keith-turner commented on code in PR #431: URL: https://github.com/apache/accumulo-website/pull/431#discussion_r1688771814
########## contributor/bylaws.md: ########## @@ -154,162 +140,88 @@ An Accumulo release manager is also expected to: * ensure that required release testing is being conducted * track whether the release is on target for its expected release date * adjust release plan dates to reflect the latest estimates -* determine if a re-plan may be needed and, if so, call a vote -* call votes on release candidates +* terminate a release vote by either withdrawing a release candidate from consideration, if needed +* tally the votes and record the vote result after a release vote period has elapsed +* ensure any post-release tasks are performed, such as updating the website and publishing artifacts Details on [making][making] and [verifying][verifying] a release are available on the Accumulo website. # Decision Making Within the Accumulo project, different types of decisions require different -forms of approval. For example, the previous section describes several -decisions which require 'consensus approval'. This section defines how voting -is performed, the types of approvals, and which types of decision require which -type of approval. +forms of approval. For example, the previous section describes 'consensus' from +the existing PMC members. Consensus in that case can be achieved through a +[consensus approval vote][consensus]. ## Voting Decisions regarding the project are made by votes on the primary project development mailing list: [email protected]. Where necessary, PMC voting may take place on the private Accumulo PMC mailing list: [email protected]. Votes are clearly indicated by a subject line -starting with [VOTE]. A vote message may only pertain to a single item’s -approval; multiple items should be separated into multiple messages. Voting is -carried out by replying to the vote mail. A vote may take on one of four forms, -defined below. - -{: .table } -| Vote | Meaning | -|------|---------| -| +1 | *Yes*, *Agree*, or *The action should be performed*. In general, this vote also indicates a willingness on the behalf of the voter to *make 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 | *No*, *Disagree*, or *The action should not be performed*. 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. | - -All participants in the Accumulo project are encouraged to vote. 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 across the wider Accumulo community. For PMC decisions, only the -votes of active PMC members are binding. - -See the [voting page][voting] for more details on the mechanics of voting. +starting with `[VOTE]`. After the vote period has elapsed, the initiator of the +vote, or their designee, closes it by replying to the thread with the results +of the vote. That result email should use the same subject line preceded by +`[RESULT][VOTE]`. Voting is carried out by replying to the vote mail and +continues until the vote is closed. If a vote thread becomes inactive and +remains open for too long, without a response from the initiator, the PMC Chair +may close the vote. + +All participants in the Accumulo project are encouraged to vote. However, some +votes are considered non-binding (such as votes from non-PMC members during a +release vote). However, non-binding votes are still useful to gain insight into +the community's view of the vote topic. Review Comment: ```suggestion All participants in the Accumulo project are encouraged to vote. However, some votes are non-binding (such as votes from non-PMC members during a release vote). Non-binding votes are still useful to gain insight into the community's view of the vote topic. ``` ########## contributor/bylaws.md: ########## @@ -154,162 +140,88 @@ An Accumulo release manager is also expected to: * ensure that required release testing is being conducted * track whether the release is on target for its expected release date * adjust release plan dates to reflect the latest estimates -* determine if a re-plan may be needed and, if so, call a vote -* call votes on release candidates +* terminate a release vote by either withdrawing a release candidate from consideration, if needed +* tally the votes and record the vote result after a release vote period has elapsed +* ensure any post-release tasks are performed, such as updating the website and publishing artifacts Details on [making][making] and [verifying][verifying] a release are available on the Accumulo website. # Decision Making Within the Accumulo project, different types of decisions require different -forms of approval. For example, the previous section describes several -decisions which require 'consensus approval'. This section defines how voting -is performed, the types of approvals, and which types of decision require which -type of approval. +forms of approval. For example, the previous section describes 'consensus' from +the existing PMC members. Consensus in that case can be achieved through a +[consensus approval vote][consensus]. ## Voting Decisions regarding the project are made by votes on the primary project development mailing list: [email protected]. Where necessary, PMC voting may take place on the private Accumulo PMC mailing list: [email protected]. Votes are clearly indicated by a subject line -starting with [VOTE]. A vote message may only pertain to a single item’s -approval; multiple items should be separated into multiple messages. Voting is -carried out by replying to the vote mail. A vote may take on one of four forms, -defined below. - -{: .table } -| Vote | Meaning | -|------|---------| -| +1 | *Yes*, *Agree*, or *The action should be performed*. In general, this vote also indicates a willingness on the behalf of the voter to *make 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 | *No*, *Disagree*, or *The action should not be performed*. 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. | - -All participants in the Accumulo project are encouraged to vote. 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 across the wider Accumulo community. For PMC decisions, only the -votes of active PMC members are binding. - -See the [voting page][voting] for more details on the mechanics of voting. +starting with `[VOTE]`. After the vote period has elapsed, the initiator of the +vote, or their designee, closes it by replying to the thread with the results +of the vote. That result email should use the same subject line preceded by +`[RESULT][VOTE]`. Voting is carried out by replying to the vote mail and +continues until the vote is closed. If a vote thread becomes inactive and +remains open for too long, without a response from the initiator, the PMC Chair +may close the vote. Review Comment: ```suggestion starting with `[VOTE]`. After the vote period has elapsed, the initiator of the vote, or their designee, closes it by replying to the thread with the vote results. That result email should use the same subject line preceded by `[RESULT][VOTE]`. Voting is carried out by replying to the vote mail and continues until the vote is closed. If a vote thread becomes inactive and remains open for too long, without a response from the initiator, the PMC Chair may close the vote. ``` ########## contributor/bylaws.md: ########## @@ -154,162 +140,88 @@ An Accumulo release manager is also expected to: * ensure that required release testing is being conducted * track whether the release is on target for its expected release date * adjust release plan dates to reflect the latest estimates -* determine if a re-plan may be needed and, if so, call a vote -* call votes on release candidates +* terminate a release vote by either withdrawing a release candidate from consideration, if needed +* tally the votes and record the vote result after a release vote period has elapsed +* ensure any post-release tasks are performed, such as updating the website and publishing artifacts Details on [making][making] and [verifying][verifying] a release are available on the Accumulo website. # Decision Making Within the Accumulo project, different types of decisions require different -forms of approval. For example, the previous section describes several -decisions which require 'consensus approval'. This section defines how voting -is performed, the types of approvals, and which types of decision require which -type of approval. +forms of approval. For example, the previous section describes 'consensus' from +the existing PMC members. Consensus in that case can be achieved through a +[consensus approval vote][consensus]. ## Voting Decisions regarding the project are made by votes on the primary project development mailing list: [email protected]. Where necessary, PMC voting may take place on the private Accumulo PMC mailing list: [email protected]. Votes are clearly indicated by a subject line -starting with [VOTE]. A vote message may only pertain to a single item’s -approval; multiple items should be separated into multiple messages. Voting is -carried out by replying to the vote mail. A vote may take on one of four forms, -defined below. - -{: .table } -| Vote | Meaning | -|------|---------| -| +1 | *Yes*, *Agree*, or *The action should be performed*. In general, this vote also indicates a willingness on the behalf of the voter to *make 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 | *No*, *Disagree*, or *The action should not be performed*. 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. | - -All participants in the Accumulo project are encouraged to vote. 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 across the wider Accumulo community. For PMC decisions, only the -votes of active PMC members are binding. - -See the [voting page][voting] for more details on the mechanics of voting. +starting with `[VOTE]`. After the vote period has elapsed, the initiator of the +vote, or their designee, closes it by replying to the thread with the results +of the vote. That result email should use the same subject line preceded by +`[RESULT][VOTE]`. Voting is carried out by replying to the vote mail and +continues until the vote is closed. If a vote thread becomes inactive and +remains open for too long, without a response from the initiator, the PMC Chair +may close the vote. + +All participants in the Accumulo project are encouraged to vote. However, some +votes are considered non-binding (such as votes from non-PMC members during a +release vote). However, non-binding votes are still useful to gain insight into +the community's view of the vote topic. + +Each person gets only a single vote. You can change your vote by replying to +the same vote thread to explain the change prior to the vote being closed. + +For more information on how to vote, see the Foundation's page on +[voting][voting]. + +The Foundation defines voting criteria for procedural issues, code +modifications, and releases. Most formal votes are going to be [consensus +approval][consensus]. Release votes, however, follow [majority +approval][majority]. Other decisions, when necessary, can often be made through +[lazy consensus][lazy]. In the case of an objection for a lazy consensus vote, +or the desire for explicit consensus, one can initiate a formal vote thread. + +All votes should last a minimum of 72 hours. ## Commit Then Review (CTR) -Voting can also be applied to changes to the Accumulo codebase. Under the -Commit Then Review policy, committers can make changes to the codebase without -seeking approval beforehand, and the changes are assumed to be approved unless -an objection is raised. Only if an objection is raised must a vote take place -on the code change. - -For some code changes, committers may wish to get feedback from the community -before making the change. It is acceptable for a committer to seek approval -before making a change if they so desire. - -## Approvals - -These are the types of approvals that can be sought. Different actions require -different types of approvals. - -{: .table } -| Approval Type | Definition | -|-----------------------------------|--------------------------------------------------------------------------------------------------| -| Consensus Approval | A consensus approval vote passes with 3 binding +1 votes and no binding vetoes. | -| Majority Approval | A majority approval vote passes with 3 binding +1 votes and more binding +1 votes than -1 votes. | -| Lazy Approval (or Lazy Consensus) | An action with lazy approval is implicitly allowed unless a -1 vote is received, at which time, depending on the type of action, either majority approval or consensus approval must be obtained. Lazy Approval can be either *stated* or *assumed*, as detailed on the [lazy consensus page][lazy]. | - -## Vetoes - -A valid, binding veto cannot be overruled. If a veto is cast, it must be -accompanied by a valid reason explaining 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, but 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, the action that has been -vetoed must be reversed in a timely manner. - -## Actions - -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. It also specifies the minimum length of time -that a vote must remain open, measured in days. In general, votes should not be -called at times when it is known that interested members of the project will be -unavailable. - -For Code Change actions, a committer may choose to employ assumed or stated -Lazy Approval under the [CTR][ctr] policy. Assumed Lazy Approval has no minimum -length of time before the change can be made. - -{: .table } -| Action | Description | Approval | Binding Votes | Min. Length (days) | -|---------------------------|-------------------------------------------------------------------------------------------------------------|-------------------------------------------------------|--------------------|--------------------| -| Code Change | A change made to a codebase of the project. This includes source code, documentation, website content, etc. | Lazy approval, moving to consensus approval upon veto | Active committers | 1 | -| Release Plan | Defines the timetable and actions for an upcoming release. The plan also nominates a Release Manager. | Lazy approval, moving to majority approval upon veto | Active committers | 3 | -| Release Plan Cancellation | Cancels an active release plan, due to a need to re-plan (e.g., discovery of a major issue). | Majority approval | Active committers | 3 | -| Product Release | Accepts or rejects a release candidate as an official release of the project. | Majority approval | Active PMC members | 3 | -| 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. This also covers the creation of new sub-projects within the project. | Consensus approval | Active PMC members | 7 | -| New Committer | When a new committer is proposed for the project. | Consensus approval | Active PMC members | 3 | -| New PMC Member | When a committer is proposed for the PMC. | Consensus approval | Active PMC members | 3 | -| New PMC Chair | When a new PMC chair is chosen to succeed an outgoing chair. | Consensus approval | Active PMC members | 3 | -| Modifying Bylaws | Modifying this document. | Consensus approval | Active PMC members | 7 | - -No other voting actions are defined; all other actions should presume Lazy -Approval (defaulting to Consensus Approval upon veto). If an action is voted on -multiple times, or if a different approval type is desired, these bylaws should -be amended to include the action. - -For the purposes of the "Adoption of New Codebase" action, the Accumulo -codebase is defined as the Accumulo site content, primary project code, and all -contributed code ("contribs") as they exist in their respective repositories. -Adoption of a new codebase generally refers to the creation of a new contrib -repository, but could cover, for example, a rework of the project site, or -merging a contrib project into the primary codebase. - -Voting actions for the removal of a committer or PMC member are intentionally -not defined. According to ASF rules, [committer status never -expires][committer-terms] and [PMC members can only be removed with approval -from the ASF Board][pmc-removal]. - -# Release Plans - -The approval of a release plan begins the process of creating a new project -release. The process ends when a release candidate is approved. - -An Accumulo release plan consists of at least the following: - -* a version number -* a feature freeze date -* a code freeze date -* a release date -* the choice of a release manager - -After feature freeze, new features should not be accepted for the release. -After code freeze, only critical fixes should be accepted for the release. The -release manager guides the decision on accepting changes. - -All dates in a plan are estimates, as unforeseen issues may require delays. The -release manager may adjust dates as needed. In serious circumstances, the -release manager may opt to call a re-plan vote. +Accumulo follows a commit-then-review (CTR) policy. This only means that it is +not strictly a requirement to achieve consensus prior to committing code +changes to the code repository. Committers can make changes to the codebase Review Comment: ```suggestion Accumulo follows a commit-then-review (CTR) policy. This means that consensus is not required prior to committing. Committers can make changes to the codebase ``` ########## contributor/bylaws.md: ########## @@ -154,162 +140,88 @@ An Accumulo release manager is also expected to: * ensure that required release testing is being conducted * track whether the release is on target for its expected release date * adjust release plan dates to reflect the latest estimates -* determine if a re-plan may be needed and, if so, call a vote -* call votes on release candidates +* terminate a release vote by either withdrawing a release candidate from consideration, if needed +* tally the votes and record the vote result after a release vote period has elapsed +* ensure any post-release tasks are performed, such as updating the website and publishing artifacts Details on [making][making] and [verifying][verifying] a release are available on the Accumulo website. # Decision Making Within the Accumulo project, different types of decisions require different -forms of approval. For example, the previous section describes several -decisions which require 'consensus approval'. This section defines how voting -is performed, the types of approvals, and which types of decision require which -type of approval. +forms of approval. For example, the previous section describes 'consensus' from +the existing PMC members. Consensus in that case can be achieved through a +[consensus approval vote][consensus]. ## Voting Decisions regarding the project are made by votes on the primary project development mailing list: [email protected]. Where necessary, PMC voting may take place on the private Accumulo PMC mailing list: [email protected]. Votes are clearly indicated by a subject line -starting with [VOTE]. A vote message may only pertain to a single item’s -approval; multiple items should be separated into multiple messages. Voting is -carried out by replying to the vote mail. A vote may take on one of four forms, -defined below. - -{: .table } -| Vote | Meaning | -|------|---------| -| +1 | *Yes*, *Agree*, or *The action should be performed*. In general, this vote also indicates a willingness on the behalf of the voter to *make 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 | *No*, *Disagree*, or *The action should not be performed*. 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. | - -All participants in the Accumulo project are encouraged to vote. 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 across the wider Accumulo community. For PMC decisions, only the -votes of active PMC members are binding. - -See the [voting page][voting] for more details on the mechanics of voting. +starting with `[VOTE]`. After the vote period has elapsed, the initiator of the +vote, or their designee, closes it by replying to the thread with the results +of the vote. That result email should use the same subject line preceded by +`[RESULT][VOTE]`. Voting is carried out by replying to the vote mail and +continues until the vote is closed. If a vote thread becomes inactive and +remains open for too long, without a response from the initiator, the PMC Chair +may close the vote. + +All participants in the Accumulo project are encouraged to vote. However, some +votes are considered non-binding (such as votes from non-PMC members during a +release vote). However, non-binding votes are still useful to gain insight into +the community's view of the vote topic. + +Each person gets only a single vote. You can change your vote by replying to +the same vote thread to explain the change prior to the vote being closed. + +For more information on how to vote, see the Foundation's page on +[voting][voting]. + +The Foundation defines voting criteria for procedural issues, code +modifications, and releases. Most formal votes are going to be [consensus +approval][consensus]. Release votes, however, follow [majority +approval][majority]. Other decisions, when necessary, can often be made through +[lazy consensus][lazy]. In the case of an objection for a lazy consensus vote, +or the desire for explicit consensus, one can initiate a formal vote thread. Review Comment: ```suggestion The Foundation defines voting criteria for procedural issues, code modifications, and releases. Most formal votes will be [consensus approval][consensus]. Release votes, however, follow [majority approval][majority]. Other decisions, when necessary, can often be made through [lazy consensus][lazy]. In the case of an objection for a lazy consensus vote, or the desire for explicit consensus, one can initiate a formal vote thread. ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
