On Wed, 2004-05-05 at 10:13, Richard Fateman wrote:
> I don't feel strongly about this %in business,
> but sometimes we may have competing plausible
> proposals and we have to decide.
Yes.
> Presumably anyone with CVS access can make a
> decision, though anyone else with similar access
> can change it back...
Correct. Ultimately, I will decide, because I not only have CVS access,
I also have control over who *else* has CVS access. (I would insert a
smiley face here if I didn't find them unbearably cutesy.)
> Reaching consensus is nice, but
> did we ever decide how to make decisions? Do we
> vote? Whose votes count?
It's a fine question. To date, it has sufficed to let these
conversations continue after a majority opinion emerges until the
dissenters lose steam. Personally, I try to lay low unless the consensus
appears to be moving in a direction I find unacceptable or an important
point is being missed.
When it comes down to final decisions, the people who contribute most to
the project have the most influence in my mind. There is no formal
process for this, however.
> Is there some open-source
> wisdom around to suggest methods for resolution
> of design disagreements? [Other than
> making a fork in the source and having battles for
> the rest of time, e.g. emacs, xemacs ...]
There is quite a bit of wisdom around, but I don't know that it is
terribly coherent. Here are a few points I have extracted from various
observations on open source projects:
1) Complete democratization of the design process is almost always a
disaster.
2) Avoiding forks is often listed as the primary motivation for
promoting project unity.
3) Forks can occasionally be helpful. I think the egcs fork of gcc is
generally considered to have pushed the entire gcc project forward.
4) The people who do the work have the biggest say.
5) The people who are most closely involved in a project do not
necessarily have the best feeling for problems faced by newcomers.
I don't think there are any easy answers.
> (no urgency to solve this right now, since I
> don't see much of a dispute. Just a thought.
> And this matter can be implemented by a maxima
> init file. ..
Yes. Thank goodness.
--Jim