Wikipedia talk:Talk page guidelines

Images on talk pages

With this edit, Cambalachero added, "Non-free content can not be used at talk pages. If they are being discussed, they must be linked with a colon, as described, and If they are included for decorative purposes, they must be removed. "

But Wikipedia:Non-free content criteria states, "Non-free content is allowed only in articles (not disambiguation pages), and only in article namespace, subject to exemptions."

Thoughts? Flyer22 Reborn (talk) 06:17, 9 June 2017 (UTC)

I think you have found an error dating back to 2005 . The language you quoted is obviously flawed because all articles are in article name space . This redundancy appeared In this edit. Prior to that time the text said Non- free images may only be used in article namespace, period. That text gave the green light to article talk pages. the extra text saying " only in articles " was probably intended to preclude disambiguation pages, since an explanatory parenthetical comes right after the quoted " only in articles". Seems like the only way to really resolve this for purposes of these guidelines as to attempt to fix this problem on the guideline for non-free use . But that does seem worth doing since the confusion here appears to be the result of a clerical mistake in the diff I provided. It should probably read " only an article name space , excluding disambiguation pages . NewsAndEventsGuy (talk) 07:15, 9 June 2017 (UTC)

Articles need not be in article space. They might be in User: space, or in Draft: space. Also, that text did not give the green light to article talk pages: article talk pages are in Talk: space - they are the talk pages for pages that are in article space, but they are not in article space themselves. --Redrose64 🌹 (talk) 09:42, 9 June 2017 (UTC)

oops, thanks for pointing out that an article talk page is not in article namespace.... WP:Namespaces. I hate not noticing when I am assuming! NewsAndEventsGuy (talk) 11:28, 9 June 2017 (UTC)

Would someone please spell out the problem? Flyer22's OP includes two quotes:

1. "Non-free content can not be used at talk pages ..."
2. "Non-free content is allowed only in articles ... only in article namespace ..."

