Open Stack

On 9/8/16 7: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 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