This Project Management Committee Guide outlines the general responsibilities of PMC members in managing their projects.
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.
Terms in this section as used as per RFC 2119.
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.
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).
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 guide their new committers, ensure that they have access to the proper resources, advise them about relevant ASF documentation (e.g. the Guide for new committers or the Committers' FAQ ) and generally ease their way. For individuals who are already committers on another Apache project, you will only need to grant them karma to your project instead of the below.
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 sent to the correct address (email@example.com) 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. The ASF New Account Request form should be used to send a new account request. Should the PMC chair be unavailable for any reason, any ASF member can use the same form in his/her stead.
(Note to Incubator people: 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. 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. Most of the groups are defined as LDAP references; see below for how to update them. A few groups (usually Incubator podlings) are not currently in LDAP and consist of a list of user ids. These groups are updated by editing the asf-authorization-template file in SVN.
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.
There currently are two ways to make changes to LDAP groups.
The first way, which either is going to go away or move to a chairs-only VM created for this purpose, is to login to minotaur.apache.org and use the utilities described below.
modify_unix_group.pl : To modify project group membership (also updates the corresponding Unix group)
Note: generally the same LDAP group is used for both SVN access and for updating websites.
list_unix_group.pl : To list current project groups and their members
modify_committee.pl : To modify PMC group membership
list_committee.pl : To list the PMC groups and their members.
All of these utilities support the '--help' flag.
[They are located in the /usr/local/bin directory, which is on the default PATH.]
% list_unix_group.pl gump # this will list all committers of the Apache Gump project % # To add committers with uids "foo" and "bar" to the Apache Gump project % modify_unix_group.pl gump --add foo,bar % list_committee.pl gump # This will list all members of the Apache Gump PMC % list_committee.pl # This will list all known PMCs % # To add a pair of committers with uids "foo" and "bar" to the Apache Gump PMC % modify_committee.pl gump --add foo,bar % modify_committee.pl gump --rm bar # To remove committer with uid "bar" from Apache Gump PMC
The second way, which is still new and may have bugs, is for the PMC chair to go to 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.
If the SVN access group is not defined as an LDAP group (e.g. Incubator podling) then just edit the appropriate entry in the asf-authorization-template file and commit the change. (see below)
Podling Git authorization is managed using the incubator unix group. See the previous section (modify_unix_group.pl)
Podling SVN authorization is not managed using LDAP groups. Instead, the member names must be added to the [groups] section of the asf-authorization-template
[groups] ... podling=user1,user2,...,usern
Checkout the current version of the file. Edit the podling line to add the new member id(s).
Save the updated file, and double-check that "svn diff" shows only the expected change. Checkin the updated file, and then see the instructions at the start of the file to get the change deployed.
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 invite to the potential member before the 72 hour NOTICE period has expired! It would be very awkard if the invite had to be withdrawn if the board objected.
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://mail-search.apache.org/pmc/blah-blah
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. This can be done by sending a mail to the EZMLM server at
email@example.com followed by a
XXX = message number).
ASF Members can also access the board archive on the web.
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 does not become official until the Foundation's records 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:
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 and 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.
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; 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, and pass relevant information back to the project PMC, and otherwise serve as a conduit for any questions between the board and the PMC.
While the PMC chair is not required to write their quarterly board report personally, they are responsible for ensuring the report is 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, and no. 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.
Any code which which is not created for Apache needs to be passed through the incubator, or otherwise have a Software Grant Agreement (SGA) or otherwise cleared by the Apache Legal team. The incubator team understand Apache policy and legal requirements. They need to ensure that all the correct procedures have been followed and record the appropriate documents.
For more information read this document and post questions to the incubator general list.
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, non-PMC members should not be allowed to subscribe to private@ lists.
There is a self-subscribe app which can speed up the process.
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.