Wikipedia talk:Talk page guidelines/Archive 14

Telling editors to include DATE AND TIME in {unsigned}
I claim the guideline should read
 * Attributing unsigned comments: If a comment is unsigned you can find out, from the page history, who posted it and append attribution to it, typically using {{subst:Unsigned}}:.

Another editor wants it to read
 * Attributing unsigned comments: If a comment is unsigned you can find out, from the page history, who posted it and append attribution to it, typically using {{subst:Unsigned}}:.

I challenged this editor to exhibit a recent example of anyone including the date and time (much less in the rigid UTC format that allows it to be adjusted properly for each editor's time zone when the page is displayed)  but so far that challenge has gone unmet. Like the cat that ate some cheese and stood outside the mouse hole, I wait with baited breath. EEng 03:12, 13 March 2020 (UTC)
 * Since there's a bot that is set to do this as a task (expand out the unsigned template to add the D&T), I see no point in forcing that on the user adding it. If the user adding the the unsigned template wants to add it, sure, let them, but by no means is it required, knowing we have automation in place for this. Its similar to the reference archival bot we have. --M asem (t) 03:16, 13 March 2020 (UTC)
 * EEng, you are being misleading here. The implication of your post is that "another editor" wants to add text that was not there previously, and you are objecting to that addition - your selection of diffs also suggests this. The truth is that the text concerned - i.e.  - was already there, and is long-standing. It can be traced back ten years to  made by ; and even that, minus the  tags, goes back even further, to  in 2007. You removed it, I reverted you, and then you removed it a second and indeed third time, both being reverted by . Diffs: ; ; ; ; ; and . Your claim of "It's not edit warring to unrevert once (or even twice) with clear reasoning" in the fifth of those diffs is not supported by WP:EW, much less by WP:BRD.
 * I don't see your confusion regarding UTC format: these are easily obtained from the top of the diff, or from the page history - simply copypaste the relevant text. -- Red rose64 &#x1f339; (talk) 10:33, 13 March 2020 (UTC)
 * There's nothing misleading. You think it should be one way, I think it should be another way. And we have a 3RR rule for a reason.
 * The confusion re UTC is yours. The timestamp from a diff or page history is the time in your timezone. If that's pasted into {unsigned} it will be displayed, unchanged, to all editors regardless of what timezone they're in, unlike properly formatted UTC timestamps which are modified automatically to provide, for each individual editor, a consistent timeline of posts, each with its timestamp adjusted for his or her timezone. By inserting into that timeline a static timestamp tuned to your random timezone, you make a complete mess of that timeline; better to have no timestamp at all.
 * Any progress on finding even one recent example of someone using the timestamp parameter? EEng 12:10, 13 March 2020 (UTC)
 * Perhaps we should be asking you for evidence of one recent example of someone adding the template without using the timestamp parameter. --RexxS (talk) 20:24, 13 March 2020 (UTC)
 * I invariably attribute unsigned edits using unsigned2 because that is set up to allow a copy from the history. I do this several times a day, on average, and always include the timestamp. DES (talk)DESiegel Contribs 21:18, 11 May 2020 (UTC)
 * I use the xsign template (my time is set to UTC): Examples –xenotalk  17:09, 13 March 2020 (UTC)
 * - OK, but what would happen if your time wasn't set to UTC? And how can any normal editor (read: not you or me or others with the technical understanding to be participating in this discussion) be expected to understand such details? EEng</b> 18:01, 13 March 2020 (UTC)


 * Anyone who wasn't able to wok out a time in UTC is probably uninterested in adding {unsigned}. On the other hand, folks won't learn how to use {unsigned} unless they have some guidance. That's why we have this guideline. --RexxS (talk) 20:24, 13 March 2020 (UTC)
 * So we have the guideline to explain how to use {unsigned} to people who don't know how to use it, and it's OK that it doesn't actually explain how to use it because people will already know. That makes sense. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 00:55, 16 March 2020 (UTC)


 * , I see what you did there :D --valereee (talk) 10:38, 13 March 2020 (UTC)
 * You mean the baited breath? Yes, I've been waiting a long time to use that. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 11:46, 13 March 2020 (UTC)
 * Totally stealing it next time I see someone write that. --valereee (talk) 12:26, 13 March 2020 (UTC)
 * I regularly use unsigned with a date-and-time stamp; in fact I even had unsigned2 created to facilitate that. Here's ; ; . Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 12:45, 13 March 2020 (UTC)
 * I specified "in the last week" for a reason, and perhaps I should have added, "other than by technogeeks". Where did you copy the timestamp from? <b style="color: red;">E</b><b style="color: blue;">Eng</b> 13:47, 13 March 2020 (UTC)
 * Indeed you did; fortunately I'm not bound by your specification. Try reading the latter template's documentation. And then WP:DROPTHESTICK. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 16:55, 13 March 2020 (UTC)
 * P.S. You wrote, at the top of this benighted section, "I challenged this editor to exhibit a recent example of anyone including the date and time...". Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 16:56, 13 March 2020 (UTC)
 * I wrote, in the diff I just linked, "in the last week". But it doesn't matter where I wrote that or whether I repeated it. The point remains that I'm hoping for evidence that normal editors, not technogeeks and template editors, have been able to absorb how to add timestamps properly. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 18:01, 13 March 2020 (UTC) P.S. What "latter template" are you referring to?
 * I also regularly use, but EEng asked for uses by other people. One such is , for example with . -- Red rose64 &#x1f339; (talk) 12:56, 13 March 2020 (UTC)
 * I've since found by . -- Red rose64 &#x1f339; (talk) 17:54, 14 March 2020 (UTC)
 * Sorry, doesn't count. It needs to be from the seven days immediately preceding the opening of this thread. Obviously you emailed this editor privately and put them up to this. For shame! <b style="color: red;">E</b><b style="color: blue;">Eng</b> 23:39, 14 March 2020 (UTC)
 * I did no such thing. I resent that accusation and I require you to provide proof that I carried out what I have always held to be inappropriate conduct. -- Red rose64 &#x1f339; (talk) 11:36, 15 March 2020 (UTC)
 * Neither nor anyone else emailed me, but I was pinged above (and once again above). I often come across questions at the Teahouse or on other talk pages that are unsigned. Sometimes I leave them for, but do add them if it appears that the bot has missed doing so. I always use unsigned or unsigned IP and just follow the template documentation and am pretty sure that I always leave an edit summary linking along the lines of “Added missing signature per WP:TPG” when I do. There are lots of examples of me making this type of edit to be found in my contributions history which took place well before this discussion was started and I’ve always made these edits in good faith in accordance with what I thought was be best practice. If that’s not the case, then fine and I’ll follow whatever the best practice is; however, my making the edit referenced above by Redrose64 had nothing to do with this discussion. —- Marchjuly (talk) 22:38, 15 March 2020 (UTC)
 * C'mon, you two have just got to be pulling my leg. You can't possibly have thought I actually meant that. Oh my God! <b style="color: red;">E</b><b style="color: blue;">Eng</b> 00:46, 16 March 2020 (UTC)
 * I've always used unsigned with the timestamp ever since I put a copy of the template on my userpage to cut and paste back in 2014. The expression is with bated breath, not baited. Cabayi (talk) 13:01, 13 March 2020 (UTC)
 * No, in context it's definitely baited breath. Maybe can explain it to you. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 13:47, 13 March 2020 (UTC)
 * For those playing along at home, it was a play on words that rather elegantly utilized both a common misspelling and a common misconception as the joke. As Cabayi points out, people often misspell 'bated breath' (that is, holding one's breath, generally in anticipation) as 'baited breath,' and all of us pedantic word nerds smirk and think smug thoughts. So EEng took it a step further: by eating cheese, the cat was making his breath smell like something commonly though incorrectly believed to be the ideal bait for mice. Then he stands next to the mousehole breathing, hoping the smell of cheese breath will draw out the mouse. :D --valereee (talk) 18:15, 13 March 2020 (UTC)
 * Exactly. And then there was the swine who had the pearls cast before him, and ... <b style="color: red;">E</b><b style="color: blue;">Eng</b> 21:12, 17 March 2020 (UTC)
 * Indeed, I use it with the date parameter quite often. I'll make two further points: turning timestamps in UTC to local time isn't the default behaviour – it's a gadget; and SineBot only deals with posts that are a minute old and doesn't automatically add timestamps to posts without them that are any older (no bot does that). Graham 87 13:25, 13 March 2020 (UTC)
 * Policies and guidelines are meant to document best practice and the use of a timestamp following each signature is best practice. Not only does it help other editors grasp the timeline of a thread, but quite a few automated processes rely on signatures having a timestamp, so failing to provide one when the opportunity exists is sub-optimal. The original guidance is better than EEng's version. --RexxS (talk) 14:18, 13 March 2020 (UTC)
 * Good to know... I hate most automated processes on WP... so now I will consider intentionally omitting date and time stamps. Blueboar (talk) 18:45, 13 March 2020 (UTC)
 * We hate you too. Automated processes (talk) 20:24, 13 March 2020 (UTC)
 * It should say to include the date. This is normal practice, and it's what is done by the bot that fixes unsigned comments (when it can) anyway.  — SMcCandlish ☏ ¢ 😼  19:06, 13 March 2020 (UTC)
 * These instructions aren't for bots. Still waiting for someone to explain how editors are supposed to know how to get the right date to paste in. (not pick on you, but were were talking about it above)? <b style="color: red;">E</b><b style="color: blue;">Eng</b> 20:19, 13 March 2020 (UTC)
 * "These instructions aren't for bots" - nobody said they were, but we would expect an edit to be the same whether an editor or a bot made it. As a bot makes the overwhelming majority of these additions, our guidance for editors should mirror how that is accomplished. As for finding the right timestamp, I usually just look in the page history. I know how what timezone I'm in. --RexxS (talk) 20:32, 13 March 2020 (UTC)
 * EEng, Still waiting for someone to explain how editors are supposed to know how to get the right date to paste in. - what do you think that I wrote in the second paragraph ? -- Red rose64 &#x1f339; (talk) 20:52, 13 March 2020 (UTC)
 * What you wrote in that paragraph is this:
 * I don't see your confusion regarding UTC format: these are easily obtained from the top of the diff, or from the page history - simply copypaste the relevant text
 * ... which, in fact, doesn't tell an editor how to get the right date to paste in, unless their local timezone happens to be UTC. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 05:19, 14 March 2020 (UTC)
 * the documentation of xsign gives example usage and notes that UTC time must be used. *shrug* I don’t think this is a huge deal. Just don’t include a time if you don’t want to :) but it is still okay to explain the best way to do it. –<b style="font-family:verdana;color:#000">xeno</b><sup style="color:#000">talk  22:48, 13 March 2020 (UTC)
 * We're talking about this guideline. This guideline doesn't tell the reader what timestamp is needed or how to get it, and I shudder to think of how complicated such an explanation would have to be, especially since this is primarily a primer for naive editors. As it stands it simply invites a well-meaning editor to paste in what will likely be the wrong timestamp, which is worse than none. But it's all right. Every guideline should have just one half-baked bulletpoint that tells you to do something but leaves you in the dark about how you might do it. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 05:19, 14 March 2020 (UTC)
 * FWIW from a non-techie: after reading this discussion I still have only a fuzzy idea how to put the correct date/time in. I would assume that parameter was included in the instructions because it was important. I'd assume this was one of those templates that wasn't for me. --valereee (talk) 09:56, 15 March 2020 (UTC)
 * It's only difficult because EEng is deliberately making it seem difficult in order to scare people off. This is another of those cases where EEng will try anything to win their argument, such as accusing me of emailing totally without foundation, and for which I have not yet received an apology or even a retraction.
 * The format is very easy: at the end of your post there is a timestamp, 09:56, 15 March 2020 (UTC); and that is in exactly the format that is suitable for the template. You can even omit the (UTC) part and  will add it in for you. -- Red rose64 &#x1f339; (talk) 20:54, 15 March 2020 (UTC)
 * Yeah it's the right format of the timestamp, but you're STILL not explaining where to get the right timestamp – the particular timestamp needed – from. Now you're making it sound like they should get it from their own post or something. The timestamp can only come from a diff or page history, and it needs to be relative to UTC. If you're an editor whose preferences aren't set to UTC, there's no easy and obvious way to do that, and even if there was, the guideline gives no explanation of that at all. But like I said, it's OK – every guideline should have just one half-baked bulletpoint that tells you to do something but leaves you in the dark about how you might do it, as a monument to the blindness of technogeekism. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 00:46, 16 March 2020 (UTC)
 * See my post of 10:33, 13 March 2020 (UTC) and stop pretending. -- Red rose64 &#x1f339; (talk) 09:21, 16 March 2020 (UTC)
 * I'm really beginning to wonder what's going on with you. Your blithe assertion that useable timestamps are easily obtained from the top of the diff, or from the page history - simply copypaste the relevant text WILL NOT WORK unless you happen to have your timezone preference set to UTC. You need to absorb that if you are to participate usefully in this conversation. Really. 20:57, 16 March 2020 (UTC)
 * , you are overestimating my general level of competence. :D Speaking as someone who is a little fuzzy on the whole subst vs transclude thing, for me, EEng is not making anything seem more difficult than it is. --valereee (talk) 21:23, 15 March 2020 (UTC) ETA: testing — Preceding unsigned comment added by User: (talk • contribs) — Preceding unsigned comment added by User: (talk • contribs) — Preceding unsigned comment added by Valereee (talk • contribs) — Preceding unsigned comment added by Valereee (talk • contribs) 15 March 2020 (UTC) — Preceding unsigned comment added by Valereee (talk — Preceding unsigned comment added by Valereee (talk • contribs) 21:43, 15 March 2020 (UTC) contribs) March 15 2020 21:38 (UTC) — Preceding unsigned comment added by 6:04 pm, Today (UTC−4) (talk • contribs) — Preceding unsigned comment added by Valereee (talk • contribs) 6:06 pm, Today (UTC−4) (UTC)
 * I give up. WTF am I supposed to put in here to make it look like everyone else's? --valereee (talk) 21:45, 15 March 2020 (UTC) NM, finally got it --valereee (talk) 22:07, 15 March 2020 (UTC)
 * Valiant effort,, but (and this is not your fault) you've figured out the timestamp format, but not where to get the correct timestamp itself from. See the interaction with El C two bullets down. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 00:46, 16 March 2020 (UTC)
 * , oh, you're right...it's still saying today, even though it's now yesterday. It looks like I've signed sometime in the future. Hm. Ok, I give up. And if EENg is right that an incorrect timestamp is worse than no timestamp -- which I tend to agree with -- then we should at minimum be inserting into the instructions that adding the date and time is optional for those who know how to do it. That would be enough to warn me off. :D --valereee (talk) 09:28, 16 March 2020 (UTC)


 * Having made the mistake of reading all this stuff, my opinion is that EEng is right and nobody showed otherwise. As to the best solution, I wonder if the technical folks can make it automatically convert a date-time to UTC from the user's time zone if the magic "(UTC)" is not included. Zerotalk 12:41, 15 March 2020 (UTC)
 * gets it. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 00:46, 16 March 2020 (UTC)
 * I suppose user would work — looks like: — Preceding unsigned comment added by El_C (talk • contribs) 21:09, 15 March 2020 (UTC) . Sorry, if someone already mentioned that. Myself, I confess to usually just plain forgetting to add a timestamp to, but I should really make it a habit. El_C 21:09, 15 March 2020 (UTC)
 * No, inserts the time and date as of the time you added the unsigned template to sign for the person (let's call them Editor X) who didn't sign for themselves, and that's not the time that's needed; if you use it you'll make it look like the original post was made at a much later time, which is way worse than putting no timestamp at all. The time that's needed is the time that Editor X made the post you're signing for them. The complete confusion on this and other points (which is not the fault of those here trying to figure out how to do it using the bizarrely inadequate instructions in the guideline as it stands, but is the fault of the technogeeks gathered here who keep saying the guideline makes perfect sense) proves what a joke the guideline is. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 00:46, 16 March 2020 (UTC)
 * A guideline does not need to get into the minutiae of template syntax. For details, users can refer to the documentation of unsigned, which currently states: If this is too difficult to figure out, or you are in a hurry, then leave out the time, and only put in the date. Further improvements can be made to the documentation.—Bagumba (talk) 11:22, 16 March 2020 (UTC)


 * , I'd agree, and since the template documentation says the time stamp is optional and in another place that the date is also optional, why are we defaulting to specifying the use of both of them in this guideline? I would think we'd default to leaving them both off for this guideline. Because speaking as someone who still hasn't figured out how to correctly add them, if I read the guideline as it is right now, I'd probably conclude the use of this template was not for me. Only if I'd bothered to go read the documentation -- which is always a little terrifying -- would I have seen that the tricky part is optional. --valereee (talk) 11:34, 16 March 2020 (UTC) ETA: — Preceding unsigned comment added by Valereee (talk • contribs) 11:34, 16 March 2020 (UTC (UTC) ETA: — Preceding unsigned comment added by Valereee (talk • contribs) 11:34, 16 March 2020 (UTC) Whoa, did I do it right that time? — Preceding unsigned comment added by Valereee (talk • contribs) 11:55, 16 March 2020 (UTC)
 * "why are we defaulting to specifying the use of both of them in this guideline?" because we want editors to use both of them as it's best practice, and it makes sense that we should encourage those who are capable of figuring out the date and time to do so.
 * Your guess that "we'd default to leaving them both off" is a long way off the mark, because the template without both parameters produces this:
 * → — Preceding unsigned comment added by User: (talk • contribs)
 * which is no use to anybody. --RexxS (talk) 18:55, 16 March 2020 (UTC)
 * , by both I mean date and time. I do understand we need to specify that they fill in the username or ip parameter, but that part's easy. --valereee (talk) 19:06, 16 March 2020 (UTC)
 * See, RexxS, the negation of "use both" is "do not use both" i.e. "omit at least one"; it's not "omit both". See DeMorgan's law. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 20:36, 16 March 2020 (UTC)
 * Please don't try to patronise me. Your assertion that "I would think we'd default to leaving them both off for this guideline." is just plain wrong. See Law of holes. --RexxS (talk) 21:59, 16 March 2020 (UTC)
 * You're telling that her statement of what her own thinking is is wrong? Wow. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 05:03, 17 March 2020 (UTC)

Arbor-treeish break
Would:
 * Attributing unsigned comments: If a comment is unsigned you can find out, from the page history, who posted it and append attribution to it, typically using : or ideally but optionally.

...work for everyone? --valereee (talk) 12:10, 16 March 2020 (UTC)
 * Not really, because it still tells suggests that editors do something which they will have no idea how to do (unless they are experienced editors who don't need this guideline at all) and if they do attempt it they will almost certainly do it wrong (which, as you've so kindly agreed, is worse than nothing). I'd suggest:
 * Attributing unsigned comments: If a comment is unsigned you can find out, from the page history, who posted it and append attribution to it: . (Ideally but optionally a timestamp will be added as well – see the template documentation.)
 * <b style="color: red;">E</b><b style="color: blue;">Eng</b> 15:33, 16 March 2020 (UTC)
 * {{tq|" Attributing unsigned comments: If a comment is unsigned you can find out, from the page history, who posted it and append attribution to it, typically using {{subst:Unsigned}}: USER NAME OR IP. "}} is better. --RexxS (talk) 18:57, 16 March 2020 (UTC)
 * , you did see that it took me a dozen attempts in order to figure out how to insert the date/time stamp, and that there are arguments that an incorrect timestamp is worse than none? --valereee (talk) 19:08, 16 March 2020 (UTC)
 * , I'd agree that would be the ideal, but let's see if we can find a compromise position. :) --valereee (talk) 19:10, 16 March 2020 (UTC)
 * My proposed text above is a compromise. Originally I had proposed dropping mention of the timestamp entirely. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 20:00, 16 March 2020 (UTC)
 * Not everybody is as inept has the same difficulties as you, and the plural of "anecdote" is not "data".
 * No interest in your "compromise" that worsens the guidance. There are far too many other editors disagreeing with you, and you don't seem to be able to admit when you're wrong. Drop the stick before patience wears thin with your tendentious commentary here. --RexxS (talk) 22:09, 16 March 2020 (UTC)
 * , wow. --valereee (talk) 22:12, 16 March 2020 (UTC)
 * (Taking a break, here. Just want to calm myself down. I'm sure in the morning this is going to look less FUCKING UPSETTING.) --valereee (talk) 22:22, 16 March 2020 (UTC)
 * Don't worry about it, . The singular of "admin who barely squeaked through RfA" is not "editor whose opinion anyone pays attention to". <b style="color: red;">E</b><b style="color: blue;">Eng</b> 05:03, 17 March 2020 (UTC)
 * Except I'm not wrong, and as an admin you should know that which argument prevails depends on the strength of the reasoning, not a pile-on by people who demonstrably don't understand even the technical issue (before we even reach the question of what the guideline should say). As for before patience wears thin – and when patience wears thin, then... what? Go on, tell us. Really, tell us! I'd love to see you draw wider attention to this thread. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 05:03, 17 March 2020 (UTC)
 * But, you are wrong, no matter how much you pretend otherwise. We give the best guidance we can, and WP:PAG backs my view that you have no consensus to change an established guideline. What's next for you is me filing a complaint at WP:AN, listing your long history of edit-warring and tendentious editing over these sort of guidelines, and requesting that you be topic banned from them. If you think your behaviour here is beyond criticism, you have another thing coming. --RexxS (talk) 16:56, 17 March 2020 (UTC)
 * Another think because: see smug pedant above.--valereee (talk) 17:50, 17 March 2020 (UTC)
 * Don't kick him when he's down, . <b style="color: red;">E</b><b style="color: blue;">Eng</b> 21:10, 17 March 2020 (UTC)
 * I have no excuse. Other than being cooped up for days, but we've all got that excuse.--valereee (talk) 22:28, 17 March 2020 (UTC)
 * But, you are wrong, no matter how much you pretend otherwise – Right back at ya', Rex. The difference being, of course, that (as seen below) now that the technical issue has been competently ventilated nobody – nobody – agrees with you.
 * If you think your behaviour here is beyond criticism – I fear no scrutiny. Watch out for that boomerang!
 * <b style="color: red;">E</b><b style="color: blue;">Eng</b> 21:10, 17 March 2020 (UTC)
 * <b style="color: red;">E</b><b style="color: blue;">Eng</b> 21:10, 17 March 2020 (UTC)


 * I support either of Valeree's or EEng's proposals. Zerotalk 02:37, 17 March 2020 (UTC)

Is this so difficult?
Let's take an example. At Wikipedia talk:Talk page guidelines/Archive 13 there's a single post in a section. Let's pretend it was unsigned and we wanted to add the unsigned template: You can check by comparing the result of that template with the actual timestamp in the archive that it would produce the correct result, i.e. Epinoia (talk) 00:16, 27 September 2019 (UTC), and that those steps will always give you the result you need. --RexxS (talk) 01:58, 17 March 2020 (UTC)
 * 1) Looking at the surrounding posts, we would expect to find it in the page history somewhere between 16 September and 1 November 2019.
 * 2) So we look at the page history filtered to date 1 November 2019.
 * 3) This step is easier if you have navigation popups and can hover, but you now scan the entries to find the one about WP:REDACT (you can actually spot it from the edit summary in this case).
 * 4) It turns out to be by a user called "Epinoia" and I see the timestamp as "01:16, 27 September 2019". You may see the timestamp differently. If you have no timezone set or are not logged in, you'll see it in UTC so you can skip the next step and use it directly.
 * 5) I know that my timezone in September 2019 was UTC+1. So if UTC + 1 = 01:16 then I know that UTC = 00:16. Not rocket science.
 * 6) I could now add the correct
 * Nobody has claimed that it can't be done. The lesson that you just taught, despite your intention, is that the average editor will not go through your 6 steps in order to achieve something that is of little benefit to themselves. One look and they will decide to skip adding the template altogether. Zerotalk 02:30, 17 March 2020 (UTC)
 * Perhaps that is what happens with the "average editor", but neither you nor I have any evidence either way to prove or disprove that negative.
 * On the other hand, most editors spend a lot of time on Wikipedia doing something that is of little benefit to themselves, and we do have multiple examples of editors correctly adding the template using that sort of technique. Not one of them has suggested that they find it difficult. Perhaps you should actually try it before you start making unfounded criticisms of my teaching. --RexxS (talk) 02:48, 17 March 2020 (UTC)
 * Change little benefit to themselves to simply little benefit and the point is well made. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 05:03, 17 March 2020 (UTC)
 * Only a small fraction of accounts set a local timezone. Adding a lengthy explanation here, especially since we have no evidence that this is causing disputes in the 'real wiki world', is WP:CREEPy.
 * Also, sometimes only the name is missing, in which case adding another copy of the timestamp would be wrong. WhatamIdoing (talk) 04:19, 17 March 2020 (UTC)
 * , isn't it also true that only a small fraction of accounts edit, at all, or with any regularity, and concomitantly, only a small fraction of accounts set any preferences at all? Do we know how many active editors (>X edits in the last 30 days, however defined) set their local timezone? Levivich&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 17:42, 17 March 2020 (UTC)
 * What we can certainly say is that in the entire history of Wikipedia, only 17,531 people have switched "CommentsInLocalTime" on. (Raw numbers are a bit misleading, as someone active enough to bother switching gadgets on will be disproportionately active.) &#8209; Iridescent 17:48, 17 March 2020 (UTC)
 * , that's not the gadget I was thinking of. Correct me if I'm wrong, CommentsInLocalTime gadget changes the time on talk pages. I'm talking about the time code in histories, which is set by: Preferences→Appearance→Time offset. (I'm not sure if "fill in from browser" is the default, or UTC is the default.) Levivich&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 18:02, 17 March 2020 (UTC)
 * The default is server time. Which on English Wikipedia is UTC. -- Red rose64 &#x1f339; (talk) 19:04, 17 March 2020 (UTC)
 * Rexxs, you insist on ignoring that the current guideline merely says
 * If a comment is unsigned you can find out, from the page history, who posted it and append attribution to it, typically using : USER NAME OR IP "
 * thus giving no clue to your step 5. This is what this entire discussion has been about. For anything about DATE AND TIME to remain, it would have to be expanded to explain the UTC fiddling, and I challenge you to show us what that expansion would look like (including, I guess, telling an average editor how to figure out what their timezone offset was on an arbitrary date in the past). Absent such a demonstration (which I predict – as has WhatamIdoing – would be way CREEPy) the meaningless and confusing reference to DATE AND TIME needs to be removed, and I offer again:
 * If a comment is unsigned you can find out, from the page history, who posted it and append attribution to it: . (Ideally but optionally a timestamp will be added as well – see the template documentation.)
 * <b style="color: red;">E</b><b style="color: blue;">Eng</b> 05:03, 17 March 2020 (UTC)
 * (EEng pointed me to here). At the very least, if it tells users to include the timestamp, it should also clearly state that the timestamp should be in UTC and provide easy instructions for getting a timestamp in UTC rather than in one's preferred timezone. The current guidance is very likely to lead to incorrect timestamps, worse than none because they're harder to spot and fix. Note that the unsigned template documentation also does not provide easy instructions for getting a timestamp in UTC; its instructions require that you know what your preference offset is, that you know which direction that you are offset from UTC, and that you do some mental arithmetic to do the conversion, and beyond that are not clearly spelled out. —David Eppstein (talk) 05:49, 17 March 2020 (UTC)
 * I support EEng's proposal. Incidentally, I suspect that many UK editors don't know what "UTC" is since they use "GMT". Maybe the way forward is to start an RfC. Then we should harass the techies to make a version of that takes the timestamp in the editor's timezone (per their prefs, not per their location). Then people can just copy the time-date they see in the article history. Zerotalk 05:58, 17 March 2020 (UTC)
 * Such a template already exists, Template:Xsign, which helps with this sort of thing quite a bit though even then it is kind of a PITA. Galobtter (pingó mió) 06:05, 17 March 2020 (UTC)
 * Are you sure? Template:Xsign says "Preferences must be set to display time in UTC." which suggests that it cannot be used for time-zone conversion. Zerotalk 06:15, 17 March 2020 (UTC)
 * I don't think it's possible for template behavior to depend on your preferences. The necessary information isn't provided to them by Wikimedia. It would be possible to make a template that takes your time offset as a second argument, but then you'd have to know the offset (and remember that it changes during daylight savings time, and remember which way it changes), and even then I don't know what happens when you're viewing histories from older dates when daylight savings was different from the time of viewing. The easiest way I know of to get the UTC for a page history directly is to view the history in an incognito window. But that's still kind of a PITA and also makes editing-not-logged-in more likely. (Also, I think it's not true that Brits use GMT/UST; I imagine that like most of the rest of us they use a time preference that varies between GMT and BST according to the season. But if I'm mistaken on that, please correct.) —David Eppstein (talk) 07:13, 17 March 2020 (UTC)
 * Correct about GMT/BST. The point is that telling them to use UTC might produce only "huh?". Zerotalk 08:35, 17 March 2020 (UTC)
 * Well, correct-ish. BST is almost certainly going to be abolished in 2021, when the EU abolishes daylight saving time; although the UK is no longer bound to follow, it's very unlikely they'll hang onto it since it would mean Northern and Southern Ireland being in different timezones which would cause chaos. &#8209; Iridescent 15:31, 17 March 2020 (UTC)
 * Oops, has been too long since I've used that template. The workflow I used was to open the history page logged out (using a private tab) and then copy the history entry from there, which is definitely still easier than RexxS "six steps". Galobtter (pingó mió) 08:07, 17 March 2020 (UTC)

Changing to unsnarky section head
No, RexxS, it's not difficult. It is a bit complicated, as we can see from the need for six steps to provide a tutorial, so it's something those who are as inept as I will have to take a few minutes to learn. Not everyone will want to do that, and if we imply that both the username and the timestamp are required by instructing them to include both, many may just not bother. Or they may make an assumption about how to fill in the timestamp and get it wrong, which everyone seems to agree is worse than not including the time at all. Interestingly your tutorial isn't even touched on at the template documentation; it seems to assume no one is as inept as I. Maybe we should add it there? --valereee (talk) 09:49, 17 March 2020 (UTC)
 * I think Rexx’s six steps proves the difficulty. Six is too many steps. And when your local time zone is UTC +1, it’s easy to remember that. Mine changes throughout the year because of daylight savings time. I have to look up my UTC offset every time. This entire debate breaks down into two categories of editors: for those that use the UTC time, it’s easy to copy and paste the time code. For those that do not, it’s a pain in the ass to convert from local time to UTC time. There’s a bot that will automatically add the time code? Great, that’s one less step for a human being, one less thing we need to ask of our precious human volunteers. The guidance should suggest just using the name without the time stamp. It’s not "best practice" to add the time stamp, if for no other reason than that it adds one or more steps for humans to do, and humans can get the conversion wrong. It’s best practice to let the computer do it. We create computers specifically so that they can preform tasks that we do not have to do. We don’t write bots so that humans can mimic them. Levivich&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 13:48, 17 March 2020 (UTC)
 * What Levivich said. I have the luxury of living in the UTC time zone, and even I regularly skip over cut-and-pasting the timestamp because it's just not worth the hassle. What seems to be being missed in all the back-and-forth above is that in the overwhelming majority of cases the timestamp as we only need to know that User:Alice made the comment in question; it only even potentially becomes an issue in the very rare circumstances when we need to know whether User:Alice's comment was made before or after the comment by User:Bob, and if that ever does become an issue we can always add the timestamp retrospectively. It's a waste of time ordering everyone to follow a relatively convoluted and time-consuming procedure every time, just for a relatively slight benefit in a handful of hypothetical cases. &#8209; Iridescent 15:26, 17 March 2020 (UTC)
 * in the overwhelming majority of cases the timestamp as we only need to know that User:Alice made the comment in question – Absolutely -- that was my original point way back at the beginning. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 15:41, 17 March 2020 (UTC)

EEng, I accept your correction. As for the question under contention, I would never go through conversion steps every time I encounter an unsigned comment — I get way too many of these on my talk page alone (I've gotten five yesterday, for example — I didn't even bother unsigned-ing all of them, for that matter). Anyway, unless there's a one-step automated process to facilitate this, I will continue to leave the unsigned template I add undated. And I'm not even committing to adding it each and every time — the way I see it, there's nothing compelling me, the volunteer, to do so. El_C 15:49, 17 March 2020 (UTC)


 * Now that I'm recalling, every time I tried to add the unsigned template yesterday, Sinebot edit-conflicted me. And when I gave up on adding it, Sinebot was, of course, AWOL. C'est la vie! El_C 15:53, 17 March 2020 (UTC)

It doesn't have to be "six steps". I can just as easily give the instructions in one step: Despite all of the hand-wringing, none of this is difficult to do. --RexxS (talk) 16:57, 17 March 2020 (UTC)
 * "Find the post in the page history and copy the username and timestamp into the template, remembering to compensate for your timezone if you have one set."
 * That's not one step, that's one sentence outlining multiple steps: (1) open history in 2nd browser window; (2) find time stamp; (3) open 3rd browser window; (4) look up your UTC offset; (5) calculate UTC timestamp based on your offset; (6) fill out template; (7) publish. Steps #2, #4, and #5 are three unnecessary opportunities for human error. There is no reason that these steps should be done by people instead of bots, and no reason to require or suggest that humans do this instead of bots. The guideline should be updated with language to this effect: you can add a timestamp if you want to, but if you do, it has to be in UTC, and if you don't, a bot will do it for you. Levivich&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 17:35, 17 March 2020 (UTC)
 * Indeed. Speaking for myself, I would not bother following this somewhat involved approach due to the sheer volume of unsigned comments I encounter. As mentioned above, the prospect of adding just the undated unsigned template —often edit-conflicting with Sinebot— is annoying enough. El_C 17:37, 17 March 2020 (UTC)


 * FWIW, I never bother with the timestamp when I used Unsigned templates. First off, this six step process isn't described in the documentation. Secondly, even it was, it is an absurd amount of work for a non-essential template that people add of their own free will. Making the process for listing, say, an AfD, a bit complex. Sure. But this case? No way it's reasonable to ask people just wanting to help out with a bit of cleanup to do a six-step process. CapnZapp (talk) 17:40, 17 March 2020 (UTC)
 * WTF do people need to look up their UTC offset? I don't think I've never not known my UTC offset since I was maybe 14 or younger, no matter if I'm in a place with or without DST. I personally feel unsigned is a dumb template. xsign or unsigned2 makes things easier. Why copy twice or fiddle around with the order when you can just copy once? I personally keep edit history time stamps in UTC partly for this reason, but even if you do choose local time, it still seems easier to fiddle around with the date without messing around with the order. P.S. To be clear, I don't sign comments much, but when I do I always add the date. Since my edit history is in UTC, all it really means is I copy a slightly longer thing and then replace the space with a |. I have been using unsigned2 regardless of whether they were accounts or IPs but now that I know about xsign I will still use it.  I appreciate it's a bit more work if your edit history is not in UTC, but I think people are overestimating how much extra work it is for the plenty of people who do use UTC in their edit histories. If you don't bother to copy and paste the user name, then it is a bit more work but I find it risky to go by memory. It's easy to get the capitalisation wrong. And as for IPs.....  I still find copy and pasting on mobile annoying but frankly it just means I don't generally add unsigned templates on mobile. In a number of cases I find the date is more important than the username or IP, especially when people correctly indent which while rare for those who don't sign can happen with responses in the same thread.  Nil Einne (talk) 15:02, 21 March 2020 (UTC)

The date and time parameter is optional.
I've added this line. Does that resolve things? –<b style="font-family:verdana;color:#000">xeno</b><sup style="color:#000">talk 18:01, 17 March 2020 (UTC)
 * I think that's definitely an improvement (thank you), but I also think that the reader should be advised that if they add date and time, it must be in UTC. I would maybe add, "..., and if used, must be in UTC." (with the link). Levivich&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 18:08, 17 March 2020 (UTC)
 * I think if there's going to be a link it should be to the template documentation where (we can only hope, in some halcyon future) RexxS's steps will be clearly explained. And once you're doing that, it still seems to me that my "ideally but optionally" language, with link to template documentation, is what we want. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 18:22, 17 March 2020 (UTC)
 * I support the 'ideally but optionally' language. --valereee (talk) 18:25, 17 March 2020 (UTC)
 * Everyone should listen to the ever-wise Valereee, because even with saying "must be in UTC" that still doesn't tell the reader what time it is they're adding – way back in this thread El C thought that the timestamp was supposed to be the time the {unsigned} template was added, not the time of the original post it's being added to. So, again, why not link to the template documentation where (we can only hope, in some halcyon future) RexxS's steps will be clearly explained? And thus we circle back to the "ideally but optionally" language, with link to template documentation. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 18:22, 17 March 2020 (UTC)
 * I would have thought that the documentation page for Template:Unsigned was the best place for elaborating further, although I don't think that addition hurts. However, I do think that adding something along the lines of "... more information on using unsigned can be found at Template:Unsigned/doc" would be beneficial. That would reduce the instruction bloat in these guidelines and allow the template documentation to deal with the detail. --RexxS (talk) 18:29, 17 March 2020 (UTC)
 * I agree linking to the template doc is helpful. Levivich&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 18:30, 17 March 2020 (UTC)
 * That documentation is profoundly unhelpful since it only tells you what to do, not how to do it. (And that's even dodging the greater issue: why you need to do it, as in you really don't) CapnZapp (talk) 15:35, 21 March 2020 (UTC)
 * WP:SOFIXIT – you'd be doing everyone who wants to use the documentation a favour. --RexxS (talk) 18:45, 21 March 2020 (UTC)
 * No, you misunderstand me. We're not discussing improvements to Template:Unsigned. If we were we would have had this discussion at Template Talk:Unsigned. CapnZapp (talk) 19:56, 21 March 2020 (UTC)
 * On the contrary, I understand your complaining perfectly. What you fail to understand is that details of how to use Template:Unsigned belong on the Template:Unsigned/doc page. And that's exactly what we're discussing. Feel free to copy it to the proper location. --RexxS (talk) 20:08, 21 March 2020 (UTC)
 * You still don't understand. My comment was a response to the "linking to the template doc is helpful" comment. More generally: why spend energy on explaining to users how to do a task when most users are much better served by "don't bother, leave it to the bots"? CapnZapp (talk) 09:55, 22 March 2020 (UTC)
 * You're quite wrong. I understand exactly what your comment was a response to. You'll find that linking to a template's documentation is far better than trying to re-explain details on every page where the template is mentioned. Placing all of the details of documentation in a central location allows maintenance in a single place and keeps advice consistent. That's one reason why we have hyperlinks. The template exists, and is available for editors to use in the rare cases that the bot does not fix the missing sig, and it would be irresponsible not to give instructions to those editors who want to use the template. We don't have to arrange our guidance for the majority of editors who will never use the template, but for the much smaller number who wish to. --RexxS (talk) 11:18, 22 March 2020 (UTC)
 * The bullet point currently reads:


 * Attributing unsigned comments: If a comment is unsigned you can find out, from the page history, who posted it and append attribution to it, typically using {{subst:Unsigned}}: . The date and time parameter is optional.

...and I'm entire fine with that, no need for additional links directly to any documentation. If anything, make it more clear that if you're absolutely compelled to replicate the work of a bot, here's a link for you to follow to learn more. In no circumstance have I suggested we should "re-explain details on every page". Stop setting up straw men, please. CapnZapp (talk) 16:26, 23 March 2020 (UTC)
 * We don't write guidance just to please one editor. Other editors agree with me that having a link to the template documentation would be helpful, and I'll be adding that link unless more than your lone voice disagrees. What you clearly haven't grasped is that SineBot sometimes fails to recognise the unsigned post, and it will never add a signature to it. At that point, the only way for the post to have a signature is through an editor adding it manually. There is no strawman other than your "if you're absolutely compelled to replicate the work of a bot". Anybody using Template:Unsigned is performing work that the bot has not done, and will never do. You meant to write "if you're going to add a signature that SineBot failed to do ...". --RexxS (talk) 19:48, 23 March 2020 (UTC)

"We don't write guidance just to please one editor." Now you're just obnoxious. Secondly, what happened to your prior bluster? You don't get to pretend you didn't insult me or set up straw men. Your baseless claims of my incompetence merely makes you look like a fool. Thirdly, you keep trying to avoid seeing my point: don't make the documentation look as if it recommends users to manually add signatures! As you yourself say, it's a last resort and should be treated that way. In fact, do go ahead and write something to the effect of "if you're going to add a signature that SineBot failed to do ..." since that's actually excellent phrasing. CapnZapp (talk) 08:23, 25 March 2020 (UTC)

&larr; Do feel free to tweak further. –<b style="font-family:verdana;color:#000">xeno</b><sup style="color:#000">talk 19:55, 17 March 2020 (UTC)

Cont'd
Have a look over here if you want. CapnZapp (talk) 10:07, 5 April 2020 (UTC)

New essay on talk pages
You are invited to check out Contributing to complicated discussions. &#123;{u&#124; Sdkb  }&#125;  talk 04:02, 28 July 2020 (UTC)

"No meta"
Right now under ===How to use article talk pages=== there's this: Can someone (a) explain what this is talking about, and (b) give an example of the evil it's meant to prevent? I have a sneaking suspicion this is one of those solutions-in-search-of-a-problem. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 00:04, 21 July 2020 (UTC)
 * No meta: Extended meta-discussions about editing belong on noticeboards, in Wikipedia-talk, or in User-talk namespaces, not in Article-talk namespace.
 * It's a real problem occurring from time to time on talk pages of contentious topics, and you would have seen it. It occurs mostly when inexperienced (or plain misguided) editors are unhappy about the direction of a discussion and they start filling article talk with thoughts on the best way that editing should occur, or how NPOV should work, or how biased editors are, or any issue other than an actionable proposal regarding policy-based changes to article content. For examples, trawl through Talk:Gamergate controversy or its 59 archives. Johnuniq (talk) 00:22, 21 July 2020 (UTC)
 * Well I think the phrase meta-discussions about editing could be expressed less obscurely. Not that I know how right now. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 05:26, 28 July 2020 (UTC)

Semi-protected edit request on 31 July 2020
I am not knowledgeable about using and editing Wikipedia entries but I am knowledgeable about Privateersman, Buccaneer, Pirate, Merchant Seaman of Berkeley County and Company, Planter of Carolina and SC Legislator Captain George Raynor b. 1658 of Charelston, SC. I have researched him for over 25 years. He lived on Johns Island, SC where he received a land grant of 1,020 acres from the Lord's proprietors on 9 October 1694. His land bounded by the lower public road also bordered the Stono River at Old Dock Creek near Fenwicke Hall and was bounded by the land of Susannah Bosomworth, George Saxby and William Harvey. Robert Fenwick, pirate and brother of John Fenwick of Fenwick Hall, was a close associate of Captain Raynor and was one of the Red Sea Men. Captain George Raynor married Dorcas Davis daughter of Capt William Davis and his wife Mary Godfrey (previously of Barbados who had immigrated from England). They also lived on Johns Island outside of Charleston SC. Davis's plantation was bounded by Kiawah Creek. In 1694 Captain George Raynor purchased Town Lots 211 and 212 Market Street at Oyster Point in Charleston, SC. George Raynor later purchased Kiawah Island then sold half of the island to Captain William Davis. A small portion of Kiawah that acquired the name Cap'n Samms Spit was given to one of Raynor's ship's crew members known as Cap'n Samms. The other portion of Kiawah that Raynor had retained was left for his daughter. George and Dorcas Raynor had a daughter named Mary who eventually wed King Roger Moore. Roger Moore was the son of South Carolina Governor James Elizie Moore. Roger, along with his brothers Nathaniel and Maurice, migrated to the Cape Fear region of North Carolina and founded Old Brunswick Town. This is the same Roger Moore who built Orton Plantation. Roger and Mary Moore had one known son George Moore who was likely named for his grandfather George Raynor. When George Raynor died his daughter Mary and his wife Dorcas inherited his properties. Mary also died young and her husband Roger Moore inherited his wife's share of Raynor's estate. Roger Moore sold part of his father-in-laws Johns Island property on November 2, 1720 to Alexander Hext/Hixt. Following the death of her husband George Raynor, Dorcas Davis Raynor (1672-1715) later married Samuel Eveleigh (1672-1738). When Dorcas died Eveleigh sold the Raynor properties that he had inherited through his wife.

