Open Stack

Zane Bitter [August 25, 2014 1:38 PM] wrote:

. . .

<snip>


> 
> 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 don't think anyone is saying or even really believes that distributing the workload would result in a PTL "no actual responsibilities."  There is just so much to do as a PTL for the larger projects that even having a team focused on ensuring the tactical activities happen will still leave the PTL with a superhuman workload: planning, coordinating, correcting, driving, regrouping, focusing, liaising, etc.  

As I said in my previous mail (got lost in the conversation about what to call these team members), To keep growing quality, communications, contributions and the health of the projects and OpenStack as an ecosystem, the PTLs must not only be strategic thinkers, but strategic actors.  And it's pretty darn hard to be strategic when you're down in the tactical, day-to-day weeds.  All of it is important, but the only way to keep OpenStack growing *and* healthy is to start to specialize in organizational areas, not just code areas.

Look at the organic growth of technical projects in general.  When you start with just a few people, communication is easy.  Everyone knows the whole project and it's easy to stay on the same page.  New people come on board and now you need to document design, operation and organizational lore.  More people come on board and you need to track bugs, maybe features, and maybe split into groups, which means a leader needs to arise in each group such that the multiple groups can stay in sync and integrate their components.  And it continues to grow.  Some OpenStack projects have reached the state where each of them are really multiple projects, each with a lead.  Neutron and TripleO both address this situation, empowering the internal projects and project leads, with the PTLs becoming more strategic and more focused on the ecosystem of the subprojects.

I bet Kyle Mestery, Jay Pipes and Robert Collins would be happy to dissuade you of the idea that they don't have any responsibilities ;-)

--Rocky


> > 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev