Open Stack

-----Original Message-----
From: Sean Dague [mailto:sean at dague.net] 
Sent: Wednesday, September 07, 2016 9:05 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

On 09/07/2016 11:43 AM, Thierry Carrez wrote:
> Hi everyone,
> 
> As you probably know by now, starting with the Boston event in 2017, 
> the Summit will happen further away from the release day and more 
> around the middle of the next development cycle. You can find more 
> info on the rationale for that at [1] and [2] if interested, this is 
> not the topic of this email.
> 
> One interesting side-effect is that since the timing of the election 
> period (for PTL and TC positions) is defined in the TC charter[3] 
> relative to the *Summit*, it means that (unless we change this) we'll 
> now run elections to renew PTL and TC positions in the middle of the 
> cycle. Crazy, right ? That's what I first thought. But after 
> discussing it with various people, this is not as crazy as it sounds.
> 
> First, the current election timing is not perfect -- we change PTLs in 
> the middle of the design summit prep, with old PTLs making Design 
> Summit space requests that will affect their successor. It's not as if 
> there was a perfect timing for doing elections.
> 
> Second, release cycles are longer than 6 months. They actually start a 
> few months before actual development starts, with discussions on next 
> cycle priorities and Design Summit prep. They continue a few months 
> after release, with critical stable branch backports and communication 
> about landed features. So they are one year-long, overlapping cycles 
> (like explained on the diagram at [4]). With that in mind, the PTL/TC 
> election actually would happen just before the start of the start of 
> the requirements-gathering pre-development phase of the next 
> development cycle, which makes a lot of sense.
> 
> Now, the main drawback of holding elections in the middle of a 
> development cycle is that you don't want to introduce a discontinuity 
> in leadership in that development cycle. To mitigate that, we propose 
> the introduction of a new role, the "release steward", which would be 
> attached to the release cycle. That person (who may or may not double 
> as
> PTL) would be responsible for a complete release cycle on a given 
> project team, from requirements gathering phase to post-release 
> bugfix-backport phase. A sort of per-cycle release liaison on steroids.
> 
> Since development cycles overlap, there would be two active release 
> stewards at all times. This would help with the awkward situation 
> where the PTL ends up having to think about the next cycle and prepare 
> the Design Summit (or PTG) while still being knee-deep juggling with 
> feature freeze exceptions, getting the current release out of the 
> door, and coordinating early critical fixes stable backports. Those 
> two jobs could be held by two different people.
> 
> Now, some teams (especially those doing intermediary releases) may 
> want to use the same super-human to handle everything (PTL, release 
> steward,
> release+1 steward), and some others might use two or three humans to
> spread the load. That's up to them. But once designated by the 
> newly-elected PTL, the release steward would be responsible for the 
> full release cycle and would not be displaced by the next PTL 6 months later.
> One year being a long time, if a steward needs to step down, the 
> currently-active PTL would appoint someone else to finish the job.
> 
> With this new concept I think we can get the best of both worlds, and 
> keep the election period as currently defined in the charter (rather 
> than having to change it). The PTLs we will elect in the coming weeks 
> won't be renewed before April, 2017 -- while Pike development will 
> start in February.
> 
> I know this can all be a bit confusing, so feel free to reach out to 
> me with questions on this.
> 
> [1] http://www.openstack.org/ptg
> [2] http://www.openstack.org/ptg/ptgfaq/
> [3]
> http://governance.openstack.org/reference/charter.html#election-for-pt
> l-seats
> [4]
> http://www.openstack.org/themes/openstack/images/summit-ptg-timeline-r
> evised.png
> 

> I think another option would be to run the PTL election early, but just don't have the turn over happen until the master release opens up. The current transition period is > > > 
> actually quite short as noted by the comments around how design summit planning happens. Having the PTL-next elected half way through the cycle, but having PTL current > 
> still > own landing the current release actually provides a lot more transition time.
>
>	-Sean

I had a similar thought to Sean's, with a few changes. Why not have a PTL own the release from start to finish, with the PTL for the next release getting elected as above. In this model, it would probably be advisable (or a guideline) that a PTL not run for 2 cycles in a row, because the work load would be unmanageable. This approach could help to grow a stronger leadership pipeline for each project and provide more opportunities for people in the team to grow their skills and take on leadership.

Carol

__________________________________________________________________________
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