[openstack-dev] [ironic] process for making decisions?

Jim Rollenhagen jim at jimrollenhagen.com
Fri May 20 12:58:21 UTC 2016


On Thu, May 19, 2016 at 02:02:32PM +0000, Loo, Ruby wrote:
> Hi,
> 
> I think it would be good if we came up with some general guidelines wrt the processes by which decisions are made. By ³decisions², I mean decisions that we, as a community, will try to abide by ?
> 
> I have noticed in the past, that discussions in the mailing list (ML) sometimes peter out without a conclusion or decision. The ML seems to be a decent forum for discussion but not for decision making. At least, that¹s my impression so far.
> 
> The (formal?) decision-making mechanisms we have are:
> - voting at our weekly ironic meeting. (When there is a vote, one can see who voted for what.)
> - In summit design sessions
> - in mid-cycles
> - via spec or code patches. if someone asks for more people to voice their opinion
> - anything else?
> 
>  We also tend to get consensus/agreement on IRC (if there are enough people present, where ³enough² typically means some number of core reviewers voicing their opinion).
> 
> I have a few concerns about the above. The ones that come to mind right now:
> - I would like it to be possible to make decisions without everyone being present at the same time. Or if that isn¹t possible/do-able right now, at least let¹s make it clearer what a process might be, with some caveat for people-who-couldn¹t-attend to disagree later?
> - consensus/agreement on IRC is nice, but I think it needs to move beyond that to being recorded somewhere. (I think we are doing this via comments in patches and other means but I don¹t know for sure.)
> 
> The reason I am bringing it up now (yes, the truth comes out) is because I asked a question on the mailing list on Monday [1] and it is now Thursday and maybe I am impatient ? I was about to reply to some of the comments and started to wonder whether it was worth replying or maybe it would be more effective (with respect to gathering the most feedback in the shortest amount of time) to move the discussion to our weekly meeting and hopefully have a decision then. (And the reason I even brought up that question was because I was reviewing someone¹s patch and it seemed like a good idea to try to unblock that patch instead of letting it languish there until someone else did something about it. But I digressŠ ?)
> 
> So what do folks think? Should a process for not-critical-or-time-sensitive-issues be e.g.: 
> - bring it up for discussion in the mailing list
> - after some elapsed amount of time (how long?) and/or petering out of replies, bring it up in some meeting for a decision?

Yeah, this is a real problem we have today. Thanks for bringing it up. :)

I have a feeling that nobody wants to be the person pushing their
decision on everyone else, for the sake of "community". However, this
leads to folks voicing their opinion on things, instead of proposing a
solution. Lots of words are said, no decisions are made.

I think that when we see discussions starting to peter out without a
decision, someone needs to step up and say "okay, I've read everything
on this, here's what I propose: ... any further objections?" (this is
best served with a patch in gerrit). Further discussion can be had in
the thread, or the patch, or whatever, but regardless the end result
should be a merged patch (whether that's specs or docs or code).

So in the particular case you mention, I'd recommend putting up a patch
to ironic-lib's readme that says "this is only meant to be used by
ironic/IPA/etc" and move the discussion there.

In general, we need to lead by example and push the discussion toward a
decision rather than more waffling in email. I realize this isn't a
concrete answer to your question, but I don't know if there is one.

If we do think we need a formal process for making decisions as you
define above, I think it should be something like:

* bring it up on the mailing list
* someone /must/ propose a solution along the way, in gerrit, perhaps
  the person that started the thread if nobody else steps up
* (if we think this is a really big decision, we can declare that X% of
  cores should vote on it before landing it)

Hope that helps. Feel free to tell me I'm talking nonsense. :)

// jim

> 
> --ruby
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-May/095090.html
> 
> 
> 
> __________________________________________________________________________
> 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