You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Noah Slater <ns...@apache.org> on 2009/01/02 14:33:05 UTC

Re: Decision making process (Re: Changing rev to _rev in view results (Was: Re: newbie question #1))

On Fri, Jan 02, 2009 at 11:19:18PM +1030, Antony Blakey wrote:
> That would confirm my presumption that it's probably a waste of time pushing
> something that Damien's firmly against, as opposed to expecting to vote on it.

I'm not too sure this is a wise approach. Chris is correct in that we've opted
for following consensus in the past, but that doesn't mean that whatever Damien
says we all agree with. There's still the issue of the JSON newline which has
the committers split right down the middle!

I see that this issue can take one of three possible routes:

  * the PMC decide that consensus is to reject the proposal

  * the PMC decide that opinion is spit and hold an ASF style vote

  * the PMC decide that consensus is to accept the proposal

The PMC comprises me, Chris, Chris, Jan, and Damien.

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.

-- 
Noah Slater, http://tumbolia.org/nslater

Re: Decision making process (Re: Changing rev to _rev in view results (Was: Re: newbie question #1))

Posted by Noah Slater <ns...@apache.org>.
On Sat, Jan 03, 2009 at 12:27:20AM +1030, Antony Blakey wrote:
> Is this voting/decision-making process visible?

Yes, the formal decision making process is visible. However, as a group of
people who work closely together we communicate in lots of other ways, be that
public IRC, private IRC, private email, Twitter, or telephone calls. It is
important that we discuss everything official on the mailing list as per The
Apache Way, but it is a natural consequence of our working together that we
become informally aware of each other's position on various topics. Short of
refusing to discuss CouchDB "in real life," I see this as unavoidable.

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

I guess the best way would be to do a proper proposal and request a vote. This
vote wouldn't be anything official, but it would be an informal way of
soliciting definite feedback from the community and the committers.

> 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 you submitted a patch to the mailing list and requested a vote.

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

Makes sense. I guess that's where a proper proposal would come in.

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

Predictable fashion?

> That in turn makes it less likely that people will contribute, and seem to be
> a strategic weakness.

I'm not sure I follow your reasoning at all.

The way I see it is that if someone suggests something and we all love it, there
is a clear consensus and we would go forward with that. The reverse is also
true. In this particular case it is clear to me that we do not have consensus. I
think part of that may be due to there being no concrete proposal, everyone
seems to be suggesting different things!

We are only at this juncture because nobody can agree on the best way
forwards. All I am saying is that maybe a proper proposal would be a nice idea,
something we can all say "+1" on, or not as the case may be. If you asked me now
what my thoughts were on the whole topic I would tell you that I don't know,
because I'm not even sure what the agreed proposal is, let alone the agreed
consensus is.

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

This process is already in place! Heh. All anyone has to do is write up a
concrete proposal of the changes and submit it to the mailing list requesting a
vote. We can move forward from there. If there are comments about the proposal,
the sponsor could collect them and draft a new proposal. Rinse and repeat.

-- 
Noah Slater, http://tumbolia.org/nslater

Re: Decision making process (Re: Changing rev to _rev in view results (Was: Re: newbie question #1))

Posted by Antony Blakey <an...@gmail.com>.
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