You may already know her as a Kubernetes Steering Committee member and maintainer or as a regular speaker at KubeCon + CloudNativeCons across the globe. But this month, we’re shining a spotlight on Paris Pittman for spearheading the Contributor Strategy Special Interest Group, which was formed to help grow flourishing, sustainable communities that can have smooth journeys throughout their CNCF project lifecycle. Paris took some time to answer a few questions about her history in open source, the new SIG, and her goals as a community leader.
Please tell us a bit about your professional background and how you got interested in technology.
I’ve always been envious of people that have a nice four sentence paragraph answer to this question. I’m in good company though with folks who have untraditional backgrounds and career paths.
My interest started super early in life. I learned how to code by tinkering with html tags in my 14 year old America Online profile in the mid-’90s. No one around me was as online as I was at the time; I felt like both a trailblazer and an outcast. I was moderating large chat rooms and forums, submitting bug reports to various projects and platforms, and planning in-person events before I had a drivers license. Bringing people together in Baltimore over a common unity of technology was my jam for decades. Unfortunately I lost my way and changed my major in college from computer systems and design to accounting and business. However, I still made my way into technology and engineering through supporting roles in accounting, engineering recruiting, event planning, and random technician roles (that’s a whole blog). I found my way into open source program management through an idea I had while working at advertising.com, a then-subsidiary of AOL (life is a circle).
It was during this time that I pitched senior leadership the need to invest in technical community engagement (relatable terms today would be DevRel and OSPO). They agreed, budget was secured and it changed my career because people believed in me. If you hear me preach about sponsorship over mentorship, this is why. It was at that moment that I felt empowered by the impact I could make. I didn’t realize that the combination of my random life experiences of bringing people together through early-internet AOL parties, hiring engineers by supporting communities and doing the right thing, running meetups, and advocating for open source could prepare me for the best experience of my life.
Do you remember your first contribution to an open source project?
I don’t remember exactly, but probably bug reports to GIMP. I had no idea at the time that reporting problems in open source was a contribution; I thought it only code counted. I think my first git-based contribution was to Kubernetes three years ago. It’s important to include folks who make your community go around.
I re-read my first doc contribution to Kubernetes about 40 times before hitting the big green button. My journey started with writing guidelines for the first ever Steering Committee election process (I sit on that now). My buddy Jorge Castro walked me through the process and I was so surprised at how stale the docs were already given how new the project was. That was probably my warning flag of how fast the rest of the years would go by. The good news is not much has changed (still rolling along) and the best place to get started is still indeed making a PR to the Contributor and Developer Guides. 😉
Is there any advice you’d give to people who want to start contributing?
So much, but have a feeling I have length requirements with this interview:
1- Open source is a great place to learn and belong, but many companies will pay you to participate. See if your current company can support your contributions.
Explain the value and importance of contributing by dedicating hours — for you: learning a new topic or skill (leading engineers as a maintainer!), make your job easier by staying close to upstream, grow expertise in an area, I could go on for a while here… Resources like TODO Group Guides and OSI can help with the business justifications.
2- Think about how you want to approach: Watch first, do later or pick up a few small issues and consistently deliver.
Open source communities have different norms and some of that can be ambiguous. Even though there is a contributing guide (start there!), it isn’t always immediately obvious where you can best contribute. The technology is documented, you can learn that. But first get to understand the organizational structure and how the community operates to understand if it’s a good fit for you. You’ll understand how and why they make their decisions, which can help with a smoother contributing process for you.
so happy it’s live and be a main resource for the huge community of contributors. big shoutout to @MrBobbyTables for this! https://t.co/X2Bxqapmlk
— paris (@ParisInBmore) August 24, 2020
Why did you decide to get involved with Kubernetes? How did you become a maintainer?
I first heard about Kubernetes in 2015 when I was running the Charm City Linux Meetup Group and folks from Red Hat reached out to come speak about something called Kubernetes. I was just starting to learn about containers at the time so naturally Kubernetes was just a cool word that I brushed to the side like the million javascript frameworks at the time (I think still are?). It wasn’t until OSCON in 2017 that I heard that Sarah Novotny at Google was looking for a Kubernetes Community Manager from my friend Alex who referred me (eh — another sponsorship example!). I was given the opportunity to work upstream creating community for Kubernetes contributors and continue to scale the amazing foundation that Sarah and so many others built.
In Kubernetes, you don’t often hear the term maintainer and instead: approver, reviewer, subproject owner, and many other explicit roles that are located in OWNERS.md and .yaml files. I became a “maintainer” by building trust by following through, raising people with me, caring about the overarching project, and doing glue work.
What inspired you to launch SIG-Contributor Strategy?
It was a combination of things coming at me at the same time:
- I noticed the uptick in questions from other OSS projects to community managers like myself, including those not in the CNCF, for advice on how to operate and scale their communities “like Kubernetes.” But not every project needs to be like Kubernetes, and I saw that as an opportunity to help projects see there is more than one way to do open governance. I saw similar discourse on the TOC mailing list where I was a longtime reader.
- Other discourse on the mailing list about governance related project graduation and incubation requirements got me thinking: How can we help the TOC here with all of the governance wonks around this community?
- Another opportunity I saw that come together in this big idea was maintainer learning/development. To have an intentional space to talk about and make progress on issues like: How do we help deliver scalable strategy for governance? What are some no-burnout and time management strategies? How to grow yourself while you grow others? Management and executives have this development at companies but we miss the boat in providing this support to maintainers who are ultimately performing similar duties as a tech lead+ when they may not be tech leads in their day jobs.
At KubeCon San Diego in 2019 I shared my idea with Liz Rice and Michelle Noorali, two members of the TOC. My thought at the time was we needed a group at the TOC level that is concerned about helping projects out with all things people — contributors, maintainers, consumer + maintainer feedback, etc. — and help TOC members will all the non-engineering things that make a project successful.
I spent the next couple of months writing a charter, gaining consensus, and recruited amazing contributors and chairs. During this time, others came out as equally committed to this mission as me and we pitched the SIG-Contributor Strategy to the TOC and launched in March 2020.
To date, we’ve been working on CNCF Graduation requirements as it relates to community and governance, bootstrapping a project template repo for governance and contributor guidance that you can fork, defining project health with guidance, recruiting folks to lead our maintainer circle activities, and so much more in our repo.
One of the goals of the SIG is to build a community for maintainers. What’s one important thing you’ve learned about being a maintainer that you want to share?
Only one? 🙂 Being an open source maintainer doesn’t have a job description (make contributor ladders the norm though!) and the “off” button seems kinda faulty sometimes. There is a lot of gray area and knowing how and when to draw boundaries is critical.
One more! Not everything needs an answer right away. Being a maintainer requires you to think of the project as whole, which means you will have to do some digging, or talk to others because no one knows everything in large projects. It’s very important to understand what is a priority and what needs more time to be processed, which will help with burnout/time management, delegation, helping new contributors, planning roles and more.
What are your personal hopes for this SIG?
One of my favorite memories in open source was my experience at Maintainerati in Berlin, an unconference event that includes sustainability discussions and other high level open source maintenance discourse with contributors from a myriad of projects. I felt togetherness, acceptance, and even supported from brief conversations with folks experiencing similar situations. I’d like to emulate that here in the maintainers circle concept. There is a lot of power in peer mentoring.
I hope that this network of people who have built governance and contributor operations for various project types (Federations, Clubs, Stadiums) as Nadia Eghal categorizes them beautifully in her book Working in Public — can be valuable to the community and TOC for various degrees of guidance. Each project type has different needs and values (some that may need value development help!) that goes into the creation of a sustainability plan. The decisions you make for governance are going to spur how you run and operate your community later on. With all of our experience and resources, we can help folks not recreate wheels and also not over engineer community processes by forking others.
As a chair, I hope to create an environment where folks can be excited.
What message would you like to send to newcomers to the cloud native community?
Leave it better than you found it, and I promise there is probably a doc for it, if not, write it. 🙂
Any fun facts about yourself that you’d be willing to share?
I have an extra life Mario mushroom tattoo, I was first to graduate college in my family line, and I am obsessed with cauliflower (and have some pretty awesome earrings to prove it).