Minecraft Wiki talk:Style guide

Future in history sections
Following up my previous topic, what about future changes in history sections? Does it make sense to add tweets of upcoming features before they get added, or would it be better to not state them incase it never gets added? – KnightMiner  · talk 21:17, 22 January 2015 (UTC)


 * . We shouldn't state future changes (like 1.9 things) in the history section. – LauraFi -  talk  21:31, 22 January 2015 (UTC)


 * I don't even really like tweets being in there at all, should just be version history. –Majr ᐸ Talk Contribs 02:54, 13 March 2015 (UTC)


 * I agree and disagree with that. On one hand, tweets and other relevant links are not part of its history, just because the idea was made public then does not mean it was any more than an idea. On the other hand, it is interesting to read how long went between the initial idea and the final change, and it moves the information from Mentioned features, rather than deleting it (overall though, it tends to just state features that were not added, rather than actual history of the item, so I would be fine with removing them). – KnightMiner  · (t) 22:27, 27 March 2015 (UTC)

Rewrite proposal
Following up and, I have proposed a rewrite to this page over at MCT:Community portal, which would include moving various rules to this page, and splitting out the article layout sections to allow more article layouts to be discussed. Please direct comments there. – KnightMiner  · talk 00:31, 10 February 2015 (UTC)

Following up
Following up that previous topic, there are four things I want to propose here.

First off, the style guide lacks information on formatting specific article titles, other than a few brief points in "Article titles and section headings". Also, the current style guide contractdicts standard policy when it comes to titles, and I doubt there will be agreement of making articles like "Stone Bricks" become "Stone bricks". A solution would be the addition of a new section called "Article titles", which is mostly general practice. If implemented, the section "Article titles and section headings" would become simply "Section headings"

Secondly, since the style guide now supports more article layouts, I would like to re-propose the versions style guide into the new system. You can read the proposed guide at User:KnightMiner/Workbench/Style guide/Versions

Third is something I noticed a lack of while rewriting the guide, which is guidelines relating to images for articles. Too many people think they need to upload all the screenshots they take because they relate to the article, when the image is really not needed. A few points I can think of are as follows, though I would advise more points to be added.
 * Articles should only have one image showcasing an individual attribute of the articles content. For example, a zombie wearing armor.
 * Do not add images whose sole purpose is showcasing a bug, instead report the issue on the bug tracker.
 * Images showcasing usage of specific features for decoration should be avoided.
 * Images should showcase the most up to date version of Minecraft available for the content.
 * Images that are outdated are subject to be removed.

Finally, we need to specifically state that language translations are unofficial, so they are not relevant trivia.

– KnightMiner  · (t) 17:38, 4 March 2015 (UTC)


 * So, yeah... I shall race to get Russian style guide up-to-date with English one as it becomes approved. :D
 * Offtop aside, . — NickTheRed37 t ⁄ c (f.k.a. Naista2002) 18:07, 4 March 2015 (UTC)
 * One more image point I thought of, based on the gallery on Villager:
 * Images should showcase an attribute of the articles topic.
 * Images should not show unintended strange or humorous behavior, such as mobs "sitting" on stairs.
 * The second point and maybe the third point from above could also become sub-points of this point.
 * – KnightMiner  · (t) 16:57, 7 March 2015 (UTC)
 * Also . Sorry for latency, it was due to Oversight policy/ru. —  NickTheRed37 t/c (f.k.a. Naista2002) 18:21, 7 March 2015 (UTC)


 * . –Majr ᐸ Talk Contribs 02:57, 13 March 2015 (UTC)


 * The changes proposed here have been implemented, as it has been just about a week since last revision to the proposal. – KnightMiner  · (t) 04:28, 14 March 2015 (UTC)

Article templates at the beginning
Isn’t the infobox→dablink→msgbox order looking weird? I think that infobox→msgbox→dablink is better (compare Zombie Pigman and Horse). —  NickTheRed37 t/c (f.k.a. Naista2002) 13:45, 9 March 2015 (UTC)


 * The reason I proposed that order was because I thought of dablinks as a subtitle to the title, rather than a header title to the content, thus that order made sense.
 * That being said though, I do agree it looks a little better on Horse, as keeping the text together seems to look better, although I generally do not like the look of combinations of dablinks and message boxes anyways – KnightMiner  · (t) 16:47, 9 March 2015 (UTC)
 * Thanks. LauraFi, JEC6789? —  NickTheRed37 t/c (f.k.a. Naista2002) 17:10, 9 March 2015 (UTC)

