Bugzilla Updates

Michael Tremer michael.tremer at ipfire.org
Fri Jun 2 16:51:48 CEST 2017

Hello fellow developers,

I just implemented a few changes into our Bugzilla instance that I have been
wanting to do for a long time now.

The motivation for this is that most reporters just create a new bug and set the
priority and severity to "highest." Of the course the latest bug report is
always the most important one. When there is no reaction after a day, some
people even complain and refer to the priority being high.

Obviously all of this doesn't even help anyone.

However, there are a lot of bugs in Bugzilla. And that is first of all a good
thing. Every documented problem is something that we can deal better with. Even
if we don't resolve it straight away.

But there are also quite important bugs that need quicker attention. For this,
the priority and severity settings were initially designed, but as pointed out
above they are hard to use.

So I came up with a new concept. This is not brilliantly new, but at least new
for us here at IPFire:

Instead of having options for "Priority" from "lowest", "low", "normal", "high",
"highest", we can now pick between these options:

  * Will affect all users
  * Will affect most users 
  * Will affect an average number of users
  * Will only affect a few users
  * Will affect almost no one

I think this is self-explanatory and just makes clear what this field is for:
Determining how many people are affected by a certain problem.

The severity field had "low" to "important" as well, but now has been changed

  * Documentation
  * Localization
  * Aesthetic Issue
  * Balancing
  * Minor Usability
  * Major Usability
  * Crash

So this will help us to determine how bad a certain problem is and if there is a
way to work around it or not.

The combination of both of them really shows us how important a bug is. For
example if you have a Crash that affects all users that is quite bad. If you
have a Crash that only affects a few users, this has a rather low importance.

So far most bugs are a little bit all over the place since I did not always
change these fields back to normal levels and now translated them from the
original values to the new ones.

Hope this all makes sense for you as well. If there are any questions or
comments, please email back!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ipfire.org/pipermail/development/attachments/20170602/20f8cee5/attachment.sig>

More information about the Development mailing list