These statements seem to agree. The first is spelling out a consequence of the second, and the second has more detail (it's not just article talk pages where non-free content is prohibited). I regard "only in article namespace" as a redundant device to hose down wikilawyers who may argue they can copy an article to a user subpage and retain non-free content because it is no different from the "article". Indeed, Redrose64 gives that reasonable interpretation, although I would regard a copy of an article as different from the actual article. For example, article categories should be removed from copies of articles. Johnuniq (talk) 10:17, 9 June 2017 (UTC)

Let's put for example the lead image of The Avengers (2012 film). Writing [[File:TheAvengers2012Poster.jpg]], without colon, displays the image. That's what can only be done in article namespace. Writing [[:File:TheAvengers2012Poster.jpg]], with a colon, generates a mere link to the image, File:TheAvengers2012Poster.jpg. That's just a link, and may be used anywhere. It is not the image itself, but just a software element to make reference to the filename used to store the file. Cambalachero (talk) 12:06, 9 June 2017 (UTC)

IP user talk page

I'd welcome other opinions on this edit.

It seems to me that it's not what the guideline intends at all. But in that, as far as I can tell, IP user talk pages are in namespace 3, the same as the talk pages of registered users, perhaps this needs clarification.

See Wikipedia:Administrators' noticeboard/Incidents#User:185.59.158.22 for some of the background to this. Andrewa (talk) 05:11, 26 June 2017 (UTC)

@Andrewa: It's explicitly prohibited by WP:REMOVED, fourth bullet. --Redrose64 🌹 (talk) 08:05, 26 June 2017 (UTC)

So it is! Thank you. Andrewa (talk) 08:24, 26 June 2017 (UTC)

DTTR

I believe we should codify in these guidelines that WP:DTTR is not sufficient grounds to justify removal of a post on a talk page other than your own. Though DTTR is often treated as a policy or guideline, it isn't one, there's an antithetical one called Wikipedia:Do template the regulars, and user warnings are specifically written to not be personal attacks. Thoughts? pbp 14:03, 11 August 2017 (UTC)

WP:DTTR is just an essay, which can be boiled down to "templates often treat the editor as brand new, and provide helpful links - regular editors (should) already know about all the links and what's expected of them, so treating them otherwise isn't the best idea". Regardless of if someone agrees or disagrees with DTTR, it does not give grounds to remove a post from a talk page other than your own -- There'sNoTime ^{(to explain)} 14:15, 11 August 2017 (UTC)

• Oppose See WP:CREEP. While I agree this is a correct reading of existing rules, observe that 3 of us read the existing rules as already frowning on third party talk page reverts of this sort. NewsAndEventsGuy (talk) 17:16, 11 August 2017 (UTC)

Very old talk pages

On old talk pages, I find some weird layouts.

---

text
reply

---

text
reply

reply

---

etc

What was that? — Preceding unsigned comment added by Nixinova (talk • contribs) 20:42, 13 August 2017 (UTC)

Guidance against interleaving replies

Proposed text for introduction in "Editing others' comments" section:

"Generally you should not break up another editor's comment to reply to individual points. Interleaving comments like this confuses the layout of the page and obscures the original editor's intent, as well as potentially leaving text unsigned."

Version 2 of proposal (19:49, 14 August 2017 (UTC)):

"Generally you should not break up another editor's comment to reply to individual points. Mixing comments like this confuses the layout of the page and obscures the original editor's intent, as well as potentially leaving text unsigned. Instead, place your reply entirely below the original comment. You may wish to use the {{Talk quotation}} template to quote a portion of the material in question."

I have encountered a few times situations where to respond to seemingly itemized multiple points an editor interleaves their reply within the post they are replying to, for example as Andrewa did here (I'm inviting them to continue the discussion here out of courtesy). It may be particularly prone to happen when a post has bulleted points which I have seen a couple times and which made a real mess of the talk page. The biggest issue is that it leaves the original post's text broken up and without signatures. If signatures were added after the fact that would, to me, definitely constitute editing another's post and changing what they intended to convey and how they wanted it to look, without improving the clarity of formatting. I think instead the proper convention should be to say something like Regarding X, "Regarding X," whether X is a description or a numbered point in cases where there is one, or Quoted material: with the tq template, and to do this entirely below the post you are replying to. I am proposing that some guidance be added in this regard. —DIYeditor (talk) 00:26, 14 August 2017 (UTC) Edited to correct use of tq template. 19:08, 14 August 2017 (UTC) Updated with Version 2 of proposal. 19:49, 14 August 2017 (UTC) Underlined version 2. 02:06, 15 August 2017 (UTC)

The convention as I have followed it is not to break up existing paragraphs. It is in my experience easily learned and followed, and common elsewhere on the Internet. The indenting makes the authorship plain, and the interleaving makes the logic plain. Respecting others' paragraphs leaves their comments intact.

The proposed addition doesn't really make it clear that this is discouraged, and I'm not convinced it should be.

The convention I have followed is however easily messed up, either accidentally or deliberately, and when this happens it can get very messy.

I'd like a stronger statement on the mixing of colon and asterisk indenting. This is the most common way that the convention gets messed up, in my experience. Andrewa (talk) 01:02, 14 August 2017 (UTC)

No, please do not do that. Consider what might happen if someone wanted to reply to you, and then there was some back-and-forth. That leaves a dreadful mess. Talk pages are not just for the benefit of those currently participating who might know what is going on. In a year, people might want to work out why a particular decision was taken or not taken. Johnuniq (talk) 03:10, 14 August 2017 (UTC)

Exactly. But the mixing of asterix and colon indenting is depressingly common, and as you say often leaves a dreadful mess... I'll dig up some examples. Sometimes I suspect it is even deliberate rantstyle (I might not give examples of that as it raises behavioural issues) but other times it is, disappointingly, experienced and respected users, to the point I sometimes suspect I'm just being grumpy to criticise it. But if we could avoid it, it would greatly increase the value of the archives, as you say, as well as making it easier IMO to arrive at and assess consensus in the first place. Andrewa (talk) 06:34, 14 August 2017 (UTC)

This edit is a case in point - I fixed three problems there:

1. blank lines, contrary to WP:INDENTGAP (and which incidentally I have also fixed in this edit);
2. signature divorced from post by interspersed comments;
3. markup symbols inconsistent bwtween a post and its reply which caused the enumerated list to restart at 1 instead of continuing with 3.

Mixing the three styles (asterisk, colon and hash) is not a problem per se, the problem is when people mix them incorrectly. The general principle should be that if you reply to somebody, copy the markup from the start of their post, whatever combination of symbols that might be; and add one symbol (of any type) to the right hand end. --Redrose64 🌹 (talk) 09:01, 14 August 2017 (UTC)

Agree that the protocol proposed in the above post copy the markup from the start of their post, whatever combination of symbols that might be; and add one symbol (of any type) to the right hand end would work extremely well if followed consistently. But we need to deal with bold edits by inexperienced editors as well as considered edits by old hands, and as even the old hands often depart from the relatively simple current rule of Generally colons and asterisks should not be mixed for no obvious reason, there's reason to be very afraid of a new and more complex rule. I think on balance it would be worth a try. Andrewa (talk) 13:16, 14 August 2017 (UTC)

You know, Wikipedia possesses specific tools which allows one to reply to a specific section or paragraph of an other contributor's post. For instance, the template {{Talkquote}} allows one to quote the specific part of the post one wishes to reply to, complete with signature and linked timestamp, within one's own post below which one can then post one's own reply.Tvx1 17:21, 14 August 2017 (UTC)

Certainly... at the expense only of brevity. But that can also raise objections, in my experience. Andrewa (talk) 22:39, 14 August 2017 (UTC)

• Support Although long posts can be troubling in themselves, interrupting their flow to reply to a specific point takes any shortcoming with the fact its a long post and multiplies that by 10. So don't do that please. In the discussion I noticed two related and somewhat side issues to which I reply as follows -

Re A) on messy format.... see WP:SOFIXIT. These guidelines already encourage stand-alone edits that only clean up formatting problems. I usually do not do that with regulars unless I get their permission first. But for newbies, don't hesitate, just do it, and give them a friendly how-to-do-better-formatting note.

Re B) on replying point-by-point.... hopefully my comment here shows how I do this. If the long post does not include numbers or letters so you can reply that way, just give the point you want to reply to a letter or number and say what you wish after the longwinded editor's signature.