Captain George Raynor and Josiah Raynor of New York were two different men but may have been related as I believe that George Raynor of South Carolina, who may have been named John George Raynor, was also a descendant of the Raynors of New York. It is my belief, based on my Raynor family research that Josiah and George were cousins and both descendants of Robert Reynere of England. Braynordavis (talk) 00:51, 1 August 2020 (UTC)


 * Red information icon with gradient background.svg Not done: this is the talk page for discussing improvements to the page Wikipedia:Talk page guidelines. Please make your request at the talk page for the article concerned. — Marchjuly (talk) 00:57, 1 August 2020 (UTC)

Proposal: add a line in the good practices section advising reading before commenting
It seems like a longstanding unstated norm on Wikipedia that it is good practice to familiarize yourself with a discussion before participating in it. I recently wrote an essay, WP:Read before commenting (WP:READ), to state this explicitly, and I propose that it be integrated into this guideline by adding the following bullet in the "Good practices for talk pages" section directly under the "be concise" bullet: What do you all think? &#123;{u&#124; Sdkb  }&#125;  talk 09:01, 25 April 2020 (UTC)
 * I would add ...and harder to make an idiot of yourself. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 18:17, 25 April 2020 (UTC)
 * Haha no objection to that :) &#123;{u&#124; Sdkb  }&#125;  talk 18:52, 25 April 2020 (UTC)
 * +1 to the proposed language and E's addition. Except instead of "Familiarizing yourself with a discussion", I would just write "Reading the discussion". Fewer words, better message. Also it should have a convenient shortcut, like maybe WP:READFIRST. Levivich&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 01:43, 26 April 2020 (UTC)
 * +2 but shouldn't think come first? <span style="text-shadow:#F8F8FF 0.2em 0.2em 0.4em,#F4BBFF -0.2em -0.3em 0.6em,#BFFF00 0.8em 0.8em 0.6em;color:#A2006D">Atsme  Talk 📧 02:23, 26 April 2020 (UTC)
 * I added WP:READFIRST as a shortcut. Thanks for the suggestion! &#123;{u&#124; Sdkb  }&#125;  talk 04:02, 26 April 2020 (UTC)
 * I believe Levivich's suggestion was for the shortcut to point to the proposed passage of this guideline, not your essay. CapnZapp (talk) 09:19, 27 April 2020 (UTC)
 * It's a pity that we have to spell out something so obvious, but experience has shown me that many people comment in discussions without reading them first. Phil Bridger (talk) 07:14, 26 April 2020 (UTC)

Quite a barrier to entry if the discussion is 100,000 words over 6 months. :-) <b style="color: #0000cc;">North8000</b> (talk) 13:42, 29 April 2020 (UTC)
 * There seems to be general support here, so I'm going to go ahead and add, and I'll retarget WP:READFIRST to here (sorry I misinterpreted that). I'm not sure how serious 's proposal was, but I have no qualms if anyone wants to modify the wording. &#123;{u&#124; Sdkb  }&#125;  talk 21:05, 28 April 2020 (UTC)
 * I was absolutely serious (though I suppose we might consider fool instead of idiot). <b style="color: red;">E</b><b style="color: blue;">Eng</b> 21:12, 28 April 2020 (UTC)
 * If you truly haven't learned the "worth" of EEng's contributions, Sdkb, I suggest browsing the rest of this page... CapnZapp (talk) 09:06, 29 April 2020 (UTC)
 * I guess the sting is still there, CZapp. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 12:59, 29 April 2020 (UTC)
 * Indeed! I mention WP:SKIM in Read before commenting. For here, "familiarize" is intentionally a little loose; it's not a "you must read every word". &#123;{u&#124; Sdkb  }&#125;  talk 14:16, 29 April 2020 (UTC)
 * Cool.<b style="color: #0000cc;">North8000</b> (talk) 15:48, 29 April 2020 (UTC)
 * IMO this is good common-sense advice, but much too WP:CREEPy for inclusion in a guideline. Also, there is a lot of potential for unhelpful bickering:  "Oh, I didn't notice that earlier comment" – "TPG requires all editors to familiarize themselves with prior discussions before commenting.  You violated the guideline!"   WhatamIdoing (talk) 19:40, 29 April 2020 (UTC)
 * I support this proposal. LURK MOAR has long been sage advice online. Online fora belong to the regular contributors and n00bz have a responsibility to catch up. Chris Troutman  ( talk ) 19:46, 29 April 2020 (UTC)
 * I would lean more toward it being included (with EEng's add-on), because reading before commenting is in fact good guidance, and people failing to do it does in fact waste a lot of community members' time and burn up a lot of inter-editor goodwill. And WP in 2020, as a force in the world not some odd DIY experiment it started out as, needs to spend less time holding hands and instead be more clear about what is problematic, and how/why to not be part of the problem.  — SMcCandlish ☏ ¢ 😼  20:56, 29 April 2020 (UTC)
 * Since at least someone seemed to doubt it, FTR I was indeed absolutely serious about my little addition. "Easier to form consensus" is a nice carrot, but "you might make a fool of yourself" is a better stick (not that it works for everyone, as we all know). <b style="color: red;">E</b><b style="color: blue;">Eng</b> 22:29, 29 April 2020 (UTC)

Check out Village pump (technical). At 13:30 today, I posted a CSS rule to undo the font change. As late as 17:02, people were still asking how to do it. -- Red rose64 &#x1f339; (talk) 19:17, 30 April 2020 (UTC)

Guess I'll go ahead and comment: I don't see that this addition is needed and my thoughts on the matter are more so in line with WhatamIdoing's. While I don't strongly oppose the addition, I do strongly oppose the "and harder to make a fool of yourself" piece. That's not the tone we use in our policies and guidelines, and this shouldn't be the start of using such a tone. I find that piece inappropriate, and I would have reverted it by now if I didn't think that EEng would revert me. I'm surprised it's lasted this long in the guideline. I mean, Moxy and RexxS, are you also okay with it? If I felt inclined, I would (as EEng knows) start the dreaded RfC on it. But I'll settle for leaving a post at WP:Village pump (policy) for more opinions. If most others aren't concerned about it, I won't be either. Flyer22 Frozen (talk) 19:59, 30 April 2020 (UTC)
 * I was trying to stay out of it, but okay. I agree that it's not needed, but several editors have made the case that it would be useful. I know that TPG (and guidelines in general) do get used to bludgeon others sometimes, but I tend to blame the person, not the tool, when its misused. I don't have strong feelings overall, but if pushed (and I was), I think I'd !vote for adding the line (including the 'fool') and being prepared to reverse that if it's shown to be problematical in the future. --RexxS (talk) 20:15, 30 April 2020 (UTC)
 * Not a big deal.. no strong feelings either way. Not sure it will help as someone who needs to be told this probably shouldn't be here to begin with. However our Community has been  getting less and less academic in nature thus perhaps it's warranted  as common sense isn't always so common anymore.-- Moxy 🍁 20:25, 30 April 2020 (UTC)
 * Just a note that I never stated or implied that the addition in its entirety is a big deal. My previous post mainly focuses on the "and harder to make a fool of yourself" piece. With the ways WP:Competence is required has been weaponized and the many complaints that have been directed at it after being cited by editors in discussions, especially heated ones, we want to point editors to a piece in a guideline (not an essay or supplement page) that has "fool" in it? I don't need a crystal ball to see that editors, especially newbies and other less-experienced editors (who these guidelines are mainly for), will be offended by that piece. And as for "pushed", I wasn't looking to push anyone to comment on this. Editors who watch pages don't always keep up with everything discussed or catch every addition, especially if they have a big watchlist. That applies to me as well. If it was me who was pinged and I didn't want to comment, I wouldn't have. But anyway, I wanted to know the thoughts of two editors in particular and now I do. Flyer22 Frozen (talk) 21:24, 30 April 2020 (UTC)
 * Telling people "Hey, here's a way to avoid making a fool of yourself" is no more problematic than telling people not to "bite" other people. (If you like, we could change "make a fool of yourself" to "embarrass yourself", though I don't think that's as memorable.) I don't particularly care whether the entire bullet is present or not, but if it is present I really do think it needs to give the reader a stronger motive than the vague, touchy-feely "easier to build consensus"; avoiding ridicule is a powerful motivator. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 21:36, 30 April 2020 (UTC)


 * Oppose the addition. Nobody reads that article anyways, I had never seen it before. SportingFlyer  T · C  20:25, 1 May 2020 (UTC)
 * You might want to read the top of this discussion... The reason you haven't seen the essay before is since I just wrote it the other day. &#123;{u&#124; Sdkb  }&#125;  talk 22:53, 1 May 2020 (UTC)
 * So if I'm understanding you correctly, you're recommending Familiarizing yourself with a discussion before participating makes it easier to build consensus. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 00:51, 2 May 2020 (UTC)
 * I'm fine with the addition. Seems like positive, uncontentious, good advice. Saying "reading discussions before commenting on them makes helps you avoid making a fool of yourself" is common sense, the fact that anyone could possibly find it offensive is hilarious to me. ~Swarm~  {sting} 21:19, 1 May 2020 (UTC)
 * Yes. I couldn't possibly imagine how someone who fails to read all of (or sufficiently familiarize themselves with) a discussion before commenting and is then pointed to this addition, in what will likely be a very pointed and/or condescending way, and who may already feel embarrassed, could take offense to text essentially rubbing in their (possible) embarrassment by pretty much calling them a fool. There's also the fact that it's common practice that editors don't read all of or much of a discussion before commenting (as seen at WP:ANI, for just one example), with some citing WP:Too long; didn't read in the very discussion. But, yeah, no problem will arise from "and harder to make a fool of yourself." I'm sure those (including me) who cited WP:COMPETENCE to an editor with regard to their editing and meant no offense...but caused it anyway...also thought no problem would arise. Flyer22 Frozen (talk) 22:22, 1 May 2020 (UTC)
 * Maybe other can't see it but to me the fool part seems needlessly bitey. The types who jump into discussions without reading won't change after reading a banner, they probably won't even look at the banner. It will only discourage new editors who wouldn't want to risk commenting even after reading everything to prevent "making a fool of themselves". People are already scared of complicated rules of Wikipedia as it is. Strong oppose to adding "and harder to make a fool/idiot of yourself". TryKid&thinsp;<sup style="white-space:nowrap;">[dubious – discuss] 17:48, 11 May 2020 (UTC)
 * This is really obvious, self-explanatory stuff. Having to spell out the oppose should not have to be done. Maybe the editor that suggested it could instead do with a bit of self-reflection: maybe take some time off Wikipedia, and return fresh, hopefully somewhat less jaded and cynical? CapnZapp (talk) 09:10, 12 May 2020 (UTC)
 * Saying "read a discussion before participating in it" is not an attack against those who would fail to do so. Adding the additional explanation that doing so "will help you avoid looking stupid" is not one either. It's good faith, common sense advice. The fact that we're preemptively concerned about the feelings of disruptive editors who go out of their way to insert ignorant contentious opinions into discussion they haven't read is comical. If you think you're a victim because we preemptively address disruptive behavior in policy you're likely the problem and not the solution. ~Swarm~  {sting} 01:24, 13 May 2020 (UTC)
 * Yes, "read a discussion before participating in it" isn't offensive. But it's common sense that "and harder to make a fool of yourself" should not be there. And I'm certain that if I started an RfC on this and advertised it well, the vast majority of editors would support removing it. Again, we do not use this tone in any other guideline or policy. The only reason I haven't pressed the issue further is because I'm sure it will eventually be removed and I could then state "told you so" (although I won't). I support it not being there per what I stated above. It certainly has not a thing to do with me being a disruptive editor. And per what I stated, not all editors who jump right into the discussion without reading all or most of it are disruptive. Nor all they fools. Sometimes one doesn't need to read all or most of the discussion before commenting. The heading may say it all, as is the case with RfCs, and the only "familiarizing" needed may be reading a brief summary of the matter if the discussion has it. But then again, the text does state "familiarizing yourself with a discussion" rather "read all or most of the discussion." Also, EEng offered alternative wording to the "fool" wording, and we can go with that. If "fool" stays there for long without any issue, I suppose I should look forward to "fool" being added to more policies and guidelines; we can start with WP:Civil. Flyer22 Frozen (talk) 03:32, 13 May 2020 (UTC)
 * It's "common sense" that "harder to make a fool of yourself" is true, good advice, and not attacking or denigrating anyone, rather being a general statement of fact with purely-good faith intentions. As EEng says, it simply reinforces the point being made. It does not add anything negative. ~Swarm~  {sting} 01:25, 17 May 2020 (UTC)
 * Agree to disagree. Flyer22 Frozen (talk) 00:40, 19 May 2020 (UTC)

July follow-up
Note: subheading added by &#123;{u&#124; Sdkb  }&#125;  talk at 04:27, 9 July 2020 (UTC)

Regarding this, this, this and this? Ridiculous. Guess it's RfC time after all, with good advertising for it. Let's see what the wider Wikipedia community thinks about it. Either leave it out or reword it. Or RfC time. Flyer22 Frozen (talk) 23:57, 7 July 2020 (UTC)

And regarding this and this, lovely WP:Harassment. Harassment is, after all, one of the things you are known for. With the harassment I face daily, especially from WhenDatHotlineBling and My Royal Young, you have your work cut out for you, though. Flyer22 Frozen (talk) 04:27, 8 July 2020 (UTC)
 * I fear this may impair your sense victimhood, but I am not harassing you, nor do I have any desire to harass you. You really, really need to start thinking things through before lashing out with accusations as you so frequently do; you can, of course, take that advice or leave it. But the following advice you better take: fucking lay off accusations like Harassment is, after all, one of the things you are known for. You may be in too much of a hurry to understand something (as, for example, in this link which you just posted as "evidence" of harassment), and you may not like my call-a-spade-a-spade approach, but that doesn't mean you're being harassed. So the next time you say something like that you better have actual evidence or you'll be at ANI so fast it'll make your head spin.
 * Oh and by the way, I'm pretty sure I've got you beat in the targeted-harassment department: www.breitbart.com/tech/2020/07/07/wikipedia-editors-censor-rayshard-brooks-criminal-history/, so stop expecting people to feel sorry for you. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 06:11, 8 July 2020 (UTC)
 * Sighs. You are the one who decided to play Victimization Olympics right now. You haven't an idea what I deal with on this site every day. EVERY DAY. Not some one-time incident or "Oh, this happened a few times" matter. And it is very serious (involving, among other things, daily pings and emails), like these editors I mentioned when recently requesting page protection for an article know. And that is not even counting the targeted harassment I've faced over the years from pedophiles, talking in their pedophile forums about "taking down Flyer22." I'm not going to pretend that you heading over to Editors who may be confused and making this edit, pinging me all in the edit history to get my attention, and mocking my name changes, is not about harassment. I'm not trying to get people to feel sorry for me by noting your obvious crap behavior -- behavior that you are known for -- or the fact that I face harassment all the damn time on this site. Feel sorry for me for what? I'm the one who keeps coming here. So, yeah, I guess I deserve it. Self-blame and all. I'm not going to feel guilty or as though I'm being a brat by complaining about harassment. This isn't some "Flyer just likes to feel like the victim" thing. I get harassed daily. Fact. And it's not like I often bring it up. I bring it up in context (like now). Most of the time, I simply push through it. There is no such thing as me frequently lashing out with accusations. There is no such thing as "Flyer frequently, wrongly accuses people of harassment." Others see the harassment and those people are usually sanctioned. Yours in this recent case was mild, but still very real. I don't need you or any other editor mansplaining to me about how you weren't harassing me. I felt harassed, for valid reason. Your little "editors who may be confused" edit came after you went on about how I would be making a fool of myself if I started an RfC on your inappropriate addition, when, going by the recent comments on it, I obviously would not be. Given how many times you've been embroiled in harassment matters, it's obvious to me that you just don't understand or care when you are harassing others. But I am not the woman to just sit and take it. Your ANI threat is beyond laughable. That you think I would be the one reprimanded (well, for anything other than using edit summaries to fire back) for what you did is laughable. I am cackling right now. Other than that, we can move on. Flyer22 Frozen (talk) 07:25, 8 July 2020 (UTC)
 * This discussion has a participant Flyer22 and another SportingFlyer. I noticed that and added those names to the list. The list has a practical purpose, though of course its title adds a bit of amusement, which everyone but you is able to take in the spirit in which it's offered. It did occur to me that you might choose to be offended but I really don't have time to work around elective offense. I'm sorry you get harassed – I really am – but it seems like the real harassment you get makes you see it everywhere. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 07:54, 8 July 2020 (UTC)
 * You added SportingFlyer as a cover. The rest of the usernames are simply previous usernames I had, nothing to do with anyone mistaking me for someone else. And it is highly unlikely that anyone would confuse SportingFlyer and I. The "Flyer is just paranoid" defense doesn't work. It never has. But, yeah, stick to your story. I'm done. Flyer22 Frozen (talk) 21:30, 8 July 2020 (UTC)
 * You added SportingFlyer as a cover – Welcome to crazytown. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 22:28, 8 July 2020 (UTC)
 * And yet it is that supposed crazytown thinking that allows me to stop disruptive editors left and right. They expect me to buy into their half-baked defenses. One reason your half-baked defense doesn't work is because pinging me in the edit summary edit history after a spat, and in a way that was meant to annoy me (despite your claims to the contrary), is the same exact thing so many of those other disruptive editors did and will do in the future. It's like you expect people to believe that you moved on from stating that I would be making a fool of myself by starting an RfC to trying to make me laugh or trying to offer an olive branch. Nope. That's a reality only in your head. Using "Welcome to crazytown" to indirectly call someone crazy? Why don't you just call me crazy outright? Hmm? There's no difference, really. And thanks for being as predictable as others I've profiled. Saves me the work. Flyer22 Frozen (talk) 23:01, 8 July 2020 (UTC)
 * Some might be skeptical that you could really have as many enemies as you imply, but I for one believe you 100%. Are you done obsessing on me yet? I'm sure there are editors waiting to collapse this. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 02:39, 9 July 2020 (UTC)
 * I see what you did there. Those enemies are mostly disruptive editors, especially socks, pedophiles, hebephiles, other types of child sexual abuse POV-pushers (those who think that child sexual abuse causes no harm or enough harm to consider it a serious problem), and those who support lowering the age of consent in a clearly problematic way. I usually get along with editors. And obsessed with you? You're the one who went straight to Editors who may be confused to add my previous usernames, and then reverted Adam9007 who removed the previous usernames here and here. Clearly, Adam9007, like me, doesn't buy your "these previous usernames being here are helpful" rationale. And we both know that even if this part of the thread were collapsed, you'd slide in there and get the last word if I was the last one to reply before that. I'd already stated that we can move on now. Flyer22 Frozen (talk) 03:02, 9 July 2020 (UTC)
 * Before you go ... what are we supposed to do with all the links to various sexual perversions? <b style="color: red;">E</b><b style="color: blue;">Eng</b> 03:56, 9 July 2020 (UTC)
 * Now that did get a nice laugh out of me. Flyer22 Frozen (talk) 04:01, 9 July 2020 (UTC)


 * Oppose the addition: tone is not OK for a guidance page, and other arguments made above by opponents. --Francis Schonken (talk) 04:54, 8 July 2020 (UTC)
 * Since there's been some confusion, the wording currently on the table, which Flyer was on board with too is
 * Familiarizing yourself with a discussion before participating makes it easier to build consensus (and harder to embarrass yourself).
 * <b style="color: red;">E</b><b style="color: blue;">Eng</b> 06:11, 8 July 2020 (UTC)
 * Honesty, "harder to make a fool of yourself" is funny and tongue-in-cheek; it puts a smile on the reader's face. "Harder to embarrass yourself" is condescending; it's not funny. That's my two sense.
 * Also everybody needs to lighten up. I don't know if y'all have noticed but our world is on goddamn fire, and we're discussing a parenthetical phrase in a help document on a website.
 * I'd prefer to have a straight up vote on the original "and harder to make a fool of yourself". Levivich&thinsp;[dubious – discuss] 06:33, 8 July 2020 (UTC)
 * I'd prefer to have a straight up vote on the original "and harder to make a fool of yourself". Levivich&thinsp;[dubious – discuss] 06:33, 8 July 2020 (UTC)
 * I'd prefer to have a straight up vote on the original "and harder to make a fool of yourself". Levivich&thinsp;[dubious – discuss] 06:33, 8 July 2020 (UTC)


 * I would omit at least the words in parentheses. They are patronizing in tone, and likely to offend anyone pointed to them. I also note that the recent user conduct relating to this issue has been poor, which is especially ironic in a discussion over editors' not embarrassing themselves. Newyorkbrad (talk) 06:25, 8 July 2020 (UTC)
 * Now just a minute, Mr. Johnny-Come-Lately. Flyer and I worked hard to come up with that wording, and now you want to throw away that slim hope for future peace and goodwill? But here's what's bothered me about the un-parenthesized part: it's unnecessarily specific. I mean there are 100 ways to fill in the blank in Familiarizing yourself with a discussion before participating ______________________:
 * ... makes it easier to build consensus
 * ... saves time and misunderstanding
 * ... makes things go smoother
 * ... will make your participation more valuable
 * ... is obviously a good idea
 * ... helps you learn how Wikipedia works
 * ... etc etc etc
 * What I don't understand is why the build-consensus angle, out of all of those, is the one to mention. And anyway they're all self-evident and forgettable. That's why I'll say (one more time) that I think the stick of don't-embarrass-yourself is more effective. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 06:51, 8 July 2020 (UTC)
 * An RfC, or proposed/threatened RfC, brings new editors ("Johnnies-Come-Lately") to a discussion; that's the entire point. As for the substance of your comment, you raise a separate question from the "fool/embarrassing" parenthetical that I was addressing. Perhaps Editors who have familiarized themselves with a discussion are more likely to make useful contributions to it, or something along those lines? Newyorkbrad (talk) 06:59, 8 July 2020 (UTC)
 * Sure, that's another formulation. You worried about being patronizing, but their obviousness makes all these formulations patronizing – Levivich's point above. At this point I think Levivich's proposal for a straight-up yes-no on "harder to make a fool of yourself" is the surest way forward. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 14:22, 8 July 2020 (UTC)
 * Support - the original proposal: I support the original proposal (made by at the very top of this talk section; timestamp 09:01, 25 April 2020). CapnZapp (talk) 09:22, 8 July 2020 (UTC)
 * Comment: I strongly resent EEngs various and many attempts to debase and disrupt discussion. (The archives contain many many examples where basically spams discussion in order to disrupt or stop discussion. His recent devaluation of Newyorkbrad's opinion as "Mr. Johnny-Come-Lately" is just the tip of the iceberg). Stop trying to create the impression the choice is between "make a fool of" and "embarrass". It is not. As I see it, you're only trying to dominate or suppress your fellow editors, instead of collaborating with them. CapnZapp (talk) 09:22, 8 July 2020 (UTC)
 * Only you and Flyer keep sidetracking the discussion with comments on other editors. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 14:22, 8 July 2020 (UTC)
 * How the fuck do you reconcile saying that "fool" is offensive, but then you accuse another editor of "debase" and "disrupt". Hellloooo McFly.... Levivich&thinsp;[dubious – discuss] 15:56, 8 July 2020 (UTC)
 * I'm in agreement with Newyorkbrad, including the proposal Editors who have familiarized themselves with a discussion are more likely to make useful contributions to it. Zerotalk 13:30, 8 July 2020 (UTC)
 * Comment Well-intentioned but those who need to be told to read before commenting aren't reading policy either, and for everyone else this just represents an expansion of their reading list. Also I'm not sure how we even point someone at this policy -- which means we've decided they're not-even-skimming -- without violating AGF a bit ourselves. I know it when I see it, but I can't exactly provide a diff. —valereee (talk) 13:52, 8 July 2020 (UTC)
 * A word to the wise isn't a questioning of good faith. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 14:22, 8 July 2020 (UTC)
 * I guess. I'm just trying to think how I'd point someone at this without causing offense. I just this morning struggled with how to ask the question of someone, and I had to tiptoe around the fact that what I was basically saying was, "Your comment makes clear you haven't read what you're commenting on." —valereee (talk) 15:37, 8 July 2020 (UTC)
 * EEng, if they were wise, they wouldn't need this word. Pointing someone at a sentence which says something as obvious as this is actually telling them that they aren't wise. Zerotalk 15:49, 8 July 2020 (UTC)
 * And if they don't read what they are commenting on, they are not likely to read this one, either. Only us people who do read things will read this one. — Preceding unsigned comment added by Gah4 (talk • contribs)
 * It's like how not having children is inherited: if your parents didn't have any children, then you probably won't either. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 16:51, 8 July 2020 (UTC)
 * A word to the wise means something which will benefit someone if they have the good sense to listen. The wisdom doesn't consist in already knowing everything, but rather in being prepared to listen and learn. (The only way in which a human being can make some approach to knowing the whole of a subject, is by hearing what can be said about it by persons of every variety of opinion, and studying all modes in which it can be looked at by every character of mind. No wise man ever acquired his wisdom in any mode but this; nor is it in the nature of human intellect to become wise in any other manner. – J.S. Mill) I completely agree about the obviousness, which is what makes Levivich's point above, about turning it into something people can smile at (and so remember), so good. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 16:51, 8 July 2020 (UTC)


 * I'm fairly surprised to see this discussion still happening, since I had thought it had wrapped up cleanly enough back in May. (Although I guess I shouldn't be too surprised to find a lot of talking on a talk page of a page about talking...) I've added in a subheading to make the jump clearer for anyone not paying close attention to the timestamps. Whatever is decided here, I'd hope we all have more productive ways to spend our volunteering time than WP:DEADHORSE beating. &#123;{u&#124; Sdkb  }&#125;  talk 04:36, 9 July 2020 (UTC)
 * I get the desire for completeness—we're telling people good things to do, and this is a good thing to do—but frankly, no one thinks that having a more complete understanding of a discussion would lead to less productive contributions. Commenters skip reading either because they think they have a good enough grasp of the conversation based on what they have already read, or because their time-benefit tradeoff analysis leads them to believe that reading more of the thread isn't an effective use of their time. Putting it here with a shortcut pointing to it only gives people a stick to hammer others with, which isn't helpful. That being said, if I were to pick a motivation for emphasizing the need to read an entire thread, it would be focused on making things easier for other people, and not whether or not the commenter would appear foolish: by being familiar with what points have been made, you can avoid needless repetition, demonstrating your respect for everyone else's time. isaacl (talk) 00:32, 9 July 2020 (UTC)
 * You know, I think you have something here: maybe, contrary to what I said above, the benefits aren't all self-evident and forgettable. Maybe there are some non-obvious motivating things we could list. I really hope we can get away from makes it easier to build consensus, which is just a vague platitude (sorry, ), but starting with Isaacl's suggestion, how about
 * ... you can avoid repetition, or falling into misapprehensions the discussion has already cleared up, thereby better respecting others' time.
 * Something like that (though somewhat bulky as I just formulated it). <b style="color: red;">E</b><b style="color: blue;">Eng</b> 01:15, 9 July 2020 (UTC)
 * Yes, I think editors far too often focus on how guidance affects them, and not how it can benefit others and thereby foster a more collaborative environment. isaacl (talk) 22:40, 11 July 2020 (UTC)
 * OK, but I don't think my wording (with its misapprehensions and so on) is the right one. Ideas, people? <b style="color: red;">E</b><b style="color: blue;">Eng</b> 00:04, 12 July 2020 (UTC)
 * I suggest Familiarize yourself with the entire discussion so you can avoid repeating points already made, thereby making the conversation more effective. isaacl (talk) 00:13, 12 July 2020 (UTC)
 * <sound of crickets chirping> <b style="color: red;">E</b><b style="color: blue;">Eng</b> 05:06, 20 July 2020 (UTC)
 * <in the distance, a dog howls at the moon> <b style="color: red;">E</b><b style="color: blue;">Eng</b> 23:32, 5 August 2020 (UTC)

"Wikipedia:BOTTOMUP" listed at Redirects for discussion
A discussion is taking place to address the redirect Wikipedia:BOTTOMUP. The discussion will occur at Redirects for discussion/Log/2020 August 11 until a consensus is reached, and readers of this page are welcome to contribute to the discussion. <b style="color:#049">YorkshireLad</b> ✿  <b style="color:#052">(talk)</b> 14:12, 11 August 2020 (UTC)

RfC Announce: medical advice
There is an RfC at Wikipedia talk:Reference desk/Guidelines/Medical advice that would create a new policy and would change our existing policy regarding when editors are allowed to delete other editor's comments. I am not implying that this change would be good or bad; that's for the community to decide. More input from experienced editors would be helpful. --Guy Macon (talk) 05:37, 10 August 2020 (UTC)

Now the rationale for not allowing offered medical advice to stand on the Reference Desk project pages seems just as valid to me for talk pages. My question is therefore, does it seem like a good idea to also include medical advice in the rubric of "harmful posts" that may be removed? --Lambiam 21:29, 11 August 2020 (UTC)
 * The Talk page guidelines have no explicit rule that allows one to remove medical advice. This is being used as a kind of argument for defanging the clauses in the Reference desk guideline that responses offerimg medical advice may be removed – even though the umbrella Reference desk Guidelines state that the Reference Desk project pages are not strictly talk pages, and that the Reference desk guidelines may clarify that the Wikipedia talk page guidelines do not apply to the Reference desk. Indeed, there are differences in the guidelines for when and how postings on the Reference desk may be removed or redacted.


 * Please note that Lambiam came here from the RfC with the express purpose of turning what was a neutrally-worded RfC announcement into Yet Another Battleground.


 * Changing the talk page guidlines in this way would be one solution, but beware of the unintended consequences.


 * For example, see, where a direct quote from a recognized medical expert at Seattle Children's Hospital with no added commentary was removed for being medical advice:


 * "Seattle Children's Hospital says "Scars should be carefully protected from the sun for at least 1 year after surgery or injury. Sun exposure can darken scars permanently, making them more noticeable. After about 2 weeks of healing, you can start applying sunscreen over your child's scar. Apply sunscreen in every season, not just in the summer.""


 * The above was removed from the reference desk as being medical advice. Are you sure that you want to make it so that the above cannot be posted on any talk page?


 * Saying that all medical advice is harmful would also forbid cutting and pasting certain direct quotes from Wikipedia articles. For example, the following is clearly medical advice telling the reader to avoid Ayurveda medicines:


 * "There is no good evidence that indicates Ayurveda is effective for treating any disease, and it is pseudoscientific. Some have termed Ayurveda protoscientific or unscientific. In a 2008 study, close to 21% of Ayurveda U.S. and Indian-manufactured patent medicines sold through the Internet were found to contain toxic levels of heavy metals, specifically lead, mercury, and arsenic. The public health implications of such metallic contaminants in India are unknown. "


 * The above paragraph is unambiguously medical advice. If the Seattle Children's Hospital example above was deletable the above example would be deletable as well. It is also a direct cut-and-past from our Ayurveda article. --Guy Macon (talk) 23:26, 11 August 2020 (UTC)
 * When I came to this page, with the intention of asking for input on the idea of including medical advice in the rubric of "harmful posts", I had no idea there was an RfC announcement here, so my coming here cannot have had "the express purpose" of turning something I did not even know existed into a battleground – but I see another editor has used this occasion to do just that. It is unfortunate that occasionally an overzealous editor removes a contribution as being "medical advice" while in fact it is not – the Reference desk guidelines define in a rather narrow sense how the notion of "medical advice" is meant to be understood, but this is consistently being ignored by some participants in the debate. I happen to think that is not a good reason to scrap the whole notion that medical advice may be removed. --Lambiam 06:29, 12 August 2020 (UTC)


 * Editors are entrusted with the responsibility of upholding the integrity of Wikipedia while adhering to its polices on intellectual property rights and those with legal and moral considerations.
 * General disclaimer - "Please be advised that nothing found here has necessarily been reviewed by people with the expertise required to provide you with complete, accurate or reliable information. Wikipedia cannot guarantee the validity of the information found here."
 * Content disclaimer - "There may be medical, legal or other information that is normally also the subject of professional opinions; Wikipedia is not a substitute for seeking the help of a professional. Please note:  Wikipedia does not give legal advice or medical advice ."
 * Wikipedia:Medical disclaimer - "Nothing on Wikipedia.org or included as part of any project of Wikimedia Foundation, Inc.,  should be construed as an attempt to offer or render a medical opinion or otherwise engage in the practice of medicine ."
 * -- Moxy 🍁 03:43, 12 August 2020 (UTC)

Call for archiving
I would like to request that an uninvolved editor apply Template:Hidden archive top to this thread per WP:FORUMSHOP, WP:BATTLEGROUND, and the basic principle that this is the talk page for discussing improvements to the page Wikipedia:Talk page guidelines, not a place to fight over reference desk policies. --Guy Macon (talk) 04:20, 12 August 2020 (UTC)

The policy on user talk pages (length, organization)

 * This regards WP:TALKCOND and WP:OWNTALK, respectively.

Sigh. It has recently come to my attention that the edits made to implement this: Wikipedia talk:Talk page guidelines/Archive 13 might not work as intended. The intention was to escape the nebulous and ill-defined "rule of thumb" language and to make it clear user talk pages are not bound by restrictions such as 75K length or stale discussion incidence. In other words, that it's nobody's business if I let my own user talk page grow to contain, say, hundreds of entries in the TOC, or if I create, say, a byzantine indexing system that pushes that TOC well below the first screenful, or if I, say, end up having a user talk page several magnitudes bigger than a mere 75K.

Disclaimer: Let it be clear that my own personal opinion is for our policies and guidelines to be clear and concise. If they say talk pages should not contain many stale discussions, or if they say talk pages should not (much) exceed 75K, then it should be possible to gently nudge or template transgressors, and eventually start automatic archiving for them. However, consensus was strongly against this. So I'm settling for the next best thing, to have the guideline at least be clear and upfront about this. There should be no doubt in the readers mind our guideline lets you have any kind of user talk page you wish (as regards length and organization only, of course). Language like "rule of thumb" can be interpreted differently by different editors (is it something to act upon, or is it merely air talk there to impress visitors with no actual significance?) and is therefore something to avoid.

I believed I achieved this with the latest bouts of edits, but maybe I did not? Before making any changes I'd like to first determine if that is so, or if the current guideline accurately reflects this intent. CapnZapp (talk) 09:33, 19 July 2020 (UTC)


 * I have re-read Wikipedia talk:Talk page guidelines/Archive 13. My understanding of the consensus is that (1) the archiving section of this page applies to all talk namespaces, including user talk, (2) the decision to implement archiving on a user talk page is in the sole discretion of the user to whom it belongs, (3) these two prior statements are wholly consistent with each other, and (4) it is appropriate to use uw-archive to inform users who may be unaware of the talk page size guideline. If this is not consensus, and consensus is that the archiving section does not apply to user talk pages, then an explicit statement of such a rule needs to be added to the archiving section. But to get there, I'd think someone would have to explain why the basis for the archiving guidelines (the technical limitations of many users to display long wiki pages properly) somehow do not apply to the user talk namespace. --Bsherr (talk) 02:02, 20 July 2020 (UTC)
 * Thank you. What I'm getting at is that the guideline used to be incredibly unclear as to the question: can and should we make our fellow users prune their talk pages? Specifically, that "rule of thumb" can evidently be read to support your own position, even if that is directly opposed to someone else's interpretation. Saying the rule of thumb applies is incredibly unclear - the guideline ought to clearly state the consensus. As I understand the consensus, this: with the sole exception of gently informing new users of our archival tools, we should not even ask other users to have fast-loading accessible user talk pages. 75K has nothing to do with it, I can have a 854K user talk page and it's nobody's business. The number of stale or resolved discussions is also irrelevant, I can have a TOC with 428 entries in it if I like! I can even fill the top of my talk page with home-made categorizations such that the TOC isn't even visible without scrolling down! Moreover, that if you were to use our templates to tell me to fix my user talk page - even the trivial work needed to set up automatic archiving - you should expect editors and administrators to swoop in like you were a vandal, warning you "not to template the regulars" or face getting banned. In other words, striving to clean up the garbage fires of others is treated as a fairly serious offense. By reading the guideline you would completely miss how your user talk page is your sacred space not to be violated, regardless of length or accessibility. Thus; clarity is needed. Specifically, since my user talk page can be an experience entirely divorced from the guideline under the Archiving section claiming it applies is only misleading and not clear at all! I tried to achieve this using hat notes; now I have been made aware of WP:LEGITHAT (thanks, Bsherr!) which I somehow had missed. Therefore I agree "an explicit statement" is needed, though possibly for a different reason. CapnZapp (talk) 11:24, 20 July 2020 (UTC)

This is still not getting anywhere. Either the guidelines on talk page length (75K, stale discussions) apply to user talk pages, or they don't. Consensus clearly is against enforcing the guidelines, so the logical conclusion is to rewrite the guideline making it clear they don't apply to user talk pages. We don't have guidelines just for them to be ignored. We especially don't have them to give new users something to believe in, while secretly they don't apply to users experienced enough to know which guidelines that can safely be ignored. The guideline needs to clearly explain to the reader what applies equally to everybody. This can be anything, as long as its written down, so it can be read and known and challenged. If the consensus is somehow for the limitations (75K, stale discussions) to apply, while also letting users off the hook, fine. But then this needs to be addressed openly and explicitly. In other words, there needs to be an explanation for how both of these things get to be true at the same time, and that this explanation is easy to understand. That is, "consensus" needs to assume responsibility for the incongruity here. "Consensus" needs to be held accountable, which it just isn't unless words are put to the page.

If you think you can get a straight answer out of these guys Bsherr, feel free to try, because I couldn't. All I can do is update the actual guideline, since that is so far the only thing that gets them out of the woodwork so they can be forced to engage in consensus-building discussion. That is, I'm not trying to oppose you with my change, I'm merely attempting to jump-start a discussion that "consensus" clearly does not wish to have. If you want to fight for your interpretation, that's fine, but then you also need to explain to me how exactly your statement (3) works, so we can explain it to the reader, and not just assume it is understood. CapnZapp (talk) 09:51, 5 August 2020 (UTC)
 * Contributions at Wikipedia should aim to improve the encyclopedia or the community that develops it. That means there should be a firm guideline saying long user talk pages should be archived. However, battling editors who for whatever reason want to be different is not useful. Leave this guideline alone. Johnuniq (talk) 11:32, 5 August 2020 (UTC)
 * The guideline applies to user talk pages. We enforce it by giving a warning to the user whose talk page it is. (We don't implement archiving for the user, we don't block or ban the user for not following through, we don't behead the user, and just because we don't do those things doesn't mean we aren't enforcing it.) Does that make sense? --Bsherr (talk) 18:50, 5 August 2020 (UTC)
 * I really can't believe that this is still being pursued. This is a guideline that offers advice, not an excuse for beating up any particular editors. If anyone chooses not to follow advice then that is their prerogative. The consensus is more than clear that this is a non-issue. Phil Bridger (talk) 19:04, 5 August 2020 (UTC)

Johnuniq, at this stage I'm not trying to change the guideline. I'm merely trying to make it (much) more clear that while it is permissible to warn users (especially new users), there is no actual enforcement. CapnZapp (talk) 18:27, 8 August 2020 (UTC)

Bsherr, you're explaining to me your position. I'm not asking for a personal explanation - I want the guideline to be clearer, so no explanation is needed. How would you suggest we phrase this in the guideline so the next reader understands it? CapnZapp (talk) 18:28, 8 August 2020 (UTC)
 * Yeah, I think that's the sticking point we have here. You think I am advancing a position, but I think what I am explaining is the consensus reflected in the last discussion, and the guideline as currently written. So, in my view, no major changes to the guideline are needed; just to replace "article" with "subject page" in a few places. At the risk of speaking for them, it seems like Johnuniq and Phil are much on the same page as me. However: I'm not closed-minded to improving the guideline to better explain current consensus. Perhaps you have a proposal to reword the guideline to make it clearer? To do that, two things. Firstly, we'll need to move past our disagreement over whether "enforcement" can mean only giving a user warning (you seem to think it cannot, I and others here seem to think it can). Secondly, I think we should try to avoid redundancy with the Wikipedia definition of a guideline, which already states, "Guidelines are sets of best practices supported by consensus. Editors should attempt to follow guidelines...." So, that being said, how would you improve the guideline better communicate that it applies to user talk pages, that we issue warnings, but that we don't impose archiving on a user's page unilaterally? --Bsherr (talk) 19:07, 8 August 2020 (UTC)
 * I'll add also that I'm not taking a position on the merits of the current consensus. Perhaps that should change, or perhaps not. But Templates for discussion/Log/2020 July 16 and this discussion were initiated to address whether these pages adequately state the current consensus, so I'm limiting my scope to that question. --Bsherr (talk) 19:15, 8 August 2020 (UTC)

Phil Bridger: Did you read my post (starting with This is still not getting anywhere). Do you still believe I'm looking for excuses to "beating up any particular editors"? CapnZapp (talk) 18:32, 8 August 2020 (UTC)
 * I did read it and stand by the position that I stated. Just stop flogging this dead horse. As I have said previously, if you think that someone is unaware of how to reduce the size of their User Talk page then give them a friendly message about it, not some sort of warning. If they are aware but choose not to do anything then just drop it. Phil Bridger (talk) 18:43, 8 August 2020 (UTC)

It appears that everybody is fine with the guidelines clearly saying you should archive and such, while at the same time being fine with this to be trivially ignored. This reeks of hypocrisy to me, since if you don't know better you get the impression the guideline is to be followed, but if you try to act upon it you're the one getting admonished. It's a clear case of double standards. Wanting to have the cake while eating it (newbs fixing their talk pages while I don't have to). Other guidelines don't work this way. If the consensus is that it's a recommendation only that you can freely choose to not follow, that is of course fine - but it is also spelled out for everyone to realize. But not in this case. Read the guideline and walk away with a completely different impression than if you "just know".

That's it. If anyone care to bring this up to a higher level, to break this local cabal of a consensus that flies in the face of what Wikipedia usually is, feel free. CapnZapp (talk) 18:29, 27 August 2020 (UTC)

How should "latest topic" be defined for WP:BOTTOMPOST?
WP:BOTTOMPOST says: "The latest topic should be the one at the bottom of the page, then the next post will go underneath yours and so on. This makes it easy to see the chronological order of posts."

"Latest topic" isn't defined, and could be interpreted one of two ways:


 * 1) The latest topic the last one created.
 * 2) The latest topic is the one with the most recent activity.

I propose that we codify that both ways are acceptable.

The reason the second version is important is because sometimes a topic is still actively being discussed while several new topics below it are dead and aren't being discussed any more. In that case, the topic that's actively being discussed is stuck in the middle (or top) of the Talk page, and it isn't apparent when perusing the Talk page that there's an active discussion there. I think there's an expectation that the most recent activity will be at the bottom, or near the bottom of the Talk page, but that doesn't happen when active discussions get orphaned in the middle. As an example, see WP Talk Verifiability. The active discussion topic "RfC: Let's define self-published sources" has seven topics below it that have been dead for as long as five weeks.

I'm not suggesting to make it a requirement to move active topics to the bottom of the pages, but it should at least be acceptable. I've tried to move the active RfC to the bottom of the Talk page, which I think is in keeping with the spirit of WP:BOTTOMPOST, but another user keeps reverting me, claiming his interpretation of WP:BOTTOMPOST is the only correct one. But it's not really defined, so I'm putting the question to the community.

So, on the question of both methods being acceptable, Support, Oppose, or Tweak? -MichaelBluejay (talk) 05:01, 17 August 2020 (UTC)
 * I would find it disorienting for sections to move. I prefer that they stay in their original order. isaacl (talk) 05:33, 17 August 2020 (UTC)


 * The text should be reworded to more clearer match the practice that has been standard for a long time (probably forever). Namely, new topics are started at the bottom, otherwise topics don't move. The other possibility is just begging for editors to play games with topics moving around. Zerotalk 05:36, 17 August 2020 (UTC)


 * The quoted text means to add a new topic to the bottom of the page, not to move topics every time a reply is made. It's clear in context: right before the text quoted, it says (bold as in original) "Start new topics at the bottom of the page: If you put a post at the top of the page, it is confusing and can easily be overlooked. The latest topic should be the one at the bottom of the page, then the next post will go underneath yours and so on."
 * Doing otherwise would require editing the entire page for each new comment, and could not have been what was intended. If the guideline is being misunderstood, I wouldn't object to making it more clear, but it seems pretty clear to me. TJRC (talk) 05:43, 17 August 2020 (UTC)

Example: Talk:Ayurveda I made a proposal for a lead paragraph. put it on hold until an RfC closed, then made the edit. The section was in the middle of the page, but I knew that as soon as I made the edit there would be a lot of discussion, so I moved it to the bottom. This should be a judgement call. --Guy Macon (talk) 11:27, 17 August 2020 (UTC)
 * Whether that example was good, I'm not sure, but I don't think this guideline should provide it as an option. IAR is there for rare exceptions. Zerotalk 12:05, 17 August 2020 (UTC)
 * Whilst has written As an example, see WP Talk Verifiability., they fail to disclose a number of key facts: (a) which particular edits at WT:V this relates to (for the record, they are:  and ;  and ); (b) this was discussed at my talk page a few days ago, where  also commented; and (c) it is related to an ongoing RfD (since closed as delete -- Red rose64 &#x1f339; (talk) 19:20, 20 August 2020 (UTC)).
 * My main objections to the proposed change are twofold: (i) it would require everybody who posts to a thread that was not at the bottom of the page to move it there, and that way lies chaos (consider a page having two active discussions - they would frequently need to exchange their relative positions); (ii) as may be seen from the diffs that I have posted, it makes it very difficult to see what the real change was. For instance, in (that I already mentioned), how many of you spotted the alteration of "adopting Masem's definition?" to "adopting Masem's definition of SPS?" -- Red rose64 &#x1f339; (talk) 20:47, 17 August 2020 (UTC)
 * I could go with something like "move sections with care" and "make the section move a separate edit from any content change" Moving the currently active discussion to the bottom is a useful tool that can improve the discussion, but should be rarely used and only by experienced editors. -Guy Macon (talk) 23:52, 17 August 2020 (UTC)
 * I think once I moved a new post from top to bottom on a talk page. That makes sense. I never felt like moving an old discussion, but a few times started a new discussion that might have been related to an old one, and put that at the bottom. Most of the time I think that is better than moving an old discussion. Gah4 (talk) 00:52, 18 August 2020 (UTC)
 * I could live with that. The minor amount of extra work might be a good trade-off for people not being allowed to game the system to give their comments extra prominence. --Guy Macon (talk) 02:00, 18 August 2020 (UTC)
 * Thinking about it further, I think having two sections where people are discussing the same thing could be a problem. --Guy Macon (talk) 13:38, 18 August 2020 (UTC)
 * There shouldn't be two identical sections actively discussing the same thing. In your cited example you should have simply closed the initial section in the middle of the page and started a new section on the subject, taking the RFC outcome into account, on the bottom of the page.Tvx1 14:03, 18 August 2020 (UTC)
 * Even better! I propose that the policy presents as an option (not required!) closing the old discussion (but only if there have been no comments in the previous four days) and opening up a new discussion at the bottom with a link to the old discussion. That seems better than moving sections, and that's what I plan on doing from now on for those rare times when I think moving a section is appropriate. --Guy Macon (talk) 22:53, 18 August 2020 (UTC)
 * Even better! I propose that the policy presents as an option (not required!) closing the old discussion (but only if there have been no comments in the previous four days) and opening up a new discussion at the bottom with a link to the old discussion. That seems better than moving sections, and that's what I plan on doing from now on for those rare times when I think moving a section is appropriate. --Guy Macon (talk) 22:53, 18 August 2020 (UTC)


 * The section has been changed by recent editing. Flyer22 Frozen (talk) 04:52, 18 August 2020 (UTC)
 * "Doing otherwise would require editing the entire page for each new comment, and could not have been what was intended." (groan) As I stated explicitly, "I'm not suggesting to make it a requirement to move active topics to the bottom of the pages, but it should at least be acceptable."  In any event, it's clear that we're not going to get anywhere close to consensus for my proposal, so I withdraw it. -MichaelBluejay (talk) 19:27, 18 August 2020 (UTC)
 * "My main objections to the proposed change are twofold: (i) it would require everybody who posts to a thread that was not at the bottom of the page to move it there..." NO, NO, NO, NO, NO, NO! "I'm not suggesting to make it a requirement to move active topics to the bottom of the pages, but it should at least be acceptable." -MichaelBluejay (talk) 19:31, 18 August 2020 (UTC)
 * Then why did you post . followed later on by ? Clearly, you do want people to move threads to the bottom. -- Red rose64 &#x1f339; (talk) 22:27, 18 August 2020 (UTC)
 * Could you dial back the aggression, please? Telling people that you know what they want better than they themselves do seldom works out well. --Guy Macon (talk) 22:56, 18 August 2020 (UTC)


 * Before violence breaks out, could someone please give an example of actual behavior, on an actual talk page, that the contemplated guideline changes are intended to forestall? (If such an example is already hidden somewhere above, my apologies.) <b style="color: red;">E</b><b style="color: blue;">Eng</b> 01:12, 19 August 2020 (UTC)
 * I have never seen any examples, but then again I am a newbie -- only 14 years and 51,000 edits. :) --Guy Macon (talk) 01:31, 19 August 2020 (UTC)
 * Then what is everyone arguing about? <b style="color: red;">E</b><b style="color: blue;">Eng</b> 02:45, 19 August 2020 (UTC)
 * I gave examples in my post of 20:47, 17 August 2020 (UTC). -- Red rose64 &#x1f339; (talk) 22:29, 19 August 2020 (UTC)
 * Um, your link shows someone moved a thread, and I gather from something elsewhere that maybe the move changed something. That's bad. So does the guideline tell people to move threads, and the proposal is to change it to not say that? Or is it something else? <b style="color: red;">E</b><b style="color: blue;">Eng</b> 00:06, 20 August 2020 (UTC)
 * Mathglot put the anchor in the middle of my post, not at the start, so you missed all of the examples that I intended you to read. Anyway, the "someone" who moved a thread is (yes, the same person who originated this discussion), and as I pointed out elsewhere, it is Michaelbluejay's earlier misinterpretation of the existing guideline that triggered this all off. -- Red rose64 &#x1f339; (talk) 19:18, 20 August 2020 (UTC)
 * Oh, no; mea culpa! Sorry,, that was inadvertent; and sorry everybody for some unintentional misdirection. My intent was transparency, it's unfortunate that it just made a muddle of things. (Walks away sheepishly...) Mathglot (talk) 19:41, 20 August 2020 (UTC)
 * Per : new topics are started at the bottom, otherwise topics don't move.
 * I get 's dormant section update concern, although I haven't felt that to be a concern myself; but let me see if I can address it.
 * As I understand it, Guy, the use case is roughly this: section "Middle" goes quiescent for a while; meanwhile, five or ten new discussions get added to the bottom of the page. Now, you want to reply to "Middle", and not have to worry that it won't be noticed halfway up the page. If I misunderstood, please correct me.
 * My proposed solution: start section "Middle prime" at bottom of page, and start it with some boilerplate, e.g. "Following up on the issue in section above, I wanted to propose that...". (You could instead use Discussion moved from.) Concomitantly, up in section "Middle", you append a Discussion moved to template, or just a link to " ". (To underscore that the follow-up is in the bottom section exclusively, you could Close the discussion.)
 * Does that work for you, Guy? WP:REFACTOR discusses the possibility of moving discussions around, as you mentioned, but it's a bit of a bold move, as REFACTOR implicitly acknowledges, saying: "If another editor objects to refactoring then the changes should be reverted." But continuing a dormant section in a new, bottom-of-page section would never be off-limits, afaict; and I believe it handles your "dormant-section-update-findability" concern, as well as my "dont-move-the-furniture-around-while-I'm-asleep" concern. What do you think?
 * Oh, and as to the original point of adding a definition: I don't think it's necessary here. It's hard to imagine anyone interpreting "Last" other than bottom of page. If there's a counterexample demonstrating confusion on someone's part, please add a diff link. We shouldn't be fixing problems that don't exist. Mathglot (talk) 06:25, 19 August 2020 (UTC)
 * Repairing faulty ping: User:Zero0000. Mathglot (talk) 06:27, 19 August 2020 (UTC)
 * In my post of 20:47, 17 August 2020 (UTC), I linked to User talk:Redrose64, where confusion is shown over what constitutes the "latest topic". -- Red rose64 &#x1f339; (talk) 22:29, 19 August 2020 (UTC)
 * Lol, well that's a technical win for you, . But you have to know the backstory, which is that MichaelBlueJay is half Vulcan, and his logic sometimes leads him to a conclusion that mere humans like us would never imagine. So let me amend my, "hard to imagine any one " to "hard to imagine any three interpreting...". (Michael, no canvassing T'Pol, pls.) Thanks, Mathglot (talk) 23:22, 19 August 2020 (UTC)


 * Thanks for the suggestion but this guideline will never say anything that might encourage people to move sections on a talk page. That way lies madness with hard-to-check diffs (did the new user correctly move sections, or was something lost?) and pointless turmoil (I think a certain section should be at the bottom but you think it shouldn't) and edit conflicts. If there is a dormant section below something important, either archive the dormant section or, as Mathglot says, start a new section that references the hard-to-see earlier discussion. All of that is for experienced editors only—by definition, if you don't know how to do it or whether it would be desirable, you should leave it alone. If really essential (it isn't), ask at WP:Teahouse for assistance. By the way, WP:BOTTOMPOST has been fixed (thanks EEng). Johnuniq (talk) 07:21, 19 August 2020 (UTC)
 * I count 114 section headings or dot points in this article, which must be a record for all guideline pages. I think that is way over the top and hardly any editors will take the time to study it. Zerotalk 07:47, 19 August 2020 (UTC)
 * To expand on my previous comment: for most pages I use my watchlist to be notified of changes and then look at the history diff between the last edit I read and the current edit. For this, sections moving around introduces a lot of noise and makes it harder for me to find the latest changes. For high traffic pages such as the incidents noticeboard (ANI), I skim through the sections I'm interested in looking for changes, generally based on timestamp. Moving sections around would make it harder for me to find sections of interest. In addition, the hard changes to find are those in the middle of a section, thanks to the multi-branching discussion convention used on Wikipedia, and moving sections to the bottom doesn't help me at all in this case. So for me personally, moving a section to the end would not help me find changes in it. Does someone have another mode of operation that would be aided by this proposal? isaacl (talk) 10:20, 19 August 2020 (UTC)
 * Re: "Does that work for you, Guy?", not only does Mathglot's "My proposed solution" above work for me, but it is clearly superior to what I have done in the past. I have already decided to do the above in those rare cases where I previously would have (carefully) moved a section. I would like to see an explanatory supplement on this so other editors can benefit by knowing the preferred method. --Guy Macon (talk) 15:00, 19 August 2020 (UTC)
 * I'm sorry, but if we're talking about continuing a discussion (that's in an old section in the middle of the page) by creating a new "Middle prime" section at bottom of the page, with these pointers back and forth, that's a terrible idea that fragments the discussion. Just continue the thread in the section it's in, wherever that is (maybe starting a ===-level subsection to highlight that discussion's being resumed). If there are stale threads below the thread you're resuming, then archive them; if all the threads below are still active, well then your thread is just one more of the active threads at the end of the page. And people who really care should be clicking on X changes since my last visit in their watchlists.I'd be against anything recommending this create-a-new-section-with-pointers idea. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 15:23, 19 August 2020 (UTC)
 * , That's a disingenuous misdirection, I'm afraid. You're way too smart a guy not to know what fragmenting a discussion is about. Actual fragmentation by cross-posting the same discussion on two pages lessens coherence and ability to follow a discussion, because it goes on separately in two places. This proposal improves coherence and transparency, by preventing fragmentation. Whatever its other disadvantages may be, fragmentation is certainly not one of them. Mathglot (talk) 19:58, 20 August 2020 (UTC)
 * I appreciate the compliment, but I'm afraid I'm not smart enough to understand what you're saying. The proposal seems to be that a thread in the middle of a page might be continued by opening a new section at the bottom of the page, with some kind of pointer saying "OK, here we'll continue the earlier thread named Foo above on this page". (If I misunderstand, my apologies.) That breaks the discussion into two parts for no reason I can see, and that's fragmenting it (even if not in the WP:CROSS-POST sense.) <b style="color: red;">E</b><b style="color: blue;">Eng</b> 20:37, 20 August 2020 (UTC)

Telling newbies to post at the bottom without telling them why
EEng, regarding this? Why tell editors to post at the bottom and not state why we are telling them that? Do you really believe that is the best route, or are you reverting just to revert me? You really think I need to provide diffs of newbies wondering why they are being told to post to the bottom or repeatedly posting to the top after being told to post to the bottom...when many of us have experienced this?

And, Francis Schonken, regarding this? My reason was not "Oh, I talked it over with Johnuniq, and our opinions trump others' opinions." It's that Johnuniq is the one who initially removed that part, I asked him about it via email, and he was clear that he went overboard on that matter and he agrees that this piece should stay. Flyer22 Frozen (talk) 03:50, 20 August 2020 (UTC)

What valid reason is there to remove this long-standing short piece from the guideline? Flyer22 Frozen (talk) 03:52, 20 August 2020 (UTC)
 * without telling them why – What are you talking about? My text was
 * Start new topics at the bottom of the page, where they are most visible. Use the "" button (at the top of the page) to do this.
 * So it does tell them why: it says that the bottom is the most visible location – surely a strong motivation. And yes, you claimed that "countless times" newbies have explicitly asked "Why do I have to post at the bottom of the page?", which I think is hyperbole at best. But if it's really true then you should have no trouble providing a few diffs; asking for evidence that there's a problem to be solved is standard when discussing guidelines, to counter bloat.And I'd further request that you produce such diffs from newbies who went on to be productive editors. Let's say the professor says, "Time's up. Place your bluebooks in this box." One kid says, "Why should I?" How long do you think he'll remain in good standing? Same principle applies here.What valid reason is there to remove this long-standing short piece – The reason is that this page is 30% longer than it needs to be because of all the soporific blah blah blah blah blah blah blah, so nobody reads it and the rules we're trying to inculcate slumber here unspied upon, magnificently impotent. That's why. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 04:14, 20 August 2020 (UTC)
 * What am I talking about? The following is telling them why: "If you put a post at the top of the page, it is confusing and can also get easily overlooked." Your "where they are most visible" wording is an unnecessary, watered down cut. No, I'm not going to provide you diffs on a common occurrence that many long-time Wikipedia editors, including myself, have experienced, as I though I am lying. You stated, "[I]f it's really true then [I] should have no trouble providing a few diffs." Oh, yes, because I should think back on the encounters I've had, trying to remember which newbies I interacted with or saw do this when interacting with others. I should do this...when I and others have dealt with so many newbies. Nope. I wasn't inclined to provide examples of editors breaking up others' posts when I made my argument on that matter either. Others provided examples. This "telling newbies why they should post to the bottom" thing? I'm not going to debate something that should obviously be stated in the guideline. Like I've done for years, I'd rather just point to that section instead of tell a newbie, "The reason you should post at the bottom is because it's standard to post that way, and so posts at the top will be considered old and may therefore be overlooked." When I made this clarifying edit summary, I figured that, just to aggravate, you would predictably remove the piece I restored. Or do you just think that only you get a say in how these guidelines are worded? Considering this wholesale revert, it seems to me that you should have left it alone. Flyer22 Frozen (talk) 04:48, 20 August 2020 (UTC) Tweaked post. Flyer22 Frozen (talk) 04:57, 20 August 2020 (UTC)
 * Please AGF. I didn't intentionally remove your text. It turns out that there are two bullet points headed Start new topics at the bottom of the page – one in the Layout section and one in the New topics and headings on talk pages section. As a result it seems we've been talking at cross purposes, and in the change you complain about I was adding the "where it's most visible" text, to address the concern expressed in your edit summary. Only if you scroll down in the diff does it become apparent that, through some accident of which revision I grabbed, I was (unintentionally) also removing something in the second Start new topics bullet later on the page. OK? <b style="color: red;">E</b><b style="color: blue;">Eng</b> 12:49, 20 August 2020 (UTC)
 * Okay, EEng. We do have a somewhat tempestuous history; you know that. So it's not unreasonable for me to consider that you were just poking me. But, as seen above, I also wondered why you didn't want us telling newbies why we want them posting at the bottom. Flyer22 Frozen (talk) 02:29, 21 August 2020 (UTC)
 * Without my glasses I though for a moment it said temptress history. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 19:40, 28 August 2020 (UTC)
 * Whether newly created discussion sections are put at the bottom or the top is a matter of convention within a given community. Those that are used to having them on top would find that to be most visible or most likely to not be overlooked, and vice versa for those used to having them on the bottom. We only need to say adding new threads at the bottom is the convention in English Wikipedia. isaacl (talk) 06:12, 20 August 2020 (UTC)
 * Exactly. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 12:49, 20 August 2020 (UTC)


 * The most visible part of a page is the top, not the bottom. That's why, for example, we put the title and lead of an article at the top, rather than the bottom.  So, we should not use visibility as an explanation because it would be wrong.  Bottom posting is just a convention and it is not always followed on Wikipedia.  Places where new entries are top-posted include WP:AFD, WP:ITN and WP:RFA.  Presumably, that's because in those areas, they want the newest item in the most visible position – the top. Andrew🐉(talk) 06:56, 20 August 2020 (UTC)
 * Most people coming to an article haven't seen it before, and start reading at the beginning; that's why the lead is at the top. Most (or many, anyway) people coming to a talk page want to know what's new, and start at the bottom; thus the bottom is arguably the most visible location (and of course it's well known that talk page headers, FAQs, and so on are overlooked in the main). The old text was
 * Start new topics at the bottom of the page: If you put a post at the top of the page, it is confusing and can easily be overlooked
 * so if you like we can avoid the "most visible" issue by simply saying
 * Start new topics at the bottom of the page where they won't be be overlooked
 * Though as I mention somewhere above, it turns out there are two Start new topics at the bottom of the page bullets on the page, and we've all been trapped in a comedy of errors. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 12:49, 20 August 2020 (UTC)
 * In both mentions of posting at the bottom it should say why. That's not "bloat", it's brief and motivates good behavior. And posting at the bottom makes it more visible to Wikipedians, so we should say it makes it more visible. Most of us scroll past the old junk at the top of many talk pages, or have seen newbies post there. Crossroads -talk- 17:59, 20 August 2020 (UTC)
 * I would have agreed with that but Andrew's "most visible part of a page is the top" post above pretty well demolishes the argument. If a reason is to be given, it should be that other editors expect new topics to be at the bottom without entering the rabbit hole of whether bottom-posting is more visible than top-posting. All I want is for the guideline to start by telling people what to do (click the "new section" button) and use minimum waffle so that message is not diluted. Johnuniq (talk) 02:13, 21 August 2020 (UTC)
 * That very last thing you said is the golden principle of which this page so very much needs generous and frequent application. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 02:47, 21 August 2020 (UTC)
 * As several others have pointed out, it is not true that the bottom of the page is the most visible. The most visible place is where your browser first takes you when you visit. For all of my browsers, that is the top. It is true that posting at the top will confuse other people, but that's only because other people know the convention is to post at the bottom. In summary, the only real reason that new topics should go at that bottom is that that is what we do. Editors are not too stupid to understand that, and they don't need more reasons than that, especially not false reasons. Zerotalk 12:18, 21 August 2020 (UTC)
 * Everyone agrees that posting a new comment in a thread that is in the middle of a large number of threads and which hasn't had a new comment in months is not particularly visible. The question is waht, if anything, to do about it. --Guy Macon (talk) 12:43, 27 August 2020 (UTC)
 * As I said before close the discussion in the middle of the page and start a fresh one at the bottom.Tvx1 12:58, 27 August 2020 (UTC)

Here are the options
Consider the situation where there is an active talk page with many sections. You see a thread in the middle of the page that has not had a new comment in weeks. You wish to add a comment. Your options are: Did I miss any?
 * 1) Just add your comment, sit back, and watch as nobody notices it. Not popular among those who leave comments in the middle of the page and get zero responses.
 * 2) Start a new section at the bottom, possibly with two-way links between the old and new sections. Not popular among those who don't want to see the same thing discussed in several sections.
 * 3) Move the existing section to the bottom in one edit, them add your comment in a separate edit. Not popular among those who dislike the idea of allowing editors to move sections.

