Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # general >> [DISCUSS] Proposed bylaws for Hadoop


Copy link to this message
-
Re: [DISCUSS] Proposed bylaws for Hadoop
On Wed, Oct 20, 2010 at 3:15 PM, Chris Douglas <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 20, 2010 at 10:14 AM, Nigel Daley <[EMAIL PROTECTED]> wrote:
>> FWIW, "PMC does not generally operate by majority but by consensus." was given as a rationale when explaining to an existing PMC member why it was ok to approve so many new PMC members from a single company.
>
> FWIW, working at the same company doesn't imbue contributors with a
> shared agenda, neither does it rob them of their ability to
> compromise, relieve their concern for the project's health, nor does
> it diminish their respect for other contributors. If individuals from
> that company display any of those traits, then the PMC should address
> them. Equating association and collusion a priori is inadmissible. And
> insulting.
>
> On Wed, Oct 20, 2010 at 2:12 PM, Tom White <[EMAIL PROTECTED]> wrote:
>> I suggest we make this stronger.
>> By way of comparison, the recently enacted bylaws for Pig
>> (http://pig.apache.org/bylaws.html) have consensus, for example.
>
> Consensus is equivalent to making the PMC a permanent appointment.
> Discussions would be more civil and more likely to offer compromise-
> we would actually work toward consensus- if intransigence and
> hostility had consequences. Removing people is a last resort. Moving
> the barrier closer doesn't make it more likely, but it aligns
> incentives so rational people will reign in their more intemperate
> comments and, instead, find ways to make progress.
>
> Many projects require supermajorities or even 3/4 majorities. It's
> sufficiently damning if more than half the PMC thinks an individual is
> so destructive that less damage would be done by ejecting them, in my
> opinion, but again: this is not a facility we should use, or have to
> use. Throwing someone out is an expensive failure for the project, and
> an conspicuous failure of its governance and community. Personally, I
> don't care if it's a majority or a supermajority, but consensus is a
> fig leaf.

Fair point. For a large PMC, that's probably true. This matter was
discussed on the Pig list, and there was a range of opinion there:
http://search-hadoop.com/m/jk35b2tZCuy&subj=RE+DISCUSS+Apache+Pig+bylaws.
Personally, I think a supermajority strikes the right balance.

Tom

>
>> Also, Pig has a minimum length of time for each action, rather than
>> the same fixed number for each. Might be worth considering.
>
> IIRC, the reasoning for a full week in the last thread was to prevent
> national holidays from affecting the definition of "working days." We
> might expedite votes for security/patch releases. -C
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB