From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Bugzilla Updates
Date: Fri, 02 Jun 2017 15:51:48 +0100 [thread overview]
Message-ID: <1496415108.23621.29.camel@ipfire.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 2313 bytes --]
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
to:
* 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!
Best,
-Michael
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
reply other threads:[~2017-06-02 14:51 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1496415108.23621.29.camel@ipfire.org \
--to=michael.tremer@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox