groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: [VOTE] Support Java-like array
Date Mon, 14 May 2018 22:57:16 GMT
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.popma@gmail.com 
> <mailto:remko.popma@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 <sunlan@apache.org
>     <mailto:sunlan@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>
>
>


Mime
View raw message