<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 22, 2014 at 10:51 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 08/22/2014 08:33 AM, Thierry Carrez wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi everyone,<br>
<br>
We all know being a project PTL is an extremely busy job. That's because<br>
in our structure the PTL is responsible for almost everything in a project:<br>
<br>
- Release management contact<br>
- Work prioritization<br>
- Keeping bugs under control<br>
- Communicate about work being planned or done<br>
- Make sure the gate is not broken<br>
- Team logistics (run meetings, organize sprints)<br>
- ...<br>
<br>
They end up being completely drowned in those day-to-day operational<br>
duties, miss the big picture, can't help in development that much<br>
anymore, get burnt out. Since you're either "the PTL" or "not the PTL",<br>
you're very alone and succession planning is not working that great either.<br>
<br>
There have been a number of experiments to solve that problem. John<br>
Garbutt has done an incredible job at helping successive Nova PTLs<br>
handling the release management aspect. Tracy Jones took over Nova bug<br>
management. Doug Hellmann successfully introduced the concept of Oslo<br>
liaisons to get clear point of contacts for Oslo library adoption in<br>
projects. It may be time to generalize that solution.<br>
<br>
The issue is one of responsibility: the PTL is ultimately responsible<br>
for everything in a project. If we can more formally delegate that<br>
responsibility, we can avoid getting up to the PTL for everything, we<br>
can rely on a team of people rather than just one person.<br>
<br>
Enter the Czar system: each project should have a number of liaisons /<br>
official contacts / delegates that are fully responsible to cover one<br>
aspect of the project. We need to have Bugs czars, which are responsible<br>
for getting bugs under control. We need to have Oslo czars, which serve<br>
as liaisons for the Oslo program but also as active project-local oslo<br>
advocates. We need Security czars, which the VMT can go to to progress<br>
quickly on plugging vulnerabilities. We need release management czars,<br>
to handle the communication and process with that painful OpenStack<br>
release manager. We need Gate czars to serve as first-line-of-contact<br>
getting gate issues fixed... You get the idea.<br>
<br>
Some people can be czars of multiple areas. PTLs can retain some czar<br>
activity if they wish. Czars can collaborate with their equivalents in<br>
other projects to share best practices. We just need a clear list of<br>
areas/duties and make sure each project has a name assigned to each.<br>
<br>
Now, why czars ? Why not rely on informal activity ? Well, for that<br>
system to work we'll need a lot of people to step up and sign up for<br>
more responsibility. Making them "czars" makes sure that effort is<br>
recognized and gives them something back. Also if we don't formally<br>
designate people, we can't really delegate and the PTL will still be<br>
directly held responsible. The Release management czar should be able to<br>
sign off release SHAs without asking the PTL. The czars and the PTL<br>
should collectively be the new "project drivers".<br>
<br>
At that point, why not also get rid of the PTL ? And replace him with a<br>
team of czars ? If the czar system is successful, the PTL should be<br>
freed from the day-to-day operational duties and will be able to focus<br>
on the project health again. We still need someone to keep an eye on the<br>
project-wide picture and coordinate the work of the czars. We need<br>
someone to pick czars, in the event multiple candidates sign up. We also<br>
still need someone to have the final say in case of deadlocked issues.<br>
<br>
People say we don't have that many deadlocks in OpenStack for which the<br>
PTL ultimate power is needed, so we could get rid of them. I'd argue<br>
that the main reason we don't have that many deadlocks in OpenStack is<br>
precisely *because* we have a system to break them if they arise. That<br>
encourages everyone to find a lazy consensus. That part of the PTL job<br>
works. Let's fix the part that doesn't work (scaling/burnout).<br>
</blockquote>
<br></div></div>
I think the czars approach is sensible and seems to have worked pretty well in a couple projects so far.<br>
<br>
And, since I work for a software company with Russian origin, I support the term "czar" as well ;)<br>
<br>
On the topic of whether a PTL is still needed once a czar system is put in place, I think that should be left up to each individual project to decide.<br>
<br>
Best,<br>
-jay<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><div class="gmail_default" style="font-family:courier new,monospace">​<br></div><div class="gmail_default" style="font-family:courier new,monospace">+1 to czars<br></div><div class="gmail_default" style="font-family:courier new,monospace">

+1 to considering the future and role of TC versus future of PTL<br></div><div class="gmail_default" style="font-family:courier new,monospace">​</div><br></div></div>