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.

Also: Being a PTL is a full-time job.

>From working with current and former PTL's, I've noticed that it's almost
impossible to split your time between being a PTL 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.

Not many people have the privilege of working for a company that supports
that level of upstream commitment. If your employer doesn't, send me your
Resumé ;).


On Wed, Sep 9, 2015 at 8:15 AM Flavio Percoco <> wrote:

> Greetings,
> Next week many folks will be running for PTL positions and I thought
> about taking the time to dump[0] some thoughts about what being a PTL
> means - at least for me - and what one should consider before running.
> Since the audience I want to reach is mostly in this mailing list, I
> thought about sending it here as well.
> [0]
> Flavio
> It's that time of the cycle, in OpenStack, when projects need to elect
> who's going to be the PTL for the next 6 months. People look at the,
> hopefully many, candidacies and vote based on the proposals that are
> more sound to them. I believe, for the PTL elections, the voting
> process has worked decently, which is why this post is not meant for
> voters but for the, hopefully many, PTL candidates.
> First and foremost, thank you. Thanks for raising your hand and
> willing to take on this role. It's an honor to have you in the
> community and I wish you the best of lucks in this round. Below are a
> few things that I hope will help you in the preparation of your
> candidacy and that I also hope will help making you a better PTL and
> community member.
> Why do you want to be a PTL?
> ============================
> Before even start writing your candidacy, please, ask yourself why you
> want to be a PTL. What is it that you want to bring to the project
> that is good for both, the project and the community. You don't really
> need to get stuck on this question forever, you don't really need to
> bring something new to the project.
> In my opinion, a very good answer for the above could be: "I believe
> I'll provide the right guidance to the community and the project."
> Seriously, one mistake that new PTLs often do is to believe they are
> on their own. Turns out that PTLs arent. The whole point about being a
> PTL is to help the community and to improve it. You're not going to do
> that if you think you're the one pulling the community. PTLs ought to
> work *with* the community not *for* the community.
> This leads me to my next point
> Be part of the community
> ========================
> Being a PTL is more than just going through launchpad and keeping an
> eye on the milestones. That's a lot of work, true. But here's a
> secret, it takes more time to be involved with the community of the
> project you're serving than going through launchpad.
> As a PTL, you have to be around. You have to keep an eye on the
> mailing list in a daily basis. You have to talk to the members of the
> community you're serving because you have to be up-to-date about the
> things that are happening in the project and the community. There may
> be conflicts in reviews, bugs and you have to be there to help solving
> those.
> Among all the things you'll have to do, the community should be in the
> top 2 of your priorities. I'm not talking just about the community of
> the project you're working on. I'm talking about OpenStack. Does your
> project have an impact on other projects? Is your project part of
> DefCore? Is your project widely deployed? What are the deprecation
> guarantees provided? Does your project consume common libraries? What
> can your project contribute back to the rest of the community?
> There are *many* things related to the project's community and its
> interaction with the rest of the OpenStack community that are
> important and that should be taken care of. However, you're not alone,
> you have a community. Remember, you'll be serving the community, it's
> not the other way around. Working with the community is the best thing
> you can do.
> As you can imagine, the above is exhausting and it takes time. It
> takes a lot of time, which leads me to my next point.
> Make sure you'll have time
> ==========================
> There are a few things impossible in this world, predicting time
> availability is one of them. Nonetheless, we can get really close
> estimates and you should strive, *before* sending your candidacy, to
> get the closest estimate of your upstream availability for the next 6
> months.
> Being a PTL is an upstream job, it's nothing - at the very least it
> shouldn't have - to do with your actual employer. Being a PTL is an
> *upstream* job and you have to be *upstream* to do it correctly.
> If you think you won't have time in a couple of months then, please,
> don't run for PTL. If you think your manager will be asking you to
> focus downstream then, please, don't run for PTL. If you think you'll
> have other personal matters to take care of then, please, don't run
> for PTL.
> What I'm trying to say is that you should sit down and think of what
> your next 6 months will look like time-wise. I believe it's safe
> enough to say that you'll have to spend 60% to 70% of your time
> upstream, assuming the porject is a busy one.
> The above, though, is not to say that you shouldn't run when in doubt.
> Actually, I'd rather have a great PTL for 3 months that'll then step
> down than having the community being led by someone not motivated
> enough that was forced to run.
> Create new PTLs
> ===============
> Just like in every other leading possition, you should help creating
> other PTLs. Understand that winning the PTL election puts you in a
> position where you have to strive to improve the project and the
> community. As part of your responsibilities with regards to the
> community, you should encourage folks to run for PTL.
> Being a PTL takes a lot of time and energy and you'll have to step
> down[0], eventually. As a PTL, you may want to have folks from the
> community ready to take over when you'll step down. I believe it's
> healthy for the community to change PTLs every 2 cycles (if not every
> cycle).
> Community decides
> =================
> One of the things I always say to PTLs is that they are not dictators.
> Decisions are still supposed to be taken by the community at large and
> not by the PTL. However, being in a leading position gives you some
> extra "trust" that the community may end up following.
> Remember that as a PTL, you'll be serving the community and not the
> other way around. You should lead based on what is best for the
> project and the community rather than based on what's best for your
> company or, even worse, based on what will make your manager happy. If
> those two things happen to overlap, then AWESOME! Many times they
> don't, therefore you should be ready to take a pragmatic decision that
> may not be the best for the company you work for and that, certainly,
> won't make your manager happy.
> Are you ready to make that call?
> Closing
> =======
> By all means, this post is not meant to discourage you. If anything,
> It's meant to encourage you to jump in and be amazing. It's been an
> honor for me to have served as a PTL and I'm sure it'll be for you as
> well.
> Despite it not being an exhaustive list and the role experiences
> varying from one project to another, I hope the above will provide
> enough information about what PTLs are meant to do so that your
> excitement and desire to serve as one will grow.
> Thanks for considering being a PTL, I look forward to read your
> candidacy.
> [0]: Note to existing PTLs, consider stepping down and helping others
> become PTLs. It's healthier for the community you're serving to change
> PTLs
> --
> @flaper87
> Flavio Percoco
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
OpenStack Development Mailing List (not for usage questions)

Reply via email to