Wikipedia talk:Talk page guidelines

Definition of a personal attack is...off

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

I agree. As there has been no movement on this issue for over a month, I've marked the statement as disputed in the hope that it will attract more editors to this discussion. --RexxS (talk) 17:26, 5 January 2020 (UTC)

- WP:NPA and WP:FOC say, "comment on content, not the contributor" - making negative comments is focusing on the contributor, not the content - it is possible to point out inappropriate behavior of editors by stating facts and citing guidelines instead of making negative comments - see WP:AGF and WP:AAGF - "In cases where you feel that someone definitely needs to be cautioned for interpersonal behavioral issues...consider citing a policy applicable to the situation, such as Wikipedia:No personal attacks, Wikipedia:Civility, or Wikipedia:Harassment and alternatively approach for administrator attention." - Epinoia (talk) 17:45, 5 January 2020 (UTC)

@Epinoia: If I have to warn or sanction an editor whose contributions have been poor by telling them that their editing has been below the standard required, I say something negative about them, no matter how you try to couch it. This guideline calls that a "personal attack", which is patent nonsense. Your assertion that "it is possible to point out inappropriate behavior of editors by stating facts and citing guidelines instead of making negative comments" is demonstrably untrue. "Stating facts" often involves saying something negative, sometimes unavoidably. --RexxS (talk) 19:17, 5 January 2020 (UTC)

WP:CONDUCTDISPUTE suggests that conduct should be dealt with on user pages, which is covered by WP:UP. This page,WP:TPG, deal with article talk pages, where focusing on content applies. Part of the problem is "Talk page guidelines" sounds very generic, as if they apply to user talk as well.—Bagumba (talk) 19:05, 6 January 2020 (UTC)

Not every issue where it is unavoidable to say something negative about another person is a pure conduct issue; not all conduct issues are best brought up only on user talkpages. Some issues are a mixture of content and conduct in such a way that raising the one without the other is impossible. For that matter, not everything negative said about another person is about another editor. To give two examples:

• If I use the article talkpage to explain the removal of content that at a quick glance may look reasonable, but that was part of a since-blocked editor's POV-warring campaign, I am saying something negative about that editor and commenting upon conduct. It is, however, relevant on that article's talkpage and not something I ought to raise on the blocked user's usertalk instead, and I am certainly not engaging in personal attacks.
• If I use the article talkpage of a BLP to discuss how to word said living person being convicted of fraud, which of a myriad of available references are preferable, and where in the article it makes most sense to put it, I most definitely am saying something negative about someone. I am not, however, engaging in personal attacks. AddWittyNameHere 20:02, 6 January 2020 (UTC)

@Bagumba: I never mentioned user talk pages. WP:CONDUCTDISPUTE fails to consider the case when multiple editors are involved. A guiding principle is that discussions should not be split over multiple pages, and it is quite normal for an uninvolved admin to step in on an article's talk page and issue warnings to more than one editor about substandard behaviour in that article or on its talk page. That will generally involve commenting negatively, but justifiably, on individuals' behaviour, and will have the added effect of acting as discouragement for other editors to join in on the behaviour. This guidance oversimplifies what a personal attack is, and consequently fails to reflect accepted practice. It needs to be revised. --RexxS (talk) 22:01, 6 January 2020 (UTC)

OK, I wasn't reading it literally or from the perspective of a less experienced user. It seems the problem is that Wikipedia:Talk_page_guidelines#Behavior_that_is_unacceptable tried to generally define personal attack with a single sentence, which the actual policy page Wikipedia:No_personal_attacks#What_is_considered_to_be_a_personal_attack? doesn't even attempt to do. Perhaps this is a solution: "No personal attacks: A personal attack is saying something negative about another person. This includes:"—Bagumba (talk) 11:44, 7 January 2020 (UTC)

@Bagumba:: works for me. I'd keep the link to Wikipedia:No_personal_attacks, of course, and for grammatical pedantry, I think it should read "These include:" (since it now refers to a plural). Cheers --RexxS (talk) 21:47, 7 January 2020 (UTC)

Works for me as well. Flyer22 Reborn (talk) 05:54, 8 January 2020 (UTC)

And for me too. AddWittyNameHere 16:26, 8 January 2020 (UTC)

Section headings

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

In what way is Wikipedia:Talk page guidelines#New topics and headings on talk pages "problematic"? It already says

"Make a new heading for a new topic"

and

"Make the heading clear and specific as to the article topic discussed".

--Guy Macon (talk) 14:55, 5 January 2020 (UTC)

I was referring to the paragraph on "Section headings" under Wikipedia:Talk page guidelines#Editing others' comments.--Jack Upland (talk) 23:18, 6 January 2020 (UTC)

OK, I see what you are talking about.

What say we replace

"It can also sometimes be appropriate to merge entire sections under one heading (often preserving the later one as a subheading) if their discussions are redundant."

With

"It can also sometimes be appropriate to merge fragmented discussions under one heading or to split a discussion into two sections if the topic drifts."

--Guy Macon (talk) 15:52, 7 January 2020 (UTC)

That would probably be better. But I don't see why this guideline exists. If this was regularly practised it would cause so many problems:

