1. BUG SEVERITY SIGNIFICANTLY UNDER-REPORTED. The severity of many currently reported bugs has been significantly under-reported. If the practical effect of many bugs marked as normal would be considered, they would be found to be blocking or critical for the part of Koha to which they relate. Koha might be modestly usable without those parts, if that was the standard for not considering a bug blocking. but we should not be conceiving of Koha as merely a modestly usable ILS.
By the evidence, most people never bothered to carefully consider the severity of a bug by a functionally useful standard if they bothered to consider changing the default severity at all. The important thing was and is filing the bug at all. Most people might have also presumed that every bug would be evaluated after being reported and that those with the worst effects would be fixed. irrespective of the severity listed. before 3.0 was released as stable. I examined the bug list a few days ago. I did not think I should take it upon myself to change the severity of bugs which I did not report myself without discussing the issue on the mailing list. If I would make appropriate changes to currently reported bugs with my knowledge of the practical effect of many bugs, I would double the number of critical and blocking bugs when adhering to a rather cautious use of those severity levels. 2. STANDARDS OF BUG SEVERITY. For the benefit of those who were not present or do not remember, Joshua Ferraro offered a standard for bug severity on the #koha IRC channel in which almost any bug which was noticed by the librarian would be perceived as critical. Koha has mostly been adopted by libraries which have been somewhat tolerant of bugs or do not recognise bugs which ought to be fairly obvious. The standard which I applied when considering that re-evaluating the severity of reported bugs would double the number of critical and blocking bugs is a much more relaxed standard. By the standard given by Joshua, even the most trivial OPAC bug would be a critical bug. "01/09/06 03:06:53+-5 [kados:#koha] I notice that US companies place more importance on a web presense than French, so perhaps this is part of the difference 01/09/06 03:07:10+-5 [kados:#koha] to a US organization, a website is a core part of the organization 01/09/06 03:07:25+-5 [kados:#koha] and if something on the website seems silly, people perceive the organization to be silly 01/09/06 03:08:12+-5 [kados:#koha] I agree it's not a blocker 01/09/06 03:08:34+-5 [kados:#koha] but it is still critical (the fact that I received two separate bug reports in minutes about this proves it)" 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. In either case, libraries may run in the opposite direction if they do not already have a commitment to Koha. While Koha 3.0 has a much better underlying foundation than 2.2, that foundation is not what the user sees and the foundation will not be appreciated when so many bugs are noticeable. Looking carefully in the way librarians ought to when evaluating an ILS choice, perhaps three times as many bugs could be reported as have been now. I have avoided reporting bugs which I thought would either necessarily be fixed as the particular part of the software became more developed or would have too low a priority for being fixed unless I fixed them myself. (Sadly, I did not have the time to fix for a second time the few OPAC bugs which I had originally fixed around the time of Koha 2.2.3-5 but which reappeared a version or two later. At least now LibLime has someone, Nicole Engard, who has recognised and reported some of them.) I presume that it may be acceptable for Koha 3.0 to have a much lower standard for what counts as a stable release than 3.1-. If the standard for 3.0 is much lower than for 3.1-, then 3.0 may be suitable for libraries which have essentially already decided to commit to Koha. 3.1- could still be attractive to libraries at large when a much larger number of bugs would be fixed, including many bugs which are trivially easy to spot but have not yet been reported. It would be most unfortunate if too many libraries looked at 3.0 and formed an adverse judgement which left them disinclined to give due consideration to 3.1. Unless there are some contractual needs for developers offering support services to have a stable 3.0 release at a much lower standard than 3.1-, I suggest a series of 3.0 release candidates with a more rigorous effort at reporting additional bugs and reporting their severity. Many of the readily noticeable unreported bugs with which I am familiar are easy to fix but merely giving enough attention to fix them necessarily takes time. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783 On Wed, May 21, 2008 1:22 pm, Joshua Ferraro wrote: > Hi folks, > > I've done an audit of the outstanding bugs in Bugzilla and have found > 39 are marked as blocker, major, or critical: > > http://tinyurl.com/5hysmf > > There are an additional 157 marked 'normal': > > http://tinyurl.com/5apjsy > > Galen and I discussed the blocker, major, critical issues and concluded > we could address them with a concerted effort before Monday, June 16th. > I'd like to set that as the date for releasing 3.0-stableRC1, then do a > string > freeze, to allow translators to wrap up any changes to translations, and > then a final 3.0-stable on July 1. > > I do request that those of you using and programming Koha take > a look at the outstanding bugs in both categories, and flesh out any > issues in more detail where you can -- and if you feel a bug in the > 'normal' category should be prioritized, please speak out. > > Thanks to everyone who's contributed, even in small ways, to the > major improvements to this new version of Koha. > > Cheers, > > -- > Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE > CEO migration, training, maintenance, support > LibLime Featuring Koha Open-Source ILS > [EMAIL PROTECTED] |Full Demos at http://liblime.com/koha |1(888)KohaILS > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.koha.org > http://lists.koha.org/mailman/listinfo/koha-devel > _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
