This Project Management Committee Guide outlines the general responsibilities of 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, please read the PMC Governance overview.
This document is targeted at Apache PMC members. A Project Management Committee (PMC) is responsible for the proper management and oversight of an Apache project, and reports directly to the board quarterly. Every PMC has a Chairperson, who is also an officer of the ASF titled "Vice President, Apache Projectname".
If you are a committer who is not yet a PMC member then you probably want to read the committers guide instead.
If you are not yet a committer but are interested in joining an Apache project then please start at the Contributors Tech Guide.
For more information on how Apache projects are run, see "What makes Apache projects different?", the Apache Community Development website, and this essay requiring Apache Projects to act Independently.
Terms in this section as used as per RFC2119. The Board expects all PMCs to understand and comply with these policies.
PMC Chairs / Vice Presidents SHALL timely 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, any other PMC members may write and submit the report.
Similarly, PMC Chairs SHALL ensure that board questions to the PMC about their report or about other project operations are answered back to the board@ mailing list and will ensure the PMC takes any actions required by the board.
PMC Chairs/Vice Presidents have specific additional duties like updating their PMC roster and reviewing the board@ mailing list.
PMCs SHALL ensure that the work on their project and the code that they produce complies with relevant Legal Affairs Committee policies, including appropriately using the Apache License, 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 both in the overview of
PMC Branding Responsibilities as well as the Apache Project Branding Requirements that defines requirements for project websites.
PMCs SHALL review basic uses 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 be done on their normal public mailing lists, such as dev@ or user@. Decisions SHALL NOT be made in other mediums, like IRC or at conferences; rather discussions from such places must be brought back to the appropriate mailing list for all participants to discuss and decide upon.
PMCs SHOULD ensure that decision making processes allow input for 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.
All PMCs SHALL restrict their communication on private mailing lists to only issues that cannot be discussed in public such as:
pre-disclosure security problems
pre-agreement discussions with third parties that require confidentiality
nominees for project committer, project committee or Foundation membership
personal conflicts among project personnel
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.
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 is devolved 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, as well as following other policies as outlined in this document.
It is the responsibility of each project PMC to review productive contributors to their project and consider nominating those contributors, and then voting them in as committers (and possibly PMC members as well). PMCs should be guiding their new committers, ensure that they have access to the proper resources and ASF documentation (e.g. the Guide for new committers or the Committers' FAQ ). If a productive individual is already an Apache committer on another project, you can just grant them karma to your project instead.
Most PMCs hold formal votes on committer nominees to decide 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,
you should then invite the person, and require the new committer to
submit an Individual Contributor License Agreement (ICLA) to the secretary.
New committer accounts
will not be processed without 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 ASF officers (e.g. PMC chairs) have access. The Apache Phone Book
has an Unlisted CLAs page
which is generated daily from the iclas.txt file, so the recently received CLAs
will appear there.
Encourage your new committer to include both the PMC name and the desired account id on the submitted ICLA. If both of these pieces of information are provided on the ICLA form; and the ICLA is sent to the correct address (firstname.lastname@example.org); and secretary or assistant can verify a [VOTE][RESULT] for the new committer, the account will be requested by the person (secretary or assistant) 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 (see above), the ASF New Account Request form should be used to generate the request. Should the PMC chair be unavailable for any reason, any ASF member can use the same form in his/her stead.
For incubating projects: If the podling has its status page set up; and the podling is identified on the ICLA; and a valid account id is provided on the ICLA; and the podling is listed on the incubator's ProjectProposals page; and the submitter is named on the project proposal; then the secretary or assistant will request the account. In other cases, the Mentors will request the account. Also, if the podling you're requesting accounts for doesn't appear in the drop-down list of podlings, just put 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 to - and the responsibility of - providing write access to the project's source repository.
Access to SVN directories is controlled by the asf-authorization-template file. 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 (only) 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 Git authorization is managed using the incubator unix group.
Podling SVN authorization is managed using LDAP groups - please use Whimsy Roster tool to update.
In this case, please contact your PMC first. All PMC chairs can add SVN access for already existing accounts. See above. For podlings, the PMC is the Incubator.
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@example.com 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, then you can request an account by contacting the Apache Infra team.
Account request form: To: infrastructure Cc: private@<project>.apache.org, firstname.lastname@example.org 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.
Adding a new PMC member requires sending an email notification to the Board's mailing list and the PMC's private mailing list and waiting 72 hours. Once the notification appears in the archives, an invitation may be sent out 72 hours later (unless a Director objects to the nomination). The detailed process can be found in the June 2013 board minutes under section "7 G. Amend the Procedure for PMC Membership Changes"
Do NOT send an unconditional invite to the potential member before the 72 hour NOTICE period has expired! It would be very awkard if the invite has to be withdrawn if the board objects.
This notification may be sent by the PMC Chair, or by any other PMC member if they include a link to the formal PMC decision or vote on their private@ list.
Ensure the PMC private list is copied - but do not Cc the potential member. For example:
To: email@example.com Cc: private@<project>.apache.org Subject: [NOTICE] Jane Doe for <project> PMC <project> proposes to invite Jane Doe (janedoe) to join the PMC. (include if a vote was held) The vote result is available here: https://lists.apache.org/...
The link should be a Permalink from the lists.apache.org mail archive. This allows any member to easily review the mail vote.
If the candidate does not (yet) have an Apache account, then please note that fact in the notification email.
Use a separate e-mail for each candidate.
Please note: e-mail delivery can fail silently.
Now that an ACK is no longer required, it is vital that the PMC Chair checks the board archives to ensure that the NOTICE has actually been delivered to the board mailing list.
This can be done by sending a mail to the EZMLM server at
firstname.lastname@example.org followed by a
XXX = message number).
If the EZMLM server refuses the request, check that you are subscribed to the board@ list
ASF Members can also access the board archive on the web.
Note that it is not sufficient to check that you have seen the email; the email must appear in the archives.
After 72 hours have elapsed without objection, then you may formally add the candidate to your PMC - the PMC Chair needs to:
Note that the appointment to the PMC does not become official until the Foundation's records (i.e. committee-info.txt) have been updated (see 7G (3) of the board minutes cited above)
If the candidate declines PMC membership or doesn't respond to the invitation, please follow up the original notice to the board to say that the change did not happen, and do not update the records.
The duration of the 72 hour waiting period is very important, not only in this context but also at a project level. People are in various timezones and have busy schedules. As with normal email, we need to provide time for people to respond. The ASF experience has shown that at least 72 hours is needed. We also need to follow defined procedures so that the ASF can operate according to its corporation status. The procedures and these FAQs should make it easy for everyone to operate efficiently.
New PMC members are required to read the PMC Branding Responsibilities, if they haven't already.
"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 detailed process can be found in the June 2013 board minutes under section "7 G. Amend the Procedure for PMC Membership Changes"
The ASF does not have any formal concept for an "emeritus PMC member" - an individual is either a member of the PMC or not (i.e. wishes to resign). 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:
These updates can be done using the Whimsy roster tool.
Projects can establish their own policy on handling inactive members, as long as it is applied 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.
Typically, PMC members who are no longer able to participate will resign from the PMC. However, if a PMC chooses to remove one of its members (i.e. without that member's consent), then it must request the Board to make that decision (which is typically done with a resolution at the Board's next meeting). 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 cc: the project's private@ list.
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:
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, the code should be copied intact to the Apache source repository, preserving its original header. The license for the code should be added to the top level LICENSE file. If changes are made to the code, an Apache header should be added to the file(s) noting the changes that were made.
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, then the code can be copied 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 and must not be quoted 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:
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 (with the exception of ASF Members) .
You can self-subscribe to mailing lists.
There are two main ways to check the membership of PMCs and LDAP groups. Using the Whimsy tool roster pages, and using the Apache Phonebook.
Committers can view, and PMC chairs can update PMC rosters using Whimsy:
Anyone may view Apache Phonebook pages at:
Where you can link to a specific PMC, for example:
Please allow time for any changes to LDAP and committee-info.txt to be propagated to the Phonebook app.
Please 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 resources like these for your project.
In almost all cases, project business should happen on that project's publicly archived mailing lists - the detailed policy explains the few exceptions.
As much project business as possible should be conducted on public mailing lists. Any topic which does not specifically need to be private should be discussed 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 email@example.com mailing list. Some projects also have a user@ mailing lists for more general or non-technical questions, or have a general@ mailing list in addition. Every project should have a clear Mailing Lists page that has instructions for subscribing to their lists and for reading the archives.
PMC Chairs SHALL be subscribed to the board@ mailing lists to ensure that they are aware of Foundation level issues that may affect their project. Note that board@ is a privately-archived mailing list (thus, you should not forward information from board@ elsewhere); however as an officer of the ASF PMC Chairs are allowed to subscribe.
PMC chairs should monitor the minutes of board meetings that are relevant to their project, especially any comments made by directors on their reports, and 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. Note that feedback on meeting minutes are usually sent to the private@ list.
While the PMC chair is not required to write their 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 is responsible to ensure the new committer has karma (access) to your repositories.
Maintain info about your PMC composition in the SVN "committers" repository at committee-info.txt and keep it up-to-date; remember to update the LDAP committee group as well.
Be aware of anything currently in incubation at incubator.apache.org.
If a PMC wishes to change their VP / Chair, typically you will hold a vote or otherwise reach a consensus in the PMC as to who you'd like your new Chair to 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.
It is recommended to use the Whimsy Board Agenda (requires Apache login) to submit the formal chair change resolution to the next month's board meeting. Login 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.
Yes, they are officers of the corporation, and no, they are not "Members". PMC Chairs are appointed by the board to be both the Vice President of their top level project, as well as 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 than the governance of the ASF as a whole Foundation. Members of the Foundation are essentially shareholders in the legal corporation that hosts our 100's of software projects.
The board reads each submitted project report at monthly meetings, and sometimes individual directors make comments or ask questions in the Whimsy tool of 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 personally.
Some comments are simple feedback or notes on the report; some comments are specific questions from directors reading your report. If there is any question or unusual feedback in this email, the board expects that a PMC member will reply-all to send back a reply to board@.
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 present. A PMC can do this by each replying to a thread to board@, or 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 send this to board@.
Projects that are quiet or mature are just fine, even if there isn't much if any development happening. However the ASF does need to show that there are people providing oversight of the project, in the case of security vulnerabilities or other serious bugs being reported. While the PMC doesn't have to fix all bugs or requests that come in, the board does need to be able to see that there are at least three PMC members monitoring the project's mailing lists who could reply if a security problem came up.
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 be shut down and moved to the Apache Attic for lack of oversight.
Mature or very slow-running projects should periodically (once a year is recommended) have a check-in amongst the PMC to be able to show at least three PMC members are still present.