On Wed, Mar 4, 2015, at 07:24 AM, Alexis Lee wrote: > John Griffith <john.griffi...@gmail.com> writes: > > Should we just rename this thread to "Sensitivity training for > > contributors"? > > Culture plays a role in shaping ones expectations here. I was lucky > enough to grow up in open source culture, so I can identify an automated > response easily and I don't take it too seriously. Not everyone has the > same culture and although I agree we need to confront these gaps when > they impede us, it's more constructive to reach out and bridge the gap > than blame the outsider. > > > James E. Blair said on Tue, Mar 03, 2015 at 07:49:03AM -0800: > > If I had to deprioritize something I was working on and it was > > auto-abandoned, I would not find out. > > You should receive messages from Gerrit about this. If you've made the > choice to disable or delete those messages, you should expect not to be > notified. The review dropping out of your personal dashboard active > review queue is a problem though - an email can be forgotten.
I used to use email to track such things, but I have reached the point where keeping up with the push notifications from gerrit would consume all of my waking time. I currently have 2931 unread messages in my filtered mailbox representing comments only on changesets I have submitted or reviewed, which does not include changes in repositories I am interested in or where I am a core reviewer. I'm sure that's a small number compared to some of our other developers more active than I am. We all have different workflows and ways to keep up. We can't assume that the solution any one of us uses will work for everyone involved in the project -- we work differently and we have different scopes in terms of number of repos we watch, or even the areas within a repository that we care about. Jim's proposal to provide a variation on one tool based on gerrit queries is a small change, and seems more reasonable than what appears socially as throwing away someone's work. Based on his arguments in this thread, I am going to stop abandoning patches in Oslo repositories (I was doing it by hand, rather than with a script) and start leaving comments suggesting that authors may want to update or abandon their patch instead. We have a good dashboard  set up thanks to Sean's dashboard creator tool , and I use it with reasonably good results when I sit down to do reviews.  https://wiki.openstack.org/wiki/Oslo#Review_Links  http://git.openstack.org/cgit/stackforge/gerrit-dash-creator > > For what little it's worth, I think having a community-wide definition > of inactive and flagging that in the system makes sense. This helps us > maintain a clear and consistent policy in our tools. However, I've come > around to see that abandon semantics don't fit that flag. We need to > narrow in on what inactive really means and what effects the flag should > have. We may need two flags, one for 'needs submitter attention' and one > for 'needs review attention'. As Jim and others have pointed out, we can identify those changesets using existing attributes rather than having to add a new flag. For example, that Oslo dashboard includes a section for patches that haven't been reviewed in the last 2 days and another for changes that were submitted in the last 5 days and have no reviews at all. All of the queries filter out patches failing Jenkins tests , so it's possible for us to ignore those easily. Gerrit's query language is a bit clunky, but it is quite powerful for building these sorts of useful views.  http://git.openstack.org/cgit/stackforge/gerrit-dash-creator/tree/dashboards/oslo-program.dash Doug > > > Alexis > -- > Nova Engineer, HP Cloud. AKA lealexis, lxsli. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev