This Project Management Committee Guide outlines the general responsibilities of PMC members in managing their projects.
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.
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. See also the Intended Audience section for links.
It is the responsibility of each project PMC to both review productive contributors to their project for potential committership, as well as 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 the individual is already an Apache committer, you can just grant them karma to your project instead.
You need to first ensure that the new committer fills out the
appropriate forms (including the CLA ). An account
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 (email@example.com); 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.
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.
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.
(Incubator note: 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 Mail Search tool or pony mail. If the election was held on a public list, then you can supply the URL using mail-archives.apache.org.
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, a person with root access 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.
The shell scripts are no longer in use; please use Whimsy - see below
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.
This is available to PMC chairs.
Podling Git authorization is managed using the incubator unix group.
Podling SVN authorization is managed using LDAP groups.
Use Whimsy to update LDAP group membership.
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, you may send email to infrastructure at apache.org. This should only be for people who already have a minotaur.apache.org account and need extended commit access.
Karma request form: To: infrastructure Cc: private@<project>.apache.org, firstname.lastname@example.org 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.
Access to official ASF servers is on demand. In order to request an account, please send your request to infrastructure at apache.org.
Account request form: To: infrastructure Cc: private@<project>.apache.org, email@example.com 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: firstname.lastname@example.org 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
email@example.com 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.
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:
One thing that must be done is to notify firstname.lastname@example.org and email@example.com. This will allow the person's account to be disabled, and any necessary Foundation records to be updated.
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 without the permission of the author.
PMC members may need to search the archives of their pmc list. ASF members and officers may also need to read various PMC mailing list archives. There are at least three ways to access our private archives:
minotaur.apache.org(note: only accessible by ASF Members). There are many ways to search them but
grepis easy and simple.
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) .
There is a self-subscribe app which can speed up the process.
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.
The Whimsy tool roster pages are only available to ASF committers. PMC chairs can additionally use the tool to update their PMC. The Whimsy PMC roster pages are at:
For example, check the Gump PMC at:
The Apache Phonebook pages are at:
It's also possible to show PMC details directly, for example:
Please allow time for any changes to LDAP and committee-info.txt to be propagated to the Phonebook app.
The official record for PMC membership is the committee-info.txt file, and not the LDAP committee group.
TODO - the below is out of date
The LDAP committee groups are used to grant access to various resources, for example the PMC private mailing lists and the SVN dist/release tree. The LDAP unix groups are also used to grant access to resources, for example SVN and website publication. Therefore all PMC members (as per committee-info.txt) should be members of the corresponding LDAP committee and LDAP unix groups.
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 firstname.lastname@example.org 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 the list and for reading the archives.
You should have been sent a copy of the advice for new chairs when you became chair. The document gives some additional information you may find useful.
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 are they published publicly - this normally happens one month after the board meeting itself.
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 has the ability to provide write access to the project's source repository (see svn:infrastructure/trunk/subversion/authorization). Other PMC members might also have this ability, however the chair must ensure it's being done. There is a post-commit hook that puts the changes into production immediately.
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 the board an official resolution for the board to approve (or reject) before this change can officially take place. There are lots of examples in past board minutes, and there is a template for change of PMC chair.
Yes, they are officers, 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.