Minecraft Wiki talk:Community portal/Archive 23

Creating empty/contentless pages
Please stop creating new pages that are functionally empty (e.g. they only contain maintenance tags such as Stub or text such as "Foobar is a block.") Such pages are useless to readers; because links to these pages become blue, readers are misled into thinking there is useful content on these pages. This practice is especially useless if you create a page in this manner and then immediately turn around and edit the page with useful content. If this continues, lI'm going to start handing out blocks over it. 「」· 14:26, 18 April 2018 (UTC)


 * Yes! Several chemistry-related pages were created in this way, which was bothersome. Others (the 4 utility blocks) were created with useful text, except it was copied directly from the education edition website, which is also not wanted. -  15:17, 18 April 2018 (UTC)


 * I've also noticed this for snapshot pages. For example, there will be a tweet that "a snapshot may come out later today," and somebody will create that as soon as the tweet is posted, with the only content being "Dinnerbone tweeted that a snapshot will come out today." I understand that it's exciting when this happens, but there really is no reason to rush. I have complete trust that editors will create the snapshot page within 5 seconds of its release (I mean, literately).-- undefined 15:22, 18 April 2018 (UTC)


 * Yeah, this is a problem I've noticed happening for a while. The creation of contentless stubs for the various Classic versions is what finally spurred me to comment on it, though. 「」· 15:24, 18 April 2018 (UTC)


 * I'd say there are two cases here. One would be creating the articles, and marking them all as In use so that two people don't work on making it at the same time.  In my opinion, that's fine (though the template should probably be used for that case).  Another would be just creating an article where the subject doesn't even exist yet (e.g. future snapshots) and the article couldn't be written.  That's a case where I would say it's a problem.  --  16:16, 18 April 2018 (UTC)


 * If someone wants to work on an article like that, they need to do it in their userspace and then move it to the mainspace when it's ready to go. Trying to prevent duplication of effort is not a valid reason to create empty/contentless pages. 「」· 23:26, 18 April 2018 (UTC)


 * , please read this section, and note that in the future, reverting edits that change empty/contentless pages to redirects will result in a block. 「」· 23:26, 18 April 2018 (UTC)
 * After checking those edits, I was mistaken about what you did. However, in the future if you properly create a page from an edit revert, please replace or delete the edit summary before saving so your edit isn't listed as a revert in the page history. 「」· 23:32, 18 April 2018 (UTC)


 * , please read this section. 「」· 22:31, 23 April 2018 (UTC)

