On 08/09/16 16:48 -0600, Doug Wiegley wrote:
On Sep 8, 2016, at 12:49 PM, Matt Riedemann <mrie...@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?)
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
