Minecraft Wiki talk:Style guide/Versions

Proposed new section
I propose an amendment to Minecraft Wiki:Style guide/Versions.


 * Background

Since the announcement of 1.10, several features have been tweeted by the developers as being for 1.10, and several other features have been tweeted, but not mentioned when they would be added to PC.

Among that second category of features, include the Observer block, changes to the Structure block, and Nether Wart blocks.


 * The problem

The 1.10 page has been hit frequently with edits to the Planned Additions and Changes sections:
 * Observer block: Special:Diff/973112, Special:Diff/973132, Special:Diff/973624, Special:Diff/975226, Special:Diff/974930, Special:Diff/975278, Special:Diff/975622
 * Nether Wart blocks: Special:Diff/974348, Special:Diff/974547, Special:Diff/974691, Special:Diff/974747, Special:Diff/974844, Special:Diff/974877, Special:Diff/974930, Special:Diff/974976, Special:Diff/975156, Special:Diff/975226, Special:Diff/975278, Special:Diff/975337, Special:Diff/975620, Special:Diff/975643, Special:Diff/975935, Special:Diff/975940, Special:Diff/975954


 * Attempted solutions so far

Editor's notes have apparently been ineffective. Many of these edits have been due to VisualEditor, which does not make editor's notes obvious; they are effectively invisible to these editors.

We have just had to continue to revert these edits.


 * My own thoughts on why this problem is happening

I believe such people look at the page, and see simply that, for instance, Nether Wart blocks are not mentioned, and put an entry into the Planned Additions section.

I have the feeling that the majority of occasional editors are only slightly aware, if at all, of our Mentioned features page, and the distinction we try to strictly maintain, and this unawareness, in turn, is another reason they make that edit.

People who do see the notes know about the policy can still believe that the features are confirmed for 1.10.
 * It's my belief that most people can easily get the impression that since the developers tweeted it during 1.10 development, that means it's confirmed. This can lead to the editor note not preventing them from adding it.
 * If you look at who is adding the edits, it's sometimes even regular editors as well as casual editors.


 * Proposed solutions so far

On Talk:1.10, it was suggested that a link on the page to Mentioned features might be enough to stave off these edits.

I offer my criticism of that suggestion: For a person who scans the page looking for Nether Wart blocks, not seeing any specific mention of it, and not knowing enough about our policy to also consider the mentioned features page, that link will likely do nothing to stop them making their edit.


 * My proposed solution

It would be nice if something were stated on the page about those blocks, listing those blocks, stating they are not, in fact, stated as coming in 1.10, but instead have only been mentioned in the course of 1.10 development.

I do not propose muddling the meaning of the guidelines, or making changes to that at all. I fully believe it's important to be clear about what's planned and stated, with good references.

I do not propose a specific case-by-case exception to be made, temporarily, for the 1.10 page; I like it when rules are clear and can work well without exception, so I am proposing an amendment to the rules.

I propose a new section where such features and their status could be stated.

I believe that if editors read the text of the page, they would then easily find the mention of Nether Wart blocks. Furthermore, their mistaken impression that they're confirmed would be corrected, since we could include references and so forth.


 * Specific proposal

A new top-level section shall be permitted, called "Unconfirmed features".

It would be allowed only for versions in development. It would only be permitted to contain features mentioned since that version started development, and only those that were never confirmed as planned / upcoming, and only those that were never released in a development version, and only those not explicitly promised for a different version. Added 21:24, 10 May 2016 (UTC)

It should start with the text: "These features were never confirmed for 1.10, but developers have shown screenshots or discussed adding them during 1.10 development. Main article: Mentioned features Changed 04:38, 11 May 2016 (UTC)''

It should be concise -- It should not allow a big, multi-line description of each block / item / feature, as if we were detailing it fully. It would just be, for instance, "Taiga villages", "Observer block", etc -- because the purpose of this section is really to just state that these are unconfirmed features, and you shouldn't confuse them with confirmed features, the purpose is not to document the nitty gritty details. That can be done at mentioned features.

The features should be supported either by either:
 * a (non-joke) screenshot showing that a developer has worked on the idea
 * a developer's statement indicating they do plan to add the feature, not merely a statement responding to another person's idea. Added 21:24, 10 May 2016 (UTC)


 * Example

