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 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.

> 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