In closing, I think the suggestion to not insert comments in the middle is a good one, but I don't care for the word "interweave". My brain stopped cold, I had to think, it was an obstacle. Better to just use simple third grade language, something only a bit more refined than "Don't butt in line". NewsAndEventsGuy (talk) 14:06, 14 August 2017 (UTC)

Perhaps "Mixing comments" rather than "Interleaving comments"? And how about some additional guidance like: "Instead, place your reply entirely below the original comment." and perhaps "You may wish to use the Talk quotation template to quote a portion of the material in question." I agree that keeping it simple would be good but maybe some clear advice on what to do in addition to what not to do would help. —DIYeditor (talk) 19:19, 14 August 2017 (UTC)

Positive guidance, rather than negative, is greatly to be preferred. It is both far more likely to be effective and adheres to the spirit of wp:AGF. Andrewa (talk) 19:45, 14 August 2017 (UTC)

I don't think those are side issues at all...

A) I would welcome strengthening the relevant guidelines to make that a bit clearer. In particular, In general... is vague. If the proposed more elaborate guideline (which is growing on me) is adopted, I hope the phrasing will be more to the point than that.

B) Yes, that works in cases like this. Another technique which I have employed is to start a new subsection on a particularly important point that is raised. I've received some criticism in the past for doing this, but generally from those who did not wish to hear what was said (at the risk of violating wp:AGF... sometimes the assumption wears a bit thin). Andrewa (talk) 19:45, 14 August 2017 (UTC)

Andrewa, as far as your A) on this this proposal maybe it should simply be "You should not" rather than "Generally". I wasn't sure if consensus would be behind a strong statement but it seems to be heading that direction. —DIYeditor (talk) 23:58, 14 August 2017 (UTC)

I must state that I cannot stand when an editor breaks up my comment to reply to individual parts. Any time that it is done, I either put my comment back the way it was or copy and paste my signature for each part of the broken up comment to make sure that others are not confused by who is commenting. And I ask the editor not to break up my comment like that again. Flyer22 Reborn (talk) 02:33, 31 August 2017 (UTC)

Modifying comments already replied to

This edit rather surprised me... wouldn't it be better to raise it as a new post, with a heads-up? Andrewa (talk) 01:11, 15 August 2017 (UTC)

It's got a time stamp. Perhaps should have been underlined if it is not clear by the time stamp that it was a change. —DIYeditor (talk) 02:03, 15 August 2017 (UTC)

