ctubbsii commented on code in PR #431: URL: https://github.com/apache/accumulo-website/pull/431#discussion_r1706543549
########## 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 Review Comment: No, they aren't in conflict. A thread is not defined by the subject alone, and changing the subject is not the same as starting a new thread in the conventional sense or in the technical sense. In the technical sense, you can reply to a thread and change its subject line before sending in most email clients. A good email client will preserve the threading headers so that the mailing list service will keep them threaded in spite of the subject change. Although they have evolved, these features have generally been around for decades and were enormously useful in the days when NNTP newsgroups were supported by popular email clients. Some email clients (from my observations, Outlook is one) are particularly bad at this and drop these threading headers, and effectively start a new thread every time you change the subject. However, even if they aren't threaded in the technical sense, (such as if a user uses a bad email client, for instance) it's still the same thread in the conventional sense. Anybody looking at the subject line will be able to understand what's going on, because even if they are not technically identified as the same "thread" of conversation by the software, humans recognize the convention of adding tags to prefix a subject line as being part of the same overall thread of conversation. An example post is [this one](https://lists.apache.org/thread/22fol574ch2dbp48w4wbb0hn31j2mx0m) whose [raw content](https://lists.apache.org/api/source.lua?id=22fol574ch2dbp48w4wbb0hn31j2mx0m) contains the header `In-Reply-To: <cal5zq9btlw8n6pjbujpouwaycdeuteqe6c2sktzlutofxdq...@mail.gmail.com>` which references [this previous message](https://lists.apache.org/thread/01lq7fs8pf3fy4tddsmoml9r9lgd9ogz)'s [header](https://lists.apache.org/api/source.lua?id=01lq7fs8pf3fy4tddsmoml9r9lgd9ogz) `Message-ID: <cal5zq9btlw8n6pjbujpouwaycdeuteqe6c2sktzlutofxdq...@mail.gmail.com>` as well as other messages in the same thread in the `References:` header. -- 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]
