Excerpts from John Griffith's message of 2016-09-08 14:13:14 -0600: > On Thu, 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. > > > > -- > > > > Thanks, > > > > Matt Riedemann > > > > > > > > __________________________________________________________________________ > > 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 > > > I think Sean Dague made some really good points and I'd tend to lean that > way. Honestly charters, bylaws, governance etc shift or are rewritten > fairly often. Why not just change when we do elections to correspond with > releases and keep the continuity that we have now. Is there a problem > with the existing terms and cycles that maybe I'm missing? > > If there's a real hang up on the wording of it being related to the summit, > then fine... word it such that the election is "summit-date - N months = > election-date". I think there is value in continuity of a single PTL for a > release cycle personally.
Someone needs to write up those changes soon. Self-nominations for PTL elections are next week and the voting is the week after. Doug __________________________________________________________________________ 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