Unconfirmed features ''These features were never confirmed for 1.10, but developers have shown screenshots or discussed adding them during 1.10 development. Main article: Mentioned features''
 * Taiga villages
 * Jeb indicates he is "Not sure yet"
 * 'Observer' block
 * Jeb indicates it will come to PC 'eventually'
 * Two new blocks crafted from Nether Wart
 * Never specifically stated as coming in 1.10


 * Strengths of this proposal


 * It can directly educate the casual editor of the difference between confirmed and not-confirmed, a long-term benefit.
 * It can acknowledge the existence of the feature, and accurately describe its 'unconfirmed' status -- not leaving a reader with the impression that the wiki might be incomplete.
 * It communicates facts about the development of the version, and so, while it's definitely just a 'mentioned feature', it's also a 'feature mentioned during 1.10 development' and so it has a natural place on the page, from that perspective.
 * It doesn't encourage duplication of content, because it's simply naming some features, describing their status, and pointing to the main 'Mentioned features' page, where the screenshots and full details could be.
 * For all of the above reasons, it will probably stop people making so many edits to Planned Additions and Changes, which is the goal.

Submitted for your consideration, – Sealbudsman talk/contr 19:33, 8 May 2016 (UTC)

---


 * The original reason I proposed the planned additions/changes sections was for a similar purpose as this, basically editors kept adding features to the update article with no distinction of what was added, what was planned, and what was unsourced.
 * Along those lines, I think the section looks pretty good and should help with the issue of editors adding unconfirmed features. It might even be worth adding sectional links to Mentioned features for the features just so users can be directed to the exact location with more information. My only concern is to make sure features are actually have something to show the developer is planning them for some update soon and its not just a random idea they mentioned, basically not adding features where someones asks a dev on twitter "please add this" and the dev responds with "maybe" or "I like the idea".
 * On a related note, it might be worth combining planned additions and planned changes into planned features, as there is rarely enough content for both there and the difference when unadded is a little arbitrary at times
 * – KnightMiner  · (t) 03:50, 9 May 2016 (UTC)


 * Regarding the concern; I agree; proposal amended, shown in green . – Sealbudsman talk/contr 21:24, 10 May 2016 (UTC)


 * I agree with this change, and think it could work very well. Maybe we could also have links to the Pocket Edition pages for some features that were confirmed for 0.15.0, but not 1.10? Anyway, this would work out great and I hope it is implemented. Who decides whether these things gets changed? -PancakeIdentity (talk) 20:08, 10 May 2016 (UTC)


 * If there's a consensus that people are okay with it / like it / won't oppose it, I think it's just as simple as agreeing on some wording, and once that's done, updating the Style Guide page. I think we're a little ways away from that; there's only 2 in support (3 including me) and personally I think it would be more credible if we, at minimum, heard the people from Talk:1.10, namely . – Sealbudsman talk/contr 20:40, 10 May 2016 (UTC)
 * Sounds like you've thought about this a fair amount and tried to come up with a good solution. I'm willing to give it a try; if this doesn't work out as intended, we can always come back and revise the policy. -- Orthotopetalk 21:40, 10 May 2016 (UTC)
 * Do it. Anomie x (talk) 01:18, 11 May 2016 (UTC)
 * Even though I was leaning towards supporting it at first, unfortunately I've decided to ultimately per my comment from Talk:1.10 . -BDJP (t 02:01, 11 May 2016 (UTC)
 * Your first point on that page, "... doesn't mean it's just straight-up going to be in 1.10", I think if you look at the example (both as it was and currently), it would be very hard to look at the thing and get the impression that those features would be in 1.10, you would almost have to ignore 2/3 of what you're reading.
 * As for "driving speculation", are you thinking people would then just add their own ideas and wishes into the list? I think that is probably directly proportional to how tight the language is on the subtitle. I'll change it now to something that makes it clearer what does / doesn't belong in the list. – Sealbudsman talk/contr 04:38, 11 May 2016 (UTC)
 * . I think we should give it a try. --AttemptToCallNil, previously known as GreenStone (report bug, view backtrace) 10:06, 11 May 2016 (UTC)

