[Koha] [Koha-devel] [corrected] Koha 3.0 Stable Release Plan

Wed Jun 4 20:56:04 NZST 2008

Oops, I meant Koha 3.0.1 where I wrote 3.1 in my previous message.  The
corrected message follows.

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.0.1-.  If the standard
for 3.0 is much lower than for 3.0.1-, then 3.0 may be suitable for
libraries which have essentially already decided to commit to Koha. 
3.0.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.0.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.0.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
> jmf at liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha.org
> http://lists.koha.org/mailman/listinfo/koha-devel
>