So, what is the community consensus here? Should we not create snapshot pages until they have been released unless there is significant coverage over the features that will be added in a source? created before it was released, and  created, as it's expected to be released tomorrow (both of these users did it out of good faith). Whatever decision we make should probably be mentioned in the style guide. I personally like the idea of not creating any unreleased snapshot pages unless several of their features are mentioned in a source (kind of like how it currently is with version releases), but I'm open to anything. What do the rest of you think?-- undefined 00:45, 9 May 2018 (UTC)


 * This isn't about creating pages for announced versions before their release (which is fine), it's about creating empty or contentless (e.g. the only content is something like ) pages. As long as something useful can be (and is) said in the article, it can (and should) be created. 「」· 19:49, 16 May 2018 (UTC)
 * So if I understand correctly, it's fine to create (snapshot) pages (before they are released yet), if it is done with useful content in the first edit. So if you'd be filling in more content later, hold off clicking the submit button before you do. Fair enough, right? – [ Jack McKalling ] [   ] 19:58, 16 May 2018 (UTC)


 * Yes, that's it exactly. 「」· 20:00, 16 May 2018 (UTC)
 * Well, we could enforce this with a message (box) in the editintro, add a formal note to the already mentioned style guide, or a step further, insert a minimum data requirement to the editor (there must be some mechanic for something like that somewhere). Because I'm sure people new to this discussion are probably not going to read this before they make the same mistake others have already. These are just the tools I can think of to help, do we need any of that? – [ Jack McKalling ] [   ] 20:07, 16 May 2018 (UTC)


 * Adding a note to the style guide (or some other place where it's clear this is a wiki guideline/policy) would be ideal. An abuse filter rule can be created to catch some cases of this as well, but I don't think this problem is widespread enough to justify that (though if someone who knows their way around writing abuse filter rules wants to write one, I'd have no problem adding it; email it to me in that case). Adding an editnotice wouldn't be appropriate for this, because page creations are a very low proportion of edits, and AFAIK there's no real way to selectively display an editnotice specifically on page creation. 「」· 20:16, 16 May 2018 (UTC)


 * Regarding the, wouldn't it work to just put  in it? Interested to know if it would. And if that doesn't work, you could also try checking a variable inserted by . The parser function failed for me, but I can't truly test it in system messages like that. So all right, lets focus on the style guide then. What about adding another phrase to Notability.General.1, so it would read for instance   Any thoughts? – [ <span class="gamepedia_pro_user">Jack McKalling ] [    ] 20:50, 16 May 2018 (UTC)


 * There is a separate message that occurs when creating a page. I do not know the name, but it currently starts with “You have followed a link to a page that does not exist yet”. Additionally, the message would be useful for all namespaces except user. Therefore, we should use . It would generalize the message to an indication that placeholder pages should only be created in the userspace. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 23:21, 16 May 2018 (UTC)


 * System message  controls this message, so creating such a notice is possible. Not sure how useful the abuse filter would be in this case: many placeholder pages are created with infoboxes, navboxes, etc., so filtering on page length wouldn't necessarily work. A filter to prevent creating any page less than 16 bytes might stop some blank or nearly-blank pages while still allowing redirects, but could be bypassed with an empty section header and a navbox. -- undefined 03:17, 17 May 2018 (UTC)


 * Of course we could just use newarticletext, I had already linked to it above, but this system message is NOT visible during preview. Does that matter here? So no adjusting the abuse filter. Also agreed the message box could be shown on more namespaces than just the mainspace. And as an example implementation of the message box, would this suffice?


 * I just used the same sentence as I suggested for the style guide. – <span class="plainlinks" title="View User PROfile">[ <span class="gamepedia_pro_user">Jack McKalling ] [   ] 08:54, 24 May 2018 (UTC)

'''Next time, if you are writing something that is a stub and/or not completed yet, press the "Save draft" button instead of the "Save changes" button. You can come back to work by accessing the page.'''   00:34, 24 June 2018 (UTC)

Update Videos (up)
Are you guys still ok with ? [   ] 14:39, 22 April 2018 (UTC)


 * I personally am fine with it, and it seems like many other users are too., ? Would you be okay with doing this?--<span style="background-color:aqua;border: 1px solid"> undefined 14:51, 22 April 2018 (UTC)


 * I'm fine with whatever the community consensus is. (Personally, I'd rather read a well-written article than watch a video, but that's mostly because I can read a lot faster than most people talk.) However, as Dinoguy repeatedly mentioned, we need a list of Mojang/developer channels to add to the video policy before this can be implemented. -- undefined 16:43, 22 April 2018 (UTC)
 * Currently, there are only . The only YouTube channel there is TeamMojang. We should start making a section about official YouTube accounts other than Mojang's. -- 01:06, 23 April 2018 (UTC)
 * I've saw that slicelime was added, could we start now? Or do we need another seperate page ? [    ] 18:54, 23 April 2018 (UTC)
 * The help page is probably the ideal location for the list to go, and the video policy should be updated to point to it instead of maintaining a separate list. <span class="nowrap">「」· 22:03, 23 April 2018 (UTC)


 * Alright, can we start now, , , ? [    ] 15:10, 30 April 2018 (UTC)


 * Works for me, especially because it's now been added to the page. However, should we update the  page as well before we do this?--<span style="background-color:aqua;border: 1px solid">  undefined 15:22, 30 April 2018 (UTC)


 * The can be easily changed, as it's copied from Terraria wiki. Minecraft Wiki can set up their own rules. The video policy should be updated.   15:33, 30 April 2018 (UTC)


 * I don't know how to do it, can someone do it? [    ] 21:38, 1 May 2018 (UTC)

Only admins can edit the page, and none of the admins you've pinged have replied yet. I guess we can wait a week or so, and then I'll try contacting one of the active admins directly.--<span style="background-color:aqua;border: 1px solid"> undefined 21:43, 1 May 2018 (UTC)


 * I've made the change, though I welcome suggestions for improvements to the text there (not just my text, but any of the text on the page, most of which I didn't look very closely at while editing). <span class="nowrap">「」· 07:35, 2 May 2018 (UTC)


 * So, may we start adding update videos by slicedlime? ?--<span style="background-color:aqua;border: 1px solid"> undefined 02:39, 6 May 2018 (UTC)


 * I think so, I'm going to start, a template is available . [    ] 17:22, 9 May 2018 (UTC)

So to clarify, it is ok to start adding slicedlime videos to update pages now? 05:49, 10 May 2018 (UTC)


 * Yes! Make sure to all follow the same (which can be found on 'Category:Update_videos' too) to not be confused.  [    ] 08:38, 10 May 2018 (UTC)


 * You can't use subpage transclusion as the snapshot pages are transcluded on the subpages, which points the video transclusion to a subpage of that page, which obviously doesn't exist. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>  10:17, 10 May 2018 (UTC)


 * doesn't work, but fixes the issue. Applied fix to existing pages and altered the instructions on the category page. -   12:58, 10 May 2018 (UTC)


 * That's strange how it doesn't work for you. It should work, and it does work just fine for me. So when you access, the video does not show up? (That revision is before you added the extra :18w16a) Oh wait, I'm sorry, never mind - it's for the development versions that is doesn't show up, I should have read Majr's comment more thoroughly.--<span style="background-color:aqua;border: 1px solid"> undefined 13:06, 10 May 2018 (UTC)

Bedrock Beta versions
So, ever since the 1.2.13 betas, the version numbers have gotten pretty weird, and at the top of the weirdness is the recent Beta 1.5.0.0, the ninth beta version leading up to full version 1.4. Attempted breakdown as follows (numbers in brackets are full version numbers):

Now, the article for Beta 1.5.0.0 is currently called "1.4 build 10", which is false, since it's the 9th build for 1.4 (Update Aquatic). And unlike previous numbers, it doesn't make sense for it to be "1.5 build 1", since it's not a build for 1.5. So, should it just be called "Beta 1.5.0.0"? Should the naming system be changed for the beta versions? I'm not really sure what to do here. -  21:05, 26 April 2018 (UTC)


 * To be honest I have no idea what to do, I've been wondering the same thing! For 1.2.14, builds for it added update Aquatic features, but then the iOS release of it only had bug fixes. Also, the order of the builds doesn't make sense at all, and it seems like some of the Wiki, such as the bedrock Edition version template, regards all of the builds as "1.4." Anybody else have any ideas?--<span style="background-color:aqua;border: 1px solid"> undefined 21:14, 26 April 2018 (UTC)


 * Yeah, out of the beta versions listed, only 1.2.13.5-6 have actually been related to the version number. 1.2.13.8 and later have all been Update Aquatic betas, with no correlation to the full versions 1.2.13 or 1.2.14 despite sharing version numbers. As briefly touched upon, naming them "Beta [number]" could be a potential solution for the 9 builds in question, but it would need consensus. -  21:33, 26 April 2018 (UTC)


 * Looks like it's better if we named the version articles like "Beta [version number]". I'd consider "Update Aquatic Build [N]", but build numbers seem unreliable, judging by the 9/10 confusion, and this naming method will fail if the builds for the next major update become similarly confusingly versioned before the update's name is announced. If things get worse, we may have to resort to version release dates... but then again, nothing prevents the developers from "accidentally" releasing two or more updates on the same day in an ambiguous order. -- 10:33, 27 April 2018 (UTC)


 * My suggestion is "Bedrock Edition Beta 1.2.6" for . Using this way will prevent confusion and make it a lot easier. We don't need to version numbers and update names. This is to keep consistent with Java Edition's s articles. The name does not have the update name. Plus, builds are names used by Android betas only, uses the term Beta instead of builds.--  11:33, 27 April 2018 (UTC)


 * This is going to be confusing with the way we've historically treated the terms alpha/beta: as being an entire set of versions that come prior to the initial 1.0 release (just look at how history is organised). You might expect that BE Alpha 1.0 precedes BE Beta 1.1, but there's actually release versions in between. If we do this, we're going to have to make sure the infobox clearly differentiates between pre-release alpha versions, and mid-release beta versions. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 11:49, 27 April 2018 (UTC)


 * Well, that only applies to Java. While it might be confusing, it is accurate; Bedrock Edition uses Beta versions as their equivalent of Java snapshots (as of Beta 1.2.13.8), introducing experimental features which may or may not be included in the full version. Display methods in templates could be as follows:

Infobox (Beta 1.5.0.0) "Type" indicates that it's a beta (snapshot) version, "Beta version for" indicates which version it's a beta for.

History (dolphin) For this one, "beta [version number]" is used in the same way as snapshots, being listed under the upcoming version they are a beta for.

-  13:19, 27 April 2018 (UTC)

A better way is to write the version just like in-game. We don't need beta prefixes. Beta 1.5.0.0 will be just called 1.5.0.0. This can prevent confusion. 06:57, 28 April 2018 (UTC)

An example.

Infobox (1.5.0.0) "Type" indicates that it's a beta (snapshot) version, "Beta for" indicates which version it's a beta for.

I'm sure most readers can determine this is a Beta version page. 07:01, 28 April 2018 (UTC)


 * Are we going to start a renaming project?-- 01:32, 2 May 2018 (UTC)


 * I don't think a renaming project would be necessary - I certainly wouldn't mind moving all of the builds to their beta titles and fixing the article's information. I would like the opinions of other editors before doing this though, as I'm not sure if we've come to a consensus yet. This will be a pretty drastic change to the wiki, so we need to make sure that the community overall is OK with doing this, so that we can avoid a mass page-move revert. Another thing to keep in mind is all of the templates and links that will need to be updated after we've done this.--<span style="background-color:aqua;border: 1px solid"> undefined 01:36, 2 May 2018 (UTC)


 * I guess we don't need to move all of it, but only updates after 1.0. Because the in-game version started using this format after 1.0. Before 1.0, Pocket Edition still uses build numbers in-game. This is the same with and, we need to follow the in-game number. I have created a page .--  01:46, 3 May 2018 (UTC)


 * I'm all for using in-game names as much as possible. Making up our own terms isn't helpful to reducing confusion. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 05:28, 5 May 2018 (UTC)
 * How about fitting the Japanese page that separates the template before and after the 1.2 release that became Bedrock Edition?-- 15:08, 6 May 2018 (UTC)
 * If you use Changelog in game as information source, 1.2.20.1 is build 8, 1.2.20.2 is build 9, 1.5.0.0 is build 10, 1.5.0.1 is build 11.-- 15:20, 6 May 2018 (UTC)
 * Can confirm the above as I’ve seen a screenshot of it that said “Build 11” on it. So referring to these as builds 9, 10, 11, etc. is fine. -- 13:10, 9 May 2018 (UTC)
 * Revisting this because yesterday on the MC Monday stream the devs announced that 1.4 would be coming very soon and said conduits would be in the second part of UA, which is 1.5. This actually makes sense because Beta 1.5.0.0 may actually the first build for 1.5 (despite just being bug fixes) and 1.5.0.1 is build 2 since that added conduits. Also, 1.2.20 may end up being similar to 1.2.14 where the betas share the same version number but the actual update contains none of the things in the beta. The current betas that are considered part of Update Aquatic (up to the last 1.2.20.x beta) would be part of 1.4, since there was no beta labeled 1.4.0.x. -- 16:13, 15 May 2018 (UTC)
 * Another thing I thought we could do is rename the articles to something like on the  page (this would make it somewhat easier to distinct it from the other  To keep the other versions mentioned as well, the lead would be something like this:


 * Update Aquatic build 1, also known as 1.2.13 build 3, 1.4 build 1 or beta 1.2.13.8 is a build released on March 16, 2018 that added some of the features through Experimental Gameplay.


 * I’m not entirely sure how this would work but I’ll explain it more in detail soon. -- 00:45, 16 May 2018 (UTC)


 * undid nearly every single edit I did to try and fix this problem and he claims “no source was given”. We need to settle this right now (pinging, , and any others i couldn’t immediately think of) as  is mislabeled - there are no conduits in the full 1.4 release (I checked, not added even in EG) but this is a 1.5 feature that is in an article under 1.4 which is factually incorrect. Someone needs to email the development team itself to see if they can provide better information to fix this. --  19:28, 16 May 2018 (UTC)


 * As I explained on your talk page, the names of version articles should reflect those versions' in-game names (see also MinecraftPhotos4U's massive cleanup and correction campaign with early Minecraft versions, which featured a lot of renaming for that purpose). If you can demonstrate that a given build is named in-game how you renamed its article, then the rename is fine and can be redone. Otherwise, if you can demonstrate the name was used in an official source, it should be noted in the article as an alternative name. Beyond that, if there is incorrect information in the articles, it should be corrected (for most of them, if anything is required, this probably just means clarifying what version the build is actually for). This does not mean, though, that articles should be "corrected" because a given feature in the build isn't included in the release version the build is named for (that comes down to the versioning for BE being messed up in the first place, and is not our place to try to fix, though we should explain it for readers). <span class="nowrap">「」· 19:56, 16 May 2018 (UTC)
 * Now that I think about it, the way the betas were named post-1.0 actually seems like a plausible idea (like what Skylord wars suggested) since they are the actual numbers in-game. -- 20:01, 16 May 2018 (UTC)
 * I've created two template mockups for so we can vote which one is more suiting.


 * Mock-up #1


 * Mock-up #2


 * Personally I'd be willing to go with the second one since thats what its referred to in-game, although the alpha/beta name can be template-only and the pages without the name - e.g "beta 1.2.13.8" would link to . This creates problems with 1.0 and 1.1 as their respective builds were labeled "alpha v1.x.x.x" during gameplay but it changed to "beta v1.x.x.x" from 1.2 onwards. If such a case rises we can just name it with alpha being all lowercase to be different from the Alpha phase of development (0.1-0.16). Same would go for beta. --  22:34, 16 May 2018 (UTC)


 * We need to do something about 1.4, it's currently claiming that beta versions for, , and the seemingly non-existent belong to it, but then the page's themselves refer to the parent version of the same name. So which is it? It looks more like those versions are entirely separate from 1.4, but re-implemented features from it in a "pseudo beta" behind the experimental gameplay setting. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>  06:07, 18 May 2018 (UTC)

Deletion requests for mod pages
Several IPs (I'm pretty sure they're the same person though, as their IPs are very similar and always have a similar edit summary) are going to mod pages for mods that only work in outdated versions, and requesting that they be deleted. I'm not familiar with mods and how they should be incorporated into the wiki, which is why I'm asking this question to the community. If a mod does not work in the current version, should it be deleted? Like I said, I'm not too familiar with the subject, so I haven't been adding any deletion templates myself, but if the answer is "No, just because the mod doesn't work in the current version doesn't mean the mod page should be deleted," then I will start reverting the edits from the IP(s) adding delete.--<span style="background-color:aqua;border: 1px solid"> undefined 14:18, 4 May 2018 (UTC)
 * Trivially, this is not enough reasoning. No mod would work with the ultra-new, two-hour-old JE release, and this is not valid basis to nuke every mod page there is.
 * However, mod pages in general seem to be largely abandoned. Some of them are almost contentless. I think we should change the topic of the conversation to the more general one of mod article policy on this wiki. -- 14:27, 4 May 2018 (UTC)
 * I do agree that we should discuss the mod policy on the wiki. However, for short term purposes, should I let the IP(s) add deletion templates to every single mod page there is that does not work in the current version (which is pretty much what they're doing now), or revert the edits?--<span style="background-color:aqua;border: 1px solid"> undefined 14:52, 4 May 2018 (UTC)
 * I'm not the final authority, but I'd just check, and if both the mod is available for download, and the required MC version is listed in the official launcher, I'd revert; if not, I'd replace the deletion reason with "no longer available/usable". -- 15:47, 4 May 2018 (UTC)


 * We also need to make the same decision about custom servers.
 * I'm totally happy to get rid of all the mods and move them to . It's better set up to work with mods, whereas ours are just tacked on the side with vanilla taking the main space. I think it's a lot simpler to have this wiki focus on vanilla, and FTB and individual wikis focus on mods.
 * Xbony2@undefined What's FTB's policy on abandoned mods and ones for outdated versions of Minecraft, such as what's currently inhabiting ? <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 05:20, 5 May 2018 (UTC)


 * I believe the question of mods has come up on Slack in the past, though I couldn't say what (if any) result came of it; personally I'd be in favor of Majr's suggestion to move all mod content to FTB and/or individual wikis. Doing this would also let us simplify several templates that have for years had to include support for mods (IIRC it would mostly be the inventory-related templates that are affected).
 * I added a comma to your comment to clarify your meaning, Majr, feel free to remove it if I got it wrong or you don't want it there.
 * <span class="nowrap">「」· 08:12, 5 May 2018 (UTC)
 * What would you have other language wikis do with their mod articles? The Russian wiki has a substantial portion of users contributing mainly to mod articles. -- 09:23, 5 May 2018 (UTC)
 * That would be up to each wiki to decide for themselves; the English wiki shouldn't presume to dictate how the other-language wikis have to operate. If any of them want to go the suggested route here, though, the obvious option would be checking if there's an FTB/individual wiki in that language, and if not, seeing about having one set up (assuming the FTB/individual wiki isn't currently operated as a multilingual wiki). <span class="nowrap">「」· 09:32, 5 May 2018 (UTC)


 * En's mod articles being mostly garbage and unmaintained doesn't affect other languages, so I don't see how us getting rid of them entirely does either. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 09:58, 5 May 2018 (UTC)


 * English wiki deletes mod articles.
 * English wiki removes mod support from templates/modules.
 * A non-English wiki (Wiki X) decided to keep their mod articles and use the original template/module versions.
 * Affected templates/modules are updated on the English wiki in order to introduce functionality needed on all language wikis. The update requires nontrivial adaptation (i. e. beyond copying and string translation) in order to make it work with the original, mod-supporting templates/modules. As a result, a major portion of mod templates/modules on Wiki X now requires substantially more effort to update.
 * I don't think this is an improbable scenario. -- 10:11, 5 May 2018 (UTC)


 * That's fair, in which case I would use separate templates for mods. If we were keeping mods, that's what I'd want to do anyway, as supporting mods makes some things difficult to do (like getting rid of the legacy grid images). <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 12:05, 5 May 2018 (UTC)

I'm not exactly sure what "separate templates for mods" means. Something like a  which only supports vanilla and   which also supports mods? And then  for vanilla recipes, and   for recipes from mods, plus similarly separated template pairs for all other interfaces? -- 13:04, 5 May 2018 (UTC)


 * If the features mods need diverges from the features vanilla needs enough, it would be easier yes. If possible, it should be designed so that the mod version can just implement the extra features and hook in to the vanilla version for output. But if it's simple to include, we don't necessarily need to remove mod support entirely. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 13:34, 5 May 2018 (UTC)
 * Vanilla supports mod content via namespaces (vanilla uses, other mods are assigned other namespaces).  This behavior should probably be in all of the templates, especially if Mojang does end up introducing content in other namespaces.  I don't know enough about how the templates work to actually say how feasible this is though.  (I've been adding namespaces to things when I see it, though a lot of pages still are missing them) --  16:26, 5 May 2018 (UTC)
 * oh god, I have been pinged for a bunch of stuff I haven't seen. Please poke me on Slack if you need my attention here; echo notifications are totally broken. Sorry that this is late. We accept and would be happy to accept the move of any/all mod content to the FTB Wiki, and we have no restrictions on mods being abandon or old or whatever. -   13:02, 13 May 2018 (UTC)

Create redirects
I guess yet again, I have to discuss with the community about the creation of these redirects per MinecraftPhoto4U's move summary. The redirects I want to create are, , , and. The reason is, A a ton of pages link to these that have not been fixed, B they are all very likely search terms, and C no other versions have development stages with these titles, so there's no reason not to have these redirects. Also, I'm not sure why MinecraftPhotos4U moved them to Java Edition Version history/[Development stages], as no pages would link to them and would never need to, AND it's useless for searching, as the first letter of any word is not case-sensitive in the search box.

Also, please don't think I'm trying to be rude or anything, but, I'm really not a fan of how you're moving a ton of pages without leaving a redirect, breaking a lot of links, removing search options, AND all of the moves are without discussion, could be controversial, and many times (such as this time), just really don't make any sense - and then you say that we must discuss before recreating the redirects. I'm fine with you doing this if the community agrees with this, but for me it kind of seems annoying. I really hope you don't take any offense to this - you're a great editor and you've done some great things on the Minecraft Wiki. We're all just trying to make the Minecraft Wiki a better place, and I just thought I would bring this up. Once again, please don't take this as rude or offensive, as I do not mean for it to be taken that way at all.--<span style="background-color:aqua;border: 1px solid"> undefined 22:39, 5 May 2018 (UTC)


 * About the redirects, most of them are fixes. See, , , and . Most search engines have fixed their links. Plus, it seems strange to let Alpha and Beta be in "Java Edition version history", while others are in "Version history". Thus, I don't see a reason to make these redirects-- 06:40, 6 May 2018 (UTC)


 * It is useful to have these and they existed for ages and are still linked to by a lot of pages. What's wrong with having them? –    06:53, 6 May 2018 (UTC)


 * You don't because there's no reason to be moving these redirects in the first place. Additional redirects can be created where needed, and unused and worthless redirects can be deleted, but moving them usually doesn't make sense. Since they were warned to stop moving pages, but continued, they've been blocked for a few days. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 07:28, 6 May 2018 (UTC)

Hostile Mobs not spawning in singleplayer survival.
I've started a singleplayer survival world, but I've had this problem that hostile mobs rarely spawn, only spwaners work, traps that include them spawning randomly in low light platforms seem to not be working. I've tried everything;
 * lighting up caves (which are almost empty, no mobs in there, as if I was in peaceful mode)
 * afk 24+ blocks away for longer than 1 hour (only 2 creepers spawned, figured that when I found 4 gunpowder transported in the chest by hoppers at the bottom of the trap)

If there's anything I can do please let me know. I've seen other vanilla players in youtube, they get massive quantities of spawns, but I don't get any. Screenshots included. –Preceding unsigned comment was added by ( • ) at 19:00, May 6, 2018 (UTC). Please sign your posts with
 * You may need to post in in the . Try turn your render distance to a higher level, it may work.-- 11:19, 6 May 2018 (UTC)

Texture Update sprites
So when the texture update is released, will these old textures in the InvSprite stay? Or are they going to be replaced with the new ones? I propose to move the old sprite to a separate template where it will eventually be used in the history section. – ⟨|⟩ 06:16, 9 May 2018 (UTC)


 * So something like moving InvSprite to InvSpriteOld or InvSpritePre(release date here), then updating InvSprite with the new textures?  06:20, 9 May 2018 (UTC)


 * Yes, but I'm not sure if that's necessary though. The has reached 1MB and I don't know if it will affect performance issues. –  ⟨|⟩ 06:50, 9 May 2018 (UTC)


 * Performance isn't really a concern with sprites, they're meant to have lots of images in (I'd actually be more worried about the size of the documentation page). However in this case, since it's changing pretty much everything I think it would be good to split off now, just to make editing easier (smaller page/image to upload reduces edit time), and also we should probably do this for blocks and items too. Then we just need to decide if we want to make it totally historical stuff (so whenever a texture changes we move the old image to the historical invsprite), or if it should contain all textures beginning from the texture update.
 * I'll create the base for the modules now so anyone can start getting the new textures uploaded. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 07:56, 10 May 2018 (UTC)


 * Nice, I'll start adding texture for the items now. Also I have a question, are those "TextureUpdate" suffix temporary? We seem somewhat familiar with the current sprite title. – ⟨|⟩ 10:36, 10 May 2018 (UTC)


 * Of course, the current templates/modules will be moved elsewhere once the update comes out (the name of which we need to decide on), then the new ones moved over the redirects.
 * Also I noticed you mentioned having an issue with using find in the browser creating duplicates? Did you mean you used some sort of find/replace thing to change names rather than editing them manualy? If that's the case then I think I can fix that. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 10:47, 10 May 2018 (UTC)


 * About that, I didn't use to replace (well since I can't), I used the key to find the name instead of scrolling. When I search E.g 'blue', the highlighted word will be considered as a duplicate, so I can't save it until I change all the misinterpreted words into something different. It seems like it only occurs on Edge, but I'm not sure for other browser.  –  ⟨|⟩ 11:23, 10 May 2018 (UTC)


 * Ah that wasn't the bug I was thinking of then. The issue is that edge sends a blur event to elements when it moves the find highlight off of them, regardless of if it was focused (and it doesn't send a focus event on the element which it moved the highlight to), which causes the script to think the original value is undefined (because there was no focus event to set the original name), which causes the script to "change" the current name to exactly the same as it already was making it think it's a duplicate. Was easily fixed though. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 12:10, 10 May 2018 (UTC)


 * Majr@undefined Also, how did you manage to make semi-transparent grid images while retaining its original color transparency? I had this problem while adding the Hardened Glass. – ⟨|⟩ 07:46, 11 May 2018 (UTC)


 * Well it was quite awhile ago, but I seem to recall using a feature in gimp to remove the background. I would assume it's possible in other editors. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 03:21, 13 May 2018 (UTC)


 * To remove the background in gimp it's: "Fuzzy Select" or "select by color" to select just the background, then "color to alpha". This way only the background is selected and the rest of the image remains untouched, also only editors that can handle alpha (transparency) can be used to remove the background, and beyond that only a few file formats can store images with alpha, for example PNG.  23:53, 16 May 2018 (UTC)


 * Thanks. Even though the RGB values are slightly off, it's fair enough. – ⟨|⟩ 03:41, 17 May 2018 (UTC)

How are the sprite sheets currently generated? By hand or with a script? 04:57, 17 May 2018 (UTC)


 * Its done using JavaScript, but the code is integrated into the wiki. Just head to any sprite page and click the edit sprite tab. <span class=nowrap>– · 16:18, 17 May 2018 (UTC)


 * Thank you. So i can just call the sprite editor from a sandbox and create a sprite sheet directly that way? Also i'm assuming the sprites are just block renders, correct?  02:29, 19 May 2018 (UTC)


 * The sprite editor is for editing the sheets after the fact, since you are just using the old version of the current textures just copy InvSprite to start for the textures. <span class=nowrap>– · 04:40, 19 May 2018 (UTC)


 * but in theory would starting with a blank image work?  04:59, 19 May 2018 (UTC)


 * is exactly that. I could copy the names over too, but they're not all necessarily relevant to the texture update version (like historical sprites), so I just left it to start from scratch. The inv sprites are just screenshots from the inventory, not renders. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 07:47, 21 May 2018 (UTC)

Reference template with archive support
What is everyones opinion on a reference template that allows you to specify both the original link to a page but also an archive.org link for it? Something similar to wikipedia's  option for it's citation template. 11:05, 9 May 2018 (UTC)
 * Could be useful, but I don't think we want to specify archive links for absolutely every reference. -- 11:24, 9 May 2018 (UTC)
 * I know that, it would be optional, so if you don't specify an archive link it will treat it as a normal reference.  11:27, 9 May 2018 (UTC)
 * -- 12:46, 9 May 2018 (UTC)
 * Where on the page would this template be used? Would it also have  and   parameters? –  ( &middot; ) 17:33, 9 May 2018 (UTC)
 * I was thinking it could be used in place of the  tag, so it would be used anywhere the   tag could be used. Also it could have   and maybe a   parameter that accepts a binary value (0 for false;1 for true), when true it could maybe state in the reflist that the original link is dead and to use the archive link, or maybe it could automatically redirect the reference to the archive link, otherwise when false it would just do nothing. This is currently more a concept than a working idea, and i would need some help getting a working prototype.   00:24, 10 May 2018 (UTC)


 * I've added an parameter to link (which only shows if  is set). –     04:18, 10 May 2018 (UTC)
 * That looks really good to me, except I wonder: What's the rationale behind displaying the dead URL and following it with the archive URL? Wouldn't it be better to display the original link but link it to the archive site, and insert "(archived)" without a link? That would keep users from trying to follow the dead link first. – ( &middot; ) 15:20, 10 May 2018 (UTC)


 * That would make more sense, especially since the archive link is only if the original is dead. Although i would make a slight change to your idea, rather than displaying "archived" at the end i would do something more like this:

&emsp;&emsp;&emsp;Archived page(original) – Example site, archived day month, year

22:56, 10 May 2018 (UTC)


 * I just don't agree with intentionally displaying a broken link when you have one that works. As a link it's useless. As a record of the original source it's useful for historical reasons, but not for validating the citation, and the archive page serves both purposes so it's not needed. Besides, it will still be in the template call when you're editing, assuming nobody would bother to delete it. Anyway, here's a comparison of the proposed expansions, as I understand the preceding discussion:

– ( &middot; ) 05:25, 11 May 2018 (UTC)


 * I've edited it to replace with  if the latter is set. –     19:45, 11 May 2018 (UTC)

I've been trying to use for awhile now and it doesn't seem to produce a reference entry, if it doesn't work like a reference how is it suppose to be used? 08:17, 19 May 2018 (UTC)

Sounds parameter in BlockTileEntity template
When trying to add the new audio for the conduit and beacon to their relative infoboxes i noticed the BlockTileEntity template didn't have a sound parameter, would it be possible to add one since there are quite a few tile entities that produce sound. 05:44, 10 May 2018 (UTC)


 * by Majr.--<span style="background-color:aqua;border: 1px solid"> undefined 00:13, 11 May 2018 (UTC)

A bug in the Bug template
I've recently edited the 1.13 page on the Hungarian wiki, and found out that links to Mojang bug pages at references don't work. Instead they try to link to wiki pages like MCbug:122563. I've checked the template and it's the same as the one here. What could be the problem and how could it be fixed? 16:52, 10 May 2018 (UTC)
 * You need to go to and add some interwiki prefixes from . These prefixes may be used by the template (space-separated):  . --  17:07, 10 May 2018 (UTC)
 * Thank you!  17:19, 10 May 2018 (UTC)

Audio from mp3 to ogg
Would anyone have any objection to me reuploading current mp3 files in ogg format, ogg has better compression while often providing better audio quality, and is completely open source. 01:21, 11 May 2018 (UTC)


 * It should be noted that IE can't play ogg. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 01:34, 11 May 2018 (UTC)


 * Although development for IE has been discontinued, and it is increasingly being replaced by other browsers.  01:56, 11 May 2018 (UTC)


 * Discontinued development doesn't mean it's not being used. Also Edge can't play ogg either. – ( &middot; ) 05:36, 11 May 2018 (UTC)


 * You can technically open .ogg files in Microsoft Edge. You need to install this pack to open. It is free by the way.  08:04, 11 May 2018 (UTC)


 * Since that's installed by default (as least on the April 2018 update), it may as well be considered that Edge can play ogg. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px> 08:24, 11 May 2018 (UTC)

IE has been discontinued and every other browser has support for vorbis encoded audio (webm and ogg), since IE is no longer being developed and support for it will eventually run out i don't believe it should be considered. Ogg is a much better format for audio in web browsers and has many advantages compared to mp3. If we are considering IE though then what about the other audio files on the wiki that are already in ogg format, would we reupload them in mp3 specifically for IE users? 09:48, 11 May 2018 (UTC)


 * IE is officially discontinued since the release of . I dont think we need to reupload. For IE users, they should take some time to see this article.  04:13, 12 May 2018 (UTC)
 * What about ios users?, we cant play ogg-- 03:38, 13 May 2018 (UTC)

File:Ground_impact1.ogg
why is nothing being done about it?-- 06:29, 12 May 2018 (UTC)

Education Edition Infdev and other backlog oddities
The reason behind this, as well as way too many other entries, is that  checks the existence of articles on similarly named versions of other editions by calling , which creates a backlink even if the target page is never supposed to exist.

Pretty much the only solution is to code the corresponding infobox row value manually. Manual substitution of already automatically inserted links shouldn't be too much of a problem. -- 13:02, 13 May 2018 (UTC)
 * The same also goes for . See .   00:51, 16 May 2018 (UTC)

Turtle shell documented on page, and has its own page?
Is the Turtle Shell being documented on the page, but also having  intentional? - 23:39, 17 May 2018 (UTC)


 * Hello? Is anyone there? - 00:32, 19 May 2018 (UTC)


 * I believe it is intentional. Because turtle shells can be worn as armor, but are also very different from all other armor making a separate page good for explain turtle shells in particular.  02:16, 19 May 2018 (UTC)


 * The, , and  pages have their own pages but are also a part of the  page. There is an unfinished discussion on whether to merge them. I would support merging these pages, as they are wearable, protective items that have a material associated with them (e.g., ‘’iron’’ helmet), and various enchantments that can be applied. Turtle shells are different because they are the only “armor” crafted using scutes, they provide water breathing as well as protection, they are not enchantable, and they can also be used for brewing. However, there is  of the armor page that links to other wearable items, such as pumpkins and elytra. I would support mentioning turtle shells here and otherwise make turtle shells a separate page. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 14:15, 19 May 2018 (UTC)


 * Actually turtle shells can be enchanted with an anvil in survival mode.  00:31, 20 May 2018 (UTC)


 * , the page does not mention enchantments. Could you please list the enchantments available on a turtle shell? <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 02:59, 20 May 2018 (UTC)


 * I added the enchantment section to the page.   02:54, 30 May 2018 (UTC)

Minecraft Wiki (EN) Discord?
has already created a Discord server for this wiki, but there's a problem.

This is our situation:
 * 1) We have a Discord server intended for wiki users and just interested community members.
 * 2) It's not prominently linked anywhere (such as on the community portal).
 * 3) There has been no discussion behind its creation.
 * 4) It has been created by a non-administrator.


 * A server not prominently linked will miss its intended audience.
 * A server prominently linked is implied to be endorsed by site administrators.
 * A server for a site not administrated by that site's administration team, but endorsed by them, is weird at best and problematic at worst.

I think there's no point in a permanently unofficial and unrecognized Minecraft Wiki Discord server, and that we should only request the server to be taken down as a last resort.

Decisions need to be made on the following points:
 * 1) Does the wiki need a Discord server?
 * 2) If it does, can it be, after some reconfiguration, the server created by Crraftt?

I propose the following:
 * In this discussion topic, the community decides on the points 1) and 2) mentioned above.
 * If the decision is against 1) (i. e. a Discord server is not needed), a further decision will need to be made on what to do with the existing one. Note: Crraftt@undefined please don't act rashly if the discussion starts to go against having a server, it would be better if you waited for the resolution before e. g. taking the server down.
 * If the decision is for 1), but against 2), a further decision will need to be made on the procedure of the new server's creation and deprecation/decommissioning of the existing one.
 * If the decision is for 1) and 2), Crraftt is asked to reconfigure the server as per the discussion's resolution (likely including, but not limited to, transfer of the "Server Owner" status to a confirmed wiki administrator), and the server is advertised as per the discussion's resolution (e. g. sitenotice, community portal, dedicated page like, etc.)

I favor the points 1) and 2) mentioned above. -- 17:37, 20 May 2018 (UTC)
 * While I'm not necessarily an active member of en wiki, I moderate a Discord server for other MCWiki project. I feel like a Discord server is beneficial to our (much smaller) community. It's a place where we often have a possibility to talk about edits to members who made them directly, definitely easier than discussion pages. With our current setup (recent changes feed, IRC bridge, some bots) it's also pretty neat place to hang out and banter or monitor changes. I think if properly moderated (with moderators spread around the globe) the server would be beneficial for this community as well. However, one of my fears when I created the server for project I'm contributing to was that it would distribute the discussions between the wiki and Discord, which is not what I want in a open project, chats on the Discord are closed only to server members. I think this is a really important matter that should be discussed further. Answering to two questions:
 * 1. I think it would be beneficial for the wiki to have a Discord server
 * 2. I'd feel safer if the server was in hands of administration member or at least more active/experienced editor, I don't mean any offence to Crraftt, I'm pretty sure their intentions are good and all they want is to make the wiki better, they seem very passionate about how they could help, but still. If Crraftt proves to be a good person to lead the server however, I have no issue with their server being the one for this community.  18:12, 20 May 2018 (UTC)
 * Perhaps I should have been more clear, but Discord has a concept of "Server Owner". Whoever created the server is initially designated such. If this person decides so, they can transfer this status to another user of the same server. A server owner has total control of the server and cannot be restricted from anything.
 * Given Crraftt's reaction in Slack, I don't think he would be unwilling to transfer the "server owner" status to a wiki admin. Thus, he wouldn't need to lead the server. -- 18:22, 20 May 2018 (UTC)
 * I'm well aware of how ownerships work on the Discord, but considering the fact Crraftt didn't say anything about transferring the ownership I assumed it wouldn't happen.  18:39, 20 May 2018 (UTC)

