What I meant to say yesterday at 1am was: "On the other hand I do not get why
only 2 PMC members have been
voting +1 on this proposal..."
This is not against voting +0, but about why so few PMC members vote at all...
(?)
-------- Ursprüngliche Nachricht --------Von: MG <[email protected]> Datum:
15.05.18 00:57 (GMT+01:00) An: [email protected], Paul King
<[email protected]> Betreff: Re: [VOTE] Support Java-like array
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
Cheers, Paul.
On Sun, May 13, 2018 at 2:20 PM, Remko
Popma <[email protected]>
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 <[email protected]>
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
