The principle/policy/rule of the ASF regarding code changes is very explicit, well documented and unambiguous. Can a project's PMC have another methodology in place while being part of the ASF? I guess not.
Consensus with respect to on and off boarding of people is nice, as it expresses unanimity. And I, as I expect it to be for all, am all for it. But to have it as an requirement would be a show stopper. Would it be ok for the ASF if there were a project under its umbrella, that would say: that majority voting principle you for procedural issues is nice, but for us - when it comes to people - we veto promotors/speakers/book writers to participate in our project with privileges (commit right, PMC membership)? Or, that it vetoes people from France (this is example, I have nothing against people from France or even with the French nationality)? 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 9:20 AM, jan i <j...@apache.org> wrote: > On 23 March 2015 at 09:02, Pierre Smits <pierre.sm...@gmail.com> wrote: > > > When it comes to people, consensus (acceptance by unanimity) is the best > > thing to have. But if the ASF has as its principle that no vetoes are > > allowed, how can it be the remit of a project's PMC have it as its > policy? > > > > I think it is a matter of wording, I do not think it is a ASF Principle > (actually not sure how that relates to "policy") that veto is not allowed, > Consensus is the ASF Principle. We all want to avoid Vetos, for many good > reasons, but that it not the same as not being allowed. > > As a Foundation we try to have very few rules and policies, and let the > communities handle how they want to do it, this here is surely > a case where we do not a foundation wide rule. > > I would have no problem, if the wording on the page was something like "it > is recommended not to use Veto" > > Pierre@ maybe just for my understanding, why would ASF be better, if we > make this rule foundation wide, instead of leaving it up to > the single community ? > > rgds > jan I. > > > > 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 Sun, Mar 22, 2015 at 3:17 PM, Jacques Le Roux < > > jacques.le.r...@les7arts.com> wrote: > > > > > Le 22/03/2015 14:42, jan i a écrit : > > > > > >> On 22 March 2015 at 14:35, Pierre Smits <pierre.sm...@gmail.com> > wrote: > > >> > > >> HI Bertrand, > > >>> > > >>> Thanks for the clarification regarding > > >>> http://community.apache.org/newcommitter.html > > >>> > > >>> Shouldn't http://www.apache.org/foundation/voting.html then also > > >>> explicitly > > >>> reflect that vetoes aren't allowed when it comes to on- and > ofboarding > > >>> contributors as committer and PMC member? That would surely bring > > >>> clarity. > > >>> > > >>> I would be very unhappy with "aren´t allowed", that is something the > > >> individual PMCs should decide ! > > >> > > > > > > Yes indeed that's PMCs 's remit; we just need to clarify the ASF > default. > > > > > > Jacques > > > > > > > > > > > >> rgds > > >> jan I. > > >> > > >> > > >> 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 Sun, Mar 22, 2015 at 2:25 PM, Bertrand Delacretaz < > > >>> bdelacre...@apache.org > > >>> > > >>>> wrote: > > >>>> On Sun, Mar 22, 2015 at 2:17 PM, Jacques Le Roux > > >>>> <jacques.le.r...@les7arts.com> wrote: > > >>>> > > >>>>> ...Thanks for the clarification Bertrand, this was also unclear to > > me. > > >>>>> > > >>>> Should > > >>>> > > >>>>> we not amend the newcommitter page?.. > > >>>>> > > >>>> That would be great, I don't have time right now myself. > > >>>> -Bertrand > > >>>> > > >>>> > > >
