Being a PTL: The Good, the Bad, and the Ugly - - PowerPoint PPT Presentation
Being a PTL: The Good, the Bad, and the Ugly http://cinetropolis.net/wp-content/uploads/2013/10/the-good-the-bad-and-the-ugly-t-anderson-banner.jpg About the Presenters Matt Riedemann Software Developer, Huawei N-O-P Nova PTL Steve Martinelli
http://cinetropolis.net/wp-content/uploads/2013/10/the-good-the-bad-and-the-ugly-t-anderson-banner.jpg
Armando Migliaccio
Software Developer, SUSE M-N-O Neutron PTL @armandomi2001
Steve Martinelli
Software Developer, IBM M-N-O Keystone PTL @stevebot
Matt Riedemann
Software Developer, Huawei N-O-P Nova PTL
Slides available at: https://www.slideshare.net/SteveMartinelli1/building-iam-for-openstack
After Before
○ We’re also not historians or psychics
○ We’re moderators and liaisons
○ We’re hardly the best at anything
○ Ensure the gate isn’t broken, nominate cores,
bugs, run meetings, organize bug smashes, ensure stable isn’t broken, release libraries, monitor mailing list, draft release notes, etc...
○ project governance changes ○ interop working group ○ initiatives in other projects ○ release management ○ vulnerabilities ○ roadmaps, really!?
○ Email inbox explosion ○ Gate queue explosion ○ Bug backlog explosion
○ bug triage ○ test coverage ○ team meetings
rewarding experience
○ (Except Matt, he doesn’t do hugs)
○ You’ll learn a lot about yourself than you’ve ever wanted (examples to follow? what did you learn Steve?) ■ How to optimize everything, manage every minute of your day ■ What amount of work you can handle, and how you choose to handle extra work (longer hours or delegate) ■ How to be a leader (rally a team, delegate work, communicate effectively) ○ Chance to pass on what you’ve learned and create future leaders
○ See the project change and grow ○ Nominating new core members! ○ Watching core members grow and learn
○ You do a lot of the day to day dirty work and see how the sausage is made ○ Mentoring new contributors
○ Orchestrating dozens of new features ○ Fixing bugs and adding code that fills long standings gaps ○ Actually seeing big complicated cross-project efforts get worked out and implemented.
○ All the glory and fame! (not really) ○ Being the go-to person, if that’s your thing ○ Competing in an election, and win by a good margin (mriedem: I’d drop this / reword, i.e. not Trump) ○ Increased visibility in the industry ○ Rewarded by the praise of co-workers (if doing a good job!) ○ You’re like a rock-star: other developers want pictures with you! (really?) (i’d agree with this) ○ Lots of (promised) beer or alcohol of your choice during Summits or Mid-cycles/PTGs
○ docs wants sign-off prior to release for the install guide now with a tag in the governance repo ○ interop wg is looking for help on guidelines each release
○ release team needs that stuff done ○ security team needs ○ cross-project needs for feature development (limits in keystone, multiattach in cinder, glance v2 support, routed networks with neutron, etc etc)
○ Feeling the urge to go check email/IRC even when on vacation ○ Find a good way to strike a compromise, e.g. resolve a dispute amongst cores ○ Hopelessly herding cats
○ Keeping up with all the mailing lists ○ Monitoring gate status and making sure we have adequate test coverage ○ The ever-growing bug backlog and how to get people to care about it ○ Running a meeting where clearly everyone is multitasking and/or not paying attention to (the echo chamber) ○ Releasing a library that unintentionally breaks someone, and scrambling to fix the breaks ○ Seeing core members drop out of the community, this sucks. Maybe this is ugly content? ○ Thinking there will be agreement on what you think is an incremental improvement turn into a massive bikeshedding session which ultimately results in nothing getting done and a lot of frustration and wasted time.
○ Foundation wants you doing marketing stuff each release ○ Product wg wants you working with the foundation to set a 3-release out roadmap for what you're going to be working on
○ Vendors hate you for not getting their specs approved or code in ○ Constant pressure for not pushing through enough code ○ Trying to justify the time you spend upstream to your employer
○ Growing the core team ○ Dealing with the stress of retention (or the perception that openstack is failing and it's all our fault) ○ Having to kick/ban people from IRC ○ Being the PTL of a project with bad reputation or on the verge of collapse (is this Nova or Neutron, or both?) (I was thinking murano or zaqar) ○ Telling people nicely that they are full of it ○ Release crunch time
○ Arguing with your spouse about why you need to travel so often ○ Working until the crack of dawn
Should we each talk about our experiences here? That’s easy for me with Nova. It also ties into ‘the journey’ and how one becomes PTL a bit, because John was doing some of the work for Michael, and I was doing some of the work for John, so the transition was pretty natural. SM: let’s just add this to the “ugly” part
Reality Perception
Steve Martinelli
Software Developer, IBM M-N-O Keystone PTL @stevebot
Matt Riedemann
Software Developer, Huawei N-O-P Nova PTL
Armando Migliaccio
Software Developer, SUSE M-N-O Neutron PTL @armandomi2001
After Before
Reality Perception
Perception
answer all questions.
Reality
people before you were thinking.
manager and liaison.
○ Gate sanity, nominate cores, organize PTGs, liaise, bug triage, meetings, bug smash, stable maintenance, release libs, mailing list, release notes, etc….
○ Work from the ground up (fix bugs, watch the gate, help with the release, documentation, ...) ○ Become known, build a cross-project network ○ Make yourself available ○ Perform hundreds of code reviews ○ Become a core ○ Work well with the current PTL and other cores
○ Piss people off: think twice before you push the Send/Post button ○ Think you know it all (see comment #1): be humble and always ask for feedback ○ Work in isolation: keep a live pulse with the community ○ Push your company’s agenda onto everyone else
○ You have a solid understanding of both the project’s technical and social aspects ○ You’re an excellent cat herder ○ You have time that you can devote to the upstream project for the given cycle ○ You have time that you can devote to the upstream project for the given cycle ○ You have time that you can devote to the upstream project for the given cycle ○ ...that’s right, because most likely you’ll end up running more than once!
○ Because your manager asks you to ○ So that you can drive your own company’s agenda ○ Because you can ask for more money, if you go to another employer
○ You’ll learn a lot more about yourself than you’ve ever wanted ■ How to optimize everything, manage every minute of your day ■ What amount of work you can handle, and how you choose to handle extra work (longer hours or delegate) ■ How to be a leader (rally a team, delegate work, communicate effectively) ○ Chance to pass on what you’ve learned and create future leaders
○ See the project change and grow ○ Nominating new core members! ■ Watching core members grow and learn
○ You do a lot of the day to day dirty work and see how the sausage is made ○ Mentoring new contributors ○ Orchestrating dozens of new features ○ Fixing bugs and adding code that fills long standings gaps ○ Building consensus ○ Actually seeing big complicated cross-project efforts get worked out and implemented
○ All the glory and fame! (not really) ○ Being the go-to person, if that’s your thing ○ Increased visibility in the industry ○ You’re like a rock-star: other developers want pictures with you! (really?) ○ Lots of cheering when stepping up ○ Lots of praising when stepping down ○ Lots of (promised) libations of your choice during Summits or Mid-cycles/PTGs ○ Your opinion might actually have some weight
○ Dealing with governance tags, e.g. docs, stable maintenance, upgrades, etc ○ The interop workgroup is looking for help on defcore guidelines each release ○ Working with tangential teams ○ Release team needs that stuff done ○ Security team needs ○ Cross-project needs for feature development (limits in keystone, multiattach in cinder, glance v2 support, routed networks with neutron, etc etc)
○ Feeling the urge to go check email/IRC even when on vacation ○ Find a good way to strike a compromise, e.g. resolve a dispute amongst cores ○ Hopelessly herding cats ○ Working long hours due to guilt and feeling that there is always more to do
○ Keeping up with all the mailing lists ○ Monitoring gate status and making sure we have adequate test coverage ○ The ever-growing bug backlog and how to get people to care about it ○ Running a meeting where clearly everyone is multitasking and/or not paying attention (the echo chamber) ○ Releasing a library that unintentionally breaks someone, and scrambling to fix the breaks ○ Seeing core members drop out of the community (when they didn’t want to) ○ Thinking there will be agreement on what you think is an incremental improvement turn into a massive bikeshedding session which ultimately results in nothing getting done and a lot of frustration and wasted time. ○ Being expected to have an opinion about everything, even though your opinion might not matter
○ Managing contributors and workplace expectations ○ Contributors resent you for not getting their specs approved or code merged ○ Constant pressure for not pushing through enough code ○ Trying to justify the time you spend upstream to your employer ○ Having a disconnect with PTLs in other projects ○ Having a disconnect with former/future PTL in the same project
○ Growing the core team ○ Dealing with the stress of retention ○ Having to kick/ban people from IRC ○ Being the PTL of a project with a bad reputation or on the verge of collapse ○ Telling people nicely that they are full of it ○ Release crunch time
you're going to be working on
around, give them a hug (except mriedem, he doesn’t do hugs).