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

[Thierry Carrez]

Matt Riedemann wrote:
>> [...]
>> Here is mine: it would fail to take into account that preparation for a
>> development cycle starts a few months /before/ PTG, not a just few weeks
>> before.
> 
> Do we really expect the next cycle PTL to be planning for the next cycle
> midway through the current cycle? That seems pretty extreme to me, when
> we're still crunching to the 3rd milestone and trying to wrap things up
> for feature freeze, which will determine a lot of what spills over into
> the next cycle.

There is /some/ expectation that by the middle of the cycle you start
listening to users and start thinking about what you won't be able to
accomplish this cycle and should definitely prioritize for the next.

It doesn't impact development yet, since as you said most people are
crunching to the 3rd milestone. But you are already past your "priority
feature freeze", and you can use the Summit to seed your thinking for
the next cycle.

I totally agree with you that it's difficult for even a single person to
switch focus to the next cycle that early. It is precisely why having
one specific person starting to think about the next cycle while almost
all the others are still wrapping up things can help. That person would
gradually involve more and more people (past feature freeze, past
RC1...) so that the next cycle doesn't start from nothing.

>> Talking with operators at the recent Ops midcycle, they were pretty
>> enthusiastic with the idea of having someone take responsibility for a
>> release cycle from day 0 (when you start collecting priorities) through
>> the development cycle, to release, up to early stable branch backports
>> and communication about the work that has been accomplished. The best
>> way to achieve that is to have that person designated in the middle of
>> the previous cycle, not just a few weeks before the development branches
>> open.
> 
> Are there specific bad acting projects that operators are having a
> problem with? Like, are there just terrible transitions happening
> somewhere in the community that the rest of us don't know about and it's
> impacting release-to-release development of major projects?

At the current design summit, operators and users trying to communicate
their priorities to some projects are routinely turned down by
developers saying that the slate is already full or the priorities are
already set. And that's fair -- eight weeks into the development cycle
is not the best moment to add priorities, so the timing of that feedback
was actively preventing it from happening.

That is why we are moving most of the feedback dialog to the "Forum"
event at the Summit in the middle of the cycle in the future --
sufficiently before the start of the "development" part of the next
release cycle that it's still time to listen. But we need someone there
to collect their feedback and start thinking about the next cycle,
otherwise you're just pretending to listen. That's why I think it's a
good idea to have someone more obviously focused on the next cycle
designated by then, to coordinate that feedback. But then, each team is
free to ignore that suggestion and handle user feedback differently.

-- 
Thierry Carrez (ttx)

__
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

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

[gordon chung]

On 09/09/16 03:50 PM, Matt Riedemann wrote:
>
> Do we really expect the next cycle PTL to be planning for the next cycle
> midway through the current cycle? That seems pretty extreme to me, when
> we're still crunching to the 3rd milestone and trying to wrap things up
> for feature freeze, which will determine a lot of what spills over into
> the next cycle.
>
> I think having a PTL switchover in the middle of a release and then
> having them start bugging everyone about planning for the next cycle
> would be really distracting.

i imagine it would be ok for transition to occur during RC period where 
the PTL-elect and some subset of contributors start planning while 
others work on stability of current release. that of course would be 
based on many assumptions like having enough contributors to take away 
resource from testing and your project as a whole being ok with a subset 
of people having fun task of planning and others laboring away at fixing 
stuff. that said, these decisions probably can't be applied to all 
projects generally.

>>
>> Talking with operators at the recent Ops midcycle, they were pretty
>> enthusiastic with the idea of having someone take responsibility for a
>> release cycle from day 0 (when you start collecting priorities) through
>> the development cycle, to release, up to early stable branch backports
>> and communication about the work that has been accomplished. The best
>> way to achieve that is to have that person designated in the middle of
>> the previous cycle, not just a few weeks before the development branches
>> open.
>>
>
> Are there specific bad acting projects that operators are having a
> problem with? Like, are there just terrible transitions happening
> somewhere in the community that the rest of us don't know about and it's
> impacting release-to-release development of major projects?

i imagine transitions would be hidden from operators by the 
deployment/packaging/release teams? i don't know of any bad transitions 
personally.

-- 
gord

__
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

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

[Matt Riedemann]

On 9/9/2016 6:49 AM, Thierry Carrez wrote:

Rob Cresswell wrote:

I've been toying with send this email for a while, but here goes: this
all feels like overcomplication and changing of a system that doesn't
really need to change.


Except the proposal here is actually to not change anything, but I see
what you mean.


I've read the pros and cons, and I still can't really see a convincing
reason not to move the PTL election to just-before-PTG, so that the new
PTL is present for one development cycle as before.


Here is mine: it would fail to take into account that preparation for a
development cycle starts a few months /before/ PTG, not a just few weeks
before.


Do we really expect the next cycle PTL to be planning for the next cycle 
midway through the current cycle? That seems pretty extreme to me, when 
we're still crunching to the 3rd milestone and trying to wrap things up 
for feature freeze, which will determine a lot of what spills over into 
the next cycle.


I think having a PTL switchover in the middle of a release and then 
having them start bugging everyone about planning for the next cycle 
would be really distracting.




Talking with operators at the recent Ops midcycle, they were pretty
enthusiastic with the idea of having someone take responsibility for a
release cycle from day 0 (when you start collecting priorities) through
the development cycle, to release, up to early stable branch backports
and communication about the work that has been accomplished. The best
way to achieve that is to have that person designated in the middle of
the previous cycle, not just a few weeks before the development branches
open.



Are there specific bad acting projects that operators are having a 
problem with? Like, are there just terrible transitions happening 
somewhere in the community that the rest of us don't know about and it's 
impacting release-to-release development of major projects?


--

Thanks,

Matt Riedemann


__
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

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

[Matt Riedemann]

On 9/9/2016 3:42 AM, Thierry Carrez wrote:


That doesn't prevent you from doing it Nova-style and use the PTL as the
release steward. It just lets you use someone else if you want to. A bit
like keeping a headphone jack. Options.



What's preventing any projects from delegating release duties to a 
non-PTL person today? That's the whole point of the release liaison I 
thought? That's why I don't really get the point of this release steward 
proposal except it's more process and a new official title, and maybe a 
different time to do the PTL election.


--

Thanks,

Matt Riedemann


__
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

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

[Nikhil Komawar]

On 9/9/16 4:42 AM, Thierry Carrez wrote:
> John Griffith wrote:
>> ​I think Sean Dague made some really good points and I'd tend to lean
>> that way.  Honestly charters, bylaws, governance etc shift or are
>> rewritten fairly often.  Why not just change when we do elections to
>> correspond with releases and keep the continuity that we have now.​  Is
>> there a problem with the existing terms and cycles that maybe I'm missing?
> AFAICT this is not what Sean is proposing. He is saying that we should
> run elections in the weeks before Summit as usual, but the newly-elected
> PTL would /not/ take over the current PTL until 3 months later when the
> next development branches are opened.
>
> While it's true that there are projects with a lot of continuity and
> succession planning, with the old PTL staying around after they have
> been replaced, there are also a fair share of projects where the PTL is
> replaced by election and either rage-quits or lowers their involvement
> significantly as a result. I'd rather have the /possibility/ to separate
> the PTL from the release steward role and ensure continuity.
>
> That doesn't prevent you from doing it Nova-style and use the PTL as the
> release steward. It just lets you use someone else if you want to. A bit
> like keeping a headphone jack. Options.

LOL. May be we need to name the release steward as "headphone jack" then!

>

-- 

Thanks,
Nikhil


__
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

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

[Jeremy Stanley]

On 2016-09-09 06:35:10 -0600 (-0600), John Griffith wrote:
> On Fri, Sep 9, 2016 at 2:42 AM, Thierry Carrez 
> wrote:
[...]
> > That doesn't prevent you from doing it Nova-style and use the PTL as the
> > release steward. It just lets you use someone else if you want to. A bit
> > like keeping a headphone jack. Options.
> >
> I see what you did there (and I like it).

An act of true courage if I've ever seen one. ;)
-- 
Jeremy Stanley

__
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

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

[Nikhil Komawar]

On 9/9/16 11:32 AM, Thierry Carrez wrote:
> Thierry Carrez wrote:
>> [...]
>> 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.
>> [...]
> Oh. Wait. *Some* of the wording in the charter actually mentions "design
> summit" -- since that's dissolved into two events, we kind of need to to
> alter the wording there anyway. There is no status quo.
>
> So we'll have to discuss whether it's better to define our next PTL/TC
> elections relative to the PTG (happening Feb 20-24, 2017) or to the
> Summit (happening May 8-12, 2017), or to something completely different
> (like the release date).
>
> I still think it's simpler to run relative to Summit (so that the PTLs
> running for election in the coming days will have a normal 6-month
> term), but the other solution would work too.
>
> Personally I care about having a point person to handle a release cycle
> from the preparation stages (months before the PTG) to the post-release
> stage (months after release). I don't care as much about exactly when
> the name of the person holding the PTL title (may) change... since there


"""
> is no perfect timing for that, you're always in the middle of something.
>
"""

"no perfect timing..." this can go in as thought of the day and I will
acknowledge +1000 to it.

-- 

Thanks,
Nikhil


__
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

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

[Thierry Carrez]

Thierry Carrez wrote:
> [...]
> 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.
> [...]

Oh. Wait. *Some* of the wording in the charter actually mentions "design
summit" -- since that's dissolved into two events, we kind of need to to
alter the wording there anyway. There is no status quo.

So we'll have to discuss whether it's better to define our next PTL/TC
elections relative to the PTG (happening Feb 20-24, 2017) or to the
Summit (happening May 8-12, 2017), or to something completely different
(like the release date).

I still think it's simpler to run relative to Summit (so that the PTLs
running for election in the coming days will have a normal 6-month
term), but the other solution would work too.

Personally I care about having a point person to handle a release cycle
from the preparation stages (months before the PTG) to the post-release
stage (months after release). I don't care as much about exactly when
the name of the person holding the PTL title (may) change... since there
is no perfect timing for that, you're always in the middle of something.

-- 
Thierry Carrez (ttx)

__
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

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

[Hongbin Lu]

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: September-09-16 8:19 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all] Timeframe for future elections &
> "Release stewards"
> 
> On 08/09/16 18:41 +, Hongbin Lu wrote:
> >
> >
> >> -Original Message-
> >> From: Thierry Carrez [mailto:thie...@openstack.org]
> >> Sent: September-08-16 5:00 AM
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [all] Timeframe for future elections &
> >> "Release stewards"
> >>
> >> Sean Dague wrote:
> >> > On 09/07/2016 12:27 PM, Thierry Carrez wrote:
> >> >> Barrett, Carol L wrote:
> >> >>> From: Sean Dague [mailto:s...@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.
> >> >
> >> > It doesn't give you 2 PTLs. It gives you PTL-next that gets to
> make
> >> > decisions on master once it opens up, and guides it until it's a
> >> > stable branch. It doesn't seem like it breaks anything to me.
> >>
> >> So... the difference between your proposal and mine is: you force
> the
> >> PTL to be the release steward (rather than having a choice there),
> >> and introduce a delay between election and start of authority for
> the PTL.
> >>
> >> I don't see that delay as a good thing. You would elect in April a
> >> PTL whose authority over the project would start in August. That
> >> sounds a bit weird to me. I'd rather say that the authority of the
> >> PTL starts when he is elected, and not introduce a delay.
> >
> >If the authority of the PTL starts in the middle of a cycle, what
> happen if the just-elected PTL disagree with what were planned by the
> previous PTL? Does the just-elected PTL have authority to override what
> were planned? For contributors, it is confusing to have two PTLs in one
> cycle. They might follow the instruction from one PTL to setup the plan
> for the whole cycle. Then, in the second half of the cycle, the new PTL
> give a totally different instruction for the same item. As a result,
> the plan needs to be changed or extra efforts are needed to ensure the
> new PTL agrees with the original plan. In this case, introducing
> "release stewards" doesn't solve the problem because this new role
> doesn't have final says.
> 
> I think you're pushing the role of the PTL a bit too far, or at least
> how PTLs should interact with the community. I've written about this in
> the past:

Maybe, but I was not arguing the role of the PTL. I was arguing it is confusing 
to have two PTLs in one cycle.

> 
> http://lists.openstack.org/pipermail/open

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

[Ihar Hrachyshka]

Thierry Carrez  wrote:


Ihar Hrachyshka wrote:

[...]
I slightly disagree with enforcing another formal role to all teams. I
feel that we have enough of them (release liaison for one) to cover for
release cross-project work, and projects are free to set their teams
with more roles if needed.


You should probably re-read what I wrote, because there is no
"enforcement" at all. There is merely the added possibility for teams to
pick someone different for release liaison work per-cycle, so that the
person preparing the next cycle is not necessarily the same person who
works on completing the release. Quoting my original email: "some teams
[...] may want to use the same super-human to handle everything [...],
and some others might use two or three humans to spread the load”.


Well, unless you won’t request projects to designate someone specific for  
the role, you enforce it. But that’s not my main problem with the proposal,  
and I can live with another name assigned to release liaison, I am more  
concerned about switching the PTL that oversights the team in the middle of  
release cycle.





I somewhat disagree with attempt to document a single project team
hierarchy and impose, top to bottom, same roles on everyone irrespective
to project needs. I understand the need of some ‘liaison’ roles where
project decisions influence other projects, but I feel that now we get
into over-formalizing internal project structure. New roles in a team
should be generally driven by actual needs, from the bottom.


Define "bottom". The need for a release liaison comes from the Release
Management Team, just as the need for an Oslo liaison comes from the
Oslo team. In case this is not clear, the idea of having "release
stewards" comes from the Release Management Team. Quoting my original
email: "a sort of per-cycle release liaison on steroids”.


There is a significant difference between release liaison role defined to  
handle cross project work, and release steward defined for what seems to be  
purely internal project matters.





I very much disagree with the idea of switching PTL in midterm. I
believe in some cases this proposal will add unnecessary rivalry in
lives of projects.


Define "midterm". If you take into account that the work on a release
cycle starts well before the development branches are open, then it's
the current elections that happen "midterm". Whenever you choose, it's
always at the start of something and the middle of something else.


From where I came (neutron), it does not happen that way, but maybe we are  
just bad at handling release cycles? We have release cut-off as an  
opportunity to clean the slate and reconsider our direction for the next  
release. I don’t think introducing a structure that will allow for  
significant direction changes in the middle of the release cycle will be to  
the benefit of the project.


But having earlier elections for more smooth power transition would.

Ihar

__
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

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

[Thierry Carrez]

Ihar Hrachyshka wrote:
> [...]
> I slightly disagree with enforcing another formal role to all teams. I
> feel that we have enough of them (release liaison for one) to cover for
> release cross-project work, and projects are free to set their teams
> with more roles if needed.

You should probably re-read what I wrote, because there is no
"enforcement" at all. There is merely the added possibility for teams to
pick someone different for release liaison work per-cycle, so that the
person preparing the next cycle is not necessarily the same person who
works on completing the release. Quoting my original email: "some teams
[...] may want to use the same super-human to handle everything [...],
and some others might use two or three humans to spread the load".

> I somewhat disagree with attempt to document a single project team
> hierarchy and impose, top to bottom, same roles on everyone irrespective
> to project needs. I understand the need of some ‘liaison’ roles where
> project decisions influence other projects, but I feel that now we get
> into over-formalizing internal project structure. New roles in a team
> should be generally driven by actual needs, from the bottom.

Define "bottom". The need for a release liaison comes from the Release
Management Team, just as the need for an Oslo liaison comes from the
Oslo team. In case this is not clear, the idea of having "release
stewards" comes from the Release Management Team. Quoting my original
email: "a sort of per-cycle release liaison on steroids".

> I very much disagree with the idea of switching PTL in midterm. I
> believe in some cases this proposal will add unnecessary rivalry in
> lives of projects.

Define "midterm". If you take into account that the work on a release
cycle starts well before the development branches are open, then it's
the current elections that happen "midterm". Whenever you choose, it's
always at the start of something and the middle of something else.

-- 
Thierry Carrez (ttx)

__
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

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

[John Griffith]

On Fri, Sep 9, 2016 at 2:42 AM, Thierry Carrez 
wrote:

> John Griffith wrote:
> > ​I think Sean Dague made some really good points and I'd tend to lean
> > that way.  Honestly charters, bylaws, governance etc shift or are
> > rewritten fairly often.  Why not just change when we do elections to
> > correspond with releases and keep the continuity that we have now.​  Is
> > there a problem with the existing terms and cycles that maybe I'm
> missing?
>
> AFAICT this is not what Sean is proposing. He is saying that we should
> run elections in the weeks before Summit as usual, but the newly-elected
> PTL would /not/ take over the current PTL until 3 months later when the
> next development branches are opened.
>
​Yes, which is a reasonable choice in my mind as well.  I was throwing out
there however that maybe this isn't that hard, maybe we could just move the
election date as well.
​


>
> While it's true that there are projects with a lot of continuity and
> succession planning, with the old PTL staying around after they have
> been replaced, there are also a fair share of projects where the PTL is
> replaced by election and either rage-quits or lowers their involvement
> significantly as a result. I'd rather have the /possibility/ to separate
> the PTL from the release steward role and ensure continuity.


> That doesn't prevent you from doing it Nova-style and use the PTL as the
> release steward. It just lets you use someone else if you want to. A bit
> like keeping a headphone jack. Options.
>
​I see what you did there (and I like it).​


>
> --
> Thierry Carrez (ttx)
>
> __
> 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

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

[Flavio Percoco]

On 08/09/16 16:48 -0600, Doug Wiegley wrote:



On Sep 8, 2016, at 12:49 PM, Matt Riedemann  wrote:

On 9/8/2016 6:42 AM, Sean Dague wrote:

On 09/08/2016 05:00 AM, Thierry Carrez wrote:

Sean Dague wrote:



So... the difference between your proposal and mine is: you force the
PTL to be the release steward (rather than having a choice there), and
introduce a delay between election and start of authority for the PTL.

I don't see that delay as a good thing. You would elect in April a PTL
whose authority over the project would start in August. That sounds a
bit weird to me. I'd rather say that the authority of the PTL starts
when he is elected, and not introduce a delay.

I don't see *forcing* the PTL to be the release steward to be a good
thing either. The just-elected PTL can totally be the release steward
for the upcoming cycle -- actually, that is how my proposal would work
by default: the PTL elected around Boston would be the default release
steward for Q, and the PTL elected around Sydney would be the default
release steward for R. But I'd rather allow for some flexibility here,
in case the PTL prefers to delegate more of his work. I also think
allowing for more leadership roles (rather than piling it all on the
PTL) helps growing a stronger leadership pipeline.

In summary, I see drawbacks to your variant, and I fail to see any
benefits... Am I missing something ?


I can only bring my own experience from projects, which is to expose
projects to succession planning a bit earlier, but otherwise keep things
the same. Both with working in the QA team, and in Nova, usually the
standing PTL starts telling folks about half way through their final
term that they aren't going to run again. And there ends up being a
bunch of private team conversations to figure out who else is
interested. Often those folks need to clear some things off their plate.
So there is some completely private indication of who might be the next
PTL. However, nothing is made official, and no one wants to presume
until an actual election happens months later.

When succession planning doesn't go well, you get to nomination week,
and you find out the current PTL isn't running, and there are two days
of mad scramble trying to figure out who is going to run.

Forcing the PTL-next conversation back some amount of time means it
matches the way I've seen succession planning work in projects for the
best handoff.

I feel like projects and PTLs do already delegate the things they can
and want to. It's not clear to me that creating another title of release
steward is going to dramatically change that. Maybe it's an active
suggestion to delegate that role out? Or that another title helps
convince employers that someone needs to end up at the PTG?

I'm also not very concerned about delayed authority of the PTL. Peaceful
handoff should be a pretty basic tenant in projects. Knowing about it
for a longer time shouldn't be a big deal. If it causes giant strife to
pass the torch from one PTL to the next there is something else going
wrong in that project. In the few cases I'm familiar with in which a
standing PTL lost an election, the relationship between that PTL and the
PTL-next was fine.

Again, these are personal experiences from the projects I'm actively
involved with, or collaborate with the most.

-Sean



+1 to everything sdague said here.


Another +1 to sdague’s sentiments.

If a PTL wants to setup this kind of heirarchy, they are already free to do so. 
 (And in your proposal, if they want to not do it, they are free not to, so why 
codify it?)


This is true but not often known or even used. Sure, anyone is free to do
whatever they feel like. Some PTLs decide to do everything themselves, others
decide to delegate as much as possible. One other benefit of Thierry's proposal
is encouraging PTLs to delegate this bit of work, which is crucial. The proposal
does that by recognizing this role in the community (this is not to say other
liaison roles are not important) and by encouraging PTLs to help creating new
leaders in the community.

Again, this is one extra benefit but not the main motivation behind this change.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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

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

[Ihar Hrachyshka]

Thierry Carrez  wrote:


Rob Cresswell wrote:

I've been toying with send this email for a while, but here goes: this
all feels like overcomplication and changing of a system that doesn't
really need to change.


Except the proposal here is actually to not change anything, but I see
what you mean.



Maybe it does not change anything in formal wording, but it definitely  
changes dynamics in project teams. I feel like it’s better to change the  
wording than impose real life impact on developers. I was actually under  
(wrong?) impression that the split summit initiative was not supposed to  
influence how engineers do their work, but now I am quite surprized by  
where it’s leading us.



I've read the pros and cons, and I still can't really see a convincing
reason not to move the PTL election to just-before-PTG, so that the new
PTL is present for one development cycle as before.


Here is mine: it would fail to take into account that preparation for a
development cycle starts a few months /before/ PTG, not a just few weeks
before.


Fine, just move the election a bit earlier, and give the new PTL to transit  
into the role naturally, having extended time to accommodate for the new  
role.


I agree the way it is done now (immediate power transition) is not ideal.  
In democracies, you usually have some time between elections and ascension  
to power. This time is taken so that the new person can learn the process,  
talk to the old PTL, close current affairs, participate in actual decisions  
for the next PTG already in the new role. I believe just holding elections  
a tad earlier (+3 weeks as of  now?) would be the best outcome.


I slightly disagree with enforcing another formal role to all teams. I feel  
that we have enough of them (release liaison for one) to cover for release  
cross-project work, and projects are free to set their teams with more  
roles if needed.


I somewhat disagree with attempt to document a single project team  
hierarchy and impose, top to bottom, same roles on everyone irrespective to  
project needs. I understand the need of some ‘liaison’ roles where project  
decisions influence other projects, but I feel that now we get into  
over-formalizing internal project structure. New roles in a team should be  
generally driven by actual needs, from the bottom.


I very much disagree with the idea of switching PTL in midterm. I believe  
in some cases this proposal will add unnecessary rivalry in lives of  
projects.


Ihar

__
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

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

[Flavio Percoco]

On 08/09/16 18:41 +, Hongbin Lu wrote:




-Original Message-
From: Thierry Carrez [mailto:thie...@openstack.org]
Sent: September-08-16 5:00 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] Timeframe for future elections &
"Release stewards"

Sean Dague wrote:
> On 09/07/2016 12:27 PM, Thierry Carrez wrote:
>> Barrett, Carol L wrote:
>>> From: Sean Dague [mailto:s...@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.
>
> It doesn't give you 2 PTLs. It gives you PTL-next that gets to make
> decisions on master once it opens up, and guides it until it's a
> stable branch. It doesn't seem like it breaks anything to me.

So... the difference between your proposal and mine is: you force the
PTL to be the release steward (rather than having a choice there), and
introduce a delay between election and start of authority for the PTL.

I don't see that delay as a good thing. You would elect in April a PTL
whose authority over the project would start in August. That sounds a
bit weird to me. I'd rather say that the authority of the PTL starts
when he is elected, and not introduce a delay.


If the authority of the PTL starts in the middle of a cycle, what happen if the 
just-elected PTL disagree with what were planned by the previous PTL? Does the 
just-elected PTL have authority to override what were planned? For contributors, it is 
confusing to have two PTLs in one cycle. They might follow the instruction from one PTL 
to setup the plan for the whole cycle. Then, in the second half of the cycle, the new PTL 
give a totally different instruction for the same item. As a result, the plan needs to be 
changed or extra efforts are needed to ensure the new PTL agrees with the original plan. 
In this case, introducing "release stewards" doesn't solve the problem because 
this new role doesn't have final says.


I think you're pushing the role of the PTL a bit too far, or at least how PTLs
should interact with the community. I've written about this in the past:

http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html

Flavio



I don't see *forcing* the PTL to be the release steward to be a good
thing either. The just-elected PTL can totally be the release steward
for the upcoming cycle -- actually, that is how my proposal would work
by default: the PTL elected around Boston would be the default release
steward for Q, and the PTL elected around Sydney would be the default
release steward for R. But I'd rather allow for some flexibility here,
in case the PTL prefers to delegate more of his work. I also think
allowing for more leadership roles (rather than piling it all on the
PTL) helps growing a stronger leadership pipeline.

In summary, I see drawbacks to your variant, and I fail to see any
benefits... Am I missing something ?

--
Thierry Carrez (ttx)

___
___
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


--
@flaper87
Flavio Percoco


signature.asc
Description:

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

[Rob Cresswell]

This makes sense to me. I think I'm having a slow day and wasn't connecting the 
dots. Having the next PTL come in and immediately hear feedback and begin 
planning how to address it, rather than coming in shortly before the planning 
event without a feedback loop, sounds like a good move.

+1

Rob

On 9 September 2016 at 12:49, Thierry Carrez 
> wrote:
Rob Cresswell wrote:
> I've been toying with send this email for a while, but here goes: this
> all feels like overcomplication and changing of a system that doesn't
> really need to change.

Except the proposal here is actually to not change anything, but I see
what you mean.

> I've read the pros and cons, and I still can't really see a convincing
> reason not to move the PTL election to just-before-PTG, so that the new
> PTL is present for one development cycle as before.

Here is mine: it would fail to take into account that preparation for a
development cycle starts a few months /before/ PTG, not a just few weeks
before.

Talking with operators at the recent Ops midcycle, they were pretty
enthusiastic with the idea of having someone take responsibility for a
release cycle from day 0 (when you start collecting priorities) through
the development cycle, to release, up to early stable branch backports
and communication about the work that has been accomplished. The best
way to achieve that is to have that person designated in the middle of
the previous cycle, not just a few weeks before the development branches
open.

--
Thierry Carrez (ttx)

__
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

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

[Thierry Carrez]

Rob Cresswell wrote:
> I've been toying with send this email for a while, but here goes: this
> all feels like overcomplication and changing of a system that doesn't
> really need to change.

Except the proposal here is actually to not change anything, but I see
what you mean.

> I've read the pros and cons, and I still can't really see a convincing
> reason not to move the PTL election to just-before-PTG, so that the new
> PTL is present for one development cycle as before.

Here is mine: it would fail to take into account that preparation for a
development cycle starts a few months /before/ PTG, not a just few weeks
before.

Talking with operators at the recent Ops midcycle, they were pretty
enthusiastic with the idea of having someone take responsibility for a
release cycle from day 0 (when you start collecting priorities) through
the development cycle, to release, up to early stable branch backports
and communication about the work that has been accomplished. The best
way to achieve that is to have that person designated in the middle of
the previous cycle, not just a few weeks before the development branches
open.

-- 
Thierry Carrez (ttx)

__
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

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

[Rob Cresswell]

I've been toying with send this email for a while, but here goes: this all 
feels like overcomplication and changing of a system that doesn't really need 
to change.

I've read the pros and cons, and I still can't really see a convincing reason 
not to move the PTL election to just-before-PTG, so that the new PTL is present 
for one development cycle as before. If the bigger projects want to have 
"release stewards" (which again, seems to be a fancy term for "current PTL" and 
"stable PTL") then they should be able to do that with the current model 
anyway. I think this preferable because it prevents any disconnect from either 
A) an election mid way through development and B) and election that isn't 
actually in effect until 3 months later.

I think the PTG/Forum change is already generating some confusion amongst 
management and organisations that are outside of core upstream development (as 
in, not 100% upstream work), and I think trying to shake up project 
organisation is just going to make things more confusing. I don't imagine I'm 
the only person reading through this thread and just wondering "why?".

I absolutely agree that encouraging people to take leadership roles and 
responsibility within their community is a great thing, but I don't think this 
really achieves it. That's down to the projects to change their culture, rather 
than just adding new roles and hoping for the best :)

Rob

On 9 September 2016 at 10:00, Thierry Carrez 
> wrote:
Sean Dague wrote:
> [...]
> I'm also not very concerned about delayed authority of the PTL. Peaceful
> handoff should be a pretty basic tenant in projects. Knowing about it
> for a longer time shouldn't be a big deal. If it causes giant strife to
> pass the torch from one PTL to the next there is something else going
> wrong in that project. In the few cases I'm familiar with in which a
> standing PTL lost an election, the relationship between that PTL and the
> PTL-next was fine.
>
> Again, these are personal experiences from the projects I'm actively
> involved with, or collaborate with the most.

I think that we are in alignment in 98% of what's proposed here.
Elections would still be run in the weeks prior to the summit. I'm
saying that there should be release stewards and by default it would be
the PTL. You are saying there should be PTLs with release duties, but
they can still delegate that. That's nearly the same thing.

