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

[Thomas Dukleth]

Reply inline:


On Wed, June 4, 2008 1:33 pm, MJ Ray wrote:
> "Thomas Dukleth" <kohadevel at agogme.com> 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