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
