Open Stack

> On Sep 8, 2016, at 12:49 PM, Matt Riedemann <mriedem at linux.vnet.ibm.com> wrote:
> 
> 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.

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