• It doesn't say not to change the heading if that changes the meaning of other posts. Many new posts are of the form: "Mangoes: Why is this important?" Changing this to "Political timing: Why is this important?" completely changes the meaning. It also changes the meaning of subsequent posts such as, "I agree" or "Reliable sources say this is important". It can be hard to see other editors' points of view and ascertain whether a change in heading affects what they said.
• It says to discuss the change with the original poster if the change is likely to be controversial. This seems to promote discussion about the discussion, Talk page talk, which is undesirable. It doesn't say you need consensus, so how is the change decided? Clearly, since it says the original poster doesn't "own" the heading, the original poster has no right of veto.
• It gives editors carte blanche to go over old posts where the original poster is uncontactable and change the headings to what they consider to be appropriate.
• It encourages fussy, bossy behaviour, interference with other people's postings, and petty disputes. Why, why, why?--Jack Upland (talk) 17:46, 7 January 2020 (UTC)

please correct me if I am wrong, but it sort of sounds like you disagree with

"Because threads are shared by multiple editors (regardless how many have posted so far), no one, including the original poster, "owns" a talk page discussion or its heading. It is generally acceptable to change headings when a better heading is appropriate"

In particular you mention "interference with other people's postings" as if the header was part of the post.

I think the flaw here is in the "discuss the change with the original poster if the change is likely to be controversial" advice. That's bad advice. The change should not be controversial in the first place. Misuse of headers is rampant, and it is always appropriate to replace a one-sided header like "Definition of a personal attack is...off" with something neutral and descriptive such as "Definition of a personal attack". --Guy Macon (talk) 01:39, 8 January 2020 (UTC)

Yes, I disagree with the guideline that the original poster doesn't "own" the heading. To a greater or lesser degree, that heading is an integral part of the post. It is contradictory to say "Don't edit other editor's comments", but do change the heading. I think recommending a discussion is problematic however you look at it. The best policy, however, is avoiding conflict, which you have done by ignoring that other heading.--Jack Upland (talk) 02:23, 8 January 2020 (UTC)

Trying to fix everything on Wikipedia is like drinking out of a firehose. I only fix non-neutral headings when they are causing a problem.

As to who owns the heading, there appears to be an overwhelming consensus against doing it your way. I could be wrong, of course; an RfC would settle the question. --Guy Macon (talk) 12:03, 8 January 2020 (UTC)

I don't know whether this creates problems in articles about zoology or Renaissance drama, but in politics articles and other contentious areas, it tends to invite pointy and POV title-tweaking that's not helpful and causes its own set of problems. I think Jack Upland has identified room for improvement here. SPECIFICO talk 15:33, 8 January 2020 (UTC)

I think this could create problems across the board. People use a variety of headings ranging from "Hey Yankee!" to "Definition of a personal attack is...off". These might not fit the guidelines. I've been editing almost since Wikipedia began, and I've never seen those guidelines. I don't understand how there can be an "overwhelming consensus" in favour of editing original headings if there is "Misuse of headers is rampant" and "Trying to fix everything on Wikipedia is like drinking out of a firehose". This guideline isn't being enforced. Editors have voted with their feet. This guideline is just a licence for an officious busybody to selectively change headings he or she doesn't like, thereby generating pointless conflict.--Jack Upland (talk) 08:41, 20 January 2020 (UTC)

guidance on talk page size

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

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

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

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

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

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

Proposal: Change the following sentence

from

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

to

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

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

I'm very leery of participating in a discussion that speaks of "enforcement" and "letting users off the hook" in the context of something so trivial as talk page size. EEng 17:21, 22 February 2020 (UTC)

I think the editor kindly gave DGG two weeks to take care of things. Of course, DGG and you, EEng, are the worst offenders, haha. You doing alright? I was going to leave a note on your talk page but my laptop would crash! ;) Drmies (talk) 17:36, 22 February 2020 (UTC)

What are you talking about? I'm down to 400K. And as everyone knows it's the images that count, not the text. EEng 17:42, 22 February 2020 (UTC)

Mea culpa! Drmies (talk) 22:09, 22 February 2020 (UTC)

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

• I deliberately retain closed discussions which I think to be of continuing general interest , and many people have been appreciative of this. But it is currently too long--I think perhaps half the size would be much more practical. : The excess size of my page is because I have not kept up-to-date in removing those that are no longer of general interest or have been superseded by other discussions, or in removing those which the intent was not to keep them once they were closed-- the need to remove old material is to focus on the important current material. The need to keep the page within limits is to facilitate using the contents. I One possible solution for this I might consider is hatting discussions, to reduce the rendered size in the browser. DGG ( talk ) 22:21, 22 February 2020 (UTC)

  Oh, DGG , you're so sweet in your innocence. Hatting has absolutely zero (read: ZERO) effect on bandwidth usage, load times, memory usage, processor cycles, or anything else whatsoever -- other than the amount of scrolling someone has to do to get to the bottom of the page. EEng 01:09, 23 February 2020 (UTC)

User:DGG I will be much more comfortable discussing issues pertaining to your talk page on your talk page. Let this discussion be about the general "rule of thumb" that we then apply equally to everybody. Cheers CapnZapp (talk) 08:27, 24 February 2020 (UTC)

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

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

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

