Open Stack

On Sat, Aug 23, 2014 at 11:02 AM, Anne Gentle <anne at openstack.org> wrote:

>
>
>
> On Fri, Aug 22, 2014 at 6:17 PM, Rochelle.RochelleGrober <
> rochelle.grober at huawei.com> wrote:
>
>> /flame-on
>> Ok, this is funny to some of us in the community.  The general populace
>> of this community is so against the idea of management that they will use
>> the term for a despotic dictator as a position name rather than "manager".
>> Sorry, but this needed to be said.
>> /flame-off
>>
>> Specific comments in line:
>>
>> Thierry Carrez wrote:
>> >
>> > Hi everyone,
>> >
>> > We all know being a project PTL is an extremely busy job. That's
>> > because
>> > in our structure the PTL is responsible for almost everything in a
>> > project:
>> >
>> > - Release management contact
>> > - Work prioritization
>> > - Keeping bugs under control
>> > - Communicate about work being planned or done
>> > - Make sure the gate is not broken
>> > - Team logistics (run meetings, organize sprints)
>> > - ...
>> >
>>
>> Point of clarification:  I've heard PTL=Project Technical Lead and
>> PTL=Program Technical Lead. Which is it?  It is kind of important as
>> OpenStack grows, because the first is responsible for *a* project, and the
>> second is responsible for all projects within a program.
>>
>>
> Now Program, formerly Project.
>

I think this is worthy of more exploration. Our docs seem to be very
inconsistent about what a PTL is - and more broadly, what the difference is
between a Project and a Program.

Just a few examples:

https://wiki.openstack.org/wiki/PTLguide says "Program Technical Lead".
https://wiki.openstack.org/wiki/PTL_Elections_March/April_2014 simply says
PTL - but does say that each PTL is elected by/for a Program. However,
Thierry pointed to
https://wiki.openstack.org/wiki/Governance/Foundation/Structure which still
refers to Project Technical Leads and says explicitly that they lead
individual projects, not programs. I actually have edit access to that
page, so I could at least update that with a simple "s/Project/Program/",
if I was sure that was the right thing to do.

http://www.openstack.org/ has a link in the bottom nav that says
"Projects"; it points to http://www.openstack.org/projects/ which redirects
to http://www.openstack.org/software/ which has a list of things like
"Compute" and "Storage" - which as far as I know are Programs, not
Projects. I don't know how to update that link in the nav panel.

I wasn't around when the original Programs/Projects discussion was
happening - which, I suspect, has a lot to do with why I'm confused today -
it seems as though people who were around at the time understand the
difference, but people who have joined since then are relying on multiple
conflicting verbal definitions. I believe, though, that
http://lists.openstack.org/pipermail/openstack-dev/2013-June/010821.html
was one of the earliest starting points of the discussion. That page points
at https://wiki.openstack.org/wiki/Projects, which today contains a list of
Programs. That page does have a definition of what a Program is, but
doesn't explain what a Project is or how they relate to Programs. This page
seems to be locked down, so I can't edit it.

That page does mention projects, once. The context makes it read, to me, as
though a program can follow one process to "become part of OpenStack" and
then another process to "become an Integrated project and part of the
OpenStack coordinated release" - when my understanding of reality is that
the second process applies to Projects, not Programs.

I've tried to find any other page that talks about what a Project is and
how they relate to Programs, but I haven't been able to find anything.
Perhaps there's some definition locked up in a mailing list thread or some
TC minutes, but I haven't been able to find it.

During the previous megathread, I got the feeling that at least some of the
differing viewpoints we saw were possibly down to some people thinking of a
PTL as responsible for just one project, while others think of a PTL as
being responsible for any projects that might fit within a Program's scope.
As we approach the next PTL elections, I think it would be helpful for us
to recap the discussions that led to the Program/Project split and make
sure our docs are consistent, so that people who weren't following the
discussion this time last year can still be clear what they're voting for.



