[openstack-dev] [TripleO] Review metrics - what do we want to measure?

Derek Higgins derekh at redhat.com
Thu Sep 4 15:11:40 UTC 2014


On 04/09/14 14:54, Jeremy Stanley wrote:
> On 2014-09-04 11:01:55 +0100 (+0100), Derek Higgins wrote:
> [...]
>> How would people feel about turning [auto-abandon] back on?
> 
> A lot of reviewers (myself among them) feel auto-abandon was a
> cold and emotionless way to provide feedback on a change. Especially
> on high-change-volume projects where core reviewers may at times get
> sucked into triaging other problems for long enough that the
> auto-abandoner kills lots of legitimate changes (possibly from
> new contributors who will get even more disgusted by this than the
> silence itself and walk away indefinitely with the impression that
> we really aren't a welcoming development community at all).

Ok, I see how this may be unwelcoming to a new contributor, a feeling
that could be justified in some cases. Any established contributor
should (I know I did when it was enforce) see it as part of the process.

perhaps we exempt new users?

On the other hand I'm not talking about abandoning a change because
there was silence for a fixed period of time, I'm talking about
abandoning it because it got negative feedback and it wasn't addressed
either through discussion or a new patch.

I have no problem if we push the inactivity period out to a month or
more, I just think there needs to be a cutoff at some stage.


> 
>> Can it be done on a per project basis?
> 
> It can, by running your own... but again it seems far better for
> core reviewers to decide if a change has potential or needs to be
> abandoned--that way there's an accountable human making that
> deliberate choice rather than the review team hiding behind an
> automated process so that no one is to blame for hurt feelings
> besides the infra operators who are enforcing this draconian measure
> for you.

There are plenty of examples of places where we have automated processes
in the community (some of which may hurt feeling) in order to take load
off specific individuals or the community in general. In fact automating
processes in places where people don't scale or are bottlenecks seems to
be a common theme.

We automate CI and give people negative feedback
We expire bugs in some projects that are Incomplete and are 60 days inactive

I really don't see this as the review team hiding behind an automated
process. A patch got negative feedback and we're automating the process
to prompt the submitter to deal with it. It may be more friendly if it
was a 2 step process
  1. (after a few days if inactivity) Add a comment saying you got
negative feedback with suggestions of how to proceed and information
that the review will be autoabandoned if nothing is done in X number of
days.
  2. Auto abandon patch, with as much information as possible on how to
reopen if needed.

> 
>> To make the whole process a little friendlier we could increase
>> the time frame from 1 week to 2.
> 
> <snark>How about just automatically abandon any new change as soon
> as it's published, and if the contributor really feels it's
> important they'll unabandon it.</snark>
> 




More information about the OpenStack-dev mailing list