[
https://issues.apache.org/jira/browse/SAMOA-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14301351#comment-14301351
]
Gianmarco De Francisci Morales commented on SAMOA-5:
----------------------------------------------------
So, I did a bit of research, and here is what I came up with. Remember we are
mainly speaking about code changes.
By default,
http://www.apache.org/foundation/voting.html#votes-on-code-modification says
that 3 +1 votes are required, unless lazy consensus.
http://www.apache.org/foundation/voting.html#LazyConsensus says that lazy
consensus cannot be applied for review-then-commit policy, but we can set our
own rules.
Pig uses Lazy Aproval (which is kind of like lazy consensus) on code changes
(not counting the vote of the contributor) http://pig.apache.org/bylaws.html.
In practice, what the community does is this: a patch needs a +1 if the
contributor is a committer (and he can commit it after the +1), otherwise it
needs 2 +1.
Storm still has only a draft of the bylaws
(https://github.com/apache/storm/blob/master/BYLAWS.md).
In any case they use a similar policy for code changes: one +1 from a Committer
other than the one who authored the patch, and no -1.
Drill does the same thing
https://cwiki.apache.org/confluence/display/DRILL/Project+Bylaws
Consensus approval of active committers, with a minimum of one +1. The code can
be committed after the first +1.
So I think we can copy from any of these.
The principle I would use is "it needs 2 pairs of expert (Committer's) eyes
before being committed".
So either 2 +1 from committers or just 1 +1 if the patch is already from a
committer.
For the other actions (release plan, new committer, new PPMC member, modifying
bylaws) we can probably stick with the defaults.
We should also decide whether we want to be a difference between PPMC member
and committer, or whether we prefer to keep it flat and invite people in the
PPMC directly while we are incubating.
Otherwise, who has binding votes on what? Committers should be allowed to vote
on code changes but not on nominating committers/PPMC.
Personally, I'd prefer to keep it flat, but I don't have a strong opinion about
it.
> Create bylaws
> -------------
>
> Key: SAMOA-5
> URL: https://issues.apache.org/jira/browse/SAMOA-5
> Project: SAMOA
> Issue Type: Task
> Components: Documentation
> Reporter: Gianmarco De Francisci Morales
>
> Define the bylaws under which the SAMOA project operates.
> As an example, here are the bylaws of Pig (http://pig.apache.org/bylaws.html).
> It might be premature right now but eventually it needs to be done.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
