You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by "Geir Magnusson Jr." <ge...@pobox.com> on 2009/01/02 13:16:07 UTC
Decision making process (Re: Changing rev to _rev in view results (Was: Re: newbie question #1))
On Jan 2, 2009, at 12:33 AM, Antony Blakey wrote:
>
> It's never been clear to me that there is a process for voting - the
> decision making process within the commit group seems opaque.
How can that be? I assume that all decisions are made in public on
the dev@ mailing list.
geir
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
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 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 "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 2, 2009, at 7:37 AM, Chris Anderson wrote:
> On Fri, Jan 2, 2009 at 4:16 AM, Geir Magnusson Jr. <ge...@pobox.com>
> wrote:
>>
>> On Jan 2, 2009, at 12:33 AM, Antony Blakey wrote:
>>>
>>> It's never been clear to me that there is a process for voting - the
>>> decision making process within the commit group seems opaque.
>>
>> How can that be? I assume that all decisions are made in public on
>> the dev@
>> mailing list.
>>
>
> The committers have a history of deferring to Damien (especially on
> deeply technical matters like the document identity model). It's fair
> to say that most of what we do is bug fixes and the like. When we have
> a new feature or module under development, we like to run the code by
> Damien before we commit it. He understands CouchDB inside and out, and
> he's pretty good at seeing how an API detail or caching property will
> effect the big picture of how people use CouchDB.
That's perfectly reasonable if it's on the dev@ list.
>
>
> There have been votes on the dev list before, but they are rare
> because we so often move with consensus.
That's also perfectly reasonable, and in fact, how I personally like
to participate - it seems that if it comes down to a vote, the
consensus mode has failed.
geir
>
>
> --
> Chris Anderson
> http://jchris.mfdz.com
Re: Decision making process (Re: Changing rev to _rev in view results (Was: Re: newbie question #1))
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 2, 2009, at 7:49 AM, Antony Blakey wrote:
>
> On 02/01/2009, at 11:07 PM, Chris Anderson wrote:
>
>> On Fri, Jan 2, 2009 at 4:16 AM, Geir Magnusson Jr. <ge...@pobox.com>
>> wrote:
>>>
>>> On Jan 2, 2009, at 12:33 AM, Antony Blakey wrote:
>>>>
>>>> It's never been clear to me that there is a process for voting -
>>>> the
>>>> decision making process within the commit group seems opaque.
>>>
>>> How can that be? I assume that all decisions are made in public
>>> on the dev@
>>> mailing list.
>>>
>>
>> The committers have a history of deferring to Damien (especially on
>> deeply technical matters like the document identity model). It's fair
>> to say that most of what we do is bug fixes and the like. When we
>> have
>> a new feature or module under development, we like to run the code by
>> Damien before we commit it. He understands CouchDB inside and out,
>> and
>> he's pretty good at seeing how an API detail or caching property will
>> effect the big picture of how people use CouchDB.
>
> 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.
That would be the case of any committer - anyone can veto a code
change, including one by Damien (Technically it's a PMC member, but
some communities include all committers in this, which IMO is a good
way)
However, the fact that people defer to Damien is perfectly
reasonable. (But remember the goal of an ASF community - you want to
make it strong enough that the original founders/motivators can step
back)
>
>
>> There have been votes on the dev list before, but they are rare
>> because we so often move with consensus.
>
> I'm merely curious bout this, but now that Couch is formally an
> Apache project, is there some Apace mandated consensus-driven
> decision making approach, or do they accept whatever model comes in
> - I'm wondering if the ASF brand might 'mean' something in that
> sense. And I've just noticed that Geir is on the ASF board - he
> should know if anyone does!
I'm not here as anything but an interested user that knows something
about the ASF, and I see in a followup that you found something on the
website :) All is well.
geir
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 02/01/2009, at 11:19 PM, Antony Blakey wrote:
> I'm merely curious bout this, but now that Couch is formally an
> Apache project, is there some Apace mandated consensus-driven
> decision making approach, or do they accept whatever model comes in
> - I'm wondering if the ASF brand might 'mean' something in that
> sense. And I've just noticed that Geir is on the ASF board - he
> should know if anyone does!
Ahh yes, I should have read the Apache site :/ I'll slap my own wrist.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Reflecting on W.H. Auden's contemplation of 'necessary murders' in the
Spanish Civil War, George Orwell wrote that such amorality was only
really possible, 'if you are the kind of person who is always
somewhere else when the trigger is pulled'.
-- John Birmingham, "Appeasing Jakarta"
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 02/01/2009, at 11:07 PM, Chris Anderson wrote:
> On Fri, Jan 2, 2009 at 4:16 AM, Geir Magnusson Jr. <ge...@pobox.com>
> wrote:
>>
>> On Jan 2, 2009, at 12:33 AM, Antony Blakey wrote:
>>>
>>> It's never been clear to me that there is a process for voting - the
>>> decision making process within the commit group seems opaque.
>>
>> How can that be? I assume that all decisions are made in public on
>> the dev@
>> mailing list.
>>
>
> The committers have a history of deferring to Damien (especially on
> deeply technical matters like the document identity model). It's fair
> to say that most of what we do is bug fixes and the like. When we have
> a new feature or module under development, we like to run the code by
> Damien before we commit it. He understands CouchDB inside and out, and
> he's pretty good at seeing how an API detail or caching property will
> effect the big picture of how people use CouchDB.
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.
> There have been votes on the dev list before, but they are rare
> because we so often move with consensus.
I'm merely curious bout this, but now that Couch is formally an Apache
project, is there some Apace mandated consensus-driven decision making
approach, or do they accept whatever model comes in - I'm wondering if
the ASF brand might 'mean' something in that sense. And I've just
noticed that Geir is on the ASF board - he should know if anyone does!
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
The intuitive mind is a sacred gift and the rational mind is a
faithful servant. We have created a society that honours the servant
and has forgotten the gift.
-- Albert Einstein
Re: Decision making process (Re: Changing rev to _rev in view results (Was: Re: newbie question #1))
Posted by Chris Anderson <jc...@gmail.com>.
On Fri, Jan 2, 2009 at 4:16 AM, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> On Jan 2, 2009, at 12:33 AM, Antony Blakey wrote:
>>
>> It's never been clear to me that there is a process for voting - the
>> decision making process within the commit group seems opaque.
>
> How can that be? I assume that all decisions are made in public on the dev@
> mailing list.
>
The committers have a history of deferring to Damien (especially on
deeply technical matters like the document identity model). It's fair
to say that most of what we do is bug fixes and the like. When we have
a new feature or module under development, we like to run the code by
Damien before we commit it. He understands CouchDB inside and out, and
he's pretty good at seeing how an API detail or caching property will
effect the big picture of how people use CouchDB.
There have been votes on the dev list before, but they are rare
because we so often move with consensus.
--
Chris Anderson
http://jchris.mfdz.com