I feel a discord server for the wiki would be very useful, i understand there is a slack server but it seems to be more difficult to use than discord. Not to mention more people use discord than slack, which would allow more people to get involved in discussions. But i also feel the discord server should be created by a wiki admin, and should have a set of rules setup specifically for it as it would be difficult to apply wiki rules to a discord server. 01:15, 24 May 2018 (UTC)
 * I agree. - ( · ) 06:53, 24 May 2018 (UTC)

Why is the invite not working? -  14:22, 24 May 2018 (UTC)


 * MinecraftPhotos4U@undefined What happens when you click it?--<span style="background-color:aqua;border: 1px solid"> undefined 14:24, 24 May 2018 (UTC)


 * The original one may have expired. Here's a new one, it shouldn't expire. -- 14:26, 24 May 2018 (UTC)

So where does this currently stand, has a decision been made regarding this topic? 22:55, 27 May 2018 (UTC)
 * Yeah, the Discord server is already up and running with roles, channels, bots etc. A lot of wiki staff is there as well (currently 45 members overall). It's supposed to be more "public" soon. You can join to it using the link AttemptToCallNil posted above.  23:10, 27 May 2018 (UTC)

New snapshot pages and their related article reference
Every snapshot comes with a related article on the main website, and we create a new page for each. But each additional snapshot of the same week that is released, does not actually create a new article, but instead the previous is updated. However, the problem there is that Mojang apparently doesn't update the link to those articles consistently. Sometimes the article of an additional snapshot keeps the link of the previous, and sometimes the link gets updated to the name of the new snapshot, but not even consistently during the same week. For example, the articles for snapshots 10a, 10b, 10c and 10d all are linked by 10a, but 20a, 20b and 20c are all linked by 20b.

