• Dukc (22/22) Jul 18 2022 Apart from regressions being considered the worst bugs, I don't
• Paul Backus (7/13) Jul 18 2022 Personally the only severities I use in my bug reports are
• RazvanN (30/52) Jul 18 2022 Hi Dukc,
• Dukc (16/41) Jul 21 2022 Thanks, these are good starting points in my opinion. I also
• Paul Backus (11/19) Jul 21 2022 IIRC we have a "diagnostic" keyword for issues about error

Dukc <ajieskola gmail.com> writes:

Apart from regressions being considered the worst bugs, I don't 
know of any guideline on evaluating a severity of a bug I'm 
reporting. I feel this is a problem. Because everyone has a 
different perception of what consitutes, for example, a "major" 
bug, this means that two bug reports about the same issue may 
differ by multiple severity levels.

For example, my personal rule has long been "if the compiler 
crashes from using a vanilla, or soon-vanilla (DIP1000) language 
feature, it's automatically critical". But some report those 
issues [as 
"normal"](https://issues.dlang.org/show_bug.cgi?id=19932). I 
don't know which is right, and I don't think anyone else knows 
either.

This means that those who are bold with assigning severity levels 
get more attenton than those who downplay their bugs severity for 
fear of dramamongering accusations, or something. Also it's hard 
to override the severity of bug reports of others even when I 
feel it's wrong, when there is no guideline to say which 
interpretation is right.

Are there any guidelines that I'm not aware of? If not, I think 
they should be laid down. It does not need to be anything 
complex, just several rules and examples to get us started.

Paul Backus <snarwin gmail.com> writes:

On Monday, 18 July 2022 at 11:28:52 UTC, Dukc wrote:
 Apart from regressions being considered the worst bugs, I don't 
 know of any guideline on evaluating a severity of a bug I'm 
 reporting. I feel this is a problem. Because everyone has a 
 different perception of what consitutes, for example, a "major" 
 bug, this means that two bug reports about the same issue may 
 differ by multiple severity levels.

Personally the only severities I use in my bug reports are 
"regression", "normal", and "enhancement".

I have occasionally seen my reports elevated to "major" or 
"critical" when they affect industry users of D. The elevated 
severity does not appear in my experience to have any effect on 
how quickly the issue is resolved.

RazvanN <razvan.nitu1305 gmail.com> writes:

On Monday, 18 July 2022 at 11:28:52 UTC, Dukc wrote:
 Apart from regressions being considered the worst bugs, I don't 
 know of any guideline on evaluating a severity of a bug I'm 
 reporting. I feel this is a problem. Because everyone has a 
 different perception of what consitutes, for example, a "major" 
 bug, this means that two bug reports about the same issue may 
 differ by multiple severity levels.

 For example, my personal rule has long been "if the compiler 
 crashes from using a vanilla, or soon-vanilla (DIP1000) 
 language feature, it's automatically critical". But some report 
 those issues [as 
 "normal"](https://issues.dlang.org/show_bug.cgi?id=19932). I 
 don't know which is right, and I don't think anyone else knows 
 either.

 This means that those who are bold with assigning severity 
 levels get more attenton than those who downplay their bugs 
 severity for fear of dramamongering accusations, or something. 
 Also it's hard to override the severity of bug reports of 
 others even when I feel it's wrong, when there is no guideline 
 to say which interpretation is right.

 Are there any guidelines that I'm not aware of? If not, I think 
 they should be laid down. It does not need to be anything 
 complex, just several rules and examples to get us started.

Hi Dukc,

I spend some time looking through bugs and sorting them. I am 
using some guidelines and I try to be consistent with them, but 
these are my own criteria so take them with a grain of salt.


Enhancement - I use this tag for bug reports that propose a new 
feature or a new extension for an existing feature. So if 
something is proposed but is not covered by the spec, I tag that 
as an enhancement.

Trivial - I use this tag for bug reports where I can evaluate 
that the fix is indeed trivial; for example: a typo in an error 
message, request for fully qualified name for a symbol in an 
error message, adding documentation etc.

Minor - I haven't used this tag ever and I would advocate for 
removing it. In theory, this tag should be used for bug reports 
where the behavior is wrong, but but the outcome is something 
that you can live with. Typically, when the compiler issues an 
error message that is not quite indicative of the problem you 
could tag that error as being minor. :-?

Normal - this is how most of the bugs should be tagged.

Major - this is used for bugs that affect a lot of code but for 
which there exists a work around. Typically, I use the major tag 
for bugs that are reported by industry players.

Critical - ICEs

Blocker - Major issues that have no workarounds

Regression - speaks for itself.

As for when fixing bugs, indeed I look at regressions first and 
then at criticals and blockers.

Hope this helps,
RazvanN

Dukc <ajieskola gmail.com> writes:

On Monday, 18 July 2022 at 14:44:53 UTC, RazvanN wrote:
 Enhancement - I use this tag for bug reports that propose a new 
 feature or a new extension for an existing feature. So if 
 something is proposed but is not covered by the spec, I tag 
 that as an enhancement.

 Trivial - I use this tag for bug reports where I can evaluate 
 that the fix is indeed trivial; for example: a typo in an error 
 message, request for fully qualified name for a symbol in an 
 error message, adding documentation etc.

 Minor - I haven't used this tag ever and I would advocate for 
 removing it. In theory, this tag should be used for bug reports 
 where the behavior is wrong, but but the outcome is something 
 that you can live with. Typically, when the compiler issues an 
 error message that is not quite indicative of the problem you 
 could tag that error as being minor. :-?

 Normal - this is how most of the bugs should be tagged.

 Major - this is used for bugs that affect a lot of code but for 
 which there exists a work around. Typically, I use the major 
 tag for bugs that are reported by industry players.

 Critical - ICEs

 Blocker - Major issues that have no workarounds

 Regression - speaks for itself.

 As for when fixing bugs, indeed I look at regressions first and 
 then at criticals and blockers.

 Hope this helps,
 RazvanN

Thanks, these are good starting points in my opinion. I also 
propose some extra conventions:

  - The regression category is literally for regressions only. The 
blocker category, however, is a generic severity category, 
meaning it's for the most serious non-regression bugs of any 
type. Not just for literal blockers.

  - accepts-invalid or rejects-valid should usually be normal or 
higher. Trivial and minor categories are mainly for minor 
documentation and error message shortcomings.

  - Unsafe code being accepted in ` safe` should be major or 
higher.

  - Compiled code behaving wrong in a way that's likely to go 
undetected (thinking wrong optimisations) is critical or blocker.

  - A security vulnerability (if reported publicly at all) should 
always be a blocker, if it's not a regression.

Paul Backus <snarwin gmail.com> writes:

On Thursday, 21 July 2022 at 19:26:10 UTC, Dukc wrote:
  - accepts-invalid or rejects-valid should usually be normal or 
 higher. Trivial and minor categories are mainly for minor 
 documentation and error message shortcomings.

IIRC we have a "diagnostic" keyword for issues about error 
messages. Might be worth adding a "documentation" keyword as well.

  - Unsafe code being accepted in ` safe` should be major or 
 higher.

You can use the "safe" and "accepts-invalid" keywords for this.

  - Compiled code behaving wrong in a way that's likely to go 
 undetected (thinking wrong optimisations) is critical or 
 blocker.

This is what the "wrong-code" keyword is for.

In general, I think more emphasis should be placed on keywords 
and less on severity levels, since keywords are self-descriptive 
and mostly unambiguous.

Another benefit of keywords is that if/when we migrate from 
Bugzilla to Githhub, keywords can be translated easily into issue 
labels.