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> > _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev