I notice in the original bug report, Steve Langasek asked for, "I think it
would be better to either not offer users the choice of RC severities in
novice mode, or to only allow users to choose bug severities by
*description* rather than by name."
Then reportbug changed to remove the RC severities entirely, and Steve
remarked, "I said that, in novice mode, users should not be presented with
a list of severities *by name* to pick between because they won't have read
the documentation and won't know what the correct severity is."
Steve, I think that you changed your mind between filing the bug and adding
that comment. However I'm sympathetic to your desire to show RC bug
severities to novice users in a way that allows them to choose them, but
prevents them from choosing them merely due to a sense of self-importance.
I also noticed that the bug severities are listed most-severe first. See
below for a transcript from reportbug (some lines removed). I believe that
this puts the word "critical" at front & center of newcomers' minds, and
that this is a bad idea because it encourages choosing that option.
Therefore, I propose the following change:
- For non-novice users: show the lowest severity first and highest severity
last.
- For novice users: either (A) show the same as we show for all users, now
sorted with lowest severity first, or (B) skip the severity prompt, since
novice users are mostly unable to choose accurately, and tell novice users,
"If you need to change the severity, you can do so after the bug is filed,
or by changing your reportbug configuration level."
Steve, what is your preference between these options? Sandro Tosi, what is
yours?
My personal preference is to change the sorting for non-novice users as
described above, and also to do change the novice form according to option
(B).
Steve, I noticed that you suggested showing the RC bug severities without
their names. I attempted to create a proposed transcript that does that,
but I could not come up with a way to format it that still looked
reasonable to me. So if you can come up with a proposal, great! Until then
I am going to assume there is no reasonable way to do it.
Here's the transcript of current behavior.
<quote>
$ reportbug dracut
[...]
Briefly describe the problem (max. 100 characters allowed). This will be
the bug email subject, so keep the summary as concise as possible, for
example: "fails to send email" or "does not start with -q option specified"
(enter Ctrl+c to
exit reportbug without reporting a bug).
> asdf
Rewriting subject to 'dracut: asdf'
How would you rate the severity of this problem or report?
1 critical makes unrelated software on the system (or the whole
system) break, or causes serious data loss, or introduces a security hole
on systems where you install the package.
2 grave makes the package in question unusable by most or all
users, or causes data loss, or introduces a security hole allowing access
to the accounts of users who use the package.
3 serious is a severe violation of Debian policy (that is, the
problem is a violation of a 'must' or 'required' directive); may or may not
affect the usability of the package. Note that non-severe policy violations
may be
'normal,' 'minor,' or 'wishlist' bugs. (Package
maintainers may also designate other bugs as 'serious' and thus
release-critical; however, end users should not do so.). For the canonical
list of issues worthing a
serious severity you can refer to this webpage:
http://release.debian.org/testing/rc_policy.txt .
4 important a bug which has a major effect on the usability of a
package, without rendering it completely unusable to everyone.
5 does-not-build a bug that stops the package from being built from
source. (This is a 'virtual severity'.)
6 normal a bug that does not undermine the usability of the whole
package; for example, a problem with a particular option or menu item.
7 minor things like spelling mistakes and other minor cosmetic
errors that do not affect the core functionality of the package.
8 wishlist suggestions and requests for new features.
Please select a severity level: [normal]
</quote>
Here's my proposal instead:
<quote>
$ reportbug dracut
[...]
Briefly describe the problem (max. 100 characters allowed). This will be
the bug email subject, so keep the summary as concise as possible, for
example: "fails to send email" or "does not start with -q option specified"
(enter Ctrl+c to
exit reportbug without reporting a bug).
> asdf
Rewriting subject to 'dracut: asdf'
How would you rate the severity of this problem or report?
1 wishlist suggestions and requests for new features.
2 minor things like spelling mistakes and other minor cosmetic
errors that do not affect the core functionality of the package.
3 normal a bug that does not undermine the usability of the whole
package; for example, a problem with a particular option or menu item.
4 does-not-build a bug that stops the package from being built from
source. (This is a 'virtual severity'.)
5 important a bug which has a major effect on the usability of a
package, without rendering it completely unusable to everyone.
6 serious is a severe violation of Debian policy (that is, the
problem is a violation of a 'must' or 'required' directive); may or may not
affect the usability of the package. Note that non-severe policy violations
may be
'normal,' 'minor,' or 'wishlist' bugs. (Package
maintainers may also designate other bugs as 'serious' and thus
release-critical; however, end users should not do so.). For the canonical
list of issues worthing a
serious severity you can refer to this webpage:
http://release.debian.org/testing/rc_policy.txt .
7 grave makes the package in question unusable by most or all
users, or causes data loss, or introduces a security hole allowing access
to the accounts of users who use the package.
8 critical makes unrelated software on the system (or the whole
system) break, or causes serious data loss, or introduces a security hole
on systems where you install the package.
Please select a severity level: [normal]
</quote>
