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

Contents

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?" and the Community Development PMC's website.

PMC Required Policy

Terms in this section as used as per RFC 2119.

Comply With Legal Affairs Policies

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.

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@ project.apache.org for this private list (where project is the name of the project).

PMC FAQ

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

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 people.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.]

Examples:

% 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

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 apache.org. This should only be for people who already have a people.apache.org account and need extended commit access.

Karma request form:

To: infrastructure
Cc: private@<project>.apache.org, 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 people.apache.org.

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

Account request form (other machines than people.apache.org):

To: infrastructure
Cc: private@<project>.apache.org, 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.

We've voted in a new PMC member. Now what?

According to the current rules, election of a new PMC member requires notification of the board by the PMC chair (this cannot be delegated). The PMC chair should send a simple email asking for acknowledgement of additions or removals (provide the committer ID and name); ensure the PMC private list is copied - but do not Cc the potential member.

For example:

To: board@apache.org
Cc: private@<project>.apache.org
Subject: [ACK] Jane Doe to join <project> PMC

The <project> PMC has VOTEd to invite Jane Doe (janedoe) to the PMC.

(optional) The vote result is available here: https://mail-search.apache.org/pmc/blah-blah

Could an Apache Board member please ACKnowledge this PMC addition?

One board member will acknowledge, then a waiting period starts (72 hours). After this has elapsed and no board member objects, your PMC chair needs to:

• formally invite the new member; if they accept, then:
• update https://svn.apache.org/repos/private/committers/board/committee-info.txt with the new PMC member's details and the effective join date.
• 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. modify_committee.pl {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)

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

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, http://apache.org/foundation/marks/responsibility.html, 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.

According to the current rules, all changes to the composition of a PMC require that the PMC chair notify the board.

The PMC chair should send a simple email asking for acknowledgement of any removals (provide the committer ID and name); ensure the PMC private list is copied.

Once the removal has been acked, and the 72 hour wait has elapsed, the PMC chair should:

• update https://svn.apache.org/repos/private/committers/board/committee-info.txt to remove the entry entirely
• update the appropriate {project}-pmc group i.e. modify_committee.pl {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, a PMC can request removal of inactive PMC members who have not responded to repeated inquiries about their status. In this case, the PMC chair should send an email to the board asking for acknowledgement and providing rationale for the change, and then follow the usual process for removing a PMC member.

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.

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. After a successful vote from your PMC, the chair sends an email to the board (Cc your PMC private list) asking for acknowledgement, wait 72 hours, then add to committee-info.txt as described above. Also update the LDAP committee group (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 incubator.apache.org.

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:

• mail-search.apache.org
• The archives are in /home/apmail/private-arch on people.apache.org (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.

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.