settingsLogin | Registersettings

[openstack-dev] [all] Timeframe for future elections & "Release stewards"

0 votes

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

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Sep 7, 2016 in openstack-dev by Thierry_Carrez (57,480 points)   3 8 13
retagged Jan 26, 2017 by admin

59 Responses

0 votes

On 09/07/2016 10: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.

I think this is a great idea. Having a person be on point for a
particular release from inception to whenever we stop caring about it
makes a lot of sense.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 7, 2016 by Monty_Taylor (22,780 points)   2 5 7
0 votes

Excerpts from Thierry Carrez's message of 2016-09-07 17:43:59 +0200:

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

Thanks for writing this up, Thierry. It sounds similar to what I
know a few companies are already doing internally. It should help
with continuity upstream, too, since the steward will work on a
given release through its whole life-cycle, rather than handing off
each time a new release cycle starts.

Doug


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 7, 2016 by Doug_Hellmann (87,520 points)   3 4 9
0 votes

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-ptl-seats
[4]
http://www.openstack.org/themes/openstack/images/summit-ptg-timeline-revised.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

--
Sean Dague
http://dague.net


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 7, 2016 by Sean_Dague (66,200 points)   4 8 14
0 votes

Doug, Thierry,

Do we want the stewards to serve as the CPL for Release team as well?

-- Dims

[1] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management

On Wed, Sep 7, 2016 at 11:57 AM, Doug Hellmann doug@doughellmann.com wrote:
Excerpts from Thierry Carrez's message of 2016-09-07 17:43:59 +0200:

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

Thanks for writing this up, Thierry. It sounds similar to what I
know a few companies are already doing internally. It should help
with continuity upstream, too, since the steward will work on a
given release through its whole life-cycle, rather than handing off
each time a new release cycle starts.

Doug


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Davanum Srinivas :: https://twitter.com/dims


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 7, 2016 by Davanum_Srinivas (35,920 points)   2 4 8
0 votes

-----Original Message-----
From: Sean Dague [mailto:sean@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-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 7, 2016 by Barrett,_Carol_L (3,380 points)   2 3
0 votes

Davanum Srinivas wrote:
Doug, Thierry,

Do we want the stewards to serve as the CPL for Release team as well?

Yes, they probably would be an evolution of the current release
liaisons. Like I said in the email, "a sort of per-cycle release liaison
on steroids".

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 7, 2016 by Thierry_Carrez (57,480 points)   3 8 13
0 votes

Barrett, Carol L wrote:
From: Sean Dague [mailto:sean@dague.net]

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.

The drawback of this approach is that it breaks the governance model
around project teams. You need a "the buck stops here" person (even if
that power is seldom used). But you can't have two -- what happens if
they disagree ?

So it's simpler to have a single PTL at all times and one or two release
liaisons at all times. Could be the same person though.

--
Thierry Carrez (ttx)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 7, 2016 by Thierry_Carrez (57,480 points)   3 8 13
0 votes

On 16-09-07 12:20 PM, Barrett, Carol L wrote:

-----Original Message-----
From: Sean Dague [mailto:sean@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-request@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@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.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 7, 2016 by Anita_Kuno (21,320 points)   3 3 4
0 votes

On Wed, Sep 7, 2016 at 11:43 AM, Thierry Carrez thierry@openstack.org 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

--
Thierry Carrez (ttx)

I like this. As someone that has been PTL for multiple cycles, it is
incredibly stressful trying to finish the release, start planning for the
next one, manage summit planning, etc. I'd love to have someone
designated to manage the release-specific bits of the project, while
PTLs can worry about the longer-term vision of the project and the
day-to-day management.

Thanks for writing this up, Thierry. :)

// jim


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 7, 2016 by Jim_Rollenhagen (12,800 points)   2 3 3
0 votes

-----Original Message-----
From: Monty Taylor mordred@inaugust.com
Reply: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org
Date: September 7, 2016 at 10:58:52
To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org
Subject:  Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

On 09/07/2016 10: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.

I think this is a great idea. Having a person be on point for a
particular release from inception to whenever we stop caring about it
makes a lot of sense.

I agree. Regardless of how PTL elections end up working, I think we should definitely move forward with this "Release Stewards" concept. It sounds like an excellent idea.

One question, should "Release Stewards" also be members of the Stable Team for that project or will they become members of the Stable Team? It seems like there should be a relationship there to me (although maybe not a strictly enforced one).

--
Ian Cordasco


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Sep 7, 2016 by sigmavirus24_at_gmai (8,720 points)   1 2 3
...