The two differences are:
- defining "release stewards" as a thing slightly encourages PTLs to
delegate the role.
- the transfer of the ultimate tie-breaking/veto authority of the PTL
happens at election time in my case (as defined in the TC charter),
while you suggest it happens 3 months later, when development on N+1 starts.

One thing to note is that unless someone proposes a TC charter change
during Ocata, the authority of the newly-elected PTL starts at election
time, since the charter only recognizes one PTL at a time.

--
Thierry Carrez (ttx)

__
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

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

[Thierry Carrez]

Sean Dague wrote:
> [...]
> I'm also not very concerned about delayed authority of the PTL. Peaceful
> handoff should be a pretty basic tenant in projects. Knowing about it
> for a longer time shouldn't be a big deal. If it causes giant strife to
> pass the torch from one PTL to the next there is something else going
> wrong in that project. In the few cases I'm familiar with in which a
> standing PTL lost an election, the relationship between that PTL and the
> PTL-next was fine.
> 
> Again, these are personal experiences from the projects I'm actively
> involved with, or collaborate with the most.

I think that we are in alignment in 98% of what's proposed here.
Elections would still be run in the weeks prior to the summit. I'm
saying that there should be release stewards and by default it would be
the PTL. You are saying there should be PTLs with release duties, but
they can still delegate that. That's nearly the same thing.

The two differences are:
- defining "release stewards" as a thing slightly encourages PTLs to
delegate the role.
- the transfer of the ultimate tie-breaking/veto authority of the PTL
happens at election time in my case (as defined in the TC charter),
while you suggest it happens 3 months later, when development on N+1 starts.

One thing to note is that unless someone proposes a TC charter change
during Ocata, the authority of the newly-elected PTL starts at election
time, since the charter only recognizes one PTL at a time.

-- 
Thierry Carrez (ttx)

__
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

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

[Thierry Carrez]

John Griffith wrote:
> ​I think Sean Dague made some really good points and I'd tend to lean
> that way.  Honestly charters, bylaws, governance etc shift or are
> rewritten fairly often.  Why not just change when we do elections to
> correspond with releases and keep the continuity that we have now.​  Is
> there a problem with the existing terms and cycles that maybe I'm missing?

AFAICT this is not what Sean is proposing. He is saying that we should
run elections in the weeks before Summit as usual, but the newly-elected
PTL would /not/ take over the current PTL until 3 months later when the
next development branches are opened.

While it's true that there are projects with a lot of continuity and
succession planning, with the old PTL staying around after they have
been replaced, there are also a fair share of projects where the PTL is
replaced by election and either rage-quits or lowers their involvement
significantly as a result. I'd rather have the /possibility/ to separate
the PTL from the release steward role and ensure continuity.

That doesn't prevent you from doing it Nova-style and use the PTL as the
release steward. It just lets you use someone else if you want to. A bit
like keeping a headphone jack. Options.

-- 
Thierry Carrez (ttx)

__
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

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

[Lana Brindley]

On 08/09/16 04:46, Matt Riedemann wrote:
> On 9/7/2016 11:33 AM, Jim Rollenhagen wrote:
>>
>> 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
>>
> 
> I don't really see how managing the release-specific bits of the project as a 
> 'release steward' is different from a release cross-project liaison. Nova has 
> a release CPL (really more than one probably informally).
> 
> I do think it's a bit weird that I've already slotted the Ocata design summit 
> rooms for Nova when someone else could be PTL, but I don't think what I'd 
> reserve would be drastically different from someone else in Nova, this is why 
> we have trust relationships and talk about stuff as a team.  There was a lot 
> of overlap from Michael to John and from John to myself and we've shared 
> responsibilities during those transitions.
> 
> The release steward concept just seems like unnecessarily complexity and 
> formality to me, but that's just my opinion. Things might work differently in 
> other projects.
> 

Although I appreciate that my project is probably a bit different to many of 
the others (horizontal vs vertical, etc), I much prefer this method of 
overlapping the PTL changeover a little more instead of appointing form 
stewards. 

In docs, we've started assigning two release managers about a month before 
release time. They work with the PTL and other core team members to make sure 
the release happens smoothly, which allows the PTL the luxury of knowing 
there's eyes on all those small pieces that need to happen to get the release 
out while they get on with Summit prep. This means that having a formal release 
steward would just mean we appoint that person earlier in the cycle, so there's 
no real change for us in Thierry's proposal. We did this for a lot of reasons, 
at least some of which are about training people to understand the project on a 
deeper level (and thus create a leadership pipeline, of sorts). 

Having the PTL changeover time increase would have helped greatly during the 
time I was taking over as PTL from Anne. Like I said, docs is a little 
different, we have very little PTL-churn, which means that changeover process 
is a lot more complicated and involves a lot more information exchange than 
other projects that regularly change PTLs, I think. So I think this would be 
good for us, but accept that it might not work so well for other projects.

Lana

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



signature.asc
Description: OpenPGP digital signature
__
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

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

[gordon chung]

On 07/09/16 12:04 PM, Sean Dague wrote:
> 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
>

i would probably lean towards this proposal as well since, for better or 
worse, the PTL and the PTL-elect tend not to differ very drastically 
given it's usually (always?) another fellow core member so conflict is 
rare/non-issue.

i'm not against release stewards idea but i'm not entirely sure how it's 
different from release liaison. if it's just the liaison, i think the 
indifference to who it is and whether it's the PTL or not will cause 
similar indifference. we've 

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

[Doug Wiegley]

> On Sep 8, 2016, at 12:49 PM, Matt Riedemann  
> wrote:
> 
> On 9/8/2016 6:42 AM, Sean Dague wrote:
>> On 09/08/2016 05:00 AM, Thierry Carrez wrote:
>>> Sean Dague wrote:
>> 
>>> So... the difference between your proposal and mine is: you force the
>>> PTL to be the release steward (rather than having a choice there), and
>>> introduce a delay between election and start of authority for the PTL.
>>> 
>>> I don't see that delay as a good thing. You would elect in April a PTL
>>> whose authority over the project would start in August. That sounds a
>>> bit weird to me. I'd rather say that the authority of the PTL starts
>>> when he is elected, and not introduce a delay.
>>> 
>>> I don't see *forcing* the PTL to be the release steward to be a good
>>> thing either. The just-elected PTL can totally be the release steward
>>> for the upcoming cycle -- actually, that is how my proposal would work
>>> by default: the PTL elected around Boston would be the default release
>>> steward for Q, and the PTL elected around Sydney would be the default
>>> release steward for R. But I'd rather allow for some flexibility here,
>>> in case the PTL prefers to delegate more of his work. I also think
>>> allowing for more leadership roles (rather than piling it all on the
>>> PTL) helps growing a stronger leadership pipeline.
>>> 
>>> In summary, I see drawbacks to your variant, and I fail to see any
>>> benefits... Am I missing something ?
>> 
>> I can only bring my own experience from projects, which is to expose
>> projects to succession planning a bit earlier, but otherwise keep things
>> the same. Both with working in the QA team, and in Nova, usually the
>> standing PTL starts telling folks about half way through their final
>> term that they aren't going to run again. And there ends up being a
>> bunch of private team conversations to figure out who else is
>> interested. Often those folks need to clear some things off their plate.
>> So there is some completely private indication of who might be the next
>> PTL. However, nothing is made official, and no one wants to presume
>> until an actual election happens months later.
>> 
>> When succession planning doesn't go well, you get to nomination week,
>> and you find out the current PTL isn't running, and there are two days
>> of mad scramble trying to figure out who is going to run.
>> 
>> Forcing the PTL-next conversation back some amount of time means it
>> matches the way I've seen succession planning work in projects for the
>> best handoff.
>> 
>> I feel like projects and PTLs do already delegate the things they can
>> and want to. It's not clear to me that creating another title of release
>> steward is going to dramatically change that. Maybe it's an active
>> suggestion to delegate that role out? Or that another title helps
>> convince employers that someone needs to end up at the PTG?
>> 
>> I'm also not very concerned about delayed authority of the PTL. Peaceful
>> handoff should be a pretty basic tenant in projects. Knowing about it
>> for a longer time shouldn't be a big deal. If it causes giant strife to
>> pass the torch from one PTL to the next there is something else going
>> wrong in that project. In the few cases I'm familiar with in which a
>> standing PTL lost an election, the relationship between that PTL and the
>> PTL-next was fine.
>> 
>> Again, these are personal experiences from the projects I'm actively
>> involved with, or collaborate with the most.
>> 
>>  -Sean
>> 
> 
> +1 to everything sdague said here.

Another +1 to sdague’s sentiments.

If a PTL wants to setup this kind of heirarchy, they are already free to do so. 
 (And in your proposal, if they want to not do it, they are free not to, so why 
codify it?)

Thanks,
doug

> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __
> 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

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

[Doug Hellmann]

