Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by ChrisGualtieri (talk | contribs) at 06:24, 28 December 2013 (→‎Orphan tag alternate idea: re). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


« Archives, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213

Proposal to move the Orphan tags to the talk page

There is consensus to move orphan tags to the talk page, including with a bot. There were various proposals to create some type of new class of "minor maintenance templates," but they did not gain widespread support. Ramaksoud2000 (Talk to me) 20:41, 19 December 2013 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Reposted from Wikipedia talk:WikiProject Orphanage for wider visibility

Hi. I'll make this short and quick. I'm still struggling to see how useful the {{Orphan}} tag is. It's big, it's ugly, and it concerns a very very minor problem that most of the times does not really have a solution. Some articles are simply about subjects that have not been mentioned in any other Wikipedia articles. As the VERY large backlog in Wikipedia:WikiProject Orphanage makes quite clear. Forcing editors to link them or add them even in places where they are only vaguely relevant is not good practice. Neither does it concern any of the readers, but it's them who have to see the tag first thing on the page. If it was a problem on sources, I would understand, as readers should know about it. But not being linked enough is not that serious of a problem to merit defacing an article.

I propose that the tag itself be moved to the talk page to minimize its impact on the article's readability.

Note that I do not know how this can be accomplished (probably by a bot?) Neither do I really have the time to make this a formal proposal, but I'm simply fed up at seeing it all the time for otherwise perfectly fine articles. What does everyone else think?-- OBSIDIAN†SOUL 01:41, 14 November 2013 (UTC)[reply]

  • I can't imagine in what way a template that is formatted exactly the same as every other content notice and is barely two lines of text tall could possibly be construed as both "big" and "ugly". I would argue that the article page is the only place where it will do any good. If the original creator or other contributing editors had thought of incoming links that had been appropriate, they probably would have already done it. It's the drive-by reader, who searches and finds the orphan page, ostensibly after having been reading a related article, who should see that this needs to be done. Which means that the talk page is wholly insufficient to the task of the notice. VanIsaacWS Vexcontribs 02:38, 14 November 2013 (UTC)[reply]
It is formatted exactly in the same way, but not for the same problems. Not enough references, improper language, possible COI, those are templates that have the right to be noticed by the reader and should be screamed out prior to reading the article as a warning on the possibility that the content they were about to read may not be that reliable or in a bad shape.
But orphans? Really? It's not like those articles have problematic content or are completely inaccessible. Virtually all readers arrive on articles through search engines, not by clicking on a wikilink somewhere. And some articles again, simply can't be wikilinked elsewhere. What exactly is wrong with that? There's far more problems in shoehorning a distantly related article into another article simply because the tag tells you you need to link it. I've seen this happen when small out-of-the-way highly specialized articles get linked to high level articles by their creators where it isn't even mentioned and only vaguely relevant just because the tag tells them to.
As for regular readers, I highly doubt they would even know or care what it is for. And again, from the backlog (more than 120,000 of our articles have this tag, dating back from 2007 as a result of the rise of automated tools and drive-by tagging), they don't or (probably in most cases) can't fix it. They're basically going to stay there for eternity.
Give me one good reason why the reader has to know that the article they're reading is an orphan. And why they have to know it so urgently that it has to be the size of a bus with a big yellow threatening sign on it.
Because yes, it does affect readability. As an article writer, this kind of thing is extremely annoying. If not the talk page, how about something like the stub warning then? The one at the bottom of stub articles. At least those are placed after the text and is suitably small enough to not be defacing.
I am not the first person to complain about this. See Template talk:Orphan, and this has been proposed at least once before AFAIK (though there weren't enough editor input IMO) in Wikipedia:Templates for discussion/Log/2013 January 5#Template:Orphan placement discussion.-- OBSIDIAN†SOUL 03:18, 14 November 2013 (UTC)[reply]
And if you had actually read through all of those previous discussions, you would have seen numerous links to Wikipedia:Perennial proposals#Move maintenance tags to talk pages, which explains exactly why this is a bad idea. VanIsaacWS Vexcontribs 04:28, 14 November 2013 (UTC)[reply]
A compromise would be to move the tag to the bottom near the "no categories" tag. The categories and the linking are often being done at the same time when the article is first created, and this would separate it from the content problems being pointed out by the tags at the top of the page. —Anne Delong (talk) 04:36, 14 November 2013 (UTC)[reply]
I would be happy with having maintenance tags autocollapsed by default, with just a simple bar saying "Orphan article", "Article for Deletion candidate", etc, then having the standard "show" button to allow you to get the details. Obviously, it would require a far greater consensus than we can establish in this conversation, but it has the advantage of not requiring a bot run to alter 125 thousand articles, and the reprogramming of tools like AWB, and all the (dozens? hundreds?) tools and bots that do article tagging. VanIsaacWS Vexcontribs 08:52, 14 November 2013 (UTC)[reply]
Oh. This is one of the perennials? Why am I not surprised at that. That alone betrays that there really is a problem, don't you think? But yes, Anne Delong's idea is much much better in terms of what we have now. Autocollapse would be better too. Anything but that madly conspicuous "Notice me! This page has a teeny tiny problem that you need to know in the most obnoxious way possible (November, 2013)". It's just missing marquee and it could be a Vegas sign. -- OBSIDIAN†SOUL 12:46, 14 November 2013 (UTC)[reply]
While the "orphan" tag points out a minor problem, some of the other tags point out major ones, such as advertising and no references. I don't think these should be collapsed. About moving the orphan tag to the bottom: I don't think it would be important that this was absolutely consistent. Without necessarily changing all of the other bots or scripts, a new bot that ran perhaps once per week or even once per month could check for articles that had had an orphan tag placed since the last time it was run and move the tags to the bottom. If a few were missed or if some were moved by other bots it would still be an improvement. The old tags would gradually melt away as links were added, and at some point a run-once bot could catch any that were left from years ago. Just talking off the top of my head here.... —Anne Delong (talk) 14:08, 14 November 2013 (UTC)[reply]
Yes. As stated above, I actually have no problems with unreferenced, COI, POV, etc. tags. It's perfectly reasonable that the reader should know about those, as it affects the actual content of the article. Orphans however, have actually nothing to do with the content, and it's a very minor problem that in the natural evolution of articles, eventually does go away. Those which don't are highly unlikely to ever be linked ever, and the orphan tag on them becomes permanent and unreasonable.-- OBSIDIAN†SOUL 21:22, 14 November 2013 (UTC)[reply]

Votes (orphan tags)

Support. Move orphan away. No need to scream at every visitor over every little thing. Rmhermen (talk) 17:24, 14 November 2013 (UTC)[reply]
Support if de-orphaning was attempted and/or for all BLPs, businesses, and organizations (the orphans least likely to be de-orphaned in my experience). The reason that the tags "have to be" present on the page is because we're hoping that "readers" will turn into "editors" by trying to solve the problem. But if it's not (apparently) possible to solve the problem, then IMO we can safely place the tag elsewhere (or even remove it, but then some busy person might replace it later). WhatamIdoing (talk) 18:44, 14 November 2013 (UTC)[reply]
comment – there is a parameter att which editors may use to assert that they attempted to de-orphan; using this parameter makes the {{Ambox}} disappear, and populates Category:Attempted de-orphan. For example usage, see this diff. Wbm1058 (talk) 15:28, 4 December 2013 (UTC)[reply]
I also support the idea of moving them to the bottom of the page, along the lines of a stub tag. WhatamIdoing (talk) 01:15, 6 December 2013 (UTC)[reply]
Support Orphan tags have always annoyed me as being very low value and distracting. We could have a gadget for those people that want to know about it, but at least 99% of readers will not care. Whether de-orphaning is attempted or not does not matter, there is no requirement for an article to be linked from elsewhere. Graeme Bartlett (talk) 20:33, 14 November 2013 (UTC)[reply]
Support I would create a separate category or class of "minor maintenance tags" which would be treated differently, and restructure the template code to change their display, making it less obtrusive, or else use a bot to move them to the talk page. DES (talk) 21:54, 14 November 2013 (UTC)[reply]
Support per Graeme Bartlett. Kudpung กุดผึ้ง (talk) 06:24, 15 November 2013 (UTC)[reply]
  • support It might take some digging to find, but I recall making more or less this exact same proposal four or five years ago. Unlike other tags, being orphaned is not crucial information that readers should be informed of. We should treat the same way as notices for links to dab pages or broken brackets, just put it on the talk page and eventually it will be dealt with. Beeblebrox (talk) 19:57, 15 November 2013 (UTC)[reply]
Turns out it didn't take much digging after all, see here. Beeblebrox (talk) 20:01, 15 November 2013 (UTC)[reply]
Support per DES. --NeilN talk to me 21:34, 15 November 2013 (UTC)[reply]
Support per others. The reader should see maintenance tags that give us reason to be concerned about reliability (no refs, POV, etc.). But editor facing tags, such as this, should be kept in editor areas, i.e.: talk pages. Resolute 21:39, 15 November 2013 (UTC)[reply]
  • Support outright removal -- the "Orphan" template, unlike other maintenance templates like {{ref improve}} or {{COI}} (random examples), provides absolutely no new information whatsoever. While other templates provide useful information that can't be acquired elsewhere (we don't have a bot that can automatically detect conflicts of interest, for example), all that the Orphan template does is provide one datapoint that is already viewable through the Wikipedia API or Special:WhatLinksHere. Additionally: should the template be removed, it would be trivial to develop a userscript to automatically inject an Orphan notice at the top of orphaned articles upon load for those who still wished to see the notice. Theopolisme (talk) 00:19, 16 November 2013 (UTC)[reply]
Support Agree with the arguments above. Too many articles are tagged to death for no good reason and the least relevant ones like the orphan tag might do more harm than help. We already have some link related maintenance tags and announcements (such as DAB links and Commons image deletion) on the talk page. --ELEKHHT 00:24, 16 November 2013 (UTC)[reply]
Support The fewer tags we keep on the article space, the less confusing The article itself should have only the necessary templates that affect the reader's use of the article--such things as NPOV. This probably includes tags like Unreferenced, because they too serve as a warning about reliabioity). It should not include any of the purely technical matters that may need to be improved, but do not immediately affect the readers. The failure to have appropriate links--in either direction--is not optimal for most articles, but it affects directly only the editors. DGG ( talk ) 00:49, 16 November 2013 (UTC)[reply]
Support. Normally my position might even be closer to "The more tags on the article - the better!", but the orphan tag is an exception. First, it does not indicate any problem with the article itself - the fact that it is not linked from elsewhere might be a problem for the rest of Wikipedia, but not for that article. Second, one of the main reasons to have tags on the article itself do not apply here: the user who corrects the problem is not that likely to see the tag and thus this placement does not encourage him to remove it when it ceases to apply. Third, having no incoming links simply is not that much of the problem. Actually, I'd say that a list maintained by a bot would be a good replacement for this tag... Speaking of which, Russian Wikipedia has a project to find articles that are not "orphans", but can only be reached from a very limited amount of other articles (ru:Википедия:Изолированные статьи, ru:Проект:Связность). Maybe the ones who like to work with "orphaned" articles will wish to have a look..? --Martynas Patasius (talk) 02:49, 16 November 2013 (UTC)[reply]
The Russian project is actually controversial, with a number of very vocal editors pushing it to the point that the majority of editors started to tremble at eny mention of "connectivity" in any context.--Ymblanter (talk) 12:02, 16 November 2013 (UTC)[reply]
"Support".Agree with Anne Delong,Reso, ELEKHH, Martynas, Rmhermen. --Andrea edits (talk) 05:58, 16 November 2013 (UTC)[reply]
  • Support, the arguments provided are actually pretty much reasonable.--Ymblanter (talk) 12:02, 16 November 2013 (UTC)[reply]
  • Oppose as I feel that if an article is an orphan, what does it say about the notability of the topic. If this topic is not notable enough to be related to any of the other millions of topics, how "notable" can it really be. So, I oppose this being moved to the talk page on that basis. As for collapsing, I don't rightly see how that is very possible. I would venture to say that "most" of the uses of this template are inside of a {{Multiple issues}} grouping so it is already trimmed down to one line. I suppose it is possible for it to be a lone template and the article to have no other issues, but that just seems entirely improbable to me. Technical 13 (talk) 15:51, 17 November 2013 (UTC)[reply]
    • If an article's topic is suspected to be non-notable, the relevant template is {{notability}}. If one really needs to know if the article is an orphan, there is a simple technical solution: Special:Whatlinkshere. Keφr 17:05, 17 November 2013 (UTC)[reply]
      • Then there are multiple issues on the article page anyways and there is no need to have two edits to make two templates, one on the article page and one on the talk page needless bumping up edit counts. The whole point of this is to reduce work and template size. Have to make two separate edits defeats the purpose. Technical 13 (talk) 15:45, 19 November 2013 (UTC)[reply]
  • Hokay. That's some convoluted logic there. Firstly, you are (wrongly) assuming that when orphan tags exist, other problems must also exist. You do realize that {{Multiple issues}} != {{Orphan}}, right? Secondly, as already mentioned, notability is a completely separate (and a far more serious) problem. The reasons for why an article can not or does not have links to it from other articles has nothing to do with how notable a topic is. It's usually because they're highly specialized or simply because we don't have enough articles on related topics yet. Yes, as hard as it is to believe, Wikipedia is still far from being complete. Because if all orphans are non-notable, all of them should have been deleted by now. Thirdly, orphans already require you to edit multiple pages anyway. In fact, unlike the other problems that you can find in the multiple issues tag, orphans are unique in that they require you to edit other articles. Not the article which is currently an orphan. And as far as I know, de-orphanings are done by periodic bot runs.
And lastly, the whole point of this proposal is to reduce the work and template size as well, by removing one of the "issues" which doesn't belong to the other issues. An issue which is neither priority nor something the regular reader should know about. We also don't place uncategorized, stub status, the lack of pictures, low internal article assessment grading, etc. on the {{Multiple issues}} template do we? -- OBSIDIAN†SOUL 04:22, 22 November 2013 (UTC)[reply]
  • Weak support, since being orphaned is not something very urgent, and I think a reader needs not be warned about it, unlike for example being {{unreferenced}}. Keφr 17:05, 17 November 2013 (UTC)[reply]
  • Support per Graeme Bartlett & DES. →Davey2010→→Talk to me!→ 00:57, 18 November 2013 (UTC)[reply]
  • Support removing the message from the top of the article, either by putting it on the talk page or by making the template simply add the "hidden category" but not display anything (like {{coord missing}}). The reader simply does not need this information, and it detracts from the article. Most maintenance tags warn readers about possible problems with the article, to which they need to be alerted. The fact that no articles link to it is irrelevant to the reader. PamD 22:55, 18 November 2013 (UTC)[reply]
  • Support per Martynas Patasius. – Quadell (talk) 01:29, 19 November 2013 (UTC)[reply]
  • Support. It always seemed manifestly idiotic to place a tag on a page detailing problems on other pages. :) Protonk (talk) 20:20, 20 November 2013 (UTC)[reply]
  • Support I don't think readers need to be warned about this, and orphan tags encourage adding dubious links to tangentially related pages. --Cerebellum (talk) 01:53, 26 November 2013 (UTC)[reply]
  • Support, agree with Rmhermen, above. Cheers, — Cirt (talk) 18:49, 26 November 2013 (UTC)[reply]
  • Support or just delete the damn template entirely. It has long outlived its usefulness. Kaldari (talk) 00:57, 27 November 2013 (UTC)[reply]
  • Support. Indeed, would support deleting the template as it's not giving useful information nor providing a workable solution (it can be difficult to work backwards to find which articles already mention the topic). SilkTork ✔Tea time 01:54, 27 November 2013 (UTC)[reply]
  • Support removal altogether. Warning tags should only be used for problems that affect the reader. Additionally, the existing orphaned tag often leads inexperienced editors to make inappropriate inward links. I like the idea of a bot notifying the creator of an orphan article, as long as the text made plain that it wasn't necessary to insert inward links if appropriate articles don't exist. Espresso Addict (talk) 03:17, 27 November 2013 (UTC)[reply]
  • Support per nom and the tag makes users think there is something wrong with the article as they are used to seeing tags like {{unreferenced}} or {{Disputed}} when being an orphan is not worth notifying the readers and is a small issue. Ramaksoud2000 (Talk to me) 06:23, 27 November 2013 (UTC)[reply]
  • Support Contrary to WP:UNDUE and WP:RF, these grotesque banners give undue weight to an issue which is of no interest to our readers. Most of the other banner tags should be dialled down too. Notice that every page is displayed with a link to our disclaimers. This is important legal information - more important than most clean-up tags. But it is placed at the foot of every page in an inconspicuous way. By placing some clean-up tags in banners, we exaggerate their importance and diminish the importance of the disclaimers. Most clean-up tags are, in fact, quite useless as they are so vague and lacking in actionable detail that they commonly stay on pages for years without any productive result. They result in banner blindness like the boy who cried wolf. Save banners for those things that demand immediate attention and link to a discussion, like AFD. Warden (talk) 07:43, 27 November 2013 (UTC)[reply]
  • Oppose Who is most likely to have an idea of which other articles should link to the orphaned article? People who are reading it! Why should we stop inviting them to do so? I find the comments above about how we don't need to "warn" the readers about orphanness to be missing the point, as maintenance tags are as much or more to invite readers to join in editing the encyclopedia as they are to "warn" them of issues. Similarly, the claims that this information is available via Special:WhatLinksHere, gadgets, and the like don't really help readers or new editors who don't know about these features. Anomie⚔ 13:53, 27 November 2013 (UTC)[reply]
