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". 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.

On Monday, 18 July 2022 at 11:28:52 UTC, Dukc wrote:

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.

On Monday, 18 July 2022 at 11:28:52 UTC, Dukc wrote:

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

On Monday, 18 July 2022 at 14:44:53 UTC, RazvanN wrote:

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.

On Thursday, 21 July 2022 at 19:26:10 UTC, Dukc wrote:

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

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

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.