Page History

{lozenge:title=Roles and Responsibilities|width=100%|icon=!Users 3 48x48.png!}
Apache projects define a set of roles with associated rights and responsibilities. These roles govern what tasks an individual may perform within the project.
{lozenge}

h2. {color:#2d5291}Users{color}

The most important participants in the project are people who use our software. The majority of our developers start out as users and guide their development efforts from the user's perspective.

Users contribute to the Apache projects by providing feedback to developers in the form of bug reports and feature suggestions. As well, users participate in the Apache community by helping other users on mailing lists and user support forums.
\\

h2. {color:#2d5291}Contributors{color}

All of the volunteers who are contributing time, code, documentation, or resources to the Apache Flex Project. A contributor that makes sustained, useful contributions to the project may be invited to become a Committer.
\\

h2. {color:#2d5291}Committers{color}

The project's Committers are responsible for the project's technical management. Committers have write access to the projects source code repositories.

The responsibilities of an committer include:
* Upholding and promoting the Apache Way
* Helping out users
* Reviewing code check ins
* Testing releases
* Maintaining the project's shared resources, including the repository, mailing lists and website

It is up to each individual committer exactly where they focus their attention and how how much time they spend on the project.

Committer access is by invitation only and must be approved by Consensus of the PMC members.

All Apache committers are required to have a signed Contributor License Agreement (CLA) on file with the Apache Software Foundation.

Any committer can make a release candidate and call for a vote on making it an official release.

The forms of contribution are not limited to only code. It can also include code reviews, helping out users on the mailing lists, documentation, testing, etc.

A committer is considered inactive by their own declaration and can rejoin at any time.

Committers can veto code check ins but committers votes are not binding on releases.

A committer who makes a sustained contribution to the project may be invited to become a member of the PMC.
\\

h2. {color:#2d5291}Release Manager{color}

A Release Manager (RM) is a committer who volunteers to produce a Release Candidate.

The RM is responsible for building consensus around the content of the Release Candidate, in order to achieve a successful Product Release vote.
\\

h2. {color:#2d5291}Project Management Committee{color}

The Project Management Committee (PMC) for Apache Flex was created by the Apache Board. In December 2012 Apache Flex became a top level project at Apache.

The PMC is responsible to the board and the ASF for the management and oversight of the Apache Flex project.

The responsibilities of the PMC include:
* Upholding and promoting the Apache Way
* Deciding what is in a release
* Voting on releases
* Maintaining the project's shared resources, including the repository, mailing lists and website
* Speaking on behalf of the project
* Resolving any disputes (licensing or otherwise)
* Nominating new PMC members and committers
* Maintaining these guidelines of the project

Membership of the PMC is by invitation only and must be approved by Consensus of PMC members.

A PMC member is considered inactive by their own declaration and they can rejoin at any time.
\\

h2. {color:#2d5291}Chair{color}

The chair of the PMC is appointed by the ASF board. The chair is an office holder of the Apache Software Foundation (Vice President, Apache Flex) and has primary responsibility to the board for the management of the projects within the scope of the Apache Flex PMC. The chair reports to the board quarterly on developments within the project.

The term of chair is for one one year or until they retire. After one year the chair can elect to stand for another year or a vote by the PMC be taken for a new chair.

Users

The most important participants in the project are people who use our software. The majority of our developers start out as users and guide their development efforts from the user's perspective.

Users contribute to the Apache projects by providing feedback to developers in the form of bug reports and feature suggestions. As well, users participate in the Apache community by helping other users on mailing lists and user support forums.

Contributors

All of the volunteers who are contributing time, code, documentation, or resources to the Apache Flex Project. A contributor that makes sustained, useful contributions to the project may be invited to become a Committer.

Committers

The project's Committers are responsible for the project's technical management. Committers have write access to the projects source code repositories.

The responsibilities of an committer include:

• Upholding and promoting the Apache Way
• Helping out users
• Reviewing code check ins
• Testing releases
• Maintaining the project's shared resources, including the repository, mailing lists and website

It is up to each individual committer exactly where they focus their attention and how how much time they spend on the project.

Committer access is by invitation only and must be approved by Consensus of the PMC members.

All Apache committers are required to have a signed Contributor License Agreement (CLA) on file with the Apache Software Foundation.

Any committer can make a release candidate and call for a vote on making it an official release.

The forms of contribution are not limited to only code. It can also include code reviews, helping out users on the mailing lists, documentation, testing, etc.

A committer is considered inactive by their own declaration and can rejoin at any time.

Committers can veto code check ins but committers votes are not binding on releases.

A committer who makes a sustained contribution to the project may be invited to become a member of the PMC.

Release Manager

A Release Manager (RM) is a committer who volunteers to produce a Release Candidate.

The RM is responsible for building consensus around the content of the Release Candidate, in order to achieve a successful Product Release vote.

Project Management Committee

The Project Management Committee (PMC) for Apache Flex was created by the Apache Board. In December 2012 Apache Flex became a top level project at Apache.

The PMC is responsible to the board and the ASF for the management and oversight of the Apache Flex project.

The responsibilities of the PMC include:

• Upholding and promoting the Apache Way
• Deciding what is in a release
• Voting on releases
• Maintaining the project's shared resources, including the repository, mailing lists and website
• Speaking on behalf of the project
• Resolving any disputes (licensing or otherwise)
• Nominating new PMC members and committers
• Maintaining these guidelines of the project

Membership of the PMC is by invitation only and must be approved by Consensus of PMC members.

A PMC member is considered inactive by their own declaration and they can rejoin at any time.

Chair

The chair of the PMC is appointed by the ASF board. The chair is an office holder of the Apache Software Foundation (Vice President, Apache Flex) and has primary responsibility to the board for the management of the projects within the scope of the Apache Flex PMC. The chair reports to the board quarterly on developments within the project.

The term of chair is for one one year or until they retire. After one year the chair can elect to stand for another year or a vote by the PMC be taken for a new chair.

{lozenge:title=Decision Making|width=100%|icon=!Decision Arrows 3 way 48x48.png!}
Within the Apache Flex project, different types of decisions require different forms of approval. This section defines how voting is performed, the types of approvals, and which types of decision require which type of approval.
{lozenge}

h2. {color:#2d5291}Voting{color}

Decisions regarding the project are made by votes on the primary project development mailing list 

Voting

Decisions regarding the project are made by votes on the primary project development mailing list (dev@flex.apache.org).

Where

necessary,

PMC

voting

may

take

place

on

the

private

Apache

Flex

PMC

mailing

list.

Votes

are

clearly

indicated

by

subject

line

starting

with

[VOTE

].

The

vote

email

should

indicate

the

voting

approval

type

(Consensus,

Lazy

Consensus,

Majority

Approval

or

2/3rds

Majority

Approval)

and

that

should

follow

what

is

in

these

guidelines.

If

the

voting

approval

type

is

not

specified

and

is

not

covered

by

these

guidelines

it

defaults

to

Consensus.

Voting

is

carried

out

by

replying

to

the

vote

mail.

Voting

may

take

four

flavors:

• +1

• "Yes,"

• "Agree,"

• or

• "the

• action

• should

• be

• performed."

• In

• general,

• this

• vote

• also

• indicates

• a

• willingness

• on

• the

• behalf

• of

• the

• voter

• in

• "making

• it

• happen".

• +0

• This

• vote

• indicates

• a

• willingness

• for

• the

• action

• under

• consideration

• to

• go

• ahead.

• The

• voter,

• however

• will

• not

• be

• able

• to

• help.

• -0

• This

• vote

• indicates

• that

• the

• voter

• does

• not,

• in

• general,

• agree

• with

• the

• proposed

• action

• but

• is

• not

• concerned

• enough

• to

• prevent

• the

• action

• going

• ahead.

• -1

• This

• is

• a

• negative

• vote.

• On

• issues

• where

• consensus

• is

• required,

• this

• vote

• counts

• as

• a

• veto.

• All

• vetoes

• must

• contain

• an

• explanation

• of

• why

• the

• veto

• is

• appropriate.

• Vetoes

• with

• no

• explanation

• are

• void.

• It

• may

• also

• be

• appropriate

• for

• a

• -1

• vote

• to

• include

• an

• alternative

• course

• of

• action.

You

can

also

vote

in

fractions

to

indicate

the

strength

of

the

vote,

for

example

by

voting

+0.5,

-0.5,

+0,

-0

etc

etc.

Only

a

full

-1

is

considered

a

veto

and

releases

and

consensus

require

3

full

+1

votes.

All

participants,

not

just

committers

and

PMC

members,

in

the

Flex

project

are

encouraged

to

show

their

agreement

with

or

against

a

particular

action

by

voting.

For

technical

decisions

(but

not

releases),

the

votes

of

committers

are

binding.

Non

binding

votes

are

still

useful

for

those

with

binding

votes

to

understand

the

perception

of

an

action

in

the

wider

community.

For

PMC

decisions,

only

the

votes

of

PMC

members

are

binding.

Changes

made

to

the

Apache

Flex

codebase

are

made

on

a

Commit-then-review

basis.

Any

change

may

be

reverted

by

a

veto

(-1)

in

reply

to

the

commit

message

sent

when

the

commit

is

made.

Voting timeframes

Voting is open for 72 hours unless otherwise specified. When voting on release candidates the release manager at their discretion can carry over votes from the previous release candidate if there are minimal changes between release candidates. This should be indicated in the new release candidate vote.

If 72 hours pass and there's not enough votes for a resolution voting continues until cancelled or until there are enough votes for a resolution.

Cancelling Votes

A vote may be cancelled by the person who started the vote by sending an email with the subject line [VOTE][CANCEL] to the mailing list.

Vote Results

Once a vote has been taken and the required timeframe has elapsed an email should be sent to the list with results of the vote and whether the vote passed or failed with a subject line of [VOTE][RESULT].

Changing Your Vote

Anyone can change their vote until the required voting timeframe has passed and the results have been announced. Only a person's last vote counts in any total.

Approvals

These are the types of approvals that can be sought. Different actions require different types of approvals

• Consensus Approval - Consensus approval requires 3 binding +1 votes and no binding vetoes.
• Lazy Consensus - Lazy consensus requires no -1 binding votes ('silence gives assent').
• Majority Approval - A majority approval vote requires 3 binding +1 votes and more binding +1 votes than -1 votes.
• 2/3rds Majority Approval - A 2/3rds majority approval vote requires at least 3 +1 binding votes and twice as many +1 binding votes as -1 votes.

Majority Approval and 2/3 Majority Approval is based on the number of votes cast, not on the number of eligible voters.

Vetoes

A valid, binding veto cannot be overruled. A veto is only valid if it is accompanied by an explanation. The validity of a veto, if challenged, can be confirmed by anyone who has a binding vote. This does not necessarily signify agreement with the veto - merely that the veto is valid.

If you disagree with a valid veto, you must lobby the person casting the veto to withdraw their veto. If a veto is not withdrawn, any action that has been vetoed must be reversed in a timely manner.

Majority votes can not be vetoed.

{lozenge:title=Actions|width=100%|icon=!Gear 48x48.png!}
This section describes the various actions which are undertaken within the project, the corresponding approval required for that action and those who have binding votes over the action.
{lozenge}

h2. {color:#2d5291}Code Change{color}

A change made to a codebase of the project and committed by a committer. This includes source code, documentation, website content, etc.

* Lazy Consensus of committers.

* There is no need for a formal vote. All code changes are commit then review so there's no waiting period of approval. A code change can be vetoed with a \-1 vote by any other committer by replying to the commit email.
\\

h2. {color:#2d5291}Product Release{color}

When a release candidate of one of the project's products is ready, a vote is required to accept the release candidate as an official release of the project.

* Majority Approval of PMC members.

* The release manager can carry over of votes from previous release candidates to the new release candidate if there are minimal changes between release candidates.
\\

h2. {color:#2d5291}New Committer{color}

When a new committer is proposed for the project.

* Consensus of PMC members.
\\

h2. {color:#2d5291}New PMC Member{color}

When a committer is proposed for the PMC.

* Consensus of PMC members.
\\

h2. {color:#2d5291}New PMC Chair{color}

When the Chair resigns or term has come up.

* Consensus of PMC members.
\\

h2. {color:#2d5291}Committer Removal{color}

When removal of commit privileges is sought. Note: Such actions will also be referred to the ASF board by the PMC chair.

* 2/3rds Majority Approval of PMC members (excluding the committer in question if a member of the PMC).
\\

h2. {color:#2d5291}PMC Member Removal{color}

When removal of a PMC member is sought. Note: Such actions will also be referred to the ASF board by the PMC chair.

* 2/3rds Majority Approval of PMC members (excluding the person in question if a member of the PMC).
\\

h2. {color:#2d5291}PMC Chair Removal{color}

The chair can be removed by the ASF board.
\\

h2. {color:#2d5291}Modifying Bylaws{color}

Modifying this document.

* 2/3rds Majority Approval of PMC members.

Code Change

A change made to a codebase of the project and committed by a committer. This includes source code, documentation, website content, etc.

• Lazy Consensus of committers.

• There is no need for a formal vote. All code changes are commit then review so there's no waiting period of approval. A code change can be vetoed with a -1 vote by any other committer by replying to the commit email.
  

Product Release

When a release candidate of one of the project's products is ready, a vote is required to accept the release candidate as an official release of the project.

• Majority Approval of PMC members.

• The release manager can carry over of votes from previous release candidates to the new release candidate if there are minimal changes between release candidates.
  

New Committer

When a new committer is proposed for the project.

• Consensus of PMC members.
  

New PMC Member

When a committer is proposed for the PMC.

• Consensus of PMC members.
  

New PMC Chair

When the Chair resigns or term has come up.

• Consensus of PMC members.
  

Committer Removal

When removal of commit privileges is sought. Note: Such actions will also be referred to the ASF board by the PMC chair.

• 2/3rds Majority Approval of PMC members (excluding the committer in question if a member of the PMC).
  

PMC Member Removal

When removal of a PMC member is sought. Note: Such actions will also be referred to the ASF board by the PMC chair.

• 2/3rds Majority Approval of PMC members (excluding the person in question if a member of the PMC).
  

PMC Chair Removal

The chair can be removed by the ASF board.

Modifying Bylaws

Modifying this document.

• 2/3rds Majority Approval of PMC members.