Who are the people least likely to know or care how to properly wikilink articles? The readers. If they don't know about gadgets and special pages, chances are they don't know enough to link properly either. The vast amount of unfixed orphans already makes it clear that readers don't care to fix it (virtually all of the orphans that can be fixed, get fixed by the original authors of the article, not the readers). And even if they did, readers most likely won't have the experience to know when and how to link articles together, resulting in links being added to other articles of dubious relevance. Their only motivation after all, is that if they did that, they might be able to get rid of the ugly banner and read the article in peace. Maintenance tags are also invitations, yes, but invitations for pressing issues that need to be fixed ASAP. Being an orphan isn't a fatal error, neither is it something that requires immediate attention as again, most of them are fixed naturally as more articles are added to Wikipedia which link to them. We have other minor issues too that aren't included with the pre-lead maintenance tags precisely for this reason. -- OBSIDIAN†SOUL 15:01, 27 November 2013 (UTC)[reply]
Because it's not an invitation. It's either noise to be ignored by the reader or a vague hint that something is amiss about the article. I recommend watching new editors read pages with warning templates on them. Or asking them about the experience. From my interactions, tags are plentiful enough on wikipedia that they just mentally sort anything in those boxes as 'oh these are problems'. We only consider them 'invitations' because we (as wikipedians) are collectively insane. I mean that in the most loving way possible. There's no research indicating readers are converted to editors at a higher rate due to the tags or that they read articles more critically because of them (AFAIK). I support tags on pages where there is a problem on the page which someone can fix or where there is content on the page which may not need to be removed but we may not want to present as 'whole'. Otherwise what's the point? Protonk (talk) 19:35, 27 November 2013 (UTC)[reply]
  • Support. I prefer the idea of a small comment at an article's end such as the placement of a stub tag. This would categorise the article without yelling "fire". Fylbecatulous talk 18:22, 27 November 2013 (UTC)[reply]
  • Support moving to talk page or removing altogether, it's just not that big an issue.  Sandstein  20:32, 28 November 2013 (UTC)[reply]
  • Support per Resolute. An unnecessary disturbance for the reader. I have been directed to a couple of old orphaned articles via SuggestionBot; many of these orphans have been former deputy members of the Parliament of Norway and there is often no articles to naturally insert them in, so I simply removed the tag. But at the talk page, the tag won't bother any. Regards, Iselilja (talk) 21:15, 28 November 2013 (UTC)[reply]
  • Support making orphan tags less in your face either by moving them or hiding them. Eric Corbett 21:31, 28 November 2013 (UTC)[reply]
  • Oppose the move to talk page, Support hiding it away someway. From many years of doing maintenance backlog and tracking some of the progress, very little maintenance happens by drive by editors. Almost all happens by project or individual drives to clean out a cleanup cat. Whatever we do, the category must remain on the page, so that tools like the svick tool pick them up and catscan can be used to sort them. Moving the tag to the talk page just adds an unnecessary complexity to the sorting tasks - and will be a big task to do, compared to simply changing the contents of the {{orphan}} template. A bot run based on the current guideline of 0 links, rather than the old guideline of <3 links would be useful to work out how many of the 121,000 are really still orphans by the current rule. The-Pope (talk) 07:36, 30 November 2013 (UTC)[reply]
  • Support per Resolute. Lova Falk talk 09:50, 30 November 2013 (UTC)[reply]
  • Strong Support from two perspectives. Firstly, if we are going to throw a big flashy tag in front of our readership, we want it to inform them of a serious problem with the article that they might not have otherwise picked up on (coi for the author, non-notable subject, etc.) Secondly, Imagine you are a new user. You have just written a shiny new article, only to have a heartless robot come along and slap ugly tags on the front of it. Some of these tags are a net benefit, but others, especially orphan tags and similar, simply discourage the new user for minimal benefit. Tazerdadog (talk) 17:36, 2 December 2013 (UTC)[reply]
  • Support It's a silly tag, as there is no policy that requires articles to have links to them. Strangely, the tag isn't even about fixing the article that is tagged, but about working on other articles to add links. For those interested in such minutiae, the talk page is a good place. Note: there are obscure plant articles that simply won't have an incoming link, yet the plant/subject is clearly notable enough for an article. Now I won't have to just remove the tags without fixing the 'problem.' First Light (talk) 05:23, 3 December 2013 (UTC)[reply]
  • Support I believe the orphan tag has value and purpose but does not need to clutter up the main article page at the. I prefer a stub like message at the bottom on the main article but a talk page template is fine too. Gizza (t)(c) 00:41, 4 December 2013 (UTC) Gizza (t)(c) 00:38, 4 December 2013 (UTC)[reply]
  • Support. Babakathy (talk) 10:59, 4 December 2013 (UTC)[reply]
  • Support Oh god yes. I have been hoping this would eventually happen. -DJSasso (talk) 14:23, 4 December 2013 (UTC)[reply]
  • Support moving the tag to the bottom area where {{Uncategorized}} is placed and also support auto-collapsing, although the latter may require a meta-template enhancement (a bot should be able to just move it). Oppose moving it to the talk page. Category:Orphaned articles should be populated with articles, not talk pages. Talk pages are appropriate for matters where there is actually something to discuss, such as requested moves. Discussion about which articles should be linked to the orphan isn't likely, it's just up to someone to just do it. I would also support creating a new, more subtle meta-template for this purpose, similar to the {{asbox}} (article stub box) meta-template., which may mean a new Wikipedia message box template category. – Wbm1058 (talk) 18:55, 4 December 2013 (UTC) Amending my position to say that I can even support User:PamD's proposal to effectively collapse the message box out of existence entirely, as preferable to the existing banner, though that's not my preferred solution. I often do link to orphans and remove the tag when I see it... usually it's easy to find one or two good articles to link. Maybe even a small note at the bottom? This article is an orphan. I don't patrol for these. Though if it was eliminated entirely we wouldn't even need a bot to move the tags. Wbm1058 (talk) 23:48, 4 December 2013 (UTC)Oppose simply adding the "hidden category" and not displaying anything. At a minimum, a link to #The Find link tool should be retained, for the convenience of overworked editors. Wbm1058 (talk) 16:04, 9 December 2013 (UTC)[reply]
  • Support My initial reaction was opposition, thinking that tags being ugly is a feature, not a bug, but after thinking about it a bit, I feel that way about tags aimed at readers, rather than editors. I started to write out my support position, but then read over some of the comments and see that User:PamD mirrored my thoughts, so I'll support with "What PamD said".--S Philbrick(Talk) 22:47, 4 December 2013 (UTC)[reply]
  • Support moving it to the talk page (maintenance is the function of talk pages), second preference is oblivion (deletion). My position on maintaince tags (which are solely editor to editor communications -- and so excludes tags such as {{unreferenced}}} which also convey useful information to readers -- is well known (see for example Template talk:Orphan and Wikipedia talk:Perennial proposals#Move maintenance tags to talk pages and the whole argument on Wikipedia:Perennial proposals#Move maintenance tags to talk pages is bogus as there has never been consensus (until now) on this issue. One point about placing maintenance tags on the talk page that I think needs emphasising is that they can then be automated with a bot. If a bot places tags in article space editors may well remove the tag and complain to the bot pilot. But similar tags place on a talk page are unlikely to annoy other editors so much. That means an accurate category of such pages can then be automatically maintained by a bot through the tags on the talk pages, for those WikiGnomes who like to fix such things. Those doing the fixing can then decide among themselves what is an appropriate level to the number of links to without those who think the template is unnecessary in article space trying to have it put as low as possible. -- PBS (talk) 14:45, 5 December 2013 (UTC)[reply]
  • Support - the tags should either be removed from the articles (putting them on the talk page would work) or be invisible. The average reader of these articles would be more likely to botch the job than do it correctly, and the problem is relatively minor (unlike, for example, the {{hoax}} tag or even the {{coi}} tag, which suggest the article's reliability level is below what can be accepted here). עוד מישהו Od Mishehu 16:37, 5 December 2013 (UTC)[reply]
  • Conditional Support. But only moved to the bottom of the page and/or hidden. Oppose any move to talk pages—which only makes it harder on those who target these for editing. GenQuest "Talk to Me" 18:36, 5 December 2013 (UTC)[reply]
  • Support Move to talk page since it's a minor and harmless issue with the page. Acalycine talk 08:13, 6 December 2013 (UTC)[reply]
  • Support - it's high time this was done. The tag at the top of the article is a disproportionate distraction to the actual importance of the tag. Much better to place it on the talk page. Jusdafax 01:01, 7 December 2013 (UTC)[reply]
  • Support for reasons offered above. SnowFire (talk) 19:03, 7 December 2013 (UTC)[reply]
  • Oppose per Anomie. If you don't like seeing maintenance templates, improve the article! Chris Troutman (talk) 01:36, 8 December 2013 (UTC)[reply]
    That is of course a ridiculous position, as any "improvements" have to be to other articles, not the one that's being tagged. Eric Corbett 03:02, 8 December 2013 (UTC)[reply]
  • Support being moved to the talk page (or removed completely). The less we advertise our articles' minor problems to our readers, the better. iMatthew / talk 04:03, 8 December 2013 (UTC)[reply]
  • Support per PamD and SPhilbrick ("either by putting it on the talk page or by making the template simply add the "hidden category"") –Quiddity (talk) 23:24, 8 December 2013 (UTC)[reply]
  • Support. About time. This has been discussed in the past, it's a constant headache. As per above, uglification and alienation of the article is not worth any small benefit. Save the big honkin' tags for serious problems. Herostratus (talk) 08:55, 9 December 2013 (UTC)[reply]
  • Yes, probably. I had forgotten about that one. It's hard to keep track of all that stuff. I guess it could be a compromise. I guess my desired outcome in order of preference would be 1) move it to the talk page, 2) move it to the bottom of articles, 3) recast it as smaller box. Herostratus (talk) 17:21, 9 December 2013 (UTC)[reply]
  • I agree with getting rid of the template, but I'm not sure that the talkpage is the right place. My preference would be to replace the template with a hidden category, ideally one that was autogenerated by the system. That would work for the people looking for orphans to de-orphan, and would also work for our readers. No-one minds the odd maintenance category. ϢereSpielChequers 22:54, 10 December 2013 (UTC)[reply]
  • Support per majority of above comments. --LT910001 (talk) 03:53, 11 December 2013 (UTC)[reply]
  • Support and call for snow close. Gives undue weight to an issue which is of interest to editors but not to our readers. In my humble opinion, anyone who wishes to really understand this should look at the following two pages:
User:Greg L/Sewer cover in front of Greg L’s house
User:Guy Macon/On the Diameter of the Sewer cover in front of Greg L’s house
I hope this helps... --Guy Macon (talk) 01:18, 13 December 2013 (UTC)[reply]
Oppose - The orphan tag doesn't necessarily indicate a problem with the page itself, just that someone should find other articles it is relevant to and link to it. A Wikipedia page that isn't linked from any other article is almost useless; it is practically unreachable. If an article has not been created until now, and it is an orphan, and no one can find any other highly relevant article to link to it from, it gives a very strong (and very useful) signal that the new page may not be notable. This is useful for cleaning out new articles that are not meant to be on Wikipedia. I may have agreed with this if it was the year 2005 or something, but in 2013, the Orphan tag is very useful and very telling. Ithinkicahn (talk) 05:45, 25 December 2013 (UTC)[reply]

Possible implementation

And there are many scripts that will do this too such as in page patrol and AFC. So we should arrange that these do not add the template. (As a temporary remediation the template could be invisible on the page). Graeme Bartlett (talk) 20:31, 16 November 2013 (UTC)[reply]
I seldom delve into the deeper aspects of maintenance in Wikipedia. So if any of you know how to attract a larger number of editors to !vote on this so we can get a consensus please do so. Same with how this could be implemented if it passes.-- OBSIDIAN†SOUL 21:38, 16 November 2013 (UTC)[reply]
I've added a Wikipedia:Requests for comment tag. Theopolisme (talk) 18:06, 17 November 2013 (UTC)[reply]
Thanks.-- OBSIDIAN†SOUL 01:33, 19 November 2013 (UTC)[reply]
  • Comment - It's important that editors be encouraged to link articles to each other. If the orphan notification is not to be at the top of the article, it could be (1) a tag at the bottom of the article near the "category improvement" tag, (2) a category of its own, (3) a tag on the talk page, or (4) not displayed at all, but kept track of in a hidden way, or (5) ignored totally. I prefer option 1, because fixing up categories and linking pages are often done together when pages are new, but there may be advantages to other ways. One good thing about a visible tag is that it's easy to find all of the orphan pages by using the "What links here" search. Another possibility would be to have two tags, one for new articles which no one had tried to link, and a second less conspicuous one for articles that really were (at the time) unique topics. —Anne Delong (talk) 21:45, 16 November 2013 (UTC)[reply]

(edit conflict) If this should gain consensus there are several methods that could be used to implement it:

  • Modify the existing template so that it displays differently, in a page-bottom position and with a less obtrusive style;
  • Create an alternate template for talk page use instead;
  • Notify script maintainers and ask them to use the alternate temple from now on
    • Alternatively, modify the template further so it appears differently on talk pages than it does on article pages;
  • request a bot or bot-task to move existing uses to talk pages, or request bot-authorization to use AWB for this purpose, once a talk-page-appropriate version of the template has been created.

Together, those should implement a decision (assuming one is made) to change this. DES (talk) 21:52, 16 November 2013 (UTC) @Anne Delong, yes it is important, but it is IMO questionable how much the visible tag encourages meaningful linking. As to your options, note that a tag can also put an article in a category, as can a hidden tag, and that even a hidden tag can be traced via what-links-here. DES (talk) 21:57, 16 November 2013 (UTC)[reply]

Thanks for these. I have no preferences on where it could be alternatively placed really. Just that I believe that the {{Orphan}} tag does not belong to the "reader-needs-to-know" tags that appear before the lead. These can probably be discussed in greater detail when enough editors have commented for consensus. Best with input from WikiProject Orphanage members as well(if the WikiProject is still active), as it is them who work on them, after all.-- OBSIDIAN†SOUL 01:33, 19 November 2013 (UTC)[reply]
  • Comment: I'd suggest that the template should be amended so that it does not display anything to the reader but continues to add the hidden category Category:Orphaned articles from December 2013 etc, in the same way that {{coord missing}} does. Then any editor looking for orphans to fix can do so, and can then remove the template when it's fixed. Anyone else can ignore it. (Though as there are 121k orphaned articles in the system at present, I wonder how much point there is in even doing that?) PamD 23:02, 4 December 2013 (UTC)[reply]

The problem with hiding them in article space is that the hidden categories they link to tend the to become the preserve of WikiGnomes. I think that if these maintenance tags were moved to the talk page and displayed at the top of the talk page as maintenance that needs to be done then other editors are more likely to get involved (I know I would be). I think that deletion is not a good solution because even it it is acceptable for this particular template, there are other maintenance templates that may be more important but ought not to be visible in article space. Moving this one to the talk page could be test and a forerunner to iron out the bugs before others are moved to the talk page. Particularly if the placing and deletion of the template on a talk page can handed over to a bot (same goes for {{Uncategorized}} and probably may more maintenance templates where the decision is a simply binary one involving no human judgement) -- PBS (talk) 15:16, 5 December 2013 (UTC)[reply]

Realistically it's just WikiGnomes that will work on these articles, which are mostly just cruft as Guy Macon alludes to in his comment above. They find these cruft-works because they were tagged for some violation(s), often by the new page patrol. If the gnome is orphan-focused, they need no on-page notice because they find it in Category:Orphaned articles. If talk pages are categorized, then that just slows down the gnome because their next step will be to click on the article tab, then click what links here to verify. Then they need to read the article for clues on what to link to it. Often the only thing on the talk page will be a WikiProject tag, so the talk page is usually useless. I usually find these when I'm on patrol for some other problem. I just fix what I see, and usually don't bother to look at the talk page, or check what links here. So if there's not at least some small message, I'll probably just miss it. Wbm1058 (talk) 18:19, 5 December 2013 (UTC)[reply]

@Wbm1058 with regards to your edit in the next section that starts "We can only guess on how many read... I think improvements to the message box text emphasizing that there is a nice tool to help may be more important than where on the screen the message is placed..." I think that what you are proposing is clearly against the consensus that has emerged for this specific template. The consensus is to do away with it. The only area where there is not consensus is whether to delete it completely, move it the talk page or make it into an invisible template on the article page (probably in that order of preference). -- PBS (talk) 11:19, 11 December 2013 (UTC)[reply]

Self-references to avoid

There are a number of other similar maintenance templates which I think are similar enough to {{Orphan}} to be included in this discussion. Take for example {{Underlinked}} which was created at 07:01, 29 September 2012‎ with next to no support for its creation.

One major problem is anyone can create a new maintenance/clean template for use in article space with no support or very little from other editors. Once created they are difficult to delete because the person who has created it will usually tenaciously defend their baby arguing that there is no consensus to delete it. There are quite a few of these templates listed in Wikipedia:Template messages/Cleanup.

I think the first place to start is to beef up the wording in Wikipedia:Manual of Style/Self-references to avoid. See a proposal I suggested about a year ago here which stalled because of lack of interest at that time. -- PBS (talk) 23:25, 8 December 2013 (UTC)[reply]

It's not quite true that {{Underlinked}} just 'came out of nowhere' with minimal support. {{Internal links}} was an earlier version of this tag, and {{Wikify}} was often used for this purpose, but was deprecated because the term Wikify is too vague. Wbm1058 (talk) 01:01, 9 December 2013 (UTC)[reply]
There was also awhile before {{Underlinked}} where {{dead end}} meant the article had zero, one, two, or three links. GoingBatty (talk) 01:04, 9 December 2013 (UTC)[reply]
Whether there had or had bot been other previous templates, there is no evidence of a discussion which involved more than a few of editors over the desirability of creating a new template called {{Underlinked}}. Besides instructions like "Wikify", "undelinked", and "dead end", are all things that ought to be on the talk page not in article space. Then if someone really does not understand what "Wikify" means it can be explained to them in Janet and John terms. If a editor were to write at the top of an article in indented italic text "I think this article in underlinked" they would be told that such comments belong on the talk page not in article space. Placing it in a box does not change the essence of the message or where it should reside. Placing text into an article that starts "this list is incomplete" would not be deleted because it is a useful warning to readers whether or not a reader becomes an editor by helping by expanding it. -- PBS (talk) 08:34, 9 December 2013 (UTC)[reply]
Wikipedia:WikiProject Wikify is an established and fairly active project and it should be clear from the project page and the project's logo that adding internal links is a core function, if not the core function of the project. So, whether or not there was extensive discussion, there is widespread de facto support for that template, or some naming variant of it.
An editor writing "I think this article in underlinked" at the top of an article in indented italic text is probably more likely to find their edit converted into an {{Underlinked}} template than flat-out reverted or moved to the talk page.
But there is evidence of discussions of your core proposal. See Wikipedia:Perennial proposals#Move maintenance tags to talk pages. Wbm1058 (talk) 12:48, 9 December 2013 (UTC)[reply]
Adding internal links may or may not be a core function (see the fuss over over-linking particularly dates), but that is beside the point of whether such templates as {{Underlinked}} should be placed in article space. Back in 2007 I wrote about how editors can and often do view pages differently from readers. They can forget that most people come to a page to read about the subject not about how the presentation of the subject matter can be improved. Articles should be about the subject, talk pages should be used for how editors can improve the article (if not why not why bother with talk pages and instead just append the talk page chatter at the end of the page as is done on many blog sites?). -- PBS (talk) 15:05, 9 December 2013 (UTC)[reply]
It's thoroughly maddening to me that you laid out what should've been a sufficient case to remove/move these templates 6 years ago and got the (no offense to whichever editor replied to you) standard data-free, 'truthy' response which totally ignored your reasoning in the first place. We've been slapping templates on pages since the inception of the project, telling ourselves (despite a near total lack of evidence in support) a pretty comforting fable. Protonk (talk) 23:41, 9 December 2013 (UTC)[reply]
The section in Perennial proposals is worded in a misleading way. It implies that there is a consensus to reject the proposal, when in fact there never has been any such consensus (See the Perennial proposals talk page for more details). I think that this RfC tips the balance further towards discouraging their use in article space. -- PBS (talk) 14:49, 9 December 2013 (UTC)[reply]
Oh I see: Wikipedia talk:Perennial proposals#Move maintenance tags to talk pages. Regarding your movies analogy, yeah, I'll agree that the current bold templates at the top might be like turning on the actors' and directors' commentary on a DVD. But why would moving the tag to the bottom and toning it down be harmful? That would be more like rolling the credits at the end of the DVD. Just as viewers are free to walk out of the theater or eject the DVD or turn off the TV, readers are free to just quit reading when they get to that point. I'd guess that the readers most likely to become editors of a particular article are those that take the time to read to the end of the article. Those just casually reading the lead before clicking off to elsewhere are the least likely to edit—and the most likely to be annoyed by in-your-face tags. And I do find the orphan tag useful as a reader. It tells me that the article is poorly integrated into the encyclopedia, which makes me question its reliability and notability. So I may not trust the article as much as articles lacking the tag. Wbm1058 (talk) 15:50, 9 December 2013 (UTC)[reply]
On articles with large reference sections, how many people will read past them to see what's at the very bottom of the article, unless they're looking for external links or navboxes? Anomie⚔ 19:18, 9 December 2013 (UTC)[reply]
I am sorry you posting is not clear to me. Are you advocating placing them at the bottom or the top? -- PBS (talk) 13:09, 10 December 2013 (UTC)[reply]
I'm pointing out that the comparison to movie credits isn't necessarily apt. Anomie⚔ 16:54, 10 December 2013 (UTC)[reply]
@Anomie: We can only guess on how many read to the end, and how much, if any, reduction in orphan-linking activity a move to the bottom would cause. I'd wager that very few well-developed articles with large reference sections are orphans. Many more orphans are stubs, where the top and bottom all fit on a widescreen HD monitor, or minimal scrolling is needed to get to the end. I share your concern about finding ways to increase orphan-linking edits. Along those lines, I think improvements to the message box text emphasizing that there is a nice tool to help may be more important than where on the screen the message is placed (see the next section). I think a bot-generated list of the most potentially link-able articles, using the Find link tool's algorithm, could be a big stimulant to orphan-linking similar to how the to-do list at Wikipedia:Disambiguation pages with links helps with that project, and would get our most significant orphans needing help knocked off faster. As to linking the articles of lesser notability, I just picked a longstanding one at random, and it happens to be what I feel is typical. Ken Nimori is in Category:Oregon State University alumni. It would be nice to create a lookup table that paired that category with List of Oregon State University alumni. Every member of the category should be in the list. I'd guess that hundreds of such pairs could be created. Then have a bot compare the categories with the lists and put orphans like Ken Nimori into the See also section of List of Oregon State University alumni, where a human editor could then find the correct section to move him to. I think a phased implementation of a move to the bottom would work best and cause the least disruption. Allow the tag to be at the top or the bottom during an indefinite phase-in period. When encased in {{multiple issues}} it will of course still be at the top. Over time the bots and AWB can start adding new ones at the bottom. If we find that the move causes a significant reduction in orphan-linking, then the move can be reversed before too much damage is done. I'll create a sandbox version of what I think could be a good, less cartoon-like bottom-dwelling template that would be less in-your-face but should still get noticed. Best regards, Wbm1058 (talk) 00:30, 11 December 2013 (UTC)[reply]
I think we are getting side-tract here. The specific points that Wbm1058 has raised in this last posting should be in the previous section I am going to place a comment in the previous section about it. -- PBS (talk) 11:09, 11 December 2013 (UTC)[reply]

How many of you are aware of and have used Find link? I'll confess that I'd read this template many times, and assuming that suggestions may be available was just a link to some "helpful advice" on how to go about finding articles to link to the orphan, never bothered to click on that link because "I already knew how to do that". So I was very pleasantly surprised to find that this was a link to a very useful tool. I'd suggest changing the vague "suggestions may be available" to "try the Find link tool", and see if that doesn't draw more traffic to the tool. I think some may find it fun to use, perhaps a bit addicting. I think it's a shame that when this template is sandwiched inside {{multiple issues}} the link to the tool is removed. We have bots running that are efficiently tagging orphans, e.g., monstrous coalition was recently tagged. I just used the tool to link that to seven articles. That was like hitting the jackpot. Often the tool comes up empty. When the tool doesn't find the article title anywhere in the encyclopedia, then you have a "super-orphan", and we have a lot of those. It may be helpful to have a bot run this tool on everything and generate a list of the most potentially link-able articles for further attention by human editors, so we make the most impact with our time. – Wbm1058 (talk) 03:49, 9 December 2013 (UTC)[reply]

I see that someone also had this issue in the discussion at Template talk:Orphan#Is it possible to have the functionality provided in the Toolbox?. I'm looking into solutions and would like some opinions on this. Thanks, Wbm1058 (talk) 23:14, 10 December 2013 (UTC)[reply]

Here is my quick pass at an orphan-bottom template, with new Find link tool advice:

Notice that the Find link tool connects to List of biological databases, although manual intervention is needed because the tool didn't successfully convert an external link to an internal link. Once again, if Category:Biological databases were paired with List of biological databases, than a bot could add every orphan member of the category to a see also section of the list article. Wbm1058 (talk) 02:48, 11 December 2013 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal for a Template Documentation: namespace

This proposal is moved from the Idea Lab. That discussion may be found at Wikipedia:Village pump (idea lab)#Proposal for a Template Documentation: namespace. Update this link if it moves!

Any template with even a shard of complexity has a corresponding documentation file... the end result being that AllPages for templates is chock full of /doc, /doc, /doc. For such a ubiquitous feature, I feel that it would be very justified for a new Template Documentation: namespace to contain all of these documentation pages. This way, we could have a clear dichotomy between template code to be transcluded, as opposed to whatever needs to be said or explained about the template (but, of course, not transcluded with the template).

Let's also consider taking the idea a few steps further. By its direct association with an existing Template: namespace, the new TD namespace has potential for some features not usually found in a run-of-the-mill new namespace.

Automatic transclusion
We could make the function of the {{Documentation}} template automatic: a Template: page, requiring no individually-paged code or template to do so, could automatically check for a corresponding Template Documentation: page and display that on the bottom of the Template page, with a little explanatory divider/footer separating the two - explanation similar to the format currently in place on {{Documentation}}. And of course, none of that documentation or divider explanation would be transcluded onto any pages using the Template page. If we did this, it would be very feasible for a fully-developed, fairly complex template, complete with documentation, to use zero includeonlies, and zero noincludes. None of that crap. {{Documentation}} could become a thing of the past.
No documentation exists? "No documentation exists for this template. Click here to write some! <link>"
Special pages
Hard-coded associations between Template: pages and their Template Documentation: pages would enable us to look into additional Special pages: "Special:WithoutDocumentation", et cetera.
Intelligent categories
An infobox template about birds might be in Category:Infobox templates. It might transclude Category:Birds onto host pages which use it. This is logical, but to restrict the application in those ways we need more include rules. Ugly! My understanding is you simply must have include rules to use categories on a template page - because honestly, how often do categories apply to both templates and their host pages?
A better system: we could declare that categories in the Template: page's code would only apply to host pages, while categories one wishes to apply to the Template: page itself are placed in the Template Documentation: page.

I think that this would be a really useful thing to have on Wikipedia, and if it's adequately implemented it opens the door for similar features on other wikis. =)

Support

  • As proposer: − Elecbullet (talk) 06:34, 12 December 2013 (UTC)[reply]
  • See no reasons to object thus far; anyone who has worked on templates know how unwieldy the /doc subpage workaround system is for documentation. Not sure how much of this would also apply to Modules though. TeleComNasSprVen (talk • contribs) 07:04, 12 December 2013 (UTC)[reply]
    • I know very little about Modules, in fact I learned they existed in the process of writing this proposal, so I have little ability to comment. I foresee much commentary about how if we can have documentation for user scripts, CSS, modules, et cetera, why should templates have special treatment?
If a decision is made to implement Template Documentation as I have proposed, then (due to the bold-faced features I listed) my meager understanding of the software indicates it would probably require the writing of an extension, rather than just a simple new namespace. I think this extension could very easily have the capacity to work for every kind of namespace, and it could implement a system by which the individual installation selects which namespaces are document-able. So we could enable it for Templates if the consensus is as much, and if it is decided to apply to Modules as well, we could enable it there too. And if someone chooses to install the extension on their own wiki, the webmaster can implement documentation on whichever namespaces they please. Maybe I'm just rambling though. − Elecbullet (talk) 07:33, 12 December 2013 (UTC)[reply]
As in something like a new super-namespace in the hierarchy? Like Documentation: Documentation\Template: Documentation\Modules: etc... (Well for now I mean we should just concentrate on Template Documentation: )TeleComNasSprVen (talk • contribs) 07:38, 12 December 2013 (UTC)[reply]
Modules could already use such a system by changing MediaWiki:scribunto-doc-page-name if the target namespace existed. And if I were to implement such a thing more generically I'd do it along the lines of MediaWiki:ns10-doc-page-name. Personally, I'd recommend a pattern along the lines of "Documentation:Template:Foo" and "Documentation:Module:Foo" for a documentation namespace. Anomie⚔ 12:56, 12 December 2013 (UTC)[reply]
That honestly sounds really great. An administrator here suggested to me a master "Documentation:" namespace, which I kinda brushed aside 'cause I never thought of it like that.
Maybe that would be a better way to go about it. − Elecbullet (talk) 17:52, 12 December 2013 (UTC)[reply]
Going one step further, I note we already have a "Help" namespace, and both Special:PrefixIndex/Help:Template: and Special:PrefixIndex/Help:Module: are empty. OTOH, Patrick87 does have a good point below about /doc subpages matching with /sandbox and /testcases subpages. Anomie⚔ 19:48, 12 December 2013 (UTC)[reply]
Help: was mentioned in Idea Lab. I thought that it would be wise to keep generic, wide-scoped help pages like "Help:Editing" distinguished from specific, definitively page-associated documentation like "Template:Infobox bird/doc", which is why I didn't much like the idea of extending the use of Help. − Elecbullet (talk) 02:52, 14 December 2013 (UTC)[reply]
  • Support, although the technical details need to be discussed and ironed out first. The namespace could have the same relationship to Template: space as the Template talk: namespace has, or it could be a new Documentation namespace, where identically-named Template, Module, and perhaps MediaWiki pages would automatically tie to -- similar to the way edit notices are handled. There should be a discussion on the pros and cons of each. equazcion → 02:38, 13 Dec 2013 (UTC)
Part of me thinks that a master Documentation namespace with "Documentation:Template:Infobox" as name format would be best. But part of me thinks also that if that were the case, why would it not be at "Talk:Template:Infobox" too?
It seems that everyone seems to agree that the basic idea of segregating template documentation in some more intelligent manner is a good idea - if I interpret his message correctly, even the fellow under "oppose" (but feel free to correct me). If we can move toward that goal in some form or fashion I think it'd be really good. − Elecbullet (talk) 22:15, 13 December 2013 (UTC)[reply]

Oppose

  • Support the idea behind it, but oppose the proposed implementation. A new namespace for everything (I still have the whole "Draft" NS discussion in mind) will clutter up the UI to a point were it becomes impractical and it will definitely not improve clarity, especially for beginners. A documentation page is a fixed part of a template and should therefore be a subpage of it (I love logical hierarchical structures were appropriate!). The same goes for template sandboxes and everything else linked to the template.
TL;DR: I would favor an implementation similar to WP:Editnotices. – as long as it is technically feasible. {{Documentation}} offers some functionality that would probably need some thought to carry over to the proposed system. Other projects have much more sophisticated documentation templates, e.g. commons:Template:Documentation which automatically creates WP:TemplateData, takes care of translations and much more. All this has to be considered and made available, too, which I currently have no idea how it could be done in a clear and easy way (without recreating the same problem - that this proposal aims to avoid - again) --Patrick87 (talk) 09:20, 12 December 2013 (UTC)[reply]
  • Help: is very broad when it comes to Wikipedia, and covers mainly How to Write X (where X = article, redirect, portal, etc), How to Join the Education Program, How to Use the Watchlist, How to File a Username Change, in short how to use Wikipedia's front end. This namespace is used to document the code or the backend for the MediaWiki software among other things. (And then the really really far backend of this is on mediawiki.org) Sort of like when Help: was split from Wikipedia: as a namespace. I'll still take Help: into consideration as another place for documentation. TeleComNasSprVen (talk • contribs) 11:51, 14 December 2013 (UTC)[reply]
  • Oppose we don't need another namespace. Documentation works fine the way it is. This is a solution in search of a problem. -- Ross Hill • Talk • Need Help? • 17:00, 15 December 2013 (UTC)[reply]
  • Oppose The reasons for this are unconvincing. /doc pages represent only 5% of the template namespace. What is preventing AllPages from being an effective way to search through templates is the fact that we have half a million templates, making an alphabetical list an inefficient way of searching. Not having to use noinclude to transclude the documentation seems like a pretty trivial benefit, when you consider the tens of thousands of pagemoves and edits it will require to implement this. We could already do things like Special:WithoutDocumentation as a database report. You will still need include rules for categories to avoid categorizing the template itself in article categories. Saying that categories on the template page don't apply to the template is confusing and would require even more thousands of edits to create documentation pages for the thousands of templates that are categorized, but undocumented. As I mentioned, only around 5% of templates have a /doc page, but 90% have at least 1 category. Mr.Z-man 18:05, 15 December 2013 (UTC)[reply]
  • Oppose. The benefits do not even come close to the cost in time; energy; resources; effort; etc. to implement this. GenQuest "Talk to Me" 18:10, 15 December 2013 (UTC)[reply]
  • Oppose. This should be implemented properly as a MediaWiki extension, if it is to be done at all. — This, that and the other (talk) 06:31, 16 December 2013 (UTC)[reply]
  • Oppose. While I could see some advantage to it, it seems to be a huge cost in maintenance and conversion, for very little gain, and it introduces rules that bring in a whole new set of issues with common documentation pages. It ain't broke, so why are we trying to fix it? VanIsaacWS Vexcontribs 06:42, 16 December 2013 (UTC)[reply]
  • Oppose per Patrick87. I think the idea of moving documentation transclusion out of community edited templates and into something supported by mw is valuable. It likely doesn't need to be a namespace, but we should push toward hand-rolling less of the template infrastructure as time goes on. Protonk (talk) 18:05, 16 December 2013 (UTC)[reply]
  • Oppose the method, but Support the desire to make it easier to manage template documentation. Is this something that could be done with a template that automatically transcludes the documentation page "Foo Template/doc" within "Foo Template"? I agree that the whole include/noinclude syntax is a bit daunting for moderately experienced article editors who are trying to figure out how templates work and how to improve their function or documentation. I also agree with the proposer that it should be easier to add missing documentation to a template. – Jonesey95 (talk) 16:07, 19 December 2013 (UTC)[reply]
  • Oppose – per Ross Hill. United States Man (talk) 02:17, 21 December 2013 (UTC)[reply]

Comment

− Elecbullet (talk) 06:39, 12 December 2013 (UTC)[reply]
Similar things have been mentioned in other sections. An outline of proposals put forth:
  1. Template:Foo/doc (unchanged, ofc)
  2. Template documentation:Foo
  3. Documentation:Template:Foo
  4. Help:Template:Foo
Of the four, I am afraid that I must see #4 as the least desirable, because I think that the Help: namespace, which is currently reserved for broad subjects such as Help:Editing, does so very well, but would not do well to be mixed with individual-page-specific documentation such as "Template:Infobox/doc". I honestly don't know if I would prefer that over no change at all. − Elecbullet (talk) 06:34, 15 December 2013 (UTC)[reply]
  • I note there are really two separate issues here: (1) Automatically transcluding documentation (which could do /doc subpages) like in the Module namespace, and (2) a separate namespace for documentation. Anomie⚔ 20:01, 15 December 2013 (UTC)[reply]
    When you put it that way, simply having /doc be auto-transcluded without a new namespace really doesn't seem like a terrifically bad option. If we could find a way to move toward that it would be very good. − Elecbullet (talk) 03:49, 23 December 2013 (UTC)[reply]

Template vandalism with images

Over the past couple of days, there have been several reports of vandalism or "hacking" at WP:AN and WP:ANI regarding template vandalism. The vandals target highly used templates that will transclude on lots of articles by placing images in the template to catch readers off-guard and shock them with nudity or something gross. There's obviously very little we can do other than revert the vandalism, protect the template, mark the image as a "bad image" and block the editor as of this moment.

My proposal is short, though the technical aspect of implementing it is a bit more complicated: To add images to the template namespace, an editor must have the autoconfirmed right. After filing a bugzilla and requesting it be changed, when the save button is hit, if the edit would transclude an image in the template namespace, the software would perform a check on the account and if it doesn't have autoconfirmed on their account, then the save will be stopped and brought back to the preview window with a message telling them they do not have the proper rights.

The result would be:

  • There would not be any IPs adding any images to templates, which is almost always reverted anyways because most unregistered users do not understand how to either correctly places images in template syntax or they don't understand that images are not a common thing in the template namespace. In regards to the problem, a majority of the vandalism comes from IPs as well. Forcing autoconfirmed for saving images would force them to at least create an account.
  • Brand new accounts with the intent to add images to vandalize wouldn't work either, because the autoconfirmed permission means they have to wait about four days and make ten edits, which makes template vandalism almost pointless if they have to wait for days and make edits that won't get them blocked. Vandals get bored that way.
  • To users who aren't brand new, it doesn't change anything.
  • The only potential collateral would be a brand new, well-intentioned user who is trying to insert a legitimate image into the template namespace and not being able to, and that is going to be a fairly low number of users who experience this problem.

Regards, — Moe Epsilon 04:17, 19 December 2013 (UTC)[reply]

There's too many ways someone could get around that (not discussing how per WP:BEANS; if you want to know I'll email you). It'd be almost impossible to completely prevent it without effectively semi-protecting all templates. Jackmcbarn (talk) 04:30, 19 December 2013 (UTC)[reply]
See Nirvana fallacy#Perfect solution fallacy. --Guy Macon (talk) 11:02, 21 December 2013 (UTC)[reply]
It's not intended to be a solution that will end the problem, there's effectively no way to end any vandalism outside of full protection so only administrators can edit the page. Of course there's ways to get around it, but it will still stop the majority of it. It's intended to slow down the problem, not to be complete prevention. It's becoming a daily occurrence, and we need to change something other than just wait it out and have readers stumble across an image of a woman peeing again. Regards, — Moe Epsilon 04:40, 19 December 2013 (UTC)[reply]
Support this proposal as a mostly effective countermeasure. -- Ross Hill • Talk • Need Help? • 04:45, 19 December 2013 (UTC)[reply]
  • Actually, there are two other pieces of collateral not mentioned: 1) regular editors editing from an insecure connection, where logging in could compromise their account, and 2) regular editors without an account. Both of these groups would be adversely effected by a semiprotect-esque edit filter on the entire template namespace. So I would have to oppose something like this. I would, however, be supportive of looking at expanding WP:High-risk templates to draw up criteria for semi-protecting semi-widely transcluded templates, including mature wikiproject infoboxes and expansive navboxes. VanIsaacWS Vexcontribs 05:13, 19 December 2013 (UTC)[reply]
