On 25/08/14 06:30, Thierry Carrez wrote:
Zane Bitter wrote:
On 22/08/14 12:45, Dolph Mathews wrote:
I'm all for getting a final decision, but a 'final' decision that
has been
imposed from outside rather than internalised by the participants is...
rarely final.
The expectation of a PTL isn't to stomp around and make "final"
decisions,
it's to step in when necessary and help both sides find the best
solution.
To moderate.
Oh sure, but that's not just the PTL's job. That's everyone's job. Don't
you think?
I did that before I was the PTL and will continue to do it after I'm no
longer the PTL. And if anyone in the (especially) the core or wider Heat
team sees an opportunity to step in and moderate a disagreement I
certainly expect them to take it and not wait for me to step in.
I'm not calling for no leadership here - I'm calling for leadership from
_everyone_, not just from one person who holds a particular role.
I guess the difference between you and me is that I don't see having a
PTL as preventing that moderation and leadership from everyone. I really
see it as a safety valve in case things ever go badly wrong. I prefer
that safety valve to be built into the project leadership, rather than
at the TC level.
Could you explain how having a PTL is preventing that "leadership from
everyone" ? Did it prevent it in Heat ? Did having the PTL safety valve
hurt you ?
I'd say we've done fairly well, but I would attribute that at least in
part to the fact that we've treated the PTL as effectively the temporary
"release management contact" more than the "guy who will resolve
disputes for us". In other words, despite rather than because of the
requirement to have a PTL.
I do think that having a PTL with no actual responsibilities runs the
risk of having it be seen as a trophy rather than a service to the
community. The good PTLs - which so far is all of them - are likely to
respond by volunteering for just as many things as they were doing
before, so that will tend to counteract the goal of preventing burnout.
I'm open to the alternative solution (which would be for programs which
are not interested in having a PTL to just not have one). But then if
things go badly wrong, you require the TC to step in with threats of
removal of OpenStack and/or to force an election/vote in the middle of
the crisis. I'm really failing to see how that would result, in those
hypothetical crisis scenarios, in a better outcome.
I don't think there are any good scenarios if you get to that crisis
point. Imagine a scenario where the community is more or less evenly
split and neither side is willing to back down even after seeking
guidance from the TC, the PTL breaks the deadlock by fiat in lieu of
consensus, followed by an unusually high number of spelling mistakes
corrections in the source code, a single-issue election, potentially a
reversal of the decision and possibly a fork that will force the TC to
step in and choose a side. (Note: not choosing is also a choice.) That's
pretty much an unmitigated disaster too.
Our goal must be to avoid reaching the crisis point, and it seems to me
that it is actually helpful to make clear to projects that their choices
are:
Option A: reach consensus
Option B: there is no Option B
cheers,
Zane.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