I just updated all snapshot articles of to test and fix them (some were dead already). At the same time I took the opportunity to replace references to article with snap. The snap template exists specifically for these links, an alternative to the article one, so I think we should always use that instead of article. The only visual difference is that it does not include quotes around the link.

So I would like to ask everyone to from now on use snap for consistency, and secondly, to always be aware that the article link does not always include the name of the particular snapshot you're referring to. So always update the links to all same-week-snapshot articles, in case a new snapshot comes out and Mojang decided to change the existing article link. Thanks :) Lastly, do we need to update all older snapshot pages with this template as well? – <span class="plainlinks" title="View User PROfile">[ <span class="gamepedia_pro_user">Jack McKalling ] [   ] 16:56, 23 May 2018 (UTC)


 * I have updated the template to include quotes, and as I am the creator of the template, I have been updating the latest snapshots to incldue snap and hoped that other users would catch on. –   05:24, 24 May 2018 (UTC)


 * To clarify, where on the page would snap be placed?  05:42, 24 May 2018 (UTC)
 * The template specifies the link to the Minecraft.net snapshot article, and it goes into the reference just after the snapshot name of the first sentence on the page. Like this:  The first argument is the name of the snapshot to link to, and it may be different than the one that the page is about. – <span class="plainlinks" title="View User PROfile">[ <span class="gamepedia_pro_user">Jack McKalling ] [    ] 07:31, 24 May 2018 (UTC)

Simplified version guides
For about a week now i've been working on a simplified 1.13 guide, i designed it to allow players to get a general overview of the additions and changes of 1.13, without being overwhelmed by the technical information on the page. I think it is finally ready to let people see it, and i would appreciate opinions and suggestion from everyone, but keep in mind it is still a work in progress. The page is currently located. 07:14, 24 May 2018 (UTC)

The guide for 1.13 should be done within the next week now, so do we know yet where it will go? I still think a tutorial page would be fine. 23:09, 30 May 2018 (UTC)


 * I definitely like the idea of it, and your guide certainly seems more appealing to readers than just a bunch of text, like how the normal version pages are. I'm not so sure about what it should be moved to - a tutorial page seems reasonable to me, but I would like to hear the opinions of other users. If you're planning on making version guides from 1.0.0 - to present, though, that's quite a lot - it may be worth it to even create a new root page name for version guides exclusively; e.g. Version guides/1.0.0, Version guides/1.8.7, Version guides/1.12.2, etc. For now, though, it may be better to just create this as a "Tutorials" sub page.--<span style="background-color:aqua;border: 1px solid"> undefined 23:14, 30 May 2018 (UTC)


 * Would it be fine to link to the guides from the main Java Edition versions template even if they were tutorials? I think that would be cool. –   |  23:40, 30 May 2018 (UTC)


 * I definitely like the idea of that. It would be kind of crammed and a bit much to condense in a small space, but I don't think it would be too bad, especially because we're not doing it for snapshots.--<span style="background-color:aqua;border: 1px solid"> undefined 23:43, 30 May 2018 (UTC)


 * I also like the idea of that, but I think it would only make sense on doing it for "full" releases -- not e.g. ones like or such that don't have a lot of changes (the main article for it is definitely enough for those).  Perhaps they should go under the version subtitle ("Update Aquatic", "World of Color Update", etc) in the template?  For minor updates that still added content such as  I'm not entirely sure how that would work, though (perhaps just a subsection on the main guide?). --  02:33, 31 May 2018 (UTC)


 * as a subpage of the major version update page, like, not . Because the scope of the version update page includes all releases of that major version, which the guides are also if I understand correctly. And for instance is just one release, just like 1.13.x. I find this hard to explain, but to show what I mean, it could be added to the template like this:
 * {| style="border: solid 1px black"


 * style="text-align: right; font-weight: bold" | 1.5
 * style="text-align: right; font-weight: bold" | 1.5


 * }
 * – [   ] 08:55, 31 May 2018‎ (UTC)


 * That's actually an even better idea in my opinion. I definitely like that. And I do think the minor updates should be mentioned somewhere - and having them as a subsection of the main guide makes the most sense to me.--<span style="background-color:aqua;border: 1px solid"> undefined 12:07, 31 May 2018 (UTC)
 * I also forgot to mention that if the guides become a subpage of the major update page like I showed above, the main page should also offer a link to its guide somehow, on-page. – [   ] 12:20, 31 May 2018 (UTC)

Madminecrafter12 for admin?
<div style="background-color: #efe; padding: 0 10px 0 10px; border: 1px dotted #aaa;">

The result of the discussion was promote .

Proposed both on Discord and on Slack. In the last weeks, a significant part of vandalism and spam has been handled by global administrators, and it has been suggested new local administrators should be promoted.

In specific, was the candidate with the most support. I suggest the proposal is further discussed here, and everyone who's voiced their opinion outside the wiki re-post it in this topic.

I offer strong support for the idea to promote new administrators (or at least one), as well as weak support for the idea to promote Madminecrafter12 in particular. -- 14:14, 24 May 2018 (UTC)


 * I appreciate you taking the time to post this. I'm also going to ping many of the people who were active in this matter outside of Slack so that they know this is going on: --<span style="background-color:aqua;border: 1px solid"> undefined 14:28, 24 May 2018 (UTC)
 * I have reasons to believe Madminecrafter12 is the right user to acquire administrator status. With his experience on this and other wikis, good history of contributions and good communication with rest of the community he has enough of qualities to properly administrate the wiki. With Gamepedia staff admitting Minecraft Wiki needs more administration, I think adding new administrator is a responsible, if not necessary thing to do. I hope the current administration agrees.  14:52, 24 May 2018 (UTC)


 * MCW needs more active admins. GRASP and global admins shouldn't have to step in as often as they do (almost daily), especially for as large and active a wiki as MCW. Whether or not that should be Madminecrafter is up to you guys. -- 15:46, 24 May 2018 (UTC)


 * Agreed on the new admin need, uncertain about Madminecrafter12. He's made a lot of useful and good quality contributions, but I'm not sure about his administrative decision making. I haven't seen much of that to be able to judge it. How are new admins brought up to speed with admin policies and procedures, and would they get training, supervision or some other form of guidance on how to deal with their new abilities and responsibilities? Just casually concerned and caucious, not trying to be a downvoter. – <span class="plainlinks" title="View User PROfile">[ <span class="gamepedia_pro_user">Jack McKalling ] [   ] 16:06, 24 May 2018 (UTC)
 * To be honest, most of what I know about admin tools is from watching how many experienced admins handle situations many times. There are several guides for admins on the Gamepedia Help wiki, and there are many more on Wikipedia, and I have read the ones that I think are the most important. However, I've found that just watching how admins handle situations (especially when comparing them to how I would handle them), is the most helpful to me. Also, I do think it might be worth noting that I'm admin on two other wikis, one of them being a Gamepedia wiki. I don't think admins necessarily get any specific training or anything, but I do think the community and bureaucrats prefer to promote admins who are familiar with how admin tools work and when to use them.--<span style="background-color:aqua;border: 1px solid"> undefined 16:29, 24 May 2018 (UTC)
 * Also forgot to mention I'm interested in the prior Slack discussion, but I fear I can't get access to it on this machine. Last time I joined a team on slack, the platform rendered disabled due to lack of support in my browser. I'm really hating my old machine here. – <span class="plainlinks" title="View User PROfile">[ <span class="gamepedia_pro_user">Jack McKalling ] [   ] 16:12, 24 May 2018 (UTC)
 * Echoing the general opinion. Also, Madminecrafter12’s promotion would introduce “new blood” into the wiki’s administration — the last newly appointed admin,, has actually deserved his new status (in my opinion) for many years. — <span class="nowrap"> ( | ru.Wiki Admin) 16:15, 24 May 2018 (UTC)
 * That was one of the things I thought the community may not be supportive of - the fact that I've not been registered for a long time like many admins are. I definitely have learned a lot in the time that I have been involved with wikis, though. And I agree that KnightMiner should have been appointed admin a long time ago - it seemed like the community was fully supported of him in early-mid 2015, but he didn't become an admin till late 2017 somehow.--<span style="background-color:aqua;border: 1px solid"> undefined 16:40, 24 May 2018 (UTC)


 * - The user have made many constructive edits, even creating the templates speedy delete and welcome-vandal templates, both are good, the most useful template was the speedy delete template. I Strongly support that the user could become admin, but should be here for at least 1-2 months more. <span class=nowrap><font face="Trebuchet MS"> undefined 16:31, 24 May 2018 (UTC)


 * of the Russian Wiki was promoted to admin just two months and ten days after registration on October 2010, but he apparently came from Wikipedia or some other wiki. The candidate is known to be a Wiki Guardian for a different Gamepedia project. — <span class="nowrap"> ( | ru.Wiki Admin) 16:45, 24 May 2018 (UTC)


 * Correction: HEKP0H is one of the founders of the Russian wiki. -- 16:50, 24 May 2018 (UTC)


 * also - I would be extremely comfortable with no reservations with Madminecrafter as an admin. The way he comports himself as an editor interacting with his fellow editors, old and new, and with anons, is exemplary in my opinion, and is an example worth following. He displays a self awareness of how new he is, comparative to others who have taken the role, and I believe he fully appreciates that there is much to learn -- and he certainly cares to do so, and to do things well. If he will accept the keys to do some of the things that need done around here, I fully trust him to have them. –   |  19:12, 24 May 2018 (UTC)


 * There really is no negative consequence to making Madminecrafter12 an Administrator in my opinion. He is very active in the Slack community, already a Wiki Guardian on another wiki, and has demonstrated good hard work and determination. He is well respected and trusted by many. All good qualities for an Administrator. –  17:35, 25 May 2018 (UTC)


 * -- 22:14, 25 May 2018 (UTC)


 * as well. -  22:22, 25 May 2018 (UTC)

