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. —munin · · 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)

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

Disallow long signatures

Can we disallow overly long signatures? MCPEplayer2'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: 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)

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

 Oppose. --MCPEplayer2 ^{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 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  Support. --User:MCPEplayer2 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)

 Agree —munin · · 06:48, 15 November 2015 (UTC)

 Agree –Goandgoo ᐸ Talk
Contribs 06:50, 15 November 2015 (UTC)

 Agree –LauraFi - talk 12:47, 15 November 2015 (UTC)

 Agree -BDJP ^(t|c) 13:43, 15 November 2015 (UTC)

 Agreed. — 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:

• Do not archive sections in MCW:Community portal#Requests for comment.
• If a section gets archived against your will, you can unarchive it.

Should we implement these proposals? The Blobs 15:38, 10 August 2017 (UTC)

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 (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 Blobs 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 Blobs 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 (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 Blobs 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 [ ] 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 · 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 [ ] 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𝓣𝓟𝓒 🗸 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 [ ] 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 [ ] 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 User talk pages are also exempt from rules 1 and 6 to User talk pages are also exempt from rule 1, and one's own talk is exempt from rule 6 as well, 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^{Talk to me} 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. — BabylonAS (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  Neutral as to whether we should disallow users from removing comments from their own talk page if they don't violate the rules.-- Madminecrafter12^{Talk to me} 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 [ ] 09:45, 27 August 2018 (UTC)

Disallow deleting posts on own talk pages

The following is a closed discussion of a proposed policy amendment. Please do not modify it. Any editors wishing to make further comments should start a new topic.

The result of the discussion was remove the exception allowing users to delete posts on their 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 (talk | ru.Wiki Admin) 12:45, 22 November 2018 (UTC)

IMO, you should be allowed to delete useless messages only (such as “hi”), but be required to keep the proper ones (those voicing concerns, starting discussions, etc.). FVbico (talk) 17:45, 22 November 2018 (UTC)

Yeah; how do we phrase the policy to make it clear that removing test edits, vandalism, and the like is acceptable, but removing other comments is not? -- Orthotope^talk 17:59, 22 November 2018 (UTC)

This isn't that much of an issue, given that general guideline 6 makes an exception for cases when "the topic violates one of the other rules", and this includes vandalism. Do we need to rephrase that exception?

And then we have warnings, where it is questionable that a user should have authority to determine they are vandalism.

Also, I find it weird that the purpose of user talk pages is defined in the very end of the General section, while generally talk page purpose is defined in general guideline 1. At first, I didn't notice user talk pages have a defined purpose at all. --AttemptToCallNil (report bug, view backtrace) 18:09, 22 November 2018 (UTC)

 FYI Quote from the Russian wiki’s rules page: section “Discussion rules”, point 4:

4. Deletion of comments by other users is not allowed, excluding cases if these comments violate these rules and the fact of violation is obvious. If the fact of rules’ violation is not obvious but proven, such a comment must be removed by administrators or with their consent.

 1. Deletion of other user’s comments on a user talk page by the associated user is not allowed (excluding cases described above), especially if these comments have administrative tone (e.g. warnings or block messages).

 2. Own messages can only be removed in case they haven’t been answered, there hasn’t been any reaction to them, or they violate the rules.

Original (in Russian, per ru:Special:Permalink/698230#Правила обсуждений)

4. Запрещено удаление чужих сообщений другими участниками, за исключением случаев, если они нарушают настоящие правила и если факт этого нарушения очевиден. Если нарушение правил неочевидно, но доказано, то такое сообщение должно удаляться администраторами или при их явном согласии.  1. Запрещено удаление чужих сообщений на странице обсуждения участника самим этим участником (за исключением указанных выше случаев), особенно если сообщения несут административный характер (например, если это предупреждение или сообщение о блокировке).  2. Собственные сообщения могут быть удалены только в случае, если на них не было произведено ответа, на них не было никакой иной реакции или если они нарушают правила.

This may help with solving this problem here, on the English wiki. — BabylonAS (talk | ru.Wiki Admin) 14:51, 23 November 2018 (UTC)

I assume this can be implemented already? --AttemptToCallNil (report bug, view backtrace) 20:02, 27 November 2018 (UTC)

---

The above discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Talk pages with no main page

User-12316399 recently made a change suggesting a new general guideline for talk pages:

Talk pages with no associated main counterpart (due to it being deleted or never existing at all) are eligible for deletion without further notice, unless they contain a significant amount of information that would be better off kept accessible.

Since it was an undiscussed change, I would like to discuss it here first before implementing it, as we have had way to many changes to the rules and guideline pages of late without discussion.

As for my opinion on it, I personally agree that we should add a brief section on talk page notability, but the statement "unless they contain a significant amount of information" is way too vague. I propose instead adding a brief "talk page notability" subsection to in general, since these rules are not relevant to most talk pages. Here are my proposed points:

• Talk pages may exist for any content page, template, module, file, or other main page type that currently exists.
• Talk pages are not allowed if there is no associated main counterpart, except in the following cases:
  • User talk pages may be created even if there is no main user page as they provide a means to communicate with users. This includes user talk pages for IP addresses.
  • If a talk page was created before its main counterpart was deleted, and it contains discussions relevant to other parts of the wiki, it should be archived instead of deleted so the discussions can still be referenced.

–KnightMiner · (t) 18:53, 13 April 2020 (UTC)

Seems reasonable. –Sonicwave ^talk 22:04, 16 April 2020 (UTC)

Interwiki link contradiction

MCW:TALK#Signing contains two contradictory points about interwiki links, the first bullet point disallowing interwiki links and the third allowing (but discouraging) them. Personally I think interwiki links to user and user talk pages is fine, but linking to contributions on a different wiki doesn't really make sense. –Sonicwave ^talk 23:55, 14 August 2020 (UTC)

Sorry, I missed this discussion. I can see how the wording is a bit confusing, but let me explain the intention. You are required a single link to one of your user pages for your signature. The required link must not be interwiki. Additional links are allowed to be interwiki though, though it is discouraged to make interwiki links unrelated to your user. I think a simple rewording on the first bullet point to "This link must not be interwiki." or "The required link must not be interwiki." would be sufficient to clarify that. –KnightMiner · (t) 19:30, 2 October 2020 (UTC)

Remove a guideline

I don't like the guideline "For clarity on the editing screen, it is advised to leave a blank line between comments by separate users". I don't see many editors adding blank lines between comments, and it has a slight but significant increase in line space when the talk page is viewed normally. So I propose that this guideline be abolished. Fadyblok240 (talk) 03:31, 21 November 2020 (UTC)

Allow typo/grammar corrections?

Currently, the guidelines say the following:

Do not edit other users' comments, except to sign unsigned comments or fix formatting.

I am proposing we add typo/grammar correcting to the exception.

The main point of the rule is to not change any of the meaning the commenter intended, but fixing typos/grammar doesn't do that.

For example, if you see a comment saying "when they say that there opposing this", correcting that "there" to "they're" is not changing the commenter's intended meaning. Changing anything that is not correcting a typo or grammar will change the actual meaning of the message instead (which is why that is disallowed).

Thoughts? Dhranios (talk) (Join the wiki videos project!) 13:05, 10 February 2021 (UTC)

 Support--Olivia Capucine Elisabet (talk) 13:11, 10 February 2021 (UTC)

 Support as long as: 1) this is an actual unintentional mistake; 2) fixing the typo does not result in loss of context (so if the typo got a comment, it becomes meaningful and shouldn't be fixed). --AttemptToCallNil (talk) 14:23, 10 February 2021 (UTC)

"so if the typo got a comment" you mean like if somebody reacted to it specifically, or do you mean a reply to the message containing the typo in general?

Agreed on the first point, so no fixing my post's quoted example. :) Dhranios (talk) (Join the wiki videos project!) 14:29, 10 February 2021 (UTC)

"Typo got a comment" = someone reacted the typo specifically. For example, if I wrote "Cat attach the .ods file if asked" instead of "Can attach the .ods file if asked" and someone asked me to attach a cat picture. --AttemptToCallNil (talk) 17:04, 10 February 2021 (UTC)

 Strong Support for this considering I have been reverted a few times in the past for fixing peoples grammar, mostly by TheGreatSpring. I also was recently reverted for trying to add a link to someone's comment that they forgot to add for a block request. I think that editing other comments to fix accidental grammar issues and to add page links when necessary should be allowed. I also support fixing unintentional grammar errors on user pages as well. James Haydon (talk) 14:30, 10 February 2021 (UTC)

I suggest making different topics for the adding links and userpages. Just to keep this discussion about 1 thing only. Dhranios (talk) (Join the wiki videos project!) 14:33, 10 February 2021 (UTC)

Neutral: I feel like fixing others' misspellings, except for links, is unnecessary. However, I would allow users to fix typo and grammar errors in their own comments. Fadyblok240 (talk) 14:51, 10 February 2021 (UTC)

The guidelines never prohibited the latter, it is only about others' comments.

I don't think it is unnecessary, for non-native speakers, a typo or grammar error may "corrupt" (for the lack of a better word) the commenter's intent. I had once where a typo "now" -> "not" inverted the entire meaning of the message. Dhranios (talk) (Join the wiki videos project!) 15:08, 10 February 2021 (UTC)

 Comment: if you are going to allow editing other people's comments to fix typos, add a timelimit to it. I'd rather not see users going through all the old talk pages fixing typos as that has no benefit for the wiki. Maybe you can only edit comments if the latest comment in the discussion is at most 3 months old or a similar time limit. And of course, policy needs to be worded so its clear you should not edit to "fix" non typos, like british english instead of american english.

That said, I am a bit concerned about saying its okay to edit other peoples comments. I don't much like the idea that someone else is editing my words after I write them even for minor changes. Especially as most typos I have seen don't impact readability at all. If it does impact readability, nothing stops you from "replying" with a clarifying comment, and that gives the original commenter a chance to correct their own mistake instead. So, overall neutral, leaning towards against, as I don't see anyones typos causing that big of a problem. KnightMiner ^(t/c) 18:27, 10 February 2021 (UTC)

 Reply Yes I agree with the part about not fixing old comments but I think that after about a month of the mistake being there and/or if its context is missing or it's just generally unreadable, then they should be fixed whether the commenter agrees or not. James Haydon (talk) 18:30, 10 February 2021 (UTC)

Why? If a mistake is sitting there for a month, add a comment saying "KnightMiner's comment has a typo, X should be Y" and you have prevented anything from being unclear without forcing an edit to my words. That has the benefit of if it was not a typo, you are not changing my words and I can more easily reply with a proper correction. Plus, it attaches a name to the person who corrected the typo.

If you don't want to reply, another option is adding template that strikes out original words with the correction/moves the original to a tooltip, and in the tooltip it also says who made the correction. Template could be as simple as {{comment edit|original|fix|~~~~}}. I like this approach as it clearly attributes the correction without needing to view the edit history. I would agree to saying all non-formatting edits must be marked with such a template. KnightMiner ^(t/c) 18:41, 10 February 2021 (UTC)

Okay that could work, if only we could make a button that placed that template automatically like the unsigned template. James Haydon (talk) 18:45, 10 February 2021 (UTC)

No template needed, just use ; edited ~~~~~ after the signature. 04:27, 2 March 2021 (UTC)

So, has a final solution been decided yet? James Haydon (talk) 19:33, 2 March 2021 (UTC)

Regarding no template being needed, you missed my point entirely. The point is to make it clear *exactly what was changed*, not that it was changed. If someone changes my words, I want them to clearly mark what they changed and ideally why. KnightMiner ^(t/c) 19:48, 2 March 2021 (UTC)

KnightMiner I created {{Typo}}, if this is used, do you think the proposal is ok? (Not exactly sure how I feel about adding the whole signature of the corrector, so I suggest just adding the name.) Dhranios (talk) (Join the wiki videos project!) 11:07, 20 March 2021 (UTC)

Something like that would be sufficient, yes. I agree, probably do not need to include the full signature in there, though maybe if we use a title instead of a sup we can fit add that info.

To be consistent with other talk page templates, it should probably be substed, current formatting is not bad for that (though the double sup is weird). KnightMiner ^(t/c) 04:16, 22 March 2021 (UTC)

 Oppose – having a template for this just to make it work seems a bit cumbersome, and I agree with KnightMiner's original comment otherwise. I feel like this has the potential to become excessive, like people blanking old userpages just for the sake of it. –Sonicwave ^talk 04:27, 22 March 2021 (UTC)

Revisit removal of comments from user's own talk page

I saw this edit on a user's talk page today and it bothered me. Technically the edit was correct according to our talk page guidelines and the discussion above. But these guidelines seem somewhat draconian as applied to a user's own talk page. I'd like to revisit this.

Considering the breadth and complexity of the rules on Wikipedia, the Wikipedia guideline WP:OWNTALK is surprisingly simple and laid-back regarding removing stuff from one's own talk page:

“

Although archiving is preferred, users may freely remove comments from their own talk pages. Users may also remove some content in archiving. The removal of a warning is taken as evidence that the warning has been read by the user. This specifically includes both registered and unregistered users. Some new users believe they can hide critical comments by deleting them. This is not true: Such comments can always be retrieved from the page history. There are certain types of notices that users may not remove from their own talk pages, such as declined unblock requests and speedy deletion tags...

„

So it basically considers removal of a comment as an acknowledgment that a comment has been seen, and prohibits removal of certain administrative notices.

In that light, I suggest we add #6 to the list of exceptions for user talk pages, or create a subsection with guidelines specific to user talk pages, similar to the Wikipedia guidelines.

People coming over here from Wikipedia would expect a somewhat consistent experience, too. There's an expectation that your user page and your user talk page is a space on the site that you can manage the best way you see fit. Amatulic (talk) 17:44, 26 June 2021 (UTC)

 Strong support with re-adding the exception to rule six. BDJP ^(t|c) 19:03, 26 June 2021 (UTC)

Neutral to weak support for readding #6 as an exception. --AttemptToCallNil (talk) 12:03, 27 June 2021 (UTC)

I don't think we should simply re-add #6 as an exception. There should be limits. Administrative warnings and block notices while a user is blocked shouldn't be removed in my opinion, but non-blocked users should be free to manage their talk pages as they see fit. Amatulic (talk) 15:07, 27 June 2021 (UTC)

I propose appending a new sentence to the final paragraph: "Users are also exempt from rule 6 with respect to their own talk pages unless the user is blocked, in which case any administrative notices should be retained on the user talk page for the duration of the block." Amatulic (talk) 15:15, 27 June 2021 (UTC)

I understand your concern and agree with it. Your proposed sentence sounds fine. --AttemptToCallNil (talk) 02:24, 28 June 2021 (UTC)