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

Sean Dague sean at dague.net
Thu Sep 8 11:42:31 UTC 2016


On 09/08/2016 05:00 AM, Thierry Carrez wrote:
> Sean Dague wrote:
<snip>
> 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



More information about the OpenStack-dev mailing list