Minecraft Wiki talk:Community portal/Archive 26

Add "Did you know..." section
In this wiki there are many things that not every player knows, so adding a "Did you know..." section will:
 * 1) Provide readers with more facts about the game.
 * 2) Make the wiki more interesting.

Of course, the tone shouldn't be playful, just be like revealing a secret or something. I'm terrified of the playful voice on Discord already...

More information: This section is on the main page and will have something random to tell from the articles.

( | ) 12:10, 7 November 2018 (UTC)

Update: is my suggestion about the placement of the new section. ( | ) 03:16, 9 November 2018 (UTC)


 * We already have that section, it's called Trivia, and the wiki pages already tell all there is to know. –  12:18, 7 November 2018 (UTC)
 * I know, I know. I meant this section is on the main page. Sorry for not being clear... ( | ) 12:32, 7 November 2018 (UTC)
 * Oh. Well, that's a great idea!  –  12:40, 7 November 2018 (UTC)


 * Do you mean some (automated) semi-randomized message from a set of predefined messages, or more like a single message news feed that we manually populate? I'd rather like the former, would be a nice flair to the main page that isn't too much of a burden to maintain. – [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 12:57, 7 November 2018 (UTC)
 * There can be a queue that is fed several facts at a time and then the contents will be revealed one by one. ( | ) 13:03, 7 November 2018 (UTC)


 * I have implemented . Preview:
 * {| class="wikitable"


 * Did you know...
 * Did you know...


 * }


 * I would love if you have some facts to feed in.
 * ( | ) 13:20, 8 November 2018 (UTC)
 * Sounds good, and makes the main page more interesting. 05:32, 9 November 2018 (UTC)

Proposed to. ( | ) at 3h57:42 | 11/11/2018 (UTC)

Before adding this...
I wholly support this idea, but after seeing that it's been added to the editcopy and was syncing the editcopy to the main page, I noticed 2 major issues that probably should be addressed before adding it the main page. The first is that if we don't make any amendments, anyone will be able to edit the main page. Yes, indeed; all it takes is for some random IP to blank the DidYouKnow template and replace it with "poop" and the main page will have been vandalized. A solution to that would be to directors-only protect DidYouKnow and have an editcopy for it instead. Another problem is the fact that anyone can add anything to a trivia section of a page, even if it's false, and it may not get reverted before a curious user adds it to the DidYouKnow template. Therefore, there should likely be a requirement that all DYK hooks must be tested in the game if they involve in-game material before they're added to the template. However, I'm not sure if we should restrict this ability to certain users so that not just anyone can claim that a random fact is true. I also think that if it's a hook that requires a citation (e.g. a planned update), the article should have an official source supporting the claim in the hook.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 14:26, 23 November 2018 (UTC)


 * Protecting the template is the easiest solution, since the actual content is at . Of course, that page then needs to be at least semi-protected, maybe directors-only. -- undefined 17:15, 23 November 2018 (UTC)


 * Well, for that matter, and  should likely be directors-protected as well. These will still appear on the main page, regardless of whether they're a direct transclusion or not, so I really don't think we should be allowing any registered user to vandalize them. Perhaps we could have something like  or ?--  Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 17:19, 23 November 2018 (UTC)


 * >I really don't think we should be allowing any registered user to vandalize them
 * So we should only allow directors to vandalize them? 🙃🙃🙃 -- 17:22, 23 November 2018 (UTC)


 * If we have a director go to the, I think we'll be in a lot bigger trouble than this. :-)-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 17:24, 23 November 2018 (UTC)


 * Bump. Anyone want to comment on this?-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 14:18, 30 November 2018 (UTC)


 * I have no strong feelings on the proposal. As far as transcluding unprotected pages is concerned, though, I just added cascading protection to the main page, which will protect against that (though we shouldn't rely on it; pages should still be directly protected). 「」undefined 14:29, 30 November 2018 (UTC)


 * I don't think we should highly-protect the facts, because that means additions must wait in a queue and I'm worried that sometimes admin will even forget to pull the editcopy. Even without protection, the facts module hasn't been added facts and it will only survive to 4 | 5/12/2018 if no one cares about it. At most, the facts module should be extended-confirmed protected, so we can filter out potential vandals while still open it for dedicated contributors. ( | ) at 12h21:26 | 1/12/2018 (UTC)


 * There is no extended confirmed protection on Minecraft Wiki. -- 12:22, 1 December 2018 (UTC)


 * Correct. We shouldn't let anyone edit the main page if they can't edit the main page itself (which now it's impossible to do so anyways due to the cascading protection, which to clarify is a good thing). A better idea might be to get a ton of hook ideas before we even make this life so that the editcopy won't have to be edited to often.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 13:47, 1 December 2018 (UTC)


 * Unfortunately, an entry for November 6 in the News section uses the w template, a shortcut to the wikipedia template, so now that (in my opinion, totally unnecessary) template and shortcut are fully protected. If we're going to use the cascade option, shouldn't we ban the use of common unprotected templates on it? – ( &middot; ) 14:28, 1 December 2018 (UTC)


 * So we will have to parse manually? ( | ) at 14h37:16 | 1/12/2018 (UTC)


 * Hmm that is a concern. This means that if we add anything such as ctrl or code to the main page, the template will be only editable by directors. The thing is, that may be something we want. Should we really allow anybody to vandalize the main page using one of its templates? It is true that most vandals are probably knowledgeable enough with wikis to know they can do it; still, we shouldn't take risks, imo, so I support the cascading protection. Wonder if we could have a separate template that duplicates an existing template but is what we use on the main page so that the other duplicate template can still be editable by anyone? We've already done that for FrontPageSprite. For this particular case, we probably could just replace the w template with the bare coding, as it's a very simple template.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 14:47, 1 December 2018 (UTC)


 * Before I commented above, I did search the main page for any other templates that would be affected, and there weren't any. All other template calls on the page were already to protected templates. So I'm not sure it's a big problem. However, any director merging editcopy changes would need to look out for them, as would directors of other language wikis who frequently update the main page directly. (Incidentally, I feel like that's an abuse of their power in many cases. They aren't EN wiki administrators, and should only edit the EN wiki as registered users. But that's another topic.) – ( &middot; ) 15:06, 1 December 2018 (UTC)


 * DidYouKnow Lua error... -- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 15:36, 16 December 2018 (UTC)


 * I edited the module to have it display randomly chosen facts. -- 16:06, 16 December 2018 (UTC)
 * Also fixed a random formatting issue with the table, got rid of all template calls in the facts, and added a list of all facts to the documentation page. -- 16:28, 16 December 2018 (UTC)


 * Is it safe to add this template/module to the Main Page? It's been on the editcopy for a few months, and doesn't seem to have any formatting issues (though I haven't looked at it that closely). – undefined  23:35, 10 April 2019 (UTC)
 * I've synced the main page editcopy completely since it's been sitting there for half a year with no opposition. –  Nixinova sig1.png Nixinova sig2.png 07:33, 8 May 2019 (UTC)

Sonicwave32 for admin?
We have needed more admins on MCW for a while now, and one of the few candidates I've seen that I really thought would make a really great admin is. Sonicwave joined the MCW in 2014, long before I did, and has since improved the MCW in a huge variety of ways, whether it's making basic copy-edits, adding sound files, or correcting/adding information. However, Sonicwave's primary area of focus is vandalism fighting. Many great qualities I've noticed about Sonicwave32 is that he always leaves clear edit summaries when making edits, is absolutely wonderful at communication, and never newbies.

So why should Sonicwave32 to become an admin? Well, as I mentioned, he's a wonderful vandalism fighter. In the event of a persistent vandal, he would be able to block them himself rather than wait for another admin to get to them. He knows exactly what is vandalism and what is not, as well as to give users friendly notices when they are making disruptive edits but acting in, so I'm confident that he can be trusted with the block button. In addition, Sonicwave32 is experienced and accurate with tagging pages for deletion, and has always been a backlogged area. From what I have observed, Sonicwave has great judgement, is experienced, and is "clueful." I believe that Sonicwave would make a great admin, and thus him, and I hope that the rest of the community feels the same way.

Sonicwave, if you would like to add something, please do so, or if I missed something, please let me know.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 21:23, 20 November 2018 (UTC)


 * Thanks for taking the time to write this out, and I accept this nomination. – undefined  02:38, 21 November 2018 (UTC)


 * While I admit I'm not really a regular user on this wiki, I would like to point a few things that I feel are important.
 * I'm not quite sure Sonicwave is active enough recently to solve by himself the issue about the lack of admins... While I don't disagree that he may be a good candidate for the role, this wiki really need a more present admin team. Thus, it would probably be a good idea to look at all the possible candidates — and I have to disagree with you, there is a bunch of editors here who would make some excellent admins! So, if the community want more than one additional admin, well, Sonicwave would definitively be a good candidate and I of course support him, but others should also be considered!


 * Regarding that, I would like to point out that seems another really solid candidate to become admin on this wiki, and I really think the community should also discuss to promote him as well. With his impressive knowledge of the game, his important contributions and his general motivation, he is definitively someone to think about for the role. I know some could be concerned about a bit of edit warring, and we should absolutely encourage him to improve himself on that aspect — but despite that, he's still someone who would really help the wiki if promoted. Promoting both of them could be a good way to resolve the lack of admins issues.
 * On another subject, the promotion system seems a bit ineffective right now... If the wiki is needing more admins for a while, without anything done to address the issue, perhaps it would be interesting to make a new system for the promotions. A Request for Adminship system is the most common elsewhere, this wiki should perhaps think about it (or something else). But anyway, that's not the point.
 * So this is my contribution to that subject. I hope I will have brought an helpful point of view for this discussion.   04:17, 21 November 2018 (UTC)


 * So you propose we implement sophisticated systems for tasks which, until now, have been served well by simpler equivalents, with no apparent substantial drawbacks? And yet you complain that Minecraft Wiki is bureaucratic? -- 07:18, 21 November 2018 (UTC)


 * I'm suggesting this wiki is reviewing its process, to make sure there is always enough admins to do the tasks on this big wiki. By encouraging people who are interested to become admin to identify themselves instead of this weird habit of choosing them when it's really too late, we could resolve a lot of problems. I'm not suggesting a RfA is the best system, of course, simply one who have been successful elsewhere. And for me, having new bureaucratic system is not in itself an issue; having some that are useless or used abusively is however. In this case, the goal would simply be to set clear rules and process on how promotion should work here, to make the process more fair and open to all. (I suggest that if you want to further talk about this, you should open a new section instead, to give a proper place for the community to answer on this subject.)  15:44, 21 November 2018 (UTC)


 * I don’t object to being nominated. :)  10:20, 21 November 2018 (UTC)


 * of being admin. He is doing great anti-vandalism work and might also be trusted with the "block" button to block vandals. --Wikipedia-logo.png ( • ) 09:58, 21 November 2018 (UTC)


 * I don’t object to accepting both Sonicwave32 and FVbico. I don’t recall any problems with either users, at least when I had been actively observing the English wiki. — ( | ru.Wiki Admin) 14:58, 23 November 2018 (UTC)


 * against Sonicwave getting the admin flag. -- 15:58, 23 November 2018 (UTC)


 * why not? =^^=  01:19, 24 November 2018 (UTC)


 * Per the above discussion, and given it's been several days since the last comment, I've Sonic to admin. 「」undefined 03:59, 28 November 2018 (UTC)

Extra nominations
The original discussion on Discord (which led to this community portal post) included mentions of several other users who have been deemed potential candidates for admins. Of course, we can't really promote them against their will or against consensus, but I think it will be useful to get people's views on this matter.

The users mentioned (beyond Sonicwave32, who is the subject of the main topic) were:
 * (opted out)
 * (promoted by Majr at 05:39, 3 March 2019, see below)
 * (promoted by Madminecrafter12 on 8 May 2019, see below)
 * (opted out)
 * (see below, would be fine with being an admin but has found little time to contribute)
 * (does not use talk pages for personal reasons and sadly seems to have stopped editing as well)

Their opinions on their nominations, as well as the opinions of other users on their nominations, are welcome. -- 15:58, 23 November 2018 (UTC)


 * I'm not quite clear; is this a general thing where we just provide informal input? Is this a reaching-a-consensus thing? Or are we just asking these users if they want to be an admin for now, without any outside input?-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 16:22, 23 November 2018 (UTC)
 * I intended this to be a typical nomination. Just as the one above. With the intent to reach consensus. -- 16:26, 23 November 2018 (UTC)
 * Shouldn't we ask people if they actually want to be an admin before a typical consensus nomination?-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 16:26, 23 November 2018 (UTC)
 * Well, we won't actually promote anyone unless/until we get a "I'm fine with being an admin" from them. -- 16:29, 23 November 2018 (UTC)
 * I suppose that works, but I still don't necessarily think it's fair to present these editors to the community and allow everyone to scrutinize their behavior and find reasons why they may not make a good admin, without even having their consent.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 16:31, 23 November 2018 (UTC)
 * Do you want to insist other users shouldn't comment on a nominee unless/until they confirm the subject is willing to be an admin? -- 16:34, 23 November 2018 (UTC)
 * I have no issue with a subtle comment, like what we did on Discord for Sonicwave, but you specifically said that this is a consensus thing. Some people may not want to be formally nominated and discussed by the community.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 16:38, 23 November 2018 (UTC)
 * I didn't really say we should start seeking consensus right now. And it is actually a somewhat casual comment. But I think a resolution would be desired. -- 16:46, 23 November 2018 (UTC)
 * Oh, so you're thinking just present them here and wait for them to accept or decline the nomination, and then we can start supporting or opposing while providing reasoning of course? That could work. FVbico's the only one who's accepted as of right now.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 16:48, 23 November 2018 (UTC)
 * Yes. -- 16:49, 23 November 2018 (UTC)


 * For me, I don't particularly mind it being brought up in this manner, and don't mind any scrutiny it might invite. So, thank you, but I should be up-front:  I don't find myself having much time for this project and this community, these days.  I haven't opened Discord in many weeks.  I would be unresponsive to things that need to be done here, and would be perennially out of the loop.  If that doesn't disqualify me, well, I would accept the permissions, and do my best, as I'm able, because you all are amazing and great and I've had a great time here. –   |  16:47, 23 November 2018 (UTC)
 * I think you're a great editor, have excellent judgement, and have a nice, mature temperament; those are definitely great qualities for an admin. You don't have that much experience in admin-related areas, however, although you have tagged some pages for deletion months ago. For admin candidates, I generally want to see decemt knowledge of when to block vs. protect, block lengths, etc., but that would mainly be true if blocking/protecting is an area you plan on being involved in. If you were to be an admin, do you have specific areas in mind which you would work in? That will likely help me out a bit when trying to decide my position here. I doubt I'd outright oppose you, but if I do, please don't take it as anything personally.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 16:55, 23 November 2018 (UTC)


 * I personally don't think I have enough time to be a full admin on the wiki; I already do a lot of work on other things (e.g. the bug tracker) and I don't think I have time to take on more responsibilities. (However, my situation might change in the future; I'm not 100% sure). --  01:29, 24 November 2018 (UTC)


 * I'm grateful for the nomination, but in-line with my previous statements (including on discord) I don't want to be an admin. Sorry. I don't want the responsibility, and I'm planning on tuning down my activity. If it were the case that I need to be, I'd be willing to accept, but I don't think this is the case. I only have a limited timespan of focus, and sadly I'm running out already... – [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 10:46, 26 November 2018 (UTC)


 * and since there's no word of you two yet, I'm just going ahead and ask. Do you accept being nominated for admin?   13:59, 1 December 2018 (UTC)


 * I don't think Nicolerenee could be an admin, as she's not going to use talk pages for her private reasons. I think she may be a good admin, not personally voting against, but in this state she can't communicate on the wiki (or even post her opinion here). – [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 14:09, 1 December 2018 (UTC)


 * Yes, I do accept being nominated. I've been editing for over 5 years now and I think I have a good idea of how this wiki works. One thing, though: I edit a lot on mobile, and the mobile view hides the 'undo' and 'revert with edit summary' buttons, and it's annoying to have to switch between mobile and desktop view. Can that be fixed? –  Grid Book and Quill.png Grid Diamond Pickaxe.png 18:10, 1 December 2018 (UTC)


 * I don't think there's a fix for that other than wait for the developers to address the issue, which may not even happen. -- 18:34, 1 December 2018 (UTC)


 * Bumping, this discussion/evaluation has been open for a long time, yet there's only like 4 people who responded at all.  21:52, 28 January 2019 (UTC)
 * Considering the bad reputation the Minecraft Wiki discussions have (for a good reason) I'm not planning on contributing to it. Are there any objections from you regarding the nominations? I admit that activity on the extra nominations is rather low but at the same time there were no opposes and I know many people saw this discussion 10 times already.   14:51, 20 February 2019 (UTC)


 * The lack of participation is the root cause of discussions not going anywhere, so that isn't helping. As for nominations, I figure it's appropriate to fill in a replacement for dinoguy, but I'm not active enough to have a strong enough opinion to pick someone myself. – ᐸ  10:57, 21 February 2019 (UTC)


 * Oh well, in this case I guess we are heading for discussion to die. Note, I'm not blaming anyone, just a bit disappointed that discussion ends this way.  11:59, 21 February 2019 (UTC)


 * So, what do we do now? Nothing? Give admin (looking at the little opposes)? Add a notice to the wiki’s main page?  17:32, 23 February 2019 (UTC)


 * Both FVbico and Nixinova have been promoted to admin now. Consider this discussion completed/closed now; considering how old this is, any new nominations or comments about adminship in general should probably go in a new section. Thanks to everyone who helped bring these discussions forward.-- ( 02:21, 8 May 2019 (UTC)

FVbico for admin
The result of the discussion was Promote.

Vote and voice concerns about FVbico here.


 * (Just for clairity) I already stated I have no objections to being nominated above.  16:14, 23 November 2018 (UTC)


 * The reason I haven't responded yet to FVbico's nomination is because I've had to spend some time thinking about it. It's a tough decision, but I'm going have to go with an, with much regret. (I support now) First of all, let me make this clear; FVbico is an excellent editor, a very hard worker, and most definitely one of the most active users we have here, so I don't like having to oppose him, but I do have some concerns that make me unsure about how he would use the administrative tools. In particular, there have been quite a bit of edit warring issues, most notably as follows: , , and , of which a few times rollback was used without any kind of edit summary (though most of the time undo was used instead or rollback with a summary, which is a good thing); using rollback w/o summary to edit war is really something that should never happen. I also have a few concerns about possibly . Working with newcomers is very difficult and saying one thing wrong can make them never want to edit again; they are even more likely to get scared away if it's an admin who says the wrong thing – although adminship really is no big deal, newcomers don't know this. An example is ; for a newcomer acting in , you shouldn't command them to do something by using multiple exclamation marks. Some other problems with civility (that are not targeted towards newbies) include here and more severely here; it is true that the second one was several months ago, so I am a bit more lenient about that one, i.e. that alone would not be a reason for me to oppose. I am a bit concerned about deletion tagging as well. , , and were tagged for deletion by FVb, despite being common alternate names and very plausible search terms; this makes me a bit unsure about how they'd do with the delete button. I also have some minor concerns of inappropriate rollback use, but I'm not one of these  for adminship requests who opposes for a few tiny little single mistakes, so that alone definitely wouldn't be a reason for me to oppose. :-)
 * I'm sorry I had to oppose, as FVbico is clearly a very helpful editor. However, these concerns are just too much for me to be comfortable giving him my full support for adminship. This is definitely not a "never" thing, just a "not quite yet" thing; if FVb keeps up the good work for several more months, addressing these concerns clearly and without having new concerns pop up, I see no reason why I shouldn't fully support him for adminship. If any of the community wishes to post a reply to my comment, I'd appreciate if you could do so here rather than on, for the sake of transparency and keeping all discussion in one place. But do try to stay civil. :-) Best of wishes, -- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 03:32, 28 November 2018 (UTC)


 * “of which many times rollback was used without leaving a summary”, um what? The histories you linked I provided a summary for all rollbacks/reverts; with maybe 1 or 2 exceptions...
 * On the other points, yes I do have some anger management issues (partially related to past experiences with certain parts of the community) and am trying to correct that, but I don’t always succeed in it. Sometimes things are really frustrating, even here, and that swaps over to anger quickly to me. Which causes my more hostile behavior (the biting and editwarring).  08:25, 28 November 2018 (UTC)


 * There have been quite a few times where rollback was used without leaving a summary (when edit warring it's generally accepted that you always should) but you're correct that most of the time you did leave an edit summary, so I've modified the wording a bit. Thanks!-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 14:15, 28 November 2018 (UTC)


 * I hope I'm not being indiscreet to bring this up., your sudden and angry departure from Mojira a few months ago after what seemed to me to be a highly defensive response to criticism and attempts to calm you, worries me. I was not directly involved in that incident and don't have an opinion on whether you were treated unfairly or whether your leaving was an overreaction, but it saddened many of the other moderators and helpers and was generally disruptive. You and I have never had a conflict, but I can't help but be concerned by that incident. Do you feel you've learned enough from it that you can confidently say your anger wouldn't steer your exercise of administrator authority? And in the event that it does, will you be able to gracefully accept constructive criticism from the other administrators? Those are genuine questions, not wishy-washy expressions of doubt. I feel that your passion can be a great asset, provided you keep it harnessed and use it positively. So I'm asking for your honest self-evaluation: Are you ready to be an administrator now, or would it be better to wait until you've had more opportunity to practice self-control? – ( &middot; ) 15:07, 28 November 2018 (UTC)


 * Leaving mojira was something I thought abaout MANY times before that, and it was (justified) distrust towards others that drove me away, not the critisism. I won't work with people who go talk crap behind my back (those who did, and read this will know that I'm referring to them), such as calling me asshole, or even putting other people against me. Additionally, aside from the distrust, I was being portrayed as villan (regarding MC-123456) because "of a joke", while I asked over a douzen times to not do that, yet people continued. In general, it was not a spontanious thing, but something brewing up over the last couple of years. I'm fine with critisism (if it's actually constuctive), and I have not actually abused any administrative powers before (aside from the last action I did on mojira, to try and get people to stop portraying me as villan, non-mods couldn't even see what I did).
 * FYI, I have no intent to return to mojira, and have been trying to forget it.  15:54, 28 November 2018 (UTC)


 * Well, in case it wasn't clear already, I firmly believe FVbico should be promoted. He would make a fantastic admin!  01:00, 29 January 2019 (UTC)
 * 2 months since November went by and I haven't seen any new concerns regarding FVBico, looking through his contributions he is on the wiki daily, active both in the community (by doing patroller requests, his and active on MCW Discord) and on the wiki from the content side. His knowledge about game is exceptional and he is a great contributor. As I said in the past, I find Mad's concerns valid but very nitpicky. Those were single exceptions from the rule, ones that I think he improved upon. I do believe he should be given a chance.  have you changed your mind for 2 months or do you need several more? I'd hate to see this discussion die like that, especially when I see someone who actually would fit into an admin.   23:58, 9 February 2019 (UTC)


 * Still oppose from me. On Discord he said that this was a moderator nomination. How dare he not recognize a difference between admin and moderators?!? That means he thinks that he's going to become a moderator. Wth? Mods aren't even on this wiki anymore. Remember, we're moving them to the Ftb wiki. So he's probably going to create a bunch of mod pages and then delete everyone who doesn't create mod pages and block the main page and protect Curse... what was the question again? -- ( 00:23, 10 February 2019 (UTC)


 * Ok serious reply: Thanks for the ping. I definitely feel like FVb's behavior has improved since my oppose, I've been seeing a lot less edit warring and a lot kinder demeanor to other users, particularly new ones. I do not think my concerns were nitpicky, however; they were absolutely stuff that would be concerning were FVb were to be admins. But again, that's in the past now and FVb has taken the feedback well since. Well, anyways, it's late and I'm tired and I want pizza so I'll take a bit more time to think on this, but I'm leaning towards a support right now and I certainly don't think I would oppose anymore. Taking the feedback of others is, imo, one of the most important qualities for adminship, and FVbico has proven to have that. :)-- ( 00:26, 10 February 2019 (UTC)


 * now. Admin actions can always be undone and FVb seems to be good at taking feedback, considering how much he's improved since my oppose. So, support from me and best of luck if you do get admin. I do wish this discussion could come to a resolution some way or other, whether the outcome is made to promote FVb or not. I agree with Frisk that it's sad to see this go absolutely nowhere.-- ( 18:01, 22 February 2019 (UTC)


 * Well doesn't seem like there's much community interest in whether or not more admins are promoted, so the few supports we have so far will have to do for consensus, so closing this as approved. (I support having another admin to replace dinoguy for what it's worth.) – ᐸ  05:39, 3 March 2019 (UTC)

Nixinova for admin
The result of the discussion was Promote.

Vote and voice concerns about Nixinova here.


 * I think this discussion is a bit old but I have no objections to being nominated. –  Grid Book and Quill.png Grid Diamond Pickaxe.png 03:54, 17 December 2018 (UTC)


 * I don't really have any objections to making Nixinova an administrator, from what I saw there’s nothing wrong with any of the actions made.  22:05, 17 December 2018 (UTC)


 * If you were to be an admin, what admin-related areas would you be involved in? E.g., would you patrol recent changes and block users when necessary? Patrol ? Perform fully-protected page edits, such as to high-traffic templates and the main page? This would be helpful for me to know before having an opinion. Thanks!-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 18:42, 18 December 2018 (UTC)
 * I patrol and revert on recent changes currently, so I would block users making blatant vandalism, I think I would probably patrol pending deletion (if there aren't too many pages in it). –  Grid Book and Quill.png Grid Diamond Pickaxe.png 19:04, 18 December 2018 (UTC)


 * (Bump) –  Nixinova sig1.png Nixinova sig2.png 18:04, 22 February 2019 (UTC)


 * I'd support the promotion. -  10:56, 3 March 2019 (UTC)
 * 11:22, 3 March 2019 (UTC)
 * 02:51, 4 March 2019 (UTC)
 * 20:08, 25 April 2019 (UTC)
 * No real objections from me; the only minor thing is that there are a few rollbacks that I would personally prefer to leave an explanation on (e.g. and ). I understand that mobile view doesn't allow you to leave explanations on rollbacks though, and aside from that I have no issues. – undefined  23:35, 10 April 2019 (UTC)
 * The former rollback was because I misread what they added (I went back and fixed on in the next edit) and the latter was because they were adding download links to a fake version. –  Nixinova sig1.png Nixinova sig2.png 06:43, 16 April 2019 (UTC)
 * That rollback issue is now fixed. –  Nixinova sig1.png Nixinova sig2.png 20:21, 25 April 2019 (UTC)


 * Not only is Nixinova very active, but also from what I've seen of him on the Minecraft Wiki Discord server (since I joined recently), he seems to be well involved with this community and to have the right temperament for serving as an administrator.
 * I'd also point out that this discussion seems to have run its course and has reached an obvious and definitive consensus among those members of the community who are active and willing to share their thoughts here, and there has been no substantive opposition. So I'd call for the closing of the discussion and the implementation of the promotion forthwith.  &#8212; &#124; 06:46, 27 April 2019 (UTC)


 * This discussion has gone on for nearly half a year now and I think there's a pretty clear agreement to promote, given that many experienced users have given well-reasoned support and there has been no opposition. I've interacted with quite often and I haven't noticed any major issues that would prevent me from promoting him; however, I would recommend for him to try to leave edit summaries with clear reasoning for almost all admin actions he may perform in the future, as I have noticed that sometimes he would leave inadequate or no explanation for potentially controversial edits . Putting nitpicks and personal opinions aside, like I said there's a solid consensus to make Nixinova an admin; therefore, I have gone ahead and  him the administrator role.-- ( 02:07, 8 May 2019 (UTC)

Page protection locks gadget: New padlocks?
Wikipedia has implemented a set of new padlocks to signal page protection, the reasons behind this implementation are in the RfC in the first link. Should we implement these same padlocks for our gadget? -- 14:47, 21 November 2018 (UTC)


 * , would definitely be easier to tell what type of protection was applied at a glance. – undefined  05:43, 22 November 2018 (UTC)

One thing I didn't think of: we use the black padlock to signal a level of protection which doesn't exist on Wikipedia; if we're going with the new Wikipedia padlock approach, we'll need someone willing and able to edit a vector image for us. -- 07:31, 22 November 2018 (UTC)


 * About the SVGs, I believe I can modify the thing. ( | ) at 14h25:41 | 30/11/2018 (UTC)


 * Here is my proposal for the director protected icon:


 * Director protected proposal.svg


 * ( | ) at 13h44:28 | 1/12/2018 (UTC)
 * I think you should remove the white design elements and make the letter substantially thicker. This icon is going to be used in 25px resolution, where the white design elements aren't visible, and the D is visible just barely; see it for yourself — Director protected proposal.svg. -- 14:06, 1 December 2018 (UTC)


 * Here is version 2 with thicker lines:


 * Director protected proposal 2.svg Director protected proposal 2.svg


 * ( | ) at 14h30:53 | 1/12/2018 (UTC)


 * ...or with just a D:


 * Director protected proposal D only.svg Director protected proposal D only.svg


 * ( | ) at 14h33:30 | 1/12/2018 (UTC)


 * The lines don't actually add any useful information for the readers, and they make the D (which is more or less useful information) less legible, so yes, I support the third version. -- 14:47, 1 December 2018 (UTC)

More opinions
I've been patrolling the deletion category and deleting/untagging what I can, but I would like to have some more opinions on the following pages before making a decision, because I'm really not sure if they should be deleted or not: If possible, I'd appreciate some of y'all helping me come to a decision on some or (preferably) all of these so that we can eventually empty the deletion category. Thanks, -- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 00:31, 24 November 2018 (UTC)
 * (redirect to, may be a useful typo because there is no 1.4.3 but there is ) . Kept and changed to redirect to instead per discussion below
 * and (both tagged for deletion as old and outdated custom servers)
 * ,, , , and
 * and (both tagged for deletion as old and outdated mods)
 * (tagged for deletion because the page is outdated and it already has an official wiki, but it's not a Gamepedia wiki)
 * (tagged for deletion as superfluous disambig)
 * ,, , and (tagged for deletion as unnecessary redirects) ; deleted per below
 * 1.4.3 should be kept as in-game he f3 screen doesn't say "pre" –  Grid Book and Quill.png Grid Diamond Pickaxe.png 01:01, 24 November 2018 (UTC)
 * The launcher also uses too despite being a pre-release.--   10:46, 24 November 2018 (UTC)
 * do you think it would be better to redirect to instead then?--  Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 15:11, 24 November 2018 (UTC)
 * By the way, I think that "" should be renamed and redirected to "1.4.3 (Pre-release)". -- 15:15, 24 November 2018 (UTC)
 * Yeah since in-game that's all it's known as. –  Grid Book and Quill.png Grid Diamond Pickaxe.png 18:15, 24 November 2018 (UTC)
 * Alright, . I've modified the target of the redirect, removed delete from the redirect, and struck through the 1.4.3 bullet point in this post with an explanation. Thanks for helping me out with this!-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 18:38, 24 November 2018 (UTC)


 * I went ahead and deleted the talk page redirects and it seems pretty uncontroversial. Feel free to scream at me if you have any objections. :-)-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 02:35, 27 November 2018 (UTC)


 * Anyone want to comment on this? Bumping this discussion.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 19:25, 5 December 2018 (UTC)


 * I don't really have anything to say, the deletion reasons are valid, and I see no real reason to keep them.  19:30, 5 December 2018 (UTC)

Some suggestion about private issue description rule
To settle about yesterday, I have the following suggestions on the : -- 14:01, 24 November 2018 (UTC)
 * For security issues mentioned on the official change log, use the title from the change log, since it has been disclosed by Mojang.
 * For security issues NOT mentioned on the official change log, use “private security issues (involving...)” instead.


 * I would that. If the issue fix is something Mojang's okay with having on an official change log, then I don't see why it can't be revealed on the wiki. Maybe we should add this to the style guide?--  Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 14:02, 24 November 2018 (UTC)


 * . -- 14:04, 24 November 2018 (UTC)


 * Also, for security issues mentioned on the official change log, use the title from the change log with ref to the change log, influenced by, and . --  14:06, 24 November 2018 (UTC)


 * . - ( 15:57, 24 November 2018 (UTC)


 * . For some issues, I think it's definitely fine, but I'm not sure about whether it's a good idea to include it for all issues.  My general opinion on it is that for issues that only affect snapshots, it's fine to include it; for ones that affect releases more care must be taken (but it also varies on the issue; duplication issues I think are generally safer to make public, but that's only my stance).  I should also note: I'm generally in favor of making private issues public eventually, though that hasn't really happened on the tracker.  I should probably look into that again; the super old issues for 1.8 and the like probably can be made public at some point...  (n.b. I am a bug tracker moderator, so I have access to the details of these reports, which does mean I have additional context others don't have) --  18:09, 24 November 2018 (UTC)


 * Like Pokechu, I'm a moderator on the bug tracker. I want to mention a couple of things for consideration.
 * 1) There are 2 reasons we make bug reports private: Either they contain personal information, or they describe an exploit. I believe the intent of the rule is to avoid giving publicity to exploits, but editors generally wouldn't be able to tell which reason applies (and both could apply simultaneously). If necessary, editors could ask one of us for a publishable description of a bug.
 * 2) There are some reports that we make public despite describing an exploit. This is generally when they are already published on YouTube or Reddit and we therefore anticipate them being reported many times. We encourage users of the bug tracker to search before submitting a report, but they can't find a private report that way, so we make it public to try and avoid a lot of duplicate reports. Thus, "public" ≠ "not an exploit".
 * I don't think it's a good idea to publish exploits on the wiki at all, regardless whether they're public or private. They can absolutely ruin the game sometimes, especially on multiplayer servers. (Examples include disruption of a server's economy, invincibility during PVP, and surrounding a player with illegally obtained bedrock to extort, coerce, or disable them.) So maybe the rule should prohibit mentioning a bug's exploitative aspect instead. For instance, if the had said merely "Shulker boxes can't be dyed" and left out the duplication effect, it needn't have been reverted.
 * For these reasons, I suggest that the rule should focus on not promoting exploits, instead of whether a bug report is public or private. – ( &middot; ) 13:47, 27 November 2018 (UTC)
 * I think that Java Edition “fixes” section should be consistent with Bedrock Edition “fixes” section to solve this problem.  05:14, 29 November 2018 (UTC)

Sound file licensing
Do all non-music sound files need to be licensed as License C418, or is License Mojang sufficient for some of them? If it's the latter, which cases are these? -- 21:18, 1 December 2018 (UTC)


 * Many sounds are creative commons licensed (the exact one varies though); see the sound attribution page. --  21:37, 1 December 2018 (UTC)


 * Are the CC BY-licensed sounds specified as such on the wiki?
 * Are the non-CC BY-licensed sounds all C418-licensed? -- 21:56, 1 December 2018 (UTC)

When do we describe bugs in articles? Pt. II
I'd like to reopen the discussion at since it doesn't really reach a consensus. I just came from a discussion about some unexpected parrot behaviour that I thought the wiki would have informed me about. I couldn't add it because the page was locked, and a user dismissed my request because it seemed too much like a bug. I've been describing things that could be suspected as bugs whenever I encountered them, treating the wiki as "this is how the game is", but maybe I misunderstood the goal of the wiki? 00:04, 3 December 2018 (UTC)


 * When we characterize ourselves as describing "how the game is", we don't mean that to contrast with "how the game isn't, but rather with "how the game is now" versus how it used to be or how it might be at some point in the future. It's intended to remind us to remove information that's obsolete, or at least to clearly mark it as such, and also to avoid treating mere rumors about upcoming changes as real information.
 * With respect to bugs, we only acknowledge a bug if it has been around for a long time and Mojang isn't actively planning to fix it. The reason is that we don't want to mislead people into depending on behavior that's likely to change in an upcoming release, and also because it's highly possible that nobody would remember to remove the bug description after the bug is fixed, at which point it would become misinformation.
 * I also took a look at your edit history to familiarize myself with the behavior you're talking about and saw what I assume is you say you just came from. To summarize, the other editor described the behavior as (paraphrasing) "parrots wouldn't follow or teleport to me while I was in an Ice Spikes biome". Then they jumped to the conclusion that "parrots […] become lethargic in a cold biome". You, in turn, appeared to accept that reasoning. The problem is that this conclusion is a generalization that doesn't automatically follow from the behavior. The assumption could be wrong: Maybe it doesn't happen in all cold biomes. Or the conclusion could be incomplete: Maybe it happens in some warm biomes, too. It's also possible that the true explanation is based on something completely different: Maybe a bug is making you untrackable by any mob when you're standing on ice. There's no way you can generalize from a specific event to a behavior description without making some assumptions about Mojang's intentions, and no way you can validate those assumptions unless you have access to the code base. Consequently, any generalizations of this type from non-Mojang staff have to be treated skeptically unless there's a very convincing argument. –  ( &middot; ) 06:07, 3 December 2018 (UTC)

Request for Comment: Get rid of change log collections on Development Version subpages
At the moment, a query grabs all articles for a particular release version's development versions and transcludes most of these articles on a single page. There was a time when a single page was enough for complete change logs for all development versions, this was obviously not acceptable as a permanent solution. Apparently, keeping such complete change log collections on a per-version basis was deemed enough of a compromise to avoid scrapping change log collections entirely in favor of a single, minimalistic list. In this request for comment, apparent issues with the current approach are described, and a resolution is proposed.

It is questionable that such collection pages are substantially useful for readers. Releases contain substantial numbers of snapshots, with many changes in each snapshot, and this often results in incredibly large pages where needed information is hard to find. The feature that would mitigate (not significantly) this navigational difficulty is the built-in browser search (Ctrl+F in desktop Mozilla Firefox)... however, it's very possible many readers aren't aware of this feature. This paragraph does not even consider mobile devices, where the pages and/or the search feature may be even less usable. As an extra note, bandwidth and client performance may be a concern assuming non-text content gets transcluded from many individual version articles at once.

As a result of this approach, editors who contribute to snapshot articles are expected to properly insert  tags into snapshot articles to avoid breaking the collection pages. Beyond that this is not something obvious to beginning editors, it is not even documented where exactly should these tags be placed, and in a recent incident, a user attempted to have the tags contain the video section, resulting in a mass revert.

Additionally, collection pages require a system of complicated templates and categories which has to be maintained by more technically capable editors. The complexity of this system could be substantially reduced by removing collection pages. (An even less substantial issue is that some automatically generated lists will list the development versions collections as well as the version articles themselves, resulting in somewhat inaccurate category/list population counts.)

Proposal:
 * 1) Decide whether to keep change log collections or to get rid of them.
 * 2) If it is decided to keep the collections, the placement of   tags in individual version articles will need to be documented.
 * 3) If it is decided to delete the collections, details of the deletion procedures will need to be discussed.
 * 4) Decide whether to replace minimalistic version lists on the per-edition development versions pages with more informative versions.

-- 18:54, 3 December 2018 (UTC)


 * There's not really much point in them. Want a list of all features? go to the 1.x page. Want to look through the specific snapshots? Go to YYwWWn and click the link. –  Grid Book and Quill.png Grid Diamond Pickaxe.png 19:01, 3 December 2018 (UTC)


 * I use these pages. The main reason why is to find (using Ctrl+F) what snapshot a behavior was added in (usually so I can test bugs related to that feature, but others would have a different reason to do it).  These pages are the most convenient way to do this, since that information isn't in the full article and the specific things I'm looking for generally aren't in the history section of an article (e.g. options changes).  That would probably be solved by a more complete history section in those articles, but that's my current use case. --  19:08, 3 December 2018 (UTC)


 * I like the collection pages. They are specially useful, if you search for a change but don't know in which snapshot it changed (e.g. research for an history entry). Without the collection you would need to click through all 40+ snapshot pages.  HorseHead.png GRASP logo.png   19:12, 3 December 2018 (UTC)


 * There's not a single link to one of these collection pages in this topic, nor is one of them even named. I'm left wondering if I've ever even seen one of these; I don't remember ever seeing a giant version-related page full of transcludes. (That might be because I don't often concern myself with Java history stuff.) Are these pages actually linked on the wiki, or are they only available by typing a secret URL? – ( &middot; ) 20:11, 3 December 2018 (UTC)
 * . Clicking "view all" in the infobox on any 1.x page. –  Grid Book and Quill.png Grid Diamond Pickaxe.png 20:17, 3 December 2018 (UTC)

Thoughts on adding the "Java Edition" prefix to version pages
Now that this has calmed down a bit, what are people's thoughts on prefixing version pages with Java Edition? I, personally, am on this. –   21:04, 20 December 2018 (UTC)
 * Pros: Doesn't look like we have any bias, less confusion (in the long run; especially since bedrock version numbers are catching up to Java and we're gonna get to the point where it's "upcoming 1.17 and Bedrock Edition 1.17").
 * Cons: Have to move a whole lot of pages.


 * moving pages.  on changing upcoming template behavior to include "java" prefix which would reduce confusion in that case. --  21:13, 20 December 2018 (UTC)

Simulation distance
A while back the Options page contained the information about the technical details about the render distance sliders (increment info, # of chunks, such as: 2x increments starting at 6 chunks max 16-24 chunks, 4x increment starting at 8 chunks max 28-48 chunks etc). It's been removed and I copied that data over to a different page.

It's come to my knowledge that the simulation distance slider also varies with device just like render distance.

1 device has the simulation distance slider in 2 step increments starting at 4 chunks and ending at 8 chunks, another device has 2 step increments starting at 4 chunks and ending at 12.

Does anyone have the specific technical info about the sliders for the Simulation distance? Specifically the increments, starting number and max range of chunks.

Something like this:

Simulation distance chunks

and so on so forth

01:51, 25 December 2018 (UTC)

Split PlayStation 4 information
Now that PS4 is the only console being updated, I've changed the exclusive, history and only templates to support the "ps4" param. Since ps4 is going to be the only thing in from now on, should the 1.83 and 1.84 (and future) updates be their own pages? Before we didn't split LCE because we didn't know what the pages should be called; now that's no longer than case as ps4 is the only edition being updated. –   22:02, 27 December 2018 (UTC)


 * See . –  Grid Book and Quill.png Grid Diamond Pickaxe.png 22:10, 27 December 2018 (UTC)


 * I also think that LCE updates articles can be spilt into individual articles, In categories of every editions, such as Xbox 360 Edition TUxx (instead of Legacy Console Edition TUxx / CUxx …) -- 06:22, 28 December 2018 (UTC)


 * , but only for the PS4 Edition instead of all editions. - ( 11:19, 28 December 2018 (UTC)

From my perspective, I think that should be categorized and split to solely PS4. Another solution is to create a new page specialized for PlayStation 4 Edition.--  16:37, 31 December 2018 (UTC)
 * . But what should we do for the, should we keep it in its current form? 2. Should we name the updates "PS4 1.x" or "Patch 1.x"?


 * . There's soo much confusion between the many versions and editions. Some of my edits been shut down by users that are concerned with PC versions of Minecraft. Personally, I feel that the PC Minecraft Community is ruthless!  12:35, 14 January 2019 (UTC)


 * - I'd split every single console's information, even if that would result in a lot of duplication. -  11:22, 15 February 2019 (UTC)

Features with different names for different editions
Some features have different names depending on the edition. For example, the block called “nether brick block” in Bedrock Edition is called “nether bricks” in Legacy Console Edition and “nether brick” in Java Edition. Currently, we use the name in Java Edition for the title of the page (e.g., the page about nether brick blocks is called “Nether Bricks”).

A few years ago, the Java Edition was simply called ‘’Minecraft’’, so it was reasonable to choose the Java Edition as the “default” Edition. However, since the Better Together Update, the Bedrock Edition was the edition that is simply called ‘’Minecraft’’. It is therefore reasonable to consider the Bedrock Edition the “default” edition.

For features with different names for different editions, we should move the pages so that the page titles would correspond to the Bedrock Edition name rather than the Java Edition name (e.g., would be moved to “Nether Brick Block”. Paper.png 15:51, 31 December 2018 (UTC)


 * . We should also rename other pages like ' to ' to make it persistent with other pages. once moved it, but it was quickly reverted by  and the page was protected. [ According to him], the name "Top Snow" is not an official name and should be discussed. --   16:26, 31 December 2018 (UTC)


 * That was what I could tell at the time. I don't have access to any Bedrock Edition release of the game, so I can't check names for myself. I will note, however, that to my knowledge, since that happened, no one else has come forward even claiming without proof that the BE name for Snow is Top Snow (though I'd be happy to be proven wrong, on either count here).
 * For the proposal itself, I support documenting alternate official names as a matter of course, but am ambivalent towards which edition to consider the "main" edition or whether to rename pages to reflect that. 「」undefined 16:35, 31 December 2018 (UTC)


 * . Without getting into ideological concerns, the 1.13 brought about, which modernized and organized names.  To my understanding, bedrock has not yet had that.  Thus, the names from 1.13 should be considered more final. --  19:02, 31 December 2018 (UTC)


 * per Pokechu22. - ( 19:03, 31 December 2018 (UTC)


 * prr Pokechu22; additionally, we have confirmation from HelenAngel that bedrock will fillow the 1.13 names sooner or later (ie smooth sandstone is already renamed to cut sandstone as well.  19:26, 31 December 2018 (UTC)


 * . I propose having it so that the name that is in more editions is the name of the page so we don't have any version bias. For example, would stay there since it's used in JE and LCE but not BE but  would be moved to  even before 1.14 is released. –  Grid Book and Quill.png Grid Diamond Pickaxe.png 19:42, 31 December 2018 (UTC)
 * No two editions have the same term for nether brick blocks, so your idea would not work universally. Paper.png 19:45, 31 December 2018 (UTC)
 * In that case the edition that has had the feature added first may have the priority, so as a result Nether Bricks would retain their name. — ( | ru.Wiki Admin) 20:03, 31 December 2018 (UTC)

Redirect PlayStation 4 Edition 1.82 etc. to
Just a suggestion. What do you think? Note that these redirects will take the form " ". -- 11:03, 6 January 2019 (UTC)

Issues pages: keep them or delete them?
Argumentation taken from the Discord server: [19:57] on topic: why do we still have all the Issues/ pages around? they’re all either fixed, invalid, WAI, or reported to mojira These pages annoy me too, given they're a lot of red links and template transclusions and are nothing but barely used archives...

Should we delete the issues pages now? Do we keep them available for readers for some time? For 1 year? 10 years? Until October 23, 2077? Until the heat death of the universe? -- 15:24, 6 January 2019 (UTC)


 * They're a historical record, though I don't know if anyone particularly cares about them, nor how much value they actually have as a record. I would be sad to see them go, but wouldn't really oppose deletion. Though if it would be sufficient to address some of the complaints (e.g. by cleaning up the redlinks, or maybe moving the whole thing into the project namespace), I would prefer they be kept. 「」undefined 15:29, 6 January 2019 (UTC)
 * I think it has interesting historical value but they don't really need to be in the mainspace so maybe move into MCW:? –  Nixinova sig image 1.png Nixinova sig image 2.png 18:40, 6 January 2019 (UTC)


 * I would support moving them into project namespace and agree that they may be useful/interesting for historical context (e.g. old talk pages), though I don't have any strong arguments against deletion either. – undefined  20:21, 6 January 2019 (UTC)


 * I think they should be kept around for historical purposes, since sometimes they're useful for context on what changed (I've dug into them once or twice when looking at changes in old versions). It's strange that they're incomplete around beta -- why only beta 1.5 and beta 1.8.1, and not the various 1.7 builds for instance?  Did those once exist and get deleted?  Did they never exist?  I don't know :/.  I do support moving them to the MCW namespace, though, and probably treating them the same way as old talk pages.  --  20:29, 6 January 2019 (UTC)


 * Without checking where in the timeline of the issues pages those versions fell, towards the end (I think after the bugtracker was started, though I've never been very clear on when exactly that was) some issues pages were created but never actually used; some time after we stopped allowing people to use the issues pages for reporting new issues, I went through and deleted the pages that had never had any actual bug reports. So the gap you noted may be that. 「」undefined 20:57, 6 January 2019 (UTC)


 * Should I go ahead and move them into the MCW namespace? I've been converting all the links to static so they dont show up in special pages. –  Nixinova sig1.png Nixinova sig2.png 21:18, 10 May 2019 (UTC)


 * I would support moving them into the MCW namespace as well and could help you out with doing so. I do think we should leave a redirect from the page (but none of its subpages) just so it can be found easier considering it's been like this for so many years - one of those rare cases where a mainspace to project namespace redirect might actually be useful. -- ( 21:23, 10 May 2019 (UTC)


 * Never mind, it looks like the redirect was modified to point to  instead. Well, either way I've added a hatnote on the Bug tracker page linking to, and would suggest to continue to have such a hatnote even if the issues pages are moved into the MCW namespace.-- ( 21:24, 10 May 2019 (UTC)
 * Moved to and . –  Nixinova sig1.png Nixinova sig2.png 23:00, 10 May 2019 (UTC)

List of blocks and items
On the list of s and s, I want to get rid of most or all of the subsections and replace them with one big alphabetical list. I think some of the subsections are unnecessary and complicated, and I never know what to do with things that fit in multiple subsections. Some other subsections, like education edition only or removed blocks/items, might be worth keeping. 04:12, 11 January 2019 (UTC)

Fixed-width notice boxes
Other Gamepedia wikis use amboxes which have a fixed width. I think what we have currently is quite annoying, especially if you have many boxes on top of each other. This is a common sight on new pages and is quite an eyesore:

–   03:34, 17 January 2019 (UTC)
 * I wrote for the Russian wiki to address the issues I see with message boxes. You can see two these templates on  (look for the two orange bars in the top of the page). Would that be a better option? However, if we go that way, we'd need something like small icons for different editions to replace the exclusive template images... and I sense the edition icons could be useful in so many ways... --  04:12, 17 January 2019 (UTC)


 * To be honest, I think the fixed-width ones do stand out more, which is what they're there for. What exactly is annoying about them? Is it the irregularity, the aesthetics? – [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 10:09, 17 January 2019 (UTC)


 * They take too much space and use it suboptimally – that's my biggest concern. And centering of text makes them hard to read. The boxes need to stand out indeed, but that doesn't mean they need to stand out as much as possible (you'd agree red boldcaps on green background is not going to happen, right?). -- 10:14, 17 January 2019 (UTC)
 * I'm thinking more of Amboxes which don't take up 100% of the width but still look good. –  Nixinova sig image 1.png Nixinova sig image 2.png 18:55, 17 January 2019 (UTC)
 * Even that would be better than what we have now. -- 20:43, 17 January 2019 (UTC)

Reduce the number of gigantic tables on the wiki?


All of these are examples of huge tables. Such tables are problematic for mobile users or users with lower-resolution displays, and the tables tend to use space suboptimally in all cases. It should be possible to replace most if not all such tables with design elements not having these issues. Are there any suggestions regarding such changes? -- 12:54, 17 January 2019 (UTC)


 * I personally would support a "tabbed" design for the History template; this would not only conserve space, but one thing that annoys me greatly is that the version column appears to always stick with the same width across all different editions, leading to unnecessarily wide stretched version columns which crowd out text next to them (this is especially the case for console edition features, as well as features implemented in Java Edition 1.0.0). I have a few other ideas pertaining to the History template; I can elaborate further if desired. -  13:29, 17 January 2019 (UTC)
 * I personally like the History template as it is but the others definitely need reconsidering. –  Nixinova sig image 1.png Nixinova sig image 2.png 18:54, 17 January 2019 (UTC)


 * , which only lists Java Edition versions. I'd keep each edition in a separate table if possible, and use the tabbed system I proposed above. -  11:30, 20 January 2019 (UTC)


 * ...but before we implement a tabbed system, I'd prefer it if each edition were split into its own table/template, similarly to how the German wiki currently handles it. -  13:12, 5 February 2019 (UTC)


 * for flattening, for the rest.  The flattening article really doesn't need to be read by hand and really isn't applicable if on a mobile device, since it's mostly just data without analysis.  I don't think it's worth investing time in making it easier to read, since the main use for me is with control+F to find a specific entry.  --  16:50, 20 January 2019 (UTC)


 * making large tables easier to navigate. Another large one is n . It had been talked about in the past to make parts collapsible but never really went anywhere. I would suggest making all large tables collapsible. For some of the particularly long ones, they take a while to scroll past. If a user was not interested in the table but instead wanted to read the article, it could save time to collapse it, especially if they needed to go back a forth referencing material. –Preceding unsigned comment was added by ( • ) at 22:01, 20 January 2019 (UTC). Please sign your posts with


 * Mobile view doesn't have collapsibles and is intended exactly for those devices most likely to have problems with large tables. -- 05:13, 21 January 2019 (UTC)


 * That's interesting, it seems like that would be especially helpful on mobile. It does appear mobile can collapse sections, so at least that can help a bit. The tables look really bad in mobile portrait orientation though and collapsing doesn't help there.  03:29, 23 January 2019 (UTC)

McEdu
Hi ! I made a few edits on the wiki, mainly about McEdu : I'm quite new around here, so feel free to discuss them and perhaps made more edits if what I did wasn't accurate according to your own self. PS : Sorry for the aweful ID. -- 16:23, 17 January 2019 (UTC)


 * Hi ! From what I can see, your edits look constructive and helpful. However, please don't be offended if someone else reverts them; this happens a lot and it's nothing to take personally, some of my edits are reverted from time to time. If you'd like to change your username, fill out this form and specify that you're requesting a username change and what your requested new username would be. Your username was probably automatically changed to the current because you didn't consent to the account-name retaining for the Gamepedia/Wikia merge thing, so your username was changed to a random string of numbers to comply with the (I can explain that in more detail if you'd like). Thank you for contributing to the wiki and I hope you continue!--  Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 18:44, 17 January 2019 (UTC)
 * Thank you very much. I hope I'm not making any mistake by trying to correct some...  --  13:01, 18 January 2019 (UTC)
 * Yep, that edit was useful. The other two links were also incorrect; I've fixed those too (by checking version_manifest.json and then the relevant JSON file from there, but most people don't know that exists).  Thanks! --  17:13, 18 January 2019 (UTC)

Are fixes summaries quotes?
In the fixes section on snapshot pages, is each individual bug fix a quote? So should grammatical/spelling fixes be marked with square brackets? There's not really a guideline for this. –   22:03, 18 January 2019 (UTC)


 * There is. says the following:


 * The titles from the bug tracker issues may be freely edited to comply with the style guide. While users are encouraged to fix the titles as they find them, fixing the titles is not required; specifically when first adding the issues. Editors may make major changes to the title (such as rewording the whole title), though this is discouraged unless the original title fails to adequately describe the issue.


 * So no, they're not necessarily quotes and grammatical/spelling errors should be fixed, at least based on what the current style guide says.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 22:08, 18 January 2019 (UTC)


 * My thought is, no, using the square brackets is definitely not necessary (however, I am a bug tracker moderator and I have the power to actually edit the issue titles directly, though generally I don't bother with grammatical issues). And of course, adding links to commands and code formatting and such is sometimes helpful, though also probably not necessary most of the time.  The  is mostly me being pedantic, but I still think it's correct (they are titles, not complete sentences). --  18:36, 19 January 2019 (UTC)

Move Bedrock Edition version pages to their ".0" title
The version number both on the Feedback site and in-game display "1.x.0", so that should be the names of each page. –   20:15, 16 January 2019 (UTC) Ping – 04:41, 24 January 2019


 * based on above reasoning. – undefined  03:32, 2 February 2019 (UTC)
 * 1.8.0 has been moved to that title. Should the rest be? 1.9 and 1.10 should definitely be moved. Has the ".0" been included all the way back to 1.1? –  Nixinova sig image 1.png Nixinova sig image 2.png 03:35, 2 February 2019 (UTC)
 * I've moved 1.4–1.7 to their ".0" title. I can't confirm 1.9 and 1.10 as they aren't out yet but will probably follow the pattern. – a, 04:29, 2 February 2019 (UTC)
 * Someone now needs to go through and replace "parent=1.x" (or "snapshotfor=1.x") with "parent=1.x.0" and then move the "Bedrock Edition 1.x builds" categories. –, 04:38, 2 February 2019 (UTC)

Outdated pages belonging to translation projects - what do?
Right now, it seems like there exists a particularly large amount of pages which belong to certain translation projects. While I do not oppose translation projects (despite what it may seem), I've noticed that a sizeable chunk of such pages that still exist have received little to no attention actually regarding either translating the page ( - 22:45, 23 January 2019 (UTC)) or keeping the information on said page up to date. As a result, it seems that a lot of the information provided on the pages can be potentially quite dangerously out of date (up to seven years plus), which obviously is not a good thing for a site striving to provide up-to-date information. I think it might be in our best interests to outright delete some such pages - that way, if someone eventually does come along and wants to translate the page again, they can do so without the risk of spreading information potentially almost a decade out of date.

Personally I think we should delete translations that haven't been updated since January 1, 2016 or earlier - that sets the threshold at just about the late pre-1.9 era. We'd exclude maintenance edits to fix up things like redlinks and images, since those obviously aren't updating the textual information provided in the article. Any other proposals? -  16:53, 23 January 2019 (UTC)


 * , I find the OP's argumentation satisfactory. -- 18:17, 23 January 2019 (UTC)
 * Nuke them all. I find it very annoying having so many of these outdated pages cluttering everything. –  Nixinova sig image 1.png Nixinova sig image 2.png 19:04, 23 January 2019 (UTC)
 * Some months back I brought this up in Discord or Slack, but people at the time argued against it. Needless to say, I'd be quite happy if this proposal passes; there is no point in keeping "translation" pages that are just X-year-old copies of random articles that were never touched after being copied (there's also no point in keeping these pages with some translation work when the content is grossly out of date). In all cases, a prospective translator would have to recopy the current article anyways, and doing that with a redlink is less effort than having to first determine if the content of a preexisting translation subpage is up-to-date. 「」undefined 21:21, 23 January 2019 (UTC)

I've marked several old translation navbox templates for deletion; these have never been updated since the 2016 cutoff, some of them aren't 100% translated, they are quite outdated (one stretching back as far as when 1.3 was still in the snapshot stages) and they are EXTREMELY major offenders on (constituting well over three quarters of the content there). Deleting these should hopefully help clean that page up, since it's currently in a bit of a ridiculous state, and then we can move on to higher priority issues with WantedPages such as. -  13:26, 29 January 2019 (UTC)

There's now several extremely old and outdated translation pages awaiting deletion. -  16:20, 18 February 2019 (UTC)


 * Starting deleting, just doing a few sections a day, so don't add any more until the current set is done. – ᐸ  10:50, 21 February 2019 (UTC)

I'm considering changing the cutoff date to be January 1, 2017, or maybe even January 1, 2018, given the major technical changes the game has faced since then. However, personally I find it to be a much more tempting option to outright nuke every single translation project altogether (except Icelandic translation), given the overall minimal activity across them. Feel free to comment. -  13:28, 25 February 2019 (UTC)

Wiki cleanup
I propose the following changes: Thoughts? –   23:31, 23 January 2019 (UTC)
 * 1) Export subpages of  to  and nuke it.
 * 2) Nuke
 * 3) *“None of them have any claims of notability and are just added willy-nilly. Most of them are stubs and/or orphans and many contain blatant advertising. They require a lot of maintenance even though they haven't been relevant for almost a decade now. Unmaintainable pages which include installing programs is a recipe for disaster when anyone can edit (virus alert). These pages have nothing to do with Mojang nor with modern versions of Minecraft itself.” 04:22, 24 January 2019 (UTC)
 * 4) Delete translation projects older than 4 years (see directly above).
 * 5) * Move the remainders to [MCW:Projects/language translation/page] so maintenance can be way easier and then they don't clutter search, etc. "SuffixIndex" is not a thing so it's really hard to actually find these translation pages. 04:24, 24 January 2019 (UTC)
 * For the first one, we should finally stop talking about it and do it. I the other two points as well. --  22:33, 24 January 2019 (UTC)


 * . However, "blatand advertizing" does not seem applicable on this subject; these are open-source programs and it's just as useful as the various other .  The subpages maybe are less valuable, but a list of some sort is still useful. However it's worth noting that much of the same information is replicated on wiki.vg's Client List and Server List articles (side note: interwiki really needs to be set up for that, I really should bring that up more formally).  Since wiki.vg is also where the protocol documentation is hosted, it may make more sense to keep those lists there.  However I don't think your deleting of significant amounts of information that's been there for quite some time without any consensus is any good. --  23:31, 24 January 2019 (UTC)
 * Unless Mojang had said they use one of the software listed, nuke the outdated items (pre-1.13) on . The wiki shouldn't be a database of third-party software. applies. –  Nixinova sig image 1.png Nixinova sig image 2.png 01:49, 25 January 2019 (UTC)
 * I still disagree. I think it's at least useful to keep this information around, or at least not get rid of historically notable content.  (And it's worth noting that there are some servers that are still developing around classic -- I see edits to the CPE page occasionally on wiki.vg, though I have no idea who those people are).  Cleanup is one thing; eliminating information about the past entirely is another (for the same reason I don't like the removal of the old issues pages).  Now it might make sense to just export and migrate the data elsewhere, but I don't think nuking is appropriate.  --  05:00, 25 January 2019 (UTC)


 * What is holding us off on the first one? I believe we've discussed this several times and there's a clear consensus to move the mods there. Do we need to contact the wiki manager to export the pages or something? I do think we should keep the page itself, for an explanation of what mods are and the fact that they can be found on the ftb. If nothing is holding us off and all we need to do is contact the wiki manager, I can let her know right now.--  Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 14:25, 25 January 2019 (UTC)


 * We need FTB Wiki admins to import the pages we export. Beyond that, probably nothing. -- 14:28, 25 January 2019 (UTC)


 * Hmm I never realized normal admins could actually export or import. I don't know anything about how this works. :-) I do know that is an admin over on FTB.--  Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 14:31, 25 January 2019 (UTC)
 * Indeed, Xbony2 is the one you should contact and coordinate with. He (was) asked about this before in an earlier discussion and was willing to help. What exactly needs to be done here or how, I don't know. As far as I'm aware, there wa no one before who could "lead" the process. – [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 08:44, 26 January 2019 (UTC)


 * All that would be required on our end is an export of these pages (with the full page history), which can be performed by any user, followed by deletion, or at least being tagged for deletion. It would probably be best for Xbony to export the pages himself, to avoid the need for handing the dump files off between people. Any files would also have to be uploaded locally on FTB, if they aren't already, though this doesn't require exporting anything from this wiki, just directly downloading the files. So at this point I suppose we're just waiting on Xbony to comment here. 「」undefined 10:15, 26 January 2019 (UTC)


 * Yeah, but how would he be able to export if he doesn't have admin rights?-- ( 20:20, 31 January 2019 (UTC)
 * You don't even need to be logged in to export pages. -- 20:25, 31 January 2019 (UTC)
 * Hmm, thanks, I didn't know that. So it's just import that requires admin rights.-- ( 20:27, 31 January 2019 (UTC)


 * Why the FTB Wiki specifically? Not all mods are in FTB, and it seems to me like it would make more sense to write about mods on the same wiki as the game itself. I'm not totally on board with migrating everything there -- I think we should bring more of it in here.  14:09, 14 May 2019 (UTC)
 * No. The FTB wiki covers all mods, not just what mods are in FTB. This wiki is specifically for the game itself, FTB wiki for the mods. Our editor base here is not sufficient enough to keep mod pages updated, which is more harmful than not. – [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 14:33, 14 May 2019 (UTC)

IP talk pages
Should IP talk pages older than, say, a year be deleted? They're not of use to anyone as the IP would definitely not be using that same IP anymore. –   00:17, 30 January 2019 (UTC)
 * , but if the content has special significance, we could either keep the page or move the content elsewhere. -- 08:46, 30 January 2019 (UTC)

Create requests for comments page
MCWiki is very good at starting important discussions and never finishing them because this CP has so many topics. should be created where we add important discussions (like the above). –   04:34, 24 January 2019 (UTC)


 * How would that be any better than having the requests for comments section on the community portal page? I suppose it's true that it could be more noticeable, rather than buried underneath other information.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 14:19, 25 January 2019 (UTC)


 * The thought of an unresolved discussion tracker often crosses my mind. I think we should at least fill the RfC section as completely as we can with links to active discussions. -- 14:22, 25 January 2019 (UTC)


 * Define active, because a lot of discussions have not come to conclusions, but are as dead as I don't know what.  14:25, 25 January 2019 (UTC)


 * Sorry, I should have said "unresolved" there as well. -- 14:27, 25 January 2019 (UTC)

Semi-Protect all pages in the File: namespace?
All IP edits to pages in the File: namespace are usually only vandalism, and I have a suggestion, should we semi-protect all pages in the File: namespace so only users with registered accounts can edit it and if there is an edit the IP want to make (such as an reupload request) they should make a request on the files talk page. -- ( • ) 17:41, 24 January 2019 (UTC)


 * . It's definitely true that many IP edits to the File: namespace are vandalism, but there are constructive edits being made and I don't think the vandalism frequency is quite enough to warrant protection. The vandalism edits aren't necessarily difficult to handle, there aren't that many of them and they get reverted quickly, and I think protection would be annoying for the IP editors who make constructive edits to files, and they may not feel like going to the trouble to post on the talk page and wait for a response. I'm open to changing my mind, however.-- Orange Glazed Terracotta.pngLight Blue Glazed Terracotta.png 14:14, 25 January 2019 (UTC)


 * , File NS vandalism from IPs is a rather small portion of all vandalism, and it's less visible due to file pages being less exposed to average readers. Namespace restrictions will harm users with good intentions more than vandals. -- 14:18, 25 January 2019 (UTC)

Articles about persons: what to include and what not to include?
Following a discussion from Discord, what should and what shouldn't be included in articles about people? What's our equivalent of ? Do we need to list employees' marital status and the number of their children? There are several people opposing including the latter into MCW articles. -- 20:16, 24 January 2019 (UTC)
 * I believe adding such information as marital status or number of their children does not belong on the wiki. Prefer sticking to information relevant to Minecraft like position in the company, what the person is doing there.  20:28, 24 January 2019 (UTC)
 * I agree that we shouldn't be publishing such personal details as marital and parental status. I see no reason we should publish anything about people unless it's already public and it helps our readers play the game or participate in the community. Even if somebody volunteers additional information on their Twitter account, etc., that doesn't necessarily make it freely publishable by us, especially if they change their mind later. I understand wanting to give Mojang people credit for their contributions, but that should be Mojang's job, not ours. In fact, I'd love it if we only published biographical articles that people write about themselves (subject to vetting, of course).
 * There's one more thing to consider: exists to protect Wikipedia from legal liability. Someone from Gamepedia/Curse (?) should be part of this discussion. –  ( &middot; ) 21:21, 24 January 2019 (UTC)
 * We have no hard and fast policy for such information, but personally I agree that marital status/offspring etc are not pertinent to the subject area of the wiki. —  21:30, 24 January 2019 (UTC)
 * Unless it's somewhat related to the game (for example, Notch made a special offer during his wedding, IIRC), personal life should probably be left to the minimum. There is absolutely no reason to add them here. And it's a bit creepy, really.  01:04, 29 January 2019 (UTC)
 * I don't have any opinion on marital status or the like (it doesn't seem particularly important, but also it doesn't seem like something that should be avoided per se). However, I think there is some such info that is useful, and my example of it is dinnerbone being red-green colorblind (see ).  This plays in to things like the removed .  --  01:11, 29 January 2019 (UTC)
 * For me, his color-blindness is more a fun fact than a real personal information, so I don't think it would have been necessary to remove it anyway.  16:11, 29 January 2019 (UTC)
 * I definitely feel that their children should not be part of the page. I feel identifying information ought to be forbidden while they're a minor. And even the mention of the children/parenting should be avoided unless mentioned minimally when it has some direct bearing on the game... though I don't have criteria in mind for that really. –  |  21:57, 11 May 2019 (UTC)

Infobox item images are improperly scaled. Reupload?
by. Arguments for the proposal are provided there. Additionally, I think some currently used images have been made by scaling directly from 16x16 to 150x150 with nearest neighbor interpolation, which results in distorted images (some texture elements are scaled into 9x9 squares or 9x10 rectangles, while many are scaled into 10x10 squares).

Assuming we don't need IE 11 support, we could also try using sprites with CSS rendering method configuration, instead of reuploading 150x150 images with 160x160 versions.

The proposal still needs comments, which were completely absent in its original instance.

As a side note, the Russian wiki has been recommending 160x160 item images for some time now. -- 18:42, 26 January 2019 (UTC)

Gadget proposal: Less annoying alternative to the BLOCKED stamp on Curse profiles
Arguments against that stamp:
 * Can't be translated easily (only irrelevant if non-English communities are treated as second-class citizens)
 * Takes a lot of traffic for something which can be done only with text (only irrelevant if users on mobile and low-bandwidth connections can be disregarded)
 * Takes a lot of screen space and obstructs useful elements even if it's click-through (only irrelevant if we don't care about good design)
 * Excessive for short-term technical blocks (only irrelevant if we don't care about community health)

Arguments for that stamp:
 * Satisfying (irrelevant because it's shown to everyone and not only the blocking admin)
 * Public shaming (irrelevant because only toxic communities think public shaming is not something bad)
 * "I like it" (this argument is only relevant if more substantial arguments don't exist, and I have four)
 * "There haven't been much complaints about it" (never relevant, indicates Gamepedia staff members who support this argument are acting in bad faith to subvert constructive change).

This gadget I propose doesn't prevent the image from loading, but replaces it with less obtrusive, translatable (when implemented on non-English wikis) and ergonomic version which also adds relevant links. I have tested it on both mobile view and desktop view and found it works satisfactorily on most environments I could recreate.

Enhancement suggestions are welcome. I consider seeing this, or something like this, becoming the default to be a major victory for the community. -- 11:32, 29 January 2019 (UTC)


 * I agree with you arguments, and the code looks good to me, but I also have my own idea. A blocked user's name should be with strikethrough formatting, suffixed with (blocked) or something like that, eg: (blocked). Any links you want/need could be added within those brackets then. –  [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 11:50, 29 January 2019 (UTC)


 * That was pretty much the first version of my code, but I found this was clumsy on low-width screens. -- 11:59, 29 January 2019 (UTC)
 * Look at the image to the right; the "blocked" icon in the upper right corner should we use as a icon on blocked user's curseprofile rather than the stamp. While howering over the icon, a tooltip could appear with "This user is blocked" with link to th block log. Any proposals to the image? -- Wikipedia-logo.png ( • ) 14:16, 29 January 2019 (UTC)
 * 1. There is also the global block log which should be linked to as well. 2. There are no tooltips for mobile devices due to no way to activate hover events. 3. The meaning of that icon is not immediately obvious. -- 14:25, 29 January 2019 (UTC)
 * AttemptToCallNil@undefined Why did you remove the image? The image I uploaded want I to display to see the blocked icon. Please make the image display again 🙂😃 -- Wikipedia-logo.png ( • ) 14:33, 29 January 2019 (UTC)
 * I replaced the image with a link to an image (sorry, should have mentioned that here) because a 1000px wide image embedded in a talk page is the total opposite of a good option. --  14:35, 29 January 2019 (UTC)
 * Okay, I understand that. Okay 😄 -- Wikipedia-logo.png ( • ) 14:37, 29 January 2019 (UTC)
 * Okay, I understand that. Okay 😄 -- Wikipedia-logo.png ( • ) 14:37, 29 January 2019 (UTC)

Block sounds
Can the placement, breaking, stepping, landing, etc. sounds for blocks be uploaded and added to the pages of blocks, and historical sounds added to the History section where applicable? -  21:15, 1 February 2019 (UTC)
 * If you'd like to do that then yes. –  Nixinova sig image 1.png Nixinova sig image 2.png 21:26, 1 February 2019 (UTC)

Does anyone have access to a version of Pocket Edition for iOS between 0.5.0 and 0.11.0, so I can rip the sounds for it? Or, if providing the actual version directly isn't legally possible, could they directly rip the sounds and upload them instead so I can transclude them on History sections where appropriate? -  18:02, 2 February 2019 (UTC)

Move In(f)dev pages
I don't think "In(f)dev (month day, year)" is the best way to go. I think we should follow the version jar name of "In(f)dev ymd-n" (eg "Infdev 20091231-2"). It's much easier to link to and is shorter. It also isn't as conjectural as what is currently in use as it's the name of the jar. –   02:35, 15 February 2019 (UTC)
 * This is planned to go through when the Java rename is completed. –  Nixinova sig1.png Nixinova sig2.png 06:30, 27 February 2019 (UTC)

New bureaucrat
The result of the discussion was Promote.

Since has sadly retired, there have been several discussions on  to promote a new bureaucrat. Several users mentioned me in particular as a potential bureaucrat. Currently, we only have one active bureaucrat. Because MCW has patrollers, directors, an inactive-admin demoting "policy", etc., bureaucrats have somewhat of an active role here, at least more so than many other Gamepedia wikis, so having more bureaucrats would probably be useful. So would you, as the community, want me as a bureaucrat? As for what I'd do with the bureaucrat tools, I would probably primarily promote patrollers if they're clearly fit for the role, update directors as they're promoted on other wikis, and occasionally demote inactive admins. I only want this position if it's something the community clearly wants, so if there is a flood of opposes for this I'd be happy to withdraw this request. Also, bear in mind that I'm not the only person who could be a bureaucrat; there are five other admins besides me who are active and not bureaucrats. Thanks, -- ( 18:32, 22 February 2019 (UTC)
 * –  Nixinova sig1.png Nixinova sig2.png 23:08, 22 February 2019 (UTC)


 * You have been very involved with the roles of users on the wiki already, and you're very accessible on the wiki in cases where users need your help. I also think that having someone from the community itself rather than a wiki manager (or similar), who is active and can look into the activity of other users is necessary for a wiki like this one. Our wiki manager(s) are not so much involved with bureaucracy for us, so why not one of us? So I . I would also support for bureaucrat, as they've been here for a long time. –  [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 08:52, 24 February 2019 (UTC)
 * both and  to be bureaucrats. I say  to  because he are not so much active., and : What should you do if you want to be bureaucrat? --Wikipedia-logo.png ( • ) 07:05, 25 February 2019 (UTC)
 * Hi, thanks for commenting; I think by "What should you do if you want to be bureaucrat?" you mean what specific purposes I would use the bureaucrat tools for were I to be a bureaucrat, but I could be wrong. If so, I answered this already in my original post: "promote patrollers if they're clearly fit for the role, update directors as they're promoted on other wikis, and occasionally demote inactive admins".-- ( 13:41, 25 February 2019 (UTC)


 * Madminecrafter; he's been active and observant on the wiki and has often requested Dinoguy to promote/demote other users in the past, and I would trust him with the bureaucrat tools. I have no particular objections against Orthotope or KnightMiner either. – undefined  07:29, 25 February 2019 (UTC)


 * I can say as far as me as a bureaucrat, while I do respond to discord pings pretty quickly, any promotions/demotions I make would primarily be requests from others; one of the more active admins who is more engaged in the community would be a better choice as they know who to promote. While I am not sure how active he is lately I can say I with Orthotope for bureaucrat based on my experience with him on the wiki. I am a bit more neutral about Madminecrafter12 as bureaucrat as I have not had as much experience with him as an admin as with Orthotope, but seeing as he is the one making a lot of the right change requests I think granting him the rights makes sense.
 * As a potential alternative, since admin rights changes should not need to happen often, why not allow admins to grant the director and/or patroller right to other users? Those are the rights that change the most anyways, and would alleviate the requests on the bureaucrat(s). Directors definitely makes sense as no consensus is needed to grant the right (its just for language parity), and I cannot forsee an admin abusing granting the patroller right. If this is done, it would still make sense to add another bureaucraft, but they would not need to remain as active. – · 02:23, 27 February 2019 (UTC)


 * Well, for what it's worth, I actually did briefly ask on Slack if it would be possible to allow bureaucrats to promote and demote directors. As you point out, promoting/demoting directors doesn't require any contributions reviewing, discretionary decision-makings, etc.; you just give it to users if they're an admin on another Minecraft Wiki. However, I was told that for some reason, because Directors is a local group rather than a global group, there is not a way to enable certain user groups to grant specifically Directors to individual users, without giving those certain user groups (e.g. in this case it would be admins) the "Edit all user rights" user right (which of course would allow the adding/removing of admin and crat). I would assume it would be the same way for patrollers.-- ( 02:38, 27 February 2019 (UTC)


 * Well, that's an unfortunate limitation. If we cannot allow admins to grant just those two rights, then I will increase my support for a second bureaucrat. I agree with either you or Orthotope, though I would like a comment from Orthotope on the matter before giving full support. – · 02:54, 27 February 2019 (UTC)


 * I do think we should have Orthotope respond here before taking any final action regarding him as bureaucrat; it's possible that he does not want the role.-- ( 02:56, 27 February 2019 (UTC)


 * This has gone on for over a week now; as the only active bureaucrat, do you think action could be taken from this now? Or do you think further discussion would be beneficial?-- ( 23:20, 2 March 2019 (UTC)


 * As I've said before, I believe another admin to replace dinoguy is appropriate (FVbico is now promoted as a result), but I don't believe another bcrat is necessary as role changes aren't particularly frequent or time-sensitive, so I'm easily able to keep up with approved requests, and we have gp staff to assign another bcrat if I drop dead. However, since there is reasonable community consensus to have another bcrat anyway, I'm fine with promoting you. – ᐸ  05:47, 3 March 2019 (UTC)

Unlinking on talk pages
There isn't a set way of removing links to deleted pages on talk pages. Some people nowiki it and others remove the link altogether. I think the best way to do this is to replace the link with [{{FULLURL: page name} } page name]|undefined. It remains a working link and doesn't put the page on the wanted page list. –   06:27, 27 February 2019 (UTC)


 * I proposed converting archives to be static on the admin noticeboard, and this is one of the conversions that would be performed. – ᐸ  05:43, 1 March 2019 (UTC)

Auto-refresh button on recent changes?
Can we please add an "Auto-Refresh"-button on, , and some other pages that can be used to track changes, the button is very useful, thus allowing use of Recent Changes and the Watchlist without needing to reload the page every time to update the recent changes, I would that we add this function as a gadget that is enabled by default, so if users dont want this function they can simply uncheck the box on their options page, as a suggester i that this would be added. Any suggestions or opinions? -- ( • ) 10:37, 1 March 2019 (UTC)


 * I can't see why we would need this. It would put more stress on the wiki needlessly if people load long datasets from those pages. – [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 08:10, 2 March 2019 (UTC)
 * Why do you oppose this addition? The Auto-Refresh checkbox might be very useful to easily patrol RecentChanges without needing to reload the page, if you don't want to have to refresh the recent changes every time to see newest changes, i have a script, just copy/paste it to your .js if you don't want to have to refresh recent changes, please explain why you don't want it? the most important pages is  and the watchlist.-- Wikipedia-logo.png ( • ) 13:41, 4 March 2019 (UTC)

Some user cleared their messages a couple years ago, not a single revert. How is this acceptable?
An example is the. Yes, this isn't new, but why did no one revert this before? Posting here instead of the Discord server because people there are quick to force a more "important" discussion whenever I raise an issue. -- 18:11, 1 March 2019 (UTC)


 * Definitely not acceptable per the talk page guidelines:
 * "Do not delete topics or comments, unless they are your own topic/comment and they have not been replied to. An exception is when archiving or if the topic violates one of the other rules."


 * Going to revert it in a minute. - ( 18:42, 1 March 2019 (UTC)

About
I have made a new version of the sprite because of the outdated textures (e.g., , ) in the current sprite sheet, but I can't upload it. Do you accept the new textures in the new sprite sheet? -- 12:39, 11 March 2019 (UTC)


 * You can upload them under a different sprite ID for now; I’m doing the same with the block and effect sprites, rename/replace them when the texture update is released.  13:26, 11 March 2019 (UTC)


 * While on the subject, should probably be added to the sheet. It is used with pistons and can't always be replaced by obsidian. Not all of them would need to be added; just 1 should be sufficient.   17:03, 12 March 2019 (UTC)

Is there any standard for the block and entity renders?
Many pages on this wiki have a render of the block or entity that the page is about. Is there any standard for these renders? Is there a specific software used for all these renders? 22:57, 25 March 2019 (UTC)


 * This should answer your question: .  00:04, 26 March 2019 (UTC)
 * Yes, that does answer my question. Thanks. I don't know if I'm supposed to do something with my topic and the replies now that my question has been answered. 00:21, 26 March 2019 (UTC)
 * Hi, for now this discussion can be left as is. Generally discussions aren't removed just because they have been answered (although if a talk page is getting long and a discussion is old, it may be archived to a separate page); they can be useful for record purposes, makes it easy for other users to add more replies if necessary, and does not hurt anything. Cheers, -- ( 00:59, 26 March 2019 (UTC)