Yes, it complies perfectly with the guideline on modifying your own comments (WP:REDACT) as far as I can see. But it seems to me far more confusing than my edit [1] which inspired this whole section. I think the indenting there makes the signatory of the original post quite transparent, but I concede there are other views on this. But I can't see how this edit can fail to tangle the logic of the discussion. The text to which I was replying is no longer there to see, you need to go into the page history to find it. How can that possibly be helpful? And yet it seemingly conforms to guidelines. Should it? Andrewa (talk) 04:10, 15 August 2017 (UTC)

Well, without software to manage talk page comments all we have are manually implemented guidelines. If users are to be able to edit their posts I think strike and insert work well enough, as well as the instruction to add a new timestamp when you've done it. On some forums where users can edit their posts the custom is to do something like "Edit: I did so and so" at the end of the edited post which I think is less clear than our strike/underscore method, but we also include a suggestion to offer an explanation if necessary in brackets. Or are you proposing that users not be able to edit posts once they are replied to? This is always an issue in forums; what it appears someone responded to may actually have been edited. Without strongly discouraging or prohibiting edits I don't see a way around it. My thinking was that it would be useful in that particular situation if the proposal were updated at the top which I believe I've seen done in other surveys. Maybe it would be useful to have clear guidance on that specific circumstance - what if you want to add another option to a survey. To me at the top makes sense as long as it is clearly marked as an edit with a time stamp. It also makes sense to include a "Survey" and "Threaded discussion" section which I wish I'd done to keep the two separate. Then any updates to the survey or !votes on it can be kept in the same area. —DIYeditor (talk) 06:22, 15 August 2017 (UTC)

Strike does not have appropriate semantics, see HTML5 documentation: The s element is not appropriate when indicating document edits; to mark a span of text as having been removed from a document, use the del element.; and underscore does not have any associated semantics. For accessibility reasons, we should be using <del>...</del> and <ins>...</ins> respectively, see HTML5 documentation. --Redrose64 🌹 (talk) 14:38, 15 August 2017 (UTC)

Version 2

Proposal:

"Generally you should not break up another editor's comment to reply to individual points. Mixing comments like this confuses the layout of the page and obscures the original editor's intent, as well as potentially leaving text unsigned. Instead, place your reply entirely below the original comment. You may wish to use the {{Talk quotation}} template to quote a portion of the material in question."

1) Replaces "interleaving" with "mixing" per NewsAndEventsGuy's concern. 2) Adds a brief description of what to do in addition to what not to do. 3) A question from Andrewa is whether this should start with "Generally you should not" or stronger wording like "You should not". I thought the stronger wording may not cover every possible situation which is why I started with "Generally". 4) I felt that only a brief mention of the quote template that is most often used would be best and we should avoid putting a detailed style guide for replying in the "Editing others' comments section", but conceivably we could start a new section about quoting/replying. It could for example cover numbering or lettering points (if that's not obvious) and {{Talkquote}} (a different template from {{Talk quotation}}). That is more than I wanted to get into originally and even if that were added I think a statement in the "Editing others' comments section" against splitting another editor's post would still be appropriate. —DIYeditor (talk) 03:09, 15 August 2017 (UTC)

It's rearranging deckchairs. The more we look at the guideline the worse it gets, see #Modifying comments already replied to. Total rewrite required, incorporating the "add one of anything to the right" suggestion for more sophisticated users, and a far simpler protocol for beginners, example-based. And I still think that a brief interspersed comment is helpful on occasions, but I will of course go with the consensus on this. Andrewa (talk) 04:19, 15 August 2017 (UTC)

There may be some issues with this page as far as providing enough detail but I think the main places to address that are Help:Using talk pages and Wikipedia:Indentation (and any other topic specific locations). Providing examples and detailed style guides here would totally change the nature of the page. It is supposed to be dos and don'ts more than detailed instructions. We can make sure the reader is pointed in the right direction for more information. —DIYeditor (talk) 06:00, 15 August 2017 (UTC)

This proposal is a very welcome clarification. But I'm concerned that it is sufficiently severe in its impact as to require wider discussion. As it stands it seeks to ban or at least discourage what is a very common and IMO clear and helpful convention, one that is long in use far beyond Wikipedia. But this is a convention that I acknowledge is poorly documented on Wikipedia and often ignored here, leading to some very messy talk pages. Andrewa (talk) 17:30, 16 August 2017 (UTC)

Anchors (Version 3?)