Redirects
The result of the discussion was added to the style guide.

Currently, redirects get created and deleted with no stated reason as to what belongs. I would like to propose the following section to be added either as a subsection of notability, or its own section/subpage (admittedly a little small for a sub page, though the wiki rules are not too big either.)

Redirects are exempt from the normal notability, but must redirect to an article that fits the notability guidelines. If a redirect leads to another wiki, it must use soft redirect.
 * 1) Alternate spelling of the title, such as "Armour" for "Armor".
 * 2) Incorrect spelling, typos, and irregular formatting are not allowed.
 * 3) Alternate or shortened name, provided the name is common usage, such as "Log" for "Wood". Previous in game names are also allowed.
 * 4) This includes first names or handles for Mojang employees, such as or "Nathan" or "Dinnerbone" for "Nathan Adams".
 * 5) This also includes names from alternate English language packs, with the exception of the joke language "Pirate Speak".
 * 6) Previous article title, including if the article was moved to another wiki
 * 7) An exception is if the previous title was not commonly used
 * 8) Alternate capitalization or form, including changing the title to plural case
 * 9) A part of a merged or multi-topic article, such as a potion or a mentioned feature.
 * 10) The parent version for pre-releases which became a pre-release for another version, such as "1.7" for "1.7.2", due to "1.7-pre" being a pre-release for "1.7.2".

Redirects in the user namespace may lead anywhere, except to an article that does not exist or another redirect.

– KnightMiner  · (t) 23:24, 23 March 2015 (UTC)


 * . – LauraFi -  talk  23:29, 23 March 2015 (UTC)


 * . Sounds good. &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 00:03, 24 March 2015 (UTC)


 * . —「 JEC  6789  」talk • contribs 00:21, 24 March 2015 (UTC)
 * — NickTheRed37 t/c (f.k.a. Naista2002) 06:24, 24 March 2015 (UTC)

Notelists
First off, I'd like to add a section to the article layouts right above references called "Notes". The idea is to use that section to replace some of the HTML notes that may be relevant to the reader, rather than just the editor (for example, the reader might be interested in the formula used to calculate numbers, or for points where the scope is survival, so a command trick is left out).

Secondly, to go along with the first one, I would like to use consistent note groups for in section notes and global article notes, to avoid conflict, especially when a template uses either type. For those groups, we have two choices:


 * 1) My preferred method is using custom label, similarly to Wikipedia. I think in section notes could use "lower-alpha",[a][b][c][d] while global could use "upper-roman"[I][II][III][IV] or "upper-alpha"[A][B][C][D]
 * 2) * The actual group names can be set to anything (this is done using pages in the MediaWiki namespace, such as MediaWiki:Cite link label group-note for the group "note"), as the labels are attached to a group name, and the list style in the notelist is controlled by the template (with a bit of css), so I would simply go with "note" and "global"
 * 3) * Zombie pigmen spawn on the lowest level of nether portals<sup style="color:#0645ad">[A]
 * 4) Slightly less preferred is using specific note names, in which case common ones tend to be "note", "fn", and "n", although applicable might be be "n" for sectional and "gn" for global.
 * 5) A third option would be mixing the two, using only the "lower-alpha" group and letting global use something like "n", or vice-versa. This option might also be relevant considering how few articles use both lists.

– KnightMiner  · (t) 19:58, 27 March 2015 (UTC)


 * I like option 1, using upper-alpha not upper-roman (or any roman). But I'd like to have actual proposed text for what will go in the style guide before agreeing. &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 20:50, 27 March 2015 (UTC)


 * Well, there would not be a whole lot to state, but here are the specific texts to add. Note that the specific group names can change.
 * Here is the section for the layout pages:

 Notes 

This section contains only global. If there are no notes, this section may be skipped.
 * While for the main style guide.

 Notes 

Articles should use  notes to contain information that is relevant to the reader, but does not fit well within the article content. If the information is only relevant to the editor, HTML notes should be used instead. Examples of relevant notes include the formula used to obtain a number state in an article, or behavioral differences when elements that are required in Survival are removed.

Notes should also be used for exceptions in the case of information stated in tables.

