On Sat, Aug 23, 2014 at 11:02 AM, Anne Gentle <a...@openstack.org> wrote:
> > > > On Fri, Aug 22, 2014 at 6:17 PM, Rochelle.RochelleGrober < > rochelle.gro...@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@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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
