-----Original Message----- From: Sean Dague [mailto:s...@dague.net] Sent: Wednesday, September 07, 2016 9:05 AM To: openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev