Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jclouds Wiki" for change notification.
The "Bylaws" page has been changed by AndrewPhillips: https://wiki.apache.org/jclouds/Bylaws?action=diff&rev1=2&rev2=3 Comment: Changes based on "[DISCUSS] Proposed project bylaws" thread === 2.4.4. === "Active PMC members" are all non-emeritus PMC members. - === 2.4.4. === + === 2.4.5. === 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 jclouds) and has primary responsibility to the board for the management of the projects within the scope of the jclouds PMC. The chair reports to the board quarterly on developments within the jclouds project. The chair must be an active PMC member. - === 2.4.5. === + === 2.4.6. === If the current chair of the PMC resigns, or the term of the current chair expires, the PMC will attempt to reach consensus on a new chair through discussion, confirming that consensus via a vote to recommend a new chair using a lazy 2/3 majority voting method. In the case that consensus is not achieved, the PMC will vote for a chair using Single Transferable Vote (STV) voting. Due to the fact that the discussions are about specific individuals, this vote would be held on the jclouds-private mailing list. The decision must be ratified by the Apache board. - === 2.4.6. === + === 2.4.7. === The role of PMC chair will have a one year term. The intention of this term is to allow for a rotation of the role amongst the PMC members. This intention does not prohibit the PMC from selecting the same chair to serve consecutive terms. = 3. Decision Making = @@ -92, +92 @@ Voting may take four flavors: ==== 3.1.2.1. ==== - +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" + +1 "Yes," "Agree," or "the action should be performed." In general, this vote also indicates a willingness on the behalf of the voter to be approached for help in "making it happen". ==== 3.1.2.2. ==== - +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 a willingness for the action under consideration to go ahead. The voter, however, will not take an active role in that process. ==== 3.1.2.3. ==== -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. ==== 3.1.2.4. ==== - -1 This is a negative vote. On issues where consensus is required, this vote counts as a veto if binding. 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. + -1 This is a negative vote. On issues where consensus is required, this vote counts as a veto if valid (see 3.3.2) and binding. It may also be appropriate for a -1 vote to include an alternative course of action. === 3.1.3. === - All participants in the jclouds 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 those with binding votes to understand the perception of an action in the wider jclouds community. For PMC decisions, only the votes of PMC members are binding. + All participants in the jclouds project are encouraged to show their agreement with or against a particular action by voting. For technical decisions, only 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 jclouds community. For PMC decisions, only the votes of PMC members are binding. === 3.1.4. === Voting can also be applied to changes made to the jclouds codebase. These typically take the form of a veto (-1) in reply to the commit message sent when the commit is made. @@ -130, +130 @@ Vetoes are only possible in a lazy consensus vote. === 3.3.2. === - 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 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. + 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. Vetoes with no explanation are void. 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. === 3.3.3. === 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. @@ -145, +145 @@ During the consensus gathering process, technical decisions may be vetoed by any Committer with a valid reason. - If a formal vote is started for a technical decision, the vote will be held as a lazy consensus of active committers. + If a formal vote is started for a technical decision, the vote will be held as a lazy consensus of committers. Any user, contributor, committer or PMC member can initiate a technical desicion making process. === 3.4.2. Release Plan === Defines the timetable and work items for a release. The plan also nominates a Release Manager. - A lazy majority of active committers is required for approval. + A lazy majority of committers is required for approval. - Any active committer or PMC member may call a vote. The vote must occur on a project development mailing list. + Any committer or PMC member may call a vote. The vote must occur on a project development mailing list. === 3.4.3. 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 of active PMC members is required for approval. - Any active committer or PMC member may call a vote. The vote must occur on a project development mailing list. + Any committer or PMC member may call a vote. The vote must occur on a project development mailing list. === 3.4.4. Adoption of New Codebase === When the codebase for an existing, released product is to be replaced with an alternative codebase. If such a vote fails to gain approval, the existing code base will continue. @@ -170, +170 @@ Lazy 2/3 majority of active PMC members. - Any active committer or PMC member may call a vote. The vote must occur on a project development mailing list. + Any committer or PMC member may call a vote. The vote must occur on a project development mailing list. === 3.4.5. New Committer === When a new committer is proposed for the project. @@ -205, +205 @@ Lazy majority of active PMC members - Any active committer or PMC member may call a vote. The vote must occur on a project development mailing list. + Any committer or PMC member may call a vote. The vote must occur on a project development mailing list. === 3.5. Voting Timeframes === Formal votes are open for a period of at least 72 hours to allow all active voters time to consider the vote.
