Minecraft Wiki talk:Talk page guidelines

Replying to old posts
To clarify, is replying to an old post (general rule #4, last sentence) an undo-able offense, or just discouraged? My personal feeling is that if a topic hasn't been archived then it's open. And if a reply is no longer really relevant, then so what -- if it was in good faith, just ignore it if you don't want to reply to it or point out the reply's irrelevance. Every time we delete someone's post we may be discouraging them from becoming a positive contributor to the wiki in the future. &mdash;munin &middot;  &middot; 15:29, 21 March 2015 (UTC)


 * I personally don't have anything against most replies, I mainly find those comments annoying when a user is pointing out all the solutions to a problem that did not exist. As for actually reverting them, since we officially have the guideline in place, it is no longer disallowed to reply to old comments (I specifically worded it to "discouraged" rather than "disallowed"), so I stopped reverting them. (I was planning on discussing this with a couple older editors, though I wanted to wait until the site notice, then I forgot about it)
 * I would agree a reply to a old comment reply makes more sense, although if we archived the pages better that would avoid the problem for the most part. It would even make sense if you see a reply to an old comment to take that as a cue to archive the topics. – KnightMiner  · (t) 16:07, 21 March 2015 (UTC)

Signing your previously unsigned comment
Can we make it a rule that you should not sign a comment of yours that was already marked "unsigned"? (basically, you don't sign your post, someone else marks it with unsigned, then you replace unsigned with your current signature) I've seen several users do it, and it causes the problem where the timestamps are no longer accurate.

It may also be relevant to add a template to "sign" your previously unsigned posts, like wikipedia:Template:Signing – KnightMiner  · (t) 03:03, 27 March 2015 (UTC)


 * I don't see that this would be particularly helpful, really. Most editors who forget to sign their post are new and don't realize they're supposed to, much less how they would do so (especially given many people are conditioned to ignore banner-like elements on web pages because of banner ads); they certainly shouldn't be expected to understand why we're telling them to sign all their posts except this one, or why having a correct timestamp is important. I would be fine with letting them know they can re-sign an unsigned post with three tildes if they leave the timestamp alone, but ultimately it isn't a big deal to just recopy the original timestamp if they sign over it. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 03:43, 27 March 2015 (UTC)


 * Yeah, three tildes would make sense, something like "If you forget to sign a post, you make sign it using three tildes, just make sure the time stamp is the same" – KnightMiner  · (t) 16:15, 27 March 2015 (UTC)

Closing and archiving topics
I noticed while the talk page guidelines mention archiving topics, it does not mention closed topics or specifics on archiving. I would like to propose the following section to handle those:"

If a topic has been at least 30 days since the last reply, the topic may be moved to the appropriate archive page. Archive pages should be made as a subpage of the talk page with a prefix of "Archive" before the archive number. Archived topics should not be edited for reasons other than maintenance. If a user wishes to discuss to an archived topic, they must start a new topic instead.

Topics can also be closed before being archived using close topic, and when closed the topic is under the same restrictions as an archived topic, but it still remains on the main talk page. This generally should only be done in cases where the topic is a proposal, and is done to prevent further comments on a topic when it has been resolved. In order for a topic to be closed, it either have been open for at least a week and been three days since the last reply, or the topic of the discussion must have been performed.

On user talk pages, only the controlling user should close or archive topics in most cases. They are also exempt from the restrictions of when topics can be archived or closed, and the format of the archive titles; however, the restrictions are still advised to be followed.

The main point of this is the second paragraph, as I have seen several times a user closing a topic simply because there are a lot of users agreeing or disagreeing, or they feel one of the comments removes any further need to comment, which leads to the issue of some users never being able to discuss the topic at all. The first paragraph itself is main standardizing what is already in practice, but also to allow most of general 4 to be moved to this section.

– KnightMiner  · (t) 15:12, 4 August 2015 (UTC)


 * . – LauraFi -  talk  20:01, 21 December 2015 (UTC)

Disallow long signatures
Can we disallow overly long signatures? 's signature is currently taking up nearly the full width of the page on my monitor, which is hardly needed as signatures main purpose is stating who made the comment. Wikipedia has disallowed this, and I see no reason why we shouldn't as well.

MCPEplayer2@undefined Since this does affect your current signature, feel free to state your opinion of if we should keep allowing them.

– KnightMiner  · (t) 01:56, 24 August 2015 (UTC)


 * . — Agent NickTheRed37 (talk) 15:43, 24 August 2015 (UTC)


 * . --MCPEplayer2 Block of Gold.png Talk to me! 22:19, 24 August 2015 (UTC)
 * Any specific reason why you oppose? Stating a reason might help convince others to agree with your case. – KnightMiner  · (t) 23:02, 25 August 2015 (UTC)
 * Signatures with long coding are okay, but I prefer not having the raw signature becoming too long. --User:MCPEplayer2 Gold Ingot.png 00:32, 28 August 2015 (UTC)


 * Actually, we already disallow long code. By default, the signature field only supports up to 250 characters, and the talk page guidelines disallows a substituted signature from being longer than 250 characters as well (see "Signing" under "Links"). This proposal is only about displayed width. – KnightMiner  · (t) 14:39, 28 August 2015 (UTC)
 * Then I . --User:MCPEpl</b>ayer2</b> Gold Ingot.png 16:59, 29 August 2015 (UTC)

State against deleting topics
After some recent reverts, I noticed the talk page guidelines never specifically state not to delete comments or topics, despite users frequently reverting such edits. So I propose adding to the general guidelines something like "Don't 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." This guideline will be added to the list of guidelines that user talk pages are exempt from. – KnightMiner  · (t) 05:19, 15 November 2015 (UTC)


 * &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 06:48, 15 November 2015 (UTC)
 * –Goandgoo</b> ᐸ <small style="display:inline-block;line-height:1em;vertical-align:-0.4em">Talk Contribs 06:50, 15 November 2015 (UTC)
 * – LauraFi -  talk  12:47, 15 November 2015 (UTC)
 * -BDJP (t 13:43, 15 November 2015 (UTC)
 * . — Agent NickTheRed37 (talk) 16:16, 17 November 2015 (UTC)

Proposals
It has come to my attention that there really are not any guidelines about proposals, specifically move requests. Wikipedia does have a little to say about that, though not everything fits the wiki here perfectly, so I'd like to extend some of those guidelines here. Specifically, I would like to address the following points:
 * 1) What determines consensus, specifically that we don't go by votes, but unanimity is not required.
 * 2) Length of time before taking action from a proposal. General convention here seems to be about a week, though for small proposals I find 3 to 4 days is good.
 * 3) Information about taking action from a proposal with no replies. With larger proposals, this is no action, but most smaller ones it is usually is fine to take action after about a week if there are no replies.
 * 4) Length of a time before a proposal is closed due to lack of consensus or consensus against. This is mainly for the of those discussions that keep going with no agreement between both side or keeps going with later people saying "disagree".

