<div dir="ltr">Beautiful summary, Flavio, especially the points about creating new PTL's. It's the bus-number argument: How many people have to get hit by a bus for the project to falter? It's best to have a backup.<div><br></div><div>Also: <span style="line-height:1.5;font-size:13.2px">Being a PTL is a full-time job.</span></div><div><span style="line-height:1.5;font-size:13.2px"><br></span></div><div>From working with current and former PTL's, I've noticed that it's almost impossible to split your time between being a PTL <span style="line-height:1.5;font-size:13.2px">and, say, being a member of the TC, or working on an employer's private feature/cloud/deployment/etc. For a far more eloquent explanation of why this is, I defer to Devananda's wonderful non-candidacy email last spring.</span></div><div><span style="line-height:1.5;font-size:13.2px"><br></span></div><div><span style="line-height:1.5;font-size:13.2px"><a href="http://lists.openstack.org/pipermail/openstack-dev/2015-April/062364.html">http://lists.openstack.org/pipermail/openstack-dev/2015-April/062364.html</a></span></div><div><br></div><div>Not many people have the privilege of working for a company that supports that level of upstream commitment. <span style="font-size:13.2px;line-height:19.8px">If your employer doesn't, send me your Resumé ;).</span></div><div><br></div><div>Michael</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 9, 2015 at 8:15 AM Flavio Percoco <<a href="mailto:flavio@redhat.com">flavio@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Greetings,<br>
<br>
Next week many folks will be running for PTL positions and I thought<br>
about taking the time to dump[0] some thoughts about what being a PTL<br>
means - at least for me - and what one should consider before running.<br>
<br>
Since the audience I want to reach is mostly in this mailing list, I<br>
thought about sending it here as well.<br>
<br>
[0] <a href="http://blog.flaper87.com/post/something-about-being-a-ptl/" rel="noreferrer" target="_blank">http://blog.flaper87.com/post/something-about-being-a-ptl/</a><br>
Flavio<br>
<br>
<br>
It's that time of the cycle, in OpenStack, when projects need to elect<br>
who's going to be the PTL for the next 6 months. People look at the,<br>
hopefully many, candidacies and vote based on the proposals that are<br>
more sound to them. I believe, for the PTL elections, the voting<br>
process has worked decently, which is why this post is not meant for<br>
voters but for the, hopefully many, PTL candidates.<br>
<br>
First and foremost, thank you. Thanks for raising your hand and<br>
willing to take on this role. It's an honor to have you in the<br>
community and I wish you the best of lucks in this round. Below are a<br>
few things that I hope will help you in the preparation of your<br>
candidacy and that I also hope will help making you a better PTL and<br>
community member.<br>
<br>
<br>
Why do you want to be a PTL?<br>
============================<br>
<br>
Before even start writing your candidacy, please, ask yourself why you<br>
want to be a PTL. What is it that you want to bring to the project<br>
that is good for both, the project and the community. You don't really<br>
need to get stuck on this question forever, you don't really need to<br>
bring something new to the project.<br>
<br>
In my opinion, a very good answer for the above could be: "I believe<br>
I'll provide the right guidance to the community and the project."<br>
<br>
Seriously, one mistake that new PTLs often do is to believe they are<br>
on their own. Turns out that PTLs arent. The whole point about being a<br>
PTL is to help the community and to improve it. You're not going to do<br>
that if you think you're the one pulling the community. PTLs ought to<br>
work *with* the community not *for* the community.<br>
<br>
This leads me to my next point<br>
<br>
Be part of the community<br>
========================<br>
<br>
Being a PTL is more than just going through launchpad and keeping an<br>
eye on the milestones. That's a lot of work, true. But here's a<br>
secret, it takes more time to be involved with the community of the<br>
project you're serving than going through launchpad.<br>
<br>
As a PTL, you have to be around. You have to keep an eye on the<br>
mailing list in a daily basis. You have to talk to the members of the<br>
community you're serving because you have to be up-to-date about the<br>
things that are happening in the project and the community. There may<br>
be conflicts in reviews, bugs and you have to be there to help solving<br>
those.<br>
<br>
Among all the things you'll have to do, the community should be in the<br>
top 2 of your priorities. I'm not talking just about the community of<br>
the project you're working on. I'm talking about OpenStack. Does your<br>
project have an impact on other projects? Is your project part of<br>
DefCore? Is your project widely deployed? What are the deprecation<br>
guarantees provided? Does your project consume common libraries? What<br>
can your project contribute back to the rest of the community?<br>
<br>
There are *many* things related to the project's community and its<br>
interaction with the rest of the OpenStack community that are<br>
important and that should be taken care of. However, you're not alone,<br>
you have a community. Remember, you'll be serving the community, it's<br>
not the other way around. Working with the community is the best thing<br>
you can do.<br>
<br>
As you can imagine, the above is exhausting and it takes time. It<br>
takes a lot of time, which leads me to my next point.<br>
<br>
Make sure you'll have time<br>
==========================<br>
<br>
There are a few things impossible in this world, predicting time<br>
availability is one of them. Nonetheless, we can get really close<br>
estimates and you should strive, *before* sending your candidacy, to<br>
get the closest estimate of your upstream availability for the next 6<br>
months.<br>
<br>
Being a PTL is an upstream job, it's nothing - at the very least it<br>
shouldn't have - to do with your actual employer. Being a PTL is an<br>
*upstream* job and you have to be *upstream* to do it correctly.<br>
<br>
If you think you won't have time in a couple of months then, please,<br>
don't run for PTL. If you think your manager will be asking you to<br>
focus downstream then, please, don't run for PTL. If you think you'll<br>
have other personal matters to take care of then, please, don't run<br>
for PTL.<br>
<br>
What I'm trying to say is that you should sit down and think of what<br>
your next 6 months will look like time-wise. I believe it's safe<br>
enough to say that you'll have to spend 60% to 70% of your time<br>
upstream, assuming the porject is a busy one.<br>
<br>
The above, though, is not to say that you shouldn't run when in doubt.<br>
Actually, I'd rather have a great PTL for 3 months that'll then step<br>
down than having the community being led by someone not motivated<br>
enough that was forced to run.<br>
<br>
Create new PTLs<br>
===============<br>
<br>
Just like in every other leading possition, you should help creating<br>
other PTLs. Understand that winning the PTL election puts you in a<br>
position where you have to strive to improve the project and the<br>
community. As part of your responsibilities with regards to the<br>
community, you should encourage folks to run for PTL.<br>
<br>
Being a PTL takes a lot of time and energy and you'll have to step<br>
down[0], eventually. As a PTL, you may want to have folks from the<br>
community ready to take over when you'll step down. I believe it's<br>
healthy for the community to change PTLs every 2 cycles (if not every<br>
cycle).<br>
<br>
Community decides<br>
=================<br>
<br>
One of the things I always say to PTLs is that they are not dictators.<br>
Decisions are still supposed to be taken by the community at large and<br>
not by the PTL. However, being in a leading position gives you some<br>
extra "trust" that the community may end up following.<br>
<br>
Remember that as a PTL, you'll be serving the community and not the<br>
other way around. You should lead based on what is best for the<br>
project and the community rather than based on what's best for your<br>
company or, even worse, based on what will make your manager happy. If<br>
those two things happen to overlap, then AWESOME! Many times they<br>
don't, therefore you should be ready to take a pragmatic decision that<br>
may not be the best for the company you work for and that, certainly,<br>
won't make your manager happy.<br>
<br>
Are you ready to make that call?<br>
<br>
Closing<br>
=======<br>
<br>
By all means, this post is not meant to discourage you. If anything,<br>
It's meant to encourage you to jump in and be amazing. It's been an<br>
honor for me to have served as a PTL and I'm sure it'll be for you as<br>
well.<br>
<br>
Despite it not being an exhaustive list and the role experiences<br>
varying from one project to another, I hope the above will provide<br>
enough information about what PTLs are meant to do so that your<br>
excitement and desire to serve as one will grow.<br>
<br>
Thanks for considering being a PTL, I look forward to read your<br>
candidacy.<br>
<br>
[0]: Note to existing PTLs, consider stepping down and helping others<br>
become PTLs. It's healthier for the community you're serving to change<br>
PTLs<br>
<br>
--<br>
@flaper87<br>
Flavio Percoco<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>