Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of antony.blakey@gmail.com
 designates 209.85.198.228 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=Jr4D2Z6qJ8Ubd/H7Lgx9TT8bUZkfkQX6H3lt188157OKWNu8CDC9SrHtpr/mBR8lGO
         6iO2F0wtb7+MCXyZpeLIK06cQ8Xlspv8eKxOirwe6yE8n1QI0UQrEDX2eXI132Ngmk4r
         c7VxWyxgYs8BWjg8irR4+20qAbMeiBtnjFRKo=
Message-Id: <EF9385B8-EBBB-4A98-9BE5-C452B2C7297E@gmail.com>
From: Antony Blakey <antony.blakey@gmail.com>
To: user@couchdb.apache.org
In-Reply-To: <20090102133304.GD20892@tumbolia.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Decision making process (Re: Changing rev to _rev in view results
 (Was: Re: newbie question #1))
Date: Sat, 3 Jan 2009 00:27:20 +1030
References: <34FCDB16-6D06-4401-BCD8-0B053E2E935E@gmail.com>
 <48250456-2512-46BD-85E1-464457DBC995@pobox.com>
 <ACABD1CE-2E8E-491A-95C0-959820FBAA08@gmail.com>
 <AC6694DA-BA29-4D7E-A90E-31ABD10E1A9F@pobox.com>
 <A8DDC611-3621-4BCA-B053-3CDE0308AEE6@gmail.com>
 <20090102034756.GJ2520@tumbolia.org>
 <62D1E488-D052-4389-B61C-3FBD0D24F4AC@gmail.com>
 <6F9AE5BB-39A3-40D7-8072-A4A4E0D85F4D@pobox.com>
 <e282921e0901020437s6bd52bebqc3250f365a7859cc@mail.gmail.com>
 <B5746C26-37FE-48C2-A4F2-430DC714F2D8@gmail.com>
 <20090102133304.GD20892@tumbolia.org>


On 03/01/2009, at 12:03 AM, Noah Slater wrote:

> It's worth noting that we may never make a decision, or the decision  
> might take
> a long time. Looking back at the newline proposal, we never decided  
> consensus
> was to reject it outright, but we never resolved it the other way  
> either. One of
> us could move to call a vote, but we all feel its better to wait for  
> consensus.

Is this voting/decision-making process visible? If I'm trying to  
effect a change, how can I judge what would get it over the line i.e.  
who objects and for what reasons? How do I ensure that my patch isn't  
stuck in development hell while the PMC (maybe) waits for consensus to  
(maybe never) emerge?

If I have a change in mind, I would prefer where possible to get at  
least a majority of the PMC on side before doing (possibly a lot of)  
work. It looks like it is only when a patch is up for approval that  
any real decision will be made i.e. I can't prompt a decision on the  
metadata thread without doing all the work, which may be pointless.  
That makes a proposal very expensive, especially if the PMC doesn't  
operate in a predictable fashion. That in turn makes it less likely  
that people will contribute, and seem to be a strategic weakness.

IMO an improvement to this process would be a mechanism to submit a  
proposal to the *PMC*, to get some definitive feedback, the contract  
being that I'll do the proposal and the implementation in return for  
the PMC being prepared to give a provisional indication that a) such  
work would not be in vain; or b) the proposal won't be pursued; or c)  
more work is needed, but it's not out of the question; and/or d) some  
comment about what would need to be addressed to move forward. All of  
which is to say: is the PMC reified in some way that doesn't involve  
canvassing each member individually?

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

You can't just ask customers what they want and then try to give that  
to them. By the time you get it built, they'll want something new.
   -- Steve Jobs