Note that nothing is really written up here, as I want a few more opinions on the specific details to get this closer to general convention over my personal choices. – KnightMiner  · (t) 17:52, 21 November 2015 (UTC)

Archives
Sometimes a section gets abandoned. Later, it gets archived, even though the user is not done. I have two proposals: Should we implement these proposals? The BlobsPaper.png 15:38, 10 August 2017 (UTC)
 * Do not archive sections in MCW:Community portal.
 * If a section gets archived against your will, you can unarchive it.


 * I agree with the second proposal. I remember that a user archived the community portal’s talk page on the Russian wiki, but a theme about accepting new rules and guidelines has been ongoing then already, and yet it was archived too. The action has been reverted later. (These new rules and guidelines haven’t been accepted and were put on hold, unfortunately.) I would actually go for a period ranging from 2 weeks to 1 month until a topic is deemed suitable for archiving, unless the discussion has been closed directly, after what it is immediately suitable for archiving.
 * Regarding the first proposal, the request for comment should be removed once the associated discussion has been closed or went inactive and hasn’t been revived for 2 weeks to 1 month. —  BabylonAS</b> (talk | ru.Wiki Admin) (fka NickTheRed37) 16:03, 10 August 2017 (UTC)
 * To me, abandoning a discussion is a reason to add the discussion to the request, in order to reactive the discussion. The BlobsPaper.png 19:53, 10 August 2017 (UTC)


 * If a section is over a year old (typical time for an archive), you start a new topic and link the archive. There is no reason to pick up an old topic and start as if the year has not passed. I see no point in allow users to unarchive things as it will simply cause issues with users wanting to unarchive quite old topics. Additionally, it starts to break down the rule about not editing archives as now you just need to move before editing them.
 * As for the other point about not archiving requests for comment, I can say its a good idea to not archive them if awaiting request. Typically if a request is old enough that the topic becomes old enough to archive I really doubt anyone is going to comment so you might as well remove the request, or bring it to a more visible location in a new topic. – KnightMiner  · (t) 03:10, 12 August 2017 (UTC)
 * What would a better place be? The BlobsPaper.png 15:14, 12 August 2017 (UTC)
 * Community portal directly if the topic warrents that much attention. If not, you can sometimes assume everyone who wants to respond has. Its really a case by case thing for that. --– KnightMiner  · (t) 23:15, 12 August 2017 (UTC)
 * Rules can be always modified to have exemptions. And, it is always possible to implement a period after what the topic can no longer be revived. —  BabylonAS</b> (talk | ru.Wiki Admin) (fka NickTheRed37) 14:19, 13 August 2017 (UTC)


 * I feel it makes more sense to instead have an official minimum period after which topics can be archived, say if the last comment is X months old it can be archived. I personally say why archive them if they are just going to be revived again? If the topic is worth bring up again after that period, I think its worth having a header explaining why its worth discussing again. – KnightMiner  · (t) 22:53, 15 August 2017 (UTC)
 * I would support a template indicating that a topic should not be archived. I also think that there should be a category so users can find in-use discussions. This could replace the Requests for Comment. The BlobsPaper.png 01:13, 16 August 2017 (UTC)

