Re: Queries about release specifications [Was: who gets in and why]

[Mark McLoughlin <mark skynet ie>]

Hi Jody,

On Fri, 30 Aug 2002, Jody Goldberg wrote:

> Poor code is reflected by instability and feature problems.

	Not neccessarily. Its perfectly possible to get an app to a
certain level of acceptability even with poor code. Its future
maintenance and feature addition problems I'm worried about -
particularily when someone else has to take over the maintainership.

> Layering in beaurocracy to verify something that would get weeded on
> other criteria seems like a waste of precious resources.  If the
> community consensus is that a app is viable, then electing a
> collection of 'benevolent code fascists' to override them will not
> help.  Who would want to be put in the position to judge the code ?

	Maintainers review code every day. Mainly because they don't
want to have deal with the poor quality code at a future date. You
want it right the first time. Okay, so a new app is different from a
patch, but I don't see why the same principal wouldn't apply ..

> Lets try to keep the community fun.  If you think an app is crap say
> so with a smile :-)  People will listen.  Don't elect a committee to
> do it.

	Sure, I don't want to make it any less fun. By the sounds of
it, you think ensuring patches get reviewed or having new ideas
reviewed with a GEP makes contributing less fun? I don't - it might
make it a bit more hassle for the contributor but in the long run
makes life a lot easier for everyone.

Good Luck,
Mark the party pooper.