Re: Discussing issues

On Mon, Apr 14, 2003 at 10:59:46PM +0100, Alan Hourihane wrote: 
> I don't think anyone would reject obvious code that gives significant
> improvement in how X works.

The hard part is something like STSF/fontconfig, or release schedules,
where either the issue is not technology, or there is real technical
disagreement on the definition of "improvement." 

As Owen said a while back, doing things by consensus works great,
until you don't have consensus. Then you need a mechanism.

Projects that have mechanisms *also* work 99% by consensus. It's just
that in the 1% case, something sane happens. vs. what we now see on
this list, which I would describe as "not sane"

> > It just seems to me that where the code lives is not what people are
> > (primarily) arguing about.
> 
> That's not been made clear at all.

Absolutely! That's why in this post:

http://www.xfree86.org/pipermail/forum/2003-April/001106.html

I said "request did not really get clearly conveyed"

And why I felt that getting people on the phone would help everyone
understand what each side considered to be the important issues.
 
> > When it comes right down to it, there are decisions to make that must
> > be shared decisions. Schedules, module organization, general project
> > goals. "Agree to disagree" works up to a point (and is in fact *good*
> > when it works, because it's more modular/scalable), but it breaks when
> > you need to make a shared decision.
> 
> The point I'm trying to make is that an initial idea tends to go argued
> a lot more without code to back it up. If this code is developed in
> a seperate CVS and shown how implementation works, this gives a much
> better picture on how things are wrapped up, and therefore much less
> likely for the agree/disagree scenario. 

You can't say "show me the code" though when two parties have code,
when some parties think the code that's had is bloat/wrong/whatever,
or for topics such as release schedules, how to organize
lists/bugzilla, etc. - that's why these issues are the ones that are
causing the flames. They are issues where consensus isn't clear and
where saying "you can do that yourself if you want" doesn't make
sense.

Havoc