Observations on WordPress Contributor Team Structure

As the conversation around training team leads and team reps becomes more active, I have often explained how the project currently manages itself. Because this continues to be a topic of interest to contributors, it seems like information that should be shared in a more transparent and permanent way.

As part of my work on the WordPress project over the past three years, I’ve spent a lot of time observing the ways that contributors currently participate. To get more information about how everything is organized I read documentation, spent time talking to past and current team reps, and spoke to people who have been contributing for twice as long as I have (or longer).

After all that information gathering, some patterns emerged around how contributors hoped to work, how things actually worked, and the ways that teams tried to split the difference. I’ve detailed what I was able to learn and observe about a couple of the teams I was most active with, though the broad strokes seem true for many other teams as well.

Paths to Leadership

At WCUS 2017, I talked about the Five Stages of Volunteering, where new WordPressers are in Stage 1 leveling up to Stage 5. The ladder below gives a more visual representation of what I’ve seen. 🙂

In my observation, similar, secondary ladders exist in most other teams in the project as well. The two teams that have the most well-defined process up those ladders are the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Team and the Community Team.

The method of moving from one step to the next is entirely dependent on potential risks, levels of trust required, and severity of the outcome should a mistake happen. Moving from one point on these ladders to the next seems to happen in one of three ways:

• Self-selection
• Self-serve training + selection
• Closed selection

Each step on the ladder is contingent on the previous step, though there is no set time between them.

Getting From Here to There

The processes around leveling up volunteers are not consistent across the project. Whether volunteers are moving from the general ladder and onto a team ladder, or just from one step to the next on a single team ladder, the responsibility often falls to the volunteer themselves.

It is not intentional that onboarding and “paths to leadership” processes depend so heavily on the contributor’s willingness to expand their role in the project. The expectation that a contributor will express interest in and drive their own path to greater responsibility is largely consistent with open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. norms, in which most contributions come from those who are independently  motivated. It’s worth noting that there are multiple paths to WordPress itself, and nearly as many paths to deciding how and when to get involved once you arrive.

I’ll share what I’ve observed from those three methods I shared above.

1. Self-selection – I saw this most often from beginning contributors. Tasks and research that use only the skills and tools that person already has, and can be done and shared without any additional training. A lot of self-selection happens at Contributor Days, Translation Day, and other in-person WordPress events — from translating and captioning, to filing bug reports and submitting patches, all it takes is some passion and some time to participate in these tasks!
2. Self-serve training + selection – I saw this most often with tasks that are managed in public already, but need some additional training for the work to be productive or effective. The training in some cases is formalized (like the Community Team quizzes) and in other cases is informal (like reading handbooks/documentation, and attending meetings). The selection is often casual and ad hoc, from people already doing this type of work who are noticing good work and want to encourage it.
3. Closed selection – I saw this most often with tasks that required high levels of trust and accountability (frequently tied to continued employment), being quite close to infrastructure, or handling very sensitive information (e.g. those managing our databases, anyone handling payments, etc). I also saw this with selection of Lead Developers/Focus Leads, and named leadership (including my own position).

Feedback

Please share your thoughts and observations in a comment on this post! Specifically, I’d love to know:

1. Are there other paths to leadership in the WordPress project that I’ve missed?
2. Are there other ways to get from one point in the path to the next that I haven’t included here?