Jump to content

Wikipedia talk:Talk page guidelines/Archive 13

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 10Archive 11Archive 12Archive 13Archive 14Archive 15Archive 16

Comments by blocked sock puppets

Statement of issue

Bold edit and revert
Since Dec 2015, the TPG has talked about support/oppose comments by blocked socks. I believe the section needs work and here's why.

History
This section was originally added by NE Ent (talk · contribs) in this Dec 5 2015 edit following a discussion at the Administrator's noticeboard earlier that month. NewsAndEventsGuy (talk) 11:23, 27 May 2018 (UTC)

Not-Votes and Discussion

  • Support (1) Unless I missed it, the original discussion did not distinguish between not-vote (oppose/support) type comments by blocked sockpuppets and any other comments by blocked sockpuppets. (2) Seems like actual practice in my experience. (3) Creating an artificial distinction between not-votes and other comments by blocked socks provides undesirable ways to game the system which we should all oppose. (4) pet peeve, When eds lack evidence and/or logic for why an edit is detrimental I wish they would just say "Reverted because I Want to see you jump through hoops first".... @Thinker78, can you articulate a single reason why the TPG should treat not-vote comments by blocked socks differently than other comments by blocked socks? NewsAndEventsGuy (talk) 11:23, 27 May 2018 (UTC)
    • My understanding is that this guideline is just for "support" or "oppose" comments probably to avoid undue weight to an issue supported or opposed by different sucks and that it does not apply to other comments. That is why I reverted. Saying this, then this guideline should be expanded to include the same action to recommendations by socks in article for deletion discussions. Other comments should be treated in a case by case basis, because if the sock is just answering a question like "how do I properly format an edit?", I don't see why the comment should be struck if it has a legitimate answer, provided that they made the comment before getting blocked or banned from making said comment. Thinker78 (talk) 16:47, 27 May 2018 (UTC) Edited 17:16, 27 May 2018 (UTC)
      • ? The text I added says "...sock puppets of users editing in violation of a block or ban...". If they are editing in violation of a block or ban, they are editing in violation of a block or ban. — Rhododendrites talk \\ 17:35, 27 May 2018 (UTC)
        • Thinker78, this is the best and most appropriate typo I have seen in a long time: ...an issue supported or opposed by different sucks... --MelanieN (talk) 21:49, 27 May 2018 (UTC)
  • Support - Beat me to it. Thanks for posting this, NAEG (with a good reminder to set up email notifications for my singular doppelganger account :) ). I made the change following a discussion on MelanieN's talk page (pinging participants: @Doug Weller, Mandruss, Objective3000, Atsme, and Winkelvi:). I had gone through and started striking the comments of a particularly active sock of a community banned editor. Upon reading this page and WP:SOCKSTRIKE (which I would propose to change if this change is endorsed), I found myself wondering whether I should avoid striking comments in active discussions that aren't a !vote. I wound up unstriking non-!votes (!!votes, if you will) and leaving a note in the relevant sections, which seemed perhaps less effective. It seems that it is indeed commonly accepted to strike comments in active discussions, and that makes a lot of sense to me if the purpose is to discourage abuse and disruption of Wikipedia by sock puppetry. — Rhododendrites talk \\ 16:34, 27 May 2018 (UTC)
  • Support. Yep. And thanks for the ping, Rhododendrites. -- ψλ ● ✉ ✓ 16:39, 27 May 2018 (UTC)
  • Support - I think there could be some discretion. If the sock is heavily pushing a point (not unlikely given it’s a block evasion), then the comments are sorta !votes and should be stricken. If the sock started the section, and is arguing a point where all other editors are opposed, just hat the section with a note it was a sock. Strike anything uncivil. If the edits are innocuous or unlikely to sway, and there are rather a lot of them, meh. O3000 (talk) 16:50, 27 May 2018 (UTC)
  • Support - Responding to Thinker78 above, blocked socks are not allowed to answer a question like "how do I properly format an edit?" They are blocked, and that does not mean "no edits unless you have something useful to say". The only reason not to remove everything outright is because it would damage context in many cases. There is little benefit to discretion in this case, and it would add an unwarranted degree of complexity. Thanks for caring about maintaining PAGs-to-practice agreement, that is not done nearly enough. ―Mandruss ☎ 16:59, 27 May 2018 (UTC)
  • Support - but that could end-up being an awful lot of comments depending on when the sock is exposed. Also, is there a way the user name be stamped SOCK over the top of it instead of just a line through showing they're blocked? That would cover those comments we overlook (and maybe save some work striking). Atsme📞📧 17:38, 27 May 2018 (UTC)
    • Not without a software change, which generally requires a phab (WP:PHAB) request, which generally requires a consensus at a place like WP:VPT. Even then there's no guarantee. ―Mandruss ☎ 17:42, 27 May 2018 (UTC)
    • It could be a lot of comments, but since it only applies to active discussions, it shouldn't typically be too many to handle, I think. At least not often. It's a good question, though. I should point out that the line through the name is also a preference that's not enabled by default, I don't think (or at least wasn't for me). I don't know how that script works, but I imagine there's something it could just as easily look to see if the userpage is categorized as a sock puppet and reformat accordingly. That, too, would be something unlikely to be enabled by default, though. — Rhododendrites talk \\ 17:50, 27 May 2018 (UTC)
      @Mandruss:It might be possible using JavaScript, in which case it could be a gadget. No MediaWiki software change is necessary for new gadgets, and so we don't need a phab ticket either. It's not possible using CSS alone. --Redrose64 🌹 (talk) 10:59, 29 May 2018 (UTC)
  • Support It's work that I resent but I think we need to do it. I'll admit that it's something I generally do. I also remove unanswered posts. Most socks would love to have their edits untouched for others to see - we shouldn't let them have that victory. Doug Weller talk 18:23, 27 May 2018 (UTC)
    • I think in many cases, ignoring comments from sockpuppets is a big loss for them: people get amped up waiting for responses, and are let down with the feeling that everyone is treating them as irrelevant. But I'll also agree that remove and ignore is the best approach to deny recognition and thereby reduce incentive to violate a ban. isaacl (talk) 21:56, 27 May 2018 (UTC)
  • Support It seems that Thinker78 misunderstands. This is not a situation where editor A is blocked, and then we execute a damnatio memoriae to strike all their prior comments. Instead, this is a case where editor A is blocked, creates sock B to evade the block, and then continues editing. We strike all of sock B's comments when we determine the socking, whether it was a !vote at an RfC/RfA, etc. I'm sure you can find plenty of talk page contributions from our blocked/banned editors A. The comments from socks B get removed or striken anywhere. Chris Troutman (talk) 18:36, 27 May 2018 (UTC)
  • (Just a note that this question, and the suggested modification of our wording, arose from discussion about a case of a particularly prolific sock, who survived for six months and made more than 500 edits before getting caught. During that time he participated in multiple talk page discussions, and started at least one discussion which is still ongoing.) I support the change in wording proposed by Rhododendrites, which is a model of clarity and concision. My more wordy opinion: I would like to see as our default recommendation (allowing plenty of room for discretion since circumstances vary) that sock comments in live discussions are struck, so that participants in the discussion will know they are from the sock and can treat them accordingly. I favor striking all their comments, as opposed to merely adding a note somewhere in the discussion, because striking makes it easy for the reader to identify which comments are from the sock. This refers to comments in discussions that are still live and ongoing; as stated, no need to bother striking comments in closed discussions. It is within discretion to simply delete comments which have not been replied to. It is also within discretion to hat a discussion that the sock started, but generally this should only be done if the sock’s viewpoint was not supported by others. --MelanieN (talk) 21:46, 27 May 2018 (UTC)
    That's a lot of ifs and unlesses, and I wonder whether that much complexity is really needed. Please develop a flowchart or decision table to make the decision process accessible to ordinary editors, unless you propose to restrict the handling to admins. ―Mandruss ☎ 08:05, 28 May 2018 (UTC)
  • Support to avoid giving false legitimacy to discreet block evaders such as the case that prompted this edit. — JFG talk 11:58, 28 May 2018 (UTC)
  • Comment - With 10 in support and no opposes (unless you count NE Ent's comments below?) after 11 days, with nothing for the past several, it seems this should be reinstated. Objections? — Rhododendrites talk \\ 14:03, 7 June 2018 (UTC)
  • And with another couple weeks having gone by with no additional comments, I've gone ahead and restored it. I've used the original wording, since that was the basis for this thread. The subthread below didn't really get much by way of responses (aside from my own), so I didn't factor it in. That doesn't mean elements of it cannot be boldly added and/or discussed further, of course. — Rhododendrites talk \\ 15:51, 22 June 2018 (UTC)

Discussion

  • The edit summary is claiming both boldness and (user) talk page consensus. You really can't have it both ways.
If one can put oneself in the perspective of a non-Wikipedian normal human being ... voting support in a section labeled "Non-voting" is fairly lame. See WP:OFCOURSE. See also these very Talk Page Guidelines, which suggest Be welcoming to newcomers
The existing

Removing or striking through "support" or "oppose" comments of editors subsequently blocked as socks. Comments with no replies may simply be removed with an appropriate edit summary. Striking through with a short explanation immediately after the stricken text is done when other editors have replied to the comments. e.g. Support per nom. (Striking !vote by blocked sock.)

is much better than

Removing or striking through comments made by blocked sock puppets of users editing in violation of a block or ban. Comments made by a sock with no replies may simply be removed with an appropriate edit summary. If comments are part of an active discussion, they should be struck instead of removed, along with a short explanation following the stricken text or at the bottom of the thread. There is not typically a need to strike comments in discussions that have been closed or archived.

because:
  1. the former uses less words
  2. doesn't use equivocal language like There is not typically a need ...
  3. "Users blocked as sockpuppets" (emphasis mine) makes it clear editors can't just go to town on editors because they think/suspect another editor is a sockpuppet.
Remember,
  1. Active Wikipedians know the rules -- actually they know existing practices which the written rules typically lag.
  2. Newcomers who are trying to do the right thing are better helped by simple direct statements.
  3. Any ambiguity in policy pages becomes fodder to be argued on community discussion boards like WP:ANI
so if you wanna change the wording to be much inclusive, simply make it

Removing or striking through comments of editors subsequently blocked as socks. Comments with no replies may simply be removed with an appropriate edit summary. Striking through with a short explanation immediately after the stricken text is done when other editors have replied to the comments. e.g. Support per nom. (Striking !vote by blocked sock.)

NE Ent 00:56, 29 May 2018 (UTC)

Re the offtopic housekeeping remark in your second paragraph criticizing the section headings... The section heading is not "Nonvoting" but rather NOTVOTE as in WP:NOTVOTE; as a general rule I never link in seciton headings. Your mileage may vary. NewsAndEventsGuy (talk) 13:20, 29 May 2018 (UTC)
I find the presentation of this section pretty confusing. It seems like you're putting the proposal as well as an additional proposal below the discussion (whatever the heading may be) of the proposal. I've tried to tidy it up a bit by turning the blocks of quoted and (proposed?) text into quotes.
Coming back to what it says, though, it looks like the primary differences are that you've removed "in violation of a block or ban" (which seems problematic, since edits made by a sock before the person is blocked/banned is not typically treated the same way -- perhaps it was a legitimate use of a sock until it was used inappropriately), adding the example at the end (fine by me), removing the option of a comment at the bottom of a thread (I don't think a comment after every strikethrough in a thread is necessary), and removing the bit about old discussions (this still seems sensible to me, but I would also be ok leaving in the "active discussions" qualification and elaborating elsewhere, such as WP:SOCKSTRIKE. Regardless, most of these are not huge changes. I think that once we see there is consensus for this change in general, it would be less controversial (if this turns out to be controversial at all) to add, say, the example, or to put some of it off to the essay, or to copyedit, etc. — Rhododendrites talk \\ 13:36, 29 May 2018 (UTC)

permanently banned users

  • Question: Should we apply the same standard to permanently banned users? (Would best be done via software marking their signature, obviously.) — JFG talk 11:58, 28 May 2018 (UTC)
  • For comments after the ban, support this too (I already cast a not-vote in the prior section) NewsAndEventsGuy (talk) 00:33, 29 May 2018 (UTC)
    • No. Why? What's "permanently banned," anyway? Purpose of blocking / banning is minimize disruption, not put badges o' shame on folks.(We have social media and Reddit for that). NE Ent 00:59, 29 May 2018 (UTC)
Thanks for asking, the moment's pause inspired me to tweak my not-vote from Support to Support for comments made post-banning. The reason to leave comments pre-banning is because those are made when the ed is in good standing. The reason to apply the rule to all comments by sockpuppets and any comments post-banning by banned eds is that they are made in violation of our community standards of welcome participation... to leave them as if they speak with the full privilege of full consideration by the rest of the collaborative community is to undermine the atmosphere of consensus and civility and NPOV etc that make this place possible. NewsAndEventsGuy (talk) 10:51, 29 May 2018 (UTC)
And WP:Community ban is usually permanent, absent some overwhelming show of contrition and clue-gaining. So are most administrative indefs of socks and nothing-but-vandalism vandals.  — SMcCandlish ☏ ¢ 😼  17:03, 22 June 2018 (UTC)

Use of colored text on talk pages

Should this be mentioned in the section on emphasis? Doug Weller talk 12:23, 3 June 2018 (UTC)

I have on v-e-r-y rare occasion used colored text; no one ever complained. Is this a problem somewhere? NewsAndEventsGuy (talk) 12:28, 3 June 2018 (UTC)
Excuse me, nowadays we say "African-American text". EEng 12:39, 3 June 2018 (UTC)
Like allcaps, it can distract. I saw it today used instead of quotation marks, that was pretty confusing at first. Doug Weller talk 12:54, 3 June 2018 (UTC)
Doug - are you proposing that it should be used sparingly and are you also including highlighting? I try to use tables with colored text to show comparisons of old text vs proposed text, and also occassionally use highlighting, etc. so it has a useful purpose. Atsme📞📧 12:58, 3 June 2018 (UTC)
Like Doug, I have on rare occasion been overwhelmed with excessive use of color. I think the other eds were trying to make it MORE understandable, and I think in those rare times they failed. But personally I see this so seldom I wonder it writing rules instead of dealing with it ad hoc might produce WP:CREEP more than benefit? Open mind, just asking the question about extent of problem..... NewsAndEventsGuy (talk) 16:34, 3 June 2018 (UTC)
Color has issues with respect to accessibility; though talk pages tend to be a dog's breakfast in that regard anyway. Really, the advice at WP:COLOR is as useful on talk pages as it is anywhere else.
  • Ensure that color is not the only method used to convey important information. Especially, do not use colored text or background unless its status is also indicated using another method.... Otherwise, blind users or readers accessing Wikipedia through a printout or device without a color screen will not receive that information.
  • Some readers of Wikipedia are partially or fully color-blind....
Heck, screen-dimming apps that add a deep-red filter to one's display in the evening are getting to be pretty widespread, and those are murder on color rendition and contrast.
Fortunately, adding colored text is sufficiently inconvenient to do that most editors choose simpler (and usually better) ways to draw attention to text. I'm not sure that we need to add specific CREEP to this guideline, but I welcome input from editors and users who have more experience in dealing with accessibility issues. TenOfAllTrades(talk) 19:57, 3 June 2018 (UTC)
Gold star for considering those with screenreaders, colorblindness, and so on, TenOfAllTrades. Eventually I may learn to think of others like that, also. NewsAndEventsGuy (talk) 21:43, 3 June 2018 (UTC)
  • FWIW I find myself distracted by highlighting/background colors much more than by colored text. Especially highlighting that extends outside of a typical line size. Would definitely support a prohibition on that, but it extends beyond this discussion a bit, I suppose. — Rhododendrites talk \\ 15:53, 22 June 2018 (UTC)
  • Here's a great example of what to not do (even aside from the "interleaving" thing; the editor in question has been pointed to that rule): Talk:Ellipsis#"Save_As..."_style (page down to the "sea of crimson"). In general, I would agree with "the advice at WP:COLOR is as useful on talk pages as it is anywhere else"; we need not repeat much of it here, but we should at least point to it and say something like "the advice at WP:COLOR is as useful on talk pages as it is anywhere else". :-)  — SMcCandlish ☏ ¢ 😼  17:11, 22 June 2018 (UTC)

LISTGAPS mess avoidance

I thought we'd resolved over a year go to help curtail WP:LISTGAPS problems and other "list manglement", by instructing people, when making replies, that (absent a good reason not to) the thing to do is to copy the list markup of what they're replying to and add their indent or bullet or number-sign after it. E.g., if you encounter this: 

* '''Delete''' – NukeEmAll 16:01, 22 June 2018 (UTC)
*: By why? – TheQuestioner 17:02, 22 June 2018 (UTC)
*:: Because:
*::# It's non-notable.
*::# It's clearly promotional. – NukeEmAll 18:03, 22 June 2018 (UTC)
*::#* I'm not sure I buy that. – TheQuestioner 19:04, 22 June 2018 (UTC)

And you want to reply to the last item, add your : or * after TheQuestioner's *::*, thus: 

*::#** NukeEmAll's rationale seems correct to me. – YourNameHere 20:05, 22 June 2018 (UTC)

If you want to reply to NukeEmAll's original post, use their * followed by your bullet or indent: 

*: Thanks for clarifying, NukeEmAll. I was leaning "Keep", but those are good reasons. – YourNameHere 20:05, 22 June 2018 (UTC)

There's probably an ideal and succinct way to put it, and having a sentence of advice on this (with or without an example) would be a great boon to accessibility, orderly talk pages, and more – people who create F'ed up lists in talk pages because they don't know better also do it in articles, where the accessibility and bad rendering issues are more important. It's amazing how many long-term editors still do not understand this basic principle.  — SMcCandlish ☏ ¢ 😼  16:55, 22 June 2018 (UTC)

Yes, I still see (and occasionally fix) such problems. XFD discussions are usually the worst places in this regard. --Redrose64 🌹 (talk) 22:22, 22 June 2018 (UTC)
Pretty much zero of my editing days at WP do not encounter bad markup of this sort, often 20+ times per session.  — SMcCandlish ☏ ¢ 😼  14:02, 24 June 2018 (UTC)

"Personalities" (word in section Focus on Content)

I see no reason to have the unneeded word included in what we should concentrate on. In disputes, it is bound to cause confusion and endless discussion as to the meaning of the word "personality". I hope there is/can be consensus for removing it. --SergeWoodzing (talk) 14:00, 25 June 2018 (UTC)

  • Good callNewsAndEventsGuy (talk) 14:14, 26 June 2018 (UTC)
  • I have to disagree on this one, though maybe "personalities" isn't the right word. No qualifier at all makes it too general a statement; addressing editor behavior and viewpoint is often necessary (though, yes, it can also frequently go too far). This page should reflect the better side of actual practice, not try to live in a fantasy land.  — SMcCandlish ☏ ¢ 😼  07:41, 27 June 2018 (UTC)
It seems we do agree that "personalities" in this context should go. Sure, sometimes I use the second person "you" in talk pages, and I think my use is generally appropriate. But its a subjective thing, and its a hopeless task to try to articulate a broad unambiguous consensus on this. Those who leap for the jugular at the first instance of "you", regardless of context, are as problematic as those who run others down with a nonstop you-you-you-you-you-you. This seems like a good case of having to trust one another to figure out where the boundaries are on the fly. NewsAndEventsGuy (talk) 12:43, 27 June 2018 (UTC)
Yeah, well, someone like you would say that. EEng 13:19, 27 June 2018 (UTC)
>:) NewsAndEventsGuy (talk) 15:18, 27 June 2018 (UTC)
Seriously, though, that hits the nail: If we could trust editors to do that, much of this page would not need to exist. Pages like this are very frequently cited in noticeboard actions with real potential consequences, so we can't open up a whole new wikilawyering and systemgaming loophole. There may be more than one way to close it, but just leaving it reduced to "rather than on the editors" isn't sufficient. It either needs a qualifier, or a link to something, e.g. "rather than on the editors" so that it can't rationally be interpreted as "Jimbob92 said 'The edit you made' instead of just 'the edit', so I'm gonna go to ANI". We have too much of this going on already, too much "WP:CIVIL means no one can criticize what I do or say unless they use contorted circumlocutions".  — SMcCandlish ☏ ¢ 😼  19:42, 27 June 2018 (UTC)
If your concern is that you think the current text implies you can never talk about other editors, what it says is to "focus" on content, not editors. That leaves room for the occasional comment on behavior where needed. Or do I misapprehend your concern? EEng 20:57, 27 June 2018 (UTC)
Basically, yes. I'm not suggesting that, in a careful reading, it shouldn't be interpreted the way you want it to be, but rather than we already know this kind of wording isn't read carefully or understood clearly, and given the purpose of a behavioral guideline page, we need to take steps to avoid (often willful) misinterpretation. Part of it is this: it doesn't matter whether people could successfully game this; we just know that they would try, and that this would be a productivity drain on editors who aren't being asshats.  — SMcCandlish ☏ ¢ 😼  22:22, 27 June 2018 (UTC)
It's easy to raise vague concerns... "personalities" isn't the right word, we've agreed about that. Can you suggest an improvement? NewsAndEventsGuy (talk) 02:11, 28 June 2018 (UTC)
Already did: use a link instead of additional wording: "rather than on the editors".  — SMcCandlish ☏ ¢ 😼  05:35, 28 June 2018 (UTC)
Sorry, overlooked the blue link to WP:Casting aspersions. I've long thought that concept should be more than an additional "principle" espoused by the Arbs such as described in that page, but so far, it is at best implied in our "regular" rules. The page you've linked provides examples of when it becomes explicitly layered on top of everything else in an ARB ruling. If we can establish that principle in the day-to-day (non ARB ruling) WP:Policies and guidelines that would be a good thing. It would equally apply everywhere and it would be equally explicit everywhere. After that happens then I would agree its probably a reasonable basis for rephrasing this point in the TPG. Until then I'm opposed to basing the TPG off of arb-added "specialty" layers of procedure. I wonder where, in all our day-to-day policies, it would fit best? NewsAndEventsGuy (talk) 11:30, 28 June 2018 (UTC)

Those of us (and only those of us?) who for years have tried very hard never (never) to address or mention another user on article talk pages have fully understood how much more delightful Wikipedia work is then, and how much more delightful it would be for all of us (all of us) if everybody did that. It can (can) be done, and it is really great. The magic that it brings, in concentrating only on article content (which I think article talk pages are all about), is almost unbelievable. --SergeWoodzing (talk) 16:07, 28 June 2018 (UTC)

I guess we could link to Wikipedia:Civility. Anyway, the idea is to resolved the gameability while also retaining the concision.  — SMcCandlish ☏ ¢ 😼  17:42, 28 June 2018 (UTC)

When originally added, it read

'''[[WP:NPA|Comment on content, not on the contributor]]''': Keep the discussions focused upon the topic of the talk page, rather than on the personalities of the editors contributing to the talk page.

With slight tweaks the current text reads

'''Comment [[WP:FOC|on content]], not [[Wikipedia:No personal attacks|on the contributor]]''': Keep the discussions focused upon the topic of the talk page, rather than on the editors participating.

The original was added a long time ago in this edit with an edit summary saying it was supposed to be flip side of NPA. Both the original and the current link to WP:NPA in the bold part of the paragraph. Proposal - we could just repeat that link at the end, like this

'''Comment [[WP:FOC|on content]], not [[Wikipedia:No personal attacks|on the contributor]]''': Keep the discussions focused upon the topic of the talk page, rather than [[Wikipedia:No personal attacks|on the editors participating]].

NewsAndEventsGuy (talk) 18:21, 28 June 2018 (UTC)

Would a WP:NPA link be overly narrow?  — SMcCandlish ☏ ¢ 😼  18:55, 28 June 2018 (UTC)
Wait, no, that wasn't added a long time ago, at least not exactly. I edited it just the other day I'm sure. EEng 21:40, 28 June 2018 (UTC)
The version with "personalities of" had been stable in this page since the introduction of the line in 2009.  — SMcCandlish ☏ ¢ 😼  22:57, 28 June 2018 (UTC)
OK, Newsie has modified his earlier post to correct the longstanding text, so my comment no longer applies. EEng 06:09, 29 June 2018 (UTC)

I am very pleased with the current wording, which I think says enough to anyone in doubt as to what goes. It's bound to be very helpful now in steering away from habitual personalization of so much of our article talk. --SergeWoodzing (talk) 15:53, 29 June 2018 (UTC)

Same here. My proposal above was intended to satisfy another ed who thought it overly broad, and then thought the change I suggested is too narrow. That suits me because my preferene is also to leave it as is. NewsAndEventsGuy (talk) 16:43, 29 June 2018 (UTC)
I asked if it might be too narrow (versus, say, WP:CIVIL).  — SMcCandlish ☏ ¢ 😼  18:04, 29 June 2018 (UTC)
I have no problem changing the current link to NPA at the beginning of the current text to CIVIL, and adding another (new) link to CIVIL at the end. CIVIL in the nutshell bubble encompasses NPA but goes further in a positive direction. So changing the focus from NPA to CIVIL at the beginning is a good idea. A separate question is whether we should add a wikilink to the end of the mini-paragraph. I don't care, but I would like to make sure we don't create confusion over which standard applies. The simplest way to do that is to repeat at the end whichever link we use at the beginning. NewsAndEventsGuy (talk) 19:27, 29 June 2018 (UTC)
Civility covers more than just "comment on contributor", though. Bah. I guess just leave it as is, since you like it that way, and SergeWoodzing does, and no one seems to care about the potential-lawyering point I was raising. Maybe I'm just "terriblizing".  — SMcCandlish ☏ ¢ 😼  20:11, 29 June 2018 (UTC)
Points for trying. Wish more folks would make the effort. NewsAndEventsGuy (talk) 00:02, 30 June 2018 (UTC)
I'm very alert for gaming/lawyering loopholes. I've been editing policy here for a long time, and was a professional policy analyst in meatspace, as well as a communications director, plus a coder, and I have an anthropology degree. It's a weird-ass background, but it gives me a very procedural and stepwise approach to this sort of thing, filtered through a human reactions and foibles lens. I kind of run scenario trees in my head on all this material and how it interrelates with other material, and what rationales and mis-rationales people offer, under what circumstances, etc., etc. I'm probably not "the Best" at this, but I'm pretty good at it. :-)  — SMcCandlish ☏ ¢ 😼  06:17, 1 July 2018 (UTC)
I looked it over again, in full context, and ended up linking it to WP:Civility, because it's otherwise just not clear in the context (to someone new to this site and what goes on here and in what interaction mode). It's also the first hint on the page about anything to do with civility/NPA and related concepts, so it's a good place to link anyway.  — SMcCandlish ☏ ¢ 😼  06:13, 1 July 2018 (UTC)
I too have looked again and followed the link, which I feel unnecessarily complicates the matter now. Must we have a link?. Editors who habitually (love to?) argue with others on article talk pages, "you did this, you did that, that's wrong, you're being ridiculous etc etc etc" rather than just sticking to the subject matter, will now be able to use the excuse/assertion/claim that they are not being "uncivil" and that in turn can lead to endless disacussions and conflicts. The wording is clear enough, I think, as " ... rather than on the editors participating." Is it really necessary to link there at all? Why must we factor what is civil, or uncivil, or maybe uncivil, or maybe not, into it? We should all just avoid mentioning or directing comments at each other on article talk pages, where those habits hardly ever are needed or constructive, and where not doing so at all is like Heaven itself. --SergeWoodzing (talk) 15:29, 1 July 2018 (UTC)
Room should be allowed for the occassional humor, a thanks/congratulations, the respectful little things that build a community, without losing the vision that we're making an encyclopedia rather than doing social networking. NewsAndEventsGuy (talk) 11:42, 2 July 2018 (UTC)
The word "focused" in there should allow for that, and WP:AGF is more appropriate that building a presumed risk of personal attacks into the language. --SergeWoodzing (talk) 17:13, 2 July 2018 (UTC)
But "you did this, you did that, that's wrong, you're being ridiculous etc etc etc" is uncivil. It does not require yelling "FUCK YOU ASSHOLE" to be uncivil. Treating others like idiots or crazies and making everything a personality struggle, poisoning the ability to collegially collaborate, certainly qualifies.  — SMcCandlish ☏ ¢ 😼  17:55, 2 July 2018 (UTC)

With recent tweaks, it now (this version) links to both CIVILITY and ASSUME GOOD FAITH, and reads

'''Comment [[Wikipedia:Dispute resolution#Focus on content|on content]], not [[WP:Civility|on the contributor]]''': Keep the discussions focused on the topic of the talk page, rather than [[WP:Assume good faith|on the editors]] participating.

NewsAndEventsGuy (talk) 18:25, 2 July 2018 (UTC)

This might be a random time to bring this up, but I've never been happy with such easter egg links. Why, for example, does on content link to WP:Dispute resolution in particular? I'd much rather just say what we need to say, and follow with explicit links e.g.
'''Comment on content, not on the contributor''': Keep the discussions focused on the topic of the talk page, rather than on the editors participating. For more information, see [[WP:Dispute resolution#Focus on content]], [[WP:Civility]], and [[WP:Assume good faith]].
EEng 18:46, 2 July 2018 (UTC)

I also dislike EGGs as Eeng said above. Proposed rewrite

Focus on content instead of other editors: With rare exceptions, discussion at each talk page should always support the purpose of the associated page. For example, at article talk pages, limit discussion to improving the article by discussing sources, how they can best be used, and ideas for style and layout. When there is a disagreement, never address other editors or talk about other editors unless you are making a good faith and civil attempt to resolve the dispute, or are making a good faith attempt to seek help from editors with particular roles or privileges (e.g., WP:Administrators).

Thoughts? (self struck) NewsAndEventsGuy (talk) 23:02, 2 July 2018 (UTC)

Too much and too many links to same places, I think. I like EEng's suggestion, with no links in the guideline itself and with minimal risk of all kinds or arguments over interpretations and semantics. We must be careful to avoid more confrontation and not to create an extended battleground. People who are habitually uncivil (and there are many of us very active every day) are prone to argue endlessly and vindictively to try to prove they aren't, and they (much too) often get away with that because nobody will orka take them on. Let's keep that in mind, especially here! --SergeWoodzing (talk) 12:59, 3 July 2018 (UTC)
Crap. Of course your is better EEng... I must have been in a hurry and only read the EGG part, not noticing you offered an alternative. Thanks for calling it to my attention SergeWoodzing.NewsAndEventsGuy (talk) 14:17, 3 July 2018 (UTC)
I am filled with a warm inner glow of validation. You have my permission to continue expressing praise and admiration. EEng 15:11, 3 July 2018 (UTC)
Forget that bucko... Focus on content, eh? NewsAndEventsGuy (talk) 19:00, 3 July 2018 (UTC)
"never address other editors" in my dialect implies "Do not talk with other editors, or acknowledge their presence, and definitely not by name." EGG links are perfectly fine in policypage material; people know they are not navigating around in a million+ pages of it, and that something relevant to the contextual meaning of the linked phrase will be elucidated in the principles at the page they're directed toward. This is vastly preferable to explicit "See ..." cross-references, because the main complaint about WP:P&G material is there's just too much of it and it rambles/blather. Don't give people more TL;DR to complain about (except on talk pages; I consider it a gods-given right, demmit!). Anyway, I'll sit on the rest of it a while. Getting tired, and y'alls may still be massaging your drafts. All I cared about was not losing some kind of a clear indicating that talking about other editors and their edits, choices, arguments etc. is not forbidden or actionable – it has to objectionable talk about them, or a dwelling on them – because we already get too many false reports of alleged civility/NPA/HARASS breaches that are nothing of the sort.  — SMcCandlish ☏ ¢ 😼  07:31, 4 July 2018 (UTC)

Template:Album ratings

Is there any page where I can find all known rating publishers like AllMusic? I'm interested in these non-english publishers especially. Eurohunter (talk) 21:04, 28 July 2018 (UTC)

@Eurohunter: this is the talk page for discussing improvements to the page Wikipedia:Talk page guidelines. I suggest that you try WT:ALBUMS. --Redrose64 🌹 (talk) 22:10, 28 July 2018 (UTC)
I don't know how I entered here but I wanted to add thread to Wikipedia talk:WikiProject Albums. Thanks for notification, it's moved now. Eurohunter (talk) 22:13, 28 July 2018 (UTC)

Formatting

@Alsee: {{Shortcut}} broke the list formatting because it contains line breaks. I've removed the line breaks from Module:Shortcut, so either type of list should be fine now (I think). Jc86035 (talk) 17:47, 2 August 2018 (UTC)

Jc86035 I had pretty much figured out what was going on, but then I got confused as heck when I viewed my edit in page-history and suddenly the problem was gone! Hahaha. Looks like it's all solved. Thanx. Alsee (talk) 18:11, 2 August 2018 (UTC)

Footnotes in talk and Template:Reflist-talk

Once or twice a month, plus/minus, I encounter a topic in an article's Talk page that is footnoted. The footnote is at the page bottom, though the section footnoted is mid-point in the article. I asked about this a couple of months ago and got the right fix on my specific request, inserting: {Reflist-talk} (with double braces -- one brace omitted for discussion's sake).

This is a minor yet regular Talk pages problem and might be worthy of added instructions or even a template adjustment. Probably this is more a problem for us mid-level editors, conscientious enough to cite our references, ignorant enough to not stick them in place. I'll strive to fix what I find from here out. But, if any of you highly capable Wikipedians can figure out where one might insert a fix regarding this... .

Thanks, GeeBee60 (talk) 15:24, 7 August 2018 (UTC)

That's a good idea. I deal with this often in science and climate pages. Bold attempt How does that look? NewsAndEventsGuy (talk) 16:21, 7 August 2018 (UTC)
To quote a template without invoking it, use the {{t}} template, for example you can talk about {{reflist-talk}} this way; I changed it in the section header. Another useful template is {{sources-talk}} which produces a collapsed list of sources, that is less distracting to the conversation when many sources are cited. — JFG talk 17:42, 7 August 2018 (UTC)
Thanks I didn't know about either of those.NewsAndEventsGuy (talk) 18:07, 7 August 2018 (UTC)
References are displayed at the next <references /> tag in the page, or at the bottom of the page if there is no <references /> tag after the point where the ref is used. Templates like {{reflist}} and {{reflist-talk}} contain a <references /> tag with some extra styling. So since the only issue is the absence of such a tag or template, there is really nothing that can be fixed. --Redrose64 🌹 (talk) 19:54, 7 August 2018 (UTC)
I pictured one of two fixes: Either modify the talk template, which you convince me (by the above) may be impractical. OR, append the talk information page so that what you have said here is more readily known there. Many people do not know that footnotes on a Talkpage are (ought to be) approached differently than footnotes in an Article.
Anyway thanks very much, Glen Buschmann

Offensive Heading?

Am I Wrong in Finding This an Offensive Heading to Be in a Talk Section? Or Anywhere Else in Wikipedia, for That Matter

I read the article about the British military commander Alan Brooke with interest. Among many other things, I learned that he was an Ulsterman from Northern Ireland. I then went to the talk page to see if there was anything of interest there. I was startled to see this heading somewhat down the page: "Why does Alan Booke look so swarthy? Moreso looks a sub-Loirean Frenchman or a cryto-Jew."

https://wiki.riteme.site/wiki/Talk:Alan_Brooke,_1st_Viscount_Alanbrooke#Why_does_Alan_Booke_look_so_swarthy?_Moreso_looks_a_sub-Loirean_Frenchman_or_a_cryto-Jew.

That seems to me to be an extremely offensive remark, based solely on what appears to me to be racial or racist prejudice. I have just gone through the "talk page guidelines" and don't see anything that pertains specifically to something like this.

Am I being overly "politically correct" about this, or do others find it as offensive as I do? Further, I note that the person who created this section did it anonymously. What, if anything, can/should be done about it? Hayford Peirce (talk) 23:54, 7 August 2018 (UTC)

Agree, Hayford Peirce. Changed to "Identity or ethnicity". Bus stop (talk) 00:19, 8 August 2018 (UTC)
Thank you! It is still an absurd question to pose (ie, should every WP article identify the ethnicity of every person for whom there is an article?), but at least now it is no longer patently racist or offensive. Hayford Peirce (talk) 01:30, 8 August 2018 (UTC)
Thank you for raising the issue! In my opinion various attributes of identity such as ethnicity and religion may be included or omitted. I don't think there can be a rule for this—just consensus on an article-by-article basis. That was a ridiculous "Section heading" that you brought to our attention, and I think there are some guidelines at WP:TALKNEW that are semi-applicable, such as "Make the heading clear and specific as to the article topic discussed" and "Keep headings neutral". They don't really address the problem but I don't think there can be policy and guidelines for everything. Bus stop (talk) 02:32, 8 August 2018 (UTC)
There has been a big rise in trolling like that in Britain recently with the Brexit vote and the immigration problem and the antisemitism in the Labour party. And in Northern Ireland they divide so loyalists support Israel and republicans support the Palestinians. So I think your feelings about the title were quite justifiable. Dmcq (talk) 09:25, 9 August 2018 (UTC)
Yes, thank you, Hayford Peirce. The header was created by IP 92.5.91.155 in December 2017, along also with this charming edit. I suppose nobody with a block button noticed at the time, and it's a little late to block the troll now. Bishonen | talk 12:24, 15 August 2018 (UTC).

Got me thinking

Crypto-Jew... Crypto-currency... MORE THAN A COINCIDENCE???[FBDB] EEng 11:45, 9 August 2018 (UTC)

Nah... just subtle marketing for Krypto. Blueboar (talk) 11:50, 9 August 2018 (UTC)

Not the right venue, really

Personally, had I seen this post right away I would have moved it to user talk, and directed the OP to DR, HELPDESK, TEAHOUSE, and ANI. WIthout studying it, my gut says there's been an uptick in people complaining about specific disputes on this page, and it is not the right place to do that. I wish regular page watchers would help bar the gates or we'll be doing ANI like stuff everywhere eventually. NewsAndEventsGuy (talk) 12:29, 15 August 2018 (UTC)

WikiMedia PolicyMakers: Talk page banner directs editor to bottom of page

My idea.. not sure this will reach the policymakers/decisionmakers and actual hard-coders behind the wiki website properties.. Why not near the top of EVERY Talk (discussions) page, once someone enters into editing mode, display a red or yellow background rectangular banner at the top reminding commenters to add to the BOTTOM of the wiki text/code, and not to the top? My two cents. :) Vid2vid (talk) 05:18, 4 September 2018 (UTC)

see WP:CREEP. Careful new users will already find out about the WP:TPG and read it anyway, and the other type of new editors won't bother reading banner notes. I sometimes see this particular problem, but rarely NewsAndEventsGuy (talk) 06:51, 4 September 2018 (UTC)
@Vid2vid: If you use the "New section" tab, it will automatically: (i) add the new thread at the bottom of the page; (ii) use the correct level 2 heading, rather than the level 3 heading that you used here; (iii) use an edit summary that includes the title of the new thread, plus the words "new section". See for example this posting. --Redrose64 🌹 (talk) 19:14, 4 September 2018 (UTC)

WP:TPG#Non-free images

It might be a good idea to change the name of WP:TPG#Non-free images to WP:TPG#Non-free content or WP:TPG#Non-free files. While the majority of non-free files uploaded to Wikipedia is probably image files, there are audio files as well. This change would make it clear that this sub-section applies to all non-free content, not just image files. The relevant content would also need to be tweaked accordingly. -- Marchjuly (talk) 02:38, 28 September 2018 (UTC)

Not a good idea, as quoting non-free content is something allowed per policy, as is limited use of other non-free content, at least in namespace. Thinker78 (talk) 06:12, 29 September 2018 (UTC) Edited 19:45, 29 September 2018 (UTC)
Quoting copyrighted content on a talk page is fine, but I’m referring to cases where people have added non-free files to talk pages as part of a discussion. Usually it’s a file being used in the article that’s being discussed, but other times people have uploaded something non-free just to support a position they’re taking on the talk page as some sort of visual/audio proof. — Marchjuly (talk) 14:34, 29 September 2018 (UTC)
I think now after reading the policy more that your suggestion is very valid. I suggest replacing with this text, "Non-free content: Non-free content should not be displayed on talk pages. If images are being discussed, they must be hidden by linking them with a colon—as described in 'Hiding or resizing images', above. If they are included for decorative purposes, they must be removed. Other non-free content should be removed." Thinker78 (talk) 20:00, 29 September 2018 (UTC)
What I wonder is if the guideline regarding images cover all images or just non-free images. Thinker78 (talk) 20:03, 29 September 2018 (UTC)
The restrictions apply to nonfree images only, obviously. Non-nonfree images are, um, free. EEng 20:52, 29 September 2018 (UTC)

Linking to a talk page discussion

It seems that a section link to a talk page discussion (be it user talk, article talk, project talk or whatever) gets broken once that discussion is archived. If so this is a fundamental flaw as it should be easy to refer back to a discussion if needed and such links in edit summaries can't be corrected. Is there any solution or workaround to this? A way to create a permalink perhaps? --Jameboy (talk) 10:17, 25 October 2018 (UTC)

@Jameboy: There is a parallel thread at Wikipedia:Village pump (technical)#Question about breaking links. But permalinks are available: Special:PermaLink/865658540#Linking to a talk page discussion. --Redrose64 🌹 (talk) 10:21, 25 October 2018 (UTC)
@Redrose64: Will take a look, thanks. --Jameboy (talk) 10:30, 25 October 2018 (UTC)

What is a "Meta-Discussion?

No meta: Extended meta-discussions about editing belong on noticeboards, in Wikipedia-talk, or in User-talk namespaces, not in Article-talk namespace.

What are "meta discussions" and how do they apply to Talk Pages? Can anyone give any examples of what a "meta discussion" is, either actual or hypothetical. This term is totally meaningless to me.Tym Whittier (talk) 19:52, 4 November 2018 (UTC)

As I understand it, meta-discussions are discussions about discussions, in much the same way that metadata is data about data, or the Meta-Wiki is a wiki about the wikis. That doesn't help much, so let's look at the context.
This is in the subsection How to use article talk pages. Mainly, it means that article talk pages should concern themselves only with matters specific to that one article. If you want to discuss, for example, a general matter about a particular user's behavioural pattern over several articles, that is not a matter for an article's talk page. --Redrose64 🌹 (talk) 21:44, 4 November 2018 (UTC)

Currently WP:INTERSPERSE goes to the § Layout section, just like WP:TOPPOST and WP:BOTTOMPOST. WP:INTERLEAVE goes to the § Editing others' comments section, which is a separate idea. It's not listed in the convenience-links box there. And "intersperse" and "interleave" are fair lay-language synonyms. Can someone work in a cross-linking of these two ideas? Or unify them? It's not obvious that interleaving a reponse to paragraph one of a three-paragraph parent post is editing that parent post vs just threading/layout games. DMacks (talk) 08:08, 12 November 2018 (UTC)

Request for clarification

In [this] section, in the point fixing layout errors, am I allowed to replace <font> tag to <span> tag as part of removing obsolete HTML tag errors without informing the specific user?Adithyak1997 (talk) 17:32, 18 November 2018 (UTC)

Yes, if there has been a discussion somewhere showing that such a cleanup is desirable. An edit summary should link to that discussion. If the user reverts, don't repeat but seek assistance. Johnuniq (talk) 22:06, 18 November 2018 (UTC)

AVG PC TuneUp page comment

Hi – I posted a Talk page comment at Wikipedia talk:Ignore all rules regarding Wikipedia’s erroneous description of the features of AVG PC TuneUp (my employer’s product), because there are no available citations to reflect a recent product revamp that removed many of the features Wikipedia describes as current. I just saw that an editor (@Verify References:) deleted my Talk page comment and attempted to answer my question. Was it appropriate for an editor to delete my Talk page comment? Can I restore it? Empey at Avast (talk) 19:06, 1 March 2019 (UTC)

Your comment was off-topic at Wikipedia talk:Ignore all rules because it did not relate to the policy. The problem is that hundreds of off-topic comments are made every day and they have to be cleaned up. In this case, you should have received a WP:Notification (aka "ping") because the editor answered your question at Talk:AVG PC TuneUp#New release, different features. I don't understand their answer but perhaps with more background, you do. If assistance is needed, try asking at WP:Teahouse. Your question has no good answer because articles cannot be based on what people "know". Instead, articles have to be based on reliable sources in order to minimize misinformation. Johnuniq (talk) 23:11, 1 March 2019 (UTC)

Talk pages

I just created a talk page but what I really wanted was to create an article... How may i change it ? Sagher Genesis (talk) 10:38, 28 December 2018 (UTC)

Your draft article about this rapper has no citations to any sources, so it isn't ready to be an article anyway. For help see Wikipedia:Your_first_article. NewsAndEventsGuy (talk) 10:56, 28 December 2018 (UTC)
@Sagher Genesis: I cannot find evidence that you have created any talk pages, your only page creation is your user page. --Redrose64 🌹 (talk) 22:21, 28 December 2018 (UTC)
@Redrose64: What should i have done or shouldn't have done then ??Sagher Genesis (talk) 09:45, 29 December 2018 (UTC)
The thing is, you started off by saying "I just created a talk page", without saying which talk page. So I looked through your contributions - and the only talk page that you have edited so far is this one. Moreover, you didn't create it: it was created way back in 2005 by Lubaf (talk · contribs). --Redrose64 🌹 (talk) 08:36, 29 December 2018 (UTC)

Removing empty edit requests

Please see Talk:XXXX#Semi-protected edit request on 30 November 2018 and Talk:XXX#Well... for context. I propose to add the following to these guidelines at Wikipedia:Talk page guidelines#Editing others' comments:

  • Empty edit requests. It is acceptable to remove empty edit requests from a Talk page. Consider using {{Empty edit request}} on the User Talk page of a user who has posted an empty edit request.

Shhhnotsoloud (talk) 07:57, 15 January 2019 (UTC)

  • Support Thanks for your interest in clean up! Under "off topic" it already says "It is common to simply delete gibberish, test edits, harmful...". So this is already covered and I routinely delete empty edit requests when I see them. No one has ever squawked. That said, the bit I quoted is sort of buried and you have to think to realize it covers this regular occurrence. A bullet of its own will help someone someday NewsAndEventsGuy (talk) 09:29, 15 January 2019 (UTC)
    I have had one person who squawked - see Wikipedia talk:WikiProject Council#Item removed from this page. It wasn't a person who had submitted an edit request. --Redrose64 🌹 (talk) 19:39, 15 January 2019 (UTC)
  • Comment - I would suggest a two step response to empty requests: First, respond to an empty request with a note saying “not done - unclear what edit is desired” (or similar)... It’s a polite way to tell the editor who posted the request that he/she needs to follow up with a more specific request. Second, If after a few days no one follows up, delete the empty request. Blueboar (talk) 11:57, 15 January 2019 (UTC)
    Even better delete from article talk page, and put the note Blueboar suggests on that particular ed's page. Those who are actually here with us will still see it that way, while null requests left by driveby graffitti artists will not clutter up anyone else's experience. NewsAndEventsGuy (talk) 12:54, 15 January 2019 (UTC)
    On the other hand... if a particular page is getting lots and lots of empty requests, leaving one or two of them (with replies explaining why they were not done) can help teach subsequent editors how to format their requests properly. It is something of a judgement call. I do think we should allow the removal of empty requests (at least we should not disallow it)... but I am not sure we want to highlight or encourage it. Blueboar (talk) 13:23, 15 January 2019 (UTC)
    @Blueboar: We do have {{subst:EP|xy}} (it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate) which is often correctly used on vague requests, but occasionally gets used on empty requests too. The only times that I've seen that message actually being replied to are when the original request wasn't empty. Using it on an empty request is simply a waste of time. --Redrose64 🌹 (talk) 19:53, 15 January 2019 (UTC)
  • Support - Editors who leave a letter-perfect blank edit request template are arriving there by trying to edit the page, landing at the View Source page, clicking on Submit an Edit Request, and saving the page with no changes in spite of all the instructions on the three preceding screens telling them how it works. Doing it that way, you never actually see the article talk page before submitting your request, so there's no point to leaving blank requests on the article talk page for these editors to learn from. And if you're not going to be bothered to read any of the instructions, I have severe doubts that you're monitoring the talk page for followup on the non-request.
    As I noted in the discussion at Talk:XXXX, I've been removing empty requests for most of the last year following this discussion at VPT. To be clear - I'm only removing completely blank requests where the requestor has made no changes to the template whatsoever and saved it. If they placed the template manually, or if they tried to make a request and malformed it or made it completely nonsensical, they deserve a reply (barring vandalism - though I guess that deserves a different sort of reply). I do consider using {{Empty edit request}} (since I found out it exists last month - that might need to be pushed out a bit wider?), but my rule of thumb has been to place it for registered accounts on their first such request, or for IPs that have tried multiple requests. Based on that thumbrule, I think I've placed the template twice. ‑‑ElHef (Meep?) 14:40, 15 January 2019 (UTC)
    ElHef, perhaps adding to Twinkle? (please Reply to icon mention me on reply; thanks!) Emir of Wikipedia (talk) 20:55, 15 January 2019 (UTC)
  • Software solution? The sample message This is a byte county test. contains just 27 bytes. Maybe we could all be helped if the software counted the bytes in the "meat" of these messages, and popped up a box if the content was under 30 bytes? That way, the only way intentional vandals could post would be to add junk, and users who actually meant to say something would be alerted that they goofed somehow. NewsAndEventsGuy (talk) 15:12, 15 January 2019 (UTC)
    I had the thought awhile ago to request an edit filter, but I've talked myself out of it. There's many ways that someone can mess up an edit request that I would actually want to reply to - for example, I've seen many where the request has been put in the section header in place of the normal header, leaving the byte count more or less the same as an empty request. I don't want to have an edit filter block a legitimate request from a brand-new editor, and if someone has already ignored the information on the first three pages, I don't know how much difference a fourth warning would make. That said, I know literally nothing about coding edit filters, so it could be a lot easier than I'm thinking. ‑‑ElHef (Meep?) 20:35, 15 January 2019 (UTC)
    Not a problem!! Apologies for not being more clear. I did not mean to simply not post empty ones. Instead, I meant to hold the hand of the editor who tried to post an empty one and, through the pop up box, coach them how to do it better until it actually goes through. So the issue you describe would also be cured with this software tweak NewsAndEventsGuy (talk) 21:02, 15 January 2019 (UTC)

 Done Since there were no objections, I edited the guideline as I suggested, adding "if considered necessary" to respond to the comments above. Thanks for the feedback. Shhhnotsoloud (talk) 19:32, 22 January 2019 (UTC)

Strike through

I made an edit (Revision as of 12:01, 29 January 2019) that was reverted (Revision as of 12:28, 29 January 2019 ) by user:NewsAndEventsGuy with the comment "Oppose as WP:CREEP and its redundant, see the part about removing prohibited material"

The change I made was to the paragraph that currently reads:

Striking text constitutes a change in meaning, and should only be done by the user who wrote it or someone acting at their explicit request. (added in August 2010 by user:Xeno)

However it is precisely because of the bullet point "sockvote"

  • Removing or striking through comments made by blocked sock puppets of users editing in violation of a block or ban. Comments made by a sock with no replies may simply be removed with an appropriate edit summary. If comments are part of an active discussion, they should be struck instead of removed, along with a short explanation following the stricken text or at the bottom of the thread. There is not typically a need to strike comments in discussions that have been closed or archived. (initially added by user:NE Ent in December 2015 and in its current format by user:Rhododendrites in June 2018)

that the former needs to change because at the moment there is a possible conflict in interpretation.

The paragraph existed for five years before the bullet point was introduced and is and always was incorrect as sockpuppet comments have been struck out for far longer than that.

I also added an example of what "striking text" means as it is jargon without an explanation that could confuse new editors for whom this page is most useful. -- PBS (talk) 15:00, 29 January 2019 (UTC)

Ah, I see what you're trying to do. Thanks for explaining. Suggested alternative Striking out text (e.g., <del>...</del>) constitutes a change in meaning, and should only be done by the user who wrote it or as otherwise provided in these talk page guidelines. This way, we eliminate the apparent conflict with the other provision without making the whole thing way too long, we avoid repetition, and we reduce the burden for ongoing maintenence, since the meat of the sock instructions is just in a single place. NewsAndEventsGuy (talk) 15:14, 29 January 2019 (UTC)
Dealing with sockpuppetry would be an exception, I think N&EG's suggstion works fine. –xenotalk 18:45, 29 January 2019 (UTC)

Premature archiving

Not sure if it's been discussed before, but I was wondering what the etiquette is for editors that unilaterally decide to archive conversations before the already configured bot has been able to archive the conversation. I'm noticing the behavior on some politics related articles, and while there's nothing (that I know of) in our policies that forbids or discourages the practice, I find the behavior potentially troublesome (because someone may decide to archive a topic they disagree with or find works against any bias they might be trying to push in the affected article).

Thoughts on perhaps adding a section that states manually archiving talk page sections less than a week after the last comment is discouraged behavior? —Locke Cole • t • c 08:41, 28 January 2019 (UTC)

Policies and guidelines should not attempt to micromanage. Sometimes aggressive archiving is a good way to handle particularly misguided commentary. As with all things, if someone has a good reason to disagree with an action they can revert it and then seek WP:DR if they are reverted in turn. Johnuniq (talk) 09:18, 28 January 2019 (UTC)
Seems reasonable, thank you for the feedback. —Locke Cole • t • c 03:28, 4 February 2019 (UTC)
Discourage as strong as forbid. How about recommend against? A week does seem fast to me, but some discussions grow fast, some slow, and some ready to restart anew. Gah4 (talk) 10:05, 28 January 2019 (UTC)
I wouldn't go so far as to forbid it. I think discouraging it would be enough. —Locke Cole • t • c 03:28, 4 February 2019 (UTC)
  • Opposed but thanks... we need well-intended suggestions! I oppose because this is WP:CREEP and already covered by our rules. Disclaimer, I sometimes do this. That said, if you simply apply WP:Assume good faith there are three possibilities, none of which need new legalese from the playground monitors. These are....
(A) You assumed good faith and your own nose is not out of joint because of the archiving. Here you can just assume someone has the overall big picture at heart and acted for the right reasons. In this first case, your assumption is correct and you can keep a happy heart and mind believing everyone is doing the right thing the right way for the right reasons.
(B) Same as A, but your assumption was wrong. Here someone acted in bad faith. BUUuUUUTTUTTT.... since your own efforts are not effected and your own nose is not out of joint, why ride in on your battle horse? You can assume good faith and move on, trusting that those effected will be able to act like grown ups to response appropriately. And so this has the same outcome, you can keep a happy heart and mind believing everyone is doing the right thing the right way for the right reasons... and you get to do this because you moved on before sensing bad faith in someone else's battle.
(C) Here, you ARE involved. And the answer is extremely simple. Just manually move it out of the archives back to the talk page with edit summary "Premature archiving, let's keep discussing this". If you don't add a substnative comment of your own, then beware of looking like you're the one with the problem.
Those are the three possibilities if you AGF the first time this happens. If someone re-archives it after you added a thoughtful comment, then that's really solid evidence of a problem. You can leave a note on their talk page and de-archive it again. If they do it a third time, just report to WP:ANI because that's what admins are for.
NewsAndEventsGuy (talk) 11:25, 28 January 2019 (UTC)
This... isn't a poll or a vote. But thanks for leading out with your opposition. I think my problem with rapidly archiving conversations, especially on topics relating to United States politics of late, is the impression it leaves that the only people with input on article content are those tenacious enough to literally be on here daily to argue their opinions. I understand the desire to avoid instruction creep, but sometimes a little guidance goes a long ways in avoiding people feeling that changes are only barely being discussed before being shuffled off to the archive (I'll need to dig deeper on the specific article I had in mind to see if there's any patterns emerging with the behavior, such as speedily archived conversations being used as claims of "consensus" in reverts/editing disputes later). I'm all for assuming good faith, but AGF is not a death pact. Once poor behavior is observed, it's perfectly acceptable to begin making assumptions based on the behaviors so far... —Locke Cole • t • c 03:28, 4 February 2019 (UTC)
That certainly is a conflict prone subject area. If you don't already know about it, "discretionary sanctions" applies to US politics after 1932. If that's brand new to you and you'd like to talk about how that tool works, drop me a note on my user page. NewsAndEventsGuy (talk) 10:53, 4 February 2019 (UTC)

Outdated markup for redacting

Is there any reason to keep <s>...</s> and <u>...</u> for redacting? Using them, one loses the ability to style deleted and inserted text differently via CSS or script. Paradoctor (talk) 23:48, 2 March 2019 (UTC)

Although the s element represents contents that are no longer accurate or no longer relevant, the u element represents a span of text with an unarticulated, though explicitly rendered, non-textual annotation, such as labeling the text as being a proper name in Chinese text (a Chinese proper name mark), or labeling the text as being misspelt, which is barely relevant to indicating added text; thus, we should be using <ins>...</ins> instead of <u>...</u>. For consistency, we should also use <del>...</del> instead of <s>...</s>, see HTML 5.2 section 4.6. Apart from the fact that these have semantic meaning, they may also enclose block-type elements as a group: 
<del>
*'''Delete''' per nominator.
*:It is unencyclopedic, not notable, its last sentence fails [[WP:NPOV]]. And I had an argument with the page creator five years ago. --[[User:Example|Example]] ([[User talk:Example|talk]]) 01:00 3 March 2019 (UTC)
</del><ins>
*'''Keep''' We should not delete this page.
*:It is useful, I like it, and I have since met the page creator socially. --[[User:Example|Example]] ([[User talk:Example|talk]]) 02:00 3 March 2019 (UTC)
</ins>
The <s>...</s> and <u>...</u> elements cannot do this, because they are inline elements. --Redrose64 🌹 (talk) 11:38, 3 March 2019 (UTC)

Question about month/year headings on user talk pages

Not sure whether this has been discussed before – I can't see anything about it here.

In certain situations, mostly leaving warning messages about vandalism or the like, it's common to use the month and year as a heading.

When this is done, should the heading be based on the date of the edit the message is about, or the date when the message is left? For instance, if today I discover that a user made a bad edit in January that has until now gone unresolved, should my message to that user be under the heading "January 2019" or "March 2019"?

This is even more likely to occur when an edit is done late on the last day of a month, in which case it must be quite frequent that no further activity occurs until the following month. And this is before you get into time zone complications.... — Smjg (talk) 12:16, 9 March 2019 (UTC)

Ultimately, it does not matter. The headers are merely a convenient way to separate the vandalism warnings from other messages, or (in the case of persistent vandals) one set of warnings from another set of warnings. Nothing says we have to use the month & year format (at all), so if you are unsure which month or year to put... don’t use that format. Use some other language instead. Blueboar (talk) 12:51, 9 March 2019 (UTC)

WP:OTHERTALK

Housekeeping note... when this thread started there were four links in the LINKBOX. I have since deleted shortcut WP:SIGCLEARN, which was created in 2010 and had only 49 WhatLinksHereHits. NewsAndEventsGuy (talk) 15:11, 16 March 2019 (UTC)

So this new shortcut I created to Wikipedia:Talk page guidelines#Editing others' comments has unexpectedly become the subject of controversy. User:JJMC89 first removes with the rationale that it is "unused", but obviously all shortcuts are unused when first introduced. Then User:Johnuniq removes as too many shortcuts create confusion. But that section already has four shortcuts, twice as many as any other on the page. Thinking five is one too many is completely arbitrary.

To quote Wikipedia:Shortcut:

Shortcuts are created for the convenience of editors. [...] Shortcuts are often used on talk pages in their abbreviated form, decreasing readability for the general reader. [...] To avoid these problems, a good practice when creating shortcuts is to choose common English words that are easily identifiable and memorable.

"WP:OTHERTALK" clearly fares better on these grounds than any of the other shortcuts that link to the same section. "WP:OWNTALK" is already a shortcut, so it is natural to have "WP:OTHERTALK" as well. If the issue is too many shortcuts, I suggest removing some of the others to make room for "WP:OTHERTALK". Three of the four shortcuts ("WP:TPO", "WP:TALKO" and "WP:TPOC") were all created by the same user, who has been indefinitely banned since 2015. Not only that but the meaning of those shortcuts is pretty opaque.

Citizen Canine (talk) 10:12, 16 March 2019 (UTC)

The issue concerns this edit adding a shortcut (WP:OTHERTALK) to the Editing others' comments section. One shortcut (WP:SIGCLEAN) is not relevant for this dicussion because it relates to a different concept. Three shortcuts (WP:TPO + WP:TPOC + WP:TALKO) were created in May 2009—nearly ten years ago. WP:TPO is very commonly used. I'm not sure about the others and don't have time to check at the moment. An argument could be made to replace one of the others with a new shortcut but the section definitely does not need five. I'll think more later, after others have commented. Johnuniq (talk) 10:30, 16 March 2019 (UTC)
(A) Let us not compare to WP:OWNTALK which is a different concept. OWNTALK is about an editor's own talk page. The analogous shortcut for editing one's own comments in other places (e.g., on this talk page) is WP:REDACT.
(B) I too would like a better shortcut (one that is in common English and easy to remember). The current shortcuts do not fit the bill, but then neither does the new one. The problem I have with "OTHER TALK" is because I instantly think of other talk pages, instead of other editors. It makes me want to ask "Oh? You mean there is some forum shoppoing or cross posting happening? OK, where is the real discussion?" FYI WP:TALKO has between 250-500 uses since its creation more than 10 years ago. Obviously it isn't very important. We wouldn't need to delete the redir page, but it doesn't have to be listed here either. For an alternative, what about WP:OTHERSWORDS? That avoids the confusion I have when hearing "OTHERTALK". Even better might be WP:CLEANOTHERSWORDS, as it emphasizes that we must not change the meaning when doing this, but some may object due to its length. NewsAndEventsGuy (talk) 11:58, 16 March 2019 (UTC)
Until last October, the guidance at WP:LINKBOXES was "they generally should list only one or two common and easily remembered redirects". Following discussion at Wikipedia talk:Shortcut, that was relaxed to "they generally should list only the most common and easily remembered redirects". Anyone reading that debate will conclude that the purpose of the change was not to give Citizen Canine the green light to wikilawyer about going from four to five shortcuts. There is no value in creating a fresh shortcut when we have four already. The new one will not meet the criterion of "most common and easily remembered" precisely because its unused. Of course a new shortcut is unused, but there's a world of difference between establishing a new shortcut when none already exist, and creating yet another one when we have more than enough already. --RexxS (talk) 13:37, 16 March 2019 (UTC)
@RexxS: There is no value in creating a fresh shortcut when we have four already. Yes there is. In terms of both quantity and quality, 1 memorable shortcut is preferable to 3 obscure ones. I'm in favour of WP:OTHERSWORDS, which is just as concise as WP:OTHERTALK and is clearer. Removing those current shortcuts will not make them cease to link to the section. Citizen Canine (talk) 13:46, 16 March 2019 (UTC)
Rex, the letter of the law about "most common" being applied to a new one... that's wikilawyer nonsense if I ever heard it NewsAndEventsGuy (talk) 14:05, 16 March 2019 (UTC)
@Citizen Canine: has it occurred to you that by the time we get to four shortcuts, we've almost certainly exhausted all of the "most common and easily remembered" ones? If you really thought that you had a strong case that WP:OTHERTALK would become more common and easily remembered than WP:TPO, WP:TPOC, WP:TALKO and WP:SIGCLEAN, why did you choose to repetitively force it into the article, rather than make your argument on the talk page?
@NewsAndEventsGuy: Don't talk bollox. We have strong and recent consensus for WP:LINKBOX, and it's the appropriate guidance for the situation where new shortcuts are introduced to the linkbox. Which bit of "there's a world of difference between establishing a new shortcut when none already exist, and creating yet another one when we have more than enough already" didn't you get? --RexxS (talk) 14:23, 16 March 2019 (UTC)
Oh I got it. The point was to say, subjectively, "more than enough already". I at least agree we have more than enough.... in fact we have too much rarely-used, weirdly phrased, hard-to-remember links and so rather than frustrate a good faith effort to do better by defending piles of old crap, there is a much better way forward. (see below the outdent) NewsAndEventsGuy (talk) 14:56, 16 March 2019 (UTC)
I don't have much to add here other than restating what has already been said. The point of these template boxes is not to list every single redirect for any given page (indeed, that's what Special:WhatLinksHere is for); instead, they generally should list only the most common and easily remembered redirects.WP:LINKBOXES A redirect that is unused (including WLH and edit summaries, outside of comments related to added it to this page) is not common; therefore, it should not be included. Yes, all new shortcuts will start out unused. If they come into common usage, then by all means consider adding them. Until then, don't. — JJMC89 (T·C) 06:07, 17 March 2019 (UTC)
Are "TPOC" and "TALKO", which are obscure initialisms with only a few hundred uses in almost 10 years, "common and easily remembered"? Those shortcuts were all added the same day they were created. The overwhelming majority of those few uses are due to their inclusion in the link box. I don't see why you are biased against new, better additions. I was trying to introduce a shortcut that could be easily assimilated so people wanting to link to the section wouldn't have to bother visiting the page to check the links. As NewsAndEventsGuy mentioned, the section is counterpart to WP:REDACTED (Editing own comments). I suggest something like "WP:DOCTORED". And that's just a suggestion, not a proposal. Citizen Canine (talk) 11:57, 17 March 2019 (UTC)
I'd say they should be removed. Supporting your position with other stuff isn't going to work. It has nothing to do with what the shortcut is – WP:LINKBOXES is clear that only common shortcuts should be included. One that isn't used is not common. — JJMC89 (T·C) 23:08, 17 March 2019 (UTC)

