This Project Management Committee Guide outlines the general responsibilities of PMC members in managing their projects.


Intended Audience

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.

If you are a committer who is not yet a PMCer then you will probably find that the committers guide is more useful.

If you are not yet a committer but are interested in joining Apache then please start at the Contributors Tech Guide.

For more information on how Apache projects are run, see "What makes Apache projects different?", the Community Development PMC's website, and this essay on Apache Project Independence.

PMC Required Policy

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, and handling cryptography.

Comply With Brand Management Policies

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.

Responsibly Report Misuses Of Apache Brands

PMCs SHALL review basic uses of their Apache project brand by third parties and follow the Apache Trademark Use Reporting Guidelines when appropriate.

Conduct Project Business On Mailing Lists

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:

  • Discussion of

    • pre-disclosure security problems

    • pre-agreement discussions with third parties that require confidentiality

    • nominees for project, project committee or Foundation membership

    • personal conflicts among project personnel

All projects SHALL use the name private@ for this private list (where project is the name of the project).


What Is A PMC?

A project management committee (PMC) is a committee of the Apache Software Foundation charged with responsibility for a top level project. The PMC is the vehicle through which decision making power and responsibility for oversight is devolved to developers.

We've decided on new committer. Now what?

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.

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 page Apache Committers has a section at the bottom called "Unlisted CLAs". This page 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 and the desired account id on the submitted ICLA. If both of these pieces of information are provided on the ICLA form, the account might 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

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.

After that, 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.

How to grant SVN access to a project 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. To make changes to LDAP groups the chair needs to login to and use the utilities described below. : 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. : To list current project groups and their members : To modify PMC group membership : 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.]


% gump # this will list all committers of the Apache Gump project

% # To add committers with uids "foo" and "bar" to the Apache Gump project
% gump --add foo,bar

% gump   # This will list all members of the Apache Gump PMC
%        # This will list all known PMCs

% # To add a pair of committers with uids "foo" and "bar" to the Apache Gump PMC
% gump --add foo,bar

% gump --rm bar # To remove committer with uid "bar" from Apache Gump PMC

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.

We want to grant karma to someone who already has an account.

In this case, please contact your PMC first. All PMC chairs can add SVN access for already existing accounts. See above.

If your PMC chair is not responsive or unavailable, you may send email to infrastructure at This should only be for people who already have a account and need extended commit access.

Karma request form:

To: infrastructure
Cc: private@<project>, committers@email.address
Subject: Karma request

Userid:       ...

Requested karma:  <projec>[/<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.

We need access to a machine other than

By default, new accounts are only created on Access to other ASF machines are on demand. In order to request an account, please send your request to infrastructure at

Account request form (other machines than

To: infrastructure
Cc: private@<project>, committers@email.address
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

According to the current rules, adding a new PMC member requires a notification to the Board's mailing list and the PMC's private mailing list. Once the notification appears in the archives, an invitation may be sent out 72 hours later (unless a Director objects).

Note: The current rules 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.

The notification may be sent by the PMC Chair, or by any other PMC member if they include a link to the formal PMC decision.

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 followed by a (XXX = message number). ASF Members can also access the board archive on the web.

Ensure the PMC private list is copied - but do not Cc the potential member. For example:

Cc: private@<project>
Subject: [NOTICE] Jane Doe for <project> PMC

<project> proposes to invite Jane Doe (janedoe) to join the PMC.

(optional) The vote result is available here:

If the candidate does not (yet) have an Apache account, then please note that fact in the notification email.

After 72 hours have elapsed without objection, then the candidacy becomes valid and the PMC Chair needs to:

  • formally invite the new member; if they accept, then:
  • update with the new PMC member's details and the effective join date.
  • Note: the effective join date is the date when the ASF records are updated, i.e. the date in committee-info.txt needs to be the date when the entry is added
  • Please only use their ASF e-mail address as this is used by scripts to identify the person. Also please sort the entries by first name, and don't use tabs! Thanks.
  • update the appropriate {project}-pmc group as described above in Grant SVN access. In almost all cases this means updating the LDAP group, e.g. {project} --add id

This gives access to the PMC-only parts of SVN for the project. (Note: a few projects do not have a {project}-pmc group)

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)

The person can now subscribe to your project PMC mailing list in the normal way.

If the individual 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 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 branding guidelines,, if they haven't already.

A PMC member wishes to be resign/go emeritus. Now what?

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).

Note: see previous section for link to board resolution.

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:

  • update to remove the entry entirely
  • update the appropriate LDAP committee group i.e. {project} -rm=id

Should the PMC remove inactive members?

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, then it must request the Board to make that decision (which is typically done with a resolution at the Board's next meeting). The request to the Board's mailing list should provide a rationale for the decision.

What are the duties of the PMC chair and how to perform them?

See the definition of PMC and chair , and be familiar with the ASF Bylaws and their effect on your project and the position that you hold.

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 the PMC chair is allowed to subscribe.

Monitor the minutes of board meetings and pass relevant information back to the project PMC.

Quarterly report to Board. See the reporting page for what the reports should contain. (Note that new PMCs are required to report monthly for the first quarter.)

The schedule is listed in committee-info.txt, along with the procedure.

The report is mainly about the status of the project, together with any community and legal issues or other general impediments. If there are issues requiring board assistance, then make that apparent, separate from any general project news. You can seek input from your PMC, but it is mainly your report to the board. The chair does not report to the PMC- the chair reports to the board (i.e. ultimately to the ASF membership).

Look at Board Meetings and Calendar for examples of past PMC reports and to find out when the next meetings are due.

Remember that, as in any meeting, 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 to flow smoothly. 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. There is a post-commit hook that puts the changes into production immediately.

Adding a new PMC member. The chair is responsible for sending the 72-hour NOTICE email to the board, then updating committee-info.txt and the LDAP committee group after the candidate accepts -- see above.

Maintain info about your PMC composition in the SVN "committers" repository at /board/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

Changing the PMC chair

If the chair is being changed , then at some stage your PMC needs to 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.

Change VP/chair name at the foundation website. See editing tips for the top-level websites.

See FAQ Why are PMC Chairs officers of the corporation?

See also the documents at Apache Incubator and Apache Jakarta Wiki: RoleOfChair

How Do We Import Code From An External Source?

Any code which which is not created for Apache needs to be passed through the incubator. 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.

How Do I Search The Archives For Private Lists?

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:

  • The archives are in /home/apmail/private-arch on (note: only accessible by ASF Members). There are many ways to search them but grep is easy and simple.
  • PMC members who are not also ASF members can fetch archives in the normal way: via the -get administrative command to ezmlm.

Who Is Allowed To Subscribe To A Project's Private List?

PMC members of each project should be subscribed to their project's private list. In addition, ASF members may join any project's private list.

There is a self-subscribe app which can speed up the process.

How Do We Request A Wiki?

How Do We Request A Blog?

How Do We Request A New Mailing List?

See the Contact Infra roadmap.

Where Should Project Business Be Discussed?

Read the policy.

Each PMC has a private mailing list for the discussion of confidential or socially sensitive topics. As much project business as possible should be conducted on public mailing lists. Any topic which does not clearly 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.

Some projects use the main development list for discussing these matters. Others have a dedicated list (traditionally general ) for the discussion of pmc and project-wide topics which do not need to be confidential.