Issues/Classifying bugs

From Minecraft Wiki
< Issues(Redirected from Help:Classifying bugs)
Jump to: navigation, search
This guide refers to an outdated wiki feature.
All bugs are now reported on the bug tracker, not this wiki.

This page gives some more detailed guidance for the non-technically inclined on how to grade bugs and annoyances accurately.

Bug: A basic definition[edit]

When we talk about a 'bug', the term has two common meanings: either a computer program is doing something it shouldn't do, or it isn't doing something it should.

The first case is quite clear-cut, provided you can reproduce the behavior. If you can do so, you can catch the program actively doing something wrong. Once a developer can see the problem, it's quite easy for them to accept that it's a bug, and fix it, or confirm that it's not a bug (denoted with [N] ) and the program really is doing what it's supposed to.

The second case is harder to prove, because there are several possibilities:

  1. Program code has been written to do whatever-it-is, but it isn't working properly. This is also a genuine bug.
  2. Due to an oversight, no code has been written to do whatever-it-is. This is also a bug, but it's an error of omission rather than an active mistake.
  3. No code has been written yet to do whatever-it-is, although it may be planned for the future. This is better classed as a missing feature, as there aren't necessarily any errors in the program code.
  4. No code has been written to do whatever-it-is, and none is planned. So this issue is intentional, not an error or omission.

Unfortunately, when reporting bugs of the second kind it can be difficult to distinguish between these four options. There will be occasional disagreements. As far as possible, please try to avoid reporting 'bugs' that fall under cases 3 or 4. If one of these issues really spoils the game for you, submit it as an annoyance.

Bug severity[edit]

Crash bugs[edit]

The most severe types of bugs, Crash Bugs are flagged with [!!] . Do not mark a bug with [!!] unless it results in the Minecraft game crashing, or your bug will be downgraded.

When we say 'crash bug', we mean the Minecraft game stops running and you have to restart it and re-select a saved game before you can continue playing.

Severe bugs[edit]

Severe bugs are marked with [!] . To qualify as severe, a bug needs to result in:

  • Loss of data, as in the case of a corrupted or unloadable saved game.
  • The game becoming unplayable, because you can't move, can't see, can't break or place blocks, the frame rate drops to less than 2-3 frames per second, or some other fundamental part of the game doesn't work properly.
  • Instant death without warning and without any way to work around it. This is a legitimate issue because if you die in hardcore mode, your saved game is deleted, so a death without warning results in a loss of data. Such problems must be reproducible or they will be assumed to be player error rather than a bug and will be disregarded.
  • A major feature or part of the game being broken. Deciding what features are "major" can often be a contentious opinion-based issue. If in doubt, mark the bug as minor to start with and suggest that it should be upgraded.

Minor bugs[edit]

All other bugs (including otherwise 'severe' bugs where there's a feasible workaround), are classed as minor bugs [X] . Most bugs should fall into this category.

Annoyance: A basic definition[edit]

If you're reasonably sure something doesn't count as a bug, but it impairs your enjoyment, you can class it as an annoyance. An annoyance is something the game does that you wish it wouldn't, or something the game doesn't do that you strongly feel it should. Sometimes the only difference between an 'annoyance' and a 'feature request' is that an annoyance complains about something that isn't present, whereas a feature request asks for that something to be added.

To qualify as a real annoyance, the problem has to be one that spoils your enjoyment. If you merely think, 'Wouldn't it be great if...' then that's a feature request, and they are not currently tracked in the Known Bugs pages.

Major annoyance[edit]

Major annoyances are marked with [A!] . To qualify as a major annoyance, a problem has be more intrusive than a minor bug. There also needs to be no easy way to work around it, or the advised solution is likely to be 'Don't do that then'. If there is consensus that a major annoyance isn't major, it will be downgraded.

Minor annoyance[edit]

Minor niggles with the game, that you are reasonably sure are not bugs, are classed as minor annoyances [A] . Please try to avoid mis-classifying bugs as annoyances, and vice versa. If it's an error, even something tiny like a single letter typo in an item name, it's a bug, and it should be flagged as such. If you incorrectly flag a bug as an annoyance, then by the very rules of the wiki Mojang can't mark it with [N] for 'Not a Bug'. Therefore it's important to classify things correctly, and not misuse 'annoyance' as a category for really really minor bugs.

More on the [F] and [N] codes[edit]

When a bug is marked [F] that means it's been fixed for the next release. Note that it won't magically start working in the current version of the game. You still have to wait for a new version that actually contains the correction.

When Mojang marks a bug with [N] , that means it's not a bug in the Minecraft game. But Minecraft uses some external resources such as the LWJGL (LightWeight Java Game Library). Sometimes there will be a problem in one of these external resources, and in these cases Mojang may not be able to fix or work around the problem because it's in a piece of program code they don't control.

Changing others' reports[edit]

Be careful about re-classifying bugs and annoyances reported by others. If a bug or annoyance report breaks the guidelines given on this page, it's OK to correct it, but if there is any doubt you should defer to the person who originally reported the problem. In particular, if they called it a bug, don't change it to an annoyance. If the bug is questionable (i.e. you can't reproduce it, or you don't think it's a bug), add a [?] flag and a comment to it, as in the example below. If you anticipate lots of discussion, make a link to the Known bugs talk page for that release and copy the bug report there into its own section before the discussion grows to a distracting size. If you can reproduce or confirm something marked as 'questionable', add a suitable comment and remove the [?] annotation.

Example

The following example demonstrates correct use of the [?] tag. Each user provides some helpful information which the next person is able to build on, refining the initial bug report.

A user starts by reporting a bug:

[X] <Initial bug report> --[A User]


Some time later, a follow-up is added:

[X] [?] <Initial bug report> --[A User]

  • <Tried X, Y and then Z, could not reproduce. Marking as {?}> --[Another User]


Then, later still, a second follow-up is added:

[X] <Initial bug report> --[A User]

  • <Tried X, Y and then Z, could not reproduce. Marking as {?}> --[Another User]
  • <Confirmed initial bug, described reliable way to reproduce. Removed {?}> --[Third User]