[vtk-developers] Avoiding MR stagnation (was: rules proposal drop "+1")

[Robert Maynard]

Currently I believe the issue is that the reviewer is equally at
responsible for watching the dashboard for regressions caused by MR.

Moving to a simple Yes/No +1/No system where the responsibility for
fixing failures falls to the author would solve the hesitation of
reviewers to give +2.

On Thu, Jul 7, 2016 at 10:10 AM, Will Schroeder
<will.schroeder at kitware.com> wrote:
> It's a time problem: I see chunks of code which at a superficial level seem
> fine and I'm willing to give it a +1. The problem with a +2 is that issuing
> such a score has implications that I've jumped into the code at a deep level
> and can vouch for it. This can occasionally mean hours or days of work hence
> the delay. Maybe it's because I'm a chicken and should have faith (or
> otherwise ensure) that there is enough testing to proof it out, but I feel
> reluctant in some cases to give a +2 without enough due diligence which
> takes time I often don't have. Besides more testing, one thing that might
> help would be more "documentation" providing me with the confidence that
> important issues have been considered and accounted for.....
>
> Best,
> W
>
>
> On Thu, Jul 7, 2016 at 9:56 AM, Brad King <brad.king at kitware.com> wrote:
>>
>> On 07/07/2016 08:56 AM, David E DeMarle wrote:
>> > In either case both authors and reviewers are responsible for
>> > watching the dashboards and addressing issues that come up afterward.
>>
>> This is the real reason people are hesitant to +2.  If we strengthen
>> the meaning of +1 then people will just say "LGTM" or something else
>> to "approve" without taking responsibility.  Posting +1 is a common
>> convention for voting and should not be given stronger meaning.
>>
>> The real problem we'd like to address is stagnation of MRs that
>> are ready but not merged.  The syntax for approving is not very
>> important.  We should identify reasons MRs stagnate and address
>> them directly:
>>
>> * It may be a governance problem.  No one has responsibility
>>   to ensure everything that is ready gets merged.
>>
>> * It may be a workflow problem, like waiting for buildbot results
>>   to approve and then forgetting.  The new workflow:buildbots
>>   label may help here.
>>
>> -Brad
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>
>
>
> --
> William J. Schroeder, PhD
> Kitware, Inc. - Building the World's Technical Computing Software
> 28 Corporate Drive
> Clifton Park, NY 12065
> will.schroeder at kitware.com
> http://www.kitware.com
> (518) 881-4902
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>