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 <[email protected]> wrote: > > -----Original Message----- > > From: Jay Dobies [mailto:[email protected]] > > Sent: 04 September 2014 18:24 > > To: [email protected] > > 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 > > > [email protected] > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