>
>> I'd also like to set out as an example of a Program that is growing to
>> encompass multiple projects, the Neutron Program.  Look at how it is
>> expanding:
>>
>> Multiple sub-teams for:  LBAAS, DNAAS, GBP, etc.  This model could be
>> extended such that:
>> - the subteam is responsible for code reviews, including the first +2 for
>> design, architecture and code of the sub-project, always also keeping an
>> eye out that the sub-project code continues to both integrate well with the
>> program, and that the program continues to provide the needed code bits,
>> architecture modifications and improvements, etc. to support the
>> sub-project.
>> - the final +2/A would be from the Program reviewers to ensure that all
>> integrate nicely together into a single, cohesive program.
>> - This would allow sub-projects to have core reviewers, along with the
>> program and be a good separation of duties.  It would also help to increase
>> the number of reviews moving to merged code.
>> - Taken to a logical stepping stone, you would have project technical
>> leads for each project, and they would make up a program council, with the
>> program technical lead being the chair of the council.
>>
>> This is a way to offload a good chunk of PTL tactical responsibilities
>> and help them focus more on the strategic.
>>
>> > They end up being completely drowned in those day-to-day operational
>> > duties, miss the big picture, can't help in development that much
>> > anymore, get burnt out. Since you're either "the PTL" or "not the PTL",
>> > you're very alone and succession planning is not working that great
>> > either.
>> >
>> > There have been a number of experiments to solve that problem. John
>> > Garbutt has done an incredible job at helping successive Nova PTLs
>> > handling the release management aspect. Tracy Jones took over Nova bug
>> > management. Doug Hellmann successfully introduced the concept of Oslo
>> > liaisons to get clear point of contacts for Oslo library adoption in
>> > projects. It may be time to generalize that solution.
>> >
>> > The issue is one of responsibility: the PTL is ultimately responsible
>> > for everything in a project. If we can more formally delegate that
>> > responsibility, we can avoid getting up to the PTL for everything, we
>> > can rely on a team of people rather than just one person.
>> >
>> > Enter the Czar system: each project should have a number of liaisons /
>> > official contacts / delegates that are fully responsible to cover one
>> > aspect of the project. We need to have Bugs czars, which are
>> > responsible
>> > for getting bugs under control. We need to have Oslo czars, which serve
>> > as liaisons for the Oslo program but also as active project-local oslo
>> > advocates. We need Security czars, which the VMT can go to to progress
>> > quickly on plugging vulnerabilities. We need release management czars,
>> > to handle the communication and process with that painful OpenStack
>> > release manager. We need Gate czars to serve as first-line-of-contact
>> > getting gate issues fixed... You get the idea.
>> >
>> /flame-on
>> Let's call spades, spades here.  Czar is not only overkill, but the wrong
>> metaphor.
>> /flame-off
>>
>
> I'm with Rocky on the anti-czar-as-a-word camp. We all like clever names
> to shed the "corporate" stigma but this word ain't it. Liaison or lead?
>
> Also wanted to point to https://wiki.openstack.org/wiki/PTLguide as it's
> quite nice.
>
> I think PTLs tend to find help when they absolutely are ready to fall
> over, and I'm all for a plan that helps us not fall over. I've had people
> step up for bug triaging, gate work, tests, and oslo, sometimes one person
> did three or four at once. I certainly can't do it all for cross-project.
> Based on what I've seen, I doubt that we can add this much formality to
> this across 20+ programs. It's the "bigger more integrated project" vs.
> "smaller more focused project" difference that won't let us do a pattern
> here. We can certainly document the responsibilities and let programs know
> there are some best practices.
>
> Anne
>
>
>>
>> Each position suggested here exists in corporate development projects:
>> - Bug czar == bug manager/administrator/QA engineer/whatever - someone in
>> charge of making sure bugs get triages, assigned and completed
>> - Oslo czar == systems engineers/project managers who make sure that the
>> project is in line with the rest of the projects that together make an
>> integrated release.  This position needs to stretch beyond just Oslo to
>> encompass all the cross-project requirements and will likely be its own
>> "committee"
>> - Gate Czar == integration engineer(manager)/QA
>> engineer(manager)/build-release engineer.  This position would also likely
>> be a liaison to Infra.
>> - Security Czar == security guru (that name takes me back ;-)
>> - Release management Czar == Project release manager
>> - Doc Czar == tech editor
>> - Tempest Czar == QA engineer(manager)
>>
>> Yes, programs are now mostly big enough to require coordination and
>> management.  The roles are long defined, so let's just document the
>> definitions and get volunteers.  Each project would be able to decide which
>> roles needed to be filled and whether individuals are capable of filling
>> multiple roles.
>>
>> These roles need to be transparent in a governance sense and should be
>> increasing communication between projects, community and contributors.
>>
>> > Some people can be czars of multiple areas. PTLs can retain some czar
>> > activity if they wish. Czars can collaborate with their equivalents in
>> > other projects to share best practices. We just need a clear list of
>> > areas/duties and make sure each project has a name assigned to each.
>> >
>> > Now, why czars ? Why not rely on informal activity ? Well, for that
>> > system to work we'll need a lot of people to step up and sign up for
>> > more responsibility. Making them "czars" makes sure that effort is
>> > recognized and gives them something back. Also if we don't formally
>> > designate people, we can't really delegate and the PTL will still be
>> > directly held responsible. The Release management czar should be able
>> > to
>> > sign off release SHAs without asking the PTL. The czars and the PTL
>> > should collectively be the new "project drivers".
>> >
>> > At that point, why not also get rid of the PTL ? And replace him with a
>> > team of czars ? If the czar system is successful, the PTL should be
>> > freed from the day-to-day operational duties and will be able to focus
>> > on the project health again. We still need someone to keep an eye on
>> > the
>> > project-wide picture and coordinate the work of the czars. We need
>> > someone to pick czars, in the event multiple candidates sign up. We
>> > also
>> > still need someone to have the final say in case of deadlocked issues.
>> >
>> > People say we don't have that many deadlocks in OpenStack for which the
>> > PTL ultimate power is needed, so we could get rid of them. I'd argue
>> > that the main reason we don't have that many deadlocks in OpenStack is
>> > precisely *because* we have a system to break them if they arise. That
>> > encourages everyone to find a lazy consensus. That part of the PTL job
>> > works. Let's fix the part that doesn't work (scaling/burnout).
>> >
>>
>> Perhaps, the crux of the issue with PTLs is that we still need PTLs, but
>> they should be *Project* Technical Leads and the role currently defined as
>> PTL should really become a Program Manager - someone who coordinates all
>> the projects, their issues, needs, communications and leave the deep
>> technical work to the project leads and individual developers.  Consider
>> the project technical leads seeing the trees and the program manager sees
>> the forest.  Let the program manager gather the technical requirements and
>> wishes for the next release and track those, let the team of project
>> technical leads determine the design, architecture, tools, etc.
>>
>> > --
>> > Thierry Carrez (ttx)
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> Great idea Thierry, just thought I'd propose a slight twist on your
>> concept.
>> And sorry for the flames, but I'm in Jay Pipe's camp when it comes to
>> needing to ensure inclusiveness, openness and transparency for the
>> community and I think even the name czars are a slippery slope to something
>> less open.
>>
>> --Rocky Grober
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140828/f2d38ae7/attachment-0001.html>