"Regular editors without accounts" — this is a perennial (almost hallowed) objection to any suggestion of restricting IP access. How many of these are there? How is "regular" defined, and how substantial are their collective contributions relative to the work not done because time and effort spent cleaning up after irrregular IP editing? ~ J. Johnson (JJ) (talk) 22:01, 20 December 2013 (UTC)[reply]
How many long-term IPs are there? I've encountered enough that when I see a proposal like this, I think "but that would keep regular IP editors from doing X", but few enough that when I run into an issue with an IP, I don't give more than a passing thought to the possibility that they are actually a long-term IP editor. But you chose to ignore the possibility of other lines of inquiry - about expanding the high-risk template definitions to bring in default semi-protection for the kinds of templates where this could be a problem - so I don't know whether you are actually taking any of this seriously, or whether there's something else going on entirely that I'm not seeing. VanIsaacWS Vexcontribs 12:30, 21 December 2013 (UTC)[reply]
The proportion of IP editors that are "regular" (good? serious?) is small, just because of the large base, and I suspect their total number as well. But what I am curious about is: how substantial are the supposed contributions of these purported "regular IP editors" relative to the work necessitated by not having everything semi-protected? ~ J. Johnson (JJ) (talk) 20:27, 21 December 2013 (UTC)[reply]
Quite frankly, I don't know, and I'm not sure that anyone can even make an educated guess on it. You usually don't ever follow up on figuring that sort of thing out unless there is a conflict of some kind, which horribly biases personal experience, and tools can't see through dynamic IPs. We're actually dealing with five different populations here, and it's almost impossible to distinguish between many of them, let alone make any sort of comparitive enumeration: 1) single incident IP vandals 2) short-term IP editors involved in edit conflicts 3) short-term, productive IP editors not involved in edit conflicts 4) long-term, productive IP editors involved in edit conflicts 5) long-term, productive IP editors not involved in edit conflicts. Because IPs get dynamically allocated, there is no tool that can tell us the difference between #2 and #4 or #3 and #5, there is basically no means of ever really being able to notice #3 or #5, or determine whether you have seven different #3s or a single #5, and #1 is the only group that you are trying to target, but #2, #3, #4, and #5 are all getting caught in the crossfire. I don't know the answer, but I would certainly argue that making a blanket ban on editing templates with an image tag in them is an overreaction. VanIsaacWS Vexcontribs 21:57, 21 December 2013 (UTC)[reply]
One of the only things that Visual Editor was good for was providing a peek at behavioural choices. When given a choice, new accounts used Visual Editor about 25% of the time, IPs about 10% of the time, and established editors about 8% of the time. A little bit of number crunching on that factoid would indicate that about 80% of IP editors are experienced editors. Certainly not a number to quote as gospel truth, but an interesting indicator nonetheless.—Kww(talk) 00:37, 22 December 2013 (UTC)[reply]
Yes, I found that stat quite interesting. But "experience" does not necessarily correlate with "good"; it may mean nothing more than most vandals are experienced. I think it tells us nothing about all the good work IP's allegedly do. ~ J. Johnson (JJ) (talk) 00:44, 23 December 2013 (UTC)[reply]
  • Oppose as this hasn't been much of a problem for years. That tells me that for years, IP editors have been adding useful and proper images to templates with only an occasional vandal mucking with things. That leaves me the impression that this would leave way too much collateral damage to be worth doing. This would also prevent an IP from making edits to templates that include an image (even if they didn't place it there). So, if they wanted to update a flag icon template for example to adjust the range of years or correct a typo of a country name in a rarely used version, they would be unable to and be required to submit an edit request. This is too tedious and I think is a bad idea. Technical 13 (talk) 12:59, 19 December 2013 (UTC)[reply]
  • This is actually been a problem for a years, it's just that vandals get more creative with time, it's the whole reason why the page for high risk templates exist and has existed for so long. Finding gross or nudity-laced images and pluging them into templates to shock readers has been a long-standing vandal tactic. It's just a matter of finding an image that isn't marked as "bad" and finding a new template that hasn't been protected yet, and a vandal as of late has just been exploiting less high-risk templates that still spread to hundreds of articles, forcing us to protect things that are not high-risk. Also, your fear that IP editors wouldn't be able to edit a template with an existing image is not needed. When you click the save button, the software identifies what text needs to be changed, shown in diffs in the history and not surrounding text unrelated to the edit. The proposal is to have the software interpret new text being inserted and if it would render [[File:imagename.extension]] or [[Image:imagename.extension]] successfully, a check of permissions for the user would be done. Existing images would not be an issue, and the fear of high collateral isn't really warranted either. Images are not highly used in the template namespace, and outside of regular editors logged out, most IP editors would not know when or how to insert an image that wouldn't be reverted. Regards, — Moe Epsilon 17:42, 19 December 2013 (UTC)[reply]
  • The problem is that figuring out whether it would render [[File:imagename.extension]] or [[Image:imagename.extension]] is extremely hard to do (impossible, actually, since the Halting problem is unsolvable). There'd either be a ton of false positives, effectively semi-protecting all templates, or a ton of false negatives, making the protection worthless. Jackmcbarn (talk) 17:53, 19 December 2013 (UTC)[reply]
