Template:Issues organization

Issue reporting
This page is n on what you should and shouldn't add to this page.

Isue repots should If you are unsure of an issue, it's good practice to post abut it on the |talk page to see whether others can reproduce it.

Whn ading yo isue repot:
 * 1) Read through the lit o knon isues firs to chck that your isue has not alread beesubtted.t has, add any extra information as a comment to the current submi.
 * 2) Always prepend your report with one or more ''o that wmments underneath your report requesting clarification or more information.

Isue reprts tht d nt povide enugh usful iformation o cntain to mch opiionated or anecdotal wafle my b subjct t remval.

Commenting
When commenting on issue reports:
 * 1) Prepend your comment point with an indented bullet point using the code ":*".
 * 2) Place the comment directly below the issue report in question. Do not leave an empty line between issue report and comment, or between comments themselves.
 * 3) Sign the comment with  --~ . This is a deliberate exception to the usual wiki conventions; normally you should only add signatures to content on talk pages.

Please don't let debates about whether something is or is not a bug get out of hand. (Also, note that if an issue is not a bug, it may still be a valid annoyance.) Similarly, don't clog issue reports with discussions of workarounds or possible fixes. If a bug or annoyance exceeds 10-12 lines of follow-up comments, move the entire follow-up discussion to the talk page and link to the discussion under the original issue report.

Page moderation
Please do not spontaneously delete an issue report unless it is blatant nonsense submitted by an unregistered user. Try to contact the submitter by user-talk first and tell them about your concerns. Almost all active submitters will be cooperative. Always assume good faith.

You may also leave a comment explaining why you feel the issue should be removed, allowing time for others to weigh in on the decision or for the original poster to give additional information. Where possible, removal of a issue should be a group decision, not a decision made by a single individual.

Please make sure issues are given the correct category, type, and priority: issues with blocks go in the Blocks section, issues with mobs go into the Mobs section, and so on. List bugs in order of importance ( !! > ! > undefined). Annoyances go into the Annoyances subsection, with major ones A! before minor ones A. Issues that Mojang have marked as fixed or skipped are moved to the Fixed/Skipped section. Issues that Mojang cannot reproduce should be left in their original place.

If a new version of Minecraft is released, create that page with for full release pages and  for developmental pages, such as weekly releases. Changes to this header should be made by editing this template.

Issue labels
Use issue labels to indicate the importance and nature of a bug.

Mandatory issue labels come first, and must be one of the following:
 * !! =  !!  = Critical bug that can crash a Minecraft client or server.
 * ! =  !  = Major bug. Use this tag sparingly; if there is consensus your bug is not major, it will be downgraded.
 * a! =  a!  = Major annoyance. Think very carefully before flagging an annoyance as major.  Is it really more important than most minor bugs?  Use this tag sparingly; if there is consensus your annoyance is not major, it will be downgraded.
 * undefined =  undefined  = Minor bug.
 * a =  a  = Annoyance. Note that this is not the same as feature requests, which is not what this page is for. Remember, leave gameplay ideas/solutions up to the developers.

Optional labels can be added after mandatory labels.

Some issues appear only in certain game modes. Such an issue should be flagged with one or more game mode labels, indicating which modes it is restricted to. If the issue appears in all modes, do not mark it with any of these labels. (So, for example, a minor annoyance which appears in both single- and multi-player, but is restricted to creative mode, should be flagged as acr, not aspmpcr.)

Labels for indicating that an issue happens only in a particular game mode:
 * sp =  sp  = Single-player.
 * mp =  mp </tt> = Multiplayer.
 * su =  su </tt> = Survival mode.
 * cr =  cr </tt> = Creative mode.
 * ad =  ad </tt> = Adventure mode.
 * lan =  lan </tt> = LAN Multiplayer on a singleplayer world.

Merge above labels if you can:
 * asp =  asp </tt> = Adventure single-player.
 * amp =  amp </tt> = Adventure multiplayer.
 * csp =  csp </tt> = Creative single-player.
 * cmp =  cmp </tt> = Creative multiplayer.
 * ssp =  ssp </tt> = Survival single-player.
 * smp =  smp </tt> = Survival multiplayer.

Label for indication that an issue happens only in a particular map:
 * csm =  csm </tt> = Custom maps only.

Labels for indicating that an issue is restricted to a particular OS:
 * =  </tt> = Mac OS X
 * =  </tt> = Windows
 * =  </tt> = GNU/Linux

Label if you see a modded client/server bug report:
 * mod =  mod </tt> = Modded.

In addition, ? = <tt> ? </tt> can be added to tag an issue that you are unsure of or that the community (on the discussion page) believes requires further vetting. Do not use this label to indicate this-is-not-a-bug. Instead, replace the issue's current label with a or a!. Furthermore, it is inappropriate to use this to flag something you disagree with. Instead, express your opinion in a comment.

To produce these labels, use the following code: <tt> </tt>c<tt> </tt> where c is the code of the label you wish to use. (e.g., a for annoyances, etc.)

The default issue type is minor bug; you can produce this label with the shorthand <tt> undefined </tt>.

Further information is available at Classifying bugs.