Open Stack

On 9/8/2016 6:42 AM, Sean Dague wrote:
> 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
>

+1 to everything sdague said here.

-- 

Thanks,

Matt Riedemann