The filter code is hidden from public view but in order to reduce false positives, it only activates under certain conditions (which we don't want determined vandals to know) and it doesn't prevent the edit, it only logs it (the linked edit wasn't logged). PrimeHunter (talk) 19:33, 19 December 2013 (UTC)[reply]
By "false positives" I mean loggings of non-vandalism edits. PrimeHunter (talk) 19:38, 19 December 2013 (UTC)[reply]
  • Sympathetic to the proposal but this discussion is way too technical for me Johnbod (talk) 22:05, 20 December 2013 (UTC)[reply]
  • Question - Is this a case where some variant of Pending Changes (something like Pending Changes 2 perhaps) for these high risk/high use templates would be useful? If it stops the vandalism going live across Wikipedia then it takes away the point of it - and it may also help to minimise the potential for people accidentally brwaking high use templates.Nigel Ish (talk) 23:35, 21 December 2013 (UTC)[reply]
  • Alas, pending changes Level 2 is not an option.
Extended content
Interaction of Wikipedia user groups and page protection levels
  Unregistered or newly registered Confirmed or autoconfirmed Extended confirmed Template editor Admin Interface admin Appropriate for
(See also: Wikipedia:Protection policy)
No protection Normal editing The vast majority of pages. This is the default protection level.
Pending changes All users can edit
Edits by unregistered or new editors (and any subsequent edits by anyone) are hidden from readers who are not logged in, until reviewed by a pending changes reviewer or admin. Logged-in editors see all edits, whether accepted or not. 		Infrequently edited pages with high levels of vandalism, BLP violations, edit-warring, or other disruption from unregistered and new users.
Semi Cannot edit Normal editing Pages that have been persistently vandalized by anonymous and registered users. Some highly visible templates and modules.
Extended confirmed Cannot edit Normal editing* Specific topic areas authorized by ArbCom, pages where semi-protection has failed, or high-risk templates where template protection would be too restrictive.
Template Cannot edit Normal editing High-risk or very-frequently used templates and modules. Some high-risk pages outside of template space.
Full Cannot edit Normal editing Pages with persistent disruption from extended confirmed accounts. Critical templates and modules.
Interface Cannot edit Normal editing Scripts, stylesheets, and similar objects central to operation of the site or that are in other editors' user spaces.
* In order to edit through extended confirmed protection, a template editor must also be extended confirmed, but in practice this is almost always the case.
Other modes of protection:
--Guy Macon (talk) 00:23, 22 December 2013 (UTC)[reply]
Why isn't PC2 an option? That RFC only said not to use it (normally; there have been a very small number of accepted exceptions) for six months or so after PC1 was available. There's nothing there that says PC2 may absolutely never be used—and even if it did, then WP:Consensus can change. If this is an especially good use case for PC2, then just make a WP:PROPOSAL to do so. WhatamIdoing (talk) 18:14, 23 December 2013 (UTC)[reply]
It's a technical issue, not a policy one. Pending changes protection doesn't work through transclusion. The latest version is always transcluded, even if it's not accepted. Jackmcbarn (talk) 18:23, 23 December 2013 (UTC)[reply]
  • I think that because an administrator is no longer needed, the threshold for what constitutes a "high-risk template" should be lowered. Perhaps we should start at half of the transclusion count of what it was for full protection? What was that threshold exactly anyways, does anyone know? I've seen as low as about 2,000. Comments? Complaints? I'm sure there will be both to this idea, so we might as well get them now. Technical 13 (talk) 05:52, 22 December 2013 (UTC)[reply]
  • I'm not exactly sure. The high-risk templates guideline says each template was considered individually, which might need to be individually re-evaluated. Obviously a high transclusion count matters, but templates that are highly visible and not cascade protected and templates substituted often are also high-risk. Likewise, one-time targets for hit-and-run vandalism and transclude on a small number of pages should not have been semi-protected. I'm curious how abuse filter 599 is doing, since I can't view what it is logging. Regards, — Moe Epsilon 07:49, 22 December 2013 (UTC)[reply]
  • Oppose This completely violates the template editor RfC. "It should be understood that the standards for what constitutes a high-risk template should remain unchanged and not be expanded, despite this newly created protection level and rights group." Jackmcbarn (talk) 16:19, 22 December 2013 (UTC)[reply]
  • I'm not proposing to change it solely on the bases of there being a new userright. I'm proposing changing the threshold because there is now evidence of vandalism on templates with a lower level of transclusion. There is a big difference there, I do hope you see it. Technical 13 (talk) 00:06, 23 December 2013 (UTC)[reply]
  • Yes, I seem to recall that during the Rfc there were a number of editors who opposed the new right because they believed that over time those with the right would find reasons to gradually protect more and more templates, causing frustration for those without it. —Anne Delong (talk) 05:51, 23 December 2013 (UTC)[reply]
  • I'd rather see a solution that added history information for transclusions, and if possible a summary added or removed images to the history pages. For example if article used template:Infobox_Foobar then the most recent changes to that template should be shown in the history. It wouldn't need to show the full history for the templates, just the most recent one for each template with a link to the full history. PaleAqua (talk) 08:26, 23 December 2013 (UTC)[reply]
  • I'm familiar with that script. It's why I think doing this for history page should be doable. The history page is seems to me to be a better place than the preview page for dealing with vandalism. The first check I make when noticing a page has been vandalized is the history page, I assume that this is fairly common. Furthermore, the editors that wouldn't automatically consider that a template change might be a cause, would likely also not be the ones to add a custom js script to common.js file. PaleAqua (talk) 18:09, 23 December 2013 (UTC)[reply]

Filtering Inappropriate Pages

Not going to happen. See WP:NOTCENSORED, WP:PEREN#Content warnings, and WP:PEREN#Censor offensive images. Anomie⚔ 13:04, 20 December 2013 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I know that some articles in this wiki are inappropriate for certain contributors. I am requesting a search filtering to prevent unregistered (anonymous) users and users registered a minors to view such Wikipedia pages. I'm also requesting a template that warns users about its explicit adult content. -- Ismael755 — Preceding unsigned comment added by Ismael755 (talk • contribs) 04:17, 20 December 2013 (UTC)[reply]

Votes

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Pseudo-namespace Redirects

There is currently an RFC opened at the village pump to clarify current consensus and policies about the controversial pseudo-namespace redirects that you might want to participate in. TeleComNasSprVen (talk • contribs) 23:48, 20 December 2013 (UTC)[reply]

Article Incubator

Hi,

There is an RFC at Wikipedia:Article Incubator/RfC to close down Incubator to close down the Article Incubator. Please join the discussion there.

TheOriginalSoni (talk) 07:33, 23 December 2013 (UTC)[reply]

On Orphan tags again

I apologise for missing the discussion above and the Request for Comment but I would like to give some arguments that oppose the move to the talk page. Before starting I would like also to note that I am ready to follow any consensus reached. I already filled a BRFA in case the consensus reached is finally implemented.

So, I start:

  1. The main argument on moving the orphan tag is a general argument against all tags and has already failed many times. SeeWikipedia:Perennial_proposals#Move_maintenance_tags_to_talk_pages
  2. Distinguishing editors from readers is completely out of the idea I have for Wikipedia. Wikipedia is the encyclopaedia everyone can edit. Every reader is a potential editor. We should encourage readers to become editors. Tags promote the idea of editing. Almost all Wikipedia articles are incomplete and need expansion.
  3. Connectivity between pages is a big deal. We should rely on the fact that an article is searchable via the Search engine. We should connect articles between each other. In the past the Russian Wikipedia went a step further and checked for articles only linking from one to each other with no other connections. We should not want dead ends in Wikipedia. Reading is an endless adventure.
  4. 120,000 pages with no incoming links, not even from lists of pages is an issue. Not a small issue. Think that from these lists we xclude disambiguation pages, SIAs etc etc.
  5. Things are getting better. That things are stale is a myth. Per progress described in Category:Orphaned articles: In January 2013, there were 175,000 orphan articles and in November 121,725 articles. 50,000 less. everytime there was some effort to reduce the list we had results. If we exclude pages with 1 or 2 incomings links from the list things may be much better. In the past we were very strict about it. Now maybe it is time switch a bit and remove tags if there is at least 1 incoming link. -- Magioladitis (talk) 11:37, 23 December 2013 (UTC)[reply]
A Bad Boy Can Be Good For a Girl, A Fort of Nine Towers, Aachen penny of Charlemagne, Abaareey, ABC Cinema, Wakefield, Abdol Ghadar, Abdul Wali Khan University Mardan, Abhay Gohil, Gerardo Ablaza, and Michael Abraham (chemist)
I could only link three. I linked Abdul Wali Khan University Mardan in Mardan. I also removed the tag on Gerardo Ablaza since he had been linked already. I linked A Fort of Nine Towers in And the Mountains Echoed, since both books are mentioned as being reviewed in one of the references of the latter. I won't contest it if it is reverted. Three out of ten, and all of them could only be linked once (which I think still makes them orphans, but I removed the tags anyway). The seven will retain their orphan tags indefinitely.-- OBSIDIAN†SOUL 16:33, 23 December 2013 (UTC)[reply]
Not indefinitely. Until Wikipedia is expanded further enough. Now I am running against all articles and checking they are already linked by other pages. Still 60,000 pages to check. -- Magioladitis (talk) 17:07, 23 December 2013 (UTC)[reply]
@Magioladitis: Yesterday I ran BattyBot over all articles tagged as orphans and removed hundreds of tags. I check the current month's articles almost daily. GoingBatty (talk) 19:04, 23 December 2013 (UTC)[reply]
@GoingBatty: and then why I did these today: [1], [2], [3], [4] and more... -- Magioladitis (talk) 19:12, 23 December 2013 (UTC)[reply]
@Magioladitis:
1 & 4 - My bot runs autotagging and then skips any articles that still contain "orphan" - these contains "orphan" in the text.
2 - Link was added yesterday from Phalia
3 - Unknown, but glad you're finding them. GoingBatty (talk) 19:28, 23 December 2013 (UTC)[reply]
Nope. Indefinitely. We have 58,662 orphans from 2006 to 2010. These are articles which had the tag for 3 to 7 years. That's 1.3% of our total number of articles. It's very clear from that alone, that readers either don't know how to fix them, or don't care to fix them. Fixing orphans are the concern of experienced editors not drive-by readers. They're the only ones with enough know-how to do it properly. All of you here who support retaining the tag as is are bot, tool, or script users. Even without the tag, you can still accomplish these tasks. But you are not anymore the average reader, and to equate yourselves with them is a mistake.-- OBSIDIAN†SOUL 00:11, 24 December 2013 (UTC)[reply]
Additionally, saying "Until Wikipedia is expanded further enough" is basically saying it can't be fixed. That's counter-intuitive to the purpose of maintenance tags. What's the use of those tags on top of the article urging everyone to fix the orphan status if it can't be fixed anyway? And it's not the minority either. That was 7 out of 10 that couldn't be fixed. It will just waste everyone's time every time they attempt to de-orphan it, only to find out they can't.-- OBSIDIAN†SOUL 01:39, 24 December 2013 (UTC)[reply]
@Obsidian Soul: Just curious why you didn't add |att=December 2013 to the seven articles you could not deorphan, which hides the article message box. GoingBatty (talk) 04:14, 25 December 2013 (UTC)[reply]
Because like our regular readers, I had no idea that I could or should hide the tags for undeorphanable files that way. It is not mentioned in the template itself. And even if it was (which would make the template even larger and more alarming than it already is), I doubt a regular reader would actually understand how to add that properly or think they have the "rights" to. The only people who know that attribute and use it, are those who do dedicated maintenance work, and they don't need the tag to tell them it's an orphan. They usually access the orphan list through the category directly.-- OBSIDIAN†SOUL 05:18, 25 December 2013 (UTC)[reply]
  • Oppose as original proposer of previous discussion.
  1. The previous proposal explicitly only applies to orphan tags. I have no problems with other maintenance templates (except when people are tagbombing to make a point). As pointed out, the assumption that there is a preexisting consensus not to move maintenance templates is not based on anything other than they were first implemented that way in the first place.
  2. Wikipedia's primary goal is to educate, not to turn everyone into Wikipedia editors. While we should encourage new editors as much as possible, we should never lose sight of the fact that we are an encyclopedia, not the borg collective. We are meant to be read first, edited second. Otherwise we might as well just display Wikipedia as an etherpad in permanent edit mode.
  3. Not everything can be connected. Much less connected two to three times. Several subjects (e.g. taxon articles) already had to explicitly be excluded from being orphan-tagged because of their highly-specialized nature. There are other articles like that that can't be categorized as easily, but are nonetheless similarly unlinkable to more than one other article (or none at all) even though they are undoubtedly notable. For example: non-western notable people, places, ideas, or organizations. Or companies and products even, where adding it to other articles would constitute spamming. And while they may not have incoming links, they would usually still have outgoing links, thus still fulfilling part of the connectivity requirement. To put it in analogy: when you're solving a jigsaw puzzle, you will always find instances of difficult pieces which do not fit yet or can only be slotted to one other piece. And the best way to solve that is not to force them to fit, but to find other easier pieces to work on until you eventually link up with it.
  4. It's a minor issue because it does not concern our readers. Again, most readers arrive through the topic through search engines, not by clicking on a link from another article. They can still find the article very easily if they wanted to.
  5. The fact that more orphans remain than are fixed seems indicative that a fair amount of them are permanent members of the category. As in they can't be linked yet or at all, unless someone forcefully adds it on See alsos of vaguely related articles. And I don't see that as ideal either.-- OBSIDIAN†SOUL 12:32, 23 December 2013 (UTC)[reply]
  • I have argued a few times to create a "page tags" extension to MediaWiki, which would make maintenance tags (and maybe WikiProject banners and things like {{ArticleHistory}}) out-of-band (separately displayed and separately editable from article content, possibly with different permissions). And by the way, it would render this whole discussion moot, since everyone could choose to hide or show tags wherever they want, as they please. Keφr 13:52, 23 December 2013 (UTC)[reply]
  • Support Keeping all of the tags on the same page. Considering the technical in-feasibility of fragmenting the tags with some on the article page or some on the talk page, it jut does not seem sensible to do so. Twinkle, AWB, AFCH, and some other scripts/tools are all having difficulties accomplishing this because it requires adding an entire new section to the code and quite frankly it's not worth it. Let's not pad a bunch of editors edit counts to fragment the maintenance tags, seems entirely counter productive. You don't like the way the tag looks on the articles page, we can change the way it looks without getting rid of it. Technical 13 (talk) 17:47, 23 December 2013 (UTC)[reply]
  • Here's my thinking:
    1. The main argument on moving the orphan tag is that it's about a problem on a different page. No amount of editing Orphan is going to de-orphan it. You have to edit some other page. I support reducing the prominence of this particular tag (e.g., moving, hiding, or re-sizing it). I do not support doing this for any other tag.
    2. I agree that every reader is a potential editor. Let's focus them on tasks that can be achieved by editing the article they're reading.
    3. I agree that we should not want dead ends in Wikipedia—but orphans are not {{dead end}} articles.
    4. I agree that having 120,000 pages with no incoming links is an issue. Maybe, in addition to manually de-orphaning some, we should be looking at whether all of these articles actually belong here. We had a spate of spam-articles about Alaskan dermatologists a couple of years ago. How many of them really belong here? Do you realistically think that we can de-orphan every single article about every single dermatologist that paid someone to create an article, without creating something silly like a "List of Alaskan dermatologists"?
    5. I agree that things are getting better, but this doesn't imply that we need these tags to be the first thing that the reader sees on the page. Things can still get better even if the orphan tag is moved to the bottom and made small like a {{stub}} tag, or moved to the talk page, or turned into a hidden maintenance category. WhatamIdoing (talk) 18:29, 23 December 2013 (UTC)[reply]
Comment I'm more likely to attempt to deorphan an article if I see the tag. Moving the tag to the talk page makes it less likely that I'll see it, which means I'm less likely to attempt deorphaning. GoingBatty (talk) 19:32, 23 December 2013 (UTC)[reply]
Note that the broader consensus of the previous discussion was to move it somewhere other than at the top of the article where it breaks article layout and is the first thing that the readers see. It doesn't necessarily have to be the talk page. A hidden category on the same page or somewhere at the bottom like {{Uncategorized}} or {{Stub}} were all proposed as alternatives. All of those are functionally fine, and editors have no problem sorting through them and fixing them.-- OBSIDIAN†SOUL 01:52, 24 December 2013 (UTC)[reply]

Proposal: Delete template, turn into hidden category

Here's an idea: Why don't we just delete the template and turn it into a hidden category. I do agree that the template itself can incite panic in new users, but moving it to the talk page helps no one if you can't see it. If you want to do maintenance in this category under the above proposal, you either have to be a user with a sophisticated understanding of how categories work (surprisingly, this is less common than most people think), or you give up because you have no idea where the template went. How about we just delete the template itself and replace it with hidden categories, so that way it can be seen on the user page, and we won't have a maintenance template appearing on a talk page. Kevin Rutherford (talk) 07:11, 24 December 2013 (UTC)[reply]

I have no problems with that. A fair amount (most?) of deorphanings are done naturally over time as more articles are created that start linking to them anyway.-- OBSIDIAN†SOUL 05:23, 25 December 2013 (UTC)[reply]

Automatically hide categories on Draft pages

Right now, we have some articles that have now been moved into the draft namespace. In the old days, you might have them under article titles like, "User:XYZ/Something." Now, they are under titles such as, "Draft:XYZ." In the days when everything was in the userspace, Articles for creation space, and wherever else people placed their submissions, it was harder to nullify the categories. Now that we have them in one space (well, in theory anyway), would people be adverse to having the categories either automatically nullified or have a bot do this work, so that we can remove potentially unnotable persons/places/things from general categories? It would remove a lot of the clutter that currently exists in these categories, which often contain half-worked on articles and ideas, and it would help to clean up the site. Plus, when the articles are moved, the site could be set up to automatically include these categories, like what goes on in the AFC submission process right now. Kevin Rutherford (talk) 07:14, 24 December 2013 (UTC)[reply]

Discussions about the new Draft namespace are usually at Wikipedia talk:Drafts. PrimeHunter (talk) 11:27, 24 December 2013 (UTC)[reply]

Wiki.png

As New Year is coming soon, so I'd like to propose that we adopt special New Year-theme appearance for our File:Wiki.png for only two days – 31/12'13 and 01/01'14. As I can see from file upload history, this wasn't a practice before. (Maybe it didn't occur to anyone.) But why wouldn't we make our Wiki space nicer with special holiday details? I have no doubts many of us were extremely hard-working this year, so we have so much to celebrate. Don't you think? Alex discussion ★ 08:57, 26 December 2013 (UTC)[reply]

Great idea! I'm in for a party hat. --NaBUru38 (talk) 21:21, 27 December 2013 (UTC)[reply]
@Aleksa Lukic: I like the spirit of the idea but I'm not too sure about whether it should actually be done. At present, and as far as I am aware, we do not and have never changed the logo for any other ceremony or festival, apart from the tenth anniversary celebrations. By celebrating New Year, not only have we selected the Gregorian calendar's date of the New Year for 'special treatment' against others (i.e. the Chinese New Year), which would only seem to exacerbate the systematic bias towards the western world on enwp. If editors would like to commemorate events, they can nominate articles for special days at DYK, TFA, FP etc., though I personally would be sympathetic to sometimes changing the logo as a fun, light-hearted way of marking secular, non-controversial and apolitical events (whatever they may be). Sorry to be a party pooper, but I'd think we'd need general consensus on changinng the logo for events in principle rather than just for this specific New Years Day. Also, it's a little late - could we get a decent logo mocked up and decided on in time? I doubt it, unfortunately. :( Acather96 (click here to contact me) 22:33, 27 December 2013 (UTC)[reply]
  • Completely agree with what Acather said. I like the idea of changing our logo for specific occasions, but we need widespread consensus for the given select events (and designated alternate logos) before we implement that. Certainly an idea to be pondered over for a longer discussion. TheOriginalSoni (talk) 00:11, 28 December 2013 (UTC)[reply]
  • I agree with what Acather has said, but I would like to add that since I like this idea (and something along the same lines is something that I actually set up on DDOwiki) I would be willing to write a userscript that would be available to anyone that would like to see this be something available. I actually have another script that changes that image to symbolize that there is something going on on a page that is .sysop-show (a hidden section designed for admins and template editors) so that a setting can be toggled to show or hide those comments and notes. So, if I can find someone willing to create the proper sized .svg images for this proposal, I would be happy to write a script that will change the image on the correct days for whichever holidays or events that have available images. I could have it customized so each user could define a list of holidays in their userspace. Let me know if this would be an acceptable alternative to forcing holidays/religions/events on all readers and editors alike on Wikipedia. Happy editing! Technical 13 (talk) 01:44, 28 December 2013 (UTC)[reply]
FYI - there's a holiday logo in Wikipedia:Wikipedia_Signpost/2013-12-25/Discussion_report. GoingBatty (talk) 05:20, 28 December 2013 (UTC)[reply]

Orphan tag alternate idea

Moving the orphan tag is an inelegant and needlessly complicated process upon which the validation and ultimate removal becomes unworkable. An alternate and better option is to remove the banner portion of the template and make it function like Template:Coord missing. The end result allows direct and no-mess tagging of orphaned articles and resolves the issue of those supporting the talk page move. I personally did not know about the RFC or would have commented - others have come to the same conclusion, but were also unaware. I believe that this resolves both parties issues with a more optimal solution in terms of those who place, check and remove the tags. To put it bluntly: The tag is gone from view and the banner won't choke the talk page where validating and removing won't occur. ChrisGualtieri (talk) 06:03, 28 December 2013 (UTC)[reply]

Question: With your suggestion, would {{orphan}} still reside within {{multiple issues}}, or be moved somewhere else? If moved, where would it reside? Thanks! GoingBatty (talk) 06:13, 28 December 2013 (UTC)[reply]
It would no longer be a banner, the most simple solution is to make it a hidden category and that would mean it would no longer be in {{multiple issues}} unless specifically requested. At this time, I think making it completely hidden is justified given the RFC, it would still be functional and check-able like any other tracking category. ChrisGualtieri (talk) 06:24, 28 December 2013 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=588034306"