Who will update the https://community.apache.org/newcommitter.html page?*
This line
A positive result is achieved by Consensus Approval i.e. at least 3 +1
votes and no vetoes.
I could be wrong but I don't think I can... (not a member)
Thanks
Jacques
Le 24/03/2015 10:11, Pierre Smits a écrit :
Now that we have that cleared up, we can all go back to our projects and
contribute the good stuff to our works.
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Tue, Mar 24, 2015 at 9:59 AM, Pierre Smits <pierre.sm...@gmail.com>
wrote:
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.
