On Tue, Aug 26, 2014 at 9:48 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> On Aug 26, 2014, at 10:10 AM, Kyle Mestery <mest...@mestery.com> wrote:
>> On Fri, Aug 22, 2014 at 8:19 PM, John Dickinson <m...@not.mn> wrote:
>>> I think Anne makes some excellent points about the pattern being proposed 
>>> being unlikely to be commonly implemented across all the programs (or, at 
>>> best, very difficult). Let's not try to formalize another "best practice" 
>>> that works many times and force it to work every time. Here's an alternate 
>>> proposal:
>>> Let's let PTLs be PTLs and effectively coordinate and manage the activity 
>>> in their respective projects. And let's get the PTLs together for one or 
>>> two days every cycle to discuss project issues. Just PTLs, and let's focus 
>>> on the project management stuff and some cross-project issues.
>>> Getting the PTLs together would allow them to discuss cross-project issues, 
>>> share frustrations and solutions about what does and doesn't work. 
>>> Basically, think of it as a mid-cycle meetup, but for PTLs. (Perhaps we 
>>> could even ask the Foundation to sponsor it.)
>> +100
>> I think John nails the key point here: PTLs are likely already doing a
>> lot of what Thierry originally proposed here. I know that I work with
>> many people in Neutron to help offload things like bug triaging, gate
>> failure analysis, etc. Without that, Neutron wouldn't scale. In effect
>> what's proposed here is something we're already doing a lot of. I
>> don't think forcing this on each project is a good way of doing this,
>> because each project has different challenges and needs.
> This proposal isn’t about how teams are organized internally; it’s about how 
> they interface with the other OpenStack teams.
> The cross-project teams need more direct coordination and participation than 
> we are getting from some projects, and so we want the projects and PTLs to 
> recognize that the areas Thierry has listed are responsibilities that need to 
> be met. Someone needs to do these basic coordination tasks in order for the 
> overall project to be successful. It’s up to each team to decide who fills a 
> given role, but by identifying these points of contact the other teams don’t 
> have to know that you make those decisions by asking for volunteers, holding 
> an election, or drawing straws.
I think it *is* about how teams are organized internally, to some
extent. These interactions with other teams somewhat dictate the
layout of the team internally. But either way, I agree with your
points Doug. Increasing visibility of the people in each of these
teams is a good thing.


> Doug
>> Thanks,
>> Kyle
>>> --John
>>> On Aug 22, 2014, at 6:02 PM, 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'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
>> _______________________________________________
>> 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

Reply via email to