This guide outlines the general responsibilities of Project Management Committee (PMC) members in managing their projects and common how-to procedures for day to day maintenance. For a high-level overview of the what and why of PMCs, read the PMC Governance overview.
This document is for PMC members of ASF projects. A PMC is responsible for the proper management and oversight of an Apache project, and reports directly to the board four times a year. Every PMC has a Chairperson, who is also an officer of the ASF with the title "Vice President, Apache Projectname".
A project management committee (PMC) is a committee of the Apache Software Foundation charged with responsibility and governance for their top level project. The PMC is the vehicle through which decision-making power and responsibility for oversight devolves to developers.
While committers on a project have the ability to update the code, only the PMC as a body has the authority to vote on formal releases of the project's software. The PMC is also responsible for voting in new committers and PMC members to the project, and following other policies as outlined in this document.
Terms in this section are used as per RFC2119. The Board expects all PMCs to understand and comply with these policies.
PMC Chairs / Vice Presidents SHALL submit a report on their project health on a quarterly basis to the Board, or when requested by a director. In the absence of the PMC Chair, or at their direction, any other PMC members may write and submit the report.
Similarly, PMC Chairs SHALL provide replies to board questions about the PMC report or other project operations to the board@ mailing list and SHALL ensure the PMC takes any actions required by the board.
PMC Chairs/Vice Presidents have specific additional duties listed below.
PMCs SHALL ensure that the work on their project and the code that they produce complies with relevant Legal Affairs Committee policies, including using the Apache License appropriately, handling IP and copyrights correctly, handling cryptography, and producing official software releases of their products.
PMCs SHALL ensure that they manage their projects' brand and treat
all Apache® marks properly as defined in the overview of
PMC Branding Responsibilities and the Apache Project Branding Requirements
for project websites.
PMCs SHALL review use of their Apache project brand by third parties and follow the Apache trademark use reporting guidelines when appropriate.
All technical decisions and the great majority of the work of any PMC should take place on their normal public mailing lists, such as dev@ or user@. Decisions SHALL NOT be made in other media, like IRC, Slack channels, or face to face at conferences; project members should bring proposals arising from such settings back to the appropriate mailing list for all participants to discuss and decide upon.
PMCs SHOULD ensure that decision-making processes allow input over a sufficient amount of time - typically at least 72 hours - so that project participants in various time zones have a chance to participate in the decision.
PMC members SHALL be subscribed to their project's private mailing list, and a sufficient number of them MUST monitor it so that the PMC is responsive to roll calls and other requests from the Board that are sent there.
All PMCs SHALL restrict their communication on private mailing lists only to issues that cannot be discussed in public, such as discussion of:
All projects SHALL use the name private@*project*.apache.org for this
private list (where project is the name of the project). PMC members must
maintain the confidentiality of messages on privately-archived mailing lists.
See the definition of PMC and chair , and be familiar with the ASF Bylaws. The advice for new PMC chairs has additional useful information.
PMC chairs should monitor the minutes of board meetings for entries that are relevant to their project, especially any comments directors make on their project's reports, pass relevant information back to the project PMC, and otherwise serve as a conduit for any questions between the board and the PMC.
Note: Feedback from the board and the unedited minutes of board meetings are not normally public information, and should be treated confidentially. Only after the board has formally approved the minutes of a meeting (normally the following month) are they published publicly. Feedback on meeting minutes is usually sent to the private@ list.
While the PMC chair is not required to write the quarterly board report personally, they are responsible for ensuring the report is complete and submitted on time.
Remember that, as in any committee, the chair is a facilitator and their role within the PMC is to ensure that everyone has a chance to be heard and to enable meetings and mailing lists to flow smoothly. A well-run PMC works together to draw up the information for their board report, but the chair is specifically responsible for getting it to the board. There is no concept of "leader" in the Apache way.
After the project has elected new committers and followed the process to get their account created, the PMC chair ensures the new committer has karma (access) to the project repositories.
The chair is responsible for ensuring your PMC's official roster in committee-info.txt of your PMC members is always kept updated. See How To Add New PMC Members.
NOTICE emails to the board are now generated automatically when the roster is updated. There is no need for PMCs to send a NOTICE before updating the roster. The roster can be updated as soon as the invitation is accepted.
board@ mailing list if desired¶PMC Chairs are welcome to subscribe to the board@ mailing list to stay aware of Foundation level issues that may affect
their project. This used to be a requirement, but the Board made it optional in June 2020. Note that board@ is a privately-
archived mailing list, so information from board@ must NOT be forwarded elsewhere.
If your PMC wishes to change their VP / Chair, typically you hold
a vote or otherwise reach a consensus in the PMC about who the
new Chair should be. Then anyone on the PMC can
send board@ an official resolution for the board to approve (or reject) at the next monthly board meeting
before this change officially takes place.
Use the Whimsy Board Agenda
(requires Apache login) to submit the formal chair change resolution to
the next month's board meeting. Log in to the Board Agenda and click the
add item button at the bottom to add the appropriate resolution. If your PMC
members have difficulty logging into Whimsy, contact the board@ mailing list for help.
Once the board approves the resolution (typically at the next monthly meeting), the newly appointed project VP and Chair will get instructions for how to accept the new role.
Yes, they are officers of the corporation, and no, they are not necessarily "Members". PMC Chairs are appointed by the board to be the Vice President of their top level project and to serve as the Chair of their Project Management Committee. Read an explanation why PMC Chairs are legal officers of the corporation.
PMC Chairs/VPs are not necessarily Members of the ASF. Members of a PMC and the Chair/VP have merit within their project, which is different from the governance of the ASF as a whole Foundation. Members of the Foundation are essentially shareholders in the legal corporation that hosts our hundreds of software projects.
The board reads each submitted project report at its monthly meetings, and sometimes
individual directors make comments or ask questions, using the Whimsy tool, in
the meeting agenda. Shortly after each month's meeting, the Secretary uses
Whimsy to automatically send all comments out to each project's private@
mailing list and to the PMC chair directly.
Some comments are simple feedback or notes on the report; some comments are
specific questions from directors. If there is any question
or unusual feedback in this email, the board expects that a PMC member
will send a reply-all response to board@.
As described on its homepage, the Attic is meant to provide oversight for projects which otherwise would not have oversight.
It's fine for ASF projects to be mature and quiet, with little development activity happening, and that in itself is not a reason to move to the Attic.
However, to be viable, an ASF project must have enough active PMC Members who provide oversight for the project. They fix and release code and handle security vulnerabilities or other serious bugs, for example.
While the PMC doesn't have to fix all the bugs or requests that come in, the Board must be able to verify that there are at least three PMC members monitoring the project's mailing lists who could reply and act in such cases.
To this end, the Board will sometimes perform a PMC roll call.
Sometimes, members leaving a project would result in fewer than three PMC members remaining, while other community members are willing to continue maintaining the project. In such a case, the best way forward, if possible, is to elect a few of those community members to the PMC to keep it viable.
If that does not happen, the Board can "reboot" a PMC by re-establishing it with a new or modified PMC. As an example, see the Board resolution to reboot the Apache Xalan PMC from the February 2019 Board minutes.
Mature or very slow-running projects should periodically (we recommend once a year) do a PMC roll call to confirm their viability.
In summary, the only reason for a project to move to the Attic is lack of oversight due to an insufficient number of active PMC members.
Note that going to the Attic is not necessarily a bad thing: it's merely a reflection that there isn't currently an active community to manage the project. It's also a clear way to set the right expectations for users of the project's code.
The Board sometimes asks for a roll call for projects that fail to report regularly, have very little visible activity on their mailing lists or releases, or do not seem to be responsive to security issues.
If a Director (on behalf of the Board) asks a PMC to perform a roll call, the PMC must respond by showing via an email thread that at least three PMC members are active.
A PMC can do this by each of its active members replying to a thread
to board@, or by having one PMC member send a link to a thread on the PMC's
lists where at least three PMC members reply that they are still monitoring
the project and could assist with creating new releases if needed. Be sure
to let the board@ mailing list know when at least three PMC members have
responded (or always cc: board@).
Projects must reply to the Board's request for a roll call. Failure to show that at least three PMC members are present before the next monthly Board meeting can lead to the Board concluding the project is due to shut down and move to the Apache Attic for lack of oversight.
See also why would a project move to the Attic?, above.
The usual process for adding a member to a PMC is to:
In specific cases, however, such as low PMC participation preventing the number of required votes from being reached, or the PMC chair being unavailable for an extended period of time, PMC members can ask the Board to make the necessary changes to the PMC without a successful PMC vote. In such a case, the Board would only be concerned if there is opposition within the PMC.
To officially add the candidate to your PMC, you need to:
Note: if the person being invited is not yet an ASF committer, be sure to request a committer account for them first. Updating the official PMC roster can be done with the Whimsy tool:
https://whimsy.apache.org/roster/committee/
Click through to your PMC's page and follow the instructions to Add/Modify. If the Whimsy tool does not work, then see documentation on updating LDAP and committee-info.txt.
If you would like to resign from a PMC, simply send an email to your project (typically the private@ list) formally resigning, and ask the PMC chair to remove you from the roster. The PMC Chair can then follow the (removal steps below)[#emeritus].
"Resignation of a member of a PMC shall take effect immediately upon receipt of their resignation, as recorded on any of the Foundation's mailing list archives, but can be revoked by that member within 72 hours of receipt."
The official process can be found in the September 2022 board minutes under section 7 C. PMC Membership Change Process.
The ASF does not have any formal concept for an "emeritus PMC member" - an individual is either a member of the PMC or not. Projects are free to establish their own policies for designating members of the PMC who are inactive but remain on the PMC, or those who were formerly on the PMC and have resigned. Some projects have also established guidelines to allow former PMC members to remain on the private PMC list, and to allow a PMC member to request reinstatement simply by asking (note that the standard Board notification procedures must still be followed for reinstatement).
Once the PMC member's resignation is received on a mailing list of the Foundation, the resignation is considered effective. However, the PMC member has 72 hours to withdraw their resignation. Notifying the board is not required, but encouraged to ease tracking.
Once the resignation has taken effect, the PMC Chair should:
Projects can establish their own policy on handling inactive members, as long as they apply it consistently. It is not a problem to retain members of the PMC who have become inactive, and it can make it easier for them to stay in touch with the project if they choose to become active again.
Often, PMC members who are no longer able to participate will resign from the PMC by emailing a request. In some cases where PMCs have a large number of inactive members, PMCs have asked the inactive members if they'd like to resign.
If a PMC chooses to remove one of its members (without that member's request or consent), the PMC must ask the Board to remove the member. The PMC chair should send an email to the board@ mailing list detailing the request for removal and the justification the PMC has for that removal, and copy the project's private@ list. The board will review the reqest as well as your project's mailing lists to see if the removal is controversial or opposed, and then make a decision, typically at the next month's board meeting.
This is a tragic occurrence, but with so many communities here at the Foundation, it is bound to happen occasionally. Each community can decide how they want to handle this issue:
It is the responsibility of each project PMC to review productive contributors to their project and consider nominating those contributors as committers, and then voting them in as committers (and possibly PMC members as well). PMCs should be guiding their new committers, to make sure that they have access to the proper resources and ASF documentation (e.g. the Guide for new committers and the Committers' FAQ ). If a productive individual is already an Apache committer on another project, you can just grant them karma to your project.
Most PMCs hold formal votes on committer nominees to decide whether to invite them, although PMCs are free to follow their own documented process for finding consensus on adding new committers.
Once the PMC formally wants to invite an individual to be a committer,
invite them,
(using the appropriate one of these templates)
and require the new committer (if an ICLA for the committer is not already on file) to
submit an Individual Contributor License Agreement (ICLA) to the secretary.
The secretary cannot process new committer accounts without receiving the CLA acknowledged by the ASF secretary or
a board member. Your PMC needs to work with the new committer to ensure
that their CLA is received and recorded properly, so you need to monitor
the file iclas.txt in the foundation/officers repository. Only ASF
members and officers (PMC chairs) have access. The Apache Phone Book
has an Unlisted CLAs page
which is generated daily from the iclas.txt file, and recently received CLAs
appear there.
Encourage your new committer to include both the PMC name and their desired account ID
on the submitted ICLA. If both of these pieces of information are provided on the ICLA
form, the ICLA is sent to the correct address ([email protected]), and the secretary
or assistant secretary can verify a [VOTE][RESULT] for the new committer, the account will be requested
by the person (secretary or assistant secretary) filing the ICLA.
If the new account information is not provided on the ICLA, the PMC chair is responsible to get the new committer's desired account ID and request the new account.
Once the ICLA has been filed, use the ASF New Account Request form to generate the request. Should the PMC chair be unavailable for any reason, any ASF member can act on their behalf.
For incubating projects: If
the secretary or assistant secretary will request the account. In other cases, the Mentors will request the account. If the podling you're requesting accounts for doesn't appear in the drop-down list of podlings, provide the podling name in the free text input box.
Most PMCs decide on new committers through an election process on their private mailing list. Please include a URL or message-id reference to the final vote tally using the Apache Mail Archives.
New account requests will only be accepted from PMC chairs and ASF members. If you are acting on behalf of a project which was accepted for incubation, please get in touch with the sponsoring PMC and let them take care of requesting any new accounts.
The request will be CC'd to the PMC mailing list. Barring objections from the PMC, the infrastructure team will create the account and assign the appropriate group permissions. This may take a few days. A message confirming the new account will be sent to the PMC mailing list and to the new committer.
If the ICLA included the PMC name, normally the account will already have been set up in the correct LDAP group that will grant access to the project source repository.
If not, the PMC takes over and provides the rest of the infrastructure needs. In particular, the PMC chair has the ability and the responsibility to provide write access to the project's source repository.
For most operations, PMCs do not need to do anything to grant new committers SVN access to their areas. However, if the automatic LDAP process does not work for some reason, the PMC can use the ASF authorization template.
The [groups] section of the file defines SVN group names and their members. The groups are defined as LDAP references; see below for how to update them.
To grant or deny access to directories in SVN, the PMC chair needs to update the appropriate [group] entry. The PMC chair has access to make changes to the project groups held in LDAP.
PMC Chairs may use the Whimsy roster tool, navigate to the committee, and either double click on the person or the plus sign to modify or add a person.
Podling authorization is managed using LDAP groups, just like PMCs - use the Whimsy Roster tool.
In this case, contact your PMC first. All PMC chairs can give an existing Apache ID access to their project's repositories. See how-to above. For podlings, the PMC is the Incubator.
Chairs may use Whimsy's roster tool to modify their project membership lists.
ONLY if a PMC chair is not responsive or unavailable, then contact the Apache Infra team for assistance. This should only be for people who already have an Apache account and need extended commit access.
Karma request form:
To: infrastructure
Cc: private@<project>.apache.org, [email protected]
Subject: Karma request
Userid: ...
Requested karma: <project>[/<subproject>]...
Reason: [a few lines explaining why someone needs karma]
[Vote: reference to mail archive for PMC bookkeeping]
Once the request has been received, a person with appropriate access will extend the karma and reply accordingly.
Most committers can access all needed resources with just their Apache ID and their project's repositories and mailing lists. But if you do need access to other official ASF servers, request an account by contacting the Apache Infra team.
Account request form:
To: infrastructure
Cc: private@<project>.apache.org, [email protected]
Subject: Machine account request - <machine>
Userid: ...
Machine: ...
Groups required:...
Reason: [a few lines explaining why an account is required]
[Vote: reference to mail archive for PMC bookkeeping]
The administrator of the machine will then reply accordingly.
If the code to be imported is licensed under a Category A license and the intent is to distribute the code under its original license, copy the code into the Apache source repository, preserving its original header. Add the license for the code to the top level LICENSE file. If the team makes changes to the code, add an Apache header to the file(s) that notes the changes.
If the code to be imported is intended to have continued development in Apache, and the owners of the code are willing to contribute their Intellectual Property to Apache under an Individual Contributor License Agreement, Corporate Contributor License Agreement, or Software Grant Agreement, you can copy the code to the Apache repository, changing the license header to the standard Apache header. In this case, the code needs to be reviewed by the Incubator via the Intellectual Property Clearance process.
There are a number of Apache lists whose archives are not available to the public. Posts to these lists are considered confidential. Do not quote them on public lists our outside the ASF without the permission of the author.
PMC members may search archives of their project's private@ list. ASF members
and officers may also read PMC mailing list archives. There
are several ways to access our private archives:
-get administrative command to ezmlm to download groups of mails.All PMC members of a project should be subscribed to their project's private@
list. In addition, ASF Members may read any project's private list. In general,
people not on a PMC should not be allowed to subscribe to private@ lists unless they are ASF Members.
You can self-subscribe to mailing lists.
There are two main ways to check the membership of PMCs and LDAP groups:
Please allow time for any changes to LDAP and committee-info.txt to propagate to the Phonebook app.
Note: The official record for PMC membership is the committee-info.txt file, and not the LDAP committee group.
See the Contact Infra roadmap to request these and other resources for your project.
In almost all cases, discussion of project business should happen on that project's publicly archived mailing lists - the detailed policy explains the few exceptions.
Discuss any topic which does not specifically need to be private on an appropriate public mailing list. This allows the public to read about the direction of the project and to offer early feedback.
Most projects do their work on their dev@project.apache.org mailing list. Some projects also have a user@ mailing lists for more general or non-technical questions, and may have a general@ mailing list. Every project should have a clear mailing lists page that has instructions for subscribing to their lists and for reading the archives.
Normally, Apache projects are expected to manage their own affairs; the people on a PMC and regular committers typically know the best way to work within their project communities. However, if things don't work well, or the project community has serious policy questions or disagreements about how to work together, you can ask for help elsewhere around the ASF.
The detailed Escalation Guide
helps communities figure out where to get help from other groups at Apache,
or, if all else fails, to ask for help or appeal issues to the Board.
The Apache Organizational Chart
can help you find the right officer or group to ask for help on most issues,
like legal, branding, press, or the many other services the ASF offers projects.