groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <remko.po...@gmail.com>
Subject Re: [VOTE] Support Java-like array
Date Sun, 13 May 2018 11:49:45 GMT
For code change votes, since a single -1 veto is sufficient to prevent the
change from going in, it may be a bit overkill to also require three
_binding_ (PMC) votes. Whether the veto vote needs to be a binding vote
from a PMC member or not is (deliberately?) vague in [1]. The document
mentions a “qualified voter”. I guess each community should figure out what
that means exactly for them.

Otherwise, it is probably good to formalize the guideline that committers
should create PRs for potentially contentious code changes.

[1]
https://www.apache.org/foundation/voting.html

Remko

On Sun, May 13, 2018 at 17:57 Paul King <paulk@asert.com.au> 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.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> 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
>>
>
>

Mime
View raw message