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 Armando Migliaccio Software Developer, IBM Software Developer, SUSE M-N-O Keystone PTL M-N-O Neutron PTL @stevebot @armandomi2001 Slides available at: https://www.slideshare.net/SteveMartinelli1/building-iam-for-openstack
BEFORE & AFTER
Before After
PERCEPTION vs. REALITY
Perception vs Reality Perception ● The PTL knows everything about the project ● The PTL is a dictator ● The PTL is the best coder on the team ● The PTL is a “super reviewer”
Perception vs Reality Reality ● We don’t know everything ○ We’re also not historians or psychics ● We’re not dictators ○ We’re moderators and liaisons ● We’re not the best coders ○ We’re hardly the best at anything ● We don’t just review code, we also… ○ Ensure the gate isn’t broken, nominate cores, organize PTGs, liaise with projects, triage bugs, run meetings, organize bug smashes, ensure stable isn’t broken, release libraries, monitor mailing list, draft release notes, etc...
BECOMING A PTL: HOW & WHY?
Becoming a PTL: How? The DO’s ● Work from the ground up ● Become known across projects ● Make yourself available ● Review code ● Become a core ● Work well with others The DONT’s ● Piss people off ● Think you know it all ● Work in isolation ● Push a company agenda
Becoming a PTL: Why? Good reasons ● Solid understanding of technical and social aspects ● Excellent at cat herding ● You have enough time to devote to working upstream ● You have enough time to devote to working upstream ● You have enough time to devote to working upstream Bad reasons ● Management asked you to ● Promote company agenda ● Leverage for more money
The Good, The Bad, and The Ugly
The Good Learning ● Learn about yourself ● Practice soft skills ● Passing on what you’ve learned Growth ● See the project change and grow ● Nominating new core members ● Watching core members grow and learn
The Good Service ● Doin’ the dirty work ● Mentoring contributors ● Coordinating feature development ● Building consensus
The Good Recognition ● Accolades, fame ● Increased visibility in the industry ● Lots of promised libations ● Lots of cheering when stepping up ● Lots of praising when stepping down
The Bad Bureaucracy ● Keeping up the many threads of execution: ○ project governance changes ○ interop working group ○ initiatives in other projects ○ release management ○ vulnerabilities ○ roadmaps, really!? ● Reality is PTL can indeed rely on liaisons, but...
The Bad Workload ● Disconnecting is hard ● Hopelessly herding cats ● Put out fires outside working hours ● Ever growing backlog ● Release crunch time
The Bad Everything Else ● Deal with scale beyond human proportions ○ Email inbox explosion ○ Gate queue explosion ○ Bug backlog explosion ● Unable to motivate people to care about ○ bug triage ○ test coverage ○ team meetings
The Ugly Managing Expectations ● Contributors may resent you ● Trying to justify upstream time to employer Managing upstream relations ● Having a disconnect with other PTLs ● Having a disconnect with former/future PTL
The Ugly Team Dynamics ● Growing/Contracting the core team ● Having to kick/ban people from IRC ● Being PTL of a project with a poor reputation ● Having a row over IRC or ML ● Having to be mom or dad to adults
To conclude ● The point of the talk was to peel back the curtain a bit ● Hopefully we haven’t turned you off completely, it’s a very rewarding experience ● If you see a PTL around, give them a hug ○ (Except Matt, he doesn’t do hugs)
Questions? … and hopefully some answers
BACKUP SLIDES
Spitball “Good” ideas here ● Learning ○ 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 ● Growth ○ See the project change and grow ○ Nominating new core members! ○ Watching core members grow and learn ● Service ○ You do a lot of the day to day dirty work and see how the sausage is made ○ Mentoring new contributors ● Project Improvements ○ 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. ● Notoriety (Recognition? Notoriety has a negative connotation) ○ 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
Spitball “Bad” ideas here ● Exposed to the bureaucracy: ○ 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 ● 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) ● Workload ○ 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 ● Misc ○ 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.
Spitball “Ugly” ideas here ● Foundation tasks ○ 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 ● Managing vendor and workplace expectations ○ 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 ● Team Dynamics ○ 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 ● Misc: ○ Arguing with your spouse about why you need to travel so often ○ Working until the crack of dawn ● Burnout is a real thing ● The drop in respect/importance can be a real kick to the self-esteem
The Delicate Hand-Off 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
team/liaison organization evolution ● Used to be Project “Technical” Lead, now it’s Project Team Lead. ● Idea: post-PTL trend to jump into TC (maybe doesn’t fit here, but somewhere), life after PTL
Perception Reality
Before After
wordy format
About the Presenters Matt Riedemann Software Developer, Huawei N-O-P Nova PTL Steve Martinelli Armando Migliaccio Software Developer, IBM Software Developer, SUSE M-N-O Keystone PTL M-N-O Neutron PTL @stevebot @armandomi2001
Before After
Perception Reality
Recommend
More recommend