Proposal addressing all comments made thus far
(A) Keep in your mind the sharp distinction between the existence of a redirect shortcut and listing that shortcut in the LINKBOX
(B) LINKBOX guidance wants a short list. OK fine, let's have a short list.
(C) Of the existing four links

TPO is widely used
SIGCLEAN (2010) = 49 WhatLinksHere After posting this comment, I deleted that one from the linkbox
TALKO (2009) = 200-300 WhatLinksHere
TPOC (2009} = 300-400 WhatLinksHere

(D) proposal Keep the redirect pages for the other three, but with less than 1000 uses in their 10-year history there is little reason to clutter up the TPG LINKBOX with weird shortcuts that are neither intuitive nor easily remembered. Having purged that chaffe, there is ample room to add a new one that is both written in common English and is easily remembered.
NewsAndEventsGuy (talk) 14:50, 16 March 2019 (UTC)

All this would be so much easier if the choice were left to the reader/editor/user/stakeholder/consumer/unwashed. Paradoctor (talk) 16:05, 16 March 2019 (UTC)
Shortcuts on P&G pages aren't for readers, they are for editors. NewsAndEventsGuy (talk) 16:07, 16 March 2019 (UTC)
There, fixed it for you. Paradoctor (talk) 16:10, 16 March 2019 (UTC)
Thanks. What you're refusing to acknowledge is that it isn't just about editors arriving here and selecting from the existing list of (mostly crappy) choices. The point is for editors who anticipate doing future work with these guidelines wanting to improve them, in order to make their future work easier. NewsAndEventsGuy (talk) 16:19, 16 March 2019 (UTC)
(edit conflict) Please don't tell me what I'm about, unless you can read my mind. Paradoctor (talk) 16:33, 16 March 2019 (UTC)
If only that were true... if editors would use descriptive link text with the shortcut, then the wording of the shortcut wouldn't matter so much. For better or worse, English Wikipedia editors tend to just link the shortcut, making it a form of jargon. (It doesn't have to be that way, but that's the way it is.) Now although jargon is confusing to the uninitiated, it can provide a benefit of having a concise term to represent a concept. This benefit is diminished, though, when there is more than one jargon term for the same thing, and it gets worse with more shortcuts, as readers have to remember which shortcuts are actually the same. Thus in the interest of trying to limit dilution of the ensuing jargon, it is desirable to encourage as few different shortcuts to be used as possible. isaacl (talk) 16:30, 16 March 2019 (UTC)
"that's the way it is" Does it have to be?
"limit dilution" ... "desirable ... few different shortcuts ... as possible." I agree with the premise, but not with the conclusion. Paradoctor (talk) 16:37, 16 March 2019 (UTC)
OK.. your prior remarks were pretty vague on substance. What different conclusions do you draw? NewsAndEventsGuy (talk) 17:20, 16 March 2019 (UTC)
Well, I literally said "It doesn't have to be that way", but it is. All attempts to get editors to do something like "guidelines to editing other people's comments" (that is, [[WP:TPO|guidelines to editing other people's comments]]) haven't been too successful. Many editors care more about minimizing the number of characters they type than avoiding jargon. Not sure what premise you're agreeing with; I guess the conclusion you're disagreeing with is discouraging a lot of different shortcuts to be used. isaacl (talk) 18:12, 16 March 2019 (UTC)
"Not sure what premise you're agreeing with": "limit dilution", as in not having 15 different names people need to memorize in order to understand what is talked about.
"get editors to do something" My point is exactly not to "get" them to do stuff.
(NAEG) "What different conclusions do you draw?" The basic problem is not, as Isaacl surmises, that "editors care more about minimizing the number of characters they type", but that the "official" names of topics are generally hard to remember. Therefore, people use shortcuts, at least for stuff they frequently refer to. The trouble begins when different users use different shortcuts. Soon, you have to know a whole herd of other people's aliases for each policy topic in order to understand their comments. OTOH, as Isaacl pointed out, enforcement of a common language is not an option.
So, what to do? How about separating content and presentation? Let the software use a single canonical name analogous to, say, Page ID[1], but present it to each user according to their preferences. That way, everybody gets their own piece of cake, even while everyone eats the same piece of it. Paradoctor (talk) 09:32, 17 March 2019 (UTC)
That's sounds like it might be interesting...I must apologize I don't really understand that or how it would work in practice. An example would help! If you type WP:TPO and I type WP:TPOC what do we each see on our screens in read mode? Specifically, do we each see the wikilinks just as we typed them? If yes I don't understand what would be different. If no, please elaborate by adding details to this or other example. Thanks! NewsAndEventsGuy (talk) 12:58, 17 March 2019 (UTC)
What happens is
  • I type [[WP:TPO]] and hit "Publish changes". The software then translates this into [[Wikipedia:Talk page guidelines#Editing others' comments]], then stores the page.
  • If I request the page from the server, the software looks up my preferences for [[Wikipedia:Talk page guidelines#Editing others' comments]], and then translates it into [[WP:TPO]], then shows you the page / edit page.
  • If you request the same page from the server, the software looks up your preferences, and then translates [[Wikipedia:Talk page guidelines#Editing others' comments]] into [[WP:TPOC]], then shows you the page / edit page.
Actually, there is no need for me (or you or anyone) to use [[WP:TPO]]. It would be entirely possible to use something like §EOtC (read "rules Editing Other's Comments") instead. Everyone can have their own preferred shortcuts, without having to worry about other's ideas what the perfect shortcut looks like. Paradoctor (talk) 13:32, 17 March 2019 (UTC)
For toning down the legalistic pugilism so often plaguing ANI and debates in general, I dislike using the legal section symbol. The idea that the server can do some translation is interesting, but as a practical matter reforming shortcut usage by creating expanding preferences seems like a hard sell.... it sounds like adding on a disproportionate amount of complexity to me. I'd rather see the servers translate my typing WP:SIGCLEAN so that in read mode I and everyone else sees TPG#Editing others comments; the wrapping paper here is not important.... whether we add the WP: or add brackets I don't care. The idea is to translate the typed shortcut into the name of the subsection. Experienced editors would have the convience of typing whatever shortcut they want. Everyone, including the editor, would read the name of the subsection. Simple. No confusion. PS... I guess I did just unconsciously use a the shortcut TPG even in this example. If we use a page in the output, I do like the idea of making that short so the section name and the comment in general can easily be read. But that would mean choosing an "approved" page shortcut and that might be a hard thing to agree on... which is an argument for just dropping the page reference and using the subsection ame only.NewsAndEventsGuy (talk) 13:49, 17 March 2019 (UTC)
"the legal section symbol" This is what I see, not anybody else! That's the whole idea! (throwing up arms).
"adding on a disproportionate amount of complexity" Not at all. I seem to forget that what I know about software is not the same as somebody else knows, usually. A core task of the MediaWiki software is the translation from Wikicode to HTML. Adding a rule for the translation of user-defined magic words is not a major project. It can even be done as a WP:gadget, independently of MediaWiki.
"translate my typing" ... "so that in read mode I and everyone else sees" I assume you mean a kind of autocorrect? No need to bother the server with that. If I wanted that for myself, I would simply add a hotstring to AutoHotKey:
:*:mytpo::[[Wikipedia:Talk page guidelines{#}Editing others' comments]]
With that, typing "mytpo" will be replaced with the full link. Paradoctor (talk) 15:24, 17 March 2019 (UTC)
Oh, I get why editors want to use shortcuts from their side; I simply didn't focus on that aspect. (And if they didn't mind typing more characters, then why aren't they also using descriptive link text, which isn't impeded by the use of a shortcut?) I implemented a proof-of-concept template once that would let you enter in an abbreviation as an argument to the template and it would automatically expand it into a descriptive string with the short cut in parentheses (see User:Isaacl/guidance/testcases for the two abbreviations I configured it with and one unrecognized abbreviation, to illustrate how it handles it). But this is getting far afield from the original purpose of this thread; perhaps it should be discussed at one of the village pumps. isaacl (talk) 15:53, 17 March 2019 (UTC)
Yep. Paradoctor (talk) 16:25, 17 March 2019 (UTC)
Please keep in mind that WLH does not show usage in edit summaries. I've seen many shortcuts related to the subject page used in edit summaries, usually when fixing someone else's error or reverting unwanted changes to a comment. — JJMC89 (T·C) 06:07, 17 March 2019 (UTC)
Ah, good point! Still, its seems reasonable to trust the WhatLinksHere tally as an indication of relative usage. TPO has between 2000-2500 hits, nearly a full order of magnitude more than the remaining two, TKO and TPOC.NewsAndEventsGuy (talk) 12:58, 17 March 2019 (UTC)
It probably is a good approximation. I just wanted to point out that it doesn't account for all uses. — JJMC89 (T·C) 23:10, 17 March 2019 (UTC)

References

  1. ^ Or "Wikipedia:Talk page guidelines#Editing others' comments", "urn:wikipedia:guideline:talkpages:editingowncomments", "308534987", ...

Guideline was changed without discussion

EEng changed the guideline from using the word "content", which was the word used at least for a year, to other wording I object to [1]. I reverted, citing WP:EDIT, but the editor didn't care and reverted back. WP:EDIT states, "changes that would alter the substance of policy or guidelines should normally be announced on the appropriate talk page first. The change may be implemented if no objection is made to it or if discussion shows that there is consensus for the change." I believe that the change of wording changes the substance of the guideline because "content" is a more general word and "discussion" is a more specific word, therefore I object. The guideline should apply to all content and not just discussions or threads. Thinker78 (talk) 05:57, 25 March 2019 (UTC)

I haven't examined the issue but "content" is not a good word to describe text on a talk page. At Wikipedia, "content" refers to the text in an article. For example, someone might be known as a "good content builder" because they spend a lot of time developing text in articles. An extract from the article might be quoted on a talk page and we could debate whether what was "content" in the article is now a "discussion", but that seems fairly pointless. Stuff is put on a talk page in order to discuss the article, so "discussion" is close enough to perfection. Johnuniq (talk) 07:11, 25 March 2019 (UTC)

HTML tag depiction

How is this simpler? It's twenty characters longer, and contains three nested tag pairs rather than one template transclusion. --Redrose64 🌹 (talk) 20:22, 2 April 2019 (UTC)

I see what you are saying. I reverted my revert.--Thinker78 (talk) 00:12, 4 April 2019 (UTC)
Thank you --Redrose64 🌹 (talk) 15:50, 4 April 2019 (UTC)

Reformatting talk page lists

I participated in an RfC at Talk:Russian interference in the 2016 United States elections, where I made this edit, which included a number of adjustments to the thread formatting. Ahrtoodeetoo objected and reverted these adjustments, and I posted the following on their talk page:

I do think I should be reformatting lists properly. I originally cited WP:INDENTMIX, but since that shortcut is only an archived discussion on a talk page, I searched for more reliable guidelines. WP:TPO states, Cautiously editing or removing another editor's comments is sometimes allowed, but normally you should stop if there is any objection. It further explains, restrict the edits to formatting changes only and preserve the content as much as possible. Examples include fixing indentation levels [...]. The #Layout section below specifically calls out accessibility problems created by improper list practices, described in detail at MOS:LISTGAP. I don't believe I've broken any rules or guidelines in merely fixing the list structure, and I believe that doing so is positive and not harmful. —⁠烏⁠Γ (kaw) │ 19:46, 04 May 2019 (UTC)

Ahrtoodeetoo and I remain in disagreement, and they suggested I ask here. Is this practice a problem, and if so, why? —⁠烏⁠Γ (kaw) │ 05:09, 06 May 2019 (UTC)

@KarasuGamma: Changing the colons to asterisks was valid per WP:LISTGAP; but removing the spaces in the two posts timed at 12:50, 24 April 2019 (UTC) and 00:39, 26 April 2019 (UTC) was not necessary. --Redrose64 🌹 (talk) 09:03, 6 May 2019 (UTC)
That's fair; there was no reason to do that part. —⁠烏⁠Γ (kaw) │ 09:53, 06 May 2019 (UTC)
To follow up on the question on the user talk page, users relying on screen readers read talk pages as well as articles. Thus avoiding extraneous announcements on the end and start of lists is valuable on talk pages, too. isaacl (talk)
Editors can be very particular about how their comments are formatted. Some prefer bullets while others prefer indents. Some prefer comments for some purposes and indents for other purposes. This takes precedence over other editors' formatting preferences. The is reflected in the fact that WP:TPO is a behavioral guideline for talk pages, and violations can lead to sanctions, whereas MOS:LISTGAP is part of the Manual of Style, which expressly applies only to article content. I'm going to speculate that the number of users relying on screen readers to read talk pages is vanishingly small. In any case, I understand the desire to clean up such lists, but when another editor asks you not to, you should stop. WP:TPO: Cautiously editing or removing another editor's comments is sometimes allowed, but normally you should stop if there is any objection. R2 (bleep) 15:45, 6 May 2019 (UTC)
Whereas I understand editors wanting to format their comments in specific manners, there is no discernible visual difference in changing from
*<br/>::
to
*<br/>*:
for example, but it makes a huge difference for vision-impaired editors. Any Wikipedia editor using a screen reader will need to access talk pages to fully participate in the editing process. Personally I wouldn't force editors to properly nest the lists in their comments, but I hope that they will appreciate that with no cost in appearance, a great benefit is accrued that improves accessibility. isaacl (talk) 16:10, 6 May 2019 (UTC)
For an illustration, my initial post at User talk:Wnt#On wikitext list markup describes what a screen reader would say when the nested lists are arbitrarily changed midway. Help:List § List basics provides a basic explanation of how wikitext lists work. isaacl (talk) 16:23, 6 May 2019 (UTC)
I misunderstood and didn't realize until now that screen readers were for the visually impaired. I'm sorry to KarasuGamma and anyone who's visually impaired. I'm going to make a slight change to WP:TPO to clarify. R2 (bleep) 16:26, 6 May 2019 (UTC)
WP:LISTGAP is not just about well-formed HTML, it is about accessibility, and hence applies to all namespaces, without exception: accessibility is not something that you can opt out of. --Redrose64 🌹 (talk) 19:43, 6 May 2019 (UTC)
No one disputes that accessibility must be a top priority. But that doesn't mean that whatever has somehow made its way into MOS:ACCESS is an actual accessibility issue, or strikes the right balance between accessibility and other important considerations. EEng 01:37, 8 May 2019 (UTC)
I disagree. Accessibility accommodations should be as comprehensive as possible. —⁠烏⁠Γ (kaw) │ 10:02, 08 May 2019 (UTC)
"As possible" is a meaningless platitude; everything is a balance of desiderata. I am particularly tired of hearing that things have to be a certain way because some broken screen reader is stuck in the 1990s. EEng 16:35, 8 May 2019 (UTC)
I agree with EEng. Most things in MOS:ACCESS plainly shouldn't apply to talk pages, for instance. R2 (bleep) 16:16, 8 May 2019 (UTC)
Why "plainly"? Why do you wish to exclude a particular group of people from our talk pages? --Redrose64 🌹 (talk) 21:56, 8 May 2019 (UTC)
I don't, and I don't appreciate the suggestion that I do. Plainly because I don't think many people would seriously argue that, for instance, talk page headings must be descriptive and consistent...that we shouldn't use strikethrough to remove objectionable text...that talk page images must have alt attributes...etc. R2 (bleep) 22:15, 8 May 2019 (UTC)
I would have thought it obvious that talk page headings should be descriptive and unique. A screen reader user will call up the list of headings on a page that they have previously visited and can go directly to the section that is of interest to them if it has a sensible heading. Given the length of some talk pages that seems like a pretty reasonable accommodation to me. I'm afraid that alt attributes are also just as important on talk pages as anywhere else in our encyclopedia. A blind editor hearing the talk page through assistive technology can't see the image, and if we fail to provide them with an alt attribute, we really do exclude them from that part of the discussion. I would recommend you re-assess your views on those issues and perhaps try out one of the free screen readers for yourself. It's quite enlightening. --RexxS (talk) 01:15, 9 May 2019 (UTC)
What you think is obvious is contrary to WP’s standard practices. That doesn’t make it wrong, however, and I commend you for your righteousness. I recommend you don’t tell other people what their views should be. R2 (bleep) 03:38, 9 May 2019 (UTC)
Wikipedia's standard practices are clearly not what you think they are. We actually do have guidance on how to make the experience of using Wikipedia more tolerable for those who are disadvantaged, and you don't have licence to breach that guidance on your whim. You can choose to ignore any advice I offer, of course, but you'll find that on a collaborative project you will have to make adjustments to your views when they fall so far outside of the norms of the rest of the editors. --RexxS (talk) 10:27, 9 May 2019 (UTC)
@Ahrtoodeetoo and EEng: I would like to draw your attention to the lead section of Wikipedia:Manual of Style/Accessibility, which has a paragraph beginning "On 14 January 2006 ...", which reproduces the primary content of wmf:Resolution:Nondiscrimination. It says nothing about applying only to articles or certain namespaces, nor to non-applicability in certain namespaces or outside of articles; it must therefore be considered to apply everywhere, regardless of namespace. --Redrose64 🌹 (talk) 10:50, 9 May 2019 (UTC)
Redrose64: And I would like to draw your attention to the fact that I never said anything suggesting that accessibility considerations don't apply outside of article space. What I said is that it's not clear that MOS/Accessibility embodies the right set of guidelines to actually achieve the goal of accessibility. EEng 16:14, 9 May 2019 (UTC)
@EEng: That's the first I've heard that the guidance offered by MOS:ACCESS is in any way unsuitable for achieving the goal of accessibility. Those guidelines have been produced as the product of extensive debate, consultation and refinement in the light of universal guidance such as WCAG2.0. Would you please indicate which guidance you are referring to and back up your accusation with some facts, please? --RexxS (talk) 16:58, 9 May 2019 (UTC)
Show me something on WP that isn't the product of exhaustive debate. There's no "accusation" and I suggest you cool your jets a little. Whether you like it or not, MOS applies only to articles, and is only a guideline. It was someone's mistake to lodge accessibility guidelines within MOS, when in fact they should have been situated somewhere else -- somewhere appropriate to something which is meant to apply project-wide. Given that mistake, it's inevitable that many or most participating in, or monitoring, Talk:MOS/Accessibility assumed that any provisions under consideration there would apply only to articles -- the word article appears some 30 times, compared to once for talk page. We can't know how this or that discussion might have gone differently had the page's advertised scope-of-applicability been wider, and you can't just expand that scope without discussion.
Beyond that, I've many times been told that MOS/Accessibility is some kind of super-policy whose provision's can't be questioned, and that's hogwash. The goal of accessibility is policy, but that doesn't mean everything that happens to have found its way onto MOS/Accessibility, because some group of editors thought it was a good idea, has the force of policy. EEng 20:09, 9 May 2019 (UTC)
Much of Wikipedia is the product of one or two editors pursuing their own personal preferences, rather than debate. You may be accustomed to that, spending so much time at MoS, but ACCESS really is the result of an entire WikiProject working to improve the experience of disadvantaged users. Your accusation is plain: "it's not clear that MOS/Accessibility embodies the right set of guidelines to actually achieve the goal of accessibility". So far your argument has rested on some vague hand-waving about the guidance at MOS:ACCESS not doing its job. So let's hear what pieces of guidance you feel are deficient. It may well have been a mistake to to place ACCESS within the MoS, but your opinion on that is clearly not shared by the majority, and it's no use whining about it. The situation is what it is, and your obstructionism on clearly delineating the scope of ACCESS results in editors regularly causing problems for anyone who has to use assistive technology, simply because they don't know any better.
I'm afraid you're quite wrong to think that ACCESS does not apply to talk pages for example. There is nothing about talk pages that renders that section of the MoS ineffective. Blind visitors still need alt text; colour-blind readers still need to get information without relying on colour; older readers still need a minimum text size to be able to read comfortably; both tables and lists still need to be amenable to use by screen readers, and so on. The only hogwash here is your creation of a strawman. Nobody here is claiming that we have a super-policy, merely that the guidance that has been carefully developed applies in much the same way to any of our content, whether it is found in articles, on article talk pages, on user talk pages, in templates, or anywhere else where a user who may not have your physical advantages wants to read or hear it. --RexxS (talk) 01:12, 10 May 2019 (UTC)
I agree that the situation is what it is: MOS applies only to articles because MOS itself says so -- see below. And for the second time, cut your bullshit about "accusations" and (now) "obstructionism". You haven't got the street cred to call into question my good faith, nor have you the breadth of experience and activity on the project to comment disparagingly on the kind of discussions I may be "accustomed" to. EEng 03:27, 10 May 2019 (UTC)
cut your bullshit about "accusations" and (now) "obstructionism". You haven't got the street cred to call into question my good faith - At this point, I'm certainly questioning your good faith. —⁠烏⁠Γ (kaw) │ 04:09, 10 May 2019 (UTC)
I'm tempted to invite you to open a thread at WP:ANI and see what reaction you get to that idea, but since you have, like, 1000 edits total, I'll take the trouble to educate a newbie by directing you to WP:AOBF, which may help you avoid getting your ass in a sling.
I answered your below query but I you seem to have been unable to craft a response. EEng 06:08, 10 May 2019 (UTC)

@EEng: Is there a concrete statement you can point to that asserts that MOS applies only to articles? And, more importantly, is there a concrete suggestion you have for improving any of this? —⁠烏⁠Γ (kaw) │ 00:19, 10 May 2019 (UTC)

Is there a concrete statement you can point to that asserts that MOS applies only to articles? – Sure, that would be MOS:MAIN's opening:
The Manual of Style (MoS or MOS) is the style manual for all English Wikipedia articles. This primary page is supported by further detail pages ... If any contradiction arises, this page always has precedence. The MoS presents Wikipedia's house style, to help editors write articles with consistent and precise language, layout, and formatting ... Style and formatting should be consistent within an article ... editors should not change an article from one of those styles to another ...
(Bolding added.) Then there's MOS/Accessibility itself, which terms itself part of the English Wikipedia's Manual of Style and discusses ...
Article structure ...structure of articles ... Article lead ... Article lead ... Article lead ... elsewhere in the article ... Article lead ... Article lead ... articles should ... articles should ... articles with ... In articles, do not ... colors in articles ... in Wikipedia articles ... Articles (and other pages) that use color ... If an article ... top of the article ... threaded discussion on talk pages ... especially in article content ... appropriate for an article ... links to other articles ... consistent appearance between articles ... articles should use ... avoided in article text ... not used in article text ... in the article's main body ... articles should be accessible ...
In fairness, in the above I've underlined the few points at which reference is made to pages outside article space.
My suggestion for improvement would be to start a page, outside of MOS, that addresses accessibility issues comprehensively with explicit reference to the (at least somewhat) different guidelines applying in different spaces.
EEng 03:27, 10 May 2019 (UTC)

A clarification

A small clarification: WP:INDENTMIX originally linked here, but it was recently updated to point to the same place as MOS:LISTGAP. (I also completely forgot that I was the one who created WP:INDENTMIX.) —⁠烏⁠Γ (kaw) │ 00:32, 08 May 2019 (UTC)

Wow. That advice was posted eleven and a half years ago (eighteen months before I joined), and people still can't get the hang of it. Included in that post is virtually the same advice that I've been giving people for some time - when replying, don't leave a blank line, do copy all the symbols from the line that you're replying to, add one symbol to their right followed by your text. --Redrose64 🌹 (talk) 07:50, 8 May 2019 (UTC)

Using talk page as repository for reference dump or removed article contents

I removed contents from an article that I didn't find it relevant for the article. Another editor simply dumped the contents removed the contents removed from prose into its talk page. example.

In this example, an editor simply dumped a list of references for others to consult for others to expand with but not a discussion of references. What do the guidelines and community consensus say on the use of talk page as a dump ground for previous contents or raw references rather than for discussion purposes? Graywalls (talk) 15:58, 28 March 2019 (UTC)

Are they actual references to consider or a bunch of random repository external links? If they're up for consideration, then they can use {{refideas}} AngusWOOF (bark • sniff) 16:15, 28 March 2019 (UTC)
I post references to talk pages all the time. This is the first time I've been questioned for doing so. ---Another Believer (Talk) 17:00, 28 March 2019 (UTC)
As for your first point, this page says, "The talk page can be used to "park" material removed from the article due to verification or other concerns, while references are sought or concerns discussed." ---Another Believer (Talk) 17:06, 28 March 2019 (UTC)

It was posted at article talk on March 9, twenty days ago, with text "For future reference". It is mainly PRIMARY source reearch on the building's history, instead of the club itself. It looks off topic to me, and after 20 days without the discussion even beginning it appears to me to be abandoned. So with the appearance of being offtopic and abandoned I moved it from article talk to user talk in this two-edit DIFF. If Another Believer disagrees, then by all means EDIT THE ARTICLE (be bold) and then DISCUSS in a meaningful way if it gets reverted (see WP:BRD. Alternatively, just start discussing in a meaningful way right now. Either way article talk should not be used as a parking place for abandoned drafts. NewsAndEventsGuy (talk) 17:20, 28 March 2019 (UTC)

FYI, from user talk here it appears this might be  Done NewsAndEventsGuy (talk) 17:27, 28 March 2019 (UTC)
NewsAndEventsGuy, Thanks. I removed the content from the article and moved it to the talk page for future reference, if helpful, but I don't care if the building content is removed from the talk page. As for posting references to talk pages, I don't plan on stopping. ---Another Believer (Talk) 17:30, 28 March 2019 (UTC)
Removing significant amounts of content from an article can be problematic. If it is clearly junk (both original research and wrong) then deleting is fine, and it should not be parked anywhere because crud accumulates and obscures anything useful. However, if removed content might have redeeming features, it is reasonable to park it on the talk page in the hope that a mythical editor in the future will use it to build proper content for the article. It's fine. Johnuniq (talk) 23:22, 28 March 2019 (UTC)
Disagree. This kind of material is basically an article draft, or at least a partial draft. The community has already decided that in mere userspace (which is much less trafficked and visible) such material should not be kept forever. See WP:STALEDRAFT. There isn't any agreed timeframe, but there is agreement that it should not be forever. There is no reason to treat stale drafts at article talk any differently, unless the visibility and traffic means we should have a tougher standard. It should suffice to post a DIFF in article talk and that thread will get archived. The original text with "maybe" redeemable qualities can be found either by searching version histories or following the DIFF from talk archives. The logical extreme of allowing this material is that we no longer need version histories, since users could just post all the text of their reverts in article talk.... an obvious absurd result. NewsAndEventsGuy (talk) 00:57, 29 March 2019 (UTC)
This is a fuss about nothing. People do this all the time. Unless the content is affirmatively objectionable (e.g. serious BLP violations) it's fine. Logical extremes are rarely enlightening. EEng 01:36, 29 March 2019 (UTC)
I have used this method on occasion for large lists of further reading, where there are already dozens of cited references, and asked other editors to discus and choose the most suitable half dozen for inclusion in a further reading section. -- PBS (talk) 10:17, 14 May 2019 (UTC)
@NewsAndEventsGuy: There is a reason why we treat fragments of content in article talk pages differently from that in userspace or draft space. The latter two venues are almost certainly watched or visited by one editor alone; if that editor abandons them, there is consequently little chance of them subsequently being useful.
In contrast, the talk page of an article will be seen by multiple editors looking to improve the article – the very audience who is most likely to make use of the fragments of content, even if abandoned by the original editor who moved them out of the article. --RexxS (talk) 11:48, 14 May 2019 (UTC)

Miguel Escopeta Keeps deleting my edits

Extremely abuse of power. Stop him. He is tampering things he doesn’t understand.

If he doesn’t understand the material, make him stop. He doesn’t have permission to delete something he doesn’t understand. Completely unfair. Wrong wrong wrong. Stealthsilent (talk) 23:26, 15 May 2019 (UTC)

You're in the wrong place. Andy Dingley (talk) 23:46, 15 May 2019 (UTC)

TPO vs. OWNTALK

Had a recent case where a logged-in editor removed an unresponded-to section on my Talk page created by a banned sock. Removing comments by a sock is permitted by the penultimate bullet at WP:TPO. On the other hand, it's my talk page, and I would think that at a minimum, a ping would be required, and a strikeout-plus-explanation would be better than stealth removal. Just wondering if OWNTALK or TPO needs to say anything about this or not. It just feels wrong to do this, but I can't pinpoint why. Perhaps there's another policy I'm missing. Mathglot (talk) 09:09, 5 June 2019 (UTC)

I wouldn’t worry about it... if, at some point in the future, you want to remind yourself about what was written (which, if you think about it, is really the only reason to retain old comments) there is a record of it in the history of your talk page. You can retrieve it at any time. Blueboar (talk) 12:36, 5 June 2019 (UTC)
@Mathglot: I suspect that the penultimate bullet at WP:TPO was aimed more at article talk pages than user talk pages, where we have the convention that the user has a lot more control over what appears there; and that is probably why it feels a little bit off when another editor simply removes a section from your talk page. TPO does recommend that archiving is preferred for user talk pages, and I see that you archive yours. If you wanted that section archived instead to allow you to find it more easily, then you could always restore the comment directly into your archive manually. I think common sense dictates that the choice should be yours unless the content is libellous or violates BLP. --RexxS (talk) 13:00, 5 June 2019 (UTC)

Draft article on user talk page

Is it correct to tell an editor not to put a draft article on their user talk page? I couldn't find anything specific.

And if it's not against the rules, then I guess I shouldn't have moved the draft to a sandbox, but I think that was acceptable given that an article draft on the page would just confuse people who are trying to use the talk page for what is intended.— Vchimpanzee • talk • contributions • 19:45, 13 August 2019 (UTC)

  • A draft should not be on the user’s main userpage, or on that page’s associated talk page... but it is fine for users to create subpages in their user space to work on drafts. Blueboar (talk) 20:46, 13 August 2019 (UTC)
Where is this stated? I posted on the user talk page that the draft shouldn't have been there and posted a link to where I had moved the content.— Vchimpanzee • talk • contributions • 21:15, 13 August 2019 (UTC)
It may not be express, but I read "When talk pages in other namespaces and userspaces are used for discussion and communication between users, discussion should be directed solely toward the improvement of the encyclopedia" as covering that. When a user puts their talk page to service as a draft article, it interferes with the ability to use it for that communication. TJRC (talk) 21:22, 13 August 2019 (UTC)
Usually when people are breaking the rules someone posts a link to where the rules are, but I didn't see where I could send this person. Anyway, what I moved got moved again to the right place.— Vchimpanzee • talk • contributions • 18:56, 15 August 2019 (UTC)
This turned out to be a bigger problem than I expected. What is the proper course of action when a draft is posted on the user talk page and there is other content there? I was told I should have moved but the other talk page content would have had to be moved back, which would still be a copy and paste.— Vchimpanzee • talk • contributions • 20:50, 16 August 2019 (UTC)
My call... create a user subpage (Essentially a sandbox... but with the username attached)... copy and paste the material into it. Leave an edit summary explaining what was done (and why). Then go back and cut the material from the talk page, leaving a message pointing to the new user subpage. Blueboar (talk) 21:03, 16 August 2019 (UTC)
That's what I did. I left the user a message that the draft was at the new subpage. But when the draft turned out to be eligible for speedy deletion … well, you can read what happened.— Vchimpanzee • talk • contributions • 21:09, 16 August 2019 (UTC)

Pointy bullets

I've been having a conversation with In ictu oculi and SmokeyJoe at User talk:Andrewa#Pointy bullets about whether edits such as this one should be bulleted.

I don't think they should be. The reason for doing so seems to be to draw attention to the post, to make it stand out. That would be better done explicitly by bold text or several other techniques IMO, if it's really the intent. Of course bolding is unattractive because it looks pushy, like shouting. The bullet point is really just as pushy, but in a more subtle way.

Plus, according to MOS:INDENTMIX, once we go to bullets we shouldn't go back.

The two users I've pinged above aren't by any means the only ones doing this, just the two I've invited to the conversation on my talk page. It seems to be spreading. And as nobody wants their comments to be less visible, I guess in time everyone will be forced to adopt the practice too, and the use of the colon : for indenting will virtually cease, and bullets will become the standard. That may not be a bad thing, technically the colon is a list markup too, but I think it needs discussion.

Comments? Andrewa (talk) 04:42, 12 September 2019 (UTC)

Not sure by "once we go to bullets we shouldn't go back" you mean that an unbulleted list cannot be nested inside a bulleted list. Note the second example in the section reached through WP:INDENTMIX does precisely that. There is no accessibility problem with introducing a different type of list nested within all of the existing ones; the problem is with changing the type of one of the existing list levels. This is a problem for all types of lists, not just bulleted ones. I discuss this in a bit more detail at User:Isaacl/On wikitext list markup.
However, if person A writes a comment and person B replies, when person C replies to A, for accessibility and general legibility they should use the same list format as person B. So in that sense, person B has made a decision for either bulleted, unbulleted, or numbered list items for replies to A that others should follow.
Leaving aside the question of undue emphasis (which I'm not clear is the case), I think a lot of people find it easier to read through bulleted lists and so like to put their comments in a bulleted list. However, unless you're actually making a list of items, it's a bit unwieldy with multi-paragraph comments. From that perspective, it would be more flexible to reply using an unbulleted list, to better accommodate future multi-paragraph replies. But I suspect many editors won't want to give up their personal preference for bulleted lists.
It might be interesting to know if those who use bulleted items for replies have experience with Usenet or text-based email. There is a long tradition of indented replies in those formats, which has been carried over into Wikipedia in the form of replies using unbulleted items. Perhaps as experience with those formats fade (though the equivalent on bulletin board forums still remains), there is a greater inclination towards bulleted replies. isaacl (talk) 05:41, 12 September 2019 (UTC)
Note the second example in the section reached through WP:INDENTMIX does precisely that. Exactly. And that second example is marked but  don't do this (switch type from bullet list to description list) (my emphasis) and has a disapproving graphic as well. Am I missing something?
So, I had a look at your page User:Isaacl/On wikitext list markup, and your page seems to me to be at odds with the MOS on this very point.
I think you're quite right about personal preferences relating to usenet etc experience. The world has changed and will continue to change, and Wikipedia with it. And we need to avoid motivated reasoning resisting the changes, it's easy to do, particularly for cranky old men like me whose experience goes back to FidoNet days. But I'm not convinced that this change is good for Wikipedia... assuming I'm right and it is a change.
So is it even a change, and if so is it a good one... that's what I want to discuss here. Andrewa (talk) 10:02, 12 September 2019 (UTC)
The third example (the first "don't do this" example) changes from * to ::. This instructs the parser to close the first-level bulleted list, start a first-level unbulleted list (it's more complicated than that, but for this description it will suffice), and then start a nested second-level unbulleted list. This leads to extra announcements by screen readers to indicate the end of the bulleted list and the start of two unbulleted lists. The appropriate markup to use instead is *:, as shown in the second example, which keeps the first-level bulleted list and starts a nested second-level unbulleted list. The visual appearance of these two is the same, but with a lot less extraneous announcements for the recommended approach.
The key aspect to understand is that the colons, asterisks, and number signs aren't indent levels. They declare both the start of a list of a specific type, when added to the end of a string of these characters, and a list item within the list. So changing any of the existing characters will reset the list types, causing extra announcements from screen readers. New characters can be added at the end, as this creates a new nested list without changing the previous list types. Yes, this is because we are abusing the HTML markup to fit legacy conventions, solely due to the appearance of the HTML markup. But for better or worse, that's where we are now. isaacl (talk) 16:04, 12 September 2019 (UTC)
Regarding the question of what type of format to use in discussions: there is some work underway by the Wikimedia foundation, which included gathering feedback from the different language Wikipedias—see Wikipedia:Talk pages consultation 2019. So maybe something will come out of that. For now, personally I don't see an arms race to use bullet items based on greater prominence and thus I don't think bullet items are inevitable for that reason. I think most newcomers emulate what they see others use, and so as long as unbulleted items are still in prominent use, some of them will pick up that usage. isaacl (talk) 18:55, 12 September 2019 (UTC)
@Andrewa: Yes, you are missing something. The green ticks and red crosses each refer to the two-line example that follows them. So there are two examples which are acceptable, and four that are not. There is a simple rule to remember:
  • When replying to any post, copy the markup from the start of the post that you are replying to, paste this at the start of a new line and add one symbol to the right-hand end of that. Do not leave any blank lines.
This additional symbol may be colon, asterisk or hash, it really doesn't matter. If you consider the examples at WP:INDENTMIX, the first two obey that rule, the other four do not. --Redrose64 🌹 (talk) 19:42, 12 September 2019 (UTC)
If person B has replied already to person A, then it matters a little: it is better to follow what person B has used as the additional symbol in order to avoid an unnecessary end-of-list/start-of-list announcement, similar to when a blank line is left between first-level list items. isaacl (talk) 21:14, 12 September 2019 (UTC)
  1. This reminds me of the situation of a childhood friend. His house had a screen door, and the parents were constantly yelling at the kids for leaving it open and letting flies in.
Even after constant threats and punishments managed to browbeat their own children into always closing it, the neighbor kids would leave it open, causing the parents to complain to other parents in the neighborhood about their children not following the rules.
  • One day one of the neighbors got tired of them trying to control the behavior of the entire world, walked up to the screen door, and installed a spring-operated automatic closer. Problem solved.
We have a similar situation with lists and accessibility.     The real problem is that the WMF software [A], misuses HTML lists to do something that isn't what HTML lists were designed to do, and [2] does so in such a way that when users act in ways that are perfectly normal the WMF software generates malformed lists that screw up the screen readers used by the visually impaired.
  1. Then we try to compensate for WMF's screw up with MOS rules.
  • The WMF could easily make software that outputs accessible HTML no matter how we use colons, asterisks, and octothorpes. You could, of course still have oddly-placed bullet points, numbers and indents --- but such errors would be clearly visible to the sighted editor. I'm just saying. --Guy Macon (talk) 14:05, 12 September 2019 (UTC)
It can be changed, but the problem is legacy uses would be affected, and there is far too much objection from the community for that to proceed. isaacl (talk) 16:07, 12 September 2019 (UTC)
  • What legacy uses would be affected if the Wikimarkup remained the same but the HTML output sent to the browsers was changed? --Guy Macon (talk) 16:45, 12 September 2019 (UTC)
    Assuming no change to the wiki markup, the parser would be making new assumptions on the meanings of the characters in question. This can potentially break instances where the old assumptions were intended: there may be some cases where complicated nestings of lists were intended. Probably not too many, but they would have to be reviewed. The more likely way forward, I believe, is along the lines of the discussion at Wikipedia:Talk pages consultation 2019/Phase 2, with new markup introduced for discussion sections and threads. isaacl (talk) 17:08, 12 September 2019 (UTC)
    @Guy Macon: Does your post of 14:05, 12 September 2019 (UTC) intentionally use badly-formatted list markup? --Redrose64 🌹 (talk) 19:43, 12 September 2019 (UTC)
Yes. It also purposely has too many spaces after one of the sentences, and purposely labels the points with [A], [2], and {third}. These formatting errors are easily seen by all users, and anyone using the preview button would see them and know to fix the formatting. Contrast this with the "formatting errors" we are talking about, which are only noticeable by the tiny percentage of Wikipedia users who are using a screen reader. My point isn't that we should ignore the needs of that tiny percent (although it is OK to do so in a single comment to illustrate bad formatting on a page where the odds of a blind person reading the talk page is vanishingly small and it would only be a minor inconvenience to any that do show up), but rather that this is the sort of thing that is bound to happen -- a lot -- because the editor making the edit doesn't see any problems.
Did you and isaacl purposely indent your comments with "::*:" when placing them below a a comment (no, not the single comment containing deliberate errors) indented with "::*"? --Guy Macon (talk) 22:05, 12 September 2019 (UTC)
I followed the rule that I gave above - I copied the markup ::* from the post that I was replying to, and added one symbol. I used a colon because I dislike using bullets in discussions except in special cases - such as at the start of the line where I state the aforementiobed rule. --Redrose64 🌹 (talk) 22:41, 12 September 2019 (UTC)
I changed my prefix to match Redrose64's, in order to avoid an extraenous list end and list start from occurring. Yes, it sucks that avoiding extra announcements requires this level of attention. isaacl (talk) 00:51, 13 September 2019 (UTC)
Several comments... first, please remember that most editors never read the “rules” about how to use colons, bullets or do indenting in general. They simply learn by doing, following what they see everyone else do. Second, to give my personal insight into all this - at the moment, I have no idea when I am supposed to indent and when I am supposed to use a bullet, etc ... nor do I really care to learn. I am content to make it up as I go along. I have looked at the current guidance and find it too confusing to follow.
That said, if “the rules” were to be simplified, I (and, I think, most other editors) would be quite willing to at least try to follow them.
Finally, I am a firm believer in not writing rules that no one will follow (even if those rules make sense and are correct)...
SO... please DO simplify, but simplify in a way that the average editor is likely to follow... don’t fall into the trap of writing rules that you think the average reader SHOULD follow. I suggest creating a draft of simplified rules, and posting periodic notices at the Village pump to get commentary from the wider community to see if what you come up with will actually BE followed. Blueboar (talk) 23:50, 12 September 2019 (UTC)
Redrose64's basic rule given above is the one simplified rule that can be followed, which is the same rule I discuss on User:Isaacl/On wikitext list markup (I just have more explanation about the motivation for it, but people who don't mind not knowing can ignore that). But... it doesn't matter if some people don't follow the rule, as long as they don't mind someone else fixing it up later. (It would be nice if some people did follow it, to minimize the overhead for others.) I agree it kind of sucks that best practice relies on copying a string of characters correctly, but that's what we have now. It's possible that something will change as a result of the talk page consultation being held by the Wikimedia foundation. isaacl (talk) 00:41, 13 September 2019 (UTC)
The simplest fix is to encourage editors not to use bulleted/numbered lists for threaded comments. The colon markup is perfectly adequate and doesn't cause problems for screenreaders (as long as extraneous blank lines are not added). That makes multi-paragraph comments simple and allows you to use an actual bulleted or numbered list within your comment, when needed, without causing confusion with other editors' comments. In the case of !votes like RfA, we can still use bulleted or numbered lists in the support or oppose sections, as those are not threaded discussions (or at least they shouldn't be) and semantically each is a list (of supports or opposes). Of course, it's never going to happen because of all the I-demand-the-right-to-do-it-my-way compulsives that abound on Wikipedia. --RexxS (talk) 16:21, 13 September 2019 (UTC)
Because, as Blueboar says, everyone infers best practices rather than reading about them somewhere, some editors have invented elaborate rules on using bulleted versus unbulleted items. I've seen an editor say they use a bullet for a new point, and a colon when following up on an existing point, and (if I recall correctly) strongly insist this is common practice. In the discussion on Andrewa's talk page, one editor likes to use a bulleted item for the first paragraph in the comment, and switches to unbulleted items for the subsequent paragraphs. Many editors, presumably under the impression that colons represent indent levels, consistently change all of the characters to colons and then add an asterisk or colon at the end. I agree it would be helpful for numbered and bulleted lists to only be used within your own comment and not as a response to someone else's comment. That way editors would only have to deal with a string of colon's, with possibly one different character at the end. But... yeah, it's unenforceable. isaacl (talk) 17:20, 13 September 2019 (UTC)
  • I agree with you both. In the last year or two I've started to notice an upswing in people sticking an indented bullet in the middle of a thread for no apparent reason. EEng 21:30, 13 September 2019 (UTC)
    IMO the reason is simply to draw attention to their post, without the negative effect of SHOUTING but with much the same effect. And that's what two "offenders" said (admitted?) in my previous discussion on my user talk page too. That's why I came here.
    And it's a downward spiral. The above is appalling to me. Not to anyone else?
    IMO we should go back to the old usenet standard of a single indenting convention. I'd even like to reinstate the ability to interleave new comments, it was always obvious to me who said what and in reply to what (if the convention was followed of course). It leads to logical, focused discussion, and gives a clear and logical means of replying to long posts and creating substrings. But I guess that's a lost cause.
    Of course the world has changed. Welcome back to chaos? Andrewa (talk) 20:26, 14 September 2019 (UTC)
    As I said, I don't feel it draws my attention more than the other comments, so that particular motivation doesn't bother me. (The bold you used in your comment is more intrusive to me, to be honest.) Editors trying to enforce particular layouts on Usenet weren't particularly celebrated there any more than on Wikipedia. But quoting conventions become supported by clients, and later on in web-based bulletin board software. In a similar manner, if the talk page consultation comes out with a new interface, for example, that can manage threads better but without losing the power of wikitext that many desire, things may improve. isaacl (talk) 22:05, 14 September 2019 (UTC)
    So, why do you do it? What does it achieve?
    My use of both bolding and capitalisation above was to display what I see as unhelpful shouting. Agree that it is intrusive and unhelpful there. That was the point. Bolding below however I feel is helpful. It's similar IMO to bolding Support or Oppose in an RM survey. Interested in other views.
    And that's the main issue here. What is helpful in building the encyclopedia? What helps to build consensus? The question of enforcement comes later, and hopefully not at all. Wikipedians should want to follow the guidelines, especially ones they don't agree with. If we only follow the ones we agree with, there's not a lot of point in having them. Andrewa (talk) 06:10, 15 September 2019 (UTC)
    Bulleted items? I mostly use them in response to person A if the first reply to A started with a bulleted list, to avoid an extraneous end of list/start of list, or to avoid shifting from a bulleted list to a nested unbulleted one, purely for esthetics. I'm no more likely to read a bulleted item than an unbulleted one, but I am more likely to read a bold word than a normal weight one. I disagree with the bold below (or in the immediately preceding comment) being helpful, though I fully understand it was intended to be—and that's part of the problem of trying to set guidelines. How do we reach a set of non-contradictory guidelines? Volunteer time being limited, editors tend to focus on building consensus for content-related matters. isaacl (talk) 06:51, 15 September 2019 (UTC)
    But the question was and is whether edits such as this one should be bulleted. Not whether bullets should be used in reply to bullets.
    So I still wonder, why do you do it? What does it achieve? Andrewa (talk) 20:55, 15 September 2019 (UTC)
    You asked So, why do you do it? What does it achieve?, so I thought you were asking me, not asking me why someone else used a bulleted item in a specific instance. I don't know why the editor chose to use a bulleted item; maybe the editor finds it easier to read. But... more relevant to your argument is whether or not other readers are actually perceiving a bulleted item as having greater prominence, regardless of the writer's intent. isaacl (talk) 00:21, 16 September 2019 (UTC)
    Yes, I asked that and you still haven't answered.
    It would help to know this, because you may have a good reason for doing it. The two who have replied at User talk:Andrewa#Mixed indents have both said it's to call attention to their post, and it may be that this is the only reason people do it.
    And if that's true, then it seems to that it's a form of shouting and it would be better if they didn't do it. Andrewa (talk) 01:43, 16 September 2019 (UTC)
    I already gave my answer for the circumstances where I use bulleted items. Maybe somewhere I've used a first-level bulleted item to make an initial comment, but I can't remember doing so. I can't tell you why I do something that I don't do. Those two editors might think they are giving their comments greater prominence, but that doesn't necessarily make it so. isaacl (talk) 03:40, 16 September 2019 (UTC)
    OK, so returning to the original question, you can't think of any good reason to bullet an edit such as this one, but you don't think it should be discouraged either, is that a fair summary? Andrewa (talk) 04:54, 16 September 2019 (UTC)
    I don't personally have an issue with discouraging the practice. I've already stated my support for using unbulleted list items. I recognize, though, that my reasons are related to semantics and esthetics, and I appreciate my reasoning may not be accepted by a wide audience. isaacl (talk) 05:09, 16 September 2019 (UTC)
(Replying to RexxS 16:21, 13 September but to me the indenting makes it obvious) Exactly. An RM survey is an example of a bulleted list, and there are others such as RfCs, AfDs, etc.. But in discussion, it's in the interest of almost everyone to stick to the colon, IMO. (We all have moments when we're tempted to subtle disruption I think! Welcome to being human.) Andrewa (talk) 21:09, 14 September 2019 (UTC)

Redundant bullets

Here is another very recent example of a bullet that seems to have no valid function. Comments? Andrewa (talk) 10:42, 18 September 2019 (UTC)

Bolding

There's some discussion above about whether bolding is helpful. To me it is on occasions, and I think that's what our guidelines say too.

I use it for two purposes, and think both are in keeping with current guidelines. Excessive bolding is shouting, but the occasional bolded word is fine.

One is as a leading summary, notably in RM and similar surveys to indicate Support, Oppose, Comment, closing comment, Relisting comment... there may be others but those are my normal ones in RMs. And similarly in informal discussion I sometimes preface my reply by Agree and bold that word. I think this helps others (including but not only an RM closer) to assess the flow and direction of the discussion or survey.

The other is to indicate raised voice in mid-sentence. This can subtly but significantly change the meaning of the sentence, and on occasions makes it more intelligible IMO. Or to reiterate: Excessive bolding is shouting, but the occasional bolded word is fine. To me that bolding helps to make the meaning clear, by making it quite clear that Excessive bolding is the only sort I mean. Interested in other comments.

I offer this as an example of both. Andrewa (talk) 01:36, 16 September 2019 (UTC)

WP:REDACT

- WP:REDACT and WP:REDACTED redirect to Wikipedia:Talk page guidelines#Editing own comments - perhaps this should be changed to WP:RETRACT and WP:RETRACTED to prevent confusion with Redaction, an Admin's ability to redact edits, that is, hide and delete page revisions (Wikipedia:Revision deletion#Criteria for redaction) - Epinoia (talk) 00:16, 27 September 2019 (UTC)

Where to add new issue?

Can someone point out where to add a new issue? At the end, at the top, or below the most similar issue, maybe at a higher indent level? (Apologies if it's already there and I couldn't find it) Uhw (talk) 20:55, 1 November 2019 (UTC)

The guideline is already too long and I'm not sure adding more explanation to it would help. At any rate, if it's a new issue, post in a new section at the bottom using "new section" as you did for this section. If there is a similar issue on the talk page, add it there at the bottom of the section, probably after a blank line and with no indent. However, don't do that if it's old. Instead, if the last timestamp is, say, a month ago, post a new section and mention that the issue is similar to the old one above. How-to questions can be asked at WP:HELPDESK and questions on other matters can be asked at WP:REFDESK. Johnuniq (talk) 21:17, 1 November 2019 (UTC)

Posting notices about discussions on articles

I just suggested this guideline might be an appropriate place for a guidence being suggested at WP:VPR#Discussions about articles on Noticeboards should leave a note on the relevant talk page. Dmcq (talk) 17:46, 21 November 2019 (UTC)

Definition of a personal attack is...off

Right now these guidelines claim, in the section Wikipedia:Talk page guidelines#Behavior that is unacceptable, that a personal attack is "saying something negative about another person". That is of course utter nonsense. Not all personal attacks take the form of saying something negative about a person (threatening them or doxxing them are examples listed in this very guideline), and by and far not everything negative said about someone is a personal attack. AddWittyNameHere 03:36, 19 November 2019 (UTC)

I agree. As there has been no movement on this issue for over a month, I've marked the statement as disputed in the hope that it will attract more editors to this discussion. --RexxS (talk) 17:26, 5 January 2020 (UTC)
- WP:NPA and WP:FOC say, "comment on content, not the contributor" - making negative comments is focusing on the contributor, not the content - it is possible to point out inappropriate behavior of editors by stating facts and citing guidelines instead of making negative comments - see WP:AGF and WP:AAGF - "In cases where you feel that someone definitely needs to be cautioned for interpersonal behavioral issues...consider citing a policy applicable to the situation, such as Wikipedia:No personal attacks, Wikipedia:Civility, or Wikipedia:Harassment and alternatively approach for administrator attention." - Epinoia (talk) 17:45, 5 January 2020 (UTC)
@Epinoia: If I have to warn or sanction an editor whose contributions have been poor by telling them that their editing has been below the standard required, I say something negative about them, no matter how you try to couch it. This guideline calls that a "personal attack", which is patent nonsense. Your assertion that "it is possible to point out inappropriate behavior of editors by stating facts and citing guidelines instead of making negative comments" is demonstrably untrue. "Stating facts" often involves saying something negative, sometimes unavoidably. --RexxS (talk) 19:17, 5 January 2020 (UTC)
WP:CONDUCTDISPUTE suggests that conduct should be dealt with on user pages, which is covered by WP:UP. This page,WP:TPG, deal with article talk pages, where focusing on content applies. Part of the problem is "Talk page guidelines" sounds very generic, as if they apply to user talk as well.—Bagumba (talk) 19:05, 6 January 2020 (UTC)
Not every issue where it is unavoidable to say something negative about another person is a pure conduct issue; not all conduct issues are best brought up only on user talkpages. Some issues are a mixture of content and conduct in such a way that raising the one without the other is impossible. For that matter, not everything negative said about another person is about another editor. To give two examples:
  • If I use the article talkpage to explain the removal of content that at a quick glance may look reasonable, but that was part of a since-blocked editor's POV-warring campaign, I am saying something negative about that editor and commenting upon conduct. It is, however, relevant on that article's talkpage and not something I ought to raise on the blocked user's usertalk instead, and I am certainly not engaging in personal attacks.
  • If I use the article talkpage of a BLP to discuss how to word said living person being convicted of fraud, which of a myriad of available references are preferable, and where in the article it makes most sense to put it, I most definitely am saying something negative about someone. I am not, however, engaging in personal attacks. AddWittyNameHere 20:02, 6 January 2020 (UTC)
@Bagumba: I never mentioned user talk pages. WP:CONDUCTDISPUTE fails to consider the case when multiple editors are involved. A guiding principle is that discussions should not be split over multiple pages, and it is quite normal for an uninvolved admin to step in on an article's talk page and issue warnings to more than one editor about substandard behaviour in that article or on its talk page. That will generally involve commenting negatively, but justifiably, on individuals' behaviour, and will have the added effect of acting as discouragement for other editors to join in on the behaviour. This guidance oversimplifies what a personal attack is, and consequently fails to reflect accepted practice. It needs to be revised. --RexxS (talk) 22:01, 6 January 2020 (UTC)
OK, I wasn't reading it literally or from the perspective of a less experienced user. It seems the problem is that Wikipedia:Talk_page_guidelines#Behavior_that_is_unacceptable tried to generally define personal attack with a single sentence, which the actual policy page Wikipedia:No_personal_attacks#What_is_considered_to_be_a_personal_attack? doesn't even attempt to do. Perhaps this is a solution: "No personal attacks: A personal attack is saying something negative about another person. This includes:"—Bagumba (talk) 11:44, 7 January 2020 (UTC)
@Bagumba:: works for me. I'd keep the link to Wikipedia:No_personal_attacks, of course, and for grammatical pedantry, I think it should read "These include:" (since it now refers to a plural). Cheers --RexxS (talk) 21:47, 7 January 2020 (UTC)
Works for me as well. Flyer22 Reborn (talk) 05:54, 8 January 2020 (UTC)
And for me too. AddWittyNameHere 16:26, 8 January 2020 (UTC)

Rule of thumb

What does "rule of thumb" mean?

Specifically, does it mean a) that we can point to WP:TALKCOND to ask editors with user talk pages in far excess of (currently) 75K to trim/archive their pages? or does it mean b) that we can't do that

If b) then what is the purpose of having a "rule of thumb"? As opposed to having a well-defined policy or guideline on one hand, or having no numerical target at all on the other?

If a) then why not have the number specified be the actual target? (Much like, say, the limit of words in a tv episode, where if a summary is even 401 words it means at least some editors will put up a cleanup template) My question is: why say 75K if we allow twice as much? Why not then have the guideline say 150K? Why have a "rule of thumb" if that only means editors can disagree how much is too much? Three times as much? (225K) Five? (375K) At this point, maybe it's better to drop any numeric target at all; meaning that even if my user talk page is 1M or 10M the community won't enforce trimming? (Editors might ask me to trim it but nothing happens if I won't)

Remember, this wording "rule of thumb" has remained unchanged for years and years. It is also very non-standard in our guidelines, so I think it's about time to question the usefulness of having a numeric target that still doesn't work like all our other numeric targets.

information Note: Unlike the previous talk page section, this one is not about the actual number (whether it should be 75 bytes, 75K or 75M). You can discuss this here.

Your input is welcome. CapnZapp (talk) 11:23, 26 February 2020 (UTC)

  • If you think that someone may not be aware of this rule of thumb then of course you can point it out once politely, but it is that editor's choice whether to take any action. There is certainly no point in telling someone about it who you know already knows. Phil Bridger (talk) 14:11, 26 February 2020 (UTC)
    So not binding. Thanks for replying, I did not know "rule of thumb" carried that meaning, but then again, I'm not a native English speaker. CapnZapp (talk) 16:44, 26 February 2020 (UTC)
  • @CapnZapp: "Rule of thumb" means that yes, you can point to TALKCOND to ask people to archive their user talk page, but also that they can reply with "no". It's there mostly as a suggested starting point for archiving article talk pages, to provide guidance for when archiving article talk pages is helpful without being overzealous, since like DGG says elsewhere, there's value to keeping closed discussions around for reference. Strictly speaking, user talk pages are a subset of talk pages as a whole, so yes, this suggestion could be considered relevant to them, but it's no more than that. And as Phil says, if they're already aware of the guideline (as EEng, for example, clearly is), there's no point in bringing it up to them, because as a rule of thumb, it's not binding. Writ Keeper ⚇♔ 15:04, 26 February 2020 (UTC)
    So not binding. Thanks for replying, I did not know "rule of thumb" carried that meaning, but then again, I'm not a native English speaker. CapnZapp (talk) 16:44, 26 February 2020 (UTC)
  • "Rule of Thumb" means "You can't make me" It's merely a phrase that allows assholes to violate rules without consequences. Either it's an enforceable rule or it's meaningless. I would remove it and say something like "Users should archive talk pages when they get too large. If a user is warned for having an unmanageably long user talk page, and refuse to comply with requests to archive it or delete old threads to bring it into compliance, they may be sanctioned with blocks until they comply". If you aren't willing to do that, there is no point in even writing a suggestion. --Jayron32 15:25, 26 February 2020 (UTC)
    Thanks for replying. It will be interesting to see what, if any, change to the wording we end up with CapnZapp (talk) 16:44, 26 February 2020 (UTC)
    So in your view any guideline is worthless if not accompanied by an iron-fist enforcement mechanism guaranteeing 100% adherence? EEng 16:58, 26 February 2020 (UTC)
    Nope. Just this one. If you would like to start a discussion on the wording of another guideline, start the discussion on that guidelines talk page, and we'll see what we can do. Other guidelines may or may not need enforcement because they aren't making pages unusable. This one is, and thus needs more teeth to make it useful.--Jayron32 17:02, 26 February 2020 (UTC)
    Your reasoning makes no sense. It would still be useful even if, despite the lack of the iron fist, it nonetheless prompted 80% or 60% or even 30% of users to keep their pages short. EEng 00:23, 27 February 2020 (UTC)
    Users who already keep their page short enough don't need the help. It's only users who, after being told why having a stupidly long page is harmful, respond with "I don't care, I'm not shortening it unless there's a rule that forces me to." That's who we need a rule for. People who either archive on their own, or who maybe get absent minded, or when you say "hey, can you archive your talk page, its length makes it hard to read" and say "No problem, I'll get right on that!" don't need guidance. They just solve their problems on their own, or understand the importance of being collegial in a collaborative workspace. It is people who adamantly refuse to be useful, even after being told why they are causing problems, who need rules. --Jayron32 20:36, 27 February 2020 (UTC)
    You're enumerating combinations of predicaments and attitudes that may apply to various species of editors, but that doesn't exclude their being yet another species you're simply ignoring i.e. those who, without guidance, won't understand that archiving is often desirable, but if there is guidance, will understand and do it, all other things being equal. And that can be true even without an enforcement mechanism. So it's just not true that unless user can be sanctioned with blocks until they comply then there is no point in even writing a suggestion. EEng 22:37, 28 February 2020 (UTC)
  • Rather than asking random people on the internet, you'll get better, more reliable information from this online encyclopedia that anyone can edit called Wikipedia. Rule of thumb: The English phrase rule of thumb refers to a principle with broad application that is not intended to be strictly accurate or reliable for every situation. It refers to an easily learned and easily applied procedure or standard, based on practical experience rather than theory. This usage of the phrase can be traced back to the seventeenth century and has been associated with various trades where quantities were measured by comparison to the width or length of a thumb. As to why we have a rule of thumb and not a specified number, see the fifth pillar ("no firm rules"). Levivich (talk) 16:54, 26 February 2020 (UTC)
Insinuating I'm asking "random people on the internet" is just ridiculous. If you don't believe this is the proper place to have this discussion, feel free to suggest a more appropriate venue. Please don't link to the general encyclopedia; this issue is about Wikipedia's own policies and guidelines, and regular article space don't apply. Please don't use a generic argument like "no firm rules" like a blunt instrument - we have quite specific limits in several areas, and you need to argue why this can't be one of them. CapnZapp (talk) 15:18, 28 February 2020 (UTC)
  • Also see the "folk etymology" section of rule of thumb which, despite being more-or-less debunked, is widely enough believed to cause the phrase to be very offensive to some people. Maybe we can find a different phrase to use that doesn't lead to that reaction. —David Eppstein (talk) 01:19, 27 February 2020 (UTC)
My priority is using a phrase that makes it clear what the number (currently 75K) signifies. I can't think of another guideline mentioning a number but then assigning zero relevance to it, at least without giving further context. Can you? Regards, CapnZapp (talk) 15:18, 28 February 2020 (UTC)
It's not "zero relevance", and WP:IAR has already been brought to your attention. Once you've grasped rule of thumb I suggest you contemplate wikt:tone-deaf (sense 4). EEng 15:51, 28 February 2020 (UTC)
Your attempts to derail or belittle this discussion only paints you as a fool, EEng. Since me and other editors have actual issues with the current wording of the guideline, please don't come running with "ignore all rules". As other editors have already understood, our issue is not a failure to grasp rule of thumb, but to question why we're using language that not only does not provide any guidance in a guideline, but actually obscures that behind language nobody can agree what it means. CapnZapp (talk) 11:30, 3 March 2020 (UTC)

Examples

Notice that today's FA – Zoo TV Tour – is 138K. The other day we had The Cabinet of Dr. Caligari at 127K. The pages are just about a single topic and their talk pages should likewise be limited to discussion of that topic. A user talk page, however, may cover any number of topics because users can and do edit numerous different subjects. My own talk page is about 400K and that's because it covers divers topics, from article number 5 million to article 6 million and a fair few in between. I chip away at it from time to time but it's a laborious process because there is no standard mechanism. Having had to develop my own filing system, I'm now inclined to keep my own counsel on how to proceed. As editors are likely to be the most active readers of their own talk pages, they need no prompting from others nor an arbitrary guideline. Andrew🐉(talk) 22:07, 29 February 2020 (UTC)

But... but... unless there's a bright-line rule, and an iron-fist enforcement mechanism, editors will be adrift, without guidance or compass, and chaos will reign! EEng 23:26, 29 February 2020 (UTC)
My reflection at this point in time is that this discussion attracts comments from editors whose own talk pages are far larger than 75K, and that they are opposed to regulating user talk page size. CapnZapp (talk) 11:30, 3 March 2020 (UTC)
Man, you're quick! EEng 21:58, 3 March 2020 (UTC)
My talk page is about 25 K long (thanks to Jimmy Wales pushing it over that number yesterday) and it will, depending how many people want to talk to me there, probably grow to about twice that size before I archive it - still well within the current rule of thumb. That is big enough for my needs, but I understand that there are editors who get involved in many more user talk page discussions than I do so may need to have a much larger talk page. There are two conflicting forces at work here: the need of users on slow or unreliable connections (such as mobile in some places) to access a small talk page, and the need to avoid archiving discussions where someone might comment further. In the case of prolific editors these forces may come into conflict, so the "owner" of the talk page needs to make a judgement, which is helped by gentle advice rather than strict enforcement. Phil Bridger (talk) 16:28, 5 March 2020 (UTC)
As for me, I understand the need to be reasonable; I do not understand the need to be uniform. I am halfway to bringing it back to reasonable, as I have done periodically, but it will still be about 400 K. I consider that the right size for what I want to do, and as has been explained by others, it should not make difficulty on any current computer or tablet. phones, not yet, but I'm working on it.
As for the general question, the first step for bring things uptodate is to change the 75kB to 150kB. regardless of what is decided otherwise, that's the minimum needed change) DGG ( talk ) 00:10, 7 March 2020 (UTC)
I'm with DGG, including the need to archive more from my own talk page. But since we are increasing the amount of stuff with longer talkpage newsletters, and the technology is improving whilst data contracts are generally getting cheaper, I suggest a rule of thumb of 10kb per year of this millennia. That puts it on 200kb now and automatically increases it to 300kb over the next decade. The advantage of such a rule of thumb is that it won't date as badly. ϢereSpielChequers 16:05, 17 March 2020 (UTC)

Use Template:Do_not_archive_until?

Sorry if this has already come up, the discussion itself is too long to be sure I've read it carefully, but DGG can you just tag the threads you want to retain with a do not archive template, then set the page to automatically archive anything older than 30 days? Apologies if this is butting in unhelpfully. --valereee (talk) 14:29, 6 March 2020 (UTC)

I'm not DGG, but the answer is yes. For an example, see the wikitext of Talk:Latino (demonym) #Argumentative sock blocked where the {{DNAU|730d}} shortcut is used inside the post. The instructions at Template:Do not archive until/doc give more detail. --RexxS (talk) 18:30, 6 March 2020 (UTC)
I'm not DGG either, but please note he was asked to clean up his talk page already two years ago. It is clear that this guideline is trying to both eat and have the cake. Either rephrase it to give the community the mandate to make users clean up their mess, or rephrase it to make it clear the community allows unlimited user talkies. CapnZapp (talk) 08:34, 12 March 2020 (UTC)

Summary so far

It's been a couple of days with no new discussion. My conservative summary is that there is a clear opposition to having a binding guideline, leaving it up to each user. In other words, that a significant part of the community is okay with user talk pages of any length.

Since there is also a significant part of the community that feels this is not made clear by the current phrasing (including me), I believe the best course of action to progress the issue is to make a BOLD edit to attempt to rectify this. Feel free to give your input on the impending edit. CapnZapp (talk) 10:37, 17 March 2020 (UTC)  Done CapnZapp (talk) 10:45, 17 March 2020 (UTC)

guidance on talk page size

On the subject of how large one's user talk page can get, as far as I know, this page is the only policy or guideline page to discuss it. The current phrasing is As a rule of thumb, archive closed discussions when a talk page exceeds 75 KB or has multiple resolved or stale discussions. WP:TALKCOND

I searched the archives. Unless I'm mistaken, this question has not been discussed since 2012: Wikipedia_talk:Talk_page_guidelines/Archive_9#The_guideline_is_outdated_and_should_be_changed_completely.

Q. Should we increase the limit† on talk page size from 75K?
†) Yes, I'm aware it's a rule of thumb and not a hard limit.

The benefit of of an increase would be to ease enforcement. It is incredibly hard in cases where a user has a much too large talk page to argue "you need to trim it to 75K". "75K??" they say, "that's nothing!".

You might think "but how about letting the editor off the hook if they reduce it to 100K or 200K..." but that just suggests the number is out of date. I mean, if we have a guideline or rule of thumb, what it specifies is really the only reasonable target. What's the point of bothering users to follow our guideline, and then not having the guideline as the target? (And if you want to argue "but don't bother the user then", you're really arguing for the limit to be increased or removed altogether).

Mostly to focus our discussions, how about I offer a specific change suggestion.

Proposal: Change the following sentence

from

As a rule of thumb, archive closed discussions when a talk page exceeds 75 KB or has multiple resolved or stale discussions.

to

As a rule of thumb, archive closed discussions when a talk page exceeds 150 KB or has multiple resolved or stale discussions.

Cheers, CapnZapp (talk) 17:11, 22 February 2020 (UTC)

I'm very leery of participating in a discussion that speaks of "enforcement" and "letting users off the hook" in the context of something so trivial as talk page size. EEng 17:21, 22 February 2020 (UTC)
I think the editor kindly gave DGG two weeks to take care of things. Of course, DGG and you, EEng, are the worst offenders, haha. You doing alright? I was going to leave a note on your talk page but my laptop would crash! ;) Drmies (talk) 17:36, 22 February 2020 (UTC)
What are you talking about? I'm down to 400K. And as everyone knows it's the images that count, not the text. EEng 17:42, 22 February 2020 (UTC)
Mea culpa! Drmies (talk) 22:09, 22 February 2020 (UTC)

I'm happy to rephrase the start of the discussion, User:EEng. Even better, feel free to start a new talk section where you raise the issue in your own words, and I'll close this one. Let us not derail into discussing decorum. CapnZapp (talk) 08:25, 24 February 2020 (UTC)

  • I deliberately retain closed discussions which I think to be of continuing general interest , and many people have been appreciative of this. But it is currently too long--I think perhaps half the size would be much more practical. : The excess size of my page is because I have not kept up-to-date in removing those that are no longer of general interest or have been superseded by other discussions, or in removing those which the intent was not to keep them once they were closed-- the need to remove old material is to focus on the important current material. The need to keep the page within limits is to facilitate using the contents. I One possible solution for this I might consider is hatting discussions, to reduce the rendered size in the browser. DGG ( talk ) 22:21, 22 February 2020 (UTC)
    Oh, DGG , you're so sweet in your innocence. Hatting has absolutely zero (read: ZERO) effect on bandwidth usage, load times, memory usage, processor cycles, or anything else whatsoever -- other than the amount of scrolling someone has to do to get to the bottom of the page. EEng 01:09, 23 February 2020 (UTC)
User:DGG I will be much more comfortable discussing issues pertaining to your talk page on your talk page. Let this discussion be about the general "rule of thumb" that we then apply equally to everybody. Cheers CapnZapp (talk) 08:27, 24 February 2020 (UTC)

As most of the guidance on article size at WP:SIZESPLIT seems to be applicable to talk pages as well, increasing the recommended size limit before archiving clearly runs counter to most of the considerations we already endorse. Consequently, I think it would be better to change this guidance to:

As a rule of thumb, archive closed discussions when a talk page exceeds 50 KB or has multiple resolved or stale discussions.

Optionally, we could re-use the ranges suggested on SIZESPLIT to present more nuanced guidance here. --RexxS (talk) 17:43, 24 February 2020 (UTC)

Any change here should also deal with a requirement that users have a talk page, and keep relevant material on it long enough to be discussed. I recognize this will invovle a much larger change. DGG ( talk ) 18:10, 24 February 2020 (UTC)
  • WP:CREEP. SIZESPLIT is for articles and is motivated by almost completely different reasons (besides, in the end, being hopelessly cookie-cutter even for articles). I continue to find it incredible that people are focused on the text size of the wikisource, which is nothing compared to even a single image on a page. For article talk pages, I suppose we could suggest that resolved (or unresolved but stale) discussions should be archived sooner or later when they're no longer useful for e.g. the edification of later visitors (whenever that is), and particularly if there are several of them. If that means human judgment is needed, and sometimes leaves multiple large discussions and a large page overall, so be it.
    For user talk pages, let's see the evidence that there's a significant problem that needs solving, much less one that needs solving via some mindless rule. EEng 21:00, 24 February 2020 (UTC)

(edit conflict)

RexxS

As a counter-argument, most of the rationale behind SIZESPLIT revolves around a human reader's limited capacity for long articles. An editor's capacity for a long talk page I would think is only distantly related - for one thing, your business on a talkie seldom involves more than a single section at a time. CapnZapp (talk) 21:09, 24 February 2020 (UTC)

DGG

Short counter-argument: no, I'm simply discussing if 75K remains appropriate in this day and age?
Longer: You need to have to be much more specific, DGG, about what you mean by "a requirement that users have a talk page" and "keep relevant material on it long enough", or your comment will likely not be understood and maybe even disregarded. It's not that I have to explain to you that you're free to split up a very long page into several user talk subpages of manageable size. Or that the subject of an archived talk section can be "re-opened" simply by starting a new talk section to resume the discussion. Cheers! CapnZapp (talk) 21:09, 24 February 2020 (UTC)
User:EEng What is your specific suggestion? That we remove any numeric rule of thumb entirely? Just chiming in to call the current phrasing "mindless" is not constructive. Cheers CapnZapp (talk) 21:12, 24 February 2020 (UTC)
I'd be fine with removing the number entirely. EEng 21:24, 24 February 2020 (UTC)
@EEng: Did you actually read SIZESPLIT? "SIZESPLIT is for articles and is motivated by almost completely different reasons" – that's patently untrue. SIZESPLIT gives five considerations:
  1. time to read the page – there is no evidence that readers can read talk pages any quicker than articles, so the guidance applies equally;
  2. some users have a low speed service – there is no evidence that users' service speed increases on talk pages and slows down for articles, so the guidance applies equally;
  3. some users have unstable connections – there is no evidence that users connection stability is greater on talk pages than articles, so the guidance applies equally;
  4. some users have a pay per kilobyte service – there is no evidence that users' service gets cheaper for talk pages than articles, so the guidance applies equally;
  5. some users may access Wikipedia through a mobile phone or smartphone whose browsers might truncate long pages – there is no evidence that smartphone browsers truncate less on talk pages than on articles, so the guidance applies equally;
How do you square those with your assertion "motivated by almost completely different reasons"? That really is well off the mark.
@CapnZapp: Even though readers may often read one section or thread of a talk page per visit, it is just as likely that readers may often read just one section of an article. In fact our statistics show that a significant number of visits to an article are brief, suggesting the reader only looks up a single fact before moving on. Your assertion that "most of the rationale behind SIZESPLIT revolves around a human reader's limited capacity for long articles" is clearly false, as most of the rationale behind SIZESPLIT revolves around other factors, and I've demonstrated that by quoting the five considerations given in SIZESPLIT. Why not address the actual guidance there, rather than making up your objections to it? --RexxS (talk) 00:03, 25 February 2020 (UTC)
SIZESPLIT is indeed about articles and issues about their size related to reading and navigating them; one sentence offers some questionable claims about unstable connections and so on. Find evidence that significant numbers of editors have browsers that truncate long pages and then we'll talk. EEng 01:08, 25 February 2020 (UTC)
I disagree with your summary of SIZESPLIT as being about five equally important criteria, User:RexxS. It's about readability, and then also that "some users" have technical issues. More importantly, SIZESPLIT concerns article space, not talk space, so if you want to be a stickler for procedure, which I think you need to be to argue there are five equally important criteria, then it is also true that none of the five criteria are relevant at all. Anyway, arguing whether SIZESPLIT applies only muddles the issue, stealing away focus from the question asked here. You are certainly free to argue for a 50 kB rule of thumb, no need to involve SIZESPLIT, and it has been noted. Thank you. CapnZapp (talk) 09:51, 25 February 2020 (UTC)
@EEng: "questionable claims" only in your opinion. SIZESPLIT has project-wide consensus, and there is no indication that the five factors there apply any less to talk pages than to articles. You find evidence that those factors affecting articles don't affect talk pages and then your opinion might be worth listening to.
@CapnZapp: I disagree with your contention that the five factors are not of equal importance. For any given reader, one or another may be the most important; it's no help being the world's fastest reader if you can't get a connection to the article you're trying to read. It's not just about readability. The factors raised in SIZESPLIT go right to the heart of this question, and SIZESPLIT has project-wide consensus that it contains useful guidance. Those factors are clearly relevant when discussing the present question, and must carry far more weight when trying to reach a conclusion on the best figure to use for guidance than your suggestion which seems to be a figure plucked out of thin air, with no rationale behind it. --RexxS (talk) 13:51, 25 February 2020 (UTC)
SIZESPLIT has project-wide consensus – That's odd, because right at the top it says it has not been thoroughly vetted by the community.
The handwringing about truncation and so on was added in 2011 with no discussion at all. Even, generously, assuming that that was in fact a realistic issue at that time, I renew my call for evidence that it remains an issue ten years later. EEng 17:49, 25 February 2020 (UTC)
It was a problem in Firefox 3,[2] and Firefox 3 is still listed in the mw:Compatibility#Browser support matrix. (Inclusion is generally determined by a certain percentage of traffic.) WhatamIdoing (talk) 19:20, 25 February 2020 (UTC)
Someone posts to stackoverflow that some big (we don't know how big) page (not a Wikipedia page) was being truncated in some way, for some unknown reason, on Firefox ==>3<== in ==>2009<=== (six weeks into Obama's first term, if that helps set context) and based on that we're supposed to be worrying about page length here on this project in 2020? Uh huh. Got anything else? EEng 22:44, 28 February 2020 (UTC)
You seemed to be having trouble believing that it was considered a realistic problem when this was added in 2011. I have demonstrated that there were rational reasons for this concern at the time. There are links to relevant reports in Mozilla's bug database in the replies, if you want to learn more about it. Whether we should care about readers using old hardware that can't be upgraded past Firefox 3.5? Well, the MediaWiki devs apparently do, but I won't tell you what your values should be. WhatamIdoing (talk) 02:10, 7 March 2020 (UTC)

information Note: At this time, I extended an invitation to the Village Pump for more input. Cheers CapnZapp (talk) 09:58, 25 February 2020 (UTC)

  • I'm happy with retaining the present rule of thumb, but would emphasize that it is simply a rule of thumb, not something that should be enforced on anyone. I would also note that there seems to be some confusion above. The proposal doesn't seem to be about talk space, but user talk space, which is seen as a partial exception to WP:OWN. Phil Bridger (talk) 10:14, 25 February 2020 (UTC)
As far as I am aware the guideline does not separate between user talk and regular talk, and the rule of thumb therefore applies equally to both. Please tell me if I'm wrong (since the language explaining this could then probably be improved). Having separate guidelines would of course be one reasonable argument to make... CapnZapp (talk) 10:18, 25 February 2020 (UTC)
As for "it is simply a rule of thumb, not something that should be enforced on anyone" I consider that a separate second issue. When we have agreed on a number (or not to have a number etc) I plan on asking what a "rule of thumb" means (in a separate talk page section), unless someone beats me to it of course. Let's just not discuss it here intermixed with my original question above, please. Cheers CapnZapp (talk) 10:20, 25 February 2020 (UTC)
"Rule of thumb" is a perfectly normal English phrase, not something that requires an idiosyncratic definition on Wikipedia. It being a rule of thumb there is no material difference between 75K and 150K. Phil Bridger (talk) 11:35, 25 February 2020 (UTC)
If you want, we could set up a second talk section right now. CapnZapp (talk) 14:27, 25 February 2020 (UTC)
Why on Earth would I want that? As I said, "rule of thumb" is a perfectly normal English phrase that already has a standard meaning. Why should Wikipedia editors give it a different meaning? Phil Bridger (talk) 14:36, 25 February 2020 (UTC)
Then you will have no problems answering my questions over here, Phil: #Rule of thumb. Cheers CapnZapp (talk) 11:25, 26 February 2020 (UTC)
No, by all means let's not intermix one misbegotten, pointless discussion with another misbegotten, pointless discussion. Pointless discussions should proceed in an orderly fashion. EEng 11:49, 25 February 2020 (UTC)
Reminder thumb ribbon
Remember..
Thumb sucking
The Rule of Thumb
  • I'd rather see talk pages reverse chronology so I don't have to scroll through all the old crud on the excessively long pages. Other than that, 25kb/75kb/1mb, as long as you aren't takes minutes to load, shrug Slywriter (talk) 14:56, 25 February 2020 (UTC)
    ^^^ THIS. When can we change this to be in line with how the rest of the world works? Levivich (talk) 18:02, 25 February 2020 (UTC)
    Lev, see how I get the creative juices flowing with a simple comment? That must be why they call it a "Talk page". lol Atsme Talk 📧 20:45, 25 February 2020 (UTC)
    We shouldn't be trying to do what the rest of the world does, but what is best for Wikipedia. For example, the rest of the world does not create the world's foremost encyclopedia, or follow our basic content policies. I see the forward chronology of talk pages both as obviously logical, and as something to be praised. People should look at previous discussions on talk and user talk pages before commenting themselves, rather than risk continual repetition. Phil Bridger (talk) 18:37, 25 February 2020 (UTC)
    I do not find that argument persuasive. When people go to a user's talk page to start a new discussion, they press the + or "new discussion" button at the top. They don't read the whole talk page. If anything, putting the most-recent discussion at the top of the talk page will increase the chances that a new visitor to the page will read it and avoid repetition. Talk pages come in two flavors: (1) those that aren't archived, which nobody is going to read because they're too long, and (2) those that are archived, and few editors will read through someone's archives before staring a new thread–even a keyword search is more effort than most will put in. So, I don't think forward chronology is any kind of improvement on the reverse chronology that is the standard for just about every other type of text-based communication software ever made. There's a reason everyone uses reverse chronology: the most recent communications are the most important, and thus should be the easiest to get to (the least scrolling). If we were really in the 21st century, or even the late 20th, we would have recently-edited sections automatically moved to the top of the page. Levivich (talk) 19:42, 25 February 2020 (UTC)
    Finally, something Levivich and I completely disagree on. I suggest we carry out the debate in Burma-Shave format. EEng 00:08, 26 February 2020 (UTC)
    OK here's the Burma-Shave summary of my argument above:
NO ONE READS
WHEN IT'S TOO LONG
NO ONE READS
WHEN IT'S ALL GONE
NEW THREADS SHOULD GO AT THE TOP
THE OTHER WAY IS WRONG
Burma-shave
Other than readability, the 75K limit is probably lower than it needs to be. My recommendation is that any guidance other than "don't overload server or blow past Wiki-software limits" or "don't make loading and editing the page impractical for a significant portion of users" should be over-ride able by "local consensus" or for a user's own talk page, by that user. So if we decide it's 75K, but the local consensus on a particular talk page says 200K, and that's not going to cause technical problems for the server, editors, or readers, then 200K it shall be for that particular talk page. davidwr/(talk)/(contribs) 17:40, 25 February 2020 (UTC)
  • The portion of the talk-page size attributable to discussion of forming a local consensus as to what the talk-page size should be – will that count toward the size limit, or will it be deductible?
  • Server resources expended with each page load or cache purge – Are you joking? Am I just dreaming that it's 2020? Is it really still 1999? EEng 18:19, 25 February 2020 (UTC)
EEng 18:19, 25 February 2020 (UTC)
@EEng: I wasn't joking about the server limits or more accurately, software limits. Two recent discussions where these had an impact are here and here (2nd is article-page-related). There are several Wikipedia tracking categories devoted just to listing pages affected by these limits. You can find them listed among the other tracking categories at Special:TrackingCategories. It's my understanding that some of these limits exist not because the Wikipedia servers are wimpy (they are not) but rather to make it a bit harder for someone to do a denial-of-service attack on them. I think I read that over on Meta or one of the other Wikimedia projects, but unfortunately I don't remember where. davidwr/(talk)/(contribs) 20:29, 25 February 2020 (UTC)
You didn't say anything about server limits or more accurately, software limits being a relevant consideration for a possible page-size limit; you talked about Server resources expended with each page load or cache purge, which is quite different and none of our business whatsoever as editors (with the narrow exception of template editors) – see WP:PERFORMANCE. EEng 23:21, 25 February 2020 (UTC)
My initial choice of wording was imprecise and in retrospect, misleading and confusing. davidwr/(talk)/(contribs) 23:40, 25 February 2020 (UTC)
Indeed. EEng 00:03, 26 February 2020 (UTC)

Alternative proposal: How about we remove all specific thresholds for user talk page length per WP:CREEP. We should be worrying about article content, not policing other people's talk pages. The penalty for having a talk page that is long enough to be cumbersome is that, in the natural course of events, people who comment there will complain about it. That should be sufficient; we don't need rules and bright lines and penalties for noncompliance. —David Eppstein (talk) 19:45, 26 February 2020 (UTC)

I wouldn't have any problem with some guidance on the subject, but it seems that there are lots of busybodies around who can't see a bit of guidance for what it is, rather than an excuse to hassle people. I would prefer to do away with the busybodies, but it seems that that sort of editor has become the majority here, so maybe we should do away with the guidance so they can do their unencyclopedic busywork elsewhere. Phil Bridger (talk) 22:16, 26 February 2020 (UTC)
What value do you ascribe to the way the guideline mentions a specific number, Phil? CapnZapp (talk) 15:22, 28 February 2020 (UTC)

If we disregard the comments that basically amount to "let's not have this discussion" without providing any substantial arguments as to why not, it seems there is no consensus (on agreeing on a particular number). The larger discussion is in the section below, so I'm holding off further comment here in the meanwhile. CapnZapp (talk) 11:20, 3 March 2020 (UTC)

It's been a couple of days with no further discussion. Please see #Rule of thumb below. CapnZapp (talk) 10:34, 17 March 2020 (UTC)

Note that with recent changes, the language used As a rule of thumb, archive closed discussions when a talk page exceeds 75 KB or... no longer applies to user talk pages, only article talk pages. I suggest further discussion is taken to a new talk page section for clarity. CapnZapp (talk) 07:47, 25 March 2020 (UTC)

Article talk page size

This is a comment, not a request for change:

Currently (see above for previous discussion) our guideline offers the following:

"Large talk pages are difficult to read and load slowly over slow connections. As a rule of thumb, archive closed discussions when a talk page exceeds 75 KB or has multiple resolved or stale discussions – see Help:Archiving a talk page."

I do think the guideline offered is obsolete. If a talk page is very active, it has (automatic) archival set up already. If it isn't, the number and age of inactive discussions/sections have a much larger impact than checking the size against some number. And we really should recommend automated archival: manual archiving needs to be repeated, can easily be set up in a manner not compatible with later auto-archival and is generally more trouble than it's worth imho.

If an (article) talk page feels "too large", an editor might ask for and set up automated archival, but I don't think that happens already at 75 KB. And even if it feels "too large", if it isn't growing, it's usually such a low-impact problem that most editors simply leave it be anyway. Our guideline would probably be better off if it reflected this common sense. CapnZapp (talk) 08:00, 25 March 2020 (UTC)

User talk page size

This is a comment, not a request for change:

Currently (see above for previous discussion) our guideline offers the following:

"The length of user talk pages, and the need for archiving, is left up to each editor's own discretion."

I personally don't see how this gels with the much more important "User talk pages must serve their primary purpose, which is to make communication and collaboration among editors easier."

  1. There are user talk pages that are a nightmare to navigate. Fact.
  2. Some of these users have failed to clean up their user talk pages even after repeated friendly reminders over years. Fact.

I realize this particular guideline isn't strictly required to make these users clean up their act, and I realize the overall impact on Wikipedia is minimal ("just don't visit"), so I guess leaving it be is okay.

However, that depends on WP:USERTALKBLOG being an appropriate venue for resolving conspicuous cases, since that's the only place we link to. Since this isn't a "dispute" between two editors, but rather reporting one editor to the greater community, if community discussion at Miscellany for deletion is not a proper venue, we might consider tweaking our language here to not send concerned editors astray. CapnZapp (talk) 08:12, 25 March 2020 (UTC)

Section headings

I think this guideline is problematic. What if someone starts a section headed "Mangoes", a discussion develops, and then an editor says, "'Mangoes' looks weird; I'm going to change the heading to 'Political timing'". Now, maybe the discussion has drifted off to a point where "Political timing" makes sense as a heading. However, when the section was originally started, "Mangoes" made sense, and "Political timing" made no sense at all. The original posting then becomes incomprehensible. Why did Wacko Jacko make a posting about "Political timing" and then ramble on about mangoes? Effectively, people who have gone off topic are rewarded and are able to colonise the discussion. It would be better for people who have gone off on a tangent to start their own discussion with a new heading, rather than taking over Wacko Jacko's section. Simply because other people want to discuss political timing, does not mean that mangoes are unimportant.--Jack Upland (talk) 09:09, 5 January 2020 (UTC)

In what way is Wikipedia:Talk page guidelines#New topics and headings on talk pages "problematic"? It already says
"Make a new heading for a new topic"
and
"Make the heading clear and specific as to the article topic discussed".
--Guy Macon (talk) 14:55, 5 January 2020 (UTC)
I was referring to the paragraph on "Section headings" under Wikipedia:Talk page guidelines#Editing others' comments.--Jack Upland (talk) 23:18, 6 January 2020 (UTC)
OK, I see what you are talking about.
What say we replace
"It can also sometimes be appropriate to merge entire sections under one heading (often preserving the later one as a subheading) if their discussions are redundant."
With
"It can also sometimes be appropriate to merge fragmented discussions under one heading or to split a discussion into two sections if the topic drifts."
--Guy Macon (talk) 15:52, 7 January 2020 (UTC)
That would probably be better. But I don't see why this guideline exists. If this was regularly practised it would cause so many problems:
  • It doesn't say not to change the heading if that changes the meaning of other posts. Many new posts are of the form: "Mangoes: Why is this important?" Changing this to "Political timing: Why is this important?" completely changes the meaning. It also changes the meaning of subsequent posts such as, "I agree" or "Reliable sources say this is important". It can be hard to see other editors' points of view and ascertain whether a change in heading affects what they said.
  • It says to discuss the change with the original poster if the change is likely to be controversial. This seems to promote discussion about the discussion, Talk page talk, which is undesirable. It doesn't say you need consensus, so how is the change decided? Clearly, since it says the original poster doesn't "own" the heading, the original poster has no right of veto.
  • It gives editors carte blanche to go over old posts where the original poster is uncontactable and change the headings to what they consider to be appropriate.
  • It encourages fussy, bossy behaviour, interference with other people's postings, and petty disputes. Why, why, why?--Jack Upland (talk) 17:46, 7 January 2020 (UTC)
please correct me if I am wrong, but it sort of sounds like you disagree with
"Because threads are shared by multiple editors (regardless how many have posted so far), no one, including the original poster, "owns" a talk page discussion or its heading. It is generally acceptable to change headings when a better heading is appropriate"
In particular you mention "interference with other people's postings" as if the header was part of the post.
I think the flaw here is in the "discuss the change with the original poster if the change is likely to be controversial" advice. That's bad advice. The change should not be controversial in the first place. Misuse of headers is rampant, and it is always appropriate to replace a one-sided header like "Definition of a personal attack is...off" with something neutral and descriptive such as "Definition of a personal attack". --Guy Macon (talk) 01:39, 8 January 2020 (UTC)
Yes, I disagree with the guideline that the original poster doesn't "own" the heading. To a greater or lesser degree, that heading is an integral part of the post. It is contradictory to say "Don't edit other editor's comments", but do change the heading. I think recommending a discussion is problematic however you look at it. The best policy, however, is avoiding conflict, which you have done by ignoring that other heading.--Jack Upland (talk) 02:23, 8 January 2020 (UTC)
Trying to fix everything on Wikipedia is like drinking out of a firehose. I only fix non-neutral headings when they are causing a problem.
As to who owns the heading, there appears to be an overwhelming consensus against doing it your way. I could be wrong, of course; an RfC would settle the question. --Guy Macon (talk) 12:03, 8 January 2020 (UTC)
I don't know whether this creates problems in articles about zoology or Renaissance drama, but in politics articles and other contentious areas, it tends to invite pointy and POV title-tweaking that's not helpful and causes its own set of problems. I think Jack Upland has identified room for improvement here. SPECIFICO talk 15:33, 8 January 2020 (UTC)
I think this could create problems across the board. People use a variety of headings ranging from "Hey Yankee!" to "Definition of a personal attack is...off". These might not fit the guidelines. I've been editing almost since Wikipedia began, and I've never seen those guidelines. I don't understand how there can be an "overwhelming consensus" in favour of editing original headings if there is "Misuse of headers is rampant" and "Trying to fix everything on Wikipedia is like drinking out of a firehose". This guideline isn't being enforced. Editors have voted with their feet. This guideline is just a licence for an officious busybody to selectively change headings he or she doesn't like, thereby generating pointless conflict.--Jack Upland (talk) 08:41, 20 January 2020 (UTC)

Could someone summarize if this discussion actually led to any change? Thx CapnZapp (talk) 15:38, 21 March 2020 (UTC)

No, it hasn't.--Jack Upland (talk) 00:46, 23 April 2020 (UTC)

Feedback requested at Talk:Great Chinese Famine

Your feedback is requested at Talk:Great Chinese Famine#Proposed rollback to April 14 in connection with dispute resolution and proper use of Talk pages. Thank you. Mathglot (talk) 19:45, 24 April 2020 (UTC)

Proposed change to off-topic discussions guideline

This page contains our guidance on collapsing off-topic talk page discussion, part of which currently reads These templates should not be used by involved parties to end a discussion over the objections of other editors. I propose that it be changed to These templates should not be added or removed by involved parties to end or restore prominence to a discussion over the objections of other editors. The rationale is that it is best to have uninvolved editors judging whether or not a discussion is off-topic, and that this should apply both ways. Just as an editor who doesn't like a thread isn't allowed to curtail it by collapsing it over others' objections, an editor who insists on perpetuating a discussion everyone else agrees is off-topic should not be allowed to keep it prominent by un-collapsing it. I think this largely reflects current de-facto practice. Note that this guideline does allow editors to continue commenting in a collapsed thread if they want, and this proposal will not change that. Sdkb (talk) 22:43, 11 March 2020 (UTC)

Well, since you made a bold edit, and User:EEng reverted you, and you brought up the issue her on talk, the next step is for him to explain his reasons why. If he doesn't, and no-one else objects, feel free to simply reinstate your changes. It's too early for the support/oppose game. CapnZapp (talk) 08:28, 12 March 2020 (UTC)

As it stands, the guideline favors continued discussion and discourages peremptory cutoff. You've put cutting off on the same footing as continuing. As it stands, the guideline favors continued discussion and discourages peremptory cutoff. Your change puts cutting off on the same footing as continuing. Adding a followup comment to a collapsed thread is nice, but that doesn't change the fact that the collapsed thread is still nominally closed, and discussion is cut off for all practical purposes. EEng 13:22, 12 March 2020 (UTC)
Why would we want to favour continuation of an off-topic discussion? --RexxS (talk) 13:34, 12 March 2020 (UTC)
Like it says later in the guideline's paragraph Your idea of what is off topic may differ from what others think is off topic, so be sure to err on the side of caution – the question often becomes clear only with continued discussion. EEng 13:52, 12 March 2020 (UTC)
Hmmm, and I've been t-banned for "continued discussion" and reprimanded for it despite the BRD restriction. I always the "D" in BRD was DELETE because editors have been discouraged from discussing issues on TP; the latter of which may have been a determination born of inadvertent bias, or so it seems. Atsme Talk 📧 15:01, 12 March 2020 (UTC)
@EEng: I agree that we should err on the side of uncollapsing when it's borderline or unclear whether something is off-topic, and I'm fine retaining the sentence from later in the paragraph in the guideline. I'd like to have my addition because I think the decision on where that line is is better made by uninvolved editors. I agree with RexxS that in situations where everyone else recognizes the line has been crossed and a conversation is off-topic, it's best that involved editors don't revert them to uncollapse the thread. Sdkb (talk) 21:25, 12 March 2020 (UTC)
Any examples where that's been a problem? EEng 23:18, 12 March 2020 (UTC)
@EEng: There was something tangentially related which prompted me to propose this, but I forget exactly what and can't be bothered to find it again now. It's not a hard situation to imagine, though, is it? I'm sure it comes up every so often. {{u|Sdkb}} talk 12:30, 2 April 2020 (UTC)
In almost every discussion, only editors who are "involved" are aware of the discussion. Also, it's common for people to collapse their own comments. This rule might not be a good one. Maybe we need something more like "Don't edit war over collapsing off-topic stuff"? WhatamIdoing (talk) 02:37, 17 March 2020 (UTC)
@WhatamIdoing: There are different levels of "involved"; the sense I interpret it to mean here is an editor who has made one of the comments others are trying to collapse or an editor who has directly argued against one of the points in a comment that may be collapsed. And I think there is a place for this policy to exist in some form — the community needs to have the authority to basically clerk itself. {{u|Sdkb}} talk 12:34, 2 April 2020 (UTC)
So maybe "Don't edit war over collapsing off-topic stuff, especially if the content is about you". WhatamIdoing (talk) 00:16, 3 April 2020 (UTC)
@WhatamIdoing: "Don't edit war" is basically the message in the proposal, but I think it's better to spell it out a bit, since just saying "don't edit war" gives a first-mover advantage. I'm not sure how to gauge consensus here; would there be objection to me trying to add it again to see if it sticks? {{u|Sdkb}} talk 08:34, 22 April 2020 (UTC)
Maybe not? If I collapse your comment, and you revert me, and I revert your reversion, then it's me that's starting the edit war, right? I think your reversion should be understood as being in the style of WP:BRD. WhatamIdoing (talk) 19:21, 22 April 2020 (UTC)
@WhatamIdoing: True. Circling back to your earlier point about editors collapsing their own comments, I think that's mostly covered by "over the objections of other editors" in the proposal. "Don't do things over the objection of other editors" is basically the same message as "don't edit war". Are there any specific changes you'd want made to or language you'd prefer for the sentence? {{u|Sdkb}} talk 13:35, 29 April 2020 (UTC)
Maybe These templates should not be used to end a discussion over the objections of other editors? Or "Don't edit war over collapsing or hiding comments"? Specifying a default rule, e.g., "In case of a dispute over hiding comments that you can't resolve through discussion, it's usually better to err on the side of leaving comments visible", might help. But it might be unnecessary, too. WhatamIdoing (talk) 20:12, 29 April 2020 (UTC)
@WhatamIdoing: I'd be okay with These templates should not be used to end or restore prominence to a discussion over the objections of other editors. Would that address your concerns? {{u|Sdkb}} talk 21:15, 30 April 2020 (UTC)
User:Sdkb, thank you (very much) for the pings. Can you explain how one uses a template such as {{collapse top}} to "restore prominence" to a discussion? That sounds a bit like using scissors to make your hair longer. WhatamIdoing (talk) 00:55, 1 May 2020 (UTC)

@WhatamIdoing: It would be through removing that template. (and I'm happy to ping or not ping, just lmk your preference) {{u|Sdkb}} talk 01:09, 1 May 2020 (UTC)

You may freely ping me whenever you want my attention, including if you pinged me before and I haven't answered your question after a couple of days.
So "use this to restore prominence" actually means "not-use this to restore prominence". This is not the right way to write that.
Is the key point that if you collapse my comments, then you don't want me to un-collapse them? WhatamIdoing (talk) 01:21, 1 May 2020 (UTC)
@WhatamIdoing: Well, the way I wrote it at the top was (italics added) These templates should not be added or removed by involved parties to end or restore prominence to a discussion over the objections of other editors. And the idea isn't that it's never okay to uncollapse comments (I agree with you that in borderline cases, uncollapsing should be the default), but rather that the community should be able to clerk itself when needed. That's the "over the objections of other editors" at the end. {{u|Sdkb}} talk 01:56, 1 May 2020 (UTC)
Which takes us back to "Don't edit war". Do we need to re-state the normal rule in this context? WhatamIdoing (talk) 22:31, 2 May 2020 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia_talk:Talk_page_guidelines/Archive_13&oldid=1137335471"