Re: [openstack-dev] [all] Something about being a PTL
+1 Fantastically well said. I'd encourage all current and potential PTLs to take these words to heart. > 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 busier the project, the closer to 100% this becomes. For keystone, I would expect nothing less than 100%. It's truly a full time job. Also note that there is no mention of writing code! :( Your job is to serve the community, and writing code is simply not the most efficient way to accomplish that. And as Michael Krotscheck mentioned, if you believe you'd be a great PTL but your employer would not fully support the time commitment, then for both the health of OpenStack and your success, I'd encourage you to change employers (look for the employers who have a history of supporting multiple PTLs that aren't quickly burning out). On Wed, Sep 9, 2015 at 10:10 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] 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
Re: [openstack-dev] [all] Something about being a PTL
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. Thanks, Kyle On Wed, Sep 9, 2015 at 10:10 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] 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
Re: [openstack-dev] [all] Something about being a PTL
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. http://lists.openstack.org/pipermail/openstack-dev/2015-April/062364.html 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é ;). Michael 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] 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 ne
Re: [openstack-dev] [all] Something about being a PTL
Very well said. Thank you for this. Kevin From: Flavio Percoco [fla...@redhat.com] Sent: Wednesday, September 09, 2015 8:10 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [all] Something about being a PTL 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 be
[openstack-dev] [all] Something about being a PTL
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 othe
