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 voted a new committer in. 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.

Once this is done, the PMC chair needs to use the ASF New Account Request form 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 hasn't had its lists created yet, it won't appear in the drop-down list of podlings. In that case just put the podling name in the free text input box.)

For elections held on public lists, please supply the mail-archives.apache.org url. For private lists, you can use the Mail Search tool to locate the appropriate url.

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 - &lt;machine&gt;

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

One board member will acknowlewdge, 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.

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

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 72hour wait has elapsed, the PMC chair should:

• update https://svn.apache.org/repos/private/committers/board/committee-info.txt Either remove the entry entirely, or mark it as [Emeritus]
• update the appropriate {project}-pmc group i.e. modify_committee.pl {project} -rm=id

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@ and infrastructure@ 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. The schedule is listed in committee-info.txt along with the procedure. If there are issues requiring board assistance, then make that apparent, separate from any general project news. The report is mainly about the status of the project, together with any community and legal issues or other general impediments. 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). The reporting page describes what the reports should contain. 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. The archives are found in /home/apmail/private-arch on people.apache.org (note: only accessible by ASF members and officers). 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?

See this.

How Do We Request A New Mailing List?

See this.

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.