Cédric, Should the voting period be extended for this vote?
Remko > On May 15, 2018, at 15:07, Cédric Champeau <cedric.champ...@gmail.com> wrote: > > 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 >>> >>
