Reply inline:
On Wed, June 4, 2008 1:33 pm, MJ Ray wrote: > "Thomas Dukleth" <[EMAIL PROTECTED]> wrote: >> 2. STANDARDS OF BUG SEVERITY. >> [..] > I support our current descriptions, which you can find at > http://bugs.koha.org/cgi-bin/bugzilla/page.cgi?id=fields.html#bug_severity > > Blocker Blocks development and/or testing work > Critical crashes, loss of data, severe memory leak > Major major loss of function > Minor minor loss of function, or other problem where easy > workaround > is present > Trivial cosmetic problem like misspelled words or misaligned > text > Enhancement Request for enhancement > This definition seems very reasonable and I was not aware that it was there. By this definition, I would have to include major in my statement about how appropriately reassigning the severity of reported bugs would double the bugs which are at least major. Yet, after exploring a few issues for bugs which I had not tested myself, it seems that some reported bugs which would be at least major seem to have been fixed but not marked as fixed. If more bugs have been fixed but not reported as fixed the overall problem may be much less serious than I had supposed. > I'd suggest that the "librarian noticability" aspect would be better > represented by the bug's Component and possibly the Priority. > I have never known what to do with selecting priority in bug tracking systems so I have usually left it at the default value. A specification for what priority values mean as has already been provided for severity would be helpful. Some higher level of priority should be designated as applicable to even trivial bugs which may lead librarians to not give sufficient consideration to adopting Koha. Some trivial bugs could then appropriately have priority over normal bugs which might not be especially noticeable. >> 3. APPLICATION TO VERSION RELEASES. >> >> The problem here is that libraries are concerned about either how they >> are >> perceived through the software they use or suspicious of deeper problems >> in software when even superficial bugs are noticeable. [...] > > To allay that suspicion, we should be clear in our release notes that > what should be our full list of known bugs is public and available. > I agree that reference to a public bug tracking system should be used to reduce concerns. Public bug tracking is a benefit of free software as opposed to the common proprietary practise. where bugs are a secret and sometimes denied even when obvious and especially when severe. We should be honest about bugs without going out of our way to advertise them so as not to seem adverse to comparable proprietary software where bugs are not disclosed. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783 _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha.org/mailman/listinfo/koha-devel