To keep names consistent, avoid conflict between groups, and apply the custom labels, notes within sections should use the group "note", while notes within article content should use the group "global".
 * – KnightMiner  · (t) 21:42, 27 March 2015 (UTC)
 * — NickTheRed37</b> t/c (f.k.a. Naista2002) 07:12, 28 March 2015 (UTC)

Achievements related to an article
What achievements are considered related to an article, thus making them belong on that article? Specifically, are achievements related to crafting in the 3x3 grid considered related to the crafting table? Likewise, are achievements that require smelting an item related to the furnace? – KnightMiner  · (t) 22:00, 14 April 2015 (UTC)


 * Seeing as the edit in question was reverted by, I would like to ask what is the specific description on what is not "related" so it can be stated on the style guide, both as a reference for reverting and for users to learn which are relevant. Currently, it seems achievements are not related if it requires using a block interface, but it is still in some cases related when using other things as tools, such as saddles. There is also the question of if mobs should state achievement related to their drops, as both cow and blaze do, despite not being required for the achievement. – KnightMiner  · (t) 20:07, 16 April 2015 (UTC)

Double space after references
I don’t see the point in having the double spacing after references. It appears as excessive spacing, which is the reason I’ve made [ this revert]. —  NickTheRed37</b> t/c (f.k.a. Naista2002) </i> 13:48, 24 April 2015 (UTC)


 * The reason is it better shows that the navboxes are not part of the article's content, but rather additional navigation links after the content. That being said, I find that it reads better to have the double linebreak. – KnightMiner  · (t) 15:12, 24 April 2015 (UTC)

Video notes
So, this is a minor thing, but I personally think it looks better to add notes about videos being incorrect or outdated using dablink, as seen on Resource pack. (which is still valid under the current guideline, as "Note:" is italic) Does anyone have any objections to that, or a preference for the current method? – KnightMiner  · (t) 04:09, 5 May 2015 (UTC)


 * dablink is for disambiguation notes only. &mdash; Grid Command Block.png NickTheRed37</b> (talk&#124;contributions) 05:50, 5 May 2015 (UTC)


 * Says who? The documentation simply says "usually for disambiguation purposes", and that formatting is not universally accepted to mean "disambig", but rather is a "hatnote", or any note at the top of an article or section. The Wikipedia version even specifically says "Often, but not always, this is a disambiguation link at the top of article pages.", and is title "hatnote" to prevent the assumption it must be a link. So unless you have something else against using it, I see no reason for you to oppose. – KnightMiner  · (t) 13:44, 5 May 2015 (UTC)


 * . – LauraFi -  talk  16:20, 5 May 2015 (UTC)


 * I've made a proposal to add a template for video notes on the community portal, which also has the advantage of adding categories for those notes. That template would standardize the formatting, so please direct later comments about formatting there. – KnightMiner  · (t) 16:14, 19 May 2015 (UTC)

Soft redirects
Apparently, redirects to other wikis don't actually redirect. Why are users supposed to use Soft redirect? 71.212.10.80 20:40, 2 June 2015 (UTC)


 * They work for me. Click the link to follow the redirect? – LauraFi -  talk  20:47, 2 June 2015 (UTC)
 * After editing a redirect, you won't be redirected. Only if you directly come to the page via a link, you'll be redirected. Soft redirects should for example be used if you have a userpage which redirects to a correspodent wiki (for example, let's say, the Dutch one), the unaware user suddenly is in another wiki in a language he probably doesn't know. Let's say the page "Feed the Beast" would lead to the main page of the Feed the Beast wiki. Many unaware wiki readers would be surprised then. That's why the template "soft redirect" exists. Normal redirect for internal links, soft redirect for external ones. | violine1101(Talk) 21:14, 2 June 2015 (UTC)
 * This is not the case actually. When a page redirects to a nonexistent page or a page on another wiki, readers will not be redirected; it resembles the interface for any redirect page not redirecting (like just after you create or edit a redirect). 71.212.10.80 01:39, 3 June 2015 (UTC)
 * Are you sure? A redirect works as long as the interwiki allows "forward links", which can be determined using Special:Interwiki. The interwiki you tested (wp) does not allow forward links. – KnightMiner  · (t) 03:09, 3 June 2015 (UTC)
 * I love how you selected a redirect page of a Russian wiki admin :) — Agent NickTheRed37 (talk) 13:32, 3 June 2015 (UTC)
 * No, I saw your red sandbox. Apparently, I missed something when I was using Minecraft wiki:Sandbox. 71.212.10.80 15:01, 3 June 2015 (UTC)

Quote template usage
recently made an edit changing the order of the infobox and the quote, and I noticed we have nothing about them in the template order information. I was wondering what are the opinions regarding the location of quote compared to the infobox, message boxes, or dablinks? In my opinion, it does not look bad with a longer quote, but shorter ones cause the same problem as message boxes where the infobox is pushed down with only an ugly whitespace above it. – KnightMiner  · (t) 14:36, 8 June 2015 (UTC)


 * Actually, message boxes are status boxes. They have more important information than infoboxes, so I would put them at the very top. Either way, quotes should be located before dablinks (if any). And GreenStone should be referred to as just GreenStone, not User GreenStone. — Agent NickTheRed37 (talk) 14:50, 8 June 2015 (UTC)


 * NickTheRed37, I did it for technical reasons which were stated in the edit summary (Also, don't tell other people how should they call me.)
 * I can reproduce the bug in my Alpha sandbox, but the bug is there only when the page is viewed directly rather that previewed. The quote also displays normally on diff and old revision pages... as well as if I remove the  rule from.
 * And I think that the order should be: 1) message boxes, 2) dablinks, 3) quotes and infoboxes. I would not have had a preference for placing quotes before infoboxed if not for the bug.
 * Also noting that on low resolutions even smaller quotes overlap with infoboxes. --GreenStone (talk) 15:10, 8 June 2015 (UTC)


 * I can only reproduce this bug in Opera; it works fine in Chrome, Firefox, and Safari. I don’t know if we should change the formatting of the wiki for everyone just to work around a browser-specific bug. — Orthotopetalk 16:20, 8 June 2015 (UTC)
 * And I can reproduce the bug in Firefox. --GreenStone (talk) 16:23, 8 June 2015 (UTC)


 * For some reason I did not think the overlap was a literal element overlap, just the elements were next to each other, as on chrome it looks fine... The issue with the overlaping is actually an opera/firebox adblock issue. Adblock only seems to remove the ad elements content, not its styles, causing the HTML to see a zero width element before seeing the infobox and allow 100% width for the quote expansion. It seems to be fixed fixed by adding the css  to MediaWiki:Common.css, which reduces the bottom margin just enough to let the quote see the infobox and adjust its width accordingly.
 * NickTheRed37@undefined Yes, message boxes should be at the top, but the infobox does not lower the content of a message box (causing it to still be at the top), but the message box will lower the infobox (causing ugly whitespace). – KnightMiner  · (t) 00:37, 9 June 2015 (UTC)

