- This document defines the bylaws under which the Apache Ant project operates. - It defines the the roles and responsibilities of the project, who may vote, - how conflicts are resolved, etc. -
+ This document defines the bylaws under which the Apache Ant project + operates. It defines the the roles and responsibilities of the + project, who may vote, how voting works, how conflicts are resolved, + etc. +- Ant is typical of Apache projects in that it operates under a set of principles, - known as the Apache Way. If you are new to Apache, please refer to the - Incubator project for more information on - how Apache projects operate. -
+ Ant is a project of the + Apache Software + Foundation. The foundation holds the copyright on Apache + code including the code in the Ant codebase. The + foundation FAQ + explains the operation and background of the foundation. + ++ Ant is typical of Apache projects in that it operates under a set of + principles, known collectively as the "Apache Way". If you are + new to Apache, please refer to the + Incubator project + for more information on how Apache projects operate. Note: the + incubator project has only been recently set up and does not yet explain + the Apache Way in great detail. +
+| Roles and Responsibilities |
+ Apache projects define a set of roles with associated rights and + responsibilities. These roles govern what tasks an individual may perform + within the project. The roles are defined in the the following sections +
+ +| + + 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 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. +
+| + + Developers + + |
+ All of the volunteers who are contributing time, code, documentation, + or resources to the Ant Project. A developer that makes sustained, + welcome contributions to the project may be invited to become a + Committer, though the exact timing of such invitations depends on many + factors. +
+| + + Committers + + |
+ The project's Committers are responsible for the project's technical + management. All committers have write access to the project's source + repositories. Committers may cast binding votes on any technical + discussion regarding the project. +
++ Committer access is by invitation only and must be approved by lazy + consensus of the active PMC members. A Committer is considered emeritus + by their own declaration or by not contributing in any form to the + project for over four months. An emeritus committer may request + reinstatement of commit access fromt he PMC. Such reinstatement is + subject to lazy consensus of active PMC members. Commit access can be + revoked by a unanimous vote of all the active PMC members (except the + committer in question if they are also a PMC member). +
++ All Apache committers are required to have a signed Contributor License + Agreement (CLA) on file with the Apache Software Foundation. There is a + Committer FAQ + which provides more details on the requirements for Committers +
++ A committer who makes a sustained contibution to the project may be + invited to become a member of the PMC. +
+| @@ -225,17 +325,18 @@ |
- The Project Management Committee (PMC) for Apache Ant was created by a resolution of the - board of the Apache Software Foundation (ASF)on 18th November 2002. The PMC is responsible - to the board and the ASF for the management and oversight of the Apache Ant codebase. - The responsibilites of the PMC include + The Project Management Committee (PMC) for Apache Ant was created by a + resolution of the board of the Apache + Software Foundation on 18th November 2002. The PMC is + responsible to the board and the ASF for the management and oversight + of the Apache Ant codebase. The responsibilites of the PMC include
- Membership of the PMC is by invitation only and must be approved by a consensus of active PMC members. - A PMC member is considered inactive by their own declaration or by not contributing in any form to the - project for over six months. An inactive member can become active again by reversing whichever condition - made them inactive (i.e., by reversing their earlier declaration or by once again contributing toward the - project's work). Membership can be revoked by an unanimous vote of all the active PMC members other - than the member in question. + Membership of the PMC is by invitation only and must be approved by a + lazy consensus of active PMC members. A PMC member is considered + "emeritus" by their own declaration or by not contributing in + any form to the project for over four months. An emeritus member may + request reinstatement to the PMC. Such reinstatement is subject to lazy + consensus of the active PMC members. Membership of the PMC can be + revoked by an unanimous vote of all the active PMC members other than + the member in question.
- 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 Ant) and has primary responsibility to the board for the - management of the projects within the scope of the Ant PMC. The chair reports to the board quarterly - on developments within the Ant project. The PMC may consider the position of PMC chair annually - and if supported by 3/4 Majority may recommend a new chair to the board. Ultimately, however, it is - the board's responsibility who to appoint as the PMC 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 Ant) and has primary responsibility to the board for the + management of the projects within the scope of the Ant PMC. The chair + reports to the board quarterly on developments within the Ant project. + The PMC may consider the position of PMC chair annually and if + supported by 3/4 Majority may recommend a new chair to the board. + Ultimately, however, it is the board's responsibility who to appoint as + the PMC chair.
-| Decision Making |
+ Within the Ant project, different types of decisions require different + forms of approval. For example, the + previous section describes + several decisions which require "lazy consensus" approval. This + section defines how voting is performed, the types of approvals, and which + types of decision require which type of approval. +
+| - Committers + Voting |
- The project's Committers are responsible for the project's technical management. All committers have - write access to the project's source repository. Committers may cast binding votes on any technical - discussion regarding the project. -
-- Membership as a Committer is by invitation only and must be approved by consensus of the active - PMC members. A Committer is considered inactive by their own declaration or by not contributing - in any form to the project for over six months. An inactive committer can become active again - by reversing whichever condition made them inactive (i.e., by reversing their earlier declaration - or by once again contributing toward the project's work). Commit access can be revoked by a - unanimous vote of all the active PMC members (except the member in question if they are a PMC member). + Decisions regarding the project are made by votes on the primary project + development mailing list (ant-dev@jakarta.apache.org). Where necessary, + PMC voting may take place on the private Ant PMC mailing list. + Votes are indicated by subject line starting with [VOTE]. Votes + may contain multiple items for approval and these should be clearly + separated. Voting is carried out by replying to the vote mail. Voting + may take four flavours
+| + +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 vetos must + contain an explanation of why the veto is appropriate. Vetos with + no explanation are void. + + | +
- All Apache committers are required to have a signed Contributor License Agreement (CLA) on file - with the Apache Software Foundation. + All participants in the Ant project are encouraged to show their + agreement with or against a particular action by voting. For technical + decisions, only the votes of active committers are binding. Non binding + votes are still useful for Committers to understand the perception of an + action in the wider Ant community. For PMC decisions, only the votes of + PMC members are binding.
- A committer who makes a sustained contibution to the project will usually be invited to become a member of - the PMC. + Voting can also be applied to changes made to the Ant codebase. These + typically take the form of a veto (-1) in reply to the commit message + sent when the commit is made.
| - Developers + Approvals |
- All of the volunteers who are contributing time, code, documentation, or resources to the - Ant Project. A developer that makes sustained, welcome contributions to the project for - over six months is usually invited to become a Committer, though the exact timing of - such invitations depends on many factors. + These are the types of approvals that can be sought. Different actions + require different types of approvals
+| + Consensus + | ++ + For this to pass, all voters with binding votes must vote and there + can be no binding vetos (-1). Consensus votes are rarely required + due to the impracticality of getting all eligible voters to cast a + vote. + + | +
| + Lazy Consensus + | ++ + Lazy consensus requires 3 binding +1 votes and no binding vetos. + + | +
| + Lazy Majority + | ++ + A lazy majority vote requires 3 binding +1 votes and more binding +1 + votes that -1 votes. + + | +
| + Lazy Approval + | ++ + An action with lazy approval is implicitly allowed unless a -1 vote + is received, at which time, depending on the type of action, either + Lazy Majority or Lazy consensus approval must be obtained. + + | +
| - Users + Vetos |
- 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. + A valid, binding veto cannot be overruled. If a veto is cast, it must be + accompanied by a valid reason explaining the reasons for the veto. The + validity of a veto, if challeneged, 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 veto, you + must lobby the person casting the veto to withdraw their veto. If a veto + is not withdrawn, the action that has been vetoed bust be reversed in a + timely manner.
-
- Users contribute to the Apache projects by providing feedback to developers in the 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.
+
+
+
| + + Actions + + |
+ This section describes the various actions which are undertaken within + the project, the correspnding approval required for that action and + those who have binding votes over the action.
+| + Action + | ++ Description + | ++ Approval + | ++ Binding Votes + | +
|---|---|---|---|
| + Codebase Change + | ++ + A change made to the main codebase of the project and committed + by a committer. This includes source code, documentation, website + content, etc. + + | ++ + Lazy Approval and then Lazy consensus. + + | ++ + Active committers. + + | +
| + Release Plan + | ++ + Defines the timetable and actions for a release. The plan also + nominates a Release Manager. + + | ++ + Lazy Majority + + | ++ + Active committers + + | +
| + Product Release + | ++ + When a release of one of the project's products is ready, a vote is + required to accept the release as an official release of the + Project. + + | ++ + Lazy Majority + + | ++ + Active PMC members + + | +
| + New Committer + | ++ + When a new committer is proposed for the project + + | ++ + Lazy consensus + + | ++ + Active PMC members + + | +
| + New PMC Member + | ++ + When a committer is proposed for the PMC + + | ++ + Lazy consensus + + | ++ + Active PMC members + + | +
+ This document defines the bylaws under which the Apache Ant project + operates. It defines the the roles and responsibilities of the + project, who may vote, how voting works, how conflicts are resolved, + etc. +
+ ++ Ant is a project of the + Apache Software + Foundation. The foundation holds the copyright on Apache + code including the code in the Ant codebase. The + foundation FAQ + explains the operation and background of the foundation. +
+ ++ Ant is typical of Apache projects in that it operates under a set of + principles, known collectively as the "Apache Way". If you are + new to Apache, please refer to the + Incubator project + for more information on how Apache projects operate. Note: the + incubator project has only been recently set up and does not yet explain + the Apache Way in great detail. +
+ + + +- This document defines the bylaws under which the Apache Ant project operates. - It defines the the roles and responsibilities of the project, who may vote, - how conflicts are resolved, etc. -
++ Apache projects define a set of roles with associated rights and + responsibilities. These roles govern what tasks an individual may perform + within the project. The roles are defined in the the following sections +
-- Ant is typical of Apache projects in that it operates under a set of principles, - known as the Apache Way. If you are new to Apache, please refer to the - Incubator project for more information on - how Apache projects operate. -
+ + ++ 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 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. +
-+ All of the volunteers who are contributing time, code, documentation, + or resources to the Ant Project. A developer that makes sustained, + welcome contributions to the project may be invited to become a + Committer, though the exact timing of such invitations depends on many + factors. +
++ The project's Committers are responsible for the project's technical + management. All committers have write access to the project's source + repositories. Committers may cast binding votes on any technical + discussion regarding the project. +
+ ++ Committer access is by invitation only and must be approved by lazy + consensus of the active PMC members. A Committer is considered emeritus + by their own declaration or by not contributing in any form to the + project for over four months. An emeritus committer may request + reinstatement of commit access fromt he PMC. Such reinstatement is + subject to lazy consensus of active PMC members. Commit access can be + revoked by a unanimous vote of all the active PMC members (except the + committer in question if they are also a PMC member). +
+ ++ All Apache committers are required to have a signed Contributor License + Agreement (CLA) on file with the Apache Software Foundation. There is a + Committer FAQ + which provides more details on the requirements for Committers +
+ ++ A committer who makes a sustained contibution to the project may be + invited to become a member of the PMC. +
+- The Project Management Committee (PMC) for Apache Ant was created by a resolution of the - board of the Apache Software Foundation (ASF)on 18th November 2002. The PMC is responsible - to the board and the ASF for the management and oversight of the Apache Ant codebase. - The responsibilites of the PMC include + The Project Management Committee (PMC) for Apache Ant was created by a + resolution of the board of the Apache + Software Foundation on 18th November 2002. The PMC is + responsible to the board and the ASF for the management and oversight + of the Apache Ant codebase. The responsibilites of the PMC include
- Membership of the PMC is by invitation only and must be approved by a consensus of active PMC members. - A PMC member is considered inactive by their own declaration or by not contributing in any form to the - project for over six months. An inactive member can become active again by reversing whichever condition - made them inactive (i.e., by reversing their earlier declaration or by once again contributing toward the - project's work). Membership can be revoked by an unanimous vote of all the active PMC members other - than the member in question. + Membership of the PMC is by invitation only and must be approved by a + lazy consensus of active PMC members. A PMC member is considered + "emeritus" by their own declaration or by not contributing in + any form to the project for over four months. An emeritus member may + request reinstatement to the PMC. Such reinstatement is subject to lazy + consensus of the active PMC members. Membership of the PMC can be + revoked by an unanimous vote of all the active PMC members other than + the member in question.
- 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 Ant) and has primary responsibility to the board for the - management of the projects within the scope of the Ant PMC. The chair reports to the board quarterly - on developments within the Ant project. The PMC may consider the position of PMC chair annually - and if supported by 3/4 Majority may recommend a new chair to the board. Ultimately, however, it is - the board's responsibility who to appoint as the PMC 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 Ant) and has primary responsibility to the board for the + management of the projects within the scope of the Ant PMC. The chair + reports to the board quarterly on developments within the Ant project. + The PMC may consider the position of PMC chair annually and if + supported by 3/4 Majority may recommend a new chair to the board. + Ultimately, however, it is the board's responsibility who to appoint as + the PMC chair.
- The project's Committers are responsible for the project's technical management. All committers have - write access to the project's source repository. Committers may cast binding votes on any technical - discussion regarding the project. -
++ Within the Ant project, different types of decisions require different + forms of approval. For example, the + previous section describes + several decisions which require "lazy consensus" approval. This + section defines how voting is performed, the types of approvals, and which + types of decision require which type of approval. +
+- Membership as a Committer is by invitation only and must be approved by consensus of the active - PMC members. A Committer is considered inactive by their own declaration or by not contributing - in any form to the project for over six months. An inactive committer can become active again - by reversing whichever condition made them inactive (i.e., by reversing their earlier declaration - or by once again contributing toward the project's work). Commit access can be revoked by a - unanimous vote of all the active PMC members (except the member in question if they are a PMC member). + Decisions regarding the project are made by votes on the primary project + development mailing list (ant-dev@jakarta.apache.org). Where necessary, + PMC voting may take place on the private Ant PMC mailing list. + Votes are indicated by subject line starting with [VOTE]. Votes + may contain multiple items for approval and these should be clearly + separated. Voting is carried out by replying to the vote mail. Voting + may take four flavours
+| +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 vetos must + contain an explanation of why the veto is appropriate. Vetos with + no explanation are void. + | +
- All Apache committers are required to have a signed Contributor License Agreement (CLA) on file - with the Apache Software Foundation. + All participants in the Ant project are encouraged to show their + agreement with or against a particular action by voting. For technical + decisions, only the votes of active committers are binding. Non binding + votes are still useful for Committers to understand the perception of an + action in the wider Ant community. For PMC decisions, only the votes of + PMC members are binding.
- +- A committer who makes a sustained contibution to the project will usually be invited to become a member of - the PMC. + Voting can also be applied to changes made to the Ant codebase. These + typically take the form of a veto (-1) in reply to the commit message + sent when the commit is made.
- All of the volunteers who are contributing time, code, documentation, or resources to the - Ant Project. A developer that makes sustained, welcome contributions to the project for - over six months is usually invited to become a Committer, though the exact timing of - such invitations depends on many factors. + These are the types of approvals that can be sought. Different actions + require different types of approvals
+ +| Consensus | ++ For this to pass, all voters with binding votes must vote and there + can be no binding vetos (-1). Consensus votes are rarely required + due to the impracticality of getting all eligible voters to cast a + vote. + | +
| Lazy Consensus | ++ Lazy consensus requires 3 binding +1 votes and no binding vetos. + | +
| Lazy Majority | ++ A lazy majority vote requires 3 binding +1 votes and more binding +1 + votes that -1 votes. + | +
| Lazy Approval | ++ An action with lazy approval is implicitly allowed unless a -1 vote + is received, at which time, depending on the type of action, either + Lazy Majority or Lazy consensus approval must be obtained. + | +
- 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. + A valid, binding veto cannot be overruled. If a veto is cast, it must be + accompanied by a valid reason explaining the reasons for the veto. The + validity of a veto, if challeneged, 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 veto, you + must lobby the person casting the veto to withdraw their veto. If a veto + is not withdrawn, the action that has been vetoed bust be reversed in a + timely manner.
- +- Users contribute to the Apache projects by providing feedback to developers in the 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. + This section describes the various actions which are undertaken within + the project, the correspnding approval required for that action and + those who have binding votes over the action.
- + +| Action | +Description | +Approval | +Binding Votes | +
|---|---|---|---|
| Codebase Change | ++ A change made to the main codebase of the project and committed + by a committer. This includes source code, documentation, website + content, etc. + | ++ Lazy Approval and then Lazy consensus. + | ++ Active committers. + | +
| Release Plan | ++ Defines the timetable and actions for a release. The plan also + nominates a Release Manager. + | ++ Lazy Majority + | ++ Active committers + | +
| Product Release | ++ When a release of one of the project's products is ready, a vote is + required to accept the release as an official release of the + Project. + | ++ Lazy Majority + | ++ Active PMC members + | +
| New Committer | ++ When a new committer is proposed for the project + | ++ Lazy consensus + | ++ Active PMC members + | +
| New PMC Member | ++ When a committer is proposed for the PMC + | ++ Lazy consensus + | ++ Active PMC members + | +