My 10 cents:
[VOTE][LAZY] seems a bit odd - if PMC members are on vacation/ill/afk
one person could basically push through sweeping changes, which seems odd.
On the other had I do not get why only 2 PMC members have been voting on
this proposal - if you do not care either way, and it already has 2 x
+1, just push it over the edge, if you are really against it, shoot it
down with -1...
Cheers,
mg
On 13.05.2018 10: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.
[1] https://www.apache.org/foundation/voting.html
<https://www.apache.org/foundation/voting.html>
Cheers, Paul.
On Sun, May 13, 2018 at 2:20 PM, Remko Popma <remko.po...@gmail.com
<mailto:remko.po...@gmail.com>> 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...
Thoughts?
Remko
> On May 13, 2018, at 11:48, Daniel.Sun <sun...@apache.org
<mailto:sun...@apache.org>> 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:
http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html>