Page versions
Realatively recently, someone created 0.12.0, even though it is used to mean Pocket Edition. Would others agree that pages like this should be disapproved? 71.212.10.80 02:00, 12 June 2015 (UTC)


 * I see no reason to keep it. Why break from the title style just for the sake of what would become a misleading redirect?
 * Also, version nav relies on there being no pages at the same title under a different prefix. Should the page "Pocket Edition 0.12.0" be created in the future, it would claim 0.12.0 as the PC version of the same number. – KnightMiner  · (t) 02:11, 12 June 2015 (UTC)


 * My point is that not specifying the edition is generally used for the PC version, and this is not only true for the Minecraft wiki. We need to enforce this. 71.212.10.80 02:37, 12 June 2015 (UTC)

Better references
Recently on the articles Seecret Friday and 1.9, some better references were added which actually contain a bit about the reference (quote, date, etc), rather then just dropping a link in. This has the benefit of adding a bit of a quote to help manage sources (as no one is going to memorize the ID numbers), and it requires the user to visit less sites when they want to know what we are referencing.

What are the opinions on doing this for more articles and more types of links? – KnightMiner  · (t) 16:06, 15 June 2015 (UTC)


 * due to the fact that I just attempted to add a reference to 1.9 and its really hard to point out what is and what is not wiki text. BDJP (t 16:12, 15 June 2015 (UTC)
 * . Such references have their good and bad sides. Yes, this allows for more accurate references, but for some users it may get complicated. BDJP007301, I didn’t quite get your point; and also see Template:Comment/doc. — Agent NickTheRed37 (talk) 16:25, 15 June 2015 (UTC)
 * The problem with naked links is that links can go stale and expire. If there is other information in the reference, it makes it easier to find where the content has moved and fix the reference. I've tried to use full references in the redstone circuit articles where possible (for example). &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 18:10, 15 June 2015 (UTC)
 * . – LauraFi -  talk  18:18, 15 June 2015 (UTC)
 * because it would have the effect of keeping the user on the page, and making an editor's job easier due to easily seeing on-page how the references justify the text. At least with Twitter. – Sealbudsman (Aaron) SealbudsmanFace.png T/C 18:24, 15 June 2015 (UTC)
 * –Goandgoo</b> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 00:38, 28 November 2015 (UTC)

Expand obtaining to allow creative/commands in select cases
The obtaining section could really use a bit more information on the exceptions to the "only state survival methods" rule, since on some mobs like the giant, and on some blocks like the barrier, it is important to state commands work. Also, on mobs such as the ender dragon and with items such as mushroom blocks, it is worth stating that they cannot be obtained or spawned using just creative. I would like to add something like the following text:

This section should may only state information on using creative mode or commands to obtain the block or item or to spawn the mob if one of the following is met:
 * The block or item cannot be obtained in creative or with commands, or the mob cannot be spawned with a spawn egg. In this case, the exception may be stated.
 * This does not apply to non-mob entities.
 * The block, item, or entity cannot be obtained or spawned in Survival. In this case, the section may state if it can be obtained or spawned in Creative or using commands.

– KnightMiner  · (t) 23:45, 25 June 2015 (UTC)


 * . – LauraFi -  talk  00:09, 26 June 2015 (UTC)
 * as well. BDJP (t 01:21, 26 June 2015 (UTC)
 * also. – Sealbudsman (Aaron) SealbudsmanFace.png T/C 02:08, 26 June 2015 (UTC)
 * –Goandgoo</b> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 03:49, 26 June 2015 (UTC)
 * . &mdash; Agent NickTheRed37 (talk) 07:02, 26 June 2015 (UTC)
 * – JEC</b><sup style='color:#FA0'>6789 talk•contribs 11:44, 26 June 2015 (UTC)

Gameplay mechanic page titles
According to 's comment in Minecraft Wiki talk:Community portal, this page recommends singular titles. However, singular titles imply that the page is more specific than it actually is (for example "Renewable resource" implies a specific renewable resource). Please state your opinion. The BlobsPaper.png 15:01, 27 August 2015 (UTC)


 * The community portal does have jurisdiction over the style guide, and we were already discussing an amendment to the style guide there in the discussion you linked, so there is really no need to start an additional discussion. Just propose your amendment on the already going discussion.
 * As for my opinion on this proposal, I don't think using the criteria of gameplay pages is a good idea, as there are a lot of pages in Category:Gameplay that don't need to be plural. Such as chest loot, damage, difficulty, experience, heads-up display, inventory, item durability, scoreboard, south-east rule, spawn, third person view, transportation, and zombie siege. = – KnightMiner  · (t) 15:15, 27 August 2015 (UTC)

Amend console edition from MCW:FUTURE
The result of the discussion was withdrawn by nominator.

In the midst of the recent slow edit war on Mob, I'm currently proposing that console edition be amend from MCW:FUTURE. The rule is currently stated as follows:

However, there is only one problem. Console Edition does not have development versions, whatsoever.

I'm not trying to push out this exception to all articles; just Mob in general. -BDJP (t 10:15, 19 October 2015 (UTC)


 * The reason the rule was added was because articles were getting flooded with "this might happen later" posts, and the easiest defining mark for things definitely being in the game (thus worth stating on articles) is them actually being in the game, plus it makes more sense to only describe features that currently exist on articles about current features.
 * The console edition's lack of development versions simply says it lacks a good enough source that those features are definitely being added, not that we need an alternative way to use upcoming. – KnightMiner  · (t) 14:22, 19 October 2015 (UTC)
 * If a version has no development versions, then only Mojang can play the pre version. Upcoming features belong on the version page. The BlobsPaper.png 21:00, 21 October 2015 (UTC)


 * Until a feature is actually in the game, we can't be sure it will be added, and thus it is speculation. If the console edition doesn't have development versions, then there's no way to be certain what will actually be in it until the version is released. –Majr ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>Talk Contribs 10:07, 22 October 2015 (UTC)


 * per KnightMiner and Majr. – 107.207.65.250 – 11:55, 22 October 2015 (UTC)

Reboot
There is not a "lack of a good source" as Knight claimed. Did you look at the source I added for guardians coming to the console edition? Clearly, they only way we can be sure that a mob is "upcoming" is through images posted by 4J Studios' twitter account.

With that, I also propose changing the rule to something that allows console edition as such with this "new evidence".

Content added in future updates may be added to the article in the main content, provided the features are marked using upcoming and have appeared in development versions. If the update contains major changes to the article, then the content may be noted as a subsection of a main section, or as its own section called Upcoming. Upcoming features must be noted as well in the history section using the proper upcoming header.

Upon the release of the update, all content that is now outdated must either be moved to the history section or removed, and any usage of upcoming may be removed.

The Console Edition is exempt from this rule as the only evidence for upcoming features is through images posted by the twitter account for 4J Studios. -BDJP (t 12:25, 21 November 2015 (UTC)


 * Yes, there is a source that it is upcoming, though the thing is such sources also exist for the PC edition and were the exact thing the original discussion was having issues with. It was determined that the best way to determine if something should be marked as going to be in the game is it actually being in the game, thus articles about game content were limited to actual game content (whether dev versions or full releases). As an example, what is to stop 4J from deciding guardians should wait a few updates to be released along side another feature, such as if they don't finish ocean monuments soon enough?
 * The other issue is if we make an exception for the console edition, why are equal or greater sources for the PC or pocket edition not allowed? It just adds an inconsistency with our sources so we can have a single table say "upcoming" under the console edition.
 * We already have several articles about planned and mentioned features, why does mob have to cover the tweets as well? – KnightMiner  · (t) 15:11, 21 November 2015 (UTC)


 * Mob will have to cover the tweets for the new rule that I'm proposing. Also:
 * You just disproved your own statement.
 * That's the reason why I'm making this exception...
 * I said nothing about sources for PC or PE, so why bring that up? -BDJP (t 05:04, 27 November 2015 (UTC)
 * That's the reason why I'm making this exception...
 * I said nothing about sources for PC or PE, so why bring that up? -BDJP (t 05:04, 27 November 2015 (UTC)
 * I said nothing about sources for PC or PE, so why bring that up? -BDJP (t 05:04, 27 November 2015 (UTC)


 * Firstly, my point is Mob does not need to and shouldn't cover tweets. You new rule may change that, but that does not make me change my stance on whether they actually are needed there.
 * Secondly, I did not disprove my own statement. My earlier statement said there was "not a good enough source", there still is a source, it just is not a unique enough type of source to isolate for CE. So while you did not mention PC or PE, the fact that in the proposal we would allow such sources on console but not the exact same type of source on PC or PE is just an unneeded inconsistency. The source is not made more valid by the lack of dev versions, if anything it would just be made less valid.
 * Lastly, I understand you want to make an exception, by my point is an exception is not needed and the previous discussion had the goal of removing such sources for all versions (I know that because I started the previous discussion). Dev versions are the only way we can know for certain that a feature will be in game, hence my earlier statement you did not reply to: "As an example, what is to stop 4J from deciding guardians should wait a few updates to be released along side another feature, such as if they don't finish ocean monuments soon enough?" – KnightMiner  · (t) 15:25, 27 November 2015 (UTC)

Minecraft developers
Since we use Minecraft developers as sources, and apparently not all Minecraft developers are with Mojang (though I believe it still fits under "closely related to"), can we specifically state that Minecraft developers are notable as well? – KnightMiner  · (t) 19:13, 24 December 2015 (UTC)


 * . – LauraFi -  talk  19:19, 24 December 2015 (UTC)


 * sigh... - Blame Wolf. Brainwashed me with this diff that I can't revert due to my "interaction ban". . -BDJP (t 19:45, 24 December 2015 (UTC)


 * If what you are trying to say is that you are confused, as Mojang is a subsidiary of Microsoft, the people who work for Mojang which is part of Microsoft are Mojang employees and the people who work for Microsoft and are currently working on Mojang products are Microsoft employees. Wolffillms (talk) 21:53, 24 December 2015 (UTC)


 * It would make much more sense to have Minecraft Microsoft workers on a Microsoft page rather than the Mojang page as the whole page is specificly about Mojang. Wolffillms (talk) 21:53, 24 December 2015 (UTC)