Return-Path:
- The roles and responsibilities that people can assume in - the project - are based on merit. Everybody can help no matter what - their role. - Those who have been longterm or valuable contributors to - the project - can earn the right to commit directly to the source - repository and to - cast binding votes during the decision-making process. -
- -- Users. - Users are the people who use the products of the Project. - People in - this role aren't contributing code, but they are using the - products, - reporting bugs, making feature requests, and such. This is - by far - the most important category of people as, without users, - there is no - reason for the Project. When a user starts to contribute - code or - documentation patches, they become a Contributor. -
- -- Contributors. - Contributors are the people who write code or - documentation patches or - contribute positively to the project in other ways. When a - volunteer's - patch is applied, the contribution is recognized in the - version control - log. -
- -- Committers. - Contributors who give frequent and valuable contributions - to a - subproject of the Project can have their status promoted - to that of - a " - Committer - " for that subproject. A Committer - has write access to the source code repository. Committer - status is - granted by the Project Management Committee by majority - vote. -
- -- Project Management Committee (PMC). - Committers and other volunteers who frequently participate - with - valuable contributions may have their status promoted to - that of a - " - Project Management Committee Member - ". The PMC - is responsible for the day-to-day management of the - Project. -
- -+ The Project Charter incorporates by reference + the current version of + + How the ASF works, with the additional guidelines + and clarifications found herein. +
- All Volunteers are encouraged to participate in decisions, - but the - decision itself is made by the Project Management + All + Volunteers + (Users, Developers, Committers, PMC Members) are encouraged to + participate in the + decision-making process, but binding + decisions are made only by the Project Management Committee. - The Project is a " - Minimum Threshold Meritocracy - ".
- Any subscriber to the list may vote on any issue or action - item. - Votes from Contributors and Committers are especially + Any subscriber to the list may + vote + on any issue or action item. + Votes from Developers and Committers are especially welcome. However, the only binding votes are those cast by a PMC Member.
-- The act of voting carries certain obligations. Voters are - not only - stating their opinion, they are also agreeing to help do - the work. -
- -Each vote can be made in one of three flavors:
- -- +1 - | -- "Yes," "Agree," or "the - action should be - performed." On some issues this is only - binding if the voter - has tested the action on their own system(s). - | -
- +/-0 - | -- "Abstain," "no opinion". An - abstention may - have detrimental effects if too many people - abstain. - | -
- -1 - | -
- - "No." On issues where consensus is - required, this vote - counts as a - veto - . All vetos must contain an - explanation of why the veto is appropriate. - Vetos with no - explanation are void. A veto cannot be - overruled. If you disagree - with the veto, you should lobby the person who - cast the veto. - Voters intending to veto an action item should - make their opinions - known to the group immediately so that the - problem can be remedied - as early as possible. - -- If a Committer tries to "override" a veto by - restoring a vetoed - change, the PMC may ask the infrastructure - group to revoke that - Committer's write privileges. - - |
-
- An action requiring consensus approval must receive at - least - 3 binding +1 - votes and - no binding - vetos - . An action requiring majority approval must receive - at least - 3 binding +1 - votes and more - +1 - votes than - -1 - votes. All other - action items are considered to have lazy approval until - somebody - votes - -1 - , after which point they are decided by - either consensus or majority vote, depending on the type - of action - item. -
-- Voting represent consensus and votes are never final. - Circumstances - change, and so may votes. A veto may be converted to a +1 - after - discussion, and likewise a +1 may be converted to a -1. - By convention, Committers should allow a vote to circulate - for 72 - hours before taking action. -
Showstoppers are issues that require a fix be in place before the - next public release. They are listed in the status file in - order to + next public release. They are designated as "blockers" in + the issue tracker in order to focus special attention on these problems. An issue becomes a - showstopper when it is listed as such in the status file - and remains + showstopper when it is designated as such in the issue tracker + by a PMC member and remains so by lazy consensus.
@@ -403,8 +239,9 @@ other assorted information to keep volunteers from tripping over each other. A release - plan must be announced to the DEV list. Lazy majority - decides each issue + plan must be incorporated into the product documentation, + or otherwise announced to the DEV list. + Lazy majority decides each issue in a release plan. @@ -429,10 +266,39 @@+ Pursuant to the + "Rules for Revolutionaries", + any committer may submit experimental material to the Sandbox area + of the repository at his or her own discretion. +
+ ++ Material must be moved from the sandbox to the main repository before + it can be released. +
+ ++ If a sandbox whiteboard becomes dormant for six or more months, + it may be moved to the archive section of the repository. +
+ ++ Experimental material that is outside the scope of the Struts project + may also be submitted to the + Apache Labs. +
+ + +Next: - Volunteers + Project Minutes
- For more about volunteers at the ASF, visit - - people.apache.org. -
Next: - Our Blogs + Volunteers