For code change votes, since a single -1 veto is sufficient to prevent the change from going in, it may be a bit overkill to also require three _binding_ (PMC) votes. Whether the veto vote needs to be a binding vote from a PMC member or not is (deliberately?) vague in [1]. The document mentions a “qualified voter”. I guess each community should figure out what that means exactly for them. 

Otherwise, it is probably good to formalize the guideline that committers should create PRs for potentially contentious code changes. 



On Sun, May 13, 2018 at 17:57 Paul King <> wrote:
My understanding is that there is some flexibility when asking for votes so long as it is clear up front what the expectation is, see e.g. [1]. Even though there are numerous generic Apache sites with similar descriptions, I was thinking of adding some more content in some of our pages to summarise the most relevant information for our project. I was thinking of some additional wording to the "Contributing code" section of the website to indicate that typically committers should be following the same guidelines (creating PRs etc.) for any significant code change as for people without committer status. Also, I was going to add some wording somewhere around our typical conventions for voting. Something like:

We strongly value keeping consensus within the project. Sometimes consensus is obvious from general discussions or informal +1s in PRs or Jira issues. For significant changes within PRs or Jiras, it is good to send an informational to the dev mailing list in any case. When consensus is not obvious or for potentially contentious changes, emails with a [VOTE] in the subject line are a good way to ascertain consensus. Typical scenarios are:
* [VOTE] for a release - requires 3 more binding +1 votes than -1 votes (no veto capability)
* [VOTE] for code change - requires 3 binding +1s but can be vetoed with a single -1 binding vote
* [VOTE][LAZY] for code change - assumes absence of a vote is a +1 (but you'd normally want at least one binding +1 so best to wait a bit longer if you don't have at least one) but can be vetoed with a single -1 binding vote
A committer creating a PR request is similar to [VOTE][LAZY].
72 hours is the minimum for such votes but there is no maximum time delay - though waiting too long isn't a good idea since the circumstances which lead to earlier +1s might have changed.

If anyone has improvements for this wording, let me know.

Cheers, Paul.

On Sun, May 13, 2018 at 2:20 PM, Remko Popma <> wrote:
That’s probably why over at Log4j we use slightly different language for voting:

“The vote will remain open for 72 hours (or more if required). At least 3 +1 votes ...”

It seems unfair that by not participating, it is possible to essentially vote -0 or -1 without justification...



> On May 13, 2018, at 11:48, Daniel.Sun <> wrote:
> Please see my original email:
> "The vote is open for the next 72 hours and passes if a majority of at least
> three +1 PMC votes are cast."
> Cheers,
> Daniel.Sun
> --
> Sent from: