content/markdown/project-roles.md

<!---
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at

  http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.
-->
# Apache Maven Project Roles

The Apache Maven project is not just the software it produces.
The Apache Foundation has a phrase: "Community over code" which
is about how it is the community that grows around a project
that is the most important thing.

Everyone reading this is part of the Apache Maven community, 
and even if you are an invisible part of the Apache Maven 
community you are still part of the community.

There are many ways we can sort the people in our
community, we present the following as one such way.
Please do not take offence if you disagree with this
categorisation. It is important to remember that we are
a *community* not a *clique* so you are entitled to disagree
with others in the community. 

*Note:* the right to disagree with other people's opinions
comes with the responsibility not to deliberately cause offence
or discord.

## Informal roles

### Lurkers

People who do not use Maven at all, but have an interest in
the project. This can include people who are developing 
competing software tools to Apache Maven.

It would be great if the lurkers would come out of the shadows
and make themselves visible, but every community needs its
lurkers, so if you are a lurker sulking about on the fringes
of the Apache Maven project, know that you are a valued member
of our community. If you ever feel the need to change your role,
we will welcome you with open arms… (and if we don't welcome you
with open arms, please advise the [Project management committee][3]
who are responsible for ensuring that the community is a healthy
one)

### Consumers

People who use Maven, but do not actively join the community.
This does not include people who are: subscribed to one of the
Maven mailing lists; active in a Maven user community (e.g. 
something like [stackoverflow][1]; submitting bug reports; etc.).

Maybe Apache Maven is the perfect product for you and does
exactly what you need and want, and you never have a need
to ask questions about how to use Maven as it is immediately
obvious to you how one is supposed to use Maven… If that is the
case, could you please consider taking a more active role in 
our community, as Maven is none of the above to our minds
and you might have a point of view that we have missed.

If you do have issues with Maven (we all have issues with it
so there is nothing wrong in having issues with Maven), please
let us know:

* Submitting bug reports is the best way to let us know about bugs,
* Asking questions on the [Users Mailing List][2] is the best way
get answers to questions.

As a last resort, other Maven user communities are another route
to getting more involved in the Maven community, but keep in 
mind that Apache Foundation projects are supposed to encourage
the community at the ASF, so you will get more eyes and a
quicker response if you engage directly with the ASF hosted
community.

### Users

People who use Maven and have joined the community. This includes people who have:

* Submitted a bug report,
* Asked a question on the [Maven user list][2],
* Joined one of the other Maven user communities.

We hope your bug report has received some attention. If it
hasn't, why don't you see if you can fix the issue yourself
and submit a patch?

We hope your question was answered. If it hasn't, think of 
all the other users who's questions sit unanswered, how many
of them do you know an answer for (even if only a partial
answer)? Why don't you respond to their questions with the
answers you know? If everybody did that, your question would
have an answer. Pay it forward!

We hope your experience in one of the other Maven user 
communities is a positive one, so why not join the canonical
Maven user community and subscribe to the [Maven user list][2]? 

### Contributors

People who use Maven, have joined the Maven community and contribute 
back to the community. This includes people who:

* Submit reports of the results of testing proposed releases of
Maven and Maven plugins,
* Answer questions on the [Maven user list][2] (or even other Maven user communities),
* Submit patches to resolve reported bugs in Maven or Maven plugins hosted at Apache,
* Help curate bug reports by identifying duplicate reports, or
related issues.

We wrote [a guide for contributors](/guides/development/guide-helping.html).

Keep up the contributions, you are a critical member of our 
community. If we like what we see, we may even ask you to 
consider taking a formal role in our project.

## Formal roles

### [Committers](http://www.apache.org/foundation/how-it-works.html#committers)

These are those people who have been given write access to the
Apache Maven code repository and have a signed 
[Contributor License Agreement (CLA)][4] on file with the ASF.

The Apache Maven project uses a Commit then Review policy and has
[a number of conventions][5] which should be followed.

Committers are responsible for ensuring that every file they 
commit is covered by a valid CLA. 

Committers who would like to become PMC members should try to find
ways to demonstrate the responsibilities listed in the PMC Members
section in order to make it easier for PMC members to decide
that the committer is ready for the responsibility.

### Emeritus committers

If a committer decides that they cannot currently continue with 
the responsibilities of a committer, they may elect to go 
emeritus. 

At any time, an emeritus committer for the Apache Maven project
may decide that they want to become an active committer again
by informing the [project management committee][3]. The current
policy is that committer role reinstatement is automatic.

### [Project Management Committee](http://www.apache.org/foundation/how-it-works.html#pmc-members)

The Project Management Committee as a whole is the entity that 
controls the project. Membership of the Project Management Committee 
is decided by the board of the Apache Software Foundation, based on
nominations from the Project Management Committee.

It is a long standing tradition of the Apache Maven Project that 
the Project Management Committee reviews the active committers
approximately every 6 months with a view to determining whether
any of those committers would be suitable candidates to 
recommend to the board for inclusion on the PMC. It should be
noted that this is simply a tradition and not a right. There
are significant responsibilities that accompany the PMC role
and as such, if a person is not demonstrating those responsibilities,
they may not be nominated or their nomination
may be rejected by the board. Such decisions are not a 
reflection of the technical competence of the person, and 
indeed the person themselves may even decide to turn down the 
nomination. For that reason the results of such periodic reviews
are kept confidential.

The Project Management Committee has the following responsibilities:

* Active management of those projects identified by the resolution of the Board
  of Directors of the Apache Foundation;
* Ensure the project remains a healthy top-level project of the Apache Foundation
  (if a PMC member wants the project to be hosted elsewhere they should resign
  from the PMC stating their reason - if the PMC shrinks beyond the minimal viable
  size then as a result of a desire by the bulk of the PMC to move the project 
  elsewhere, the Board of the Apache Foundation will take that into account
  when moving the project into the Foundation's Attic)
* Prepare reports as required by the Board of the Apache Foundation and
  ensure those reports are ready for presentation by the PMC Chair in a timely
  manner;
* Defend the trademarks belonging to the project;
* Proposing active contributors for committership;
* Ensure that votes in the community are used as a tool to establish consensus
  and not a weapon to disenfranchise or alienate a minority of the community;
* Binding votes in project decisions;
* Ensure that code committed to the project is either committed under a valid CLA
  or is code that was contributed with a clear indication that the Apache License
  applied (i.e. small patches submitted to the issue tracker or to the mailing list
  are assumed to be submitted with the intent of being covered by the Apache
  License unless the submitter clearly marks those patches as not being covered)
* Ensure that third party dependencies shipped as part of the project's releases
  are covered by a compatible license.
* Voting on release artifacts;
* Ensure [Developers Conventions][5] are followed, or updated/improved if necessary;
* Knows and respects the goals and processes of the community and helps educate 
  newer members about them.

#### Standards for Community Commitment

In the spirit of supporting the health of our community, Project
Management Committee members refrain from actions that subvert the
functioning of the committee itself.

#### Promotion of other projects

The Apache Foundation currently does not have a policy requiring projects to
cross-promote. For example Subversion is an Apache project, yet projects
are free to choose from Subversion and GIT (a non-Apache project) for source 
control.

When considering integration of technologies within Maven, there is
thus no requirement that other Apache projects be picked over non-Apache projects.

The primary requirements for picking technologies to integrate with Maven
are thus:

* A [compatible license][6], i.e. [Category A][7] or [Category B][8]
* A good technical fit
* A strong preference on behalf of the portion of the community that
  will be doing the integration.

Where a PMC member is advocating a specific technology, they should declare
any interest / involvement that they have in that technology or a competing 
technology - irrespective of whether the project is an Apache project or a 
project hosted elsewhere.

PMC members with a stated interest / involvement should try to abstain from 
making binding votes in either direction with respect to the relevant
technology choices.

#### Forks of the project codebase

All code that gets released by the community should have sufficient opportunity
for review both:

* By the PMC, to check the legal responsibilities delegated by
  the Board; and
* By the committers (which includes the PMC), to check that the technical
  direction and quality is in line with the consensus roadmap (where such a
  roadmap has been agreed).

It is self evident that the opportunity for review is much greater if the code
is committed to the project's source control as early as possible. Similarly
small commits are easier to review than large commits.

There is nothing inherently wrong with maintaining a fork of the Maven 
codebase outside of the Apache Foundation. Individual developers can have
their own style of working and may prefer to work in a fork so that they
can throw away failed experiments with less visibility (though it could be
argued that the visibility of such failed experiments can be valuable 
documentation for others). As soon as changes in that 
fork are identified (by the people maintaining the fork) which should be 
brought back to the project those changes should be introduced into at 
least a branch hosted on the Apache Maven source control in order to 
facilitate the easier review by the community. The PMC should encourage 
by example the early committing of such changes from a fork (that they 
are involved in maintaining)  back to Apache Maven source control. 

Similarly, if a fork is being hosted elsewhere in order to get contributions
from other talented individuals, the PMC members should endevour to bring
those individuals and their talent to the project as committers.

Finally, where a fork is hosted outside of Apache hardware, there is less
traceability of the code provenance, for example GIT commits can be squashed 
and history re-written to mask or otherwise hide the source of contributions.
This does not mean that code coming from an external fork inherently has
such issues, instead it means that the requirements for review and verification
of provenance grow exponentially when dealing with large sets of changes 
originating from a long running fork hosted outside of Apache foundation
source control. Anybody maintaining a long running fork should be aware
of the risk that review obligations may grow above the time capabilities
of the PMC and committers such that when they eventually decide to try and
bring the changes in their fork back to the Apache Maven project their 
contribution may end up being rejected on the basis of the review of a
large set of changes being too difficult/timeconsuming.

### [Project Management Chair](http://www.apache.org/foundation/how-it-works.html#pmc-chair)

For various legal reasons, there are certain things that the Apache 
Software Foundation can only delegate to an officer of the foundation.

The Project Management Committee is responsible for nominating
the lucky victim who gets made an officer of the foundation (subject 
to the approval of the board).

This person then becomes the interface between the board and
the project management committee. They do not have any other
additional gravitas in the project, it is the Project Management 
Committee as a whole that is responsible for the direction of the project.

If things break down and there is no consensus and there is no clear
ability to reach any conclusion *and* it is in the interest of the
foundation because damage is done and the board expects the chair
to act as an officier of the foundation and clean things up, then the chair
can act as an ultimate decision maker, however, by this point the
board of the foundation must already be well aware of the situation and
should be actively monitoring the chair.

  [1]: http://stackoverflow.com/questions/tagged/maven
  [2]: mailto:users@maven.apache.org
  [3]: mailto:private@maven.apache.org
  [4]: http://www.apache.org/licenses/#clas
  [5]: /developers/index.html#Developers_Conventions
  [6]: http://www.apache.org/legal/3party.html
  [7]: http://www.apache.org/legal/3party.html#category-a
  [8]: http://www.apache.org/legal/3party.html#category-b