ctubbsii commented on code in PR #431: URL: https://github.com/apache/accumulo-website/pull/431#discussion_r1693454699
########## contributor/bylaws.md: ########## @@ -154,162 +140,87 @@ 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 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 Review Comment: No. I intentionally left it open ended, based on expectations about the role of the PMC chair and to avoid being too legalistic in our approach to novel circumstances. From https://www.apache.org/dev/pmc.html#chair : > Remember that, as in any committee, the chair is a facilitator and their role within the PMC is to ensure that everyone has a chance to be heard and to enable meetings and mailing lists to flow smoothly. It seems to follow that this is one way the activity on the mailing list can get held up, and the chair may have to step in to facilitate things flowing smoothly again. If we impose too strict rules around how long is too long, or under what circumstances, etc., then we're constraining the ability of the chair to facilitate things to keep things flowing smoothly. I've heard similar sentiments expressed about the chair's role from a variety of people, including advice from a board member once (years ago) that the PMC chair probably should have stepped in and made a decision when there was a stalemate conflict between contributors, even though there was nothing technically written that conflicts like that should be resolved in that way. -- 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]