@Andrewa, DIYeditor, NewsAndEventsGuy, Tvx1, Redrose64, and Johnuniq: In replying to or commenting on points in preceding comments, I have occasionally inserted anchors in those comments and linked to them. This way there is no need to quote in full the point I am responding to. More than that, when the discussion is already long and complex, with many replies-to-replies-to-replies-..., a reader can find the point being replied to without a potentially long and distracting search: for example, aXXXX this reference to Andrewa's comment about the "dreadful mess" that can result from mixing asterisk and colon listing. And unlike interleaving, anchors do not affect the display at all, but are visible only in edit mode.

I guess I'm making a proposal for a better (imho) way of replying to specific comments without interleaving or necessarily quoting, so I'm adding "Version 3" to my section header. I'm not ready to turn this into a guideline proposal, so I invite you all to please have a go at it (thus the question mark).

Please {{Ping}} me to discuss. --Thnidu (talk) 18:23, 27 August 2017 (UTC)

Thnidu, I have never used anchors in that way but can't see any reason not to. I instead use a diff to refer to the comment to which I am replying, but generally quote the relevant text in italics as well.

There are many acceptable ways of structuring a discussion.

I have been involved in Internet discussions since before public ISPs were available in Australia (we used permanent dialups to form APANA that's redlink and shouldn't be, see http://www.apana.org.au/ I see it still exists, and before that there was FidoNet which also still exists of course), and was frankly astounded that the interleaving that provoked this discussion caused anyone any stress or confusion at all. My belief was (and is) that this convention is still the most common and easily followed method of structuring a complex discussion on the Internet generally. Many if not most email clients provide it automatically.

But some do have problems with it obviously. So the questions are (1) is there a better way and (2) can and should our guidelines be improved (one way or the other depending on the answer to (1)).

I have had experience before with people objecting to this convention, but previously it has always been in the context of the low-level disruption I call ranting... for example, some users will punctuate a long post with p HTML tags or with no paragraph breaks at all. Either tactic prevents interleaving, and in my opinion should be discouraged for exactly that reason. Andrewa (talk) 22:48, 27 August 2017 (UTC)

You would not be astounded that many editors find interleaving to be disruptive if you had observed discussions where they were common, and where it was necessary to refute the interleaved comments. If people cannot make their point in a digestible manner they should not comment. A comment has to be made in a way that replies to the comment could reasonably occur. Further, discussions are not just for the benefit of the current participants; future editors may need to review old discussions to see why certain conclusions were reached. Johnuniq (talk) 23:06, 27 August 2017 (UTC)

Strongly agree with most of this.

The attempt to personalise this discussion (read the link, and discuss the contribution not the contributor please) is just plain ridiculous, as you would know had you bothered to do any check of my edit history. Enough of that please.

And I'm afraid I remain astounded. Refutation of the interleaved comments is exactly what the convention makes easy and transparent, and easy for others to follow later. Of course there comes a point where indentation is excessive, but for the first two or three indents it works very well. If it goes beyond that, probably best to start a new subsection, IMO... or outdent sometimes works well, sometimes not.

But for the rest, good points all, and I think they support the proper use of interleaved comments in Wikipedia, for the same reasons as it is standard practice elsewhere. Andrewa (talk) 23:29, 28 August 2017 (UTC)

@Andrewa and Johnuniq: How do you even find relevant comments in a long and heavily interleaved discussion? Especially if they're not “addressed” with {{ping}} (or one of its numerous aliases), or with simple linked mention as in {{u|Susannah Q. User}}.

In a long discussion, it is hard work to follow the threads at the best of times, and from time to time users even use this to advantage. But is there any doubt what I'm replying to here? Does it make the above post look unsigned, or this one? I don't think so. But then I'm an old hand at this, since long before Wikipedia.

So I propose to add a brief description of this anchoring method, explicitly stating that this is not a guideline but an available alternative to interleaving. If there are no strong objections I will do so. Please {{Ping}} me to discuss. --Thnidu (talk) 18:30, 30 August 2017 (UTC)

I have no objection at all, provided it is not claimed that this is a preferred method. But I still have doubts that interleaving should be in any way discouraged. See this two-part reply as an example of a case in which I think it works well. How would you make the logic clearer? Is it necessary to do so?

But we do I think need to update the guidelines to give some help to new hands who have not seen it done previously. In particular, it's not standard practice on mobile devices AFAIK. There may even be an argument to discourage it for the benefit of mobile users, I'm not one so I would not know.

On conventional web browsers it works well IMO, if properly done. Here we're now five levels deep (perhaps we should recommend a limit to the depth of indenting), so pushing the limits, but it still works well on my browser.

Thnidu, pinging as requested. But I'm surprised that is necessary... do you use watchlist and contributions? Andrewa (talk) 22:15, 30 August 2017 (UTC)

Sorry, Andrewa. Yes, I do use them. The trouble is that on some pages that have many unrelated discussions going simultaneously, like the Teahouse, I get too many notifications about edits on topics I'm not interested in. This page is not such, but the habit stuck with me. Also, as I believe I mentioned above, navigating such a long discussion as this on a smartphone creates other difficulties. --Thnidu (talk) 23:02, 30 August 2017 (UTC)

Making the articles available to mobile users is definitely a good thing. I am yet to be convinced that mobile editing of articles or discussions is a good thing overall. It has obvious advantages but there seem to be some drawbacks to it. Andrewa (talk) 02:47, 31 August 2017 (UTC)

@Andrewa: Edits like this are precisely the problem we are trying to avoid. Without knowledge of that specific edit diff, can anybody tell from the above thread that the paragraph beginning "In a long discussion, it is hard work to follow the threads at the best of times" was not written by Thnidu (talk · contribs)? It's misattribution, plain and simple. --Redrose64 🌹 (talk) 08:25, 31 August 2017 (UTC)

This is a bad, BAD idea

Many users find this practice highly offensive, and it makes discussions very confusing to follow. We should not be encouraging it in any way. Drive a stake through this. EEng 22:37, 30 August 2017 (UTC)

If it's true that Many users find this practice highly offensive, then I'd have to agree it should be banned. End of story.

But I must ask why is it so offensive? And why is it confusing? Was anyone confused or offended by my two-part post above? Why and how?

Walls of text are one of the key techniques of rantstyle. The ability to reply concisely and clearly to a long post is vital in order to get ranting discussions back on track, and work towards consensus.

If people find this offensive, I think perhaps they're in the wrong place. In a sense even your signed contributions don't belong to you here at Wikipedia. All text is available for reuse and refactoring. There are restrictions, of course, and we should not for example misrepresent others, or deny them their chance of a fair hearing, and the guidelines seek to ensure this. But interleaving, properly done, does neither of those things.

To the contrary, it allows arguments to be easily, clearly and concisely answered. And this is not always welcome! Andrewa (talk) 00:45, 31 August 2017 (UTC)

All text is available for reuse and refactoring – Reuse, yes. "Refactoring" that in any way even slightly tampers with the context, import, or connotation of an editor's post, no, and that includes interlarding your own comments in a way that neuters the original thrust. Quote a bit of what someone said, and respond to it – as I did in this very post. More than one person may want to respond to the same post, and if they all try to interleave it becomes a complete mess. EEng 00:56, 31 August 2017 (UTC)

Agree with all of the first two sentences except the unstated implication that interleaving properly done even slightly tampers with the context, import, or connotation of an editor's post or that it neuters the original thrust.

And if a second editor inserted a comment here, it would not affect the flow or logic of my post in the slightest. Andrewa (talk) 02:26, 31 August 2017 (UTC)

It does neither. Did my example above do either? It doesn't seem to have to me. Do you have examples that have? Andrewa (talk) 02:26, 31 August 2017 (UTC)

I'll tell you why I hate it. It derives from an email/usenet practice, where correspondents inserted their comments directly into the comments of the person they responded to. In that context, it works fine, for two reasons.

First, in the email/usenet context, each response was a separate document, an email message itself. It wasn't a single document being iteratively edited, with the end result being an intermingled mass of commentary by multiple editors, where finding each editor's comments and viewpoints is much more difficult.

Second, in email/usenet, one almost always trimmed away the parts not being responded to. It was a matter both of courtesy and to keep the note from becoming ungainlily long. In contrast, on Wikipedia talk pages, we obviously don't want other editors' comments trimmed by the act of responding; again, because it's a single document, not a series of individual documents.

What worked very well for email and usenet works very badly in an interatively edited document like a Wikipedia talk page. It causes attributions to be masked or difficult to figure out.

You say "it allows arguments to be easily, clearly and concisely answered", but I don't think that's the case. Easily and concisely, sure; but clarity is a casualty of the practice. I love it in email (top-posting is the bane of modern email communication) but hate it for talk pages. TJRC (talk) 00:59, 31 August 2017 (UTC)

It seems to be a matter of taste to me. I have no problem following properly inserted comments; I find it easy to follow the logic (or lack of same) in arguments presented in this way. Again, have you any examples where clarity has suffered? Do you think that the example I gave above, or the original one that started this whole string, are unclear?

I'd like to respond to the detailed points you make, some of which I agree with, but others are I think at least questionable. But without doing what you hate I think it would be unworkable, so I'll just leave it at that. Andrewa (talk) 02:26, 31 August 2017 (UTC)

Template:Reflist-talk

I was going to boldly add a paragraph to the page, but because of the warning at the top—

You are editing a page that documents an English Wikipedia guideline. While you may be bold in making minor changes to this page, consider discussing any substantive changes first on the page's talk page.

— I'm posting it here first for discussion:

References on talk pages

If your comment includes references that will create footnotes, use Template:Reflist-talk at the end of your comment section. This will force your references to appear in a box at the end of the section, rather than at the foot of the page as they would in an article. Like this:

References

Comments, please! {{Ping}} me.--Thnidu (talk) 18:57, 27 August 2017 (UTC)

• Honestly, this page is complicated enough as it is. Refs on talk pages are fairly rare (usually they're there by accident – copied in with some other text, and of no importance at all) and it's not the end of the world if they get rendered at the end of the page. Some other more experienced editor might come along and add {talkref}, or not, and either way it's not a big deal. I'd skip it, and let it be something people learn by example. EEng 19:09, 27 August 2017 (UTC)
• @Thnidu: I agree with the proposal. I see this about once a month and while not necessary, I'd like to see the practice formalized. Chris Troutman (talk) 21:26, 27 August 2017 (UTC)
• EEng (Ye gods, I just wasted at least half an hour in your "museums". Fun but dangerous!) Um... As I was saying... Yes, I still think it's a good idea. It can save a lot of scrolling (→ time → spoons), and make it a lot easier to compare the references with the text. I'mma put it in. --Thnidu (talk) 21:53, 27 August 2017 (UTC)

  I'm not saying it's not useful to have it where it applies. I'm saying that I wonder if it's worth adding to the crushing weight of detail on this page, which is one of the first we recommend newbies absorb. Anyone can come behind an initial post and add {reftalk} when they recognize that it would help so I'm saying let a more experienced comes-along-later editor do it -- no harm done by the delay -- instead of adding one more thing a newbie thinks he has to try to remember. EEng 22:02, 27 August 2017 (UTC)

  EEng is correct. It would be nice if every editor could be given a pill that allowed them to manage talk pages, but that's not going to happen, and they certainly will not read this guideline before dumping refs in their comments. Learn-by-example is best for {{reflist-talk}} and the guideline should focus on basics which are much more important. Too much detail makes it impossible to see essentials. Johnuniq (talk) 22:59, 27 August 2017 (UTC)

  You know, I think there's a place for an essay WP:LEARNBYEXAMPLE on erring on the side of relying on learn-by-example instead of stuffing every detail into long intro pages no one can possibly read. The Help: space is a trainwreck because its builders (who, I gather, simply dropped dead of exhaustion one day) couldn't decide whether to make it a set of for-dummies quick-start pages, or a full regurgitation of every consideration and feature, drawn out with numbing examples for each and every point. Favorite examples: WP:How_to_make_dashes, Help:Footnotes, and (my all-time favorite) WP:Picture tutorial. That word tutorial in there was someone's idea of a joke. (Wikipedia:Extended_image_syntax is even more indigestible, but at least it doesn't advertise itself as a tutorial or help page.) EEng 23:23, 27 August 2017 (UTC) P.S. Sorry, I momentarily blocked on the absolutely, positively, worst help page every: Help:Table.

  @EEng: I just saw that you'd deleted my paragraph from the page. I wish you had at least mentioned that action in this discussion. --Thnidu (talk) 18:55, 30 August 2017 (UTC)

I would have if there was anything that needed saying beyond what's in my edit summary. You're expected to keep pages you care about on your watchlist. EEng 20:04, 30 August 2017 (UTC)

• I wonder if there might be a technical solution to this. It is an annoyance, especially when trying to manually archive, collapse or remove something, and you can't find where those refs at the bottom belong. On a crowded talk page in need of archiving, it can be quite difficult to find which section to stick the template in after the fact, so it would be nice if it could be either automatically generated in the first place or added by bot soon after. Beyond the scope of this talk page, I guess, but I thought I'd see if anyone thinks it's feasible before finding a place to request it. Rivertorch^FIRE_WATER 05:19, 28 August 2017 (UTC)

  I see no hope of some automated solution. But I really feel this is a search for a solution which, when found, will then be in search of a problem. Sure, it's cleaner if each talk thread ends with its own refs, but if they refs end up at the bottom of the page, so what? They're still there, and when a thread is archived the refs move properly with the thread itself to the archive page, appearing at the bottom there. Sometimes the refs are in the thread accidentally anyway e.g. got copied in as part of some text under discussion, and no one cares where they appear or indeed realizes they're even there. If it really matters that the refs be in the thread proper, someone will have the sense to add {talkref}. Otherwise, no big deal. EEng 05:29, 28 August 2017 (UTC)

  @Rivertorch: It's very easy to work out which sections to add the {{reflist-talk}} to. Assuming that you are starting with all the refs displayed automatically at the bottom of the page:

  1. Have a look at the first of those refs; it will have one or more backlinks close to the start of the line (if there is one backlink, it will be a caret "^"; if there are two or more, they will be lowercase letters).
  2. Click the first of those backlinks, this will take you to some point further up the page, almost certainly in one section or another.
  3. Edit that section, add {{reflist-talk}} to the bottom, and save.
  4. Return to the bottom of the page, check to see if there are any remaining automatically-displayed refs; if there are, return to step 1.

  and you're done. --Redrose64 🌹 (talk) 11:25, 28 August 2017 (UTC)

Yeah, that's quick and simple! Another approach would be to just not worry about on exactly what part of the page the refs display. EEng 12:02, 28 August 2017 (UTC)

Thanks, Redrose64. That's more or less what I already do, and it almost always works, but a while back I encountered a talk page where all bets seemed to be off. I don't remember exactly what I eventually found the problem was (hatted sections? an improperly closed tag, maybe?), but it just stuck in my mind and when I saw this thread it occurred to me that it might be feasible to address the problem through automated means. @EEng, I appreciate that you consider it no big deal. I certainly don't think it's a big problem, but I also think it's often worthwhile to at least consider addressing minor issues that make the interface more confusing than it needs to be, especially for new users. I'm no perfectionist, but I also dislike the "good enough" approach when something might be easily improved. Rivertorch^FIRE_WATER 18:11, 28 August 2017 (UTC)

I agree about considering, and that's what we're doing now, but to me the answer is that it's not an improvement to add these instructions to this page. A big problem in editor retention is the learning curve, and by adding this we've made that curve a little steeper in order to get a slight cosmetic adjustment to 1 in 1000 talk pages – maybe (i.e. if this new instruction is remembered and heeded by newbies). And in many cases someone else will make the slight adjustment anyway. EEng 18:27, 28 August 2017 (UTC)

(At ten levels of indentation the text is virtually unreadable on a smartphone.)

@Chris troutman, Johnuniq, Redrose64, Rivertorch, and EEng:
Clearly I left out a crucial point in my proposal: Using {{Reflist-talk}} on one's own comment requires making sure that all previous comments with references have it as well. And that does complicate it, so it would be important to note that this is an option that you can use, but you don't have to.--Thnidu (talk) 19:28, 30 August 2017 (UTC)

Great – yet more complication to an instruction that solves a tiny use case in the first place. Until five years ago {reflist-talk} didn't even exist, and we got along fine. It was invented for a the very few times where, for some special reason, it really clarified things to emit the refs accumulated to a certain point (usually how-to pages, MOS pages, etc., on which the mechanics of refs are being themselves explained). You mean well, but this whole thing is a bad use of novice editors' very limited ability to absorb our already complicated rules and guidelines. I suggest we remove it completely. EEng 20:04, 30 August 2017 (UTC)

Honest question: would you say this guideline should be primarily for newbs? Rivertorch^FIRE_WATER 23:27, 30 August 2017 (UTC)

First and foremost it's a reference for OK and not-OK behavior, for when arguments flair up. To the extent possible, it should present that in a way calculated to allow newbies to absorb it readily. That's a hard balance to strike, and way down on the list is technically complicated oh-and-in-this-rare-case-also-do-this minutiae. I'll say it again – leave this for learn-by-example. EEng 00:12, 31 August 2017 (UTC)