Fix it before moving ahead

[Rob Cozens]

>>It shouldn't be a democratic issue...I think they
>>should _all_ be fixed.
>
>I don't normally quote the whole of another person's mail, but I 
>agree so strongly with this that I really want it broadcast. I also 
>think that the idea of voting for a bug to be fixed is deeply flawed 
>if it doesn't take into account the severity of the bug, which can 
>vary from an unimportant cosmetic problem in the IDE (the fixing of 
>which might attract a lot of votes) all the way to a complete 
>showstopper

Graham, Ken, et al:

Note that the two of you are _not_ saying the same thing:

Ken:  "they should _all_ be fixed"

Graham "voting for a bug to be fixed is deeply flawed if it doesn't 
take into account the severity"

My response to Ken's comments, as posted to improve-revolution:

<<
>What good are more features if your user's application, or worse yet, their
>machines, crash because of a bug that should have been fixed by now?

Ken, et al:

Perhaps one reason why I have a lesser sense of urgency toward fixing 
all known bugs before addressing any enhancements is that, AFAIK, 
none of the known bugs crash my applications or the computers they 
run on: the bugs relate to the Rev Dev environment, not to the 
MetaCard runtime environment.

I can cause the development environment to fail in a number of ways; 
however, I cannot cause my debugged standalones to crash.  Albeit, 
I'm not using QuickTime, any SQL interface, unicode, rtf or html 
text, or doing CGI; but virtually nothing I've created in Revolution 
is subject to engine-related failure at runtime.

So, while I agree that any bug that manifests itself at standalone 
runtime and for which there is no easy workaround should be addressed 
before enhancements, I can live with flaws in the Rev Dev environment 
(eg: Rev 2.1.2 on Mac OS X hangs when opening a stack with a 
breakpoint if it is already in debug mode), if the majority of Rev 
developers feel completing some enhancement is more important than 
squashing that bug.
<<

On that basis, Graham, it seems to me you are closer to my position 
then Ken's.  In my original post to the thread, I opined, "And while 
strict democracy should not be the deciding factor in what gets fixed 
or added when, it certainly is an expression of where the user 
community in general wants Revolution's resources focused."

Utilization of limited resources is, and probably always will be, a 
sticky issue for RR Ltd.  Would you prefer they make decisions in a 
vacuum, on the basis of the level of vocality of individual users, or 
via a mechanism whereby all users are offered the opportunity to 
provide feedback on prioritizing all pending issues?  Should an 
obscure bug that knocks one developer dead in the water take 
precedence over a less severe bug that 80% of developers want fixed? 
Is it better to spend one person week fixing the one developer's bug 
or five person days fixing five (or 10) less critical ones?

I don't know the "correct" answers to these questions; but I feel the 
broader the base providing input to the Run Rev team, the better 
their decisions will be.

Cheers!
-- 

Rob Cozens
CCW, Serendipity Software Company
http://www.oenolog.net/who.htm

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)