So, which unpopular option do you want to pick? --Guy Macon (talk) 14:43, 27 August 2020 (UTC)
 * I dispute the premise "watch as nobody notices it." Most editors see comments not because they're made at the top or or at the bottom of the page, but because the article is on their watchlist and they are presented with a diff. I don't believe that the position of the new comment on the page has any significant bearing on whether it is noticed.
 * It is true that many new comments added to very old threads are ignored, but that's not because the comment was made in an area that is not noticed, but because the thread is long-dead and no one has any interest is starting to flog a long-dead horse. TJRC (talk) 18:39, 27 August 2020 (UTC)
 * Exactly. If an editor comes to the page via their watchlist, the diff tells them where to look. If an editor just wanders onto the page fresh, never having seen it before, then the whole page and its constituent sections are new to them explore as they will, and there's no way to overlook the new post because it's because it's all new. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 21:06, 27 August 2020 (UTC)
 * And yet, if the exact same "very old thread" is moved to the bottom with a new comment, for some inexplicable reason other editors do tend to "have an interest in starting to flog a long-dead horse". And on those pages where the long-dead threads don't have a bunch of other threads below them, once again the other editors tend to reply to the new comment. It's almost as if your theory about why comments made in the middle of a page with many threads don't get many responses isn't the correct one. --Guy Macon (talk) 19:59, 27 August 2020 (UTC)
 * I'd like to see evidence of this claim. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 21:06, 27 August 2020 (UTC)
 * It's hard to see how your theory or my theory could be confirmed. I can easily find examples of comments in the middle being ignored and comments with moved sections getting replies, but I can also easily find examples showing just the opposite. Clearly anecdotes are not good enough. One would have to do some statistical number crunching, and even then the numbers would be suspect -- there may be something different about users who comment on old threads in the middle of long talk pages. --Guy Macon (talk) 02:55, 28 August 2020 (UTC)
 * hard to see how your theory or my theory could be confirmed – Right, but I'm not proposing an elaboration of the already-complex guidelines in order to solve a problem merely conjectured. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 03:22, 28 August 2020 (UTC)
 * I made no proposal. I commented on a few proposals by others but the closest thing to a proposal that I wrote was "This should be a judgement call" at 11:27, 17 August 2020 (UTC). --Guy Macon (talk) 09:34, 28 August 2020 (UTC)
 * My apologies. You will understand how easily one becomes confused in the thicket that is this discussion. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 12:52, 30 August 2020 (UTC)

1 or 2, but not 3. Simple. CapnZapp (talk) 18:12, 28 August 2020 (UTC)


 * To add to that;


 * 1) You can ping relevant users to ensure they don't miss a comment made way up in the middle of a large talk page.
 * 2) if you have a good reason (meaning you're not just beating a dead horse) to "restart" a slumbering discussion that's "lost" "up page" (maybe you're late to the party), you can create a new talk section (and link to it at the end of the previous one) for maximum visibility. By adding that link (for instance "Discussion continued below") you have effectively staved off the "same thing discussed in several sections" concern, since your link effectively inactivates the old section - any editor that find the old section can (and probably should) follow your link before placing his or her comment. Note: this is exactly the same as when you find an archived discussion you want to revisit - you're instructed to start a new section on the active talk page. If you want/need to repost parts of the previous discussion, you copy (or link to) it, you never move it.
 * Cheers CapnZapp (talk) 08:37, 30 August 2020 (UTC)

Moving parts of a section is already permitted

 * "Sectioning: If a thread has developed new subjects, it may be desirable to split it into separate discussions with their own headings or subheadings. When a topic is split into two topics, rather than sub-sectioned, it is often useful for there to be a link from the new topic to the original and vice versa. A common way of doing this is noting the change at the [then-]end of the original thread, and adding an unobtrusive note under the new heading, e.g., : This topic was split off from, above. . Some reformatting may be necessary to maintain the sense of the discussion to date and to preserve attribution. It is essential that splitting does not inadvertently alter the meaning of any comments. Very long discussions may also be divided into sub-sections."

While the guideline says "The latest topic should be the one at the bottom of the page, then the next post will go underneath yours and so on. This makes it easy to see the chronological order of posts", I seriously doubt that anyone would report a violation if the person doing the splitting kept the two sections together where the one section used to be -- especially if it was split into a subsection.

Despite the above wording allowing the moving of part of a section, and contrary to what some editors on this page have implied, I could find no language that specifically allows or disallows moving an entire section section. (Feel free to correct me if I missed it.) I am unconvinced that we need to modify the existing guidelines to address this. We already have ways of dealing with disruptive edits without trying to specify all the ways someone can be disruptive. --Guy Macon (talk) 09:52, 28 August 2020 (UTC)
 * Remember, this talk section is about MichaelBluejay's proposal to allow moving talk sections (hopefully opposed by the consensus by now). What you're quoting isn't permitting moving sections: it means to create a new fork, not moving the existing ones. Essentially, you're answering your own question: if you "break the rules" and move a section for a really good reason, noone will likely intervene. Worst thing is someone will revert you, and in that case, you'll have to settle for interlinking. And that's it. Explicitly allowing section moves (even only in certain cases) will do much more bad than good, imo. CapnZapp (talk) 18:23, 28 August 2020 (UTC)
 * I see no reason why this subthread, which contains no material about MichaelBluejay's proposal, has to be limited to being "about MichaelBluejay's proposal".


 * That's a rather interesting interpretation of "If a thread has developed new subjects, it may be desirable to split it into separate discussions with their own headings or subheadings". That sure sounds like starting with an existing section and splitting it into two sections, and not at all like "creating a new fork, not moving the existing ones". --Guy Macon (talk) 18:39, 28 August 2020 (UTC)
 * I've lost track of this discussion but would suggest that moving stuff around should be done rarely and only by experienced editors. Further, there should not be edit wars if another experienced editor reverts. That can't be codified in a guideline and should be (rarely) discussed on a case-by-case basis. That is, I think I'm agreeing with Guy Macon that the guideline should not attempt to tell people moving stuff is ok because it's too complex to explain when it would be reasonable and how to respond if the move is challenged. If it's in the guideline, misguided people can keep their dead-horse topic alive indefinitely by moving it to the bottom with a repetition of their against-consensus opinion. Johnuniq (talk) 00:05, 29 August 2020 (UTC)
 * I meant no offense, User:Guy Macon. But the section is rather confused and sprawling as is it, so maybe you'd be better off starting a brand new section where you clearly introduce us to your problem (no previous reading assumed). Cheers CapnZapp (talk) 08:09, 30 August 2020 (UTC)
 * I see what you did there. (smile) Suggesting starting a new section on the same subject during a discussion where some are in favor of starting a new section on the same subject and some are opposed to starting a new section on the same subject -- brilliant! --Guy Macon (talk) 12:33, 30 August 2020 (UTC)
 * I completely agree with Johnuniq, Guy: moving stuff around should be done rarely and only by experienced editors and That can't be codified in a guideline. Specifically that it can't and is not codified in our current guidelines. This should not change. Yes, exceptions occur. No, that still doesn't mean "Moving parts of a section is already permitted" - I've explained how a split/fork does not suggest/encourage movement of existing content.  Thanks, CapnZapp (talk) 09:39, 31 August 2020 (UTC)
 * On topic, I'm not sure what to say. Whatever you may think, no guideline ever on Wikipedia encourages editors to move around/rearrange/reorder the talk comments of others (with few exceptions*). If (and only if**) what you're trying to get to is that it is possible to interpret this language as such, then you're welcome to suggest a reworded phrasing that makes it more clear that, no, just because a discussion develops a new subject does not mean it's cool to touch what's already been said. What this guideline means is that it's perfectly okay to split that out into its own (sub) header with or without links back and forth, still not moving any existing content. CapnZapp (talk) 08:21, 30 August 2020 (UTC)
 * I never implied that a guideline Wikipedia encourages editors to move around/rearrange/reorder the talk comments of others. I did point out (with a direct quote to the guideline) that one kind of "moving around/rearranging/reordering" (splitting) is explicitly allowed. --Guy Macon (talk) 12:33, 30 August 2020 (UTC)
 * You interpret it as "explicitly allowing" movement. I hope to have shown you how you can (and should) interpret it as not suggesting any movement of existing content. CapnZapp (talk) 09:44, 31 August 2020 (UTC)
 * *) even then, you only remove, archive or hide (e.g. cot/cob) stuff. Actually moving (rearranging) talk comments is almost never needed or accepted.
 * **) I have a feeling you want editors to be able to move stuff around, and if so, please disregard. Cheers CapnZapp (talk) 08:21, 30 August 2020 (UTC)
 * That's an interesting opinion, but it conflicts with the established fact (which I pointed out with a direct quote to the guideline) that one kind of moving (splitting) is explicitly allowed. --Guy Macon (talk) 12:33, 30 August 2020 (UTC)
 * Such feelings are in direct conflict with my clearly worded statements that I do not think that there needs to be any change in any of our current policies or guidelines on this. Let me be even blunter: Our existing policies and guidelines are not broken and do not need fixing. Avoiding WP:CREEP in this area has served us well. --Guy Macon (talk) 12:33, 30 August 2020 (UTC)
 * I agree about there not being a need for change, but that is because your view, that "Moving parts of a section is already permitted", is false. Not sure what else I can say, Guy. CapnZapp (talk) 09:29, 31 August 2020 (UTC) Well, that we should not confuse exceptions for rules - I have moved the comments of other editors myself, but not because specific policy allows it. Instead because we do not encode every exception, and when something is clearly misplaced, nobody will object if you make a neutral clean-up edit. This does not mean our policies actively encourage editors to move stuff around for any purpose. This leaves you with two choices:
 * 1) silently disagree. When you act upon your reading of the guidelines, be prepared to yield if and when opposed, since the other editor will likely not share your interpretation. If you "get away" with it, congratulations - you have graduated into being a pro editor who knows when rules must be broken :)
 * 2) actively propose a change to make it clear (or, I guess, more clear, anyway) movement is allowed (per some conditions, I'm sure).
 * Regards, CapnZapp (talk) 09:29, 31 August 2020 (UTC)

Redirects & talk page archives
Some talk page archives (which are subpages, i.e. "Talk:Foo/Archive 1") have their subject pages (i.e. "Foo/Archive 1") as redirects to their base pages (i.e. "Foo"). The argument in favor is that this provides a convenient manner of linking to the base page rather than a red link. The arguments against are that this pollutes search results, that the most relevant breadcrumb trail back to the base talk page is already part of the interface, and that this creates a lot of redirects with little utility. For occurrences in the article namespace, there has been a consensus at WP:RFD to delete. (See Redirects for discussion/Log/2019 November 2, Redirects for discussion/Log/2019 November 10, Redirects for discussion/Log/2020 January 27, etc.) There is also an RfD concluding in deletion for a similar redirect in the Help namespace (with an ironic topic) (Redirects for discussion/Log/2016 July 3). I recently commenced an RfD for one in the Wikipedia namespace (Redirects for discussion/Log/2020 September 23), but it occurs to me that it would be useful to form a consensus about a uniform practice, and then to document it in an appropriate guideline. So, should these redirects be created or not (and should this vary by namespace)? --Bsherr (talk) 15:21, 23 September 2020 (UTC)

Semi-protected edit request on 28 December 2020
DNMB (talk) 00:15, 28 December 2020 (UTC) Hi, I need help put back in order Bobbie Shaw Chance references. Thanks. (DNMB (talk) 00:15, 28 December 2020 (UTC));
 * This is not the place to ask for this kind of help. The best place to ask would have been the article's talk page, Talk:Bobbie Shaw Chance.  In any case, I put the references back the way they were and moved the "stand-alone" reference you added to the talk page in case it might be useful later.  You might want to read WP:Referencing for beginners and practice in your sandbox, User:DNMB/sandbox.  If you need to continue this discussion, please do so on the talk page for Bobbie Shaw Chance.  Thank you.  davidwr/  (talk)/(contribs) 🎄  00:48, 28 December 2020 (UTC)
 * You can use for cases like this. -- Red rose64 &#x1f339; (talk) 12:58, 28 December 2020 (UTC)

archive editing and reflist-talk
I know in general we aren't supposed to edit archive pages. There is one that should have a that doesn't have one, so the references come out in the wrong place. Is it too strange to edit, so they come out right? Gah4 (talk) 00:34, 6 November 2020 (UTC)
 * There are hundreds (if not thousands) of such archive pages. Which one are you thinking of? -- Red rose64 &#x1f339; (talk) 21:15, 6 November 2020 (UTC)
 * Specifically Talk:Proton/Archive_1, but mostly making sure that there isn't a rule against it. Gah4 (talk) 21:41, 6 November 2020 (UTC)
 * As Redrose64 is implying, there is not much point in fixing a minor issue in one archive because there are many more. In the absence of a really compelling reason, please do not edit archives. Doing so complicates future attempts to investigate past discussions because an edit history casts doubt on what the archive was like at the time it was archived. That can be worked out, but it's simpler to leave it alone. Johnuniq (talk) 23:31, 6 November 2020 (UTC)
 * OK, that is what I suspected. Yes it probably doesn't matter much, but it does complicate reading them when the references come out in the wrong place. Thanks. Gah4 (talk) 00:18, 7 November 2020 (UTC)
 * As Redrose64 is implying, there is not much point in fixing a minor issue in one archive because there are many more. In the absence of a really compelling reason, please do not edit archives. Doing so complicates future attempts to investigate past discussions because an edit history casts doubt on what the archive was like at the time it was archived. That can be worked out, but it's simpler to leave it alone. Johnuniq (talk) 23:31, 6 November 2020 (UTC)
 * OK, that is what I suspected. Yes it probably doesn't matter much, but it does complicate reading them when the references come out in the wrong place. Thanks. Gah4 (talk) 00:18, 7 November 2020 (UTC)
 * OK, that is what I suspected. Yes it probably doesn't matter much, but it does complicate reading them when the references come out in the wrong place. Thanks. Gah4 (talk) 00:18, 7 November 2020 (UTC)

Order of replies
and I are having a disagreement at Talk:Transsexual about the normal order of replies to a given talk page comment. My belief, based on 6 years of participating in discussions on Wikipedia, is that replies to the same comment, at the same level of indentation, are generally added one beneath the other chronologically, to preserve the natural flow of discussion. Flyer22 Frozen disagrees. Who's right? —Sangdeboeuf (talk) 06:27, 2 December 2020 (UTC)

&#8202;::I interject! -InternetLoper :The original first reply. -QuickOnTheBall — SMcCandlish ☏ ¢ 😼  07:41, 2 December 2020 (UTC) &#8202;::I interject! -InternetLoper :::Reply to Loper. -PrimoPoster &#8202;::::Reply to Primo. -InternetLoper :::::Reply to Loper. -PrimoPoster &#8202;::::::Reply to Primo. -InternetLoper :The original first reply. -QuickOnTheBall &#8202;::Some stuff. -PrimoPoster :::Some more stuff. -QuickOnTheBall &#8202;::::Even more stuff. -PrimoPoster This seems like it could seriously break the flow of discussion, especially if the lower sub-thread actually came first. —Sangdeboeuf (talk) 08:30, 2 December 2020 (UTC) — SMcCandlish ☏ ¢ 😼  20:59, 2 December 2020 (UTC)
 * As usual, the above editor is misrepresenting what I've argued. SMcCandlish, can we finally get your commentary on this non-issue? Flyer22 Frozen (talk) 06:30, 2 December 2020 (UTC)
 * At 05:46 I stated, . You replied at 06:04 stating, '. What am I misrepresenting exactly? —Sangdeboeuf (talk) 06:41, 2 December 2020 (UTC)
 * Anyone who takes the time to read that entire off-topic thread will be able to see what you are misrepresenting, and that includes taking my "Whether or not it's clearer in chronological order is obviously subject to disagreement." sentence out of context. You are done wasting my time on this. Do propose something about chronological order with regard to what you've argued, and see where that goes. It will be just like I stated. Flyer22 Frozen (talk) 06:43, 2 December 2020 (UTC)
 * The misrepresentation appears to be that she does not disagree that such is the "normal" or "general" practice as you said in your opening post here, but does disagree with you regarding exceptions, saying they can be made. And they can. Crossroads -talk- 06:51, 2 December 2020 (UTC)
 * For context, a user replied to a comment of mine here, after which Flyer22 Frozen replied to the same comment, but above the first user's comment, here. The first user then moved their comment back to where it was originally. Both were replying to the same comment of mine, at the same indentation level. My question is, was Flyer22 Frozen "correct" to put their comment above the earlier comment, as argued here? —Sangdeboeuf (talk) 07:20, 2 December 2020 (UTC)
 * It's courteous to place your reply below any preceding replies. Earlier replies, being closer to the original comment, are generally easier to understand in context than later replies. It's uncollaborative for editors commenting afterwards to assume that their comments should be placed in a more advantageous position. isaacl (talk) 07:26, 2 December 2020 (UTC)
 * Seems a bit unconventional, but it didn't really break anything. When "injecting" like that, it seems to me to be customary to indent one level extra, to make it very clear that it's a later injection.  This is how I do it, in the rare cases I think it's necessary, and no one's groused at me about it for a long time.  I tend to only do this when I think it's important (e.g. to correct a false statement, with a diff proving it); when it's seriously clarifying for all (e.g. to provide a link to a more pertinent policypage than someone cited: "I think you meant MOS:THECAPS; WP:THE is about titles, not body copy."); or when it's utterly trivial, like a one-liner joke (which I usually do in ).  If it's a regular post that is fairly likely to generate a reply to it, I'll almost always bottom-post it (quoting with  as seems needed, if the thread is long and my reply is a screenful or more away from what I'm replying to).  In this specific instance, it looks like Flyer was making a substantive point, while the other was just providing some trivial one-liner update, so the injection might subjectively have been considered reasonable. I would not have done it at the same indent level, but one deeper:    OP says yadda yadda. -PrimoPoster
 * OK then, what happens when the original reply and the "injection" produce further replies, generating entire new sub-threads, such as:   OP says yadda yadda. -PrimoPoster
 * Introducing an extra indent level causes extra announcements by screen readers, so is generally not desirable. isaacl (talk) 09:04, 2 December 2020 (UTC)
 * If it were done frequently, I would agree (to the extent our talk pages can be sensibly parsed by screen readers at all). At this point, I'm pretty sure screen-reader users know what is going on in an occasional case of "injecting", just as they know what's going on when they hit a list gap or hit a bunch of lines with  markup that should have been , and so on; they can tell by overall familiarity and previous problem-solving with it, like people who live in San Francisco can tell where they are even when the fog is thick. FWIW, I have repeatedly pestered the MW devs, at every version of their bug-tracking system over the years, to reparse talk pages to stop treating   and   as list markup and do something else with them. There are a lot of potential solutions, but the devs just DGaF about this. Geekery: One approach would be using , or trusty ol'  with some classes. For intentional "lists proper", like examples of article text one is working on with a list in it, a  wrapper could make that material be parsed the same way it is in main or project space. And there could be an   magic word that forced the parser to treat a non-talk page, like ANI or VPPOL, as a talk page for parsing purposes. (There's already some more internal way of doing this, and that's why ANI has a "New section" button in addition to "Edit"; but there's no reason it shouldn't be doable just with an in-page bit of code, I would think). None of this is terribly difficult; there's just no will at WMF to do anything about talk pages being a "user-hateful" experience for the visually impaired.  PS, if I may ramble about technically related matters: Similarly, the parser needs to stop , treating   or   as d-list markup, unless they actually form a valid d-list. According to the HTML specs, any  must be followed by another (for multi-term entries) or by a ; and a  must be preceded by another (for multi-definition entries) or by a ; ergo, any purported d-list that does not have  at least one   and at least one  , in that order, is not a valid , and instead should be re-parsed as s with styling to produce boldface or indentation, respectively.  This is actually a pretty simple coding job, but after just shy of 20 years, it's clear we're never going to get it, at least not without major staffing and priority changes on the development side. There are many other "basic HTML standards-compliance screwups" going on in MW that many of us have flagged for repair since the mid-2000s, with no action on them.
 * "This seems like it could seriously break the flow": Sure, and this is why it's not advisable to do it with anything likely to generate responses. E.g., I just did an "injection" a few minutes ago, a one-liner note that requires no reply and isn't likely to generate one.  If it did, then it would be sensible to refactor it back into the conventional article flow (adjusting the indent level), and if that put it way below another long branch of the thread, maybe refactor one's initially injected comment to have a quote making the context clearer (especially if that once-injected post was pretty context-free in its content, having at the time been immediately after the OP); this post is itself an example of that quote-for-context style. :-)  — SMcCandlish ☏ ¢ 😼  20:59, 2 December 2020 (UTC)
 * Sure, but all that refactoring seems like a lot of work that could be avoided by just putting replies in chronological order to begin with...hence the kind of thing most users won't bother doing. [N]ot advisable to do it with anything likely to generate responses seems to rule out the idea of interjecting with a substantive point, as you said Flyer22 Frozen did here. Substantive replies often generate more replies, that's kind of the point. —Sangdeboeuf (talk) 22:30, 2 December 2020 (UTC)
 * No doubt it's a lot more work to refactor, but the need to do so is actually quite rare (unless you use comment injecting stupidly). :-)  — SMcCandlish ☏ ¢ 😼  04:52, 3 December 2020 (UTC)