Reorder sections
At the moment we have (in order) General, Gameplay, Commands, Command format, World generation, Blocks, Items, Mobs. You have to scroll far down to get the new features, and at the top it starts with Splashes, then goes to Options, etc. I propose we put Blocks, Items, Mobs, and World generation to the top, so you can get the list of new features quickly without having to scroll far down. For example, in 1.8, you have to scroll down a quarter of the page before you get 'interesting' features — Nixinova (talk • edits • pages) 19:27, 19 May 2017 (UTC)


 * I'd be up for that.
 * And not to muddle your suggestion too much, but while we're at it, why not put General at the bottom. It's kind of another word for "miscellaneous." – Sealbudsman talk/contr 19:37, 19 May 2017 (UTC)
 * I know I'm almost a year late, but . Before I knew much about the Minecraft Wiki, I remember looking through version articles and being annoyed by having to scroll a long ways down to find the more important features such as items, mobs, and structures, seeing things that I didn't really care about, like technical things, splash text, and statistics. I think it would be beneficial to have the blocks, items, mobs, and world generation at the top.--Orange Glazed Terracotta.png Madminecrafter12 T • C 00:57, 8 March 2018 (UTC)
 * How about blocks, items, mobs, non-mob entities, world generation, gameplay, command format, general? Or something similar? If you're reading this, I would really appreciate it if you could reply your opinion, so that this discussion can actually go somewhere.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 20:44, 2 April 2018 (UTC)


 * . What about this full reorder: Blocks, Items, Mobs, Non-mob entities, World generation, Gameplay, General, Command format. I think this is the ordering in which the player would generally be interested in reading. First we start with the obvious things you first notice in the world, blocks, items and mobs, then less obvious things like other entities and the world and game in general, and then finish with the technical commands/data stuff. – Jack McKalling [ Book and Quill.png Diamond Pickaxe.png ] 16:12, 9 April 2018 (UTC)


 * Thanks for replying. Yeah, that order's basically what I had except for with the command format and general switched. The reason I think that command format should come before general is because general is kind of like miscellaneous, while command format is more specific. However, depending on what other users think, I would definitely be open to having general before command format.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 16:19, 9 April 2018 (UTC)


 * Yeah that seems good. – Nixinova Book_and_Quill.png Diamond_Pickaxe.png Map (item).png 06:40, 21 April 2018 (UTC)


 * Pinging, I didn't immediately respond to your suggestion about switching the order of the General and Command format sections, but now that I've seen it in action, I'm convinced that I was right. I specifically suggested General to be before Command format, because similar to all other sections, it is not technical. The general section is often about stuff that is still (very) interesting to people who are not technical, eventhough the section is somewhat of an "anything else" section. Because the General section is not really technical like Command format, but still relevant to casual players who aren't interested about the technical stuff, I believe it should come before Command format. I didn't really get the chance to give argument to my suggestion there, before your different suggestion was implemented. I would like people's opinion about my argument. – Jack McKalling [ Book and Quill.png Diamond Pickaxe.png ] 10:02, 27 May 2018 (UTC)


 * Definitely makes sense to me to keep technical changes at the bottom, as it applies to the least amount of people, but is still absolutely relevant and useful information for many people. –Majr ᐸ Talk Contribs 12:14, 27 May 2018 (UTC)


 * I'm kind of neutral leaning towards having general below command format, but I definitely don't have any kind of problem with command format being below if that's what the community wants. Also,, it seems that pinging is completely broken right now for some reason (so you probably didn't get that ping either :)) - usually I'll catch any edit in Special:RecentChanges, but if I haven't replied to a ping within 4 hours or so or the matter is urgent, feel free to leave me a comment or a message.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 12:25, 27 May 2018 (UTC)


 * No problem about the pinging, we both got "notified" in some way anyhow. In case that is how I came across, sorry if I made you think that I find the technical information not useful or not relevant to a lot of people, Majr. In fact, I'd die if it were deleted, I'm a programmer and I love and need it myself haha. But I hope I'm still also being representative to others who aren't. I'd like to hear from more people, but I guess pinging more wouldn't help. – Jack McKalling [ Book and Quill.png Diamond Pickaxe.png ] 13:33, 27 May 2018 (UTC)


 * Putting General above Commands sounds good to me. I know I proposed putting it at the bottom, earlier, but you make a good point. – Sealbudsman talk | contribs 14:33, 27 May 2018 (UTC)