Signature backgrounds, images, expanded length
There are already guidelines on the amount of files a signature may contain, and the length of the final expansion if using transclusions. But there are signatures that don't meet these criteria (2 files, 250 character expansion), and no one is enforcing anything. Only once have I seen gamepedia politely requesting a change of signature for someone, but that's about it. And there is absolutely nothing about using background colours on the text.

Should there be enforcing of these rules, or is this page really more a guide than the rule? And should a new guideline be added to restrict signatures from using background colours? Because if the expanded length of a signature is obstructive during editing, than background colours are definitely during reading. The generally accepted concept is that a signature is meant to just identify the editor, not grant attention. But what falls under acceptable formatting is subjective. Please share opinions. (I already fixed my own signature beforehand to meet the criteria) – Jack McKalling 09:32, 29 May 2018 (UTC)


 * I'm leery of making it a hard-and-fast rule (my signature, for example, is 273 characters long, if I counted correctly). The main point here in my opinion is that we don't want signatures to be disruptive or distracting, and the current guidelines are focused on things that often make a signature disruptive/distracting, but it's perfectly possible to have a signature that violates the letter of one or more of these guidelines without actually being disruptive or distracting (I hope my own signature is an example of this, and certainly I don't recall ever getting complaints about it, either here or on any other wiki). 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 12:29, 29 May 2018 (UTC)


 * Abstaining from commenting. My opinion would be rejected as too restrictive. Just so you know, I have doubts on that my current signature is not disruptive. --AttemptToCallNil (report bug, view backtrace) 13:56, 29 May 2018 (UTC)


 * Yours is miles better than some I've seen over the years, I can promise you that. I still don't know how people can think that a signature that doesn't mention their username or link to any of their userpages or their contributions is useful. 「 ディノ 奴 千？！ 」? · ☎ Dinoguy1000 14:07, 29 May 2018 (UTC)


 * I'd say, as long as the line height of the line the signature is on isn't changed and if decent contrast with the default light blue background is there, I honestly don't see a problem. — DarkShadowTNT  ( t  ♦  c ) 15:46, 29 May 2018 (UTC)
 * But if that contrast is well more than decent, and makes its own text unreadable, or when red on green colours (colour blindness) are used, doesn't that introduce reading difficulty, or would you still find that acceptable? – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 15:54, 29 May 2018 (UTC)


 * As I'm not colour blind, I have no way of testing. I hadn't anticipated for coloured text on a background other than light blue. Maybe a gadget can be created which renders everything in high contrast for ones in need of that? — DarkShadowTNT  ( t  ♦  c ) 18:07, 29 May 2018 (UTC)


 * Well, it is described as a guideline, which (on Wikipedia at least, not sure we've been as clear about this) means it's not strictly mandatory.
 * I doubt that the 250-character limit was meant to limit the length of the signature code. It seems more likely that it was to avoid killing the information density and readability of talk pages. Plus, if you interpret it as a limit on the code, it's useless because you could subst: a template in there and have a 10,000 character signature without violating the guideline. Whatever it meant should be redefined in terms of the results, not technical details. Btw, Dinoguy's sig is a measly 22 characters by my way of counting.
 * On the one hand, I feel like editors should be entitled to express their individuality in ways they feel are "cool". But on the other hand, standing out from the crowd on a talk page is contrary to the whole wiki philosophy of collaboration without ego. They're already entitled to dress their talk page however they like with few limitations. They should be gently encouraged to be more modest elsewhere, in the spirit of being a team player instead of a showboat. But remember, most of these signatures belong to kids who will one day grow up and not want such a childish signature. So they'll change it and all their posts will suddenly become no longer remarkable. In the meantime, we can insist on their sigs being readable (including by colorblind people) because that's necessary for wikibusiness, but we don't need to be too prescriptive. – Auldrick (talk &middot; contribs) 17:44, 29 May 2018 (UTC)


 * Actually, wikipedia describes here: wikipedia:WP:SIGLEN that the limit does apply to the expanded length, the length of the result after expansion of transclusions, because the software can't automatically perform the restriction after template expansion and we need to comply the limit manually. So transclusion is not a hack to said limit, but just a limitation of the software. But the case is indeed about the density of information the editor has to go through when adding to a discussion, so that's what we could take into account with our wiki's guidelines if needed/decided upon. Because of the reasons you've mentioned yourself Auldrick, it's not fair to limit signatures based on just the code needed for subst-ing. In my opinion, we should look into whether we need or should sharpen or loosen any of the signature guidelines, not about how individual's problems could be fixed (like with modules), because everyone has a special:mypage/common.css, with which they can change anything for themselves where needed. Instead, how much do we want to restrict, in order to decrease obstruction for both readers and editors (where consensus of such is)? – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 18:28, 29 May 2018 (UTC)


 * Personally, I only find images to be a problem on signatures, generally speaking, due to not really being "portable" across wikis, but I have never found generated code length to be causing any concerns. DSquirrelGM &#120035;&#120031;&#120018; &#128504; 04:14, 13 July 2018 (UTC)


 * To use my signature as an example, I only use images that are already on the wiki, using minecraft inventory icons that fit exactly in the signature height and these are not intrusive. In this example I also wouldn't need to port the images, because they would be different on other wikis anyway, like on Terraria I would use Terraria themes ones, and on minecraft interwikis these images are already present. Other types of images a user would customly upload to the wiki just for their signature would be a different story though. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 08:21, 13 July 2018 (UTC)


 * There's also the problem that, if a file used in a signature is also used in articles as game material, the signature will be affected if that file is reuploaded or deprecated. For instance, if we were to move away from Grid images to using InvSprites, we would have to keep some images if someone decided to use them in their signature. --AttemptToCallNil (report bug, view backtrace) 08:58, 13 July 2018 (UTC)
 * Or inform people that if they use them, they should accdept they may get updated at some point without prior notice. It's their choice to use them, does not mean the image is then suddenly theirs. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 07:33, 14 July 2018 (UTC)

flying mob: bird attack
I built a solid wall around me in survival and thought I was safe without a roof but large flying things eventually attacked me from the sky. What are these and are they new? I couldn't see anything on the mob lists. 69.248.214.138 20:10, 16 August 2018 (UTC)
 * It's probably the phantoms, and you posted this question on the wrong page. --AttemptToCallNil (report bug, view backtrace) 20:11, 16 August 2018 (UTC)

Wording change
I suggest changing  to , or something similar. I think the second is more of the intended meaning of the sentence, as with the current wording, it makes it seem like you can remove any posts from anybody else's talk page. We certainly don't want that.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 01:35, 26 August 2018 (UTC)
 * User talk pages should not be unconditionally exempt from rule 6. It serves no purpose and has exclusively negative effects, especially if the deleted message has administrative significance (e. g. a warning or a block notice). Since the only argument provided for the exemption is that users' talk pages are theirs and therefore should be exempt, let me tell you: this argument is total garbage for a number of reasons beyond just what's provided above. Such as that no user is the sole member of the editor community, and therefore everyone is expected not to unnecessarily complicate others' interaction with the wiki.
 * Six should definitely remain in effect for at least warnings and block notices, and likely for all comments. --AttemptToCallNil (report bug, view backtrace) 10:26, 26 August 2018 (UTC)
 * I would add on that: removing an other user's message on own user talk page may be a sign of its owner trying to evade responsibility and surely may not be considered as constructive behavior. A user talk page still remains a talk page, and nothing should restrict its communicative role, even the wishes of its owner. &mdash; BabylonAS</b> (talk | ru.Wiki Admin) 10:43, 26 August 2018 (UTC)


 * For now I've made the change I originally proposed, as I definitely think this was the intent of the text. I do think we should have more discussion before we remove it completely, though. I personally am as to whether we should disallow users from removing comments from their own talk page if they don't violate the rules.-- Madminecrafter12 Orange Glazed Terracotta.png to meLight Blue Glazed Terracotta.png 13:50, 26 August 2018 (UTC)


 * A reason I heard for people removing comments from their own talk page, is that it is for some people their way of saying "I've read this". But I feel against this particular behaviour. Better ways are moving discussions into an "archive" section on the page, or moving it to an actual archive page while using archive box (as suggested by the guideline). If comments or discussions are about administration or moderation of the user of that page, these must remain visible so other staff can still see it without inspecting the page history. Removed source is not visible. Even if they leave an appropriate explanation in the edit summary as to why they've deleted a comment or discussion from the page's source, it will still be invisible without inspection (which could be tedious for just finding a particular removed comment). I really feel we should either disallow removal of these comments, and/or make it clearer from the posted comment whether it may be removed at some point or not. Like for instance, uw-wrong could show some kind of indicator that it may not be removed once posted (just example idea, not necessarily a full solution). Also, I do think we should distinguish administration/moderation comments from other, regular ones when determining if they can be removed. Because I've seen IP users post nonsense discussions on talk pages, or subjects that don't belong on the wiki, and some users may but others may not like those on their talk page. They should remain the right to be able to remove undesired comments like that, if they don't want to deal with them politely. After all, IP users will not get notifications or pings if they're replied to anyway. – Jack McKalling [ Grid Book and Quill.png Grid Diamond Pickaxe.png ] 09:45, 27 August 2018 (UTC)

Disallow deleting posts on own talk pages
This breaks the assumption that every valid post on a user's talk page is available in the latest revisions of the talk page and its archives, and without that assumption, people will be forced to read the entire history log instead of just one revision in order to search user talk pages at all. This is effectively unconstrained freedom for the user which is at the expense of others and servers no purpose in itself.

The current wording "discouraged" should never be used in any form of policy, because violating such clauses either: 1) never becomes a basis for sanctions (effectively "allowed"); 2) becomes a basis for sanctions without any pattern or with an unstated one (effectively "unwritten policy enforced at admin discretion"); or 3) always becomes a basis for sanctions (effectively "prohibited"). --AttemptToCallNil (report bug, view backtrace) 09:55, 22 November 2018 (UTC)


 * I have already said my opinion on this several times (both here and on Discord), and I support this proposal undoubtedly. —  BabylonAS</b> (talk | ru.Wiki Admin) 12:45, 22 November 2018 (UTC)