Excerpts from John Griffith's message of 2016-09-08 14:13:14 -0600:
> On Thu, Sep 8, 2016 at 12:49 PM, Matt Riedemann 
> wrote:
> 
> > On 9/8/2016 6:42 AM, Sean Dague wrote:
> >
> >> On 09/08/2016 05:00 AM, Thierry Carrez wrote:
> >>
> >>> Sean Dague wrote:
> >>>
> >> 
> >>
> >>> So... the difference between your proposal and mine is: you force the
> >>> PTL to be the release steward (rather than having a choice there), and
> >>> introduce a delay between election and start of authority for the PTL.
> >>>
> >>> I don't see that delay as a good thing. You would elect in April a PTL
> >>> whose authority over the project would start in August. That sounds a
> >>> bit weird to me. I'd rather say that the authority of the PTL starts
> >>> when he is elected, and not introduce a delay.
> >>>
> >>> I don't see *forcing* the PTL to be the release steward to be a good
> >>> thing either. The just-elected PTL can totally be the release steward
> >>> for the upcoming cycle -- actually, that is how my proposal would work
> >>> by default: the PTL elected around Boston would be the default release
> >>> steward for Q, and the PTL elected around Sydney would be the default
> >>> release steward for R. But I'd rather allow for some flexibility here,
> >>> in case the PTL prefers to delegate more of his work. I also think
> >>> allowing for more leadership roles (rather than piling it all on the
> >>> PTL) helps growing a stronger leadership pipeline.
> >>>
> >>> In summary, I see drawbacks to your variant, and I fail to see any
> >>> benefits... Am I missing something ?
> >>>
> >>
> >> I can only bring my own experience from projects, which is to expose
> >> projects to succession planning a bit earlier, but otherwise keep things
> >> the same. Both with working in the QA team, and in Nova, usually the
> >> standing PTL starts telling folks about half way through their final
> >> term that they aren't going to run again. And there ends up being a
> >> bunch of private team conversations to figure out who else is
> >> interested. Often those folks need to clear some things off their plate.
> >> So there is some completely private indication of who might be the next
> >> PTL. However, nothing is made official, and no one wants to presume
> >> until an actual election happens months later.
> >>
> >> When succession planning doesn't go well, you get to nomination week,
> >> and you find out the current PTL isn't running, and there are two days
> >> of mad scramble trying to figure out who is going to run.
> >>
> >> Forcing the PTL-next conversation back some amount of time means it
> >> matches the way I've seen succession planning work in projects for the
> >> best handoff.
> >>
> >> I feel like projects and PTLs do already delegate the things they can
> >> and want to. It's not clear to me that creating another title of release
> >> steward is going to dramatically change that. Maybe it's an active
> >> suggestion to delegate that role out? Or that another title helps
> >> convince employers that someone needs to end up at the PTG?
> >>
> >> I'm also not very concerned about delayed authority of the PTL. Peaceful
> >> handoff should be a pretty basic tenant in projects. Knowing about it
> >> for a longer time shouldn't be a big deal. If it causes giant strife to
> >> pass the torch from one PTL to the next there is something else going
> >> wrong in that project. In the few cases I'm familiar with in which a
> >> standing PTL lost an election, the relationship between that PTL and the
> >> PTL-next was fine.
> >>
> >> Again, these are personal experiences from the projects I'm actively
> >> involved with, or collaborate with the most.
> >>
> >> -Sean
> >>
> >>
> > +1 to everything sdague said here.
> >
> > --
> >
> > Thanks,
> >
> > Matt Riedemann
> >
> >
> >
> > __
> > 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
> >
> ​I think Sean Dague made some really good points and I'd tend to lean that
> way.  Honestly charters, bylaws, governance etc shift or are rewritten
> fairly often.  Why not just change when we do elections to correspond with
> releases and keep the continuity that we have now.​  Is there a problem
> with the existing terms and cycles that maybe I'm missing?
> 
> If there's a real hang up on the wording of it being related to the summit,
> then fine... word it such that the election is "summit-date - N months =
> election-date".  I think there is value in continuity of a single PTL for a
> release cycle personally.

Someone needs to write up those changes soon. Self-nominations for
PTL elections are next week and the voting is the week after.

Doug

__
OpenStack 

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

[Nikhil Komawar]

On 9/8/16 7:42 AM, Sean Dague wrote:
> On 09/08/2016 05:00 AM, Thierry Carrez wrote:
>> Sean Dague wrote:
> 
>> So... the difference between your proposal and mine is: you force the
>> PTL to be the release steward (rather than having a choice there), and
>> introduce a delay between election and start of authority for the PTL.
>>
>> I don't see that delay as a good thing. You would elect in April a PTL
>> whose authority over the project would start in August. That sounds a
>> bit weird to me. I'd rather say that the authority of the PTL starts
>> when he is elected, and not introduce a delay.
>>
>> I don't see *forcing* the PTL to be the release steward to be a good
>> thing either. The just-elected PTL can totally be the release steward
>> for the upcoming cycle -- actually, that is how my proposal would work
>> by default: the PTL elected around Boston would be the default release
>> steward for Q, and the PTL elected around Sydney would be the default
>> release steward for R. But I'd rather allow for some flexibility here,
>> in case the PTL prefers to delegate more of his work. I also think
>> allowing for more leadership roles (rather than piling it all on the
>> PTL) helps growing a stronger leadership pipeline.
>>
>> In summary, I see drawbacks to your variant, and I fail to see any
>> benefits... Am I missing something ?
> I can only bring my own experience from projects, which is to expose
> projects to succession planning a bit earlier, but otherwise keep things
> the same. Both with working in the QA team, and in Nova, usually the
> standing PTL starts telling folks about half way through their final
> term that they aren't going to run again. And there ends up being a
> bunch of private team conversations to figure out who else is
> interested. Often those folks need to clear some things off their plate.
> So there is some completely private indication of who might be the next
> PTL. However, nothing is made official, and no one wants to presume
> until an actual election happens months later.
>
> When succession planning doesn't go well, you get to nomination week,
> and you find out the current PTL isn't running, and there are two days
> of mad scramble trying to figure out who is going to run.
>
> Forcing the PTL-next conversation back some amount of time means it
> matches the way I've seen succession planning work in projects for the
> best handoff.
>
> I feel like projects and PTLs do already delegate the things they can
> and want to. It's not clear to me that creating another title of release
> steward is going to dramatically change that. Maybe it's an active
> suggestion to delegate that role out? Or that another title helps
> convince employers that someone needs to end up at the PTG?

I think yes, an active suggestion to delegate that role out. My
experiences tell me that release work and PTL work may not always play
fair with each others. It is very useful to have someone else take care
of the releases stuff while a PTL will try to co-ordinate other pieces
of the projects.

Honestly, I think the "release stewards" concept looks more of a formal
approach to recognize liaisons. I know projects internally appreciate
what the individual liaisons do but I haven't observed one too many
instances where such individuals get wider visibility for their work.
Having another individual take care of this complicated release work
while the PTL focuses on planning and feature work -- looks like a good
idea to handle two ends of spectrum; one which is about planning,
discussions, setting trade-offs for all the different kinds of impacts a
new introduction may have, cross collaboration etc. and the other is
about getting things done, a more focused and prioritize
what-matters-only-now work.


> I'm also not very concerned about delayed authority of the PTL. Peaceful
> handoff should be a pretty basic tenant in projects. Knowing about it
> for a longer time shouldn't be a big deal. If it causes giant strife to
> pass the torch from one PTL to the next there is something else going
> wrong in that project. In the few cases I'm familiar with in which a
> standing PTL lost an election, the relationship between that PTL and the
> PTL-next was fine.
>
> Again, these are personal experiences from the projects I'm actively
> involved with, or collaborate with the most.
>
>   -Sean
>
>
>


-- 

Thanks,
Nikhil



__
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

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

[Nikhil Komawar]

Good comment and I have an answer inline.



On 9/8/16 2:41 PM, Hongbin Lu wrote:
>
>> -Original Message-
>> From: Thierry Carrez [mailto:thie...@openstack.org]
>> Sent: September-08-16 5:00 AM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [all] Timeframe for future elections &
>> "Release stewards"
>>
>> Sean Dague wrote:
>>> On 09/07/2016 12:27 PM, Thierry Carrez wrote:
>>>> Barrett, Carol L wrote:
>>>>> From: Sean Dague [mailto:s...@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.
>>> It doesn't give you 2 PTLs. It gives you PTL-next that gets to make
>>> decisions on master once it opens up, and guides it until it's a
>>> stable branch. It doesn't seem like it breaks anything to me.
>> So... the difference between your proposal and mine is: you force the
>> PTL to be the release steward (rather than having a choice there), and
>> introduce a delay between election and start of authority for the PTL.
>>
>> I don't see that delay as a good thing. You would elect in April a PTL
>> whose authority over the project would start in August. That sounds a
>> bit weird to me. I'd rather say that the authority of the PTL starts
>> when he is elected, and not introduce a delay.
> If the authority of the PTL starts in the middle of a cycle, what happen if 
> the just-elected PTL disagree with what were planned by the previous PTL? 
> Does the just-elected PTL have authority to override what were planned? For 
> contributors, it is confusing to have two PTLs in one cycle. They might 
> follow the instruction from one PTL to setup the plan for the whole cycle. 
> Then, in the second half of the cycle, the new PTL give a totally different 
> instruction for the same item. As a result, the plan needs to be changed or 
> extra efforts are needed to ensure the new PTL agrees with the original plan. 
> In this case, introducing "release stewards" doesn't solve the problem 
> because this new role doesn't have final says.

Firstly, I'd like to say that the wording is bit strong here but I can
see where it may be coming from.

To be fair to all (i.e. generalizing this a bit), I think the PTL is
more of a guide than authority. Nevertheless, veto "does" belong to the
PTL but too many veto-s means misuse of authority and the veto loses its
value. So, a PTL, in most cases, doesn't give 'instructions' (well
unless you are doing fixed-timeline work like releases), PTL is supposed
to facilitate with planning, co-coordinating different interest parties,
determining the priorities/preferences, make educated guesses for the
feature and core bandwidth, etc.

So.. in a good coherent community (which is what each project should aim
for) we won't have drastically varying decisions during the transition
phase (PTL elections). Also, the elections should indicate that the new
PTL should respect the decisions that were taken by the former one.
Dissolving the power (or rights) from the PTL to more people in the team
(like in this case the release stewards) will ensure a check on anyone
having radical (very different) ideas in the middle of a running cycle.

To be ev

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

[John Griffith]

On Thu, Sep 8, 2016 at 12:49 PM, Matt Riedemann 
wrote:

