[openstack-dev] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])

Tom Fifield tom at openstack.org
Tue Mar 3 05:21:58 UTC 2015

On 03/03/15 05:35, Clay Gerrard wrote:
> On Mon, Mar 2, 2015 at 8:07 AM, Duncan Thomas <duncan.thomas at gmail.com
> <mailto:duncan.thomas at gmail.com>> wrote:
>     Why do you say auto-abandon is the wrong tool? I've no problem with
>     the 1 week warning if somebody wants to implement it - I can see the
>     value. A change-set that has been ignored for X weeks is pretty much
>     the dictionary definition of abandoned
> +1 this
> I think Tom's suggested "help us help you" is a great pre-abandon
> warning.  In swift as often as not the last message ended with something
> like "you can catch me on freenode in #openstack-swift if you have any
> questions"  
> But I really can't fathom what's the harm in closing abandoned patches
> as abandoned?

It might be an interesting exercise to consider how areas like
"feedback", "criticism" or "asking for help" could potentially differ in
cultures and "levels of skill" other than the one with which one may be
most familiar.

Now, look at the wording of my above sentence and consider whether you'd
ever write it that way. Pretty damn indirect, and vague right?

It turns out that there are large swathes of the world that operate in
this much more nuanced way. Taking direct action against something
someone has produced using (from their perspective) strong/emotive
language can be at basically the same level as punching someone in the
face and yelling "You suck!" in other areas :)

I'm sure you are aware of these things - I don't mean to preach, but I
thought it would be a good chance to explain what  what the "help us
help you" message might come across to these kind of folks:
* This isn't your fault, it's OK!
* We're here to help, and you have permission to ask us for help.
* Here are some steps you can take, and you have permission to take
those steps.
* Here are some standard procedures that everyone follows, so if you
follow them you won't be caught standing out.
* If something happens after this, it's a random third party actor
that's doing it ("the system"), not a person criticising you.

Anyway, I guess I better dig up jeepyb again ...

> If the author doesn't care about the change enough to address the review
> comments (or failing tests!) and the core reviewers don't care about it
> enough to *fix it for them* - where do we think the change is going to
> go?!  It sounds like the argument is just that instead of using
> abandoned as an explicit description of an implicit state we can just
> filter these out of every view we use to look for something useful as
> "no changes for X weeks after negative feedback" rather than calling a
> spade a spade.
> I *mostly* look at patches that don't have feedback.  notmyname
> maintains the swift review dashboard AFAIK:
> http://goo.gl/r2mxbe
> It's possible that a pile of abandonded-changes-not-marked-as-abandonded
> wouldn't actually interrupt my work-flow.  But I would imagine
> maintaining the review dashboard might occasionally require looking at
> ALL the changes in the queue in an effort to look for a class of changes
> that aren't getting adequate feedback - that workflow might find the
> extra noise less than helpful.
> -Clay
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list