Shameless self-promotion
Just wondering, what is the general opinion of the community on me becoming an administrator here? Because I am active, in a different time zone from many other administrators, already have administration experience...

I think I am capable of being at least a basic anti-vandal/spammer who monitors the Recent Changes several times every day. Any opinions? -- 20:19, 24 May 2018 (UTC)


 * . –  |  21:29, 24 May 2018 (UTC)
 * 21:52, 24 May 2018 (UTC)
 * . It certainly can't hurt to have an extra admin, especially if they're known to use the tools properly. I do think that it would be nice to promote another admin besides you as well - whether or not that would be me is for the community to decide. But if you and one other user become an admin, I don't think we'll be needing another admin for a while - unless an admin suddenly decides to leave MCW indefinitely.--<span style="background-color:aqua;border: 1px solid"> undefined 22:22, 24 May 2018 (UTC)


 * 23:58, 24 May 2018 (UTC)


 * The wiki currently only has 13 admins exclusing bots and Abuse Filter. I suggest adding more 3 admins in total. <span style="font-family:minecraft"> 01:24, 25 May 2018 (UTC)


 * - ( · ) 06:52, 25 May 2018 (UTC)


 * I also support AttemptToCallNil for Administrator. They also have been active in the Slack community, have demonstrated good hard work and determination, and are respected and trusted. –  17:35, 25 May 2018 (UTC)


 * , good experience with AttemptToCallNil. Self-promotion looks promising, with your success here, but I admit I don't want to carry admin responsibilities myself. I fear the power. – <span class="plainlinks" title="View User PROfile">[ <span class="gamepedia_pro_user">Jack McKalling ] [   ] 20:38, 25 May 2018 (UTC)


 * -- 22:14, 25 May 2018 (UTC)


 * -  22:22, 25 May 2018 (UTC)


 * –   22:51, 25 May 2018 (UTC)

New mainterace templates?
Hello, I thinked today that we should need some mainterace templates, and modify the existing, and upload some images for those templates, and those templates can include, example: rewrite, more images, just released version or snapshht, to notice the readers that the pages need more rewrite. I can also add a navbox for the existing templates and deletion notices. A warning template for copyright violation can also be added, to use on copyright violation pages. If ok, can I begin to create those pages. Questions, ask below <span class=nowrap><font face="Trebuchet MS"> undefined 16:58, 24 May 2018 (UTC)


 * My opinions about the creation of each template:
 * Rewrite - In my opinion, that may not be quite necessary. You could just use Cleanup and say "This article needs to be rewritten" for the first (reason) parameter. Also, is not an extremely huge category right now, so currently I don't think it needs to be divided. As more and more features are added to Minecraft, though, this may could eventually become a useful template though.
 * More images - We already have that one - MoreImages. However, I do think it probably should be moved to have space in between the two words - I'm definitely going to create a redirect with the spaces though.
 * Just released version or snapshot - I don't really see the point of that. How would that really be useful?
 * Copyright vio - Could just mark those deletion. The admins aren't really that active with deleting pages requesting to be deleted anymore, but I doubt they would delete it quicker if it were separate.


 * I'm open to other opinions, though, and just because I may not be a fan of some of these doesn't mean you're not allowed to create them.--<span style="background-color:aqua;border: 1px solid"> undefined 17:09, 24 May 2018 (UTC)


 * Oh, and another thing, I do like the images idea - I think it makes the maintenance templates a lot more visually appealing with images.--<span style="background-color:aqua;border: 1px solid"> undefined 12:18, 25 May 2018 (UTC)

Allow editors to lock pages from ip edits for short periods of time
Would it be possible to add a way for editors to temporarily protect a page from ips making edits in order to avoid the long revision wars like on 18w21a, which ended up filling the page with obscenities that people visiting the wiki shouldn't need to see. For example have a way to protect it for one to two hours in order to give time for an admin to come and either extend the page protection, or block the ip. 23:53, 24 May 2018 (UTC)


 * i would like your opinions on this.  23:55, 24 May 2018 (UTC)
 * I am not sure if we want users to abuse this. However, it may be helpful to add a “Short Protector” user group., is this possible? <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 00:00, 25 May 2018 (UTC)


 * , are you saying that you think all users, or a certain group, should be able to protect pages, or are you just asking if there is a way for anybody to protect a page? If you mean the second option, then admins can semi-protect (allow only registered users) or fully-protect (allow only admins) a page. However, protection is usually (there are many exceptions though) only done when there are mutiple users vandalizing a page - otherwise, it's usually just better to block the vandal.--<span style="background-color:aqua;border: 1px solid"> undefined 00:03, 25 May 2018 (UTC)


 * I'm suggesting allow all, or maybe a select few (but how to decide on that?), confirmed users semi-protect a page for a short period of time in order to stop the vandalism until an admin can block the ip.  00:05, 25 May 2018 (UTC)


 * I definitely don't think we should allow all confirmed users to protect pages (on MCW, confirmed users are the same thing as registered users). That means that you could literately just create an account, completely blank a page, and then fully-protect it so that the vandalism can only be reverted when an admin sees what happened. Creating a new user group is a better, but I'm not sure it's worth it to create a whole new user group just to protect pages. We're currently discussing a similar matter on Slack.--<span style="background-color:aqua;border: 1px solid"> undefined 00:11, 25 May 2018 (UTC)


 * Why would it require an admin? I'm suggesting having it only semi-protect the page not fully protect it. Though i do somewhat agree that the vandal could create an account, so there would need to be a way to decide who gets to protect pages.  00:15, 25 May 2018 (UTC)

