Having reread the earlier postings I summarise what has been said it as
this:
- No vetoes are allowed, when it comes down to procedural issues
(electing persons into functions, e.g. committer, PMC Member, PMC Chair,
etc).
- As stated by Bertrand in his remark that 'A positive result is
achieved by Consensus Approval i.e. at least 3 +1 votes and no vetoes' in
https://community.apache.org/newcommitter.html wrong, because
https://www.apache.org/foundation/voting.html states that voting on
procedural issues follow the common majority rule
I wonder how many projects have stated in their policy (rules of the
games) pages, that they do it differently.
I also wonder how often it happened that - for the projects that
don't state that they do it differently - the common majority rule wasn't
applied when it came to voting regarding a potential committer or PMC
Member.
- Unanimity = consensus wrt procedural issues, as all are for either
for or against what has been voted on. Consensus wrt code-changes means no
vetoes.
- As far as the ASF and the board is concerned, any project under the
ASF umbrella can have the policies its wants/needs and the board is not
going to police that.
- Interpreting the statements made by Rich.
- However the https://www.apache.org/foundations/voting.html is
contradicting that statement in the section about binding votes.
- The statement made by Rich can be interpreted as that a project
can even deviate from any statement made in the voting.html page as these
statements are suggestions based on some kind of arbitrary best
practices.
As examples:
- if you want in your project to have it that all contributors
with signed, sent and accepted iCLAs can vote once per year on new
committers and PMC members, then that is acceptable by the ASF and the
board.
- If you want in your project to have it that all contributors
active for 1 year or more can directly vote the PMC Chair every three
years, than that is acceptable by the ASF and the board.
- If you want to have the policy in your project whereby you want
to exclude contributor 'of the other kind' from positions in
the project
(committer, PMC Member, PMC Chair), then that is acceptable
by the ASF and
the board.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Mon, Mar 23, 2015 at 6:41 PM, Mike Kienenberger <mkien...@gmail.com>
wrote:
> On Mon, Mar 23, 2015 at 1:31 PM, Ted Dunning <ted.dunn...@gmail.com>
> wrote:
>
> > > Here's a better not-quite-so-hypothetical example. A project like
> > MyFaces
> > > has to pass the TCK testing suite provided by Oracle. We would not
> want
> > > to allow unrestricted commit access by someone who did not
> > > understand profoundly and intuitively that the JSF API portion of the
> > > project has a predefined public API which cannot be changed.
> >
> >
> > Some projects feel this way. Others have found that review is just as
> > effective as restricting commit bits tightly. The classic case is
> > Subversion which has a very high profile (and thus is obliged to have
> > stable API's). That PMC offers a commit bit to anyone who asks.
> >
> > People seem to forget that erroneous commits that pass review can simply
> be
> > reverted. That is one of the points of using version control.
> >
>
> Yes, either approach could be used. Myfaces doesn't filter candidates
> based on this criteria -- we train contributers when they submit their
> first patches to the API project -- but a TCK project might decide to do
> so. The message probably should have read "They might not want to allow"
> rather than "We would not want to allow " as it gave the wrong impression.
>
