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

James Polley jp at jamezpolley.com
Wed Sep 10 07:44:31 UTC 2014


There was some discussion of this topic during today's meeting.

Full notes are at
http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-09-09-19.04.log.html
starting around 19:24

To summarise, we had one action item, and one comment from dprince which
attracted broad agreement, and which I think is worth repeating here:

19:34:26 <tchaypo> #action bnemec to look at adding a report of items that
have a -1 from a core but no response for 14 days, as a first step towards
possibly auto-WIPing these patches

19:41:54 <dprince> I sort of feel like all the focus on stats in our
meetings is going to encourage people to game them (i.e. fly by reviews)
19:42:13 <dprince> when what we really need is ownershipt to push through
the important things...
19:42:45 * dprince thinkgs stats are becoming a TripleO waste of time
19:44:12 <jp_at_hp> stats not important, being active and responsive enough
to not push new contributors away does matter
19:44:51 <lifeless> jp_at_hp: I agree; the stats are a tool, not the thing
itself.

On Fri, Sep 5, 2014 at 9:47 PM, Sullivan, Jon Paul <JonPaul.Sullivan at hp.com>
wrote:

> > -----Original Message-----
> > From: Jay Dobies [mailto:jason.dobies at redhat.com]
> > Sent: 04 September 2014 18:24
> > To: openstack-dev at lists.openstack.org
> > Subject: Re: [openstack-dev] [TripleO] Review metrics - what do we want
> > to measure?
> >
> > >> 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.
> > >
> > > The thing is that it's also pushing more work onto already overloaded
> > > core review teams.  Maybe submitters don't like auto-abandon, but I
> > > bet they like having a core reviewer spending time cleaning up dead
> > > reviews instead of reviewing their change even less.
> > >
> > > TBH, if someone's offended by the bot then I can't imagine how
> > > incensed they must be when a human does the same thing.  The bot
> > > clearly isn't making it personal, and even if the human isn't either
> > > it's much easier to have misunderstandings (see also every over-
> > reaction to a -1 ever).
> > >
> > > I suppose it makes it easier for cores to ignore reviews, but from the
> > > other discussions I've read that hasn't gone away just because
> > > auto-abandon did, so I'm not convinced that's a solution anyway.
> >
> > +1, I don't think it'll come as much of a shock if a -1 review gets
> > closed due to time without progress.
>
> +1 to auto-abandon.
>
> Taking an excerpt from Dereks mail:
>
> > 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.
>
> This sounds like the best solution.  A 1 week warning and a 2 week
> abandoning.
>
> It is about as welcoming as this sort of thing could be for a new
> committer, whilst also avoiding an ever-growing backlog of changes that
> will never see attention because the submitter has moved on to other things.
>
> There is also the benefit of prompting submitters into action when things
> get auto-abandoned, rather than them having sitting at priority #2 or #3
> forever.
>
> I was never particularly upset over the auto-abandon, just click a single
> button in the ui and get on with it.
>
> >
> > > /2 cents
> > >
> > >>
> > >>> 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>
> > >>
> > >
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Thanks,
> Jon-Paul Sullivan ☺ Cloud Services - @hpcloud
>
> Postal Address: Hewlett-Packard Galway Limited, Ballybrit Business Park,
> Galway.
> Registered Office: Hewlett-Packard Galway Limited, 63-74 Sir John
> Rogerson's Quay, Dublin 2.
> Registered Number: 361933
>
> The contents of this message and any attachments to it are confidential
> and may be legally privileged. If you have received this message in error
> you should delete it from your system immediately and advise the sender.
>
> To any recipient of this message within HP, unless otherwise stated, you
> should consider this message and attachments as "HP CONFIDENTIAL".
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140910/d92af963/attachment.html>


More information about the OpenStack-dev mailing list