On Wed, Oct 20, 2010 at 10:14 AM, Nigel Daley <nda...@mac.com> 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 <tom.e.wh...@gmail.com> 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
