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) _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
