Open Stack

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 <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.
> >
> > --
> >
> > 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
> >
> ​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