So, isaacl, going by your "uncollaborative" logic (which would apply to a whole lot of people who are actually being collaborative at various talk pages), the editor who made this post should not have placed it there? It should have been after my second post? And when replying to you right now, this post should be where it is instead of being ahead of SMcCandlish's post with correct indentation...even though placing it ahead of SMcCandlish's post with correct indentation would be clearer and I would not have needed to address you by your username? No need to ping me if you reply. In fact, please don't. Flyer22 Frozen (talk) 07:49, 2 December 2020 (UTC)
 * No, your post should have gone above SMcCandlish's (or "ahead of", if you prefer), with correct indentation, just as you say. That's why I specified that posts with the same indentation level should be in chronological order. By replying to Isaacl, you would be adding another level of indentation. This is shown in the example at Help:Using talk pages. Sangdeboeuf (talk) 08:44, 2 December 2020 (UTC)
 * As per, since you were replying to me, your reply should be one nesting level deeper than my reply, immediately after my comment. SMcCandlish was responding to Sangdeboeuf's comment, after I had already replied, and so placed his comment below mine (and, if there had been any replies to my comment at that point, below those hypothetical replies). I didn't go through this aspect, since you had already mentioned Indentation in the talk page discussion linked to in the original post. It's not necessary to ping me. I'm not sure why you only asked me not to ping you. isaacl (talk) 09:00, 2 December 2020 (UTC)
 * Isaacl, and this is the type of non-chronological order thing I was talking about and how it's common. I was very clear that non- chronological order is not always followed and pointed to such an example at the Transsexual talk page. Even here in this thread, you and another posted ahead of my "07:54, 2 December 2020 (UTC)" comment below. For another example, we can look at this section of Jytdog's talk page, where there are successive comments. If I wanted to reply to Roxy the dog, I would do so right beneath Roxy the dog's post with correct indentation. Not at the bottom. And for those even higher up, I obviously would not reply to them all the way at the bottom. Posting all the way at the bottom to respond to a comment in cases such as these is not the clearest option. It is not the best practice. That is why SMcCandlish recently posted ahead of another's comment here at Talk:Transsexual. Two posts by the same editor are dated "11:52, 2 December 2020 (UTC)." But did SMcCandlish post behind the second one? No. SMcCandlish cut in between them and responded directly to the one he was focused on. Similarly, at Talk:Transsexual, I see no solid reason why my post needed to go below this post. Sure, there is indentation and I could have used the editor's name to make it clearer who I am responding to. But, other than the indentation of the post I jumped ahead of, that comment seemed like a general statement addressed to everyone. Not just to one editor. And this has been echoed in this thread by SMcCandlish. So I chose to reply ahead of it. Editors do stuff like that all the time without issue. As for asking you not to ping me? It's because I had replied to you and pinged you while doing so. I didn't want to be pinged back. And, of course, I haven't pinged you to this section again since you stated that I don't need to. Flyer22 Frozen (talk) 00:46, 3 December 2020 (UTC)
 * Yes, when I respond to a specific comment at a specific list indent level, I make my reply as a nested list item within that comment. If there are any existing replies to that specific comment that already started a nested list, I continue the nested list by adding a new list item to the end of it, which is the standard practice as documented at Indentation. Consider the reverse case: say you've carefully worked out what you feel is a pithy, concise comment in response to an editor. Now another editor has chosen to insert a comment ahead of yours. That other editor is implicitly telling you that they consider your response to be "some trivial one-liner update". Maybe you're right; maybe they're right. Generally, though, it does little harm to leave the first response in its place, thus avoiding acrimony. I'm old school, having started editing before echo notifications. I won't ping editors already participating within a discussion. I was just uncertain why you'd think I'd ping you, but didn't seem to make the same assumption about anyone else. isaacl (talk) 01:28, 3 December 2020 (UTC)
 * For another example, we can look at this section of Jytdog's talk page ... If I wanted to reply to Roxy the dog, I would do so right beneath Roxy the dog's post with correct indentation ... And for those even higher up, I obviously would not reply to them all the way at the bottom. This is exactly what both Isaacl and I have been saying with regard to level of indentation. No one is suggesting that all new comments should go at the bottom of the page or thread.Editors do stuff like that all the time without issue. Obviously it was an issue this time, hence this discussion. —Sangdeboeuf (talk) 01:47, 3 December 2020 (UTC) (edited 01:51, 3 December 2020 (UTC))
 * Isaacl, I understand what you're saying. My point is that what I did is not some uncommon thing and that it usually does not cause problems. If my comment was some brief update about the status of the article, I maybe wouldn't call it trivial. And I did not state that the update in question is trivial; I agreed with SMcCandlish, who clearly didn't mean "trivial" in some offensive way. But I would not mind someone placing their comment ahead of mine in such a case. And, actually, this has happened times before. I think the type of comment matters. In this case, it's objective to state that the comment was a one-liner update. That's not a subjective view of the comment's value. I also started editing before the WP:Notifications feature was implemented. I remember discussion about it taking place on my talk page. Flyer22 Frozen (talk) 01:49, 3 December 2020 (UTC)
 * All I'm saying is you've made a decision that your comment has greater primacy such that it should be placed ahead of earlier repliers, and that can create friction, whether or not they choose to state an objection. It's akin to interrupting someone in a meeting, forcing them to wait to contribute. (Yes, it happens in many written and in-person discussions, and will keep happening.) isaacl (talk) 02:30, 3 December 2020 (UTC)
 * Wasn't about primacy for me. I did not think of the comment in that way. While SMcCandlish stated "trivial", I stated that "other than the indentation of the post I jumped ahead of, that comment seemed like a general statement addressed to everyone. Not just to one editor. [...] So I chose to reply ahead of it." It was about directly responding to the post that concerned my comment, similar to how SMcCandlish choosing to cut in between two posts with the same timestamp by a single editor here here was about him replying to the post that directly relates to what he had to state. If you want to see me jumping ahead of that one-liner update as a primacy matter, we disagree. And I'm sure that SMcCandlish does not view his comments in a primacy way in the instances that he mentioned jumping ahead. Flyer22 Frozen (talk) 02:42, 3 December 2020 (UTC)
 * You are essentially second-guessing the replier, indicating that you think their chosen indent level was not chosen accurately. Again, consider the reverse: if you've carefully chosen where to place your reply, will you be discontented that someone else is imposing their view on yours? And even if the other person is right, is there any significant benefit that makes the risk of upsetting you worth it? isaacl (talk) 02:51, 3 December 2020 (UTC)
 * Second-guessing the replier? Imposing my view on their view? What? No. I've considered the reverse, and I already gave you my answer on that. As for "is there any significant benefit that makes the risk of upsetting you worth it?", I do not get upset over something like this. I already replied on that. And the occasional action of me jumping ahead was never an issue for me until now. And it wasn't much of an issue before an editor decided to lecture me about it at the article's talk page and later bring the matter here. Furthermore, the two editors who made it an issue are editors I have a less-than-stellar history with, and not because of jumping ahead of their posts. But given my history with the editor I jumped ahead of in this case, it would have been better that I had not jumped ahead. Add: Also, Isaacl, you and I never agree. So I'm not surprised that you are making a bigger issue out of this than it is. Flyer22 Frozen (talk) 03:02, 3 December 2020 (UTC) Tweaked post. Flyer22 Frozen (talk) 03:17, 3 December 2020 (UTC)
 * You believe that although the other editor placed their comment one indent level in from comment X, they weren't replying to comment X but instead making a general comment, so your comment could go ahead of theirs. For better or worse, not everyone is going to be happy about this, even if they choose not to raise it in the interest of getting along. It's not a big deal—just one more potential point of contention. isaacl (talk) 03:13, 3 December 2020 (UTC)
 * We've been over this and don't fully agree. No need to repeat. Flyer22 Frozen (talk) 03:17, 3 December 2020 (UTC)

SMcCandlish, you stated, "Flyer was making a substantive point, while the other was just providing some trivial one-liner update." Exactly. That is why I made the choice I did in that case. Flyer22 Frozen (talk) 07:54, 2 December 2020 (UTC)
 * @: To make it clear to whom you are replying, the template may be used, which (if used properly) generates a bell notification. If the user concerned desires not to receive those, the variant  is available, as demonstrated at the start of this post. -- Red rose64 &#x1f339; (talk) 16:09, 2 December 2020 (UTC)
 * Thanks. Yes, I know. I was just caught up in my points. Flyer22 Frozen (talk) 00:46, 3 December 2020 (UTC)
 * Alternatively, you can just mention the editor by name, without any links or templates. isaacl (talk) 01:28, 3 December 2020 (UTC)
 * I mentioned that in both my "07:49, 2 December 2020 (UTC)" and "00:46, 3 December 2020 (UTC)" posts. Flyer22 Frozen (talk) 01:57, 3 December 2020 (UTC)
 * Note my response was to Redrose64, as it is part of the nested list one level in from his comment. (You actually did link to my user name in your 2 December post.) isaacl (talk) 02:39, 3 December 2020 (UTC)
 * Doesn't negate the fact that I mentioned it as an option. Flyer22 Frozen (talk) 02:45, 3 December 2020 (UTC)
 * I was replying specifically to Redrose64's last sentence. I was clarifying that there is no need to use the template, if the user name is written without linking to the user's page. For conciseness, I didn't choose to highlight that the text in your 2 December post is in alignment with this (although you did in fact link to my hypothetical user page); my apologies. isaacl (talk) 02:55, 3 December 2020 (UTC)
 * I heard you the first time. And I never stated or implied that you needed to highlight a thing. Flyer22 Frozen (talk) 03:07, 3 December 2020 (UTC)

Wikipedia should make talk page archiving applied on all pages by default
The process of enabling talk page archiving on a Wikipedia users own talk page can be time consuming such that it leads to the reason why not many long talk pages utilize talk page archiving. By default, sections on a users talk page should automatically go to archive if they are not edited for 15 days. Each archive should have a maximum of 30 sections. This would make the talk pages of all Wikipedia users look neat, without the need of manually activating and starting a talk page archive. Aceing_Winter_Snows_Harsh_Cold (talk) 02:00, 8 December 2020 (UTC)
 * Support because "looking neat" is what counts. <b style="color: red;">E</b><b style="color: blue;">Eng</b> 02:11, 8 December 2020 (UTC)


 * Oppose as-written. However, it would be nice to have a "gadget" that made it easy for new editors to configure the archive settings of their own talk pages.  davidwr/  (talk)/(contribs)  02:31, 8 December 2020 (UTC)
 * A well-intentioned proposal but the point of Wikipedia is that people are not forced to conform. Indeed, the reason it prospers is that people are self-empowered. It would be nice if the instructions for setting up archiving were simpler but that's what WP:HELPDESK is for. If we were going to have rules, mine would be that auto-archiving must not be fast. Johnuniq (talk) 03:46, 8 December 2020 (UTC)

Another user deleted my edit
Hello, I recently edited the Wikipedia page https://en.wikipedia.org/wiki/Imagine_Dragons that provides information about a band named Imagine Dragons.I made a minor edit,nothing controversial whatsoever,but my edit was deleted by another user and I got a message by them saying that I am "engaged in an edit war".That user did not send me a message to voice their opinion and say why they disagree,but they just deleted my edit and messaged me to threaten that I could be "blocked from editing" if I tried to edit that page again.Isn't Wikipedia supposed to be a site in which users cooperate to provide a plethora of information?Threatening another user that you will subtract their right to enrich the information furnished does not strike me as a very democratic act that encourages the collaboration of worldwide users towards the goal of rendering accurate information.I would like to ask how can a user be entitled to delete another user's edit and what can I do to defend my equal right to edit.

Thank you

Just browsing wiki (talk) 18:22, 23 December 2020 (UTC)Just_browsing_wiki


 * The warnings were given because you reinstated the edit at least twice after it had been contested. The thing to do if an edit is contested is to start a discussion on the talk page of the article, in this case Talk:Imagine Dragons, rather than just carry on reinstating it. That is where what you want to do can be discussed, rather than here. Phil Bridger (talk) 19:12, 23 December 2020 (UTC)

adding a new references to "Intelligent laser speckle classification "
I have added more independent references into the article "Intelligent laser speckle classification "against its deletion consideration. Orunab (talk) 01:18, 15 February 2021 (UTC)
 * Thank you, but please report this at Articles for deletion/Intelligent laser speckle classification. —Bruce1eetalk 01:32, 15 February 2021 (UTC)

Talk: Gympie pyramid
Hi, I would like to change the article associated with ‘gympie pyramid’. Today I added two youtube links, one about the pyramid itself and the other related to polygano walls in South America, as one wall like that was associated with the pyramid. I also deleted two web links, which are not existing. Changes were reversed today. So here we are, I am knew to the editing and find this article needs a general overhaul as most written is not relevant, some is wrong and some missing. Hope I can bring my ideas here forward and get a change granted. Chris Wikigetsme123 (talk) 09:21, 13 February 2021 (UTC)
 * This is the talk page for discussing improvements to the page Wikipedia:Talk page guidelines. Please make your request at the talk page for the article concerned. -- Red rose64 &#x1f339; (talk) 10:54, 13 February 2021 (UTC)

Question
Hi. If another editor keeps on refactoring over my objection, moving my comment on a talk page not his own to a prior discussion I opened on an unrelated article (higher on the page, so less likely to be seen), and refuses to stop--saying it is ok for him to do that, how can I best address this? Thanks. --2603:7000:2143:8500:6960:9DFE:CAD2:CC8E (talk) 18:57, 19 January 2021 (UTC)
 * For background, the conversation in question is this one: Wikipedia_talk:Did_you_know. There is also on on-going discussion on my talk page. --evrik (talk) 19:10, 19 January 2021 (UTC)
 * for a start, respect WP:MULTI and keep discussion in one place - for example, you made the same comment at Wikipedia talk:Refactoring talk pages. -- Red rose64 &#x1f339; (talk) 20:57, 19 January 2021 (UTC)


 * Thanks Redrose64. Great point. As suggested, I noted now on that page that if they want to comment, instead of editing there, to comment here. To avoid having the same discussion on multiple pages, which fragments discussion. --2603:7000:2143:8500:6960:9DFE:CAD2:CC8E (talk) 21:21, 19 January 2021 (UTC)

Discussion about "font gimmicks"
I've started a discussion about disallowing "font gimmicks" site-wide as part of the MOS at Wikipedia talk:Manual of Style/Accessibility. This page mentions them under Talk page guidelines so I figured page watchers might be interested. Woodroar (talk) 00:48, 28 February 2021 (UTC)

Mention of Username Change Allowed to Alter Signatures
At WP:UNC, it mentions usernames in old signatures' usernames can be changed for privacy reasons (although they will still be in the old revisions of the page). This isn't mentioned in the Editing own comments section, which can lead to confusion. Should a note about this be added to the section? --Pithon314 (talk) 22:28, 6 April 2021 (UTC)
 * I don't think this rare case needs to be mentioned. isaacl (talk) 22:35, 6 April 2021 (UTC)
 * Agreed, with extra point that we do not want to encourage people to spam talk pages and archives with pointless signature changes. Johnuniq (talk) 03:26, 7 April 2021 (UTC)

Omitting timestamps from signatures
Omitting timestamps from one-message sections may leave those sections unarchived for a long time, as archiving bots depend on discussion dates to know whether it is time to archive them. An undated talk section won't get archived until someone either dates the signature or manually archives it. (DIFF)

