Flavio, thanks for sending this out. I agree with everything you've written
below. Having served as PTL for 3 cycles now, I can say it's very
rewarding, but it's also very exhausting and takes an incredibly thick skin.

Before jumping in and throwing your hat into the ring (especially for a
large OpenStack project), please read Flavio's post carefully below. You
owe it to the project you're running for, the broader OpenStack ecosystem,
and yourself.


On Wed, Sep 9, 2015 at 10:10 AM, Flavio Percoco <fla...@redhat.com> 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] http://blog.flaper87.com/post/something-about-being-a-ptl/
> 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-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to