samoa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gianmarco De Francisci Morales (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SAMOA-5) Create bylaws
Date Mon, 02 Feb 2015 14:56:34 GMT

    [ 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)

Mime
View raw message