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

[Maciej Stachowiak <mjs noisehavoc org>]

On 29Aug2002 06:30PM (-0400), Luis Villa wrote:
> 
> Sounds great. All we need are extensive docs saying exactly what code
> quality is, and someone extensively committed to reviewing and assisting
> new maintainers in this direction, like we do with UI, docs, QA, and
> a11y. 
> 
> <crickets chirping>
> 
> Oh, I forgot to add 'willing to write apps with better code quality when
> they turn down apps that work perfectly well'? Because that would be a
> requirement too. Apps that meet the criteria we've already laid out but
> are rejected in a code review had better have alternatives.
> 
> <crickets chirping>
> 
> So, yes. When there is a code review team, and clear documents on what
> 'good code' is[1], then this sounds like a great idea and I'll support
> it completely[2]. I'm just not terribly holding my breath for such
> things to exist. 

A problem with using "code quality" as a criterion is that to some
extent, it is a matter of taste. It is true that some code will be
easier for most people to read and modify, but this is very hard to
quantify. For example, I'm sure I've written code that I thought was
high quality but which others found confusing and impenetrable, and
vice versa.

On the other hand, things like number of bugs relative to code size or
feature set, rate at which new bugs are introduced, usability
problems, level of documentation, performance, and so forth, are very
concrete.

I think it would be wiser to use these concrete measures to determine
what gets included - it's a lot harder to debate over "it crashes when
I click this button" or "this dialog layout is sloppy" than about
"your identifiers are too long/too short/capitalized wrong".

If there is a code review process, it should be aimed towards helping
people improve their code and their coding, not towards excluding
people. And should be equally applied to things already in the core.

Regards,

Maciej