Add the trivia and video sections
After the discussion on Category talk:Update videos, it occurred to me that the versions style guide doesn't mention anything about trivia sections or video sections. Many version articles have both of these sections - it seems kind of just like an unwritten rule as to where these two should be placed. This is especially with trivia - trivia sections on version articles have been around for a long time, unlike videos which were recently added and there's still some dispute as to where they should be placed (although it seems like the consensus is to place them below the fixes but above the trivia, gallery, and references).

I propose that we add a video section to the style guide and a trivia section below that. The video section should contain brief information about transcluding the /Update Video page, as well as the fact that it should be placed below the additions, changes, and fixes but above any other sections. The trivia section should contain similar information that is covered in the features style guide - put miscellaneous information here, try to work it into another section if possible, etc. Opinions on this?-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 13:57, 24 May 2018 (UTC)


 * I agree with adding the video section.
 * I personally am not a fan of adding the trivia section to versions in the first place; I think the information that ends up in that section is pretty useless compared to the feature articles's trivia (most of the time its facts like "it has been X days since the previous update", "this X had the longest gap before the later X took longer", or "this update was released on this obscure holiday"). If there is a consensus to keep the section I would rather see guidelines describing what is allowed there then nothing. I would also like to know if there is any other information that ends up in that section. I might be in favor if there are facts I consider more useful, in which case I would encourage the section with guidelines on what trivia is allowed. – KnightMiner  · (t) 15:13, 24 May 2018 (UTC)

Anybody else have any opinions and want to comment on this?-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 14:37, 29 May 2018 (UTC)


 * Fully agreeing with KnightMiner on this. Video section is fine where suggested, and trivia as well but seems too vague right now to be a guideline. I would prefer someone who is more versed with version pages than me, to look into what the pages usually (should) have in that section. – Jack McKalling [ Book and Quill.png Diamond Pickaxe.png ] 15:20, 29 May 2018 (UTC)


 * I was going to add the video section - but then I remember that a few of the the version articles have non-slicedlime videos, that are either Curse or official videos. What should we say about these in the video section?-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 12:42, 10 June 2018 (UTC)


 * Could you link the video sections here for the purpose of discussion? – Sealbudsman talk | contribs 13:29, 10 June 2018 (UTC)


 * Sealbudsman@undefined By "video sections" do you mean all version articles that have a non-slicedlime video? If so, there are videos that are not by slicedlime on 1.1 and 1.2.1. On 1.11 there is both a non-slicedlime and a slicedlime video, and the coordination between the slicedlime and non-slicedlime is a bit strange, but I don't know of a better way to put it there. Another thing we need to decide is whether we should put the video on named updates. The only named update that currently has a slicedlime video is Update Aquatic, which has a Curse video as well.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 13:50, 10 June 2018 (UTC)


 * As for trivia, I think I may have been one of the first perpetrators of Trivia sections for the purpose of containing some statistical information, like longest time between snapshots or something like that. Nowadays after thinking about it, I think that information about the development process or the context of the version (whether or not existing statistical information stays at all) is more directly related to the version and is not mere trivia. As such it probably belongs in the lead, for lack of any other section dedicated to development process or context. So, long story short, id be okay if Trivia weren't codified in the style guide, I think there are better arrangements to be explored. – Sealbudsman talk | contribs 13:29, 10 June 2018 (UTC)

Replace video embeds with text links?
This would make "Update Video" subpages unnecessary and improve loading times. However, this will require a new tab to be opened if one wishes to view the video; I think it is not a critical drawback. --AttemptToCallNil (report bug, view backtrace) 15:00, 5 March 2019 (UTC)
 * Alternatively, maybe they could be lazily loaded (maybe with predetermined dimensions), such that the page can finish loading before the video. Although using LoadBox for this will still require the usage of the subpages. Personally I don't think it would be a great solution if you can't preview a video before you can click play, so I don't support converting them to links. – Jack McKalling [ Book and Quill.png Diamond Pickaxe.png ] 16:04, 5 March 2019 (UTC)

