Open Stack

On 16-09-07 12:20 PM, Barrett, Carol L wrote:
>
> -----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
>
> __________________________________________________________________________
> 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

The responsibilities of a PTL is larger than focusing on a release.

Many projects have taken very specific stances on certain topics that 
span releases. The guidance and decision of the PTL at the time has 
always been a crucial part of these direction decisions for each 
individual project. Thinking of the PTL role in terms of releases fails 
to honour the larger responsibility every PTL accepts in envisioning how 
their project collaborates with other OpenStack pieces, individual 
releases notwithstanding.

Thank you,
Anita.