Each Project Management Committee (PMC) votes on its software product releases and elects new PMC members and committers to its Apache project.
The PMCs are the most important organizations at the ASF. These are the actual groups that decide what software our projects release, and do the bulk of the actual work of the ASF.
This document is background information about how and why organizations at the ASF work they way they do. For official policy information and "How To" style guides, please the documents under References or in /dev.
Contents
Committers elected to the PMC within a specific Apache project provide oversight for the project on behalf of the ASF, deciding the release strategy for the project. PMC members are expected to act as individuals, making decisions for the best interest of the project when acting on PMC or development lists.
Each project's PMC is independent. PMCs are free to set community and technical direction for their project, and are directly responsible for overseeing releases and the healthy development of their communities. PMCs are responsible for ensuring their project follows certain core requirements set by the board or other corporate officers of the ASF, like following Legal-, Branding-, and Infrastructure-related requirements, and ensuring their community operates within the basic outline of the Apache Way.
PMC members nominate new contributors to the project as either committers or as PMC members, and vote whether to elect elect new committers or PMC members. PMC members also have binding votes on any project matters.
PMCs must have at least three (3) active members. This is because the minimum number of positive (+1) votes required for a product release is three.
The board creates PMCs to manage specific named projects by resolution at monthly meetings. New top level projects (TLPs) are most often created from podlings in the Apache Incubator after a successful graduation vote from Incubation. The board appoints a Vice President - an officer of the corporation - to serve as the chair of the project's PMC.
PMC Chairs serve as normal PMC members, with one vote on project matters just like other PMC members. The primary duty of a PMC chair is providing quarterly reports to the board about the health and status of their project. PMC chairs are expected to subscribe to the board@ mailing list, and to be aware of any board concerns about the project, and are responsible for working with the PMC as a whole to address any board concerns.
PMC Chairs are also responsible for updating the official PMC roster when any new members are added to the PMC. See how to add a new PMC member. PMC members who are no longer involved with a project may also request to resign from the PMC.
Changes to PMC chairs/VPs require board resolutions to be approved at monthly meetings, since this involves appointment of an officer of the ASF. Follow the PMC Chair Change process.
As official committees of the ASF, PMCs provide legal oversight of project operations and releases, ensuring that software releases are made as acts of the ASF as an organization, not individual developers. This ensures that the ASF as an organization, not individual committers, bear any legal liability for the products of Apache projects. All PMC chairs provide quarterly reports to the board, which ensures that the board has oversight of all ASF projects.
All PMC members should subscribe to their project's private@ list, and certainly should subscribe to at least the dev@ list to be aware of the operations of the project.
Virtually all PMC communication should happen on the dev@ list or any other appropriate public mailing list. The private@ list for each PMC is for matters that require confidentiality, such as discussing personnel matters, whether to invite new committers or PMC members, or security-related issues that have not yet been publicly disclosed. Ensuring that PMC discussions about the future of the project take place the public dev@ list ensures that all of the community, including non-committers, can follow the discussion and comment on issues. While only PMC members or committers have binding votes on project matters, healthy PMCs work actively with the larger community of their project.
PMCs are free to use JIRA/Bugzilla, wikis, and other Infrastructure-hosted tools that provide for public view and comment, along with the normal project mailing lists. PMCs should make specific requests to the Infrastructure team for services that the project desires.
Some PMCs sponsor in-person meetings, teleconferences, or IRC chats to brainstorm project ideas, but must bring all information back to their project's public lists for further discussion and to make final decisions. Many PMCs either directly organize, or have contributors or organizations in their technical space organize, Meetups, BarCamps, or other in-person events focused on end-user education and sharing technical information.
Given the distributed and volunteer nature of our projects, in-person meetings of PMCs are quite rare. All project business takes place on the project's normal public mailing lists.
PMCs are free to set the bar for merit within their projects, as long as decision-making takes place in a collaborative fashion as in the Apache Way. Healthy PMCs regularly review contributions from non-committers - specific code patches, bugs reported or commented on, or just helpful interaction on their project lists - to evaluate contributors as potential committers. Ensuring that PMC members are mentoring helpful new contributors to their projects strengthens the project community.
PMCs vary significantly in the level of commitment and work they expect for a contributor to be considered for committership or membership in the PMC. Some PMCs vote in new PMC members from their existing committers (i.e. the progression is contributor -> vote -> committer -> vote -> PMC), while other PMCs always elect new committers into the PMC simultaneously (contributor -> vote -> committer & PMC member). PMCs are solely responsible for managing votes and granting commit privileges for new committers; however the board must recognize newly-elected PMC members before they officially become part of the PMC (as described in the Legal section above).
Merit within one PMC is not transferable to other PMCs; each project's PMC manages the project's committer list independently. PMC members or committers with a long history on one project will often be known by their past activities by other project's PMC members, but they are expected to build merit on each separate project they wish to become a committer on. There are many PMCs that work closely with other PMCs, and have correspondingly-large intersection in personnel; but the merit on each PMC is independent.
Although the plain sense of the word "committer" is "someone who can create new revisions in the source repository", the notion of committership is a social one: someone is a committer if the PMC has invited them to be a committer, and they have accepted the invitation.
While only PMC members have binding votes on project releases, in general PMC members participate equally with their project committers and contributors on the dev@ list. PMC members can help develop a healthy and diverse project community by ensuring the project's mailing lists are welcoming to newcomers and that members promote and follow community standards on its mailing lists.
While there are many projects with overlapping communities, and therefore some shared personal or technical relationships, fundamentally each project is its own community in terms of the bulk of project work. While all projects are part of the overall ASF, and share certain basic requirements and bits of the Apache Way, all technical direction and most of the community focus is within each individual project.
PMCs report on the health and diversity of their project's community to the board. While there are no strict requirements on the makeup of PMC members (in terms of employment or affiliation of the individuals on the PMC), the board does expect PMCs to operate independently of outside commercial influence. The board will contact PMCs that are unable or unwilling to ensure their actions are on behalf of the whole community, or that act in ways targeted to benefit specific commercial interest, and will require them to make corrections.
The board does not provide technical direction for any of its projects or activities. PMCs are the governing body for their project, and are expected to manage the project's technology in the best interest of the whole project community, independently of outside commercial influence.
While this may be a surprise to some, it is a key reflection of how the ASF is intentionally structured to ensure maximum freedom to its projects. The board and the ASF are happy to provide a home to any software project communities that are willing to follow the Apache Way. The mission of the ASF is to provide software for the common good. We are happy to help like-minded communities provide that software, are confident that communities will form around software that is useful, and understand that there are many different ways to effectively and collaboratively build software.