Past or present tense in lead?
Which tense should be used in the lead? Most use present tense ("1.x is an update for...") but I think past tense ("1.x was an update for") reads better. I'd say that the tense should match when the version is/was released: present tense for upcoming updates with development versions ("1.14 is") but past tense for past versions ("1.13 was"). It is also consistent with the dev phases: "Java Edition is..." vs "Beta was..." (see those pages). – Nixinova   07:46, 29 March 2019 (UTC)


 * As I see it, the tense to be used depends on the context. When referring to the version's release, past tense is warranted because the context involves an event (release) that occurred in the past.  When referring to features, attributes, etc. of the version, present tense is warranted because those things still apply to that version if someone uses it today; they will always apply to that version.  --Vistabuntu (talk) 02:53, 28 March 2020 (UTC)

Should bug fixes be added even if they aren’t explicitly marked as fixed?
Per this diff, I removed bug fixes that were added, yet they were not resolved as fixed on the bug tracker. Another user reverted my edit saying for me to “have some patience” and the bug reports would get “resolved in due time”. While the bug reports eventually did get resolved as fixed, I disagree with this edit because the bug reports were not explicitly marked as fixed on the tracker until later, so it should make sense that bug reports should not be listed on a version page until they are marked as fixed for said version. -BDJP (t 22:49, 3 April 2019 (UTC)


 * I personally agree with you, saying to have patience as there’s one comment on it claiming it’s fixed is not a good way to do it. The buck tracker had in the past, and still has people giving false results for fixed and affecting versions. Just because a wiki editor commented shouldn’t make it any different: It’s not marked as fixed, so it shouldn’t be in the fix list. FVbico (talk) 23:09, 3 April 2019 (UTC)
 * If it's not marked as fixed on mojira yet then it shouldn't appear on the article. – Nixinova Nixinova sig1.png Nixinova sig2.png 23:47, 3 April 2019 (UTC)


 * Agree with above, we should wait for a report to be resolved as fixed (which is often after another user or helper/moderator confirms the fix) before adding it to the article. – Sonicwave talk  19:52, 5 April 2019 (UTC)

Dealing with reuploads
Reuploads of versions (i.e., recompiled jars with the same version number as the previous version) aren't properly covered by the style guide layout, and I've just been winging it for most of the pages. First I put it in its own section, away from everything else, but then I decided that's too hidden and have been moving the main information to the lead. But then I come across versions such as 0.0.21a and (yikes) 1.6.2 where this doesn't really work well.

So, should reuploads be covered: (Also, should the word "re-upload" have a hyphen (re-upload, pre-re-upload) or no hyphen (reupload, pre-reupload)?)  Nixinova   T   C   01:28, 15 July 2020 (UTC)
 * 1) On their own pages, one page per Minecraft jar file.
 * 2) Have them all together on one page with the reupload information listed in the lead.
 * 3) Have all of them together on one page, with a section dedicated to each reupload that simply lists the changes in the re-upload in prose format.
 * 4) All on one page but with one section per re-upload that has subsections which follow the versions style guide (h3 Changes, Fixes, etc)
 * 5) All on one page but with the reuploads incorporated into the main sections, such as Changes, Reupload changes, Fixes, Reupload fixes, etc
 * 6) All on one page but with the re-upload information fully incorporated into the changelog, with lines being prefixed with "Reupload" or "Pre-reupload"
 * 7) One of the above but with exceptions for versions with huge amounts of reuploads (like 0.0.15a which had nine).
 * 8) Something else?


 * I like the options 3/4 and 7. The other options are confusing (options 2,5,6) or result in pages that don't have enough content (option 1). I also think it's better without the hyphen (pre-re-upload is just horrible). Sagessylu (discuss | edits) 07:29, 15 July 2020 (UTC)

Bedrock Edition major/minor versions
On the wiki, Bedrock Edition uses the same criterion as Java Edition to sort a version as minor of major. Nevertheless, looking for a x.x.x pattern doesn't work as all versions are released like that (eg. Bedrock Edition 1.17.0). To adapt, contributors use .0s as major versions.

This, however, is not how Bedrock works. It usually gets massive changes in "minor" releases, and smaller "major" ones. Major versions should be thoses incompatible with the previous version, and minor versions the numerous compatible ones with each version.

For example, Bedrock Edition 1.17.1 is really a minor version, but Bedrock Edition 1.17.10 is really big, too big to be compatible with 1.17.1, so it should be considered major on the wiki.

- MetalManiacMc at your service fellow human! (talk) 04:43, 21 June 2021 (UTC)