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)