Open Stack

On 07/09/16 17:43 +0200, 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-ptl-seats
>[4]
>http://www.openstack.org/themes/openstack/images/summit-ptg-timeline-revised.png

Just want to add my opinion to the pool. I think this is a good idea and I
believe this would also help PTLs share the load, which is something I've
personally recommended to every PTL.

As other folks mentioned in this thread, I believe this will also help
increasing leadership in the community, which would be another win!

Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 847 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160908/90c4dc6f/attachment.pgp>