Any change here should also deal with a requirement that users have a talk page, and keep relevant material on it long enough to be discussed. I recognize this will invovle a much larger change. DGG ( talk ) 18:10, 24 February 2020 (UTC)

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

(edit conflict)

RexxS

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

DGG

Short counter-argument: no, I'm simply discussing if 75K remains appropriate in this day and age?

Longer: You need to have to be much more specific, DGG, about what you mean by "a requirement that users have a talk page" and "keep relevant material on it long enough", or your comment will likely not be understood and maybe even disregarded. It's not that I have to explain to you that you're free to split up a very long page into several user talk subpages of manageable size. Or that the subject of an archived talk section can be "re-opened" simply by starting a new talk section to resume the discussion. Cheers! CapnZapp (talk) 21:09, 24 February 2020 (UTC)

User:EEng What is your specific suggestion? That we remove any numeric rule of thumb entirely? Just chiming in to call the current phrasing "mindless" is not constructive. Cheers CapnZapp (talk) 21:12, 24 February 2020 (UTC)

I'd be fine with removing the number entirely. EEng 21:24, 24 February 2020 (UTC)

@EEng: Did you actually read SIZESPLIT? "SIZESPLIT is for articles and is motivated by almost completely different reasons" – that's patently untrue. SIZESPLIT gives five considerations:

1. time to read the page – there is no evidence that readers can read talk pages any quicker than articles, so the guidance applies equally;
2. some users have a low speed service – there is no evidence that users' service speed increases on talk pages and slows down for articles, so the guidance applies equally;
3. some users have unstable connections – there is no evidence that users connection stability is greater on talk pages than articles, so the guidance applies equally;
4. some users have a pay per kilobyte service – there is no evidence that users' service gets cheaper for talk pages than articles, so the guidance applies equally;
5. some users may access Wikipedia through a mobile phone or smartphone whose browsers might truncate long pages – there is no evidence that smartphone browsers truncate less on talk pages than on articles, so the guidance applies equally;

How do you square those with your assertion "motivated by almost completely different reasons"? That really is well off the mark.

@CapnZapp: Even though readers may often read one section or thread of a talk page per visit, it is just as likely that readers may often read just one section of an article. In fact our statistics show that a significant number of visits to an article are brief, suggesting the reader only looks up a single fact before moving on. Your assertion that "most of the rationale behind SIZESPLIT revolves around a human reader's limited capacity for long articles" is clearly false, as most of the rationale behind SIZESPLIT revolves around other factors, and I've demonstrated that by quoting the five considerations given in SIZESPLIT. Why not address the actual guidance there, rather than making up your objections to it? --RexxS (talk) 00:03, 25 February 2020 (UTC)

SIZESPLIT is indeed about articles and issues about their size related to reading and navigating them; one sentence offers some questionable claims about unstable connections and so on. Find evidence that significant numbers of editors have browsers that truncate long pages and then we'll talk. EEng 01:08, 25 February 2020 (UTC)

I disagree with your summary of SIZESPLIT as being about five equally important criteria, User:RexxS. It's about readability, and then also that "some users" have technical issues. More importantly, SIZESPLIT concerns article space, not talk space, so if you want to be a stickler for procedure, which I think you need to be to argue there are five equally important criteria, then it is also true that none of the five criteria are relevant at all. Anyway, arguing whether SIZESPLIT applies only muddles the issue, stealing away focus from the question asked here. You are certainly free to argue for a 50 kB rule of thumb, no need to involve SIZESPLIT, and it has been noted. Thank you. CapnZapp (talk) 09:51, 25 February 2020 (UTC)

@EEng: "questionable claims" only in your opinion. SIZESPLIT has project-wide consensus, and there is no indication that the five factors there apply any less to talk pages than to articles. You find evidence that those factors affecting articles don't affect talk pages and then your opinion might be worth listening to.

@CapnZapp: I disagree with your contention that the five factors are not of equal importance. For any given reader, one or another may be the most important; it's no help being the world's fastest reader if you can't get a connection to the article you're trying to read. It's not just about readability. The factors raised in SIZESPLIT go right to the heart of this question, and SIZESPLIT has project-wide consensus that it contains useful guidance. Those factors are clearly relevant when discussing the present question, and must carry far more weight when trying to reach a conclusion on the best figure to use for guidance than your suggestion which seems to be a figure plucked out of thin air, with no rationale behind it. --RexxS (talk) 13:51, 25 February 2020 (UTC)

SIZESPLIT has project-wide consensus – That's odd, because right at the top it says it has not been thoroughly vetted by the community.

The handwringing about truncation and so on was added in 2011 with no discussion at all. Even, generously, assuming that that was in fact a realistic issue at that time, I renew my call for evidence that it remains an issue ten years later. EEng 17:49, 25 February 2020 (UTC)

It was a problem in Firefox 3,[1] and Firefox 3 is still listed in the mw:Compatibility#Browser support matrix. (Inclusion is generally determined by a certain percentage of traffic.) WhatamIdoing (talk) 19:20, 25 February 2020 (UTC)

