[NEW CHALLENGE] Cultivating community leadership

[shaunagm]

Tell us about the governance challenge you're thinking of

Many projects have a sole maintainer model, not because that person wants to be the sole maintainer, but because cultivating additional leaders is hard work and they're not sure how to do it. Signs that a project is experiencing this challenge include:

• the maintainer is starting to feel burned out, and like there's too much for them to do
• there are members of the community that want to help, but they're not sure how
• all action/decisions are going through the maintainer, even when they don't have to
• people who want to get more involved feel blocked by not knowing how to help, or not knowing enough to help well

My sense from my own experience and interviewing other project maintainers is that there are two big elements that are useful in cultivating leadership:

• having tasks people can help with that do not require lots of context about the project, but that help build context
• identifying which tasks really do require careful thought and maintainer oversight, and which do not, and encouraging people to try their hand at the latter while explicitly saying it's okay if they get things wrong

Over time, as community members gain a greater understanding of the project, they can tackle more complex tasks and be trusted to make more important decisions, until eventually they are essentially co-maintainers.

Potential Resources

Newcomer-Friendly, Context-Building Tasks

There are a surprising number of tasks that community members can perform which do not require too much familiarity with a project, but end up building familiarity (what I call "context") about the project. These include:

• Issue Triage: doing issue triage exposes community members to the biggest pain points in a project as well as the biggest areas for growth. How effective this is as a context-building activity will depend somewhat on what issue triage involves. Soliciting more information and context from the bug submitter helps make for better bug reports/feature requests, and also helps the triager learn more. There are a number of projects that explicitly have "triage teams" that include more than just existing maintainers (see Python).
• Pull Request Review: while in some (most?) cases it is important for a knowledgeable person to review pull requests, it is almost never harmful for a newcomer to also review, and doing so helps expose newcomers to context about how the project works, including the structure of the codebase, the testing suite, and what kind of bugs/feature requests are common. This mastodon thread has a dozen or so projects that do external/newcomer PR review, including several writeups.
• Writing Release Notes & Other Summaries: Cutting a new release can require expert judgment to decide what should be included and what should not, but writing up reader-friendly release notes/summaries (including credits to contributors) is something that a relatively new person can do. As with PR review, this will help them acquaint themselves with how the project is structured and how its changing. And maintainers will likely be very pleased not to have to draft the release notes themselves. For larger, more active communities with busy chats or mailing lists, other kinds of summaries may be helpful. Longtime Python core developer and current Steering Council member Brett Cannon originally got onboarded to the Python core team in part by writing up mailing list summaries.
• Collecting User Feedback: This is just a hunch of mine, but - many projects struggle with collecting user feedback outside of their issue trackers. As we discover ways to help projects be in better touch with their users, their may be a role her for aspiring community leaders to play. :)

[abadger]

Hey Shauna! An idea for context building: Recording notes during meetings. I think this was especially helpful in larger projects where there were "working meetings". People would meet, discuss, debate, and try to improve proposals. Being the person that took notes gave me insight into:

• What was important to the project at the moment
• Who was working on what
• Insight into the personalities of the people active in the project (those who attended the meetings or were making proposals)
• An understanding of what axes people tended to fall along: pro-contributor, pro-product, concerned about process, etc.

I think the benefits are largely the same as Brett's anecdote about summarizing mailing list threads but with a bit more depth into a smaller portion of the whole project.

[shaunagm]

This is great, Toshio! I'm writing it up to add to the summary for the "Context-building tasks" resource. Do you mind sharing if there was a specific project you did this for? No worries if you'd prefer to keep that private.

[abadger]

Sure! I did this regularly when I was a member of the Fedora Packaging Committee.

I did it sometimes but not nearly as frequently for FESCo (Fedora engineering steering committee) and for ansible community meetings.

Message ID: @.*** .com>