Example: This signed but not dated unsigned comment (§ Hokkaido's required to redirect municipalities) remained at the top of the talk page on 12 January 2021, even though several more recent discussions had already been archived by. I dated the unsigned edit  and then manually archived that one section to where the bot would have put it if it had been properly dated. – wbm1058 (talk) 16:49, 12 April 2021 (UTC)
 * Template:Unsigned was transcluded a couple of days later, at 22:26, 22 October 2020 and then that was substituted by a bot. So the  is more "optional" than the date. – wbm1058 (talk) 17:14, 12 April 2021 (UTC)

Alternatives to collapsing?
WP:TALKOFFTOPIC says collapsing "normally stops the off-topic discussion, while allowing people to read it by pressing the 'show' link." In short, the guidance says, "don't collapse an on-going off-topic discussion." What should be done to keep a discussion section from becoming unwieldy when editors are simultaneously discussing (a) a content dispute and (b) editors' behavior on that talk page during that dispute? (Asking for a friend.) Butwhatdoiknow (talk) 17:03, 4 March 2021 (UTC)
 * When a discussion goes off on a tangent, I have often found it helpful to insert a subsection header (such as “arbitrary break”)... followed by a comment asking a question that will (hopefully) get everyone refocused and back on track. A subsection break allows the “off track” discussion to continue above the break (if need be), and a re-focused discussion to continue below the break. Blueboar (talk) 17:25, 4 March 2021 (UTC)
 * In short, the guidance says, "don't collapse an on-going off-topic discussion." This isn't quite true.  There are two very important qualifiers - I mentioned this below, but "involved" and "over the objections of other editors" are carrying a lot of weight there.  I feel that normally, if nobody has attempted to shut down a discussion, you can take a stab at collapsing it provided it isn't glaringly obvious that someone will object (often, for particularly trivial tangents, it's reasonable to hope that everyone involved will be embarrassed they were contributing to it and wander off.)  When a hatting is likely to be more contentious, you should wait for outside editors to do it. But there's absolutely several cases where you can collapse an ongoing off-topic discussion. --Aquillion (talk) 07:22, 10 March 2021 (UTC)
 * Based on how you describe the discussion, and assuming it is on the talk page of the article that the content dispute concerns, probably nothing should be done, as a discussion about a content dispute is on topic, and a related discussion about behavior may very well make sense to discuss in the same place as a matter of convenience. There may be a question about whether the discussion is productive or not, however, and that may warrant some kind of action. --Bsherr (talk) 16:35, 10 March 2021 (UTC)
 * By that last sentence, I mean continuing discussion. As in whether continuing discussion promotes understanding and consensus-building occurring, or not. --Bsherr (talk) 16:37, 10 March 2021 (UTC)

Distinguish Collapse top/Collapse bottom from hat/hab?
I've just learned about the hat template. I'm wondering whether the "normally stops the off-topic discussion" phrase is based on hat/hab, which has language specifically ending discussion. In contrast, Collapse top/Collapse bottom does not contain that language. Is there some reason to not modify the text at WP:TALKOFFTOPIC to permit the collapse templates for an on-going off-topic discussion? — Preceding unsigned comment added by Butwhatdoiknow (talk • contribs) 18:23, 4 March 2021 (UTC)

Proposed change to WP:TALKOFFTOPIC
Current text:
 * If a discussion goes off topic (per the above subsection § How to use article talk pages), editors may hide it using Collapse top/Collapse bottom or similar templates. These templates should not be used by involved parties to end a discussion over the objections of other editors. This normally stops the off-topic discussion, while allowing people to read it by pressing the "show" link.

Proposed text:
 * If a discussion goes off topic (per the above subsection § How to use article talk pages), editors may hide it using Collapse top/Collapse bottom or similar templates. These Templates such as hat/hab should not be used by involved parties to end a discussion over the objections of other editors. This normally stops the off-topic discussion, while allowing people to read it by pressing the "show" link.

Rationale: While the "hat" pair specifically states that the discussion is closed, the "Collapse" pair does not. Allowing an involved editor to employ Collapse allows the off-topic discussion to continue without further cluttering up the on-topic conversation. Any objection? Butwhatdoiknow (talk) 05:40, 8 March 2021 (UTC)
 * No,
 * "Collapse top/Collapse bottom or similar templates" includes hat/hab
 * Neither Collapse top/Collapse bottom nor hat/hab (nor any of the other similar templates) should be used by involved parties to end a discussion over the objections of other editors
 * Current phrasing is fine and makes the appropriate guidance absolutely clear. --Francis Schonken (talk) 05:48, 8 March 2021 (UTC)
 * Since you understand the current text I hope you can help me answer two questions:
 * First, does "This" in the third sentence refer to the first sentence (hiding text) or the second sentence (ending a discussion)?
 * Second, does "normally" in the third sentence mean there are there circumstances where a Collapse on a talk page would not end a discussion? If so, what are they? Butwhatdoiknow (talk) 06:45, 10 March 2021 (UTC)
 * The key words there are involved parties and over the objections of other editors. Having someone hat an argument they're in the middle of participating in leads to bad blood, and often they're not going to be very good at when to make the call to do so.  My reading of the "over the objections" part is that unless it is glaringly obvious that doing so is unwanted, any editor (even, sometimes, an involved one, though you want to be more cautious there) can take one and only one stab at hatting a discussion that hasn't previously been closed, but they absolutely have to back down if it's reverted - essentially prodding for off-topic discussions. I think that that's a more reasonable take and perhaps the wording could make that more clear, if that's how it's supposed to be read. --Aquillion (talk) 07:17, 10 March 2021 (UTC)
 * I think you do point out a lack of clarity in the guidance. I have reordered the sentences, and I think it's an improvement. --Bsherr (talk) 08:56, 10 March 2021 (UTC)


 * Does "normally" in what is now the second sentence mean there are there circumstances where a Collapse on a talk page would not end a discussion? If so, what are they? (An example of one possible circumstance that occurs to me: an editor adds a Collapse with the title of "Ongoing discussion of editing etiquette.") Butwhatdoiknow (talk) 16:04, 10 March 2021 (UTC)
 * As there is no proscription against contributing to a collapsed discussion, the intent is to state only that collapsing a discussion usually has the behavioral effect of discouraging further contributions to the discussion. --Bsherr (talk) 16:28, 10 March 2021 (UTC)
 * My concern is that the behavioral information can be read as a proscription. Should we modify the text to suggest that editors who do not intend to cut off discussion ought to make that clear in the Collapse title? Butwhatdoiknow (talk) 17:57, 13 March 2021 (UTC)

Proposed modification to the new second sentence of WP:TALKOFFTOPIC
As explained above, (1) there is no proscription against contributing to a collapsed discussion and thus (2) the phrase "this normally stops" means "this normally has the effect of stopping." To explicitly state this in the guidance I suggest changing:
 * This normally stops the off-topic discussion, while allowing people to read it by pressing the "show" link.

to:
 * Unless otherwise stated in the Collapse title, this normally has the effect of ending the off-topic discussion, while allowing people to read it by pressing the "show" link.

This text clarifies that, for example, a Collapse with an "On-going discussion of editing etiquette" title will not normally stop discussion. Thoughts? Butwhatdoiknow (talk) 21:14, 16 March 2021 (UTC)
 * Why? The extra words just add confusion. Experienced editors know that nothing is set in stone while inexperienced editors should move on and not try to muck around with a collapsed section. Johnuniq (talk) 22:26, 16 March 2021 (UTC)
 * Okay, let's put "Unless otherwise stated in the Collapse title" aside for the moment.
 * Do you see how "This normally stops ... discussion" might have two different meanings: (a) collapsing ends a discussion (but it's not set in stone) and (b) most people won't add to a collapsed discussion? Butwhatdoiknow (talk) 23:46, 16 March 2021 (UTC)
 * At Wikipedia, guidelines are general. Per WP:BURO, there is no attempt to spell everything out. What is wanted is that people leave collapsed stuff alone because arguing forever is unhelpful. On the other hand, not everyone has the judgment to know when something should be collapsed so experienced editors might take some action other than leaving it alone. Attempting to spell out all the conditions that might apply won't work. Re your original question about how to handle disruption, the answer is that there is no good answer. Johnuniq (talk) 03:05, 17 March 2021 (UTC)
 * If I may suggest, the issue is not specificity, it is clarity. You say the current sentence means "leave collapsed stuff alone." Bsherr says above "there is no proscription against contributing to a collapsed discussion." Which one is it?
 * I think the answer is that ordinarily the purpose of a Collapse is to end a discussion but a non-Hat collapse may have other uses (such as, for example, allowing a related off-topic discussion between a few editors to continue without cluttering up an on-topic discussion). Does that properly align what both you and Bsherr are saying? Butwhatdoiknow (talk) 17:59, 19 March 2021 (UTC)
 * I would think that collapsing might well be intended to end a discussion, but that's not actually binding on anyone else. --Trovatore (talk) 19:06, 19 March 2021 (UTC)
 * Can an editor rebut the default "intent" by saying so in the title (for example, "On-going discussion of ...")? Butwhatdoiknow (talk) 19:39, 19 March 2021 (UTC)
 * I think it's important not to give the impression that editors actually have the authority to tell other people to stop discussing something. --Trovatore (talk) 19:44, 19 March 2021 (UTC)
 * To be clear, editors are at liberty to say, I think we've done this to death, please shut up about it. And other editors are free to say no. --Trovatore (talk) 19:45, 19 March 2021 (UTC)
 * Yes, but that may be a time it may make sense to move off-topic posts to a more appropriate talk page. If a conversation is off-topic but worth continuing, I think it is usually better to continue it on the appropriate talk page, where others who are interested might better notice it. Collapsing a conversation has the usual effect of suppressing participation, so should only be the preferred option when that is actually your intention. --Bsherr (talk) 19:50, 19 March 2021 (UTC)


 * In light of the most recent comments, I'd like to return to the question of whether my proposal more accurately reflects what the guideline is trying to say (changes in italics):
 * Unless otherwise stated in the Collapse title, this normally has the effect of ending the off-topic discussion, while allowing people to read it by pressing the show link.
 * If not, how could my proposal be tweaked to better explain when a Collapse does not become a Hat?  Butwhatdoiknow (talk) 21:18, 19 March 2021 (UTC)
 * Oppose – : for clarity, "editors actually have the authority to tell other people to stop discussing something" (not under whatever circumstances, sure, however sometimes this is the best way forward, e.g. ); and, in general, the current phrasing of the guideline expresses best what it currently means. --Francis Schonken (talk) 05:20, 20 March 2021 (UTC)
 * Let's put aside the "Unless otherwise stated in the Collapse title" phrase for the moment. Do you also oppose changing "normally stops" to "normally has the effect of ending"? If so, why? Butwhatdoiknow (talk) 16:53, 22 March 2021 (UTC)
 * I assume from your silence that you have no substantive objection to changing "normally stops" to "normally has the effect of ending." If I am wrong, please advise and explain. Butwhatdoiknow (talk) 19:35, 25 March 2021 (UTC)
 * I support that change. --Bsherr (talk) 03:01, 23 March 2021 (UTC)
 * Continue my oppose. Silence means that I didn't see anything that would make me change my mind on the matter. --Francis Schonken (talk) 19:41, 25 March 2021 (UTC)
 * Take care with silence, it can be easily be confused with consent or, at the other extreme, wp:Stonewalling.
 * I didn't ask you to change your mind, I asked you explain it. Here, again, is my post: "Let's put aside the 'Unless otherwise stated in the Collapse title' phrase for the moment. Do you also oppose changing 'normally stops' to 'normally has the effect of ending'? If so, why?" I gather the answer to the first question is "yes." What is the answer to the second question? Butwhatdoiknow (talk) 23:00, 25 March 2021 (UTC)
 * Attempting to define precise boundaries between good and bad ideas might be noble but they are contrary to the approach adopted at Wikipedia. If you have an example of problem, please explain it. Otherwise, it's time to move on. Johnuniq (talk) 23:18, 25 March 2021 (UTC)
 * The problem is that the meaning of the sentence in question is unclear. Above, I responded to your March 17 post by saying "You say the current sentence means 'leave collapsed stuff alone.' Bsherr says above 'there is no proscription against contributing to a collapsed discussion.' Which one is it?" You did not reply. Will you please do so now? Butwhatdoiknow (talk) 00:50, 26 March 2021 (UTC)
 * It is not possible to define a precise boundary between what would be desirable and what would not. Both replies are correct. Summary: If someone inappropriately collapses a talk discussion, any passer-by should revert it. If I think something was collapsed appropriately I still might add a comment because I think it will help (adding a comment to get the last word or to express irritation would not be desirable). Talking is fun, but it can't go on forever so in general collapsed sections should be left alone. Comments that don't help should be removed or moved to the collapsed section. Johnuniq (talk) 01:10, 26 March 2021 (UTC)
 * That may be the practice, but the current text doesn't say that. People read guidelines for guidance. If that is the practice then we should say so. I'll take another stab at explaining the problem in a new subsection. Butwhatdoiknow (talk) 04:06, 26 March 2021 (UTC)
 * Thinking about your comments it occurs to me you are warning me that I am a fool's errand. If I am reading that right then you do not find the proposed change (from "normally stops" to "normally has the effect of ending") objectionable, just a waste of time. Do I have that right? Butwhatdoiknow (talk) 15:51, 28 March 2021 (UTC)
 * I for one see no harm in simply clarifying how collapsing a thread causes the off-topic conversation to stop, namely, that it is a behavioral effect. The guideline on this page says "don't make off-topic conversation", not "don't contribute to collapsed conversation". Being intentionally ambiguous about this is just a hostility to users who haven't had the experience of dealing with the situation yet. --Bsherr (talk) 03:36, 27 March 2021 (UTC)

Simplified proposed modification to the second sentence of WP:TALKOFFTOPIC
Based on the discussion above (including concerns raised about prior proposals) my current proposal is to change:
 * This normally stops the off-topic discussion, while allowing people to read it by pressing the "show" link.

to:
 * This normally has the effect of ending the off-topic discussion, while allowing people to read it by pressing the "show" link.

This change is intended to incorporate Bsherr's explanation (above) that "there is no proscription against contributing to a collapsed discussion, the intent is to state only that collapsing a discussion usually has the behavioral effect of discouraging further contributions to the discussion." Any substantive objection to this change? Butwhatdoiknow (talk) 06:02, 1 April 2021 (UTC)
 * You did not post an objection to this proposal here on the talk page. However, you did revert the change with a substantive-free edit summary. Do you have any meaningful objection to this change? Butwhatdoiknow (talk) 22:38, 28 April 2021 (UTC)
 * Reading the entire discussion I see no reason to support this. For clarity, I continue to oppose change for change's sake. All I continue to see in this rehash of a earlier proposal (which I already objected to) is a solution in search of a problem, so no, nor this, nor any variation of it, can be implemented as far as I'm concerned. It's not as if this would in any way be an improvement of the guidance: it is more wordy without being clearer. Nothing has been demonstrated as far as addressing an actual issue is concerned. Repeating what someone else said above "... time to move on", and stop abusing your fellow-editors' time. Tx. --Francis Schonken (talk) 00:56, 29 April 2021 (UTC)
 * Thank you for this explanation. You say above (March 8) that "Current phrasing ... makes the appropriate guidance absolutely clear." Does that mean you agree with Trovatore that the guidance means "collapsing might well be intended to end a discussion, but that's not actually binding on anyone else" and with Bsherr that "stops" means "a behavioral effect" of ending? Butwhatdoiknow (talk) 15:43, 29 April 2021 (UTC)
 * I'm sorry, I don't find Francis Schonken's explanation nearly satisfactory to stand in the way of this change. Not only is it unsatisfactory, it is disparaging and uncivil. No one here wants change for change's sake, we want improvement for improvement's sake. The proposed change does not actually change any practice, it merely improves the explanation by adding clarity, as described above. That is entirely beneficial. Unless Francis Schonken cares to present an explanation refuting that this is an improvement, I think the change should be made notwithstanding Francis Schonken's "opposition". --Bsherr (talk) 03:19, 30 April 2021 (UTC)

Are the first three sentences of TALKOFFTOPIC intended to limit the use of Collapse to Hatting?
Simplified, the first three sentences of WP:TALKOFFTOPIC say this:
 * 1. Editors may "hide" off-topic discussions. [This sentence does not say that a Collapsed discussion is a Hatted discussion.]
 * 2. Hiding "normally" stops discussions. [This sentence suggests there are circumstances when a Collapse does not Hat a discussion.]
 * 3. Involved editors shouldn't hide a discussion to stop it. [This sentence suggests that involved editors can use a Collapse for a non-Hat purpose. (For example, to keep a separate on-going off-topic discussion from distracting folks trying to follow an on-going on-topic discussion.)]

If the intent of these three sentences is to say that a Collapse is always a Hat then I'll be happy to propose a re-write that says that. If the intent is to say that a Collapse is "normally" a Hat but sometimes it may be something else then I'll be happy to propose a re-write that says that. But which is it? Butwhatdoiknow (talk) 04:06, 26 March 2021 (UTC)

Bragging, access levels
I reverted your changes to the part about user access levels. I have personally found the link to Special:ListUsers helpful, and it seems like we'd want people to see directly that they can't get away with misrepresenting their credentials, so to speak. While I agree that users shouldn't brag, I'm not sure that needs to be a WP:RULE, nor should it be specific to talk pages. It might go at Etiquette if anywhere. --Sangdeboeuf (talk) 18:08, 17 June 2021 (UTC)
 * Just a thought. <b style="color:red;">E</b><b style="color:blue;">Eng</b> 19:38, 17 June 2021 (UTC)

Uncivility in talk pages
As I didn't find anything in the guidelines as to what to do when the talk pages have obscenities / vulgarity / crude humour, I looked into the archives and found this "unresolved" thread from user : /Archive 8. Although the last post there asked for help in resolving a discussion at Talk:Rubyfruit Jungle, I could not find the discussion there as it had been removed, and not archived. What I got from its history was that it was resolved as: "irrelevant obscenities and crude humor" is vandalism and should be removed from talk pages. Was this resolution incorporated back into the talk page guidelines? I would like to know if I can delete the comment from 133.87.57.32 at Talk:Bernhard_Caesar_Einstein, or the guidelines won't let me.  - Jay (Talk) 14:37, 19 June 2021 (UTC)
 * I don't see the comment meeting the criteria for deletion set forth at WP:TPO. Yes, it falls far being an stellar example of civility (or, for that matter, clarity - I think it's meant as irony and supports deletion of the article, but I'm not sure). However, it's on point and, while referring to reproductive body parts using non-obscene language may be jarring, it doesn't cross the high bar set for editing others' talk page comments. Butwhatdoiknow (talk) 16:23, 19 June 2021 (UTC)

Peer review pleas - of a prospective article - https://en.wikipedia.org/wiki/Template:PR
Insulating Ceramic Rocket Stoves For rocket stoves in general, a narrow gap between an insulating stove liner and the cookpot helps insure almost complete combustion. 'Transfer the heat efficiently by making the gaps as narrow as possible. https://www.bioenergylists.org/stovesdoc/Still/Rocket%20Stove/Principles.html For an insulating ceramic rocket stove, this consists of curved insulating bricks formed into a cylinder, such that the cook '...pot fits down inside with only a narrow gap all around...' https://ceramics.org/ceramic-tech-today/international/reducing-air-pollution-insulating-ceramic-rocket-stoves The bricks are insulating, giving a highly energy efficient stove, and these are composed of 50/ 50 by volume, clay and a combustible material, e.g., charcoal, that burns out when the bricks are fired. https://morebooks.de/store/gb/book/environmental-health-and-development-for-all/isbn/978-620-2-51414-9  The bricks start out as pre-mixed powders of clay and charcoal, then wetted and formed into the bricks, using purpose-made molds, as shown. Powders are used because this maximizes the bonding between adjacent particles, thus maximizing the strength of the bricks. https://morebooks.de/store/gb/book/environmental-health-and-development-for-all/isbn/978-620-2-51414-9 The bricks are placed together using a mortar mix of 50/ 50 by volume, pre-mix powders of clay and sand, which is then wetted. The clay brings about a bond between the bricks. The sand prevents this mortar from shrinking away from the bricks. In general, as powders, '...the strength of the agglomerates is because of adhesion between the particles. https://www.sciencedirect.com/science/article/pii/B9780080347202501027 In establishing a scientific basis for the insulating ceramic rocket stove, there is an important need to address it's affordability to those impoverished, e.g., of daily income US$1 or $2. All over the developing world there are low-income potters who produce, e.g., water containers and cook pots that are affordable within their communities. Once these potters are trained in model and mold making, https://morebooks.de/store/gb/book/plaster-of-paris-techniques/isbn/978-620-0-78788-0 they will be able to fabricate these insulating rocket stoves, affordable to their neighbors. Women potters in Burkino Faso, for example, could be easily trained to produce these stoves. https://www.youtube.com/watch?v=u8qXo8X48DI FahnbullehV (talk) 13:50, 19 June 2021 (UTC)
 * This is the talk page for Talk page guidelines. You should seek peer review for this content at Talk:Rocket stove. Here's how to use the PR template:
 * To request a Peer review, edit the article talk page, add
 * {{subst:PR}}
 * to the top of the page, and save the page. This will create a template with a link to a new peer review page for the article. Follow this link, and add your request in the edit box as instructed. Save the page and your peer review request will be listed within a day. Butwhatdoiknow (talk) 16:34, 19 June 2021 (UTC)

Declined text
Dear All

Why was the text under Ensana hotels article declined? It is just a descriptive text of our company. This is a sister company of Danubius hotels that has a page already.

Thanks for the info.

Br Lukas Bek — Preceding unsigned comment added by Lukas Bek (talk • contribs) 18:01, 1 July 2021 (UTC)


 * It looks like you have an explanation on your talk page. Butwhatdoiknow (talk) 20:06, 1 July 2021 (UTC)

Edit proposed to reduce changes of misreading.
A sentence in wp:TALKOFFTOPIC currently reads:
 * Involved parties should not use these templates to end a discussion over the objections of other editors.

This text could be read to suggest that involved editors may end discussions in some other way (expressio unius est exclusio alterius). To avoid this outcome I suggest changing the text to:
 * As with closing decisions generally, an involved editor should not use these templates to end a discussion over the objections of other editors.

Any concerns regarding this change? Butwhatdoiknow (talk) 22:08, 1 July 2021 (UTC)
 * I noticed that there was a recent edit and a revert but haven't examined the issue. However, a typical problem with pages like this is that passers-by continually improve them by adding a few words here and there. The result is a wall of impenetrable text rather than a few key concepts. If I have to study Latin to understand the point you are making, it is undue for a page like this which should be a guideline with simple principles. Johnuniq (talk) 00:33, 2 July 2021 (UTC)
 * I had added the Latin as a bit of whimsy. You do not need to study it to understand the point I am making and I have now struck it out to make that clear. I look forward to hearing from you once you find the time to read the remaining text of my post.
 * Meanwhile, if your concern is creep then an alternative way to solve the problem I point to would be to shorten the sentence from:
 * Involved parties should not use these templates to end a discussion over the objections of other editors.
 * to
 * Involved parties should not end discussions over the objections of other editors.
 * Or, better still, we can just take out the whole sentence since the topic is already covered at wp:Talk page guidelines. 01:48, 2 July 2021 (UTC)

Removed broken link
This is my first edit to Wikipedia. My apologies if I did it wrong. Should I have included the link here? I'm still learning! Chemkatz (talk) 22:40, 25 July 2021 (UTC)
 * I've replied at User talk:Chemkatz. Butwhatdoiknow (talk) 23:53, 25 July 2021 (UTC)

BOT Cruft? (Deletion)

 * Wasn't there something a while back about deleting BOT cruft (especially non-active BOTS "External links", etc), and Project "Spam" from Any/all talk pages?
 * I am also wondering about +10yr old unsigned, rather pointless comments? (on article BIO talk pages?) Mjquinn_id (talk) 19:06, 5 August 2021 (UTC)
 * It may be that there are some edits by bots that need to be removed, but "cruft" is not a useful term to describe them. One person's cruft may be another's good edit, and insulting others' edits doesn't usually result in helpful results. Phil Bridger (talk) 19:38, 5 August 2021 (UTC)

Revision of WP:TALKHEADPOV
WhatamIdoing on 21 March 2019 changed a WP:TALKHEADPOV phrase "Keep headings neutral: A heading should indicate what the topic is ..." to "Keep headings neutral: A heading on an article talk page should indicate what the topic is ..." with edit summary = "That recommendation does not apply to the thousands of instances of "A barnstar for you!" on user talk pages". True, but the WP:TALK introduction says about the guidelines of the page: "They apply not only to article discussion pages but everywhere editors interact, such as deletion discussions and noticeboards." I believe that the edit was going too far and I do not see that there was consensus at the time. I propose that we should change to "Keep headings neutral: A heading on a talk page, other than a user talk page, should indicate what the topic is ...". Disclosure: recently I referred to WP:TALKHEADPOV on WP:RSN, I was wrong, but changing now obviously can't affect current headings. Peter Gulutzan (talk) 18:50, 22 September 2021 (UTC)


 * I don't think that neutral headings are as important in 'backstage' pages. The title of Administrator intervention against vandalism is not "neutral" according to some people, but most of us don't think it's a problem.
 * In my experience, most disputes over the neutrality of a section heading or an RFC question mean that someone feels like he's "losing" and is desperately trying to get a different result from the discussion. WhatamIdoing (talk) 15:59, 23 September 2021 (UTC)
 * I wonder whether we should use the word "neutral" in that sentence at all. Our usual definition of "neutral" is "representing fairly, proportionately, and, as far as possible, without editorial bias, all the significant views that have been published by reliable sources on a topic", which isn't relevant.  I think in this case, what we mean is something closer to "don't be misleading, don't poison the well, don't be uncivil, don't use logical fallacies, etc." WhatamIdoing (talk) 16:02, 23 September 2021 (UTC)
 * Are you saying that you oppose changing "article talk page" to "talk page, other than a user talk page"? Peter Gulutzan (talk) 14:29, 24 September 2021 (UTC) Update: This was a question for WhatamIdoing. Peter Gulutzan (talk) 14:08, 27 September 2021 (UTC)
 * Seeing no clear response from WhatamIdoing, I reverted but did not add my own suggestion (here I'm trying to follow WP:PGCHANGE). The original words "Keep headings neutral: A heading should indicate what the topic is ..." were better anyway. The text of WP:TALK begins "For guidelines about user talk pages, see Wikipedia:User pages." and later says "These guidelines apply specifically to discussion pages which are used for collaboration, which includes just about all talk pages other than user talk pages. The application of these guidelines to user talk pages should be governed by common sense and should not supersede guidelines and policies specific to those pages." So there was not any need to change WP:TALKHEADPOV because of user talk pages, and not any justification to exclude other discussion pages. Peter Gulutzan (talk) 14:41, 30 September 2021 (UTC)

How do you copy and paste links into your Wikipedia page?
It's probably in there i just skimmed the page — Preceding unsigned comment added by VeraCruz776 (talk • contribs) 18:20, 14 October 2021 (UTC)
 * Is Help:Link what you're looking for? Butwhatdoiknow (talk) 16:55, 16 October 2021 (UTC)

Dana Skye Nicholson
I first submitted my name only and without attached text it was declined within second, indicating that no on read anything. I then submitted the text which was also rejected immediately meaning that no one had read or reviewed the content. Your website is cumbersome and difficult to navigate and does not ultimately tell you where you are in the review order. Please explain how a submission is automatically rejected before being read? Is there a real person I may speak with? My words are true and accurate and I remain sincere.

Cheers, and thanks, DanaDana Skye Nicholson (talk) 01:07, 17 October 2021 (UTC)


 * Welcome to Wikipedia, Dana. You first created a user talk page with article content, but talk pages are for discussion about article content. You have then created a draft which has not yet been submitted for review. It looks like you were writing about yourself, but Wikipedia is not the place for autobiographies. However, you are welcome to edit or add Wikipedia articles about notable subjects in which you have expertise. You are also welcome to ask general questions about editing Wikipedia at the Teahouse, bearing in mind that this project is run almost entirely by volunteers. ClaudineChionh (talk) 03:04, 17 October 2021 (UTC)