Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Pig >> mail # user >> [DISCUSS] Apache Pig bylaws

Copy link to this message
RE: [DISCUSS] Apache Pig bylaws
I am fine with them "as-is"


-----Original Message-----
From: Alan Gates [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 05, 2010 1:16 PM
To: Thejas M Nair
Subject: Re: [DISCUSS] Apache Pig bylaws

Comments inlined.  However, I feel like we're getting stuck in a  
rathole on this one issue of consensus and 2/3's votes.   So I would  
like to ask two questions now:

1) Are there any other issues besides voting we feel should be  
discussed before we move to a vote?
2) For those who have expressed concern about the voting, are these  
concerns enough to make you not vote for these bylaws, or can you live  
with it as is?  I am concerned that this discussion could go on with  
point and counter point ad infinitum.  I'm more interested in having  
bylaws than in having perfect bylaws.  We can amend them as necessary  
as we go.

On Oct 4, 2010, at 9:28 AM, Thejas M Nair wrote:

> The bylaws look good, but I would like to raise two issues -
> Shouldn¹t the majority requirement for changing the bylaws be more  
> strict
> than those required by the actions in bylaws ?
> For example, the bylaw for removing a committer requires a  
> consensus, but
> for changing this by-law requires only 2/3rd majority. Ie,  
> effectively,
> 2/3rd majority can remove a committer !
> Should changing the bylaws should require consensus as well?

I don't want to make it consensus to change the bylaws, as that would  
make changing bylaws _very_ hard.  I want removing a committer to be  
_very_ hard.

And, in defense of having changing procedure require a lower vote than  
the procedure, I would invoke the practices of the US Senate.  A  
simple majority vote would suffice to remove the need for 3/5 majority  
(60 votes) for cloture, yet even when one party has 50 but not 60  
votes (as has been common lately) neither has removed it for fear of  
having it used against them later.  See http://en.wikipedia.org/wiki/Cloture#United_States
  for details.

> Should we consider another unlikely situation ? - What if two  
> committers are
> unable to communicate for long duration for some reason (stuck on some
> lonely island without internet!)? Actions that require consensus  
> approval
> would not be possible. (you can't remove a inactive voter and then  
> have
> another consensus vote because two voters are missing).
> Should we have a maximum duration for casting votes that require  
> consensus ?
> (2 months ?)

My attempt to deal with the Lost scenario was the addition of the  
sentence saying that votes should not be called when we knew members  
would be unavailable.

Also, I want to clarify the difference between inactive committers/PMC  
members and members being removed.  Moving to emeritus status is  
automatic upon inactivity.  ("A PMC member is considered 'emeritus' by  
their own declaration or by not contributing in any form to the  
project for over six months. An emeritus member may request  
reinstatement to the PMC, which will be sufficient to restore him or  
her to active PMC member.")  Also, moving to emeritus status is not  
considered a bad thing.  It simply reflects that the person is no  
longer able to be a part of the project on a regular basis.  Removing  
someone by vote is a bad thing, akin to being voted off the island (to  
switch island TV show analogies), is certainly not automatic, and  
should only happen in extreme circumstances.