You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@community.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2017/03/29 00:03:43 UTC
Vetoes for New Committers??
Hi,
on https://community.apache.org/newcommitter.html#new-committer-process it
describes the process of bringing in a new committer for a "typical
project".
But in the "Discussion" it speaks of "3 +1 and no vetoes"... Is it really
"typical" that projects use vetoes for new committers? I can't recall
seeing that anywhere, not saying it is incorrect, but asking whether it
really is "typical".
Perhaps we should provide links to a handful of well-known project's
processes, to both give a template for projects to work with as well as
different approaches.
Anyone has any opinion on this matter?
Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: Vetoes for New Committers??
Posted by Hadrian Zbarcea <hz...@gmail.com>.
I tried to stay away from this thread. Oh, well...
Ted, congrats!
On 04/04/2017 08:18 PM, Ted Dunning wrote:
> Niclas,
>
> I never presented an argument in favor of *using* a veto. I presented an
> argument in favor of *having* a veto to potentially use.
That was well understood.
>
> The possibility of a veto encourages consensus building before the decision
> is recorded.
This is also understood, but it sounds to me that you are making Niclas'
point.
>
> I personally think that vetoes should almost never happen because any
> veto-worthy issue is brought out and resolved in discussion ahead of time.
Because of that, votes that may take place never do, because people
indicate via back channels what their vote will be (tactic I see even at
board level from time to time) and then the vote never takes place and
discussion and the status quo, well, continue. Nothing to report, all good.
Vetoes remove one of the few leverages the minority has, that's my
understanding of what Niclas meant.
That said, the majority has so many other ways to abuse of the minority,
that in my experience the only sane way is to just give up. Which most
do actually, sadly.
>
>
> On Tue, Apr 4, 2017 at 4:26 PM, Niclas Hedhman <he...@gmail.com> wrote:
>
>> But Ted, how does the minority regain the "minority's voice heard" simply
>> by veto of new members? If they place unreasonable vetoes and hope that
>> over time the majority will "evaporate" seems unproductive as well.
>>
>> Vetoes can become very contentious, and I don't really buy the arguments
>> presented in favor of using it. To me a negative use is a BDFL-type
>> leader/founder preventing active contributors from getting a say in a
>> project.
>>
>> The raised problem of community disharmony is not served with vetoes,
>> AFAICT.
>>
>>
>>
>> On Apr 4, 2017 14:06, "Ted Dunning" <te...@gmail.com> wrote:
>>
>> I hear it as the voice of (occasionally bitter) experience.
>>
>> It could easily be my own voice as well. I have found in my own limited
>> experience that communities who pay attention to minority voices to be far
>> better at producing real consensus. I have also found that people with a
>> majority-rules opinion often change their opinion to minority-must-be-heard
>> when they are no longer in the majority. That matches what Joe said pretty
>> closely.
>>
>> His phrasing might not be what I would use, but his experience seems to
>> match mine quite closely.
>>
>> I also really don't see how a valid statement of long experience is FUD. I
>> certainly see a healthy dose of FUD in my day job from competitors and
>> Joe's statement is pretty different.
>>
>>
>> On Mon, Apr 3, 2017 at 10:36 PM, Pierre Smits <pi...@gmail.com>
>> wrote:
>>
>>> That borders on FUD.
>>>
>>> Op di 4 apr. 2017 om 05:03 schreef Joseph Schaefer
>>> <jo...@yahoo.com.invalid>
>>>
>>>> Trust me niclas, you would be singing a very different tune if you
>>>> believed something like that were happening in a project you were
>> working
>>>> on and you were a member of the minority powerless to put a halt to it.
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Vetoes for New Committers??
Posted by Joseph Schaefer <jo...@yahoo.com.INVALID>.
+1 Ted. While I have never personally felt the need to issue a veto regarding a personnel promotion, I have seen others use it, and have on balance agreed with those decisions, including for the exact situation I mentioned.
Sent from my iPhone
> On Apr 4, 2017, at 8:18 PM, Ted Dunning <te...@gmail.com> wrote:
>
> Niclas,
>
> I never presented an argument in favor of *using* a veto. I presented an
> argument in favor of *having* a veto to potentially use.
>
> The possibility of a veto encourages consensus building before the decision
> is recorded.
>
> I personally think that vetoes should almost never happen because any
> veto-worthy issue is brought out and resolved in discussion ahead of time.
>
>
>> On Tue, Apr 4, 2017 at 4:26 PM, Niclas Hedhman <he...@gmail.com> wrote:
>>
>> But Ted, how does the minority regain the "minority's voice heard" simply
>> by veto of new members? If they place unreasonable vetoes and hope that
>> over time the majority will "evaporate" seems unproductive as well.
>>
>> Vetoes can become very contentious, and I don't really buy the arguments
>> presented in favor of using it. To me a negative use is a BDFL-type
>> leader/founder preventing active contributors from getting a say in a
>> project.
>>
>> The raised problem of community disharmony is not served with vetoes,
>> AFAICT.
>>
>>
>>
>> On Apr 4, 2017 14:06, "Ted Dunning" <te...@gmail.com> wrote:
>>
>> I hear it as the voice of (occasionally bitter) experience.
>>
>> It could easily be my own voice as well. I have found in my own limited
>> experience that communities who pay attention to minority voices to be far
>> better at producing real consensus. I have also found that people with a
>> majority-rules opinion often change their opinion to minority-must-be-heard
>> when they are no longer in the majority. That matches what Joe said pretty
>> closely.
>>
>> His phrasing might not be what I would use, but his experience seems to
>> match mine quite closely.
>>
>> I also really don't see how a valid statement of long experience is FUD. I
>> certainly see a healthy dose of FUD in my day job from competitors and
>> Joe's statement is pretty different.
>>
>>
>> On Mon, Apr 3, 2017 at 10:36 PM, Pierre Smits <pi...@gmail.com>
>> wrote:
>>
>>> That borders on FUD.
>>>
>>> Op di 4 apr. 2017 om 05:03 schreef Joseph Schaefer
>>> <jo...@yahoo.com.invalid>
>>>
>>>> Trust me niclas, you would be singing a very different tune if you
>>>> believed something like that were happening in a project you were
>> working
>>>> on and you were a member of the minority powerless to put a halt to it.
>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Vetoes for New Committers??
Posted by Ted Dunning <te...@gmail.com>.
Niclas,
I never presented an argument in favor of *using* a veto. I presented an
argument in favor of *having* a veto to potentially use.
The possibility of a veto encourages consensus building before the decision
is recorded.
I personally think that vetoes should almost never happen because any
veto-worthy issue is brought out and resolved in discussion ahead of time.
On Tue, Apr 4, 2017 at 4:26 PM, Niclas Hedhman <he...@gmail.com> wrote:
> But Ted, how does the minority regain the "minority's voice heard" simply
> by veto of new members? If they place unreasonable vetoes and hope that
> over time the majority will "evaporate" seems unproductive as well.
>
> Vetoes can become very contentious, and I don't really buy the arguments
> presented in favor of using it. To me a negative use is a BDFL-type
> leader/founder preventing active contributors from getting a say in a
> project.
>
> The raised problem of community disharmony is not served with vetoes,
> AFAICT.
>
>
>
> On Apr 4, 2017 14:06, "Ted Dunning" <te...@gmail.com> wrote:
>
> I hear it as the voice of (occasionally bitter) experience.
>
> It could easily be my own voice as well. I have found in my own limited
> experience that communities who pay attention to minority voices to be far
> better at producing real consensus. I have also found that people with a
> majority-rules opinion often change their opinion to minority-must-be-heard
> when they are no longer in the majority. That matches what Joe said pretty
> closely.
>
> His phrasing might not be what I would use, but his experience seems to
> match mine quite closely.
>
> I also really don't see how a valid statement of long experience is FUD. I
> certainly see a healthy dose of FUD in my day job from competitors and
> Joe's statement is pretty different.
>
>
> On Mon, Apr 3, 2017 at 10:36 PM, Pierre Smits <pi...@gmail.com>
> wrote:
>
> > That borders on FUD.
> >
> > Op di 4 apr. 2017 om 05:03 schreef Joseph Schaefer
> > <jo...@yahoo.com.invalid>
> >
> > > Trust me niclas, you would be singing a very different tune if you
> > > believed something like that were happening in a project you were
> working
> > > on and you were a member of the minority powerless to put a halt to it.
> >
> >
>
Re: Vetoes for New Committers??
Posted by Joe Schaefer <jo...@yahoo.com.INVALID>.
Running to the board every time there is a lack of consensus about a candidate is not appropriate governance at Apache. The fact that PMC members are afforded certain RIGHTS, including the right to stop the train on a personnel promotion, is an important aspect of maintaining proper checks and balances within the project itself.
Not to belabor the whole question about the role of diversity in this org, the fact is that once a PMC reaches a size significantly greater than the original crop of developers, conflict happens. Sometimes it means a single person is not sufficiently aligned with the rest of the team in terms of core values and principles about personnel promotions, and sometimes the group is mired in groupthink and the sole voice of reason can effectively block bad decisions from happening to the project. Either way, diversity happens, and it's not always universally positive for the collective wellbeing of the group. At least not in the short run.
But most of the time, it's resolvable to the satisfaction of everyone in the project. I've never seen a veto issued as a permanent objection to a candidate, 99% of the time the vetoer is simply saying "not yet, IMO".And that "not yet" opinion can stand according to the bylaws of the larger projects all of whom have found constructive ways of restoring the group to consensus decisions about personnel over the full spectrum of time.
On Tuesday, April 4, 2017, 3:59:05 PM EDT, Niclas Hedhman <ni...@hedhman.org> wrote:That's reassuring, but how does that relate to defaulting to vetoes for
personnel?
Your statement about Board intervening could be said for Joe's/Ted's claim
about "letting the minority be heard" as well... and doesn't support or
undermine the use of vetoes for personnel.
Cheers
On Apr 5, 2017 07:49, "Marvin Humphrey" <ma...@rectangular.com> wrote:
> On Tue, Apr 4, 2017 at 4:26 PM, Niclas Hedhman <he...@gmail.com> wrote:
>
> > Vetoes can become very contentious, and I don't really buy the arguments
> > presented in favor of using it. To me a negative use is a BDFL-type
> > leader/founder preventing active contributors from getting a say in a
> > project.
>
> If a personnel vote is contended, and it doesn't show up in a Board
> report, the PMC Chair is not upholding their responsibilities and
> should be sacked. But even if it does get omitted, at least one
> Director is probably scanning each project's private list once per
> quarter and will likely flag the issue.
>
> Contended personnel votes are not common. The Board has enough
> bandwidth to review them and curtail egregious abuse.
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
Re: Vetoes for New Committers??
Posted by Niclas Hedhman <ni...@hedhman.org>.
That's reassuring, but how does that relate to defaulting to vetoes for
personnel?
Your statement about Board intervening could be said for Joe's/Ted's claim
about "letting the minority be heard" as well... and doesn't support or
undermine the use of vetoes for personnel.
Cheers
On Apr 5, 2017 07:49, "Marvin Humphrey" <ma...@rectangular.com> wrote:
> On Tue, Apr 4, 2017 at 4:26 PM, Niclas Hedhman <he...@gmail.com> wrote:
>
> > Vetoes can become very contentious, and I don't really buy the arguments
> > presented in favor of using it. To me a negative use is a BDFL-type
> > leader/founder preventing active contributors from getting a say in a
> > project.
>
> If a personnel vote is contended, and it doesn't show up in a Board
> report, the PMC Chair is not upholding their responsibilities and
> should be sacked. But even if it does get omitted, at least one
> Director is probably scanning each project's private list once per
> quarter and will likely flag the issue.
>
> Contended personnel votes are not common. The Board has enough
> bandwidth to review them and curtail egregious abuse.
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
Re: Vetoes for New Committers??
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Apr 4, 2017 at 4:26 PM, Niclas Hedhman <he...@gmail.com> wrote:
> Vetoes can become very contentious, and I don't really buy the arguments
> presented in favor of using it. To me a negative use is a BDFL-type
> leader/founder preventing active contributors from getting a say in a
> project.
If a personnel vote is contended, and it doesn't show up in a Board
report, the PMC Chair is not upholding their responsibilities and
should be sacked. But even if it does get omitted, at least one
Director is probably scanning each project's private list once per
quarter and will likely flag the issue.
Contended personnel votes are not common. The Board has enough
bandwidth to review them and curtail egregious abuse.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Vetoes for New Committers??
Posted by Niclas Hedhman <he...@gmail.com>.
But Ted, how does the minority regain the "minority's voice heard" simply
by veto of new members? If they place unreasonable vetoes and hope that
over time the majority will "evaporate" seems unproductive as well.
Vetoes can become very contentious, and I don't really buy the arguments
presented in favor of using it. To me a negative use is a BDFL-type
leader/founder preventing active contributors from getting a say in a
project.
The raised problem of community disharmony is not served with vetoes,
AFAICT.
On Apr 4, 2017 14:06, "Ted Dunning" <te...@gmail.com> wrote:
I hear it as the voice of (occasionally bitter) experience.
It could easily be my own voice as well. I have found in my own limited
experience that communities who pay attention to minority voices to be far
better at producing real consensus. I have also found that people with a
majority-rules opinion often change their opinion to minority-must-be-heard
when they are no longer in the majority. That matches what Joe said pretty
closely.
His phrasing might not be what I would use, but his experience seems to
match mine quite closely.
I also really don't see how a valid statement of long experience is FUD. I
certainly see a healthy dose of FUD in my day job from competitors and
Joe's statement is pretty different.
On Mon, Apr 3, 2017 at 10:36 PM, Pierre Smits <pi...@gmail.com>
wrote:
> That borders on FUD.
>
> Op di 4 apr. 2017 om 05:03 schreef Joseph Schaefer
> <jo...@yahoo.com.invalid>
>
> > Trust me niclas, you would be singing a very different tune if you
> > believed something like that were happening in a project you were
working
> > on and you were a member of the minority powerless to put a halt to it.
>
>
Re: Vetoes for New Committers??
Posted by Ted Dunning <te...@gmail.com>.
I hear it as the voice of (occasionally bitter) experience.
It could easily be my own voice as well. I have found in my own limited
experience that communities who pay attention to minority voices to be far
better at producing real consensus. I have also found that people with a
majority-rules opinion often change their opinion to minority-must-be-heard
when they are no longer in the majority. That matches what Joe said pretty
closely.
His phrasing might not be what I would use, but his experience seems to
match mine quite closely.
I also really don't see how a valid statement of long experience is FUD. I
certainly see a healthy dose of FUD in my day job from competitors and
Joe's statement is pretty different.
On Mon, Apr 3, 2017 at 10:36 PM, Pierre Smits <pi...@gmail.com>
wrote:
> That borders on FUD.
>
> Op di 4 apr. 2017 om 05:03 schreef Joseph Schaefer
> <jo...@yahoo.com.invalid>
>
> > Trust me niclas, you would be singing a very different tune if you
> > believed something like that were happening in a project you were working
> > on and you were a member of the minority powerless to put a halt to it.
>
>
Re: Vetoes for New Committers??
Posted by Pierre Smits <pi...@gmail.com>.
That borders on FUD.
Op di 4 apr. 2017 om 05:03 schreef Joseph Schaefer
<jo...@yahoo.com.invalid>
> Trust me niclas, you would be singing a very different tune if you
> believed something like that were happening in a project you were working
> on and you were a member of the minority powerless to put a halt to it.
>
> Sent from my iPhone
>
> > On Mar 29, 2017, at 4:16 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> >
> > Well, isn't that a weak argument, since said company already have
> majority
> > and with vetoes can also block to loose such majority. If this happens, I
> > would assume that someone in the PMC would bring it to Board's attention
> to
> > look into the matter, as the only course of action against a malevolent
> > company taking control of a project, no matter which voting system you
> > apply.
> >
> > Cheers
> > Niclas
> >
> > On Wed, Mar 29, 2017 at 1:28 PM, Joseph Schaefer <
> > joe_schaefer@yahoo.com.invalid> wrote:
> >
> >> The downside to majority rule when it comes to personnel voting is that
> it
> >> can lead to a situation where a company having a majority on the pmc can
> >> increase their majority by voting in additional employees without the
> >> minority having any way to provide a check on that exercise of power.
> Yes
> >> this has come up in the past.
> >>
> >> Sent from my iPhone
> >>
> >>> On Mar 28, 2017, at 8:03 PM, Niclas Hedhman <ni...@hedhman.org>
> wrote:
> >>>
> >>> Hi,
> >>> on
> https://community.apache.org/newcommitter.html#new-committer-process
> >> it
> >>> describes the process of bringing in a new committer for a "typical
> >>> project".
> >>>
> >>> But in the "Discussion" it speaks of "3 +1 and no vetoes"... Is it
> really
> >>> "typical" that projects use vetoes for new committers? I can't recall
> >>> seeing that anywhere, not saying it is incorrect, but asking whether it
> >>> really is "typical".
> >>>
> >>> Perhaps we should provide links to a handful of well-known project's
> >>> processes, to both give a template for projects to work with as well as
> >>> different approaches.
> >>>
> >>> Anyone has any opinion on this matter?
> >>>
> >>> Cheers
> >>> --
> >>> Niclas Hedhman, Software Developer
> >>> http://polygene.apache.org - New Energy for Java
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> >> For additional commands, e-mail: dev-help@community.apache.org
> >>
> >>
> >
> >
> > --
> > Niclas Hedhman, Software Developer
> > http://polygene.apache.org - New Energy for Java
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
> --
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
Re: Vetoes for New Committers??
Posted by Joseph Schaefer <jo...@yahoo.com.INVALID>.
Trust me niclas, you would be singing a very different tune if you believed something like that were happening in a project you were working on and you were a member of the minority powerless to put a halt to it.
Sent from my iPhone
> On Mar 29, 2017, at 4:16 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
>
> Well, isn't that a weak argument, since said company already have majority
> and with vetoes can also block to loose such majority. If this happens, I
> would assume that someone in the PMC would bring it to Board's attention to
> look into the matter, as the only course of action against a malevolent
> company taking control of a project, no matter which voting system you
> apply.
>
> Cheers
> Niclas
>
> On Wed, Mar 29, 2017 at 1:28 PM, Joseph Schaefer <
> joe_schaefer@yahoo.com.invalid> wrote:
>
>> The downside to majority rule when it comes to personnel voting is that it
>> can lead to a situation where a company having a majority on the pmc can
>> increase their majority by voting in additional employees without the
>> minority having any way to provide a check on that exercise of power. Yes
>> this has come up in the past.
>>
>> Sent from my iPhone
>>
>>> On Mar 28, 2017, at 8:03 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
>>>
>>> Hi,
>>> on https://community.apache.org/newcommitter.html#new-committer-process
>> it
>>> describes the process of bringing in a new committer for a "typical
>>> project".
>>>
>>> But in the "Discussion" it speaks of "3 +1 and no vetoes"... Is it really
>>> "typical" that projects use vetoes for new committers? I can't recall
>>> seeing that anywhere, not saying it is incorrect, but asking whether it
>>> really is "typical".
>>>
>>> Perhaps we should provide links to a handful of well-known project's
>>> processes, to both give a template for projects to work with as well as
>>> different approaches.
>>>
>>> Anyone has any opinion on this matter?
>>>
>>> Cheers
>>> --
>>> Niclas Hedhman, Software Developer
>>> http://polygene.apache.org - New Energy for Java
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
>> For additional commands, e-mail: dev-help@community.apache.org
>>
>>
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Vetoes for New Committers??
Posted by Niclas Hedhman <ni...@hedhman.org>.
Well, isn't that a weak argument, since said company already have majority
and with vetoes can also block to loose such majority. If this happens, I
would assume that someone in the PMC would bring it to Board's attention to
look into the matter, as the only course of action against a malevolent
company taking control of a project, no matter which voting system you
apply.
Cheers
Niclas
On Wed, Mar 29, 2017 at 1:28 PM, Joseph Schaefer <
joe_schaefer@yahoo.com.invalid> wrote:
> The downside to majority rule when it comes to personnel voting is that it
> can lead to a situation where a company having a majority on the pmc can
> increase their majority by voting in additional employees without the
> minority having any way to provide a check on that exercise of power. Yes
> this has come up in the past.
>
> Sent from my iPhone
>
> > On Mar 28, 2017, at 8:03 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> >
> > Hi,
> > on https://community.apache.org/newcommitter.html#new-committer-process
> it
> > describes the process of bringing in a new committer for a "typical
> > project".
> >
> > But in the "Discussion" it speaks of "3 +1 and no vetoes"... Is it really
> > "typical" that projects use vetoes for new committers? I can't recall
> > seeing that anywhere, not saying it is incorrect, but asking whether it
> > really is "typical".
> >
> > Perhaps we should provide links to a handful of well-known project's
> > processes, to both give a template for projects to work with as well as
> > different approaches.
> >
> > Anyone has any opinion on this matter?
> >
> > Cheers
> > --
> > Niclas Hedhman, Software Developer
> > http://polygene.apache.org - New Energy for Java
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
Re: Vetoes for New Committers??
Posted by Pierre Smits <pi...@gmail.com>.
The segment (see below)t in the request for graduation to the board is a
remnant of an idea that is brought forward by many project in incubation.
> RESOLVED, that the initial Apache NAME PMC be and hereby is
> tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> Apache NAME Project; and be it further
It is something that keeps getting in without any consideration regarding
its impact. Not only within the graduating project, but also within the
IPMC or the board. If it is in and ratified through a majority vote (first
by the IPMC, subsequently) by the board it brings forward 2 actions:
1. the newly established must take actions on defining, approving (and
maintaining), publishing bylaws, and
2. the board must see to it that it will be done.
In threads elsewhere I have questioned this, and my take-away from postings
by several (ex) board members is that it is of no importance, no need to
follow through, no desire to police.
Seeing that there is no desire among others to address this,I have stopped
bringing this issue forward in (recent) vote-for-graduation requests in
general@incubator.a.o.
Best regards,
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
On Wed, Mar 29, 2017 at 7:38 AM, Pierre Smits <pi...@gmail.com>
wrote:
> In 2015 I asked a similar quiestion in this same forum. See [1]. I may
> shed some light.
>
> [1] https://lists.apache.org/thread.html/a4095177b9630643c8957e91b1e1b9
> 77b521db170767eb17eccec9f7@1426899898@%3Cdev.community.apache.org%3E
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Wed, Mar 29, 2017 at 7:28 AM, Joseph Schaefer <joe_schaefer@yahoo.com.
> invalid> wrote:
>
>> The downside to majority rule when it comes to personnel voting is that
>> it can lead to a situation where a company having a majority on the pmc can
>> increase their majority by voting in additional employees without the
>> minority having any way to provide a check on that exercise of power. Yes
>> this has come up in the past.
>>
>> Sent from my iPhone
>>
>> > On Mar 28, 2017, at 8:03 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
>> >
>> > Hi,
>> > on https://community.apache.org/newcommitter.html#new-committer-process
>> it
>> > describes the process of bringing in a new committer for a "typical
>> > project".
>> >
>> > But in the "Discussion" it speaks of "3 +1 and no vetoes"... Is it
>> really
>> > "typical" that projects use vetoes for new committers? I can't recall
>> > seeing that anywhere, not saying it is incorrect, but asking whether it
>> > really is "typical".
>> >
>> > Perhaps we should provide links to a handful of well-known project's
>> > processes, to both give a template for projects to work with as well as
>> > different approaches.
>> >
>> > Anyone has any opinion on this matter?
>> >
>> > Cheers
>> > --
>> > Niclas Hedhman, Software Developer
>> > http://polygene.apache.org - New Energy for Java
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
>> For additional commands, e-mail: dev-help@community.apache.org
>>
>>
>
Re: Vetoes for New Committers??
Posted by Pierre Smits <pi...@gmail.com>.
In 2015 I asked a similar quiestion in this same forum. See [1]. I may shed
some light.
[1]
https://lists.apache.org/thread.html/a4095177b9630643c8957e91b1e1b977b521db170767eb17eccec9f7@1426899898@%3Cdev.community.apache.org%3E
Best regards,
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
On Wed, Mar 29, 2017 at 7:28 AM, Joseph Schaefer <
joe_schaefer@yahoo.com.invalid> wrote:
> The downside to majority rule when it comes to personnel voting is that it
> can lead to a situation where a company having a majority on the pmc can
> increase their majority by voting in additional employees without the
> minority having any way to provide a check on that exercise of power. Yes
> this has come up in the past.
>
> Sent from my iPhone
>
> > On Mar 28, 2017, at 8:03 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> >
> > Hi,
> > on https://community.apache.org/newcommitter.html#new-committer-process
> it
> > describes the process of bringing in a new committer for a "typical
> > project".
> >
> > But in the "Discussion" it speaks of "3 +1 and no vetoes"... Is it really
> > "typical" that projects use vetoes for new committers? I can't recall
> > seeing that anywhere, not saying it is incorrect, but asking whether it
> > really is "typical".
> >
> > Perhaps we should provide links to a handful of well-known project's
> > processes, to both give a template for projects to work with as well as
> > different approaches.
> >
> > Anyone has any opinion on this matter?
> >
> > Cheers
> > --
> > Niclas Hedhman, Software Developer
> > http://polygene.apache.org - New Energy for Java
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
Re: Vetoes for New Committers??
Posted by Joseph Schaefer <jo...@yahoo.com.INVALID>.
The downside to majority rule when it comes to personnel voting is that it can lead to a situation where a company having a majority on the pmc can increase their majority by voting in additional employees without the minority having any way to provide a check on that exercise of power. Yes this has come up in the past.
Sent from my iPhone
> On Mar 28, 2017, at 8:03 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
>
> Hi,
> on https://community.apache.org/newcommitter.html#new-committer-process it
> describes the process of bringing in a new committer for a "typical
> project".
>
> But in the "Discussion" it speaks of "3 +1 and no vetoes"... Is it really
> "typical" that projects use vetoes for new committers? I can't recall
> seeing that anywhere, not saying it is incorrect, but asking whether it
> really is "typical".
>
> Perhaps we should provide links to a handful of well-known project's
> processes, to both give a template for projects to work with as well as
> different approaches.
>
> Anyone has any opinion on this matter?
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Vetoes for New Committers??
Posted by Rich Bowen <rb...@rcbowen.com>.
On 03/29/2017 09:00 AM, Myrle Krantz wrote:
>> Recall at a time, EVERYONE at Apache, and our projects, were fully
>> volunteer with unknown and widely varying cycles of free time. We
>> understood the ebb-and-flow of available time as an unaligned
>> volunteer and based some of our core tenets around that. That's
>> why, for example, merit doesn't expire. We realized that some
>> time you have time, and some time you don't.
>>
>> So we never wanted to "penalize" people who were infrequent or
>> had inconsistent time. Withholding PMC membership simply based
>> on that seems very, very wrong to me.
>
> This depends on what you task the PMC with. I prefer that a PMC leave
> most rule-making to the committers at large If the PMC is mostly
> about approving new committers, then I Jim's interpretation makes a
> lot of sense.
I would suggest that if you give that responsibility to the committers
at large, that's an opportunity to invite them all onto the PMC.
--
Rich Bowen - rbowen@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon
Re: Vetoes for New Committers??
Posted by Myrle Krantz <my...@apache.org>.
> Recall at a time, EVERYONE at Apache, and our projects, were fully
> volunteer with unknown and widely varying cycles of free time. We
> understood the ebb-and-flow of available time as an unaligned
> volunteer and based some of our core tenets around that. That's
> why, for example, merit doesn't expire. We realized that some
> time you have time, and some time you don't.
>
> So we never wanted to "penalize" people who were infrequent or
> had inconsistent time. Withholding PMC membership simply based
> on that seems very, very wrong to me.
This depends on what you task the PMC with. I prefer that a PMC leave
most rule-making to the committers at large If the PMC is mostly
about approving new committers, then I Jim's interpretation makes a
lot of sense.
Greets,
Myrle
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Vetoes for New Committers??
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Mar 28, 2017, at 8:15 PM, John D. Ament <jo...@apache.org> wrote:
>
> I asked a similar question on another list some time back, around voting in
> new committers. I'm not going to share that thread (public vs private) but
> I think the advice i got from it was spot on. In addition, I've heard
> great additional feedback on other threads.
>
> Projects want committers who are infrequent, but able to contribute. They
> want PMC members who are consistent and dedicated to the project.
Recall at a time, EVERYONE at Apache, and our projects, were fully
volunteer with unknown and widely varying cycles of free time. We
understood the ebb-and-flow of available time as an unaligned
volunteer and based some of our core tenets around that. That's
why, for example, merit doesn't expire. We realized that some
time you have time, and some time you don't.
So we never wanted to "penalize" people who were infrequent or
had inconsistent time. Withholding PMC membership simply based
on that seems very, very wrong to me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Vetoes for New Committers??
Posted by Joseph Schaefer <jo...@yahoo.com.INVALID>.
Yes of course!
Sent from my iPhone
> On Mar 29, 2017, at 4:05 PM, Pierre Smits <pi...@gmail.com> wrote:
>
> I wonder, when voting in new ASF Members is there the discussion on each
> nominee to achieve consensus...
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Wed, Mar 29, 2017 at 6:14 PM, Dennis E. Hamilton <or...@apache.org>
> wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: Marvin Humphrey [mailto:marvin@rectangular.com]
>>> Sent: Wednesday, March 29, 2017 05:13
>>> To: dev@community.apache.org
>>> Subject: Re: Vetoes for New Committers??
>>>
>> [ ... ]
>>>
>>> Most PMCs do not draft their own rules, and just use "at least 3 +1
>>> with no vetoes". CouchDB's majority-rule for committers is unusual. I
>>> hope that CouchDB's bylaws are not adopted as a template for others,
>>> as I believe that the rule on committer voting is counter to an
>>> important institutional tradition in Apache governance.
>>>
>> [ ... ]
>> [orcmid]
>>
>> I think there are common misunderstandings about where vetoes are allowed
>> (as opposed to No votes that need to be addressed as part of
>> consensus-seeking and community cultivation).
>>
>> My understanding is that votes on *procedural*matters* have no vetoes by
>> default, but the effort to achieve consensus is always important in the
>> presence of Nays. Treating nays as vetoes is often inappropriate because
>> it admits a form of bull-dozing in the negative. Note that lazy consensus
>> is a form of unanimous consent, with no explicit requirement for 3 +1s;
>> here an objection is not a veto since lazy consensus is specifically an
>> if-no-objection proposal and objections are invited.
>>
>> The only firm veto seems to be on commits. And, of course, the 3 +1s
>> majority is *specifically* for eligible votes on release candidates (and
>> which cannot be vetoed).
>>
>> The veto business (and the 3 +1s) seem to leak all over PMC practice
>> without ever being made an explicit policy as some sort of urban legend.
>> The fact that a podling mentor can veto actions (and also claim the myths
>> as policy) is probably confusing in that regard (if that is still the IPMC
>> practice).
>>
>> - Dennis
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
>> For additional commands, e-mail: dev-help@community.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Vetoes for New Committers??
Posted by Joseph Schaefer <jo...@yahoo.com.INVALID>.
Let me clarify that. Each nomination receives comments from other members about their history with the nominee. Not all comments are positive, but those that are are effectively counted as seconds for the nominee.
The actual vote is by simple majority however.
Sent from my iPhone
> On Mar 29, 2017, at 4:05 PM, Pierre Smits <pi...@gmail.com> wrote:
>
> I wonder, when voting in new ASF Members is there the discussion on each
> nominee to achieve consensus...
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Wed, Mar 29, 2017 at 6:14 PM, Dennis E. Hamilton <or...@apache.org>
> wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: Marvin Humphrey [mailto:marvin@rectangular.com]
>>> Sent: Wednesday, March 29, 2017 05:13
>>> To: dev@community.apache.org
>>> Subject: Re: Vetoes for New Committers??
>>>
>> [ ... ]
>>>
>>> Most PMCs do not draft their own rules, and just use "at least 3 +1
>>> with no vetoes". CouchDB's majority-rule for committers is unusual. I
>>> hope that CouchDB's bylaws are not adopted as a template for others,
>>> as I believe that the rule on committer voting is counter to an
>>> important institutional tradition in Apache governance.
>>>
>> [ ... ]
>> [orcmid]
>>
>> I think there are common misunderstandings about where vetoes are allowed
>> (as opposed to No votes that need to be addressed as part of
>> consensus-seeking and community cultivation).
>>
>> My understanding is that votes on *procedural*matters* have no vetoes by
>> default, but the effort to achieve consensus is always important in the
>> presence of Nays. Treating nays as vetoes is often inappropriate because
>> it admits a form of bull-dozing in the negative. Note that lazy consensus
>> is a form of unanimous consent, with no explicit requirement for 3 +1s;
>> here an objection is not a veto since lazy consensus is specifically an
>> if-no-objection proposal and objections are invited.
>>
>> The only firm veto seems to be on commits. And, of course, the 3 +1s
>> majority is *specifically* for eligible votes on release candidates (and
>> which cannot be vetoed).
>>
>> The veto business (and the 3 +1s) seem to leak all over PMC practice
>> without ever being made an explicit policy as some sort of urban legend.
>> The fact that a podling mentor can veto actions (and also claim the myths
>> as policy) is probably confusing in that regard (if that is still the IPMC
>> practice).
>>
>> - Dennis
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
>> For additional commands, e-mail: dev-help@community.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Vetoes for New Committers??
Posted by Pierre Smits <pi...@gmail.com>.
I wonder, when voting in new ASF Members is there the discussion on each
nominee to achieve consensus...
Best regards,
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
On Wed, Mar 29, 2017 at 6:14 PM, Dennis E. Hamilton <or...@apache.org>
wrote:
>
>
> > -----Original Message-----
> > From: Marvin Humphrey [mailto:marvin@rectangular.com]
> > Sent: Wednesday, March 29, 2017 05:13
> > To: dev@community.apache.org
> > Subject: Re: Vetoes for New Committers??
> >
> [ ... ]
> >
> > Most PMCs do not draft their own rules, and just use "at least 3 +1
> > with no vetoes". CouchDB's majority-rule for committers is unusual. I
> > hope that CouchDB's bylaws are not adopted as a template for others,
> > as I believe that the rule on committer voting is counter to an
> > important institutional tradition in Apache governance.
> >
> [ ... ]
> [orcmid]
>
> I think there are common misunderstandings about where vetoes are allowed
> (as opposed to No votes that need to be addressed as part of
> consensus-seeking and community cultivation).
>
> My understanding is that votes on *procedural*matters* have no vetoes by
> default, but the effort to achieve consensus is always important in the
> presence of Nays. Treating nays as vetoes is often inappropriate because
> it admits a form of bull-dozing in the negative. Note that lazy consensus
> is a form of unanimous consent, with no explicit requirement for 3 +1s;
> here an objection is not a veto since lazy consensus is specifically an
> if-no-objection proposal and objections are invited.
>
> The only firm veto seems to be on commits. And, of course, the 3 +1s
> majority is *specifically* for eligible votes on release candidates (and
> which cannot be vetoed).
>
> The veto business (and the 3 +1s) seem to leak all over PMC practice
> without ever being made an explicit policy as some sort of urban legend.
> The fact that a podling mentor can veto actions (and also claim the myths
> as policy) is probably confusing in that regard (if that is still the IPMC
> practice).
>
> - Dennis
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
RE: Vetoes for New Committers??
Posted by "Dennis E. Hamilton" <or...@apache.org>.
> -----Original Message-----
> From: Marvin Humphrey [mailto:marvin@rectangular.com]
> Sent: Wednesday, March 29, 2017 05:13
> To: dev@community.apache.org
> Subject: Re: Vetoes for New Committers??
>
[ ... ]
>
> Most PMCs do not draft their own rules, and just use "at least 3 +1
> with no vetoes". CouchDB's majority-rule for committers is unusual. I
> hope that CouchDB's bylaws are not adopted as a template for others,
> as I believe that the rule on committer voting is counter to an
> important institutional tradition in Apache governance.
>
[ ... ]
[orcmid]
I think there are common misunderstandings about where vetoes are allowed (as opposed to No votes that need to be addressed as part of consensus-seeking and community cultivation).
My understanding is that votes on *procedural*matters* have no vetoes by default, but the effort to achieve consensus is always important in the presence of Nays. Treating nays as vetoes is often inappropriate because it admits a form of bull-dozing in the negative. Note that lazy consensus is a form of unanimous consent, with no explicit requirement for 3 +1s; here an objection is not a veto since lazy consensus is specifically an if-no-objection proposal and objections are invited.
The only firm veto seems to be on commits. And, of course, the 3 +1s majority is *specifically* for eligible votes on release candidates (and which cannot be vetoed).
The veto business (and the 3 +1s) seem to leak all over PMC practice without ever being made an explicit policy as some sort of urban legend. The fact that a podling mentor can veto actions (and also claim the myths as policy) is probably confusing in that regard (if that is still the IPMC practice).
- Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Vetoes for New Committers??
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Mar 29, 2017, at 9:45 AM, Pierre Smits <pi...@gmail.com> wrote:
>
>
> Having the must-have-consensus (or unanimity) approach applied to
> everything doesn't work as it stalls moving forward (or beyond petty
> sentiments).
>
I'm not saying that majority rule is not a viable method to
run a project. Nor am I saying that consensus is a "nice to
have but we shouldn't worry about it" thing is wrong.
I'm just saying that you can't describe that methodology
as being compliant w/ the spirit of the Apache Way.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Vetoes for New Committers??
Posted by Pierre Smits <pi...@gmail.com>.
A call to vote (without or without a preceding discussion) is a means to
achieve a result. Equally so is the Veto-principle regarding code changes,
and the consensus-achieving discussion.
What can be derived from the aforementioned 'Veto?/Veto!' discussion is
that equally alienating/destructive are discussions started where each one
only expresses a stand-in-the ground (I want to have my way, and you must
come about) and nobody works towards an acceptable compromise. Such
discussions tend to linger on... And what is more discussion than
discussions about persons?
It sets a tone that will pop up from time to time. And such doesn't help
regarding bringing diversity in. It tends to lead to strategic nominations
and invitations.
Having the must-have-consensus (or unanimity) approach applied to
everything doesn't work as it stalls moving forward (or beyond petty
sentiments).
Best regards,
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
On Wed, Mar 29, 2017 at 3:22 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> > On Mar 29, 2017, at 9:11 AM, Pierre Smits <pi...@gmail.com>
> wrote:
> >
> > Applying the 'consensus', (or rather the 'every thing must be discussed
> > first') aspect everywhere is equally tyrranical.
> >
> > Hence the existence of the simple majority vote (50% of votes cast, + 1
> > with a min of 3 votes) for procedural matters. And onboarding new
> > committers, members, officers, etc. is a procedural matter. Unless, of
> > course, explicitly defined in bylaws.
> >
> > A -1 is nothing more than an expression of a viewpoint. Without all the
> > rhetoric!
>
> The issue w/ majority ruling is that it tends to self-perpetuate,
> and ensure that the majority continues to rule. It is ripe for
> abuse.
>
> If a PMC must "resort" to resolving things via "well, the majority ruled
> for it" then, imo, it is NOT a healthy and viable community, NOT one
> that will survive long term, NOT one which in in tune with the
> community.
>
> Consistent lack of being able to achieve consensus is a symptom of
> dysfunction
> and a severe warning sign. It is not to be ignored.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
Re: Vetoes for New Committers??
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Mar 29, 2017, at 9:11 AM, Pierre Smits <pi...@gmail.com> wrote:
>
> Applying the 'consensus', (or rather the 'every thing must be discussed
> first') aspect everywhere is equally tyrranical.
>
> Hence the existence of the simple majority vote (50% of votes cast, + 1
> with a min of 3 votes) for procedural matters. And onboarding new
> committers, members, officers, etc. is a procedural matter. Unless, of
> course, explicitly defined in bylaws.
>
> A -1 is nothing more than an expression of a viewpoint. Without all the
> rhetoric!
The issue w/ majority ruling is that it tends to self-perpetuate,
and ensure that the majority continues to rule. It is ripe for
abuse.
If a PMC must "resort" to resolving things via "well, the majority ruled
for it" then, imo, it is NOT a healthy and viable community, NOT one
that will survive long term, NOT one which in in tune with the
community.
Consistent lack of being able to achieve consensus is a symptom of dysfunction
and a severe warning sign. It is not to be ignored.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Vetoes for New Committers??
Posted by Pierre Smits <pi...@gmail.com>.
Applying the 'consensus', (or rather the 'every thing must be discussed
first') aspect everywhere is equally tyrranical.
Hence the existence of the simple majority vote (50% of votes cast, + 1
with a min of 3 votes) for procedural matters. And onboarding new
committers, members, officers, etc. is a procedural matter. Unless, of
course, explicitly defined in bylaws.
A -1 is nothing more than an expression of a viewpoint. Without all the
rhetoric!
And it seems to me that all the rhetoric viewpoints brought forward in such
discussion about why a certain (non-privileged) contributor should not be
enabled to do more is also a means to deflect from one own imperfection
and/or distrust towards the other.
As an example of such: recently a discussion was brought forward in
general@incubator.a.o. regarding the Log4cxx project (returning it to the
Logging Services project). As I learned from that thread, it seemed that it
was brought forward as a podling because PMC Members on the Logging project
were incapable of having the faith that contributors would work solely on
code belonging to that part of the repo. But that it was feared that they
would work on other code as well after being invited to get the commit bit.
How pityfull (and in my book how not the Apache Way) that a group of people
voted to have such a group of commited contributors (in a way) expelled
from a project and build a successfull community in the incubator project.
Only to discover that such wouldn't happen and the podling reverting to
project it originated from. What a waste of effort and time of many
involved.
Anyway, the CouchDb variant is equally valuable regarding the principles of
the Apache Software Foundation. And I do hope that projects will adopt them.
Best regards,
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
On Wed, Mar 29, 2017 at 2:13 PM, Marvin Humphrey <ma...@rectangular.com>
wrote:
>
> This is a key aspect of Apache community success. We use consensus
> decision making to avoid tyranny of the majority. Majority rule
> alienates the losing party. Consensus has beneficial effects in terms
> of forcing the majority to account for minority opinions, thus keeping
> the community unified.
>
> Most PMCs do not draft their own rules, and just use "at least 3 +1
> with no vetoes". CouchDB's majority-rule for committers is unusual. I
> hope that CouchDB's bylaws are not adopted as a template for others,
> as I believe that the rule on committer voting is counter to an
> important institutional tradition in Apache governance.
>
> Occasionally you reach an impasse where someone is holding out and
> consensus cannot be reached. At that point, I've seen communities
> define a specific supermajority threshold instead of requiring "3 +1
> with no vetoes".
>
> In the abstract, it would be nice if the supermajority rule were
> codified on voting.html, giving communities a template for resolving
> the impasse without thrashing. But ultimately, these votes are not
> legally binding and PMCs can be afforded a certain amount of
> flexibility. The Board cares that communities make personnel decisions
> by consensus, but "consensus" has a little give in it.
>
> (PMC votes on new PMC members are technically recommendations to the
> Board and officially it is the Board that makes decisions on PMC
> composition -- though the Board nearly always follows the PMC
> recommendation. Committer votes do not go through the Board.)
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>
Re: Vetoes for New Committers??
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Mar 28, 2017 at 5:15 PM, John D. Ament <jo...@apache.org> wrote:
> You want
> some form of consensus though through the addition of a committer. IF
> someone has serious concerns, and is unwilling to change their vote, you
> may want to hold off and monitor a bit further to see when that person
> passes that threshold to become a committer. You have to have a clear
> understanding through the community though to understand why the person
> voting -1 feels strongly that way, in addition to not scaring the person
> voting into withdrawing their vote - it could be a legitimate issue.
> Though ideally, your discussion thread would flesh something like this out.
+1
This is a key aspect of Apache community success. We use consensus
decision making to avoid tyranny of the majority. Majority rule
alienates the losing party. Consensus has beneficial effects in terms
of forcing the majority to account for minority opinions, thus keeping
the community unified.
Most PMCs do not draft their own rules, and just use "at least 3 +1
with no vetoes". CouchDB's majority-rule for committers is unusual. I
hope that CouchDB's bylaws are not adopted as a template for others,
as I believe that the rule on committer voting is counter to an
important institutional tradition in Apache governance.
Occasionally you reach an impasse where someone is holding out and
consensus cannot be reached. At that point, I've seen communities
define a specific supermajority threshold instead of requiring "3 +1
with no vetoes".
In the abstract, it would be nice if the supermajority rule were
codified on voting.html, giving communities a template for resolving
the impasse without thrashing. But ultimately, these votes are not
legally binding and PMCs can be afforded a certain amount of
flexibility. The Board cares that communities make personnel decisions
by consensus, but "consensus" has a little give in it.
(PMC votes on new PMC members are technically recommendations to the
Board and officially it is the Board that makes decisions on PMC
composition -- though the Board nearly always follows the PMC
recommendation. Committer votes do not go through the Board.)
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Vetoes for New Committers??
Posted by Shane Curcuru <as...@shanecurcuru.org>.
Joan Touzet wrote on 3/28/17 8:34 PM:
> Apache CouchDB does not allow vetos on new committer votes.
> You can read our policy on all vote types here:
>
> https://couchdb.apache.org/bylaws.html#types
>
> I encourage all other projects to make public a similar summary of
> their guidelines. This table alone has helped eliminate a LOT of
> confusion when it comes time to voting on our project.
Having project bylaws - even if merely pointing to another project's
bylaws - is an excellent way to ensure everyone knows the ground rules.
It's even in the official board resolution for new projects:
> RESOLVED, that the initial Apache NAME PMC be and hereby is
> tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> Apache NAME Project; and be it further
Many projects do have bylaws published, but some seem to simply be
copy/paste and might not be... actively used.
But the CouchDB ones look great - and it seems a number of projects have
already copied them. IT would be a neat project to take those bylaws
and check them someplace as a "here's a sample set of bylaws to start
with" in Incubator land, so podlings have an example. I bet if it were
simple to promote the docs to new websites, a lot of projects would just
use those.
--
- Shane
https://www.apache.org/foundation/marks/resources
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Vetoes for New Committers??
Posted by Joan Touzet <jo...@lrtw.org>.
Apache CouchDB does not allow vetos on new committer votes.
You can read our policy on all vote types here:
https://couchdb.apache.org/bylaws.html#types
I encourage all other projects to make public a similar summary of
their guidelines. This table alone has helped eliminate a LOT of
confusion when it comes time to voting on our project.
-Joan
----- Original Message -----
> From: "John D. Ament" <jo...@apache.org>
> To: dev@community.apache.org
> Sent: Tuesday, March 28, 2017 8:15:33 PM
> Subject: Re: Vetoes for New Committers??
>
> I asked a similar question on another list some time back, around
> voting in
> new committers. I'm not going to share that thread (public vs
> private) but
> I think the advice i got from it was spot on. In addition, I've
> heard
> great additional feedback on other threads.
>
> Projects want committers who are infrequent, but able to contribute.
> They
> want PMC members who are consistent and dedicated to the project.
> You want
> some form of consensus though through the addition of a committer.
> IF
> someone has serious concerns, and is unwilling to change their vote,
> you
> may want to hold off and monitor a bit further to see when that
> person
> passes that threshold to become a committer. You have to have a
> clear
> understanding through the community though to understand why the
> person
> voting -1 feels strongly that way, in addition to not scaring the
> person
> voting into withdrawing their vote - it could be a legitimate issue.
> Though ideally, your discussion thread would flesh something like
> this out.
>
> John
>
> On Tue, Mar 28, 2017 at 8:04 PM Niclas Hedhman <ni...@hedhman.org>
> wrote:
>
> > Hi,
> > on
> > https://community.apache.org/newcommitter.html#new-committer-process
> > it
> > describes the process of bringing in a new committer for a "typical
> > project".
> >
> > But in the "Discussion" it speaks of "3 +1 and no vetoes"... Is it
> > really
> > "typical" that projects use vetoes for new committers? I can't
> > recall
> > seeing that anywhere, not saying it is incorrect, but asking
> > whether it
> > really is "typical".
> >
> > Perhaps we should provide links to a handful of well-known
> > project's
> > processes, to both give a template for projects to work with as
> > well as
> > different approaches.
> >
> > Anyone has any opinion on this matter?
> >
> > Cheers
> > --
> > Niclas Hedhman, Software Developer
> > http://polygene.apache.org - New Energy for Java
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Vetoes for New Committers??
Posted by "John D. Ament" <jo...@apache.org>.
I asked a similar question on another list some time back, around voting in
new committers. I'm not going to share that thread (public vs private) but
I think the advice i got from it was spot on. In addition, I've heard
great additional feedback on other threads.
Projects want committers who are infrequent, but able to contribute. They
want PMC members who are consistent and dedicated to the project. You want
some form of consensus though through the addition of a committer. IF
someone has serious concerns, and is unwilling to change their vote, you
may want to hold off and monitor a bit further to see when that person
passes that threshold to become a committer. You have to have a clear
understanding through the community though to understand why the person
voting -1 feels strongly that way, in addition to not scaring the person
voting into withdrawing their vote - it could be a legitimate issue.
Though ideally, your discussion thread would flesh something like this out.
John
On Tue, Mar 28, 2017 at 8:04 PM Niclas Hedhman <ni...@hedhman.org> wrote:
> Hi,
> on https://community.apache.org/newcommitter.html#new-committer-process it
> describes the process of bringing in a new committer for a "typical
> project".
>
> But in the "Discussion" it speaks of "3 +1 and no vetoes"... Is it really
> "typical" that projects use vetoes for new committers? I can't recall
> seeing that anywhere, not saying it is incorrect, but asking whether it
> really is "typical".
>
> Perhaps we should provide links to a handful of well-known project's
> processes, to both give a template for projects to work with as well as
> different approaches.
>
> Anyone has any opinion on this matter?
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>
Re: Vetoes for New Committers??
Posted by Phil Steitz <ph...@gmail.com>.
On 3/29/17 6:32 AM, Bertrand Delacretaz wrote:
> On Wed, Mar 29, 2017 at 2:03 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
>> ...it speaks of "3 +1 and no vetoes"... Is it really
>> "typical" that projects use vetoes for new committers?...
> I like the "vetoes are only for code commits" rule that
> https://www.apache.org/foundation/voting.html defines, at least
> implicitly.
>
> In the case of committer votes, I think a PMC must take objections
> into account even if they are not considered formal vetoes.
+1
I see this as similar to releases. Technically, releases can move
forward in the presence of -1's; but it rarely happens. Much better
is to get to consensus on whatever is behind the -1 and agree to
hold on the action or take steps to address the -1.
Phil
>
> But that's a community management / health thing, not a formal mechanism IMO.
>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
> .
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Vetoes for New Committers??
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Mar 29, 2017 at 2:03 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> ...it speaks of "3 +1 and no vetoes"... Is it really
> "typical" that projects use vetoes for new committers?...
I like the "vetoes are only for code commits" rule that
https://www.apache.org/foundation/voting.html defines, at least
implicitly.
In the case of committer votes, I think a PMC must take objections
into account even if they are not considered formal vetoes.
But that's a community management / health thing, not a formal mechanism IMO.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org