Could we get your opinion please? 00:17, 25 May 2018 (UTC)


 * I don't think MediaWiki supports granting individuals such specific protecting capabilities. Its either you can protect up to your role or not, no control over specific time.
 * Main thing I'd be wary about giving a larger group the right to protect is people being too quick to protect pages when they get any vandalism. Mostly, if too many people get the ability, its more likely to be abused, and if too few get it that's just adding another group to ping if vandalism happens.
 * Best solution for this is to probably adjust the abuse filter if there are patterns that can be tracked, or to continue the other conversation on specific users to give additional rights. <span class=nowrap>– · 00:49, 25 May 2018 (UTC)
 * On Wikipedia, there are extended confirmed users. Can we add this new group? Additional rights can be given to these users. <span style="font-family:minecraft"> 01:02, 25 May 2018 (UTC)
 * As mentioned earlier, we (Gamepedia) do not distinguish between registered users and autoconfirmed users, so merely having an account is sufficient to be an autoconfirmed user. We can create a new group which is allowed to protect (or semi-protect) pages, so if that's the way you want to go we can do that but i don't see a whole lot of benefit —  12:58, 25 May 2018 (UTC)


 * As an option, there could be an adminbot responding to commands by authorized users who are not administrators. The commands could include temporary page protection and/or even short-term blocks. The bot could be linked with the Discord server. -- 13:03, 25 May 2018 (UTC)


 * I would support this user group, as some edit wars receive many edits before an admin can semi-protect the page or block the user.
 * KnightMiner@undefined I would also support an abuse filter. Since edit wars often involve a user reverting reverts to their own edits, the filter could prevent anonymous users from posting an edit that is similar to a recently-reverted edit. <span class="nowrap" style="background-color:#000;border:1px dotted #FFD">undefined 14:21, 25 May 2018 (UTC)


 * Blobs2@undefined We were discussing this on Slack, and we definitely thought that the way to go was to make it so that if an IP edit is reverted 3 or 4 times within a certain timespan, they can't make another edit to that page for a certain amount of time. However, what we're not sure about is whether the abuse filter is able to detect that an edit has been reverted. If this does turn out to be possible, I definitely think that we should see how the AF goes before creating any kind of user group.--<span style="background-color:aqua;border: 1px solid"> undefined 14:24, 25 May 2018 (UTC)


 * Just checked on the Russian wiki, abuse filters can't perform such operations on page histories. -- 14:44, 25 May 2018 (UTC)


 * Oh, darn. :(--<span style="background-color:aqua;border: 1px solid"> undefined 14:46, 25 May 2018 (UTC)


 * told me that he had a couple ideas on how to do what I had requested for the AF detecting edit reverts, and that he would experiment with them later.--<span style="background-color:aqua;border: 1px solid"> undefined 20:12, 25 May 2018 (UTC)


 * Late to the discussion, but I like the idea of a specific usergroup for dealing with spam/vandalism/edit warring etc. These tasks are not for the casual editor, as KnightMiner pointed out we need to appoint individuals who are trusted to have those abilities. I would suggest to start with the people who have already been dealing with these issues and contributed well at it. So I support a new usergroup, similar to the Autopatrol one we have, but there need to be selections and/or applications for it as well, not just on discord or slack. What is the difference between those two btw? – <span class="plainlinks" title="View User PROfile">[ <span class="gamepedia_pro_user">Jack McKalling ] [   ] 20:32, 25 May 2018 (UTC)


 * Maybe like a "verified" group? That could contain (edit: *regular*) users that have been on the wiki for over, say, one year (edit: and haven't had any trouble). –   22:12, 25 May 2018 (UTC)


 * I definitely think that if we do decide to do something like this, admins or bureaucrats should have to approve the users - how long they've been on the wiki or how many edits they've made would not be safe enough in my opinion.--<span style="background-color:aqua;border: 1px solid"> undefined 22:14, 25 May 2018 (UTC)


 * Just for reference, the Russian wiki once had a "moderator" user group which could delete, hide revisions and perform rollback. This group was disbanded when of the only two members one was demoted, and the second one was promoted to a full administrator. Even if the group suggested in this topic is formed with different permissions and generally in a different context, the group may meet the same fate.
 * One of the factors contributing to the demise of the Russian wiki group was probably an increase in local administrator activity. Given that there are two RfAs being discussed right now, both with positive outlook, creating an additional layer of vandalism combating may be excessive. -- 22:24, 25 May 2018 (UTC)


 * A "Moderator" group sounds like it would work perfectly, so long as the group has the ability to semi-protect pages in the event of excessive vandalism.  00:37, 26 May 2018 (UTC)


 * I definitely support the idea, but there are things I want to say about this.


 * I recommend first seeing how both of the requests for adminship turn out before doing this. Who knows, maybe this won't be necessary if 1 or both of the candidates that are being discussed on the community portal talk page end up becoming an admin. I definitely think that we should see how that turns out before creating a whole new user group.


 * I would suggest having the following modifications from the user rights that the Russian wiki moderator group had. First of all, I'm not sure how necessary the delete tool would be. Right now it's not being used to revert that much vandalism, and it seems like it's one of the most sensitive admin tools, and abuse of it could lead to very drastic consequences. I definitely think that if we do decide to allow this moderator group to use this tool, that they should not have access to . As for the hiding revisions, I haven't really made up my mind - other opinions and suggestions are welcome. I definitely think that rollbacking should be included.


 * And now for the protection part. Obviously, this is kind of the whole point of the group - otherwise it would just be a rollbacker group. Well, actually now that I think about it, that may not be so bad either... But anyways, one of the problems is, the ability to fully-protect pages as well as semi-protect pages are the same user right and listed on the same screen ([pagename]&action=protect), so I'm pretty sure there would be no way to allow moderators to only semi-protect pages (somebody please correct me if I'm wrong). If we did allow them to fully-protect pages, then it seems kind of counter-intuitive to not allow them to edit fully-protected pages, so it would probably be better to give them that right as well. I don't think that moderators should be allowed to block, though, as in my opinion, that's one of the more sensitive admin tools as well. It not only has potential to be abused, but a user may not be sure when to use it, and may block a good-faith editor unfairly.


 * Besides those things, this sounds like a good idea. Thanks for bringing it up, !--<span style="background-color:aqua;border: 1px solid"> undefined 00:56, 26 May 2018 (UTC)


 * If I remember correctly, you are only allowed to protect a page to a group you have access to, which is why all admins are also directors: to allow them to protect pages with director. There is a chance that feature is from an extension though, so don't quote me on that. <span class=nowrap>– · 01:09, 26 May 2018 (UTC)


 * Hmmm... interesting, that would definitely be nice if that is true. Are you basically saying that if, e.g. all registered users could protect pages, they could only semi-protect pages but not fully-protect pages, because they wouldn't be able to edit fully-protected pages? Also, would it work vice versa, e.g. if the same case were true, registered users wouldn't be able to downgrade a fully-protected page to semi-?--<span style="background-color:aqua;border: 1px solid"> undefined 01:20, 26 May 2018 (UTC)


 * I'm pretty sure that would work, if not I'm sure another wiki has made an extension granting that ability by now. So if going that route we would give them the ability to semi-protect for short times, and maybe an new protection level for the new "editors" and admins for the case of edit wars (if the edit war involves editors of course, not stopping after the protection would be grounds for possible loss of the additional editor rights). <span class=nowrap>– ·  18:31, 26 May 2018 (UTC)


 * &ensp;I do somewhat disagree with Nixinova's idea of it being time based, i.e. one year, because i feel time is a very unequal measure. Someone who has been here a year is not necessarily more qualified than someone who has been here six months. It should be entirely based on the individual, regardless of time. So perhaps change it to a certain number of edits, combined with how extensive those edits were?  03:52, 26 May 2018 (UTC)


 * As I said on slack, I with having some sort of trusted group to allow additional management without increasing the attack vector that admins create. It should be the quality of the edits, not amount of time the editor has been here, that determines if they should be in the trusted group. The main thing to decide is what permissions the trusted group would get, what is actually possible to implement in MW, and who should be in the group. <span class=nowrap>– ᐸ <small style=display:inline-block;line-height:9px;vertical-align:-3px>  07:49, 26 May 2018 (UTC)


 * UESP has a Blocker group with short-term block rights only, but that's apparently a custom extension. suggests user rights' assignments are Boolean values (true/false) and have no parameters which can be set on a per-group basis; this page also lists no other blocking rights beyond the standard one, which.
 * I have my doubts on "soft" enforcement of short-term administrative actions by trusted users (e. g. a blocker can issue blocks of any length an admin can, but when an admin comes, blockers' blocks are reviewed and their lengths adjusted as necessary). Judging by every comment in this thread though, people are looking for a solution built into the software.
 * But there's also my idea of an adminbot issuing short-term protections/blocks based on authorized users' commands. It hasn't received any comments, should I consider it rejected? -- 08:56, 26 May 2018 (UTC)


 * I would avoid an admin bot unless the software entirely prevents what we want, they tend to feel a bit clumsy and are one extra thing to learn. It would be a lot easier on the editors to just add a new user group. <span class=nowrap>– · 18:31, 26 May 2018 (UTC)

So has a decision been made about this yet? 09:18, 9 June 2018 (UTC)

Use of upcoming and only templates
What is the best parameter to use for the upcoming or only templates, or a combination of them, for when a feature has been released for Bedrock Edition but only appears in snapshots for Java Edition, and does not appear in LCE at all? This is kind of the case right now for quite a few features currently.--<span style="background-color:aqua;border: 1px solid"> undefined 20:10, 25 May 2018 (UTC)


 * I would suggest:  which is
 * A digression: lately I've toyed with the idea of a single template that accomplished something like: <Bedrock & upcoming Java Edition 1.13 only ></Bedrock & upcoming Java Edition 1.13 only> -- but A) it becomes one of those difficult-to-translate templates, and B) the combinations are many and varied, and I couldn't think of easy to use parameters for all cases. –  |  20:39, 25 May 2018 (UTC)


 * Ok, thanks! The second one would definitely be ideal, but you're right - with all the possible combinations and variations, I'm not sure how practical it would be. I'll do the first one, though. :)--<span style="background-color:aqua;border: 1px solid"> undefined 21:22, 25 May 2018 (UTC)

Proposal: Classification of edits in others' user pages
Discussed on the Discord server. Requested post.

Proposed classification follows ("host" is the user whose userspace is edited, "actor" is the one who edits; definitions used for convenience):


 * Minor edit: a minor correction unrelated to technical maintenance (spelling, grammar, etc.) Allowed unless either prohibited by host, or for actor.
 * Major edit: addition of content or non-maintenance formatting changes. May be explicitly allowed on draft pages by host, prohibited otherwise.
 * Maintenance edit: correction of problems which negatively affect site functioning, e. g. which cause the page to appear in any automatically filled list or category such as "pages with script errors". Allowed unless prohibited for actor. Host cannot restrict, reverting is considered disruptive editing.
 * Reversion of disruptive edits: same rules as for performing maintenance edits.
 * Administrative actions: an action performed as a reaction to violations of site rules. Such actions by non-admins can be overruled by admins. If the actor is an admin, the action cannot be reverted without prior admin noticeboard discussion.

Reasons for writing the proposal: it clarifies a major point not explicitly listed anywhere. Additional issues arise from the unclear status of maintenance editing of others' user pages. -- 17:00, 27 May 2018 (UTC)


 * I agree that maintenance edits, reversion of disruptive edits, and administrative actions are fine - for obviously reasons. I also definitely think that major edits should be prohibited. However, I also support that minor edits should not be made either unless the owner has given permission to make minor edits. This hasn't been a problem lately, but if we advertise that one may make minor edits to other people's user pages, I don't think that would be good. I mean, it's somebody's user page for a reason, and if they don't mind theirs being edited, they can say so. Also, I could see minor edits having a gray area as to what is considered minor and what major.--<span style="background-color:aqua;border: 1px solid"> undefined 17:07, 27 May 2018 (UTC)
 * Agreeing with concerns. Version 2:
 * Maintenance edit: correction of problems which negatively affect site functioning, e. g. which cause the page to appear in any automatically filled list or category such as "pages with script errors". Allowed unless prohibited for actor. Host cannot restrict, reverting is considered disruptive editing.
 * Reversion of disruptive edits: same rules as for performing maintenance edits.
 * Administrative actions: an action performed as a reaction to violations of site rules. Such actions by non-admins can be overruled by admins. If the actor is an admin, the action cannot be reverted without prior admin noticeboard discussion.
 * Content edit: any other form of edit. Acceptable only if allowed for actor and by host.
 * -- 17:14, 27 May 2018 (UTC)
 * -- 17:14, 27 May 2018 (UTC)
 * -- 17:14, 27 May 2018 (UTC)


 * I assume this has something to do with a proposed guideline? Because to my knowledge there is currently no official prohibition in this wiki against editing user pages other than the suggestion in . So where is this guideline being discussed on the wiki? (Please don't tell me to go read the Discord. Any discussion on Discord is preliminary and unofficial, not a substitute for talk page discussion.) – ( &middot; ) 17:07, 9 June 2018 (UTC)


 * There is only a suggestion, and that is the problem. In addition, there is general, often unwarranted hostility against any modification of others' user pages. If there were to be a guideline (and one is being proposed), people could refer to it when editing others' user pages or discussing such actions. Currently, the only relevant provisions are either nowhere explicitly stated or too general. -- 17:49, 9 June 2018 (UTC)


 * I'm all for using Discord to discuss ideas one-on-one or with a few, but I'm strongly opposed to using it for consensus building. I think reaching a consensus on Discord would tend to make those involved feel a sense of being finished and would subtly discourage them from considering objections raised later on the wiki. I'm not saying that I don't trust Discord users to try and be fair in their later deliberations, I'm just worried that once a group of editors agrees on something, they'll tend to act like a bloc, and an us-versus-them mentality could ensue. That's human nature. So if you're getting ready to propose a guideline, I hope you'll bring it to the wiki soon. –  ( &middot; ) 20:35, 9 June 2018 (UTC)


 * In the context of this proposal, Discord hasn't been used to build a binding consensus on Minecraft Wiki policy. I am aware of your concerns and share them. I cease my maintenance of the proposal for reasons not related to this discussion. -- 22:01, 9 June 2018 (UTC)


 * A while ago I proposed adding a page with some of our user guidelines, similarly to the talk page guidelines. It would probably be good to have something similar to list not just when you are allowed to edit user pages, but what is allowed on them in the first place. from back then, it basically describes what is the user space, what it is allowed to contain, then who can edit it. Its been a while since I wrote it, but for the most part everything came from common practice that I just wanted an official place to write.
 * As for the specific proposal, I feel it could be condensed a bit. For instance, you could cover "both administrative action" and "reversion of disruptive edits" as "users may remove content that breaks the rules". I also personally do not think major and minor edits should be separated, I do not think users should be editing other people's user pages at all for non-maintenance tasks such as typos without permission. <span class=nowrap>– · 00:00, 10 June 2018 (UTC)


 * That draft of yours actually looks good. Why don't we implement that, possibly with some modifications?
 * Speaking of which, here are my suggestions on that draft:
 * According to my knowledge, "articles" is typically reserved to refer to content namespace pages. I suggest replacing "articles" with "pages" in this sentence.
 * That just sounds weird to me. (in Harbinger's voice) "I AM ASSUMING DIRECT CONTROL OF THIS USERSPACE." (back to normal voice) I suggest replacing this with "directly associated with a specific user" or something similar.
 * — similar to #1, but not exactly the same, I'm not sure this should be changed.
 * Strictly speaking, .css pages are stylesheets, not scripts. Also, the extension only affects the default content model of a page (it can be changed). On a side note, I've seen some users put all their actual main userpage content into a .css subpage, and then transclude that subpage onto the main userpage. Should we suggest that .css/.js user pages should not be used for other purposes than stylesheets and scripts respectively?
 * ... file usage, page links, and possibly other maintenance issues such as invalid HTML. I suggest somehow adding all this there.
 * Suggest rephrasing as "marked as editable by other users". I see no reason any particular sentence should be mentioned (which is what the draft currently does), especially given the notice on the draft itself used different wording.
 * or to a difference, given that discussions may be archived?
 * -- 06:33, 10 June 2018 (UTC)


 * Overall I would be in favor of implementing it if there is enough support. As for specific comments:
 * Fixed
 * Fixed
 * In this case articles makes most sense. Its for things like
 * Reworded to include style sheets. I am mostly neutral on forbidding people from using .css/.js pages for transclusion. Sure, its a pretty hacky solution, but if they feel their content is safer then that is on them. I guess the only concern is it makes maintenance harder as only an administrator or the user can change anything.
 * Fixed
 * Fixed
 * The original discussion was, though most of the discussion side railed based on a different issue at the time.
 * <span class=nowrap>– · 22:51, 10 June 2018 (UTC)


 * "as" looks like a mistake. Also, "minor maintenance" implies some maintenance is not minor, which sounds somewhat weird to me. What kind of maintenance would not be minor?
 * In point 7, I wasn't asking about a link to a previous discussion on the draft, but about the text in your draft:  --  09:24, 11 June 2018 (UTC)


 * For minor maintenance, I was mainly trying to distinguish it from some general wiki maintenance tasks, such as keeping articles up to date or cleaning up grammar, both of which fall under maintenance but I don't think should be freely allowed on user pages. Its not too important to distinguish as I list allowed maintenance, but I think it makes it a bit more clear that some types of maintenance do not apply.
 * The main reason for the link is so people don't revert with good intentions, they can just read the article. I guess a diff is useful for historical purposes though so I added that. <span class=nowrap>– · 14:24, 11 June 2018 (UTC)


 * I see no further issues. implementing the proposal. --  15:20, 11 June 2018 (UTC)


 * Well spelled-out. . –   |  17:50, 11 June 2018 (UTC)

Maintenance template images
Kind of revisiting the discussion made about the new maintenance templates, but in a clearer way and this time specifically about the images. This was first discussed on Discord after the images were added to some of the maintenance templates. Basically, I see 3 options:


 * 1) Don't have any images at all for maintenance templates. Remove the existing ones, and don't add images to any of the others.
 * 2) Use images that are the same as Wikipedia's, or simulate something in real-life. This is kind of what we have now for some of the maintenance templates - e.g., splitting arrows for Split, broom icon for Cleanup, etc.
 * 3) Use images that are Minecraft-related. Some proposals on Discord were grass blocks moving towards each other for Merge simulating pages merging, and a piston getting ready to push a block for Move simulating moving.

Please discuss here, and new ideas are welcome as well.--<span style="background-color:aqua;border: 1px solid"> undefined 13:40, 30 May 2018 (UTC)


 * Ok, but I only want to have a image, and I use Minecraft-related images instead of uploading Wikipedia-related and using on the mainterace templates,
 * I would to have the "cleanup" brush remaining, and a warning icon want I to add on the delete page, but it is protected, I cannot do it, but I suggest some Minecraft-related images on some tags instead of Wikipedia's images. I would continue with some tags, but if no good exist will I place an information icon. <span class=nowrap><span style="background-color:grey">  13:48, 30 May 2018 (UTC)


 * Listing 3 options gives me the impression you'd like to standardize on this idea. I would object to making this a formal standard. I like having the images, but I wouldn't want to discourage anybody from creating a useful template because they don't have one and aren't good at making images. But maybe I'm reading too much into it, and you're just asking for input for a personal project you're considering. In that case, I'd be happy with either Wikipedia's image or a custom Minecraft one, so long as it suggests at a glance the purpose of the template. – ( &middot; ) 14:14, 30 May 2018 (UTC)
 * I think having a consistent goal is more important than a consistent style. If we decide we want Minecraft themed templates, a new template will just need a Minecraft themed image later, not immediately. <span class=nowrap>– · 14:23, 30 May 2018 (UTC)
 * Oh, yes, let me explain better. In my opinion, this is not some very formal and important thing - that is, there may be some maintenance templates that won't have images soon, or possibly never, and nobody should be discouraged from creating templates if they can't find an appropriate image. I was just curious of the general opinion and what people seemed to like the best. But yeah, thanks for bringing this up.--<span style="background-color:aqua;border: 1px solid"> undefined 14:29, 30 May 2018 (UTC)


 * with 3. I personally think if we are going to have any images, they should be Minecraft themed to match the wiki skin. I would rather not just copy the Wikipedia icons. <span class=nowrap>– · 14:23, 30 May 2018 (UTC)


 * 3. I don't believe it's necessary to demand an image for every message box out there, or even to formally declare a guideline. This is just for deciding which style we'd like to be consistent with, for those that do get/have an image. And personally I'd prefer minecraft-related ones because it's more personalizing for this wiki and fits better with the skin. – [   ] 14:41, 30 May 2018 (UTC)


 * THIS IS AN EMERGENCY SUSPENSION OF A RUNNING WIKI-BREAK.
 * Given the community seems to converge on option 3, I request that, if this turns out to be the case, administrator consensus overrule this decision per arguments provided below.
 * Beyond potential legal issues I am not qualified to and therefore shall not comment about, Option 3 introduces a precedent in which additional usage of Minecraft assets is introduced on the wiki when non-Minecraft, freely licensed materials exist, are available and carry the same meaning no less clearly while being at least as legible and possibly more technically favorable.
 * I insist on vetoing option 3, and furthermore, making usage of Minecraft assets banned (as in, an enforceable rule) whenever it is at all possible to use any other, freely licensed materials.
 * After all, there's a reason you don't just write the entire wiki in the Minecraft font. -- 15:53, 30 May 2018 (UTC)
 * Ah-oh, surely we should not use direct minecraft graphics, even with options 3. Fully agreed on copyright issues, although I don't fully understand everything you just said. But when I'd say "minecraft-related images", I do mean related, as in newly created looking similar to the game, not actually ripping the actual graphics. – [   ] 16:04, 30 May 2018 (UTC)
 * rule 3, minecraft themed images than Wikipedia-themed images, I would rather have Minecraft themed images, but the delete trashbin can be kept on the speedy delete template. <span class=nowrap><span style="background-color:grey">  16:12, 30 May 2018 (UTC)


 * This wiki literally uses Minecraft assets in its logo, I think using additional Minecraft assets is acceptable based on the brand guidelines, so there is absolutely no reason to make a rule against using Minecraft assets on the Minecraft Wiki. Sure, there are non licensed materials available, but there are non Minecraft licensed assets to use for our Logo and the Wiki skin as well. I see absolutely no reason to be inconsistent just because there is a copyright that we are allowed to use. <span class=nowrap>– · 16:30, 30 May 2018 (UTC)


 * Then I propose we just write the entire wiki using the Minecraft font. Any objections? -- 16:34, 30 May 2018 (UTC)


 * I don't see how that is relevant here. This discussion is about whether images should be added to maintenance templates, and if yes, whether Minecraft or Wikipedia images should be used. | 16:42, 30 May 2018 (UTC)


 * Non-Minecraft (Wikipedia) images are conventional, freely licensed, require no maintenance in case Minecraft changes, their meaning is more apparent beyond just that they're used on Wikipedia, they are likely to be more legible and less bandwidth-heavy.
 * Actually, I'm for version 1. No images. The text says it all. The templates are even (or could be) color-coded for convenience. This site is not for people who can't be bothered to read a couple of prominently placed short sentences. -- 16:55, 30 May 2018 (UTC)


 * I can't find anything that says that the wiki is not allowed to use Mojang content if it could be replaced with something else. I understand your points as to why freely licensed images are better, but I still disagree - and I certainly don't think this would be considered an emergency. I also don't see how "I propose we just write the entire wiki using the Minecraft font" is an argument that supports this.--<span style="background-color:aqua;border: 1px solid"> undefined 18:27, 30 May 2018 (UTC)


 * ...I withdraw myself from this discussion. -- 18:35, 30 May 2018 (UTC)

Minecraft Creators Summit 2018
Here is a list of everything i can find tweeted about what was discussed at the summit, feel free to edit this list as information becomes available.


 * Update aquatic was meant to pre-release May 30, 2018.
 * Three updates are currently planned out for minecraft, more information will be unveiled at Minecon Earth 2018.
 * At least one update is suppose to overhaul combat mechanics, another is meant change gameplay.
 * Graphics settings will be changed to add "Super Fancy" above the already existing "Fancy" setting.
 * The official modding API is still planned and being developed, it will supposedly be coming to bedrock edition before java..

Also thanks to JSBM for translating some of the tweets. 00:26, 31 May 2018 (UTC)


 * All information about the Minecraft Creator Summit 2018 can be seen in twitter. Recompiled information.

--<span style="font-family:minecraft"> 11:43, 31 May 2018 (UTC)
 * The summit is in Stockholm, Sweden. On May 30, 2018.
 * There will be a new grafics setting in Minecraft. There will be a "fancy" and "super fancy" setting.
 * The combat system will get an overhaul. The combat system overhaul will not be part of Minecraft 1.14. Mojang wants to take time and really get a lot of feedback.
 * Minecraft Update Aquatic was supposed to come out on May 30, 2018. It is pushed back to make sure all crucial bugs are fixed.
 * After Update Aquatic Mojang has already 3 more updates fully planned out to release. More info about that at Mine on Earth later this year.
 * Making mods available on Bedrock edition is one of the highest priorities the bedrock team has at the moment. It is a difficult process though, because of the huge amount of devices and systems. It will not come in the near future but it will happen.
 * Java modding will always be a construct of the community and continue to exist.
 * Mojang recognizes the awesome stuff the modding community has created and is actively making an effort to make modders lives easier going forward. They are working to lessen the pain that each update to the game brings.
 * Hope that there won’t be any more major fundamental changes to the game that will impact modders like 1.8 did and 1.13 probably will. Modders should have an easier time going forward.
 * Mojang recognize how awesome forge is and kind of want to let it be what it is. There won't be an official modding api in java.