On 08/09/16 04:46, Matt Riedemann wrote: > On 9/7/2016 11:33 AM, Jim Rollenhagen wrote: >> >> I like this. As someone that has been PTL for multiple cycles, it is >> incredibly stressful trying to finish the release, start planning for the >> next one, manage summit planning, etc. I'd love to have someone >> designated to manage the release-specific bits of the project, while >> PTLs can worry about the longer-term vision of the project and the >> day-to-day management. >> >> Thanks for writing this up, Thierry. :) >> >> // jim >> > > I don't really see how managing the release-specific bits of the project as a > 'release steward' is different from a release cross-project liaison. Nova has > a release CPL (really more than one probably informally). > > I do think it's a bit weird that I've already slotted the Ocata design summit > rooms for Nova when someone else could be PTL, but I don't think what I'd > reserve would be drastically different from someone else in Nova, this is why > we have trust relationships and talk about stuff as a team. There was a lot > of overlap from Michael to John and from John to myself and we've shared > responsibilities during those transitions. > > The release steward concept just seems like unnecessarily complexity and > formality to me, but that's just my opinion. Things might work differently in > other projects. >
Although I appreciate that my project is probably a bit different to many of the others (horizontal vs vertical, etc), I much prefer this method of overlapping the PTL changeover a little more instead of appointing form stewards. In docs, we've started assigning two release managers about a month before release time. They work with the PTL and other core team members to make sure the release happens smoothly, which allows the PTL the luxury of knowing there's eyes on all those small pieces that need to happen to get the release out while they get on with Summit prep. This means that having a formal release steward would just mean we appoint that person earlier in the cycle, so there's no real change for us in Thierry's proposal. We did this for a lot of reasons, at least some of which are about training people to understand the project on a deeper level (and thus create a leadership pipeline, of sorts). Having the PTL changeover time increase would have helped greatly during the time I was taking over as PTL from Anne. Like I said, docs is a little different, we have very little PTL-churn, which means that changeover process is a lot more complicated and involves a lot more information exchange than other projects that regularly change PTLs, I think. So I think this would be good for us, but accept that it might not work so well for other projects. Lana -- Lana Brindley Technical Writer Rackspace Cloud Builders Australia http://lanabrindley.com
signature.asc
Description: OpenPGP digital 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
