I can say why I didn't vote: I didn't have time to review the proposal and its consequences, so I don't want to give a blind +1 or -1.
Le mar. 15 mai 2018 à 08:03, mg <mg...@arscreat.com> a écrit : > 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 <mg...@arscreat.com> > Datum: 15.05.18 00:57 (GMT+01:00) > An: dev@groovy.apache.org, Paul King <pa...@asert.com.au> > 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 <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> 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 >> > > >