> On 9/8/2016 6:42 AM, Sean Dague wrote:
>
>> On 09/08/2016 05:00 AM, Thierry Carrez wrote:
>>
>>> Sean Dague wrote:
>>>
>> 
>>
>>> So... the difference between your proposal and mine is: you force the
>>> PTL to be the release steward (rather than having a choice there), and
>>> introduce a delay between election and start of authority for the PTL.
>>>
>>> I don't see that delay as a good thing. You would elect in April a PTL
>>> whose authority over the project would start in August. That sounds a
>>> bit weird to me. I'd rather say that the authority of the PTL starts
>>> when he is elected, and not introduce a delay.
>>>
>>> I don't see *forcing* the PTL to be the release steward to be a good
>>> thing either. The just-elected PTL can totally be the release steward
>>> for the upcoming cycle -- actually, that is how my proposal would work
>>> by default: the PTL elected around Boston would be the default release
>>> steward for Q, and the PTL elected around Sydney would be the default
>>> release steward for R. But I'd rather allow for some flexibility here,
>>> in case the PTL prefers to delegate more of his work. I also think
>>> allowing for more leadership roles (rather than piling it all on the
>>> PTL) helps growing a stronger leadership pipeline.
>>>
>>> In summary, I see drawbacks to your variant, and I fail to see any
>>> benefits... Am I missing something ?
>>>
>>
>> I can only bring my own experience from projects, which is to expose
>> projects to succession planning a bit earlier, but otherwise keep things
>> the same. Both with working in the QA team, and in Nova, usually the
>> standing PTL starts telling folks about half way through their final
>> term that they aren't going to run again. And there ends up being a
>> bunch of private team conversations to figure out who else is
>> interested. Often those folks need to clear some things off their plate.
>> So there is some completely private indication of who might be the next
>> PTL. However, nothing is made official, and no one wants to presume
>> until an actual election happens months later.
>>
>> When succession planning doesn't go well, you get to nomination week,
>> and you find out the current PTL isn't running, and there are two days
>> of mad scramble trying to figure out who is going to run.
>>
>> Forcing the PTL-next conversation back some amount of time means it
>> matches the way I've seen succession planning work in projects for the
>> best handoff.
>>
>> I feel like projects and PTLs do already delegate the things they can
>> and want to. It's not clear to me that creating another title of release
>> steward is going to dramatically change that. Maybe it's an active
>> suggestion to delegate that role out? Or that another title helps
>> convince employers that someone needs to end up at the PTG?
>>
>> I'm also not very concerned about delayed authority of the PTL. Peaceful
>> handoff should be a pretty basic tenant in projects. Knowing about it
>> for a longer time shouldn't be a big deal. If it causes giant strife to
>> pass the torch from one PTL to the next there is something else going
>> wrong in that project. In the few cases I'm familiar with in which a
>> standing PTL lost an election, the relationship between that PTL and the
>> PTL-next was fine.
>>
>> Again, these are personal experiences from the projects I'm actively
>> involved with, or collaborate with the most.
>>
>> -Sean
>>
>>
> +1 to everything sdague said here.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
> __
> 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
>
​I think Sean Dague made some really good points and I'd tend to lean that
way.  Honestly charters, bylaws, governance etc shift or are rewritten
fairly often.  Why not just change when we do elections to correspond with
releases and keep the continuity that we have now.​  Is there a problem
with the existing terms and cycles that maybe I'm missing?

If there's a real hang up on the wording of it being related to the summit,
then fine... word it such that the election is "summit-date - N months =
election-date".  I think there is value in continuity of a single PTL for a
release cycle personally.
__
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

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

[Matt Riedemann]

On 9/8/2016 6:42 AM, Sean Dague wrote:

On 09/08/2016 05:00 AM, Thierry Carrez wrote:

Sean Dague wrote:



So... the difference between your proposal and mine is: you force the
PTL to be the release steward (rather than having a choice there), and
introduce a delay between election and start of authority for the PTL.

I don't see that delay as a good thing. You would elect in April a PTL
whose authority over the project would start in August. That sounds a
bit weird to me. I'd rather say that the authority of the PTL starts
when he is elected, and not introduce a delay.

I don't see *forcing* the PTL to be the release steward to be a good
thing either. The just-elected PTL can totally be the release steward
for the upcoming cycle -- actually, that is how my proposal would work
by default: the PTL elected around Boston would be the default release
steward for Q, and the PTL elected around Sydney would be the default
release steward for R. But I'd rather allow for some flexibility here,
in case the PTL prefers to delegate more of his work. I also think
allowing for more leadership roles (rather than piling it all on the
PTL) helps growing a stronger leadership pipeline.

In summary, I see drawbacks to your variant, and I fail to see any
benefits... Am I missing something ?


I can only bring my own experience from projects, which is to expose
projects to succession planning a bit earlier, but otherwise keep things
the same. Both with working in the QA team, and in Nova, usually the
standing PTL starts telling folks about half way through their final
term that they aren't going to run again. And there ends up being a
bunch of private team conversations to figure out who else is
interested. Often those folks need to clear some things off their plate.
So there is some completely private indication of who might be the next
PTL. However, nothing is made official, and no one wants to presume
until an actual election happens months later.

When succession planning doesn't go well, you get to nomination week,
and you find out the current PTL isn't running, and there are two days
of mad scramble trying to figure out who is going to run.

Forcing the PTL-next conversation back some amount of time means it
matches the way I've seen succession planning work in projects for the
best handoff.

I feel like projects and PTLs do already delegate the things they can
and want to. It's not clear to me that creating another title of release
steward is going to dramatically change that. Maybe it's an active
suggestion to delegate that role out? Or that another title helps
convince employers that someone needs to end up at the PTG?

I'm also not very concerned about delayed authority of the PTL. Peaceful
handoff should be a pretty basic tenant in projects. Knowing about it
for a longer time shouldn't be a big deal. If it causes giant strife to
pass the torch from one PTL to the next there is something else going
wrong in that project. In the few cases I'm familiar with in which a
standing PTL lost an election, the relationship between that PTL and the
PTL-next was fine.

Again, these are personal experiences from the projects I'm actively
involved with, or collaborate with the most.

-Sean



+1 to everything sdague said here.

--

Thanks,

Matt Riedemann


__
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

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

[Hongbin Lu]

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: September-08-16 5:00 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all] Timeframe for future elections &
> "Release stewards"
> 
> Sean Dague wrote:
> > On 09/07/2016 12:27 PM, Thierry Carrez wrote:
> >> Barrett, Carol L wrote:
> >>> From: Sean Dague [mailto:s...@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.
> >
> > It doesn't give you 2 PTLs. It gives you PTL-next that gets to make
> > decisions on master once it opens up, and guides it until it's a
> > stable branch. It doesn't seem like it breaks anything to me.
> 
> So... the difference between your proposal and mine is: you force the
> PTL to be the release steward (rather than having a choice there), and
> introduce a delay between election and start of authority for the PTL.
> 
> I don't see that delay as a good thing. You would elect in April a PTL
> whose authority over the project would start in August. That sounds a
> bit weird to me. I'd rather say that the authority of the PTL starts
> when he is elected, and not introduce a delay.

If the authority of the PTL starts in the middle of a cycle, what happen if the 
just-elected PTL disagree with what were planned by the previous PTL? Does the 
just-elected PTL have authority to override what were planned? For 
contributors, it is confusing to have two PTLs in one cycle. They might follow 
the instruction from one PTL to setup the plan for the whole cycle. Then, in 
the second half of the cycle, the new PTL give a totally different instruction 
for the same item. As a result, the plan needs to be changed or extra efforts 
are needed to ensure the new PTL agrees with the original plan. In this case, 
introducing "release stewards" doesn't solve the problem because this new role 
doesn't have final says.

> 
> I don't see *forcing* the PTL to be the release steward to be a good
> thing either. The just-elected PTL can totally be the release steward
> for the upcoming cycle -- actually, that is how my proposal would work
> by default: the PTL elected around Boston would be the default release
> steward for Q, and the PTL elected around Sydney would be the default
> release steward for R. But I'd rather allow for some flexibility here,
> in case the PTL prefers to delegate more of his work. I also think
> allowing for more leadership roles (rather than piling it all on the
> PTL) helps growing a stronger leadership pipeline.
> 
> In summary, I see drawbacks to your variant, and I fail to see any
> benefits... Am I missing something ?
> 
> --
> Thierry Carrez (ttx)
> 
> ___
> ___
> 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

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

[Flavio Percoco]

On 07/09/16 12:02 -0500, Monty Taylor wrote:

On 09/07/2016 11:43 AM, Davanum Srinivas wrote:

On Wed, Sep 7, 2016 at 12:35 PM, Ian Cordasco <sigmaviru...@gmail.com> wrote:



-Original Message-
From: Monty Taylor <mord...@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.


Also since "Release Stewards" are nominated by PTL, projects can just
start using this concept right away (as it's not an elected position).
+1 from me.


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).


I think they should be. If they are the Steward 

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

[Flavio Percoco]

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


signature.asc
Description: PGP signature
__
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

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

[Sean Dague]

On 09/08/2016 05:00 AM, Thierry Carrez wrote:
> Sean Dague wrote:

> So... the difference between your proposal and mine is: you force the
> PTL to be the release steward (rather than having a choice there), and
> introduce a delay between election and start of authority for the PTL.
> 
> I don't see that delay as a good thing. You would elect in April a PTL
> whose authority over the project would start in August. That sounds a
> bit weird to me. I'd rather say that the authority of the PTL starts
> when he is elected, and not introduce a delay.
> 
> I don't see *forcing* the PTL to be the release steward to be a good
> thing either. The just-elected PTL can totally be the release steward
> for the upcoming cycle -- actually, that is how my proposal would work
> by default: the PTL elected around Boston would be the default release
> steward for Q, and the PTL elected around Sydney would be the default
> release steward for R. But I'd rather allow for some flexibility here,
> in case the PTL prefers to delegate more of his work. I also think
> allowing for more leadership roles (rather than piling it all on the
> PTL) helps growing a stronger leadership pipeline.
> 
> In summary, I see drawbacks to your variant, and I fail to see any
> benefits... Am I missing something ?

I can only bring my own experience from projects, which is to expose
projects to succession planning a bit earlier, but otherwise keep things
the same. Both with working in the QA team, and in Nova, usually the
standing PTL starts telling folks about half way through their final
term that they aren't going to run again. And there ends up being a
bunch of private team conversations to figure out who else is
interested. Often those folks need to clear some things off their plate.
So there is some completely private indication of who might be the next
PTL. However, nothing is made official, and no one wants to presume
until an actual election happens months later.

When succession planning doesn't go well, you get to nomination week,
and you find out the current PTL isn't running, and there are two days
of mad scramble trying to figure out who is going to run.

Forcing the PTL-next conversation back some amount of time means it
matches the way I've seen succession planning work in projects for the
best handoff.

I feel like projects and PTLs do already delegate the things they can
and want to. It's not clear to me that creating another title of release
steward is going to dramatically change that. Maybe it's an active
suggestion to delegate that role out? Or that another title helps
convince employers that someone needs to end up at the PTG?

I'm also not very concerned about delayed authority of the PTL. Peaceful
handoff should be a pretty basic tenant in projects. Knowing about it
for a longer time shouldn't be a big deal. If it causes giant strife to
pass the torch from one PTL to the next there is something else going
wrong in that project. In the few cases I'm familiar with in which a
standing PTL lost an election, the relationship between that PTL and the
PTL-next was fine.

Again, these are personal experiences from the projects I'm actively
involved with, or collaborate with the most.

-Sean

-- 
Sean Dague
http://dague.net

__
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

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

[Thierry Carrez]

Sean Dague wrote:
> On 09/07/2016 12:27 PM, Thierry Carrez wrote:
>> Barrett, Carol L wrote:
>>> From: Sean Dague [mailto:s...@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.
> 
> It doesn't give you 2 PTLs. It gives you PTL-next that gets to make
> decisions on master once it opens up, and guides it until it's a stable
> branch. It doesn't seem like it breaks anything to me.

So... the difference between your proposal and mine is: you force the
PTL to be the release steward (rather than having a choice there), and
introduce a delay between election and start of authority for the PTL.

I don't see that delay as a good thing. You would elect in April a PTL
whose authority over the project would start in August. That sounds a
bit weird to me. I'd rather say that the authority of the PTL starts
when he is elected, and not introduce a delay.

I don't see *forcing* the PTL to be the release steward to be a good
thing either. The just-elected PTL can totally be the release steward
for the upcoming cycle -- actually, that is how my proposal would work
by default: the PTL elected around Boston would be the default release
steward for Q, and the PTL elected around Sydney would be the default
release steward for R. But I'd rather allow for some flexibility here,
in case the PTL prefers to delegate more of his work. I also think
allowing for more leadership roles (rather than piling it all on the
PTL) helps growing a stronger leadership pipeline.

In summary, I see drawbacks to your variant, and I fail to see any
benefits... Am I missing something ?

-- 
Thierry Carrez (ttx)

__
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

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

[Hongbin Lu]

> -Original Message-
> From: Sean McGinnis [mailto:sean.mcgin...@gmx.com]
> Sent: September-07-16 3:17 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all] Timeframe for future elections &
> "Release stewards"
> 
> On Wed, Sep 07, 2016 at 01:07:22PM -0400, Sean Dague wrote:
> > On 09/07/2016 12:27 PM, Thierry Carrez wrote:
> > > Barrett, Carol L wrote:
> > >> From: Sean Dague [mailto:s...@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.
> >
> > It doesn't give you 2 PTLs. It gives you PTL-next that gets to make
> > decisions on master once it opens up, and guides it until it's a
> > stable branch. It doesn't seem like it breaks anything to me.
> >
> > -Sean
> 
> In the <5 minutes I've taken so far to digest this thread, this is my
> preference. It gives the incoming PTL extra run time to start planning
> and thinking about their cycle. There would be less transition time
> between PTLs and the incoming PTL can start making the decisions like
> Summit planning that will impact them.
> 
> It's at least a simpler transition from where we are to where we want
> to be.

+1

> 
> >
> > --
> > Sean Dague
> > http://dague.net
> >
> >
> __
> >  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

__
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

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

[Sean McGinnis]

On Wed, Sep 07, 2016 at 01:07:22PM -0400, Sean Dague wrote:
> On 09/07/2016 12:27 PM, Thierry Carrez wrote:
> > Barrett, Carol L wrote:
> >> From: Sean Dague [mailto:s...@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.
> 
> It doesn't give you 2 PTLs. It gives you PTL-next that gets to make
> decisions on master once it opens up, and guides it until it's a stable
> branch. It doesn't seem like it breaks anything to me.
> 
>   -Sean

In the <5 minutes I've taken so far to digest this thread, this is my
preference. It gives the incoming PTL extra run time to start planning
and thinking about their cycle. There would be less transition time
between PTLs and the incoming PTL can start making the decisions like
Summit planning that will impact them.

It's at least a simpler transition from where we are to where we want to
be.

> 
> -- 
> Sean Dague
> http://dague.net
> 
> __
> 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

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

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2016-09-07 18:24:46 +0200:
> 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".
> 

Right, I would expect them to be interact with the release team in
a lot of similar ways.

Doug

__
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

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

[Matt Riedemann]

On 9/7/2016 11:33 AM, Jim Rollenhagen wrote:


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



I don't really see how managing the release-specific bits of the project 
as a 'release steward' is different from a release cross-project 
liaison. Nova has a release CPL (really more than one probably informally).


I do think it's a bit weird that I've already slotted the Ocata design 
summit rooms for Nova when someone else could be PTL, but I don't think 
what I'd reserve would be drastically different from someone else in 
Nova, this is why we have trust relationships and talk about stuff as a 
team.  There was a lot of overlap from Michael to John and from John to 
myself and we've shared responsibilities during those transitions.


The release steward concept just seems like unnecessarily complexity and 
formality to me, but that's just my opinion. Things might work 
differently in other projects.


--

Thanks,

Matt Riedemann


__
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

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

[Anita Kuno]

On 16-09-07 02:19 PM, Ian Cordasco wrote:
  


-Original Message-
From: Anita Kuno <ante...@anteaya.info>
Reply: Anita Kuno <ante...@anteaya.info>
Date: September 7, 2016 at 13:08:44
To: Ian Cordasco <sigmaviru...@gmail.com>, OpenStack Development Mailing List (not 
for usage questions) <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"


On 16-09-07 01:59 PM, Ian Cordasco wrote:


-Original Message-
From: Anita Kuno
Reply: OpenStack Development Mailing List (not for usage questions)
Date: September 7, 2016 at 12:03:25
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"


On 16-09-07 12:43 PM, Davanum Srinivas wrote:

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.

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.

Also since "Release Stewards" are nominated by PTL, projects can just
start using this concept right away (as it's not an elected position).
+1 from me.


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).

Welcomed and required are two different things. I think the stable team
is always willing to work with new contributors. I additionally think
that floating the expectation that someone able to take on the release
steward position also is required to entertain the stable team
responsibilities might shy away good candidates for the release steward
position. I think working with the single concept of release steward
first is a good place to begin. Give it space to grow both as a concept
within OpenStack and within individual projects.

I absolutely agree that this could scare off potentially good candidates. I 
also did

a very poor job explaining why I think this is related, I'm sorry.

In my mind, if I were a Release Steward for a project. I would think I'd not 
only be in charge

of helping the initial release but also managing "post-release bugfix-backport 
phase".
That to me is what a PTL does with the Stable Team, so at least I would need to 
coordinate
with the Stable Team. It at least seems implied. Now whether the person be an 
existing
member of the Stable Team, doesn't seem important. But if the person is Release 
Steward,
I'd expect them to be able to help approve changes to the branch/release 
they're stewarding.
That, implies to me, that they'll need to work within the Stable Team. Given 
that train
of thought, it makes sense to me that a Release Steward who is not already a 
Stable Team
member would have to become one to continue their stewardship and would be 
trusted to
(maybe only at first) approve changes for their release and not for all stable 
branches.

Does that help to explain my reasoning for bringing that up?
  
Yes it does, thanks for taking the time to expand. What you say makes

perfect sense from the perspective of the contributors.
  
I'm taking a look at the perspective of a manager, who may or may not

know what our actual workflow is and how we operate. There are a number
of folks who unfortunately have to quantify their time working on
OpenStack in terms of percentage of a week or month. For anyone in that
position, and to the managers who care enough to read this list (thank
you by the way) I want to help those in this position to be able to get
permission to do the work if that is their wish. If we keep the time
required to a percentage their manager will approve then we open the
door wider. Hence my recognition of the difference between welcomed and
required. If we keep the required bit to the smallest workable piece
more managers will allow their charges to do the work or at the very
least, not block them.

I absolutely agree. =) (I'm also one of those people who has to track and 
justify % of time on OpenStack so I appreciate your consideration of us, 
sincerely.)


Thanks Ian, I'm glad we are in agreement. I know you had to cut ba

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

[Matt Riedemann]

On 9/7/2016 11:35 AM, Ian Cordasco wrote:



-Original Message-
From: Monty Taylor <mord...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Membership in the stable team doesn't really have anyth

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

[Ian Cordasco]

 

-Original Message-
From: Anita Kuno <ante...@anteaya.info>
Reply: Anita Kuno <ante...@anteaya.info>
Date: September 7, 2016 at 13:08:44
To: Ian Cordasco <sigmaviru...@gmail.com>, OpenStack Development Mailing List 
(not for usage questions) <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"

> On 16-09-07 01:59 PM, Ian Cordasco wrote:
> >
> >
> > -Original Message-
> > From: Anita Kuno  
> > Reply: OpenStack Development Mailing List (not for usage questions)  
> > Date: September 7, 2016 at 12:03:25
> > To: openstack-dev@lists.openstack.org  
> > Subject: Re: [openstack-dev] [all] Timeframe for future elections & 
> > "Release stewards"  
> >
> >> On 16-09-07 12:43 PM, Davanum Srinivas wrote:
> >>>>>> 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.
> >>>>> 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.  
> >>> Also since "Release Stewards" are nominated by PTL, projects can just
> >>> start using this concept right away (as it's not an elected position).
> >>> +1 from me.
> >>>
> >>>> 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).
> >>
> >> Welcomed and required are two different things. I think the stable team
> >> is always willing to work with new contributors. I additionally think
> >> that floating the expectation that someone able to take on the release
> >> steward position also is required to entertain the stable team
> >> responsibilities might shy away good candidates for the release steward
> >> position. I think working with the single concept of release steward
> >> first is a good place to begin. Give it space to grow both as a concept
> >> within OpenStack and within individual projects.
> > I absolutely agree that this could scare off potentially good candidates. I 
> > also did  
> a very poor job explaining why I think this is related, I'm sorry.
> >
> > In my mind, if I were a Release Steward for a project. I would think I'd 
> > not only be in charge  
> of helping the initial release but also managing "post-release 
> bugfix-backport phase".  
> That to me is what a PTL does with the Stable Team, so at least I would need 
> to coordinate  
> with the Stable Team. It at least seems implied. Now whether the person be an 
> existing  
> member of the Stable Team, doesn't seem important. But if the person is 
> Release Steward,  
> I'd expect them to be able to help approve changes to the branch/release 
> they're stewarding.  
> That, implies to me, that they'll need to work within the Stable Team. Given 
> that train  
> of thought, it makes sense to me that a Release Steward who is not already a 
> Stable Team  
> member would have to become one to continue their stewardship and would be 
> trusted to  
> (maybe only at first) approve changes for their release and not for all 
> stable branches.  
> >
> > Does that help to explain my reasoning for bringing that up?
>  
> Yes it does, thanks for taking the time to expand. What you say makes
> perfect sense from the perspective of the contributors.
>  
> I

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

[Anita Kuno]

On 16-09-07 01:59 PM, Ian Cordasco wrote:
  


-Original Message-
From: Anita Kuno <ante...@anteaya.info>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: September 7, 2016 at 12:03:25
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"


On 16-09-07 12:43 PM, Davanum Srinivas wrote:

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.

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.

Also since "Release Stewards" are nominated by PTL, projects can just
start using this concept right away (as it's not an elected position).
+1 from me.


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).
  
Welcomed and required are two different things. I think the stable team

is always willing to work with new contributors. I additionally think
that floating the expectation that someone able to take on the release
steward position also is required to entertain the stable team
responsibilities might shy away good candidates for the release steward
position. I think working with the single concept of release steward
first is a good place to begin. Give it space to grow both as a concept
within OpenStack and within individual projects.

I absolutely agree that this could scare off potentially good candidates. I 
also did a very poor job explaining why I think this is related, I'm sorry.

In my mind, if I were a Release Steward for a project. I would think I'd not only be in 
charge of helping the initial release but also managing "post-release 
bugfix-backport phase". That to me is what a PTL does with the Stable Team, so at 
least I would need to coordinate with the Stable Team. It at least seems implied. Now 
whether the person be an existing member of the Stable Team, doesn't seem important. But 
if the person is Release Steward, I'd expect them to be able to help approve changes to 
the branch/release they're stewarding. That, implies to me, that they'll need to work 
within the Stable Team. Given that train of thought, it makes sense to me that a Release 
Steward who is not already a Stable Team member would have to become one to continue 
their stewardship and would be trusted to (maybe only at first) approve changes for their 
release and not for all stable branches.

Does that help to explain my reasoning for bringing that up?


Yes it does, thanks for taking the time to expand. What you say makes 
perfect sense from the perspective of the contributors.


I'm taking a look at the perspective of a manager, who may or may not 
know what our actual workflow is and how we operate. There are a number 
of folks who unfortunately have to quantify their time working on 
OpenStack in terms of percentage of a week or month. For anyone in that 
position, and to the managers who care enough to read this list (thank 
you by the way) I want to help those in this position to be able to get 
permission to do the work if that is their wish. If we keep the time 
required to a percentage their manager will approve then we open the 
door wider. Hence my recognition of the difference between welcomed and 
required. If we keep the required bit to the smallest workable piece 
more managers will allow their charges to do the work or at the very 
least, not block them.


Thanks,
Anita.



I don't want to scare folks off at all, but I think we should maybe chat a bit 
about this.
--
Ian Cordasco




__
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

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

[Ian Cordasco]

 

-Original Message-
From: Anita Kuno <ante...@anteaya.info>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: September 7, 2016 at 12:03:25
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] Timeframe for future elections & "Release 
stewards"

> On 16-09-07 12:43 PM, Davanum Srinivas wrote:
> >>>> 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.
> >>> 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.  
> > Also since "Release Stewards" are nominated by PTL, projects can just
> > start using this concept right away (as it's not an elected position).
> > +1 from me.
> >
> >> 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).
>  
> Welcomed and required are two different things. I think the stable team
> is always willing to work with new contributors. I additionally think
> that floating the expectation that someone able to take on the release
> steward position also is required to entertain the stable team
> responsibilities might shy away good candidates for the release steward
> position. I think working with the single concept of release steward
> first is a good place to begin. Give it space to grow both as a concept
> within OpenStack and within individual projects.

I absolutely agree that this could scare off potentially good candidates. I 
also did a very poor job explaining why I think this is related, I'm sorry. 

In my mind, if I were a Release Steward for a project. I would think I'd not 
only be in charge of helping the initial release but also managing 
"post-release bugfix-backport phase". That to me is what a PTL does with the 
Stable Team, so at least I would need to coordinate with the Stable Team. It at 
least seems implied. Now whether the person be an existing member of the Stable 
Team, doesn't seem important. But if the person is Release Steward, I'd expect 
them to be able to help approve changes to the branch/release they're 
stewarding. That, implies to me, that they'll need to work within the Stable 
Team. Given that train of thought, it makes sense to me that a Release Steward 
who is not already a Stable Team member would have to become one to continue 
their stewardship and would be trusted to (maybe only at first) approve changes 
for their release and not for all stable branches.

Does that help to explain my reasoning for bringing that up?

I don't want to scare folks off at all, but I think we should maybe chat a bit 
about this.
--  
Ian Cordasco


__
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

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

[Jeremy Stanley]

On 2016-09-07 16:20:49 + (+), Barrett, Carol L wrote:
[...]
> Why not have a PTL own the release from start to finish, with the
> PTL for the next release getting elected as above.
[...]

An overwhelming majority (87%) of our official project teams'
deliverables do not follow a synchronous release cadence, and that
suggestion would unnecessarily tie their governance even more
strongly to the schedules of the minority who do.
-- 
Jeremy Stanley

__
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

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

[Amrith Kumar]

Thierry, thanks for writing this up. I think this is a great idea, and 
something that will help focus the release stewards on a specific release while 
the PTL can coordinate activities for all aspects of the project. Where 
appropriate, and where a project decides to take this route, it allows PTL's to 
distribute some of the load amongst others in the project team.

One other important benefit of this approach is, I believe, that we can expand 
the leadership pool within OpenStack by distributing the leadership activities 
to the release stewards. One of the conversations at the OpenStack SWG [1] and 
[2] has been to expand this leadership pool and I believe that this proposal 
for release stewards is a good step in that direction.

Thanks,

-amrith

[1] https://review.openstack.org/#/c/337895/
[2] https://wiki.openstack.org/wiki/Meetings/SWGMeeting

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: Wednesday, September 07, 2016 11:44 AM
> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [all] Timeframe for future elections & "Release
> stewards"
> 
> 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 con

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

[Sean Dague]

On 09/07/2016 12:27 PM, Thierry Carrez wrote:
> Barrett, Carol L wrote:
>> From: Sean Dague [mailto:s...@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.

It doesn't give you 2 PTLs. It gives you PTL-next that gets to make
decisions on master once it opens up, and guides it until it's a stable
branch. It doesn't seem like it breaks anything to me.

-Sean

-- 
Sean Dague
http://dague.net

__
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

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

[Dean Troyer]

On Wed, Sep 7, 2016 at 11:35 AM, Ian Cordasco 
wrote:

> 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).
>

That relationship is in the job description, but making it a bit more
formal could be beneficial to some teams, as well as spread the stable team
load a bit (I have no ideal what their workload is line now).

I could also see the release steward role extending, informally, until that
release's EOL.  Maybe that should also be addressed, be it affirmative or
negative...

dt

-- 

Dean Troyer
dtro...@gmail.com
__
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

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

[Monty Taylor]

On 09/07/2016 11:43 AM, Davanum Srinivas wrote:
> On Wed, Sep 7, 2016 at 12:35 PM, Ian Cordasco <sigmaviru...@gmail.com> wrote:
>>
>>
>> -Original Message-
>> From: Monty Taylor <mord...@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 

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

[Anita Kuno]

On 16-09-07 12:43 PM, Davanum Srinivas wrote:

On Wed, Sep 7, 2016 at 12:35 PM, Ian Cordasco <sigmaviru...@gmail.com> wrote:


-Original Message-
From: Monty Taylor <mord...@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.

Also since "Release Stewards" are nominated by PTL, projects can just
start using this concept right away (as it's not an elected position).
+1 from me.


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).


Welcomed and required are two different things. I think the stable team 
is always willing to work with new 

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

[Davanum Srinivas]

On Wed, Sep 7, 2016 at 12:35 PM, Ian Cordasco <sigmaviru...@gmail.com> wrote:
>
>
> -Original Message-
> From: Monty Taylor <mord...@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
>

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

[Ian Cordasco]

 

-Original Message-
From: Monty Taylor <mord...@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 qu

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

[Jim Rollenhagen]

On Wed, Sep 7, 2016 at 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
>
> --
> 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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Anita Kuno]

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


-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 
pip

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

[Thierry Carrez]

Barrett, Carol L wrote:
> From: Sean Dague [mailto:s...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Thierry Carrez]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Barrett, Carol L]

-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 
> trans

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

[Sean Dague]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Davanum Srinivas]

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  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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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

[Monty Taylor]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Doug Hellmann]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Thierry Carrez]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev