apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vlad Rozov <vro...@apache.org>
Subject Re: [DISCUSS] inactive PR
Date Wed, 27 Sep 2017 16:52:06 GMT
Based on the discussion I'll update contributor/committer guidelines to

1. ask a contributor to close PR when (s)he is not ready to work on it 
in a timely manner
2. allow committers to close inactive PR after 2 month of inactivity

Any objections to closing existing (currently open) PRs that are 
inactive for 2 month?

Thank you,

Vlad

On 9/24/17 21:19, Vlad Rozov wrote:
> Assuming that a contributor tries to open new PR using the same remote 
> branch as the original PR instead of re-opening closed PR, github 
> provides a notification reminding that one already exists, so I don't 
> see why people will generally miss the old PR.
>
> The only case where closed PR can't be re-open is when the original 
> (remote) branch was deleted and re-created or after a forced push to 
> the original remote branch (that github can't distinguish from deleted 
> and re-created branch). Would you agree that a forced push for a PR 
> that was inactive for a significant period of time should be avoided 
> as it will be impossible for reviewers to recollect comments without 
> ability to see the old patch they (comments) apply to?
>
> Thank you,
>
> Vlad
>
> On 9/24/17 15:27, Pramod Immaneni wrote:
>> If PR is open, the previous comments are available in the same 
>> context as new discussions. There is no need to remember to go back 
>> to a previous closed PR to figure out what was discussed or what is 
>> outstanding. People will generally miss the old PR and will either 
>> not reopen it or will go through it, so its possible previous 
>> reviewers concerns would be lost. Also I don’t think three months is 
>> not an unreasonable time to leave PRs open, two could work.
>>
>>> On Sep 24, 2017, at 2:56 PM, Vlad Rozov <vrozov@apache.org> wrote:
>>>
>>> If a PR is closed due to inactivity and a contributor fails to 
>>> remember that he/she open a PR in the past, what is the chance that 
>>> a committer can recollect what was discussed on a PR (whether it 
>>> stays open or is closed) that was inactive for 2-3 month :)? IMO, we 
>>> should try to optimize process for good community members (those who 
>>> follow contributor guidelines) and not those who do not follow.
>>>
>>> Thank you,
>>>
>>> Vlad
>>>
>>> On 9/24/17 09:29, Pramod Immaneni wrote:
>>>>> On Sep 24, 2017, at 9:21 AM, Thomas Weise <thw@apache.org> wrote:
>>>>>
>>>>> On Sun, Sep 24, 2017 at 9:08 AM, Pramod Immaneni 
>>>>> <pramod@datatorrent.com <mailto:pramod@datatorrent.com>>
>>>>> wrote:
>>>>>
>>>>>>> On Sep 24, 2017, at 8:28 AM, Thomas Weise <thw@apache.org>
wrote:
>>>>>>>
>>>>>>> +1 for closing inactive PRs after documented period of inactivity
>>>>>>> (contributor guidelines)
>>>>>>>
>>>>>>> There is nothing "draconian" or negative about closing a PR,
it 
>>>>>>> is a
>>>>>>> function that github provides that should be used to improve
>>>>>> collaboration.
>>>>>>> PR is a review tool, it is not good to have stale or abandoned
PRs
>>>>>> sitting
>>>>>>> as open. When there is no activity on a PR and it is waiting
for 
>>>>>>> action
>>>>>> by
>>>>>>> the contributor (not ready for review), it should be closed and

>>>>>>> then
>>>>>>> re-opened once the contributor was able to move it forward and

>>>>>>> it becomes
>>>>>>> ready for review.
>>>>>>>
>>>>>>> Thomas
>>>>>> Please refer to my email again, I am not against closing PR if 
>>>>>> there is
>>>>>> inactivity. My issue is with the time period. In reality, most 
>>>>>> people will
>>>>>> create new PRs instead of reopening old ones and the old 
>>>>>> context/comments
>>>>>> will be forgotten and not addressed.
>>>>>>
>>>>>>
>>>>> Why will contributors open new PRs even in cases where changes are
>>>>> requested on an open PR? Because it is not documented or reviewers 
>>>>> don't
>>>>> encourage the proper process? We should solve that problem.
>>>> In cases where PR was closed due to inactivity and the contributor 
>>>> comes back later to work on it, they are likely going to create a 
>>>> new PR as opposed to finding the closed one and reopening it. The 
>>>> guidelines can include proper process but most likely this is one 
>>>> of those things that will require checking on the committers part.
>>>>
>>>>
>


Mime
View raw message