Return-Path: 
 <cocoon-dev-return-35940-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 67957 invoked by uid 500); 30 Jan 2003 21:38:41 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 67898 invoked from network); 30 Jan 2003 21:38:39 -0000
X-Injected-Via-Gmane: http://gmane.org/
To: cocoon-dev@xml.apache.org
From: Berin Loritsch <bloritsch@apache.org>
Subject: Re: [PMC] bootstrapping the PMC
Date: Thu, 30 Jan 2003 16:38:39 -0500
Lines: 63
Message-ID: <b1c5tl$pbg$1@main.gmane.org>
References: <3E381983.8030701@apache.org> <3E39969E.2020808@anyware-tech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@main.gmane.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
In-Reply-To: <3E39969E.2020808@anyware-tech.com>
Sender: news <news@main.gmane.org>
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
> 
>> People,
>>
>> since Cocoon got approuved as a top level project, we have a PMC, but 
>> the ASF is designed in such a way that each PMC can choose its own 
>> rules and policies.
> 
> 
> 
> <snip because="agree"/>
> 
>> <added author="SM">
>> Any opposive vote must contain a detailed description of the reasoning 
>> that led to that vote and potentially indicate an alternative proposal 
>> that he/she would favor.
>> </added>
> 
> 
> 
> Requiring explanation of a negative vote is good. However, if the 
> explanation leads to an alternative proposal, that proposal should be 
> discussed separately, in order not to start a discussion within the vote 
> thread (SoC ?).

Keep in mind the purpose of this document.  It is for PMC related
proposals and votes.

That means topics like changing the official PMC documentation (charter
and bylaws), or procedural changes (new mailing list, adding a CVS
repository, etc.).

It is not for general coding directions.  The PMC is not responsible
for code, they are responsible for community.

99.9% of the time, the vote is merely academic because there was
sufficient discussion before the proposal was made a vote.

Usually there are only three reasons for -1 at this stage:

1) The voter is *really* against it for good reasons and his
    advice was not heeded.  This speaks to a community issue,
    because his concerns should already have been addressed.

2) The proposer rushed the proposal through and did not allow
    sufficient time for the community to comment on it.  At that
    time the community may vote -1 to bring it back to proposal
    stage.

3) The voter is merely being obstenant.  The community believes
    that greater good will come because of the proposal, but the
    voter is having a bad day, or doesn't like the proposer.
    Again this is a community issue--and it is a very rare one
    at that.

In all three cases it is a breakdown in communication that
causes the -1.  Unfortunately I have seen all three of these
cases in recent history (not here).  It is more "bureaucratic" than
alot of people like, but it has the purpose to make people think
carefully about actions that will have profound implications
on the community in general.



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org