Someone posts to stackoverflow that some big (we don't know how big) page (not a Wikipedia page) was being truncated in some way, for some unknown reason, on Firefox ==>3<== in ==>2009<=== (six weeks into Obama's first term, if that helps set context) and based on that we're supposed to be worrying about page length here on this project in 2020? Uh huh. Got anything else? EEng 22:44, 28 February 2020 (UTC)

You seemed to be having trouble believing that it was considered a realistic problem when this was added in 2011. I have demonstrated that there were rational reasons for this concern at the time. There are links to relevant reports in Mozilla's bug database in the replies, if you want to learn more about it. Whether we should care about readers using old hardware that can't be upgraded past Firefox 3.5? Well, the MediaWiki devs apparently do, but I won't tell you what your values should be. WhatamIdoing (talk) 02:10, 7 March 2020 (UTC)

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

• I'm happy with retaining the present rule of thumb, but would emphasize that it is simply a rule of thumb, not something that should be enforced on anyone. I would also note that there seems to be some confusion above. The proposal doesn't seem to be about talk space, but user talk space, which is seen as a partial exception to WP:OWN. Phil Bridger (talk) 10:14, 25 February 2020 (UTC)

As far as I am aware the guideline does not separate between user talk and regular talk, and the rule of thumb therefore applies equally to both. Please tell me if I'm wrong (since the language explaining this could then probably be improved). Having separate guidelines would of course be one reasonable argument to make... CapnZapp (talk) 10:18, 25 February 2020 (UTC)

As for "it is simply a rule of thumb, not something that should be enforced on anyone" I consider that a separate second issue. When we have agreed on a number (or not to have a number etc) I plan on asking what a "rule of thumb" means (in a separate talk page section), unless someone beats me to it of course. Let's just not discuss it here intermixed with my original question above, please. Cheers CapnZapp (talk) 10:20, 25 February 2020 (UTC)

"Rule of thumb" is a perfectly normal English phrase, not something that requires an idiosyncratic definition on Wikipedia. It being a rule of thumb there is no material difference between 75K and 150K. Phil Bridger (talk) 11:35, 25 February 2020 (UTC)

If you want, we could set up a second talk section right now. CapnZapp (talk) 14:27, 25 February 2020 (UTC)

Why on Earth would I want that? As I said, "rule of thumb" is a perfectly normal English phrase that already has a standard meaning. Why should Wikipedia editors give it a different meaning? Phil Bridger (talk) 14:36, 25 February 2020 (UTC)

Then you will have no problems answering my questions over here, Phil: #Rule of thumb. Cheers CapnZapp (talk) 11:25, 26 February 2020 (UTC)

No, by all means let's not intermix one misbegotten, pointless discussion with another misbegotten, pointless discussion. Pointless discussions should proceed in an orderly fashion. EEng 11:49, 25 February 2020 (UTC)

• Seriously? SERIOUSLY??? You're inviting people from VP (policy) to talk about whether 50K or 75K is a better number for a limit no one pays attention to so as to better address an urgent problem for which there's no evidence of an actual problem? EEng 11:22, 25 February 2020 (UTC)
• Given that I usually delete messages from my main user talk page once I have read them (I treat my talk page as being similar to voicemail)... and thus rarely (if ever) get close to any arbitrary “limit”... anyone who goes over the limit can hereby have my “extra” unused KBs. Blueboar (talk) 12:29, 25 February 2020 (UTC)

  Now see, that's what Wikipedia is all about: people helping people. EEng 12:46, 25 February 2020 (UTC)

Remember..

The Rule of Thumb

• Uhm...expand size - 5g is coming, internet speed is increasing. Oh, and add anchors to sections so they're easier to find. ^Atsme _Talk 📧 14:24, 25 February 2020 (UTC)

• I'd rather see talk pages reverse chronology so I don't have to scroll through all the old crud on the excessively long pages. Other than that, 25kb/75kb/1mb, as long as you aren't takes minutes to load, shrug Slywriter (talk) 14:56, 25 February 2020 (UTC)

  ^^^ THIS. When can we change this to be in line with how the rest of the world works? Levivich (talk) 18:02, 25 February 2020 (UTC)

  Lev, see how I get the creative juices flowing with a simple comment? That must be why they call it a "Talk page". ^Atsme _Talk 📧 20:45, 25 February 2020 (UTC)

  We shouldn't be trying to do what the rest of the world does, but what is best for Wikipedia. For example, the rest of the world does not create the world's foremost encyclopedia, or follow our basic content policies. I see the forward chronology of talk pages both as obviously logical, and as something to be praised. People should look at previous discussions on talk and user talk pages before commenting themselves, rather than risk continual repetition. Phil Bridger (talk) 18:37, 25 February 2020 (UTC)

  I do not find that argument persuasive. When people go to a user's talk page to start a new discussion, they press the + or "new discussion" button at the top. They don't read the whole talk page. If anything, putting the most-recent discussion at the top of the talk page will increase the chances that a new visitor to the page will read it and avoid repetition. Talk pages come in two flavors: (1) those that aren't archived, which nobody is going to read because they're too long, and (2) those that are archived, and few editors will read through someone's archives before staring a new thread–even a keyword search is more effort than most will put in. So, I don't think forward chronology is any kind of improvement on the reverse chronology that is the standard for just about every other type of text-based communication software ever made. There's a reason everyone uses reverse chronology: the most recent communications are the most important, and thus should be the easiest to get to (the least scrolling). If we were really in the 21st century, or even the late 20th, we would have recently-edited sections automatically moved to the top of the page. Levivich (talk) 19:42, 25 February 2020 (UTC)

  Finally, something Levivich and I completely disagree on. I suggest we carry out the debate in Burma-Shave format. EEng 00:08, 26 February 2020 (UTC)

  OK here's the Burma-Shave summary of my argument above:

  NO ONE READS
  WHEN IT'S TOO LONG
  NO ONE READS
  WHEN IT'S ALL GONE
  NEW THREADS SHOULD GO AT THE TOP
  THE OTHER WAY IS WRONG
  Burma-shave

  Rebuttal? Levivich (talk) 04:55, 26 February 2020 (UTC)

  no shade at y'all, the burma shave joke is a good one generally speaking, but am I the only one getting a little bored with it? Writ Keeper ⚇♔ 15:13, 26 February 2020 (UTC)

  Writ Keeper, Bored? With Burma-Shave? Impossible. Jeb³_{Talk at me here}^{What I've Done} 15:53, 28 February 2020 (UTC)

  He's the guy who said to Shakespeare, "What? Another sonnet?" EEng 16:01, 28 February 2020 (UTC)

  dude did like a hundred of them. get a job already Writ Keeper ⚇♔ 18:08, 28 February 2020 (UTC)

  Bored with it? Don't you mean beard with it? ... No, nothing? ... I'll show myself out now. --Jayron32 18:21, 28 February 2020 (UTC)

  @Writ Keeper: Bored with Burma Shave? Say it ain't so. Can I play too? The Bards old Sonnets / They aren't too long / Who can be bored / With his cool songs / Got a wall of text? / Cut it down. / Burma-Shave davidwr/(talk)/(contribs) 18:30, 28 February 2020 (UTC)

  When people go to a user's talk page to start a new discussion, they press the + or "new discussion" button at the top.

  I wish. Or at least if you're going to start a new section by editing the last one on the page (example), please change (or at least remove) the section heading in the edit summary. WhatamIdoing (talk) 05:06, 28 February 2020 (UTC)

  Like this. --Redrose64 🌹 (talk) 12:21, 28 February 2020 (UTC)

• Why? - That is, we need to ask ourselves the reason to have limits at all. From there, we can develop rules of thumb for specific cases. Some common answers to "Why" include:
  • Readability/usability by the reader
  • Edit-ability of the whole page by web browsers that may be running on slow computers
  • Time to download by people with slow or poor-quality internet connections
  • Server resources expended with each page load or cache purge

Other than readability, the 75K limit is probably lower than it needs to be. My recommendation is that any guidance other than "don't overload server or blow past Wiki-software limits" or "don't make loading and editing the page impractical for a significant portion of users" should be over-ride able by "local consensus" or for a user's own talk page, by that user. So if we decide it's 75K, but the local consensus on a particular talk page says 200K, and that's not going to cause technical problems for the server, editors, or readers, then 200K it shall be for that particular talk page. davidwr/(talk)/(contribs) 17:40, 25 February 2020 (UTC)

• The portion of the talk-page size attributable to discussion of forming a local consensus as to what the talk-page size should be – will that count toward the size limit, or will it be deductible?
• Server resources expended with each page load or cache purge – Are you joking? Am I just dreaming that it's 2020? Is it really still 1999? EEng 18:19, 25 February 2020 (UTC)

EEng 18:19, 25 February 2020 (UTC)

@EEng: I wasn't joking about the server limits or more accurately, software limits. Two recent discussions where these had an impact are here and here (2nd is article-page-related). There are several Wikipedia tracking categories devoted just to listing pages affected by these limits. You can find them listed among the other tracking categories at Special:TrackingCategories. It's my understanding that some of these limits exist not because the Wikipedia servers are wimpy (they are not) but rather to make it a bit harder for someone to do a denial-of-service attack on them. I think I read that over on Meta or one of the other Wikimedia projects, but unfortunately I don't remember where. davidwr/(talk)/(contribs) 20:29, 25 February 2020 (UTC)

You didn't say anything about server limits or more accurately, software limits being a relevant consideration for a possible page-size limit; you talked about Server resources expended with each page load or cache purge, which is quite different and none of our business whatsoever as editors (with the narrow exception of template editors) – see WP:PERFORMANCE. EEng 23:21, 25 February 2020 (UTC)

My initial choice of wording was imprecise and in retrospect, misleading and confusing. davidwr/(talk)/(contribs) 23:40, 25 February 2020 (UTC)

Indeed. EEng 00:03, 26 February 2020 (UTC)

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

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

What value do you ascribe to the way the guideline mentions a specific number, Phil? CapnZapp (talk) 15:22, 28 February 2020 (UTC)

• Five years is way too soon to be going down this rabbit hole again. Cabayi (talk) 16:02, 29 February 2020 (UTC)

  And there's something of a lesson in the fact that Technical 13, who instigated that particular unnecessary clusterfuck, ended up blocked for something way way worse than a long talk page: sockpuppetry. EEng 18:34, 29 February 2020 (UTC)

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

• Over the years I've seen talk page archiving used to censor discussions. If it were up to me, it would just be 25 minthreads wiki-wide. EllenCT (talk) 16:31, 11 March 2020 (UTC)

Rule of thumb

What does "rule of thumb" mean?

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

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

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

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

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

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

• What does "deckchairs on the Titanic" mean? EEng 14:07, 26 February 2020 (UTC)

• If you think that someone may not be aware of this rule of thumb then of course you can point it out once politely, but it is that editor's choice whether to take any action. There is certainly no point in telling someone about it who you know already knows. Phil Bridger (talk) 14:11, 26 February 2020 (UTC)

  So not binding. Thanks for replying, I did not know "rule of thumb" carried that meaning, but then again, I'm not a native English speaker. CapnZapp (talk) 16:44, 26 February 2020 (UTC)

• @CapnZapp: "Rule of thumb" means that yes, you can point to TALKCOND to ask people to archive their user talk page, but also that they can reply with "no". It's there mostly as a suggested starting point for archiving article talk pages, to provide guidance for when archiving article talk pages is helpful without being overzealous, since like DGG says elsewhere, there's value to keeping closed discussions around for reference. Strictly speaking, user talk pages are a subset of talk pages as a whole, so yes, this suggestion could be considered relevant to them, but it's no more than that. And as Phil says, if they're already aware of the guideline (as EEng, for example, clearly is), there's no point in bringing it up to them, because as a rule of thumb, it's not binding. Writ Keeper ⚇♔ 15:04, 26 February 2020 (UTC)

  So not binding. Thanks for replying, I did not know "rule of thumb" carried that meaning, but then again, I'm not a native English speaker. CapnZapp (talk) 16:44, 26 February 2020 (UTC)

• "Rule of Thumb" means "You can't make me" It's merely a phrase that allows assholes to violate rules without consequences. Either it's an enforceable rule or it's meaningless. I would remove it and say something like "Users should archive talk pages when they get too large. If a user is warned for having an unmanageably long user talk page, and refuse to comply with requests to archive it or delete old threads to bring it into compliance, they may be sanctioned with blocks until they comply". If you aren't willing to do that, there is no point in even writing a suggestion. --Jayron32 15:25, 26 February 2020 (UTC)

  Thanks for replying. It will be interesting to see what, if any, change to the wording we end up with CapnZapp (talk) 16:44, 26 February 2020 (UTC)

  So in your view any guideline is worthless if not accompanied by an iron-fist enforcement mechanism guaranteeing 100% adherence? EEng 16:58, 26 February 2020 (UTC)

  Nope. Just this one. If you would like to start a discussion on the wording of another guideline, start the discussion on that guidelines talk page, and we'll see what we can do. Other guidelines may or may not need enforcement because they aren't making pages unusable. This one is, and thus needs more teeth to make it useful.--Jayron32 17:02, 26 February 2020 (UTC)

  Your reasoning makes no sense. It would still be useful even if, despite the lack of the iron fist, it nonetheless prompted 80% or 60% or even 30% of users to keep their pages short. EEng 00:23, 27 February 2020 (UTC)

  Users who already keep their page short enough don't need the help. It's only users who, after being told why having a stupidly long page is harmful, respond with "I don't care, I'm not shortening it unless there's a rule that forces me to." That's who we need a rule for. People who either archive on their own, or who maybe get absent minded, or when you say "hey, can you archive your talk page, its length makes it hard to read" and say "No problem, I'll get right on that!" don't need guidance. They just solve their problems on their own, or understand the importance of being collegial in a collaborative workspace. It is people who adamantly refuse to be useful, even after being told why they are causing problems, who need rules. --Jayron32 20:36, 27 February 2020 (UTC)

  You're enumerating combinations of predicaments and attitudes that may apply to various species of editors, but that doesn't exclude their being yet another species you're simply ignoring i.e. those who, without guidance, won't understand that archiving is often desirable, but if there is guidance, will understand and do it, all other things being equal. And that can be true even without an enforcement mechanism. So it's just not true that unless user can be sanctioned with blocks until they comply then there is no point in even writing a suggestion. EEng 22:37, 28 February 2020 (UTC)

• Rather than asking random people on the internet, you'll get better, more reliable information from this online encyclopedia that anyone can edit called Wikipedia. Rule of thumb: The English phrase rule of thumb refers to a principle with broad application that is not intended to be strictly accurate or reliable for every situation. It refers to an easily learned and easily applied procedure or standard, based on practical experience rather than theory. This usage of the phrase can be traced back to the seventeenth century and has been associated with various trades where quantities were measured by comparison to the width or length of a thumb. As to why we have a rule of thumb and not a specified number, see the fifth pillar ("no firm rules"). Levivich (talk) 16:54, 26 February 2020 (UTC)

Insinuating I'm asking "random people on the internet" is just ridiculous. If you don't believe this is the proper place to have this discussion, feel free to suggest a more appropriate venue. Please don't link to the general encyclopedia; this issue is about Wikipedia's own policies and guidelines, and regular article space don't apply. Please don't use a generic argument like "no firm rules" like a blunt instrument - we have quite specific limits in several areas, and you need to argue why this can't be one of them. CapnZapp (talk) 15:18, 28 February 2020 (UTC)

• Also see the "folk etymology" section of rule of thumb which, despite being more-or-less debunked, is widely enough believed to cause the phrase to be very offensive to some people. Maybe we can find a different phrase to use that doesn't lead to that reaction. —David Eppstein (talk) 01:19, 27 February 2020 (UTC)

My priority is using a phrase that makes it clear what the number (currently 75K) signifies. I can't think of another guideline mentioning a number but then assigning zero relevance to it, at least without giving further context. Can you? Regards, CapnZapp (talk) 15:18, 28 February 2020 (UTC)

It's not "zero relevance", and WP:IAR has already been brought to your attention. Once you've grasped rule of thumb I suggest you contemplate wikt:tone-deaf (sense 4). EEng 15:51, 28 February 2020 (UTC)

Your attempts to derail or belittle this discussion only paints you as a fool, EEng. Since me and other editors have actual issues with the current wording of the guideline, please don't come running with "ignore all rules". As other editors have already understood, our issue is not a failure to grasp rule of thumb, but to question why we're using language that not only does not provide any guidance in a guideline, but actually obscures that behind language nobody can agree what it means. CapnZapp (talk) 11:30, 3 March 2020 (UTC)

Examples

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

But... but... unless there's a bright-line rule, and an iron-fist enforcement mechanism, editors will be adrift, without guidance or compass, and chaos will reign! EEng 23:26, 29 February 2020 (UTC)

My reflection at this point in time is that this discussion attracts comments from editors whose own talk pages are far larger than 75K, and that they are opposed to regulating user talk page size. CapnZapp (talk) 11:30, 3 March 2020 (UTC)

Man, you're quick! EEng 21:58, 3 March 2020 (UTC)

My talk page is about 25 K long (thanks to Jimmy Wales pushing it over that number yesterday) and it will, depending how many people want to talk to me there, probably grow to about twice that size before I archive it - still well within the current rule of thumb. That is big enough for my needs, but I understand that there are editors who get involved in many more user talk page discussions than I do so may need to have a much larger talk page. There are two conflicting forces at work here: the need of users on slow or unreliable connections (such as mobile in some places) to access a small talk page, and the need to avoid archiving discussions where someone might comment further. In the case of prolific editors these forces may come into conflict, so the "owner" of the talk page needs to make a judgement, which is helped by gentle advice rather than strict enforcement. Phil Bridger (talk) 16:28, 5 March 2020 (UTC)

As for me, I understand the need to be reasonable; I do not understand the need to be uniform. I am halfway to bringing it back to reasonable, as I have done periodically, but it will still be about 400 K. I consider that the right size for what I want to do, and as has been explained by others, it should not make difficulty on any current computer or tablet. phones, not yet, but I'm working on it.

As for the general question, the first step for bring things uptodate is to change the 75kB to 150kB. regardless of what is decided otherwise, that's the minimum needed change) DGG ( talk ) 00:10, 7 March 2020 (UTC)

Use Template:Do_not_archive_until?

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

I'm not DGG, but the answer is yes. For an example, see the wikitext of Talk:Latino (demonym) #Argumentative sock blocked where the {{DNAU|730d}} shortcut is used inside the post. The instructions at Template:Do not archive until/doc give more detail. --RexxS (talk) 18:30, 6 March 2020 (UTC)

I'm not DGG either, but please note he was asked to clean up his talk page already two years ago. It is clear that this guideline is trying to both eat and have the cake. Either rephrase it to give the community the mandate to make users clean up their mess, or rephrase it to make it clear the community allows unlimited user talkies. CapnZapp (talk) 08:34, 12 March 2020 (UTC)

Proposed change to off-topic discussions guideline

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

• Support as proposer.^{Courtesy ping EEng} Sdkb (talk) 22:43, 11 March 2020 (UTC)

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

As it stands, the guideline favors continued discussion and discourages peremptory cutoff. You've put cutting off on the same footing as continuing. As it stands, the guideline favors continued discussion and discourages peremptory cutoff. Your change puts cutting off on the same footing as continuing. Adding a followup comment to a collapsed thread is nice, but that doesn't change the fact that the collapsed thread is still nominally closed, and discussion is cut off for all practical purposes. EEng 13:22, 12 March 2020 (UTC)

Why would we want to favour continuation of an off-topic discussion? --RexxS (talk) 13:34, 12 March 2020 (UTC)

Like it says later in the guideline's paragraph Your idea of what is off topic may differ from what others think is off topic, so be sure to err on the side of caution – the question often becomes clear only with continued discussion. EEng 13:52, 12 March 2020 (UTC)

Hmmm, and I've been t-banned for "continued discussion" and reprimanded for it despite the BRD restriction. I always the "D" in BRD was DELETE because editors have been discouraged from discussing issues on TP; the latter of which may have been a determination born of inadvertent bias, or so it seems. ^Atsme _Talk 📧 15:01, 12 March 2020 (UTC)

@EEng: I agree that we should err on the side of uncollapsing when it's borderline or unclear whether something is off-topic, and I'm fine retaining the sentence from later in the paragraph in the guideline. I'd like to have my addition because I think the decision on where that line is is better made by uninvolved editors. I agree with RexxS that in situations where everyone else recognizes the line has been crossed and a conversation is off-topic, it's best that involved editors don't revert them to uncollapse the thread. Sdkb (talk) 21:25, 12 March 2020 (UTC)

Any examples where that's been a problem? EEng 23:18, 12 March 2020 (UTC)

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}}: {{subst:Unsigned|USER NAME OR IP}}.

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}}: {{subst:Unsigned|USER NAME OR IP|DATE AND TIME}}.

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) [2] [3] 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. --Masem (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. |<var>DATE AND TIME</var> - was already there, and is long-standing. It can be traced back ten years to this series of edits made by SMcCandlish (talk · contribs); and even that, minus the <var>...</var> tags, goes back even further, to this edit in 2007. You removed it, I reverted you, and then you removed it a second and indeed third time, both being reverted by RexxS (talk · contribs). Diffs: your initial removal; my revert; your second removal; RexxS's first revert; your third removal; and RexxS's second revert. 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. --Redrose64 🌹 (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)

EEng I use the {{xsign}} template (my time is set to UTC): Examples –xeno^talk 17:09, 13 March 2020 (UTC)

xeno - 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 18:01, 13 March 2020 (UTC)

Unable to wok out a time in UTC

-EEng

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. EEng 00:55, 16 March 2020 (UTC)

• EEng, 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. EEng 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 a recent example; and another; and a third. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:45, 13 March 2020 (UTC)

  I specified "in the last week" [4] for a reason, and perhaps I should have added, "other than by technogeeks". Where did you copy the timestamp from? EEng 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. EEng 18:01, 13 March 2020 (UTC) P.S. What "latter template" are you referring to?

• I also regularly use {{subst:unsigned}}, but EEng asked for uses by other people. One such is Graham87 (talk · contribs), for example with this edit. --Redrose64 🌹 (talk) 12:56, 13 March 2020 (UTC)

  I've since found this edit by Marchjuly (talk · contribs). --Redrose64 🌹 (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! EEng 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. --Redrose64 🌹 (talk) 11:36, 15 March 2020 (UTC)

  @EEng: Neither Redrose64 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 Sinebot, 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#Attributing unsigned comments” 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)

  <weeps quietly> 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! EEng 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. <pedant>The expression is with bated breath, not baited.</pedant> Cabayi (talk) 13:01, 13 March 2020 (UTC)

  No, in context it's definitely baited breath. Maybe Valereee can explain it to you. EEng 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)

• 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). Graham87 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. Xeno (not pick on you, but were were talking about it above)? EEng 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 here? --Redrose64 🌹 (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. EEng 05:19, 14 March 2020 (UTC)

  EEng 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. –xeno^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. EEng 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)

  @Valereee: 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 Marchjuly (talk · contribs) 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 {{subst:unsigned}} template. You can even omit the (UTC) part and {{subst:unsigned}} will add it in for you. --Redrose64 🌹 (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. EEng 00:46, 16 March 2020 (UTC)

  See my post of 10:33, 13 March 2020 (UTC) and stop pretending. --Redrose64 🌹 (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)

Redrose64, 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:{{{1}}}|{{{1}}}]] ([[User talk:{{{1}}}#top|talk]] • [[Special:Contributions/{{{1}}}|contribs]]) — Preceding unsigned comment added by [[User:{{{1}}}|{{{1}}}]] ([[User talk:{{{1}}}#top|talk]] • [[Special:Contributions/{{{1}}}|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, Valereee, 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. EEng 00:46, 16 March 2020 (UTC)

EEng, 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. Zero^talk 12:41, 15 March 2020 (UTC)

  Zero0000 gets it. EEng 00:46, 16 March 2020 (UTC)

• I suppose {{subst:Unsigned|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 {{unsigned}}, 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. EEng 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)

Bagumba, 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)

@Valereee: "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:

• {{subst:unsigned}} → — Preceding unsigned comment added by [[User:{{{1}}}|{{{1}}}]] ([[User talk:{{{1}}}#top|talk]] • [[Special:Contributions/{{{1}}}|contribs]])

which is no use to anybody. --RexxS (talk) 18:55, 16 March 2020 (UTC)

RexxS, 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. EEng 20:36, 16 March 2020 (UTC)

@Valereee: 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)

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 {{subst:Unsigned}}: {{subst:Unsigned|USER NAME OR IP}} or ideally but optionally {{subst:Unsigned|USER NAME OR IP|DATE AND TIME}}.

...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: {{subst:Unsigned|USER NAME OR IP}}. (Ideally but optionally a timestamp will be added as well – see the template documentation.)

EEng 15:33, 16 March 2020 (UTC)

"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}}: {{subst:unsigned|USER NAME OR IP|DATE AND TIME}}." is better. --RexxS (talk) 18:57, 16 March 2020 (UTC)

RexxS, 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)

EEng, 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. EEng 20:00, 16 March 2020 (UTC)

@Valereee: Not everybody is as inept as you, and the plural of "anecdote" is not "data".

@EEng: 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)