As our community continues to grow, I think it’s useful for us to periodically reevaluate community processes to ensure they meet our changing needs. To that end, I’d like to propose changes to our community’s notion of “code ownership” to realign it better with community needs and expectations.
We originally added code owners when we recognized that one or two people cannot be responsible for the entirety of such large projects. Code owners were introduced to help ensure that experts within a component area provide oversight for proposed changes in that area. We documented this as “The sole responsibility of a code owner is to ensure that a commit to their area of the code is appropriately reviewed, either by themself or by someone else.” However, this doesn’t capture what the community needs code owners to do today. We expect code owners to perform reviews, but we also need them to be responsible for helping to triage and ensure serious issues in their area are addressed, engage in RFCs in their area, help answer questions on Discord/Discourse, hold office hours to help onboard new contributors or unblock work, etc. And because we tend to bias code ownership to a small number of people per area (0-2 people, with 1 on average), it is challenging for our existing code owners to meet the community’s needs.
I would like to propose a bold, new approach. I would like to replace the notion of “code owner” with that of “maintainer”, document a broader list of realistic expectations for the role, allow more people to take on those roles, make it trivially easy for people to volunteer, and make it painless to remove people who can no longer fulfil the responsibilities. Concretely, I am proposing we replace the existing Code Owners documentation with something along these lines:
Maintainers
The LLVM Project aims to evolve features quickly while continually being in a release-ready state. In order to accomplish this, the project needs volunteers willing to do the less-glamorous work to ensure we produce robust, high-quality products.
Maintainers are those volunteers; they are regular contributors who volunteer to take on additional community responsibilities beyond code contributions. Community members can find active and inactive maintainers for a project in the Maintainers.rst file at the root directory of the individual project.
Maintainers are volunteering to take on the following shared responsibilities within an area of a project:
- ensure that commits receive high-quality review, either by the maintainer or by someone else,
- help to confirm and comment on issues,
- mediate code review disagreements through collaboration with other maintainers (and other reviewers) to come to a consensus on how best to proceed with disputed changes,
- actively engage with relevant RFCs,
- aid release managers with backporting and other release-related activities,
- be a point of contact for contributors who need help (answering questions on Discord/Discourse/IRC or holding office hours), and
- coordinate with and provide oversight for other maintainers in the same area of the code.
Each top-level project in the monorepo will specify one or more
lead maintainers who are responsible for ensuring community needs are
met for that project. This role is like any other maintainer role,
except the responsibilities span the project rather than a limited area
within the project. If you cannot reach a maintainer or don’t know which
maintainer to reach out to, a lead maintainer is always a good choice
to reach out to.
All contributors to the LLVM Project are eligible to be a maintainer. However, we are looking for people who can commit to:
- engaging in their responsibilities the majority of the days in a month,
- ensuring that they, and the community members they interact with, abide by the LLVM Community Code of Conduct, and
- performing these duties for at least three months.
We recognize that priorities shift, job changes happen, burnout is real, extended vacations are a blessing, and people’s lives are generally complex. Therefore, we want as little friction as possible for someone to become a maintainer or to step down as a maintainer.
To become a new maintainer, you can volunteer yourself by posting a PR which adds yourself to the area(s) you are volunteering for. Alternatively, an existing maintainer can nominate you by posting a PR, but the nominee must explicitly accept the PR so that it’s clear they agree to volunteer within the proposed area(s). The PR will be accepted so long as at least one maintainer in the same project vouches for their ability to perform the responsibilities and there are no explicit objections raised by the community.
To step down as a maintainer, you can move your name to the “inactive maintainers” section of the Maintainers.rst file for the project, or remove your name entirely; no PR review is necessary. Additionally, any maintainer who has not been actively performing their responsibilities over an extended period of time can be moved to the “inactive maintainers” section by another active maintainer within that project with agreement from one other active maintainer within that project. However, please discuss the situation with the inactive maintainer before such removal to avoid accidental miscommunications. Stepping down or being removed as a maintainer is normal and does not prevent someone from resuming their activities as a maintainer in the future.
To resume activities as a maintainer, you can post a PR moving your name from the “inactive maintainers” section of the Maintainers.rst file to the active maintainers list. Because the volunteer was already previously accepted, they will be re-accepted so long as at least one maintainer in the same project approves the PR and there are no explicit objections raised by the community.
While this sounds like I’m asking a lot more of our existing code owners, my hope is that it’s not an unreasonable request. Many of our active code owners are already performing this work within their areas, so it is a manageable amount of work to some degree. But the real hope is that we get significantly more volunteers to help spread the work around. At least within the Clang community, I know of several people who are doing the work outlined above, but are not getting the recognition they deserve because code ownership is a poor fit (they either don’t feel qualified to “own” something, or their interests are in an area that already has an active owner, etc). If this RFC is accepted, an immediate next step is to put out a call for community members to volunteer to be maintainers.
Allowing multiple people to take code ownership roles in the same area has historically come with concerns about how to handle disagreement between code owners. In Clang, we have experience with multiple code owners for the same areas and we have not run into any such issues in practice. The lldb community has also had a positive experience with overlapping code ownership. In the event of disagreement between maintainers, they’re still expected to work together to come to a consensus position and can always lean on the lead maintainer or other maintainers for the project to help as needed.
Ultimately, I think documenting realistic expectations for what it means to be a maintainer and making it as easy as possible for someone to volunteer for those responsibilities will help improve product quality, improve change velocity, reduce contributor burnout, and give us a better pipeline to develop the “next generation” of community leaders.