Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

New proposals are discussed here. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.

« Archives, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172

Get rid of stub tagsEdit

I know this is a bold proposal, and is likely to be controversial, but stub tags aren't useful. They don't get people to edit stub articles, which is their stated purpose. They do have a number of negatives: They often remain in articles long after they has been brought up to Start-class and higher. They conflict with the classes stated on talk page banners, which are often more up-to-date. They add a useless image and clutter to the articles. It's time to begin to think about eliminating them. For those people who might be feeling reticent, perhaps an experiment should be run where stub tags are removed from a random subset of articles, then they are compared in, say, one year's time, to a subset of similar articles and measured for levels of (destubifying) improvements. Any thoughts? Abductive (reasoning) 00:35, 21 June 2020 (UTC)

I think you have actually identified two distinct issues here: 1) we don't have any evidence that stub tags are achieving their stated purpose, and 2) stub tags are conflicting with WikiProject assessments. For #1, I think an experiment could yield from interesting results. For #2, I think this would make a nice bot task to remove stub tags when a WikiProject assessment is upgraded from stub. It might be worth upgrading {{WPBannerMeta}} to generate a reassess flag for the bot to add when a stub tag is removed, but a WikiProject still has it assessed as a stub. For the experiment on #1, I would suggest:
  1. Get a list of something like 10,000 random articles, and remove any that are not assessed as a stub by WikiProjects, or have neither a stub tag nor a WikiProject banner on its talk page.
  2. Do an assessment of the remaining articles and remove any that aren't actually stubs.
  3. Split WikiProject claimed articles by stub-tagged or not, and remove/add stub tags to get each WikiProject's article count roughly even (shoot for at least 1/3 of each). Remove stub tags from the unclaimed articles to even out the total count, again going no less than 1/3 for either group.
  4. For the two groups, drop the top and bottom (quartile? ⅒th?) in terms of edit size, ignoring any bot edits, and compare the two groups by interest (number of edits by unique editors), engagement (number of non-revert, non-patrolling edits by registered editors), and overall article change (total prose added to article during experiment run time). VanIsaacWScont 14:17, 21 June 2020 (UTC)
    Thanks for your input. Abductive (reasoning) 23:07, 21 June 2020 (UTC)
  • Oppose The OP doesn't present any evidence to support the proposal. Me, I'd rather eliminate project templates and assessments as I've never seen these do any good and they tend to stick around for longer. The stub templates are comparatively unobtrusive and have an encouraging and pleasant tone. Andrew🐉(talk) 22:47, 21 June 2020 (UTC)
    So, I present no evidence, then you say talk page assessments don't do any good, and also present no evidence. Abductive (reasoning) 23:07, 21 June 2020 (UTC)
    This is not my proposal and so it's not my responsibility to be providing evidence. But here's a couple of examples – both being articles that I created recently. Firstly, consider Ambarnaya. I created this with the {{river-stub}} tag. User:Catan0nymous added two more stub tags: {{Russia-stub}}, {{Siberia-stub}} and user:Abune then consolidated the stubs into {{Russia-river-stub}} and {{Siberia-stub}}. These tags seem to have three functions:
    1. Placing the article into the categories: Category:Siberia geography stubs and Category:Russia river stubs
    2. Displaying some appropriate icons -- maps of Russia and Siberia
    3. Advising the reader that the article is just a start and inviting them to help expand it
    My second example is List of longest-running radio programmes. In that case, I started out with the {{under construction}} tag because the page needed a good structure as a foundation and I wasn't sure what would be best. Once that was done, I removed the tag. By that time, the list structure was established and I used the {{dynamic list}} tag to indicated that the list was quite open-ended. That tag also invites the reader to add sourced entries and so I didn't see the need for a stub tag too.
    Neither of these cases indicate that stub tags are a problem that needs fixing. Sensible editors use them as they see fit and they don't seem to cause any trouble. One feature which helps is that, by convention, they are placed of the foot of an article, where they don't get in the way.
    Andrew🐉(talk) 08:00, 22 June 2020 (UTC)
    Andrew Davidson, I agree with the assessment system. It's absurd. Articles can be Stub, Start, C, B, GA, A, or FA. That's seven levels, which is absurd. The gradations are way to small, and the assessment criteria way to subjective. Class A articles are "Very useful to readers", but GA are, "Useful to nearly all readers". That's absurd. -- RoySmith (talk) 02:15, 22 June 2020 (UTC)
    The minimum acceptable standard for an article on the front page at ITN, OTD or DYK is effectively B class due to the requirement that they be fully referenced (the same goes for the de-stubathons), although we can't state that explicitly because B class ratings are in the hands of the projects. GA and FA are community assessments. B class articles are generally capable of becoming GA, but there is little incentive to submit them for review (GA is already backlogged enough), unless you are seeking to take it to DYK, FA or FT. Similarly, A class articles are generally capable of becoming FA after a review, but most cannot because each editor is limited in the number that can be submitted. So we have three categories (stub, start and C) for poor quality articles. The differences between them are fairly objective, but the value of the distinction is questionable. Hawkeye7 (discuss) 22:57, 20 July 2020 (UTC)
  • Comment I doubt the suggested experiment would produce any clear results frankly. People are often reluctant to remove stub tags, or simply don't notice them. The wikiproject tags are just as prone to under-rate as the ones on the article in my experience. What might be more useful is a list of articles tagged as stubs where the article is over a certain size (not sure what). Reviewing these would I expect show most can be removed. Of course people still have to do this. Johnbod (talk) 23:59, 21 June 2020 (UTC)
    • The issue isn't so much as picking the certain size, it's defining what size is. The easy way out is to count the characters of wikitext, and you end up with quarry:query/46032. But plenty of those only have a half dozen or fewer sentences, despite their absolute length. —Cryptic 01:22, 22 June 2020 (UTC)
      Like Negombo_Polling_Division - but that has massive tables, no doubt like the other Sri Lankan electoral districts, & certainly isn't a stub. In fact I'm pretty sure most of these are mainly tables. But thanks. Johnbod (talk) 02:44, 22 June 2020 (UTC)
      • Do you know of any utilities for querying the size of the prose text? VanIsaacWScont 02:06, 22 June 2020 (UTC)
        • articlequality is not bad at all. I think it guesses based on discounting common words and repeated words, which is often a feature of lists and tables. Abductive (reasoning) 04:07, 22 June 2020 (UTC)
          I'm not sure how it works, but the MilHist Project has been using it with considerable success over the last few months to assess unassessed or incompletely assessed articles. Articles that are auto-assessed as B class are flagged for human review. Hawkeye7 (discuss) 22:57, 20 July 2020 (UTC)
          WPMED has been using it with success, and some of ORES's 'stub or not-stub' work was trained on medicine-related articles. See m:Research:Screening WikiProject Medicine articles for quality for a query that they ran for me a couple of times. I would be perfectly comfortable having an ORES-based bot set (and remove) all stub-class ratings for WPMED. WhatamIdoing (talk) 00:34, 7 August 2020 (UTC)

Considering I've run contests with over 1000 articles destubbed directly from stub categories like WP:The African Destubathon and Wikipedia:The Great Britain/Ireland Destubathon and am running Wikipedia:The 50,000 Challenge which directly feeds off stub tags this is one of the dumbest, most ignorant proposals I've seen for some time and that's saying something!! There is an issue with updating the project tags once an article is no longer a stub and stub tags remaining in articles not stubs but that's hardly a reason to get rid of them entirely. Rosiestep and myself proposed a bot to sort that out but the Wikipedia community being the divided way they are wouldn't get us the consensus we need to sort it out.† Encyclopædius 08:19, 22 June 2020 (UTC)

I don't see why, User:Encyclopædius. I won some sort of prize in one of your excellent contests, but when looking for articles to improve, I remember just removing the stub tag on about five for every one that actually was a stub. I don't agree with complete abolition, but they are in a serious mess & should be sorted out. Johnbod (talk) 13:58, 22 June 2020 (UTC)
Yup, and can you believe when I proposed a bot to control the inconsistency and remove stub tags from articles with over 1.5 kb readable prose and update the talk page tags some people opposed? Andrew Davidson for a start. † Encyclopædius 14:04, 22 June 2020 (UTC)
Can a bot at least go around and remove stub tags from all really huge articles that have talk page templates that claim Start-class or above? Then maybe work its way down to smaller articles until it on the verge of making errors? Abductive (reasoning) 04:18, 24 June 2020 (UTC)
Yes. In fact, the MilHistBot is already capable of carrying out this task. Hawkeye7 (discuss) 22:57, 20 July 2020 (UTC)
AWB does something similar, too, by removing stub tags from articles that are above a (generous) size. WhatamIdoing (talk) 00:35, 7 August 2020 (UTC)
  • "stubs" help navigate articles that need attention. They typically are located at the very bottom of article and do not interfere with regular reader who has no intention to improve article. Basically nothing is wrong with "stubs" as far as I'm concerned. User:Abune (talk) 13:04, 22 June 2020 (UTC)
    Very true, User:Abune. Readers rarely notice them, and even if they do, it is hard to see that they have any negative impact. Some editors find them useful. What's the problem? (A: there isn't one). Edwardx (talk) 14:34, 22 June 2020 (UTC)
  • Qualified support. I generally agree with the issues raised by the proposer. Stub tags are not particularly aesthetically pleasing, and do tend to linger after the article has been expanded to the point where they are no longer appropriate. Efforts to just find and remove them at that point become busywork. I am wondering if there is some template magic that can be applied so that stub tags on articles that are likely not stubs can turn invisible, and just show up as categories. BD2412 T 15:11, 22 June 2020 (UTC)
    @BD2412: no problem: Template magic. 10000 might be a tad much. Also you'd have to make all stub templates pass the forcestub parameter in order to be able to force the stub template on articles longer than 10000 bytes. - Alexis Jazz 01:16, 21 July 2020 (UTC)
  • Simpler solution: If you come across an article that you think is no longer a stub... remove the tag. Problem solved. Blueboar (talk) 15:19, 22 June 2020 (UTC)
    Not really - pretty much no one who would know how to do this ever looks at these articles, all xxx,xxx of them (what is the number, does anyone know?). Johnbod (talk) 21:44, 22 June 2020 (UTC)
    There are 3,399,601 stubs as of now. You can see the stats here. TryKid[dubiousdiscuss] 23:28, 22 June 2020 (UTC)
    Yikes! Over half our articles. These are project ratings though. I see 4,310 "top importance" stubs! Thanks, Johnbod (talk) 01:28, 23 June 2020 (UTC)
    I'd like to see one of those top importance stubs. To make a start I followed TryKid's link to find Category:Stub-Class_articles. From this, I selected Category:Stub-Class Accounting articles because there is a systemic bias against business articles. Accounting standard looked promising and I found that this is assessed as High importance but Stub class. This is all coming from the project template as the article page doesn't have any tags. It could use some because I immediately noticed a blatant howler, "Accounting standards were largely written in the early 21st century." What I also notice is that while its talk page only had 7 readers in the last 30 days, the article itself had 2,481. I could now tag-bomb the article but what it really needs is improvement... Andrew🐉(talk) 08:55, 23 June 2020 (UTC)
    Yeah, 3M project rating stubs. The number of "tagged" stubs seems to be 2,265,086, from Category:All stub articles. This number looks more correct since many of the "top importance stubs" aren't stubs anymore and are already detagged but the talk page wasn't updated. As previously pointed out, even many of the "tagged" stubs aren't stubs. Maybe a bot that automatically upgrades project rating of stubs to "start" if a tag isn't found on the main page is needed. Blofeld's idea of automatic detagging if the article is above a certain size was also good. TryKid[dubiousdiscuss] 12:59, 23 June 2020 (UTC)
  • Support In my early (2005) days, stub-sorting was one of my favorite hobbies, and it saddens me to finally deprecate the stub templates, but nowadays they are duplicative of the assessment templates on the talk page and thus unnecessary. -- King of ♥ 01:58, 23 June 2020 (UTC)
  • Oppose, although a possible alternative is to link the stub tags to the WikiProject banner, if the article is assessed as a Stub class a bot adds the tag, if (hopefully when) the article is upgraded to Start or higher a bot removes the tag. Cavalryman (talk) 02:19, 23 June 2020 (UTC). Amended comment to oppose retaining alternate. Cavalryman (talk) 06:55, 27 July 2020 (UTC).
    • This is a very good idea. It fixes the discrepancy between main page and talk, while keeping some level of friendly encouragement at the main page. - Nabla (talk) 14:52, 27 June 2020 (UTC)
  • Oppose While I agree that many of the problems you listed are real and affect Wikipedia, stub tags are necessary. They may not be very effective at getting readers/editors to add content to or destubify articles, but they make a vital contrast between what is and is not a reasonable length for an encyclopedic article. Most readers don’t care to browse Wikipedia’s myriad informational pages on article length, the different classes, prose, etc. Stub tags are simple, easily understood, and to-the-point. If we’re going to get rid of stub tags, why not just get rid of the stub classification altogether? It doesn't make sense. Improvements should be made, but we need them. Their importance to the project overrides any negative aspects. MrSwagger21 (talk) 02:26, 23 June 2020 (UTC)
  • Oppose per MrSwagger21. - ZLEA T\C 02:52, 23 June 2020 (UTC)
  • Comment on balancing editor and reader needs. Regarding editor needs (which we always tend to overprioritize, given the systemic bias introduced by who we are), my takeaway here is that it seems there's no evidence that the tags draw editors, and while it's perfectly plausible they do, this might be a good thing for someone to do a research study on. Regarding reader needs (which I don't see really getting proper attention here), the way we indicate article quality is a little quirky — we indicate GA/FA with a topicon, but stubs with a tag at the bottom, and nothing in between. I think there's a reasonable case to be made that stubs, given their low quality, ought to have the tags as a sort of warning. The counterargument would be WP:NODISCLAIMERS and the fact that there's a distinction between low quality and just short, and most stubs in my anecdotal experience are not lower quality than start/C class pages, just shorter. I'm not sure where I land on the necessity of stub tags, but I hope we'll consider how they impact the experience of non-editing readers, not just editors. I have brought up before that there is room for improvement in how we present content assessments to readers more generally (particularly, the difference between GAs and FAs is not made clear), and I'd like to see more work in that area. {{u|Sdkb}}talk 07:53, 23 June 2020 (UTC)
  • Oppose no. They are helpful and low-key. Not in anybody's way. Regards, GenQuest "Talk to Me" 10:47, 23 June 2020 (UTC)
  • Comment: sorry for the somewhat self-promo, but this is something that could hopefully be done with relatively little consternation were my proposal for an extension that adds categories from tags on the talk page successful. Such a move would allow the pages to retain the stub categories, without the duplication of effort in tagging the article with stub tags and also doing the assessments on the talk page. Naypta ☺ | ✉ talk page | 13:07, 23 June 2020 (UTC)
  • weak oppose for now - People I talk to (non editors) are often not aware a talk page even exists for an article. If a stub tag encourages the occasional person to add content then I see that as a Good Thing. If there were some way of showing that there was no evidence that this occurs, then I'd support their deprecation. I should add that the proposal was worth bringing up and I did consider supporting, and I do think the topic is worth exploring. Cas Liber (talk · contribs) 04:54, 24 June 2020 (UTC)
  • Conditional support. Stub templates are messy and outdated, and does not do what they are supposed to do, although they have other important uses. I suggest removing the templates, but replacing them with categories or a function within WikiProject banners. Rehman 05:21, 24 June 2020 (UTC)
  • Support - simplification is good. What stubs do can/is/should be done in a talk page banner, e.g. wikiproject assessments. Bottom line is we should have one place where we record what state an article is in, and that one place should probably be in a talk page banner. Levivich[dubiousdiscuss] 19:26, 26 June 2020 (UTC)
  • Oppose per Cas Liber. Stub tags are at worst benign. They're the literal bottom of the article and if a reader wants to ignore it, they can. I really can't understand how they can be seen as harmful. On the other hand, if they get 1 reader to help expand an article, the encyclopedia benefits greatly at pretty much no cost. They're a clear net positive. Putting them on the talk page may be convenient for us and our internal categorizations, but that's counterproductive for article improvement. Most people don't know about talk pages (seriously, ask your friends the last time they looked at an article talk page), so hiding the stub tags where only insiders will find them is in my mind a net negative. Wug·a·po·des 21:37, 27 June 2020 (UTC)
  • Oppose. Stub templates are a type of maintenance template. Because of their ubiquity, we've decided to put them at the bottom instead of the top of the page. They share all the pros and cons of other maintenance templates. One one hand, we think that – given the dynamic nature of Wikipedia – we should alert readers and editors if something is not right with an article. On the other hand, we don't know if more time is spent tagging or actually fixing articles. The main problem I see with stub templates is what others have pointed above. We have two systems to mark an artcle as a stub: stub templates and talk page banners. These are not always in synch. When this happens, the fault is with the editor who (de)stubs an article using only one method. The guideline at WP:DESTUB says to do it using both. I'm sure we're moving toward automatic article assesment (WP:ORES) at some pace. In the meantime, we should automatize getting rid of the discrepancies between stub templates and talk page assesments using a bot. – Finnusertop (talkcontribs) 23:20, 27 June 2020 (UTC)
    "we don't know if more time is spent tagging or actually fixing articles" Probably the first one, in my considered opinion. RandomCanadian (talk / contribs) 03:43, 5 July 2020 (UTC)
  • Support A good solution, as already proposed by others, would be for categorisation via wikiproject banners on the talk page. RandomCanadian (talk / contribs) 03:43, 5 July 2020 (UTC) Striking sockpuppet.P-K3 (talk) 22:47, 8 July 2020 (UTC)
  • Oppose I'm not joking in saying that this is normally how I find GAs to write. Stub tags are invaluable. TonyBallioni (talk) 02:17, 6 July 2020 (UTC)
  • Oppose I hate creating articles (for some reason), I don't think I've created an article yet. I do help massively improve existing articles, and have plans to edit a couple of stub articles and make them more full. Stubs have their benefits, help find topics that may look interesting, and give one a chance to expand them. Also, what Tony said above. ProcrastinatingReader (talk) 12:23, 6 July 2020 (UTC)
  • Comments: Leaning toward oppose, as the WikiProject placement on Talk pages make them less obvious to readers and editors, to the point that I tend to forget about them. I would also to interested to know:
    • Do all stub categories have associated WikiProjects?
    • Is if there an easy way to get a list of articles pages (as opposed to the talk pages; c.f. Category:Stub-Class video game articles to Category:Video game stubs) from the WikiProject categories?
    • Could WikiProject stubs be organized into subcategories like the stub templates?
  • Ost (talk) 22:27, 9 July 2020 (UTC)
  • Weak Conditional support. As per @Rehman above. However, few editors may still use those stub templates. If they were at the top, maybe it would be diffwerent, but I say drop them and go with what Rehman said above. --Guitarist28 (talk) 14:32, 14 July 2020 (UTC)
  • Oppose removal. I think the format of the tag should be changed, though. I am coming from the perspective of a wikiHowian, where stub tags are placed on top of stub articles. I think it would be more useful if the stub tag was in the form of other maintenance templates. Something like:

    That way, readers see what they can do to help Wikipedia. By having them at the top, readers can work on expanding the article, and then remove the stub tag once the article provides more coverage. Aasim 08:06, 18 July 2020 (UTC)
    Awesome Aasim, I like the idea of a more clear tag, although it should be ambiguous that it isn't a major issue with the article itself, and should actually encourage people to build the page, like:
    Ed6767 talk! 00:21, 21 July 2020 (UTC)
  • Comment One badly needed step would be to go thru all of these stubs & verify that they are, in fact, stubs. In my own browsing thru articles I've found that a quarter should be re-graded to "Start" or better. And about 1 in 10 of the "Start" class should be regraded as "C" or better. (Since my experience is at odds with Johnbod above, maybe my evaluation is more strict than his?) In any case, I figure re-evaluating as many stubs as possible would help reduce the number of stubs in Wikipedia to less than half the total number. --llywrch (talk) 21:52, 20 July 2020 (UTC)
    There are two types of articles here: (1) articles that have already been re-graded as start or higher, but still have Category:Stub message templates on them; and (2) articles that are classed as stubs, but really are start or higher. Hawkeye7 (discuss) 22:57, 20 July 2020 (UTC)
    Possibly, or we're looking at different articles. I feel most assessors pretty much only take length into account, whereas for some subjects a few lines might be C or even higher. The official definitions for the classes are actually pretty generous, & I think most assessors are rather too strict (as well as judging mainly on length). Johnbod (talk) 00:08, 21 July 2020 (UTC)
    Responding to both comments together. Hawkeye7 the first case could easily be addressed with a bot -- & probably needs to be done in any case -- while the second describes the phenomenon I was talking about. Johnbod I suspect we might be looking at different articles, or groups of articles. When calling an article a "stub", I look more to how completely the article covers the topic than the length -- there are some notable historical personages about whom all we can write is limited to 2 or 3 sentences, which means we are stuck with what I call a "permastub" -- although if an article is, say, 5,000 bytes in size & marked as a "stub", I'm going to look hard at why it has that assessment instead of a "start" or "C" class. And sometimes it requires expert knowledge to know what information is available about a given topic, in order to know if the article completely covers it. -- llywrch (talk) 16:55, 21 July 2020 (UTC)
    Ah, perhaps different standards then - I stand with User:Grutness/Croughton-London rule of stubs, and indeed the official definition, though of course "the breadth of coverage expected from an encyclopedia" (which stubs lack) is wonderfully vague. But most articles in most print encyclopedias would be called "stubs" by most WP assessors imo. Johnbod (talk) 17:23, 21 July 2020 (UTC)
  • While I support the idea, there are a few things we should consider:
    1. The public. Stub came to have meaning outside the editing community: The list gradually changing colour on Haskell's screen represented hundreds of women scientists who have either never had a Wikipedia entry, or whose lives and work are dismissed in a stub a few lines long.
    2. I'd favor something more descriptive, like {{Television needs production section}}. Stub tagging is kinda lazy. (guilty as charged)
    3. I very much support an experiment. I would suggest we pick a number of articles. For half of them a hash is created and only the hash is published. For the other half you remove or hide the stub tag, but don't publish a list. Sure one could look at the contributions of the bot that does it, but we can't control that. We'll have to wait until a decent number of articles on the list has been improved beyond stub status, at which point we'd publish the list of still-stubbed articles and compare.
    4. As BD2412 suggested, Template magic. - Alexis Jazz 01:16, 21 July 2020 (UTC)
  • Oppose the editors at College Football Project often use the stub tag to focus editing efforts and assist with improving articles.--Paul McDonald (talk) 13:20, 24 July 2020 (UTC)
  • Oppose removing the stub templates, they do have a function. We possibly also need to:
    1. add an option for notes to the stub template
    2. explore a way to merge the stub flagging and the assessment systems
    3. create a bot task to find stub articles that have grown / had n edits / had a change of assessment. — GhostInTheMachine talk to me 13:05, 27 July 2020 (UTC)
  • Comment - I have edited hundreds of music stub articles, mostly by adding RS to them. I find stubs useful for sorting, at least in this specific regard. Caro7200 (talk) 15:55, 29 July 2020 (UTC)
  • Support completely rethinking what stub tags are and what they are supposed to achieve, and whether they do so. As I see it, there are three things we're trying to achieve: (i) tell people that the article isn't complete (ii) ask them to contribute and (iii) we sort the stub tags so people can concentrate on stubs in an area they're interested in. Point (i) is obvious without the tag, yet it often stay s on the article long after ceases being useful. Given how long some articles remain stubs, we are obviously not doing a great job with (ii). Stub sorting has been partially superseded by wikiproject tagging and a generally much improved category system. I must admit I like the fact that stub sorters are there (tagging an article as "stub" is a quick way to get an extra pair of eyes, as it summons a stub sorter within a few hours at most). But I haven't seen any recent evidence that tagging and categorizing stubs actually leads to much improvement at all, or that the duplication of stub/non-stub tagging on article plus talk page does anything useful. Having an easy way to display article quality (not just stub/not stub status) in any category or for any link in a list would be far more helpful. Not just stubs need improving. —Kusma (t·c) 22:47, 1 August 2020 (UTC)
  • Comment I find it interesting that no one has mentioned Wikipedia: WikiProject Stub sorting, whose members might have something to contribute to this discussion (I also don't recognize any of the commenters here from the project). One of our members apparently just found this discussion yesterday (August 1) and posted a note on the WPSS talk page. I'll put my 2p in later when I have a chance to read through all the entries here. Cheers, Her Pegship (?) 20:32, 2 August 2020 (UTC)
  • Oppose: I personally bookmark several stub categories relevant to my interests and periodically expand them, contradicting the claim that stub tags "don't get people to edit stub articles". I think the only actual problem here is articles that are no longer stubs, still being tagged as such. Sometimes I'm not sure when I'm improving articles very incrementally at what point they have stopped being stubs. I would support a bot to remove outdated stub tags based on talk page assessments, or on a length barrier beyond which an article is clearly not a stub. ~ oulfis 🌸(talk) 01:11, 3 August 2020 (UTC)
  • Support Stubs are messy and the visual clutter is immense for the reader.Epelerenon (talk) 05:25, 3 August 2020 (UTC)
  • Support The stub tags are a relic of an earlier era. Now that all articles get quality ratings from multiple projects on the talk page, having them also noted as stubs on the main article page is redundant. Time spent adding tags and finding the right categories, and then the time removing them, is time wasted. CaptainEek Edits Ho Cap'n! 06:57, 3 August 2020 (UTC)
  • Oppose. While WikiProjects cover many topics, not all stub articles fall under the purview of a WikiProject, and not all the projects use assessment tags. I have no opinion on project assessment tags, but stub tags/types/cats are not only applicable and useful across the entire encyclopedia, but also a way to gauge which topics need maintenance of other kinds. (I do believe that the parameters of what constitutes a stub article should be revisited.) Last but certainly not least, the editors of Wikipedia:WikiProject Stub sorting have been faithfully maintaining, sorting, and standardizing stub types for over 15 years (that I know of), and eliminating the fruits of that work across the encyclopedia would be counterproductive. Her Pegship (?) 17:36, 3 August 2020 (UTC)
  • Oppose: I'm frequently disgruntled by tags and tag-bombing. But I find the stub tags the least-intrusive and one of the most valuable of all the tags. Bot jobs of updating either the article or the talk page when one is changed would be valuable, but the tags do help editors find stubs in a category they're interested in. The stub categories and WikiProjects don't quite align, as I'm not the first to point out, and I think this is a feature not a bug. — Bilorv (talk) 23:13, 3 August 2020 (UTC)
    Inconsistency between article page tags and talk page project tags is certainly not a "feature" - it is purely the result of carelessness/sloppiness/ignorance on the part of editors. The stub definition is general - other quality ratings may vary with the relevance of an article to a particular project, but an article should either be or not be a stub for everyone. What would be the benefit of such a "feature"? Johnbod (talk) 01:28, 4 August 2020 (UTC)
    I believe what Bilorv means by "stub categories and WikiProjects don't quite align" is not inconsistency between ratings in the stub tags and the WikiProject assessments (ie the same article being called a stub one place and start-class another, which is a "bug"), but differences between stub categories and extant WikiProjects (ie an article being tagged as '18thC-novel-stub' even though there's no wikiproject for 18thC novels). I agree with Bilorv that this second kind of misalignment is a feature and not a bug, as it is useful to have stub categories be specific, whereas wikiprojects need to be rather broad. For the Great Britain and Ireland Destubathon, for example, it was extremely useful to have stubs categorized by quite specific geographic regions, even though it would be nonsense for a whole Shropshire wikiproject to exist. ~ oulfis 🌸(talk) 19:51, 4 August 2020 (UTC)
    Thank you Oulfis, this is exactly what I meant, and apologies for the confusion. — Bilorv (talk) 20:47, 4 August 2020 (UTC)
    Ok, thanks for the clarification. Johnbod (talk) 21:07, 4 August 2020 (UTC)
  • Support. The stub tags are a subset of the project rating system (and predate projects). Several people have stated that they use the stub tags to find work to do. That's great, but they could do exactly the same thing by bookmarking the applicable project stub categories, such as Category:Stub-Class animal articles, or even Category:Stub-Class articles. As a software guy, I believe in DRY, and now that we have project ratings, stub tags violate that. -- RoySmith (talk) 01:55, 4 August 2020 (UTC)
    • The reference to DRY is amusingly misdirected. In my experience, articles don't usually get multiple stub tags but one often find a great proliferation of project tags on the talk page. and so I often use {{WikiProjectBannerShell}} to cut down on the clutter. For example, I recently updated Stonehenge which has 11 different project templates ranging from WikiProject Alternative Views to WikiProject World Heritage Sites – a project that is explicitly inactive. The various project ratings are inconsistent and there are other independent assessments too such as a Vital rating and GA review. If you want to cut down on repetitive clutter then the place to start is the talk page. Why, for example, is there not a single template for projects, which lists all the relevant projects in one combined list? Why does each project have to have its own separate template? It's not invented here, I suppose. Andrew🐉(talk) 09:59, 4 August 2020 (UTC)
  • Comment: "all articles get quality ratings from multiple projects on the talk page"? No. They don't. I sort a lot of stubs, and frequently create the talk page and add project banners. Many readers don't know much about projects, they don't belong to one but just edit their own chosen subset of articles, or perform their favourite subset of Wikignoming. If the stub categories were abolished in the belief that projects do it all, we would need a maintenance category such as "Pages (other than dab pages or redirects) whose talk page has no project banner" - and even then the pages which have {{WP Bio}} but nothing more specific would end up lost. PamD 19:02, 4 August 2020 (UTC)
  • Support - stub tags are just visual clutter. You can usually get the same information from WikiProject categories. Maintaining the same information in multiple places is a waste of time and effort (and screen space). Kaldari (talk) 20:35, 4 August 2020 (UTC)
  • Support. No longer necessary. We presumably have quite a lot of left-over functionality that's no longer needed, and this would be a good start in clearing them up. DGG ( talk ) 00:26, 5 August 2020 (UTC)
  • Strong Support - Useless garbage. Schierbecker (talk) 14:22, 5 August 2020 (UTC)
  • Oppose - The stub tags are out of the way, do not interfere with reading the article and help in categorizing and drawing attention to articles in need of more content. Removing them would be counterproductive. A better use of our time would be a bot that removes stub tags from articles that are over a certain prose size in length. Ciridae (talk) 16:30, 5 August 2020 (UTC)
  • Support. The sole potential benefit is ease of searching up very short articles to expand, and that can already be done with Wikiproject ratings. Meanwhile, I doubt readers in 2020 need stub tags anymore. SnowFire (talk) 21:39, 5 August 2020 (UTC)
  • Oppose. The stub tags are linked into other portions of the encyclopedia, and work with the Wikiproject ratings, so removing them would cause a whole set of other problems. Frankly, I like the stub tags, they definitely have encouraged some readers to positively contribute to the project. In an era when Wikipedia is losing new contributors, shouldn't we be trying to attract more? It's also not like they are taking up space on servers, and don't clutter articles as nearly as much as the issue tags at the top. Modifying those seems to be a better way to achieve what the original poster wants. User:Heyoostorm_talk! 16:26, 6 August 2020 (UTC)
  • Support — My opinion is the stubs are graffiti and serve no useful purpose. —¿philoserf? (talk) 08:07, 8 August 2020 (UTC)
  • I think I fall on the oppose side of the s-o spectrum. I don't think it makes sense to rely on WP ratings (as noted above, many pages end up with stub tags but no WP tags). For utility, I do tend to agree that the "find short articles that could use expansion" side is fairly convincing from a utility-aesthetics spectrum. I do find it a bit obnoxious that sometimes these don't match the WP ratings, but that's a job for a bot (as noted above). If I have any pain point with stub tags, it's that they basically duplicate our category structure (whether on the article side or the WP side), and could use a much smaller tree from which to select a stub tag. (I might even suggest that we should remove all sub-stub tags and put the weight on proper categories and proper WP tags; editors interested in stubs for the categories of interest can use one of our intersection tools such as WP:PetScan.) From a visibility perspective, I actually kind of like the idea of going full {{ambox}} on them.

    On a tangential note, I'm kind of saddened that so many of the calls to action are so often attempted to be hidden on the talk page, or converted to hidden categories. We want new editors and maybe the best way to get them is certainly not going to be found hidden away. (Never mind all the other ways the world has changed in two decades, like the now-60% of readers on mobile.) --Izno (talk) 22:58, 9 August 2020 (UTC)

  • Support. Mandatory reading of Banner blindness as to why those things are useless for the average reader. Popo le Chien throw a bone 18:44, 10 August 2020 (UTC)
  • Oppose deprecating stub templates. The visible part of the template is for the reader, not the editors. It sends the message that Wikipedia is not finished. It also soothes the reaction "WTH, is this all you have on the topic?" by saying "yes, we know this is incomplete". Banner blindness may apply to frequent readers, but we should also consider more casual readers. Compare {{User page}} and {{User sandbox}} which are also aimed at informing the uninitiated. Even though the call to action probably doesn't result in immediate action, it reinforces the "anybody can edit" idea. Pelagicmessages ) – (17:23 Tue 11, AEST) 07:23, 11 August 2020 (UTC)
  • Comments. Talk-page templates are suppressed on mobile, whilst stub tags aren't (though you may have to expand References or External Links, whatever the last section is). Also, it's not immediately obvious that the talk page should be where one looks for other article meta-data like quality rating. Pelagicmessages ) – (17:23 Tue 11, AEST) 07:23, 11 August 2020 (UTC)
  • Questions. If Encyclopædius and Rosiestep couldn't get consensus for a bot that directly updates stub and quality tags, how about a bot that adds them to a category for review, like Category:Not-stub stubs? Or some other interactive query? How resource-expensive is it to run an article through ORES, is the score calculated automatically on save/publish and stored with the revision, or would a bot that compares ORES scores to stub tags be costly to run? Pelagicmessages ) – (17:23 Tue 11, AEST) 07:23, 11 August 2020 (UTC)
There is Wikipedia:Database reports/Long stubs, which has been updated recently. Don't know if there's a bot that can check the entries, or if it can only be done by human. Her Pegship (?) 17:36, 12 August 2020 (UTC)
  • Support per DGG. I agree that they have outlived their usefulness. They also are a pit of make-work for gnome editors (stub sorting) who would otherwise be doing more useful things. Calliopejen1 (talk) 00:16, 16 August 2020 (UTC)
For some of us gnomes, stub sorting is the only aspect of editing WP we feel confident about. Not a reason to keep stubs...just saying. ;P Her Pegship (?) 00:52, 16 August 2020 (UTC)
  • Support There are several articles on Wikipedia, which are long enough not be a stub article, but still classified as stub. Go to While some small articles aren't classified as stub, which reduces the value of Stub tags. In less widely used Wikipedias like the Hindi Wikipedia and Bengali Wikipedia, the problem is even more pronounced, where most of the smaller articles (some with less than 100 words) are not classified as Stub, whereas some previously Stub articles, which have since been improved, still contains the stub tags. Soukarya (talk) 13:07, 18 August 2020 (UTC)
    What the Hindi and Bengali Wikipedias do with stub tags is their own business. Maybe they have rules that don't just concern article length - such as the amount of referencing, or the quality of the writing. Or maybe the person who creates these sub-100-word articles simply doesn't know about stub tags. Whatever the reason, it's nothing to do with us; we cannot tell them how to handle stub tags on their Wikipedias. --Redrose64 🌹 (talk) 15:14, 18 August 2020 (UTC)
    Yes, not many editors know how to add or remove Stub tags, what criteria must be fulfilled in order to classify some article as Stub or remove the Stub tag, which is the reason why I support the removal of Stub tags altogether. After all, the Stub tag in English Wikipedia can be very misleading sometimes (please go through this weblink, which I had already mentioned above, to view the long, well-referenced articles which are still tagged as Stubs, and most Stub tags in popular Indian vernacular language (like Hindi & Bengali) Wikipedias are all useless, and in articles where it is required, editors do not put it there. An example of sub-100-word Stub article in Hindi Wikipedia is this, which is about a popular Indian youtuber. Soukarya (talk) 15:34, 18 August 2020 (UTC)
    Hindi Wikipedia is nothing to do with us. If you want to change their practices, do so at their discussion forums, not here. --Redrose64 🌹 (talk) 17:00, 18 August 2020 (UTC)
  • No? Someone can correct me if I'm mistaken, but I believe more than half the articles on the project are stubs? So... We're going to get rid of hundreds of templates and make edits to millions of articles because?...There is a general feeling of indifference to their usefulness? Sorry. That's not a project you undertake when the main argument is "meh". If you don't like em, don't use em. No one is going to drag you to ANI because you're just not particularly into stub sorting. GMGtalk 13:34, 18 August 2020 (UTC)
  • Oppose, solution looking for a problem. Stifle (talk) 16:05, 21 August 2020 (UTC)
  • Oppose. I'm unconvinced by the arguments for. I might be convinced that the stub information should not be visible on the article page, since readers aren't going to care -- they can already tell it's a short article, without needing us to help them out. I'd also be OK with some of the other suggestions made, such as making the stub tag invisible if a WikiProject has assessed the article above stub on the talk page, or hiding the tag above a certain article size. But getting rid of them is throwing out the baby with the bathwater; there are legitimate uses for stubs which outweigh the minor benefits discussed above. Mike Christie (talk - contribs - library) 16:20, 21 August 2020 (UTC)
  • Oppose Having more than one way to group and access stub articles to work on is totally sensible, so this is a daft proposal. Removing them would only weaken the Project. That said 'stub' categorisation on an article page, whilst unnoticeable to the vast majority of readers, really does need to match with Talk page WikiProject assessments. I confess to often amending the latter, but forgetting to remove the former. If there isn't agreement for a bot to do the work of removing outdated stub tags, then at least a tool to identify the mismatch between talk pages might be valuable for some editors. Personally, what I find frustrating is to have to individually change three or four 'stub' assessments on Talk pages - one for each WikiProject, when that assessment is going to be the same across all of them. Quality assessments could really doing with being integrated so that only one needs to be changed, leaving just the 'importance' assessment to be specific to each individual WikiProject. Just thought I'd throw that out there. Nick Moyes (talk) 19:18, 21 August 2020 (UTC)  
Although in most cases they should be the same, & it is indeed a pain to have to change several, there are many cases where it is wholly appropriate to have different ratings for different projects, especially where a project only applies to a part of the subject. Obviously that is much more often the case for importance ratings, so you might well need to edit every line anyway. Johnbod (talk) 20:33, 21 August 2020 (UTC)
  • Oppose - Stubs still have their uses and as noted above they don't interfere with readers as they're directly at the bottom of articles, They're harmless and IMHO I see no valid reason to remove or deprecate them. — Preceding unsigned comment added by Davey2010 (talkcontribs)
  • Oppose. It is a long-standing policy that Wikipedia is a work in progress, and stub tags are one of the most visible reflections of that. However, there has been a trend towards intolerance of stubs, and stubs that would have been perfectly acceptable in 2006 are now routinely draftified without discussion. Stub tags serve as a reminder that stubs are a natural part of Wikipedia, and I'm concerned that removing them would further drive that intolerance. --Paul_012 (talk) 09:57, 28 August 2020 (UTC)
  • Oppose - As a user of User:Anomie/linkclassifier.js the stub tags, and the corresponding categories, are what cause these links to appear a different colour as I am browsing Wikipedia, in turn I use this to find articles that I might be interested in improving. I would not be opposed to a redesign though.CSJJ104 (talk) 14:54, 30 August 2020 (UTC)
  • Oppose – it's simply an invitation to expand the article, which is what wikipedia needs really. Removing stub notes is hiding the embarrassment that much of wikipedia has – inadequate research & topic coverage. – ishwar  (speak) 05:05, 31 August 2020 (UTC)
  • Oppose – I agree with earlier comments that stubs are useful and help encourage readers to consider expanding the article. I've also seen too many perfectly acceptable stubs get AFD'd instead of someone taking the initiative to expand them. I really like Awesome Aasim and Ed6767's suggestion above for a "friendly" maintenance tag that encourages readers to expand the article. Carter (talk) 00:29, 1 September 2020 (UTC)
  • Oppose – for five reasons: (1) I think they are useful for new editors. All that "Be Bold" stuff? I was terrified of making edits when I first signed up. I thought anything I did would get me called in front of the Wikipedia Star Chamber. But then I started seeing stubs notices on articles I was reading, actually inviting me to try to improve them. That's what got me started making (cautious) edits, to stub pages that I knew a bit about. Stub notes are invitations to new editors: "We really mean it — try to improve this article — give it a go!" (2) They're unobtrusive. Right at the bottom of the page, they don't interfere in reading the article at all. If you read that far, you get the acknowledgement that this article could be better, and the invitation to try to fix it. (3) By contrast, adding big hatnotes at the top of a page, as suggested upthread, is saying "This article is shite, you shouldn't rely on it, but feel free to try to make it better, if you can." It isn't really much of an inducement to read the article. (4) There's Talk pages? Who knew? Why wasn't I told? (5) As I've learnt more about stubs and the intricate connection with the categories, I find them very useful to see the inter-connections between different articles within the same topic, and particularly ones that need work. --Mr Serjeant Buzfuz (talk) 03:36, 1 September 2020 (UTC)
  • Oppose – this is a huge issue and should be reviewed with its long-term effects in mind. While stub tags may not be directly effective in expanding stub articles, I think that stub tags are highly useful for Wikipedia, because they create a sense to every reader that "People like you can join Wikipedia". This is a vital part of how some readers become editors, and I'd say a good percentage of editors wouldn't have joined if it weren't for stub tags or other similar tags indicating how they could help; they wouldn't have known you can edit Wikipedia. If it weren't for stub tags Wikipedia would feel more like a book than an open community, and if it didn't have this inviting feel, if the number of editors in Wikipedia reduced, then the quality of articles in general would fall. I decided to oppose instead of to wait for the survey because I think that a survey couldn't show the effects I have in mind, as they would only be felt if a huge percentage of articles were used. While it's true that stubs may remain in articles after their class has increased, this is generally not an issue for the reader, especially since in larger articles stub tags are hard to realise. They only catch your attention if you're actually looking at a stub, when they are some of the few chinks of text in that article. While destubifying may be a hustle for editors, it is a necessity which arises from a necessary part of Wikipedia's structure.

KnolGua (talk) 09:53, 2 September 2020 (UTC)

  • I have always thought that they were pointless. Support. Foxnpichu (talk) 14:43, 3 September 2020 (UTC)
  • Support. Stub tags create the impression something's wrong with the article, although it may explain the topic sufficiently for most readers. I agree with commenters on the other side that a friendly positive invitation to readers to expand or improve an article would be fine. -- econterms (talk) 01:02, 10 September 2020 (UTC)
    • Currently there exists this friendly, positive invitation on the standard stub templates: "You can help Wikipedia by expanding it." (Brevity is the soul of wit.) Her Pegship (?) 20:45, 10 September 2020 (UTC)
  • I think the problem is less to do with stub tags at end of articles than with WikiProject ratings of articles on the articles' talk pages. If one goes to the article Escape to the Country, and looks on its talk page, one will see that is of interest to WikiProject BBC, but is only rated as stub class by this WikiProject. If one reads the article, one will see it is too long to be counted as a stub. I think the problem may be less to do with stub tags than how active WikiProjects are. Vorbee (talk) 15:02, 11 September 2020 (UTC)
    • Yes, the problem has to do with WikiProjects and how active they are. But, we should still get rid of stub tags, because finding and identifing the non-stubs that have stub tags is an annoying job. Especially throughout one of the largest websites in history. It's endless. And, with WikiProjects going inactive, comes alot of stub tags on expanded pages. Arsonxists (talk) 15:18, 11 September 2020 (UTC)
  • Support To be honest, I never got the Stub rating. Half of Wikipedia articles are Stubs, so that means alot of Stub tags. Also, Removing Stub tags won't do anything to WikiProject ratings, which still have Start, C, B, and A ratings. Arsonxists (talk) 15:47, 11 September 2020 (UTC)
  • Oppose. Editors find them useful, in such a way that cannot be replaced by WikiProjects (for example, 18th century novel stubs tag is useful as there is no WikiProject for those novel articles). In addition, they are probably the biggest invitation to edit Wikipedia on articles. I probably wouldn't be here without stub tags. A redesign may be a good idea. --Danre98(talk^contribs) 03:09, 14 September 2020 (UTC)
  • Support I have manually removed stub templates from thousands of articles; they stay around for far too long usually. Also too many articles with multiple stub templates. (as a side-note is there any one-click solution for removing all stub templates from an article?) --WS (talk) 13:10, 14 September 2020 (UTC)
    • As I believe, no. There is not a one-click solution to removing that. It's a good idea, though. We should make a proposal for that. Arsonxists (talk) 14:48, 14 September 2020 (UTC)
  • Oppose per Mr Serjeant Buzfuz et al, but let's keep talking about ways to improve the template and possibly integrate better with article ratings. Retswerb (talk) 03:50, 15 September 2020 (UTC)
    • I think a way to make stubs more integrated with article ratings if the rating topicon was on every article. Arsonxists (talk) 19:24, 15 September 2020 (UTC)
      In your preferences, there is an appearance option called "Display an assessment of an article's quality in its page header". This is much nicer, as it displays the title of the article in a colour representing its current assessment. (documentation) Hawkeye7 (discuss) 19:42, 15 September 2020 (UTC)
  • To avoid confusion, I point out that the proposalisto get rid of stub tags, not to remove articles which are so short as to be stubs. I dont think anyone is proposing that. DGG ( talk ) 22:32, 18 September 2020 (UTC)

Left sidebar update follow-upEdit

Read each section for more detailed close information:
  • Introduction page: weak consensus for Help:Introduction
  • Label and tooltip: consensus for Learn to edit as the text and Learn how to edit wikipedia as the tooltip
  • Positioning: consensus for below Help
  • Current events tooltip: consensus for Articles related to current events
  • Community portal tooltip: weak consensus The hub for editors
  • Miscellaneous proposals: no consensus
There was additional discussion below that also did not resolve into any additional consensuses. signed, Rosguill talk 22:09, 21 September 2020 (UTC)
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.

Wikipedia:Requests for comment/2020 left sidebar update was recently closed by Barkeep49 and DannyS712, and most of the results have been implemented. A huge thank-you to everyone who participated! Per the close, several items require follow-up due to low participation or lack of consensus. I am opening this discussion as a space for those discussions to take place. It is being transcluded to the WP:SIDEBAR20 page and will be moved there when it concludes. {{u|Sdkb}}talk 06:47, 12 June 2020 (UTC)

Introduction pageEdit

Help:Introduction narrowly has the most support, followed by WP:The Wikipedia Adventure and WP:Contributing to Wikipedia, with a few editors opining that all of the present options are bad. Specific arguments in favor of H:Introduction were that it's easy to use, looks good, and is supported by WMF. Arguments against H:Introduction were that it's too long and that it's suppported by the WMF. Supporters of The Wikipedia Adventure argued that it's more engaging and gets people actually editing quicker (one argument that it's particularly well-suited for children seems ill-considered, as there's no reason to assume that this link will primarily be used by children). Editors opposed to The Wikipedia Adventure argue that its gamified format may be offputting to some prospective editors. Supporters of WP:Contributing to Wikipedia felt that it was a better, one-page version of the information that H:Introduction tries to communicate. Editors opposed to present options suggested that we can do better, and that we should prioritize introductions that more briefly explain what Wikipedia is. In the absence of a status quo to fall back on, the outcome of this discussion is to adopt the frontrunner, although editors can continue to workshop better solutions. signed, Rosguill talk 22:09, 21 September 2020 (UTC)
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.

The RfC found consensus to add an introductory page for new editors, but asked for further discussion on the details.


Previously discussed options: Help:Introduction (5 !votes), Wikipedia:Contributing to Wikipedia (1 !vote), and Wikipedia:The Wikipedia Adventure (1 !vote)

  • Support Help:Introduction. To put it simply, this is our best introduction. It's where the deprecated Wikipedia:Introduction now redirects and was made the primary link in the standard welcome template. It covers all the basics without going into unnecessary detail. It is mobile-friendly and accessibility-compliant. It follows the usability best practice of splitting information into easily digestible bite-sized chunks, rather than a single overwhelming page (although it has an option to be viewed as such if one wants). It's the preferred choice of the WMF Growth Team's product manager. It's being actively maintained and is overall ready for inclusion on the sidebar. {{u|Sdkb}}talk 06:47, 12 June 2020 (UTC)
Support any page that is not Help:Introduction a huge 66 page tutorial that is not user friendly. Stats show us that almost no-one is clicking the non-action action buttons to learn more so why send even more there??? . The fact someone from the WMF with less then 350 edits and zero edits in the help namespace likes the page should be a big red flag...last thing we need is another non experienced WMF member telling us what is best.--Moxy 🍁 11:14, 12 June 2020 (UTC)
The WMF Growth Team is literally the team in charge of new user retention. They're not trying to force anything on us (I was the one who sought out their opinion), but I trust that they know what they're talking about when they say We think that help pages are better when they have a fewer number of links and options -- too many can be overwhelming. In that vein, I think that WP:Contributing to Wikipedia would likely overwhelm, and Help:Introduction would be better. As for the traffic stats, most people come to the page looking for help doing a specific thing and then click on the page relevant to that. Since there are 13 pages linked, of course none individually will be getting as much traffic as the portal. There's also the general 1% rule of the internet to consider. Even the custom-designed newcomer tasks feature only results in 9% of newcomers coming back after 3 days (compared to a baseline 4-5%), so keeping them around is a huge challenge. The stats for the Wikipedia Adventure are similar, and while we don't know how many people who visit WP:Contributing to Wikipedia actually read to the bottom of the page, my guess is that it's shockingly low. {{u|Sdkb}}talk 15:25, 12 June 2020 (UTC)
Yup same team that brought us VE.--Moxy 🍁 15:32, 12 June 2020 (UTC)
The team was formed in 2018, so no. {{u|Sdkb}}talk 15:58, 12 June 2020 (UTC)
I guess I should have been more specific..old timers will understand--Moxy 🍁 17:35, 12 June 2020 (UTC)
  • Support Help:Introduction. Although I don't disagree it is quite voluminous, it covers all the necessities in a fairly well-structured manner and I used it myself for getting started.
    5225C (talkcontributions) 13:02, 12 June 2020 (UTC)
  • Support Wikipedia:The Wikipedia Adventure as I did in the previous discussion. I'm aware of accessibility criticisms and I'm even aware of data that suggests TWA doesn't improve editor retention (though I can't find the place where I read that a few years ago). However, the purpose of the link should be to get people thinking about becoming an editor—it's before the retention period, the part where we need to show them something just interesting enough to get them to make an account. I don't want another dry link with 400 subpages, none of which actually give me something to start editing or give me enough information to have my first edit not be immediately reverted. Barring TWA, I don't believe we have a page suitable for purpose but I would support Help:Introduction as a second and support any other page as better than nothing. — Bilorv (Black Lives Matter) 13:21, 12 June 2020 (UTC)
  • Support Wikipedia:Contributing to Wikipedia Its a one page, one stop wonder. Already well trafficked, lots of videos (which new users are always asking for), and long enough to be actually useful. I would also support Help:Introduction to Wikipedia, but would strongly oppose just Help:Introduction, as it is full of ...meaningless links for newbies, and already confuses folks with the VE/source distinction, and there are plenty more useful pages. CaptainEek Edits Ho Cap'n! 14:39, 12 June 2020 (UTC)

Note: An editor has expressed a concern that editors have been canvassed to this discussion. (diff)

I informed all that were in prior discussions even the ones that like your page. If I missed any fell free to inform..--Moxy 🍁 17:35, 12 June 2020 (UTC)
With 50 views a day its clear most do not send people there. The Wikipedia:Adventure has more then a 50 percent drop in views by the second page....with a loss of 90 percent by page 3. Not as bad as Help:Introduction but close.--Moxy 🍁 17:42, 12 June 2020 (UTC)
  • Support Wikipedia Adventure as I think Bilorv makes the best case. As the most prominent link for readers, we want to convert them to editors as fast as possible. For all the problems of TWA, it's best feature is that it gets readers editing quickly without having to read an entire manual. We can fix the other problems as we go along, and with added urgency given its prominent placement. Support the others as better than nothing. Wug·a·po·des 19:18, 12 June 2020 (UTC)
  • Support Wikipedia:TWA. It's where I'd send new editors, without a doubt; it's clear, concise, to-the-point, and engaging as a tutorial of how the site works technically as well as in policy, working with both in a hands-on environment. This approach is well-tested on other sites - indeed, it's what the onboarding experience looks like on many popular social media platforms - and it works in keeping people engaged throughout, making people less likely to skip the "boring policy bits" because they're actively doing something. Naypta ☺ | ✉ talk page | 19:43, 12 June 2020 (UTC)
    @Naypta, Wugapodes, Interstellarity, and Bilorv: I tried TWA recently and had high hopes for it, since the graphics are definitely nice and the interactivity is a plus. But I came away from it concluding that there are just too many problems, and those problems are too hard to address given how rigidly it's built. To list them out:
    • The JavaScript that keeps track of where you are is very buggy; several times it lost my place and I had to go back to the start of the module. Every time that happens, it's a potential exit point for someone to decide to give up.
    • It displays terribly on mobile, which loses us half of all potential editors right off the bat (and probably more in developing areas).
    • It's not accessibility-compliant, which introduces further issues of discrimination.
    • It's longer than Help:Introduction without really covering anything important that H:I doesn't, and it doesn't touch on all the most important things right off the bat the way H:I does. I don't think most newer editors will have that much patience.
    • There's no instruction on VisualEditor, and while that may not be what we all use, for newer editors it's a very important transition aid.
    • The juvenile tone seems to be okay with some people but very off-putting to others. We can be friendly without being juvenile, and I think H:I strikes a better balance.
    Putting all those together, they add up to a dealbreaker for generalized use, and they would require a ton of work to solve. By comparison, expanding the sandbox elements for H:I into something more fully interactive would not be hard (I might work on it later today). {{u|Sdkb}}talk 20:34, 12 June 2020 (UTC)
    As I said in my original comment, I'm aware of its problems. These are all things that can (and should) be fixed. Despite that, the most important function of this link is getting readers to make an edit, not teaching them rules. For its problems, TWA's really good at that. Wug·a·po·des 20:47, 12 June 2020 (UTC)
    @Wugapodes: I agree on that point. I think the very best thing is to present newcomers with easy edits to make on Wikipedia itself, since it's infinitely more satisfying to make a live edit than one to a sandbox. That's what the Newcomer Tasks feature the WMF is developing will hopefully do extremely well, and we'll want to integrate it once it goes live. For some things, though, a quiz/sandbox environment is best. I've opened up a discussion at H:I and we'll work on adding more of those features; help is welcome from anyone who wants to contribute. Cheers, {{u|Sdkb}}talk 21:25, 12 June 2020 (UTC)refactored 22:42, 12 June 2020 (UTC) to link to discussion
    @Sdkb: I think the points you raise here are definitely important ones. It ought to be possible for an interface admin to add code to MediaWiki:Guidedtour-tour-twa1.js that would automatically redirect mobile users from TWA to H:I, and for accessibility, it might be a good idea to add markup to the top of the page offering H:I as a more accessible alternative. One other option might be to have a choice - something like the below:Welcome to Wikipedia! Would you like to read a short, accessible introduction to editing Wikipedia, or learn interactively how to edit Wikipedia by taking a tour of the site?
    That could then redirect mobile users automatically to H:I as described above. Naypta ☺ | ✉ talk page | 21:22, 12 June 2020 (UTC)
    Closer's note: I had to remove a template from the above comment because it was interfering with archive templates. The code of the original comment was {{Quote frame|{{fake heading|sub=1|Welcome to Wikipedia!}}Would you like to '''read a short, accessible introduction to editing Wikipedia''', or '''learn interactively how to edit Wikipedia by taking a tour of the site'''?}} signed, Rosguill talk 22:22, 21 September 2020 (UTC)
  • Support Help:Introduction - TWA's format makes it difficult for a new editor to jump to exactly the information they need. Plus, the whole concept of an interactive "adventure" would be offputing and distracting for many newcomers. While Help:Introduction is far from perfect, it is clearly the better option, and it's a lot easier to iterate on and improve. - Axisixa T C 22:00, 12 June 2020 (UTC)
  • The proposals are dreadful—design-by-committee with every second word linked and pointless decorations. • Help:Introduction might be ok if each button led to a single page of information. However, few people want to dive into a labyrinth where you never know if you've missed vital points, and later you can never find anything you vaguely recall seeing. • WP:TWA would be suitable for, umm, certain levels of potential editors but a sidebar link should be for useful information you might want to see more than once. • Wikipedia:Contributing to Wikipedia is the best but has too much waffle. There should be a short page with core facts and many fewer links (something that can be searched after a first read), with links to the proposals here. Johnuniq (talk) 01:52, 13 June 2020 (UTC)
H:E is shorter then WP:CTW and just about additions ...not sure why so many think new editors will read over 50plus pages to learn anything considering the data we have about them ...odd very odd to me.-Moxy 🍁 12:23, 13 June 2020 (UTC)
  • Only support something that makes it clear in the first few sentences that Wikipedia is an encyclopedia based upon what reliable sources say about a subject and that editors' opinions and knowledge/expertise are not to be used. This could be followed by something short about reliable sources, being a mainstream encyclopedia and about original research. Doug Weller talk 11:15, 14 June 2020 (UTC)
  • Support Quickstart – not sure about anybody else, but I just try out my new phone, program, tv remote, without reading the manual, or only after briefly scanning it. Maybe later, after I can't turn the phone off, or find Netflix, will I go to the manual (and then, slightly annoyed that the user interface is so poorly designed, that it isn't self-evident). I support an introduction that can fit on 3/4 of a laptop page and takes about a minute to scan. As a new Wikipedia editor, I just want to edit something, anything, to see how it works, and then learn by doing; not spend time reading endless explanations, and trying to remember what I read forty pages ago, and whether that was more important. I'll get to reading all that later, after I've got some experience. Remember learning to ride a bike? The manual is for explaining how to adjust your seat height, attach a lamp, or change a tire; it's not about teaching you how to ride on two wheels. Mathglot (talk) 09:35, 16 June 2020 (UTC)
    @Mathglot: The first content page of Help:Introduction, Help:Introduction to Wikipedia, is basically what you're describing. {{u|Sdkb}}talk 10:22, 16 June 2020 (UTC)
  • Support Wikipedia Adventure great for younger editors. (talk) has made no other edits. The preceding unsigned comment from a Canadian IP address was added at 05:50, 17 June 2020 (UTC).
  • Support Help:Introduction it is easy to use and looks good. --Tom (LT) (talk) 07:41, 21 June 2020 (UTC)
  • Update: Following up for those here who haven't clicked through to the Help:Introduction discussion, we've added a slew of interactive components, including custom sandboxes, quizzes, and invitations to make easy live edits to articles through tools like Citation Hunt. We're planning on adding a few more quizzes, and as mentioned above the interactivity will get a further boost once the new Growth Team features are implemented, but I hope the present efforts will be enough to satisfy the concerns of some of those who opted for TWA above and perhaps resolve the deadlock we seem to currently be at. {{u|Sdkb}}talk 06:11, 1 July 2020 (UTC)
  • Support Help:Introduction, other pages have too many paragraphs, poor structure, and are too daunting. It keeps annoying me how we have dozens of introduction/"read this" pages, which are all so long, and then we try to create simplified versions of these but they're also so long, but also not comprehensive enough so you end up needing to read the even longer one anyway. Help:Introduction pretty much gets the point across and looks less scary. And as a sidenote, would like to say thanks to Sdkb's for their broad and important work to make Wikipedia easier to access for new editors. ProcrastinatingReader (talk) 13:04, 6 July 2020 (UTC)

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.

Label and tooltipEdit

The result of this discussion was broad support for Learn to edit as the text and Learn how to edit wikipedia as the tooltip signed, Rosguill talk 22:09, 21 September 2020 (UTC)
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.

Previously discussed label options: "Tutorial" and "Editing tutorial". Previously discussed tooltip option: "Learn how to edit Wikipedia".

  • Support Tutorial, with "Learn how to edit Wikipedia" as tooltip. The renaming of the section where this will presumably be located to "contributing" makes it clear that this is an editing tutorial, not a tutorial on how to read Wikipedia, so we should go with the shorter label for conciseness. No one has raised any concerns about or suggested any alternatives for the previously discussed tooltip. {{u|Sdkb}}talk 06:47, 12 June 2020 (UTC)
  • Support Tutorial, with "Learn how to edit Wikipedia" as tooltip per Sdkb's reasoning.
    5225C (talkcontributions) 13:02, 12 June 2020 (UTC)
    5225C (talkcontributions) 23:53, 12 June 2020 (UTC)
  • In the new condensed sidebar there's less chance of the link getting lost, but I'd still prefer something very in-your-face as a label. I like an idea alluded to by MMiller (WMF) here: "Start editing". Or "Learn to edit". (As a tooltip, "Learn how to edit Wikipedia" or similar would be fine.) As a last resort, I'd prefer "Editing tutorial" to "Tutorial". (Who reads the section title? People navigate much more non-linearly than that. I want to know what a link is the instant I look at it, no contextual clues needed.) — Bilorv (Black Lives Matter) 13:09, 12 June 2020 (UTC)
    I like "Learn to edit" a lot — it gives a nice call to action. "Start editing" would imply that you're making actual edits during the tutorial, which isn't the case apart from the sandboxes. {{u|Sdkb}}talk 16:33, 12 June 2020 (UTC)
  • Support - first preference: "Learn to edit", then "Tutorial". MER-C 16:56, 12 June 2020 (UTC)
  • Learn to edit for label since it's short and actionable; no strong opinions on the tool tip. Wug·a·po·des 19:20, 12 June 2020 (UTC)
  • Learn to edit per Wugapodes seems best to me. Tutorial isn't quite as clear - tutorial of what? Especially for an educational site, for people for whom English is not their native language, that could potentially lead to confusion. "Learn to edit" is clear in intent and action. For the tooltip, "Learn how to edit Wikipedia" seems good. Naypta ☺ | ✉ talk page | 19:43, 12 June 2020 (UTC)
  • Support "Learn to edit" with "Learn how to edit Wikipedia" as the tooltip.
    5225C (talkcontributions) 04:21, 14 June 2020 (UTC)
  • Learn to edit. Simple and straightforward --Tom (LT) (talk) 07:41, 21 June 2020 (UTC)

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.


Consensus for placement below "help" with 5 suppporting and 1 editor for above help. signed, Rosguill talk 22:09, 21 September 2020 (UTC)
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.

Previously discussed option: Contribute section, just below Help.

  • Support previously discussed option. This seems like the logical placement, and no one has raised any concerns about it or suggested any alternative. {{u|Sdkb}}talk 06:47, 12 June 2020 (UTC)
  • Support placement below Help as the logical spot.
    5225C (talkcontributions) 13:02, 12 June 2020 (UTC)
  • Above help, as the first thing under "Contribute" should be something that leads me somewhere where I will learn to contribute. — Bilorv (Black Lives Matter) 13:22, 12 June 2020 (UTC)
  • Immediately below help, please. MER-C 16:57, 12 June 2020 (UTC)
  • Below help. --Tom (LT) (talk) 07:41, 21 June 2020 (UTC)
  • Below help. ProcrastinatingReader (talk) 14:20, 6 July 2020 (UTC)

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.

Current events tooltipEdit

"Articles related to current events" received unanimous approval from four editors this time around signed, Rosguill talk 22:09, 21 September 2020 (UTC)
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.

Previously discussed options: "Find background information on current events" (status quo, 0 !votes), "Articles related to current events" (2 !votes), and "Articles on current events" (1 !vote).

  • Support "Articles related to current events", since "on" would imply that we're writing news articles, which we're not, especially in cases like recent deaths. {{u|Sdkb}}talk 06:47, 12 June 2020 (UTC)
  • Support "Articles related to current events", per Sdkb and for clarity with WP:NOTNEWS.
    5225C (talkcontributions) 13:02, 12 June 2020 (UTC)
  • Support "Articles related to current events" as above. — Bilorv (Black Lives Matter) 13:23, 12 June 2020 (UTC)
  • Per above Wug·a·po·des 19:23, 12 June 2020 (UTC)
  • Comment as previous closer: As I had indicated to Sdkb when discussing the close previously their reducing discussion to a strict vote (as indicated in the summary introduction to this section) is not consistent with policy or practice. I would encourage anyone considering a close of this section to read the previous discussion - it's short so won't take long - rather than merely accepting the !vote summary produced here as a vote summary. Best, Barkeep49 (talk) 23:14, 15 June 2020 (UTC)
  • Articles related to current events. This is a very clear description of what the page contains. --Tom (LT) (talk) 07:41, 21 June 2020 (UTC)

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.

Community portal tooltipEdit

"The hub for editors" has weak support, despite editors having mixed feelings about that tooltip in the prior discussion. No alternatives have been suggested. Given that this has already been raised for discussion twice, I think that the current weak consensus will serve for the time being, pending someone objecting strongly. signed, Rosguill talk 22:09, 21 September 2020 (UTC)
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.

Previously discussed options: "About the project, what you can do, where to find things" (status quo, 0 !votes) and "The hub for editors" (2 !votes)

  • Support "The hub for editors". This concisely sums up the portal's role. {{u|Sdkb}}talk 06:47, 12 June 2020 (UTC)
  • Weak support for "The hub for editors", since I have no viable alternative.
    5225C (talkcontributions) 13:02, 12 June 2020 (UTC)
  • Comment as previous closer: As I had indicated to Sdkb when discussing the close previously their reducing discussion to a strict vote (as indicated in the summary introduction to this section) is not consistent with policy or practice. I would encourage anyone considering a close of this section to read the previous discussion - it's short so won't take long - rather than merely accepting the !vote summary produced here as a vote summary. Best, Barkeep49 (talk) 23:15, 15 June 2020 (UTC)

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.

Miscellaneous discussionEdit

No consensus for proposals made in this section. Editors were roughly evenly divided on the suggested proposals
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.

  • There were several other proposed tooltip changes that got very little discussion and closed as no consensus. I don't want to overwhelm this discussion by creating a section to follow up on each of them, but I'll just throw them out here, and if they turn out to be uncontroversial, perhaps we can find consensus to implement them. They are:
  • For Special pages, change from "A list of all special pages" to "List of automatically generated pages for specialist purposes"
  • For Page information, change from "More information about this page" to "Technical information about this page"
  • For View user groups, change from nothing to "view the permissions of this user" (for non-admins) and "manage the permissions of this user" (for admins)
How do those sound? {{u|Sdkb}}talk 06:47, 12 June 2020 (UTC)
  • The suggested extra wording for special pages and page information does not help, the original wording is good. For user groups, I don't see why different text for admin/non-admin users is needed, just "Permissions of this user" would be fine (that's all that is needed for a hint about what groups do). Johnuniq (talk) 07:27, 12 June 2020 (UTC)
  • I concur with Johnuniq regarding special pages. Although the current tooltip is pretty useless, the proposal seems far too long. I would instead propose "List of pages for specialised purposes" to cut out some unnecessary elaboration and to clarify that special pages are for particular uses, not particular users.
    I support the proposed changes for page information and user groups, they seem to clarify their respective purposes quite well.
    5225C (talkcontributions) 13:02, 12 June 2020 (UTC)
  • I'd like "List of system pages" for "Special pages", because that's effectively what it is. Support the other suggestions. Naypta ☺ | ✉ talk page | 19:46, 12 June 2020 (UTC)
"List of system pages" sounds good to me. {{u|Sdkb}}talk 06:31, 22 June 2020 (UTC)
  • Support all three: "A list of automatically generated pages for specialist purposes" ,"technical information about this page", and "view the permissions of this user." All three proposals make it more clear and are more accurate about what the targets do. In the past I have been confused by the titles and I think these tooltips would have helped. --Tom (LT) (talk) 07:41, 21 June 2020 (UTC)

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.

Sidebar in mobile viewEdit

@Sdkb: All of the discussion on the sidebar has been about the sidebar in desktop view. I think we should also discuss how we can improve the sidebar in mobile view. Do you have any opinions on how we can do that? Interstellarity (talk) 20:49, 12 June 2020 (UTC)

Interstellarity, I think we could certainly have a discussion analogous to WP:SIDEBAR20 for mobile. My sense is that the WMF has been more heavily involved with that than they have been with the desktop view, so it might be good to start at the idea lab and research the background. There are also other discrepancies such as the fact that mobile makes it very easy to see a user's edit count whereas desktop mostly hides it; we could talk more about those at WP:Usability. {{u|Sdkb}}talk 21:32, 12 June 2020 (UTC)

Tidying up the sidebarEdit

I recently had an edit request declined at MediaWiki_talk:Sidebar#Protected_edit_request_on_12_June_2020 that should tidy up the sidebar a little bit. I think it is best that we seek consensus for this change. Pinging @MSGJ: if he would like to comment. Interstellarity (talk) 11:08, 19 June 2020 (UTC)

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.

Adding IMDb & Rotten Tomatoes ratings to article infobox (wherever possible)Edit

Currently, no (or very few) articles about films, short-films, web-series, etc. on Wikipedia contains ratings provided by prominent sources like IMDb & Rotten Tomatoes at the Infobox of the article. Many people visit Wikipedia to get all the possible information about the Film including about its Critical Reception. Most articles written about any website contains its Alexa rank. If such articles can contain Alexa rank, then I believe that articles on movies must contain their IMDb & Rotten Tomatoes ratings. Soukarya (talk) 18:11, 17 August 2020 (UTC)

For the sake of keeping separate discussions distinct, I've split this thread into subsections below. Please place further comments in those sections. {{u|Sdkb}}talk 19:12, 17 August 2020 (UTC)
The topic of this discussion has been edited to include the word 'Infobox' to avoid further confusions regarding the proposal. Soukarya (talk) 12:04, 18 August 2020 (UTC)

Survey: IMDb in the infoboxEdit

  • I don't think this is a good idea because they are user-generated data sources that are often subject to bloc manipulation so that they can't be trusted. We can't patrol these ratings, nor could we include notes alongside our inclusion of them (e.g., "This rating is known to have been manipulated") because then we're just including non-reliable data.--Jorm (talk) 18:25, 17 August 2020 (UTC)
    @Jorm: I've just created subsections to better organize this thread, and placed your comment here. Please feel free to refactor if needed. {{u|Sdkb}}talk 19:18, 17 August 2020 (UTC)
  • Hmm, I always take these ratings with a pinch of salt. IMDb ratings are representative of the people who could be bothered to vote, while ratings on Rotten Tomatoes are also subjective. It is best to stick to reviews by mainstream critics.--♦IanMacM♦ (talk to me) 18:21, 17 August 2020 (UTC)
    @Ianmacm: I've just created subsections to better organize this thread, and placed your comment here. Please feel free to refactor if needed. {{u|Sdkb}}talk 19:18, 17 August 2020 (UTC)
  • Oppose, since those can and have been subject to manipulation. See e.g. Washington Post's Trolls are doing whatever they can to bring down the 'Ghostbusters' reboot, and FiveThirtyEight's analysis of how IMDb ratings are systemically skewed toward the preferences of men. {{u|Sdkb}}talk 19:12, 17 August 2020 (UTC)
  • Oppose IMDB is a user-defined score and thus susceptible to review bombs and other factors and thus should not be considered a reliable measure. (but that's only one issue...) User review-based scores are normally not included in any article unless it is noted by third-parties (like review bombs) in the first place. --Masem (t) 19:38, 17 August 2020 (UTC)
  • Oppose per past discussions at the filmproject. MarnetteD|Talk 20:00, 17 August 2020 (UTC)
  • Oppose Including IMDB ratings in the infobox would violated MOS:FILM#Audience_response which states "Do not include user ratings submitted to websites such as the Internet Movie Database, Metacritic, or Rotten Tomatoes, as they are vulnerable to vote stacking and demographic skew." Betty Logan (talk) 23:18, 17 August 2020 (UTC)
  • Oppose Very easy to manipulate. That link shows one of my favorite YouTube videos of all time...but you wouldn't know that looking at IMDb, as you would think it one of the top rated movies on IMDb of all time, ignoring the fact that its score is a result of a bunch of YouTube watchers manipulating the score. Also, putting IMDb in the infobox would only encourage folks to use it for other things, which we are already trying to fight against, as it is not a RS. CaptainEek Edits Ho Cap'n! 21:36, 19 August 2020 (UTC)
  • Oppose IMDb is generally not a reliable source and its use should be discouraged, except in very limited circumstances. Cullen328 Let's discuss it 21:40, 19 August 2020 (UTC)
  • Oppose An unreliable source. Its use in article space should be deprecated not encouraged. --Malcolmxl5 (talk) 14:03, 25 August 2020 (UTC)
  • Absolutely OPPOSE: per all of the above. Can this be SNOW closed by someone? GenQuest "Talk to Me" 18:16, 30 August 2020 (UTC)
  • Strongly oppose for the same reasons we don't cite these. Allowing them in the ELs is quite enough. DES (talk)DESiegel Contribs 22:26, 8 September 2020 (UTC)
  • Strongly oppose per all of the above. El Millo (talk) 22:45, 8 September 2020 (UTC)
  • Oppose-0 de tutti opposi. As mentioned above, this is a bad idea on almost as many levels as possible. Qwirkle (talk) 01:05, 9 September 2020 (UTC)
  • Oppose. Never trust audience reviews. Ever. --Enjoyer of World (talk) 12:17, 16 September 2020 (UTC)
  • Strongly oppose I think this proposition was made with the right intentions, but vote surfing is a known problem on IMDB in addition to it being a user-generated site. You can leave a review without ever even watched the film and thus the review statics are pretty skewed. Inter&anthro (talk) 01:44, 25 September 2020 (UTC)

Survey: Critic review aggregations in the infoboxEdit

E.g. Rotten Tomatoes, Metacritic

  • Support adding one of these scores, since it is pertinent information for readers. {{u|Sdkb}}talk 19:12, 17 August 2020 (UTC)
  • Oppose At least coming from video games, there are far too many times that just presenting the aggregate score by itself is a misnomer of how the game's reception should be taken. The score needs to be presented alongside other reviews and comments to give it perspective. (A recent case being The Last of Us II). I am sure the same can be said for films; a critically-panned film may be an audience favor which won't be captured by a single score. --Masem (t) 19:40, 17 August 2020 (UTC)
  • Oppose per past discussions at the filmproject. MarnetteD|Talk 20:00, 17 August 2020 (UTC)
  • Oppose The infobox is for facts. Rotten Tomatoes and Metacritic are review aggregators, so their scores come with the "subjectivies" of which critics are approved and counted by them, plus every review's own subjectivity. Putting either or both scores in the infobox would give a quality of fact that they shouldn't have. El Millo (talk) 20:07, 17 August 2020 (UTC)
  • Oppose I agree with El Millo that the infobox is best reserved for factual information. The very next question in this survey (i.e. should we use RT or MC in the infobox?) undermines the argument for including an aggregator. Per WP:AGG there is no single authority on critical reception. Sometimes RT and MC can arrive at different conclusions due to their differing methodologies and sampling different reviews. Also, these aggregators don't work particularly well for foreign films (sample size is often too small) or older films (reviews are often spread out meaning a mix of contemporary reviews and revisionist ones—ideally you want to compare the initial reception with the modern day standing for a classic film). Betty Logan (talk) 23:25, 17 August 2020 (UTC)
  • Oppose We should be summarizing the assessments of professional film critics instead of allowing aggregators summarize for us. Cullen328 Let's discuss it 21:43, 19 August 2020 (UTC)
  • OPPOSE: InfoBoxes are for facts, and not necessarily all the facts, either. In fact, InfoBoxes are optional. Per CREEP. GenQuest "Talk to Me" 18:19, 30 August 2020 (UTC)
  • Oppose I don't think these should ever go in an infobox, much less "whenever possible" Too much context is needed to present such ratings in a useful way. If present, it should be in the article prose. DES (talk)DESiegel Contribs 13:34, 9 September 2020 (UTC)

Survey: Rotten Tomatoes vs. Metacritic for infoboxEdit

If we decide above to include a critic review aggregation, which service should we include?

  • I'm not ready to make a bolded !vote on this, but the factors to weigh between them are that Rotten Tomatoes is more popular but Metacritic makes better use of statistics. {{u|Sdkb}}talk 19:12, 17 August 2020 (UTC)
Misplaced !votes
  • Oppose per past discussions at the filmproject. MarnetteD|Talk 20:00, 17 August 2020 (UTC)
    MarnetteD, this is not a support/oppose section, it's an A/B question between Rotten Tomatoes and Metacritic. The section above where you already !voted is the one asking whether to include either. {{u|Sdkb}}talk 19:04, 18 August 2020 (UTC)
    • I oppose both so my previous post is correct. MarnetteD|Talk 20:02, 18 August 2020 (UTC)
  • Oppose both. Cullen328 Let's discuss it 21:44, 19 August 2020 (UTC)

General discussionEdit

Please note that policies and guidelines for this already exist. See Wikipedia:Manual of Style/Film#Critical response and MOS:TVRECEPTION as well as this essay Wikipedia:Review aggregators. The OP may not be aware that a large percentage of the film articles include RT ratings. IMDb should not be included as they are simply a fan poll and of no critical or scholarly value. MarnetteD|Talk 19:16, 17 August 2020 (UTC)

@MarnetteD: I think the OP is asking primarily about infoboxes. I just refactored the subsections to make that explicit. Sorry for doing such aggressive refactoring here; I'm trying to put this on a focused/defined path before it gets too far off the ground. Soukarya, please let me know if you have any issue with it. {{u|Sdkb}}talk 19:26, 17 August 2020 (UTC)
At no point in the OP's statement is the word infobox used. If that is what they mean then please note that this has been discussed numerous times at the filmproject and been rejected. Perhaps Betty Logan or Erik (who both have much better memories than I do) can direct you to the archived discussions. MarnetteD|Talk 19:32, 17 August 2020 (UTC)
In fact the header for the thread clearly reads "Adding IMDb & Rotten Tomatoes ratings to articles (wherever possible) (emphasis mine) so your refactoring the subheaders to add the word "infobox" is just confusing the issue. I would suggest closing this thread down as (again) policies already exist regarding this. MarnetteD|Talk 19:43, 17 August 2020 (UTC)
"Infobox" is added here. Bus stop (talk) 19:48, 17 August 2020 (UTC)
Thank you for fixing my misreading of the post Bus stop Apologies for the error. The title of the thread is part of the confusion. I didn't locate the past discussions yet but I did find this WP:FILMRATING whixh is also part of WP:MOSFILM. MarnetteD|Talk 19:54, 17 August 2020 (UTC)
Here is one past discussion Template talk:Infobox film/Archive 24#Rotten Tomatoes. Another problem is once you make room for one aggregate website then you have to keep adding them which leads to infobox bloat - a thing that is always to be avoided. MarnetteD|Talk 19:59, 17 August 2020 (UTC)
If we reach any consensus on whether to add any ratings to the infobox, then we can continue our discussion on what aggregate websites could be the most reliable ones and stick to some policy that allows ratings of only a few aggregators that would be recognised by most of the Wikipedia editors. Soukarya (talk) 12:17, 18 August 2020 (UTC)
Sorry for the inconvenience caused to you, and thanks for highlighting this issue with the title of the thread, which I have edited to make the title more informative. Soukarya (talk) 12:17, 18 August 2020 (UTC)
  • It looks like this thread isn't going anywhere, so I'm fine with it being SNOW closed. We may at some point want to discuss RT vs. Metacritic in the body, and as always there's tons of work to do to improve documentation of past consensus. {{u|Sdkb}}talk 05:52, 18 August 2020 (UTC)
    OTOH, several of these, especially IMDb, get added as ==External links== in thousands of articles. I'd rather see them in a little(!) footer bar, similar to Template:Medical resources (which normally takes up a single line on a not-very-big laptop screen, because while there are lots of options, only a few apply to any particular subject). I asked at WP:BOTREQ about this, and if we wanted to build something that would provide these external links, but take up less space than listing each as a separate item in a bulleted list, they thought most articles could be converted to the smaller format by bot. WhatamIdoing (talk) 03:51, 20 August 2020 (UTC)
I would certainly support this ^^^ as a proposal. Regards, GenQuest "Talk to Me" 18:21, 30 August 2020 (UTC)
That kind of change would need site-wide consensus, and I think it might be hard to get. DES (talk)DESiegel Contribs 13:36, 9 September 2020 (UTC)
  • I think the infobox is the absolutely wrong place for this kind of content. There might be room for a standardized template in something like the "critical reception" section to give links to Rotten Tomatoes, iMDB, Metacritic, etc. that would include aggregate ratings, but I would suggest that would be a stylistic and operational decision for WikiProject Films/Cinema/Movies/whatever. VanIsaacWScont 01:52, 25 September 2020 (UTC)

Deindexing talk pagesEdit

Should we deindex all talk pages on Wikipedia from search engines? This comes about a month after a similar (not-RfC) discussion about the potential benefits and drawbacks of deindexing some non-content namespaces. Aasim 17:23, 19 August 2020 (UTC)

To give some context: One day I was browsing my search engine of choice and ended up finding an image that was only included on a talk page. The reason why I am making this proposal is (1) we do not want inaccurate (and potentially libelous) information about a subject (be it person, company, organization, or medical topics) showing up in search results and (2) talk pages provide no help to readers whatsoever [clarification: what I mean is they do not help readers searching for a topic on Google or Bing]. I would see them as causing more confusion (even with the disclaimer) as, and I am going to quote myself here, people that check the source of [images on talk pages] will be confused that they see what looks like a weird kind of forum that only some people can comment on instead of the traditional Wikipedia article. For these two main reasons, I started this RfC. Aasim 17:29, 19 August 2020 (UTC)

Technical notesEdit

As this is now just targeting namespace:1 ("Talk:") the technical implementation would be by setting (noindex,follow) in $wgNamespaceRobotPolicies. This can be done with a phabricator request such as in phab:T104797, such a request should include a permanent link to a successful, closed community discussion. — xaosflux Talk 23:27, 19 August 2020 (UTC)

A secondary decision that can be made is if the use of __INDEX__ should be allowed to purposefully allow indexing on a page-by-page basis (this is an update for $wmgExemptFromUserRobotsControlExtra) - by default manually tagging for indexing would be allowed, but it can also be forbidden if necessary. Pages manually tagged for indexing will appear in Category:Indexed pages for tracking and review. — xaosflux Talk 23:27, 19 August 2020 (UTC)

On a related note, currently most talk pages of BLP's are noindexed by way of having a template that inlcudes the NOINDEX directive, as can be seen in Category:Noindexed pages. — xaosflux Talk 23:30, 19 August 2020 (UTC)

From below, some talk page copy-paste "archives" may not be tagged like this. A bot may be suitable for this task if wanted. — xaosflux Talk 13:09, 20 August 2020 (UTC)
The most talk pages of BLP's are noindexed by way of having a template that inlcudes the NOINDEX directive is because those talk pages transclude Template:BLP, which contains a __NOINDEX__. Conventionally, the {{BLP}} is not used directly, but is done by means of either or both of {{WikiProject Biography|living=yes}} or {{WikiProject banner shell|blp=yes|1=...}}. --Redrose64 🌹 (talk) 19:37, 20 August 2020 (UTC)
  • Something I've just observed for a new page I created is that, even though it's not listed on Google yet since it hasn't been checked off at NPP, its talk page is listed. That's definitely not what we want. {{u|Sdkb}}talk 23:49, 31 August 2020 (UTC)

Should we deindex talk pages?Edit

  • Strong oppose - Wikipedia's search tool sucks 99% of the time for specific discussion search. Googling for discussion pages is often far easier and more flexible than MediaWiki's built-in search and accepting this proposal will result in it being much harder for myself and many other editors who use Google and other search engines to find talk pages or other discussions, especially as many might not even be aware of the indexing change. Ed talk! 18:44, 19 August 2020 (UTC)
    Ed6767, I understand that Wikipedia's search may be a little unintuitive to use for searching for a specific discussion. I just voted on an MfD and learned that the page nominated for deletion, before the MfD, was showing up on search results when searching for the subject. See [1]. I do not think this is something that we want readers to see. Aasim 20:43, 19 August 2020 (UTC)
    @Awesome Aasim: To clarify, do you mean (i) that Paul A. Bonacci was showing at Google; (ii) that Talk:Paul A. Bonacci was showing; (iii) that Wikipedia:Miscellany for deletion/Talk:Paul A. Bonacci was showing? --Redrose64 🌹 (talk) 18:33, 20 August 2020 (UTC)
    Redrose64, I just did a search with Google, and sure enough, there is the talk page. Aasim 18:37, 20 August 2020 (UTC)
    @Redrose64: (ii). Regards, Newyorkbrad (talk) 18:43, 20 August 2020 (UTC)
    Per Template:NOINDEX#Warnings, major search engines should respect the {{NOINDEX}} tag, but it may take days or even weeks for content already indexed to be removed from them. In this case, the tag was added less than 24 hours ago. Ideally, that talk page should have been tagged with {{WikiProject Biography|living=yes}} several years ago. --Redrose64 🌹 (talk) 19:48, 20 August 2020 (UTC)
  • I disagree with the assertion that talk pages provide no help to readers whatsoever (emphasis in original). Stricken following clarification that talk pages provide no help to readers seeking information on a topic via external search engines. 22:03, 19 August 2020 (UTC) As a reader, I'll typically check an article's talk page if I see certain maintenance tags, principally NPOV. And before I started editing, I would sometimes go to the talk page to ask questions as an ip to seek clarity on confusing language, for example. I'm not sure if that second use case disqualifies my experience as the question I asked would technically make me an editor rather than a reader, but I've definitely found benefit in checking out prior discussions about a topic I'm unfamiliar with, even if I have no intention of ever editing the page.
No comment on the proposal itself, but User:Awesome Aasim do you think you could courtesy ping the other ten editors involved in the prior discussion you started on this page archived less than a month ago? I may be mistaken but I believe that's standard practice for RFC proposers. <3 Folly Mox (talk) 20:22, 19 August 2020 (UTC)
Folly Mox, Okay. @Ed6767, Rmhermen, Þjarkur, TheDJ, Teratix, Orangemike, GenQuest, John M Wolfson, DGG, Phil Bridger, and Schazjmd: courtesy ping. Aasim 20:31, 19 August 2020 (UTC)
Folly Mox, to clarify about the "no help" part: talk pages are really only beneficial to editors seeking to improve the article. Many readers do not seek out talk pages for sources of information. They are not going to help readers searching for a topic. I should have made that clearer in the context of the RfC. Aasim 20:33, 19 August 2020 (UTC)
I added that clarification in the "context". Aasim 20:54, 19 August 2020 (UTC)
  • Concur - the garbage content on talk pages is much higher, and stuff we would never allow to remain in an article can just lie there on a talk page, like the proverbial "t**d in a punchbowl", ready to be stumbled on by an unsophisticated seeker of information. --Orange Mike | Talk 21:08, 19 August 2020 (UTC)
  • ? Awesome Aasim the "Talk:" namespace is pretty easy to identify in your proposal, but as far as "other discussion" - how are you defining these? For example are you also proposing that the entire village pump not be indexable? — xaosflux Talk 22:47, 19 August 2020 (UTC)
Xaosflux Hmmm... for now, let's just do talk pages I guess. I'll update the header and question to clarify that. Aasim 23:26, 19 August 2020 (UTC)
Xaosflux Aasim 23:27, 19 August 2020 (UTC)
  • Support not appropriate for Google, and I think the assertion that the internal system is "too hard", etc., is nonsense; many discussion venues (such as the Village Pumps and Administrators' noticeboards, etc.) have an archive search tool, and for the rest there's Special:PrefixIndex. Anyone who unfortunately falls through those cracks can, ultimately, just "deal with it", to be blunt. – John M Wolfson (talkcontribs) 23:01, 19 August 2020 (UTC)
  • Support for talk pages per previous discussion. Oppose anything beyond that for now. Wug·a·po·des 23:09, 19 August 2020 (UTC)
  • Support honestly astonished that those were indexed to begin with. Headbomb {t · c · p · b} 23:14, 19 August 2020 (UTC)
  • Support, also for all *_talk: namespaces. I'm also surprised that these pages are indexed. Although publicly available, they correspond to behind-the-scenes discussions which most websites would keep private and which retain material that we would quickly purge from articles. Readers almost always seek an article and don't want to be diverted to discussion on how it was made. Certes (talk) 00:43, 20 August 2020 (UTC)
  • Support - somehow thought this was the case already. I know userspace isn't indexed, but in general I don't think there's a need to index talk namespaces by default (but there might be a good case for exceptions on a case-by-case basis). — Rhododendrites talk \\ 01:32, 20 August 2020 (UTC)
  • Oppose (from previous discussion): I think the negative effects of indexing talk pages are too slight to justify changing the usual practice ... I would expect users who come across talk pages in their search results will grasp their nature as discussion hubs, given the clear prefix in their titles, and adjust expectations of their content accordingly. The problem is when search engines present talk pages' content misleadingly, as in Aasim's Bing search. Bing, unlike Google, does not give an image's domain without a mouseover, and even then it ambiguously gives the chart's source as "Wikipedia" (you have to click through to see it's from a talk page). That is their responsibility to fix, not ours. If the chart's source was presented unambiguously, there wouldn't be a problem.Teratix 03:14, 20 August 2020 (UTC)
Another issue was the potentially negative impact on users who dislike MediaWiki's search engine and prefer to browse discussion archives through external engines, which, as Ed6767's comment suggests, is not an uncommon practice. – Teratix 03:19, 20 August 2020 (UTC)
Teratix it will not do to say that [it is Bing's] responsibility to fix, not ours. That something might not be our responsibility does not make it any less our problem, especially if Bing does nothing about it. We can't control what Bing does but we can control what we do. Your other arguments are sound (even if I don't agree with them, see above), but I just wanted to note and rebut that particular point. – John M Wolfson (talkcontribs) 03:57, 20 August 2020 (UTC)
Do we know for sure that Bing won't do anything about the problem if someone asked? – Teratix 02:10, 21 August 2020 (UTC)
They may or may not, but that's beside the point that we shouldn't reject an otherwise good proposal based solely or even partially on what other websites "should" or "should not" do with our pages (unless, of course, it entails a legal responsibility on their part, but I digress). – John M Wolfson (talkcontribs) 03:08, 21 August 2020 (UTC)
I don't believe it is an "otherwise good proposal"; it would have serious negative impacts on editors who prefer to use external search engines to browse discussions, as several have attested. – Teratix 03:20, 21 August 2020 (UTC)
  • Oppose People searching on Google should be aware of the context in which information is present. As noted under the technical notes section, talk pages of BLPs are already noindexed. Also, most internal pages that we don't want to be indexed such as all deletion discussions, copyright investigations, etc are already being noindexed. There's no need to apply a blanket noindexing on all talk. Google is a much more sophisticated search engine than what we have internally - if you remember someone having said something on a discussion page but can't recall the exact wording, Google search is more likely to yield the correct result than internal search. The internal search is good only for exact strings. SD0001 (talk) 03:25, 20 August 2020 (UTC)
    SD0001, I just did a check on Bing to see if Donald Trump's talk page is indexed. I discovered that only the talk page of Donald Trump is deindexed; all of the archives are indexed, which still poses a problem regarding BLPs as potentially defamatory content should not show up on any search engine rank. Something that deindexing pages in the Talk: namespace could fix. Aasim 07:24, 20 August 2020 (UTC)
    The solution to that would be to have the archiving bots apply noindexing when creating archives of a noindexed talk page. SD0001 (talk) 07:52, 20 August 2020 (UTC)
    That would kinda work if we did not have 1000000+ BLPs (and many more archives). If we had fewer archives, this would definitely be a practical solution. Adding __NOINDEX__ to the millions of archives we had (or to {{talkarchive}}) would unnecessarily waste a lot of server resources, and it would take time for the search engines to stop deindexing the millions of archives. Plus, like I mentioned above, we have libelous content on talk pages of non-BLPs and it would be impractical to try and suppress each of this libelous content. Turning off talk page indexing makes this content part of the deep and dark web. I know it may inconvenience us editors trying to find archives, but this is really just the less than 1% of all readers that go through archives. For editors it may be something to get used to, but readers could probably care less as many of them don't look at talk pages anyway. (I did not learn about the various namespaces and maintenance pages until I just happened to stumble on pages in each of those namespaces.) Aasim 15:09, 27 August 2020 (UTC)

    Adding __NOINDEX__ to the millions of archives

    There aren't millions of archives. The vaast majority of the million+ BLP articles don't have any talk archives at all.

    ... would unnecessarily waste a lot of server resources, and it would take time for the search engines to stop deindexing the millions of archives

    It would take the same time for search engines to stop indexing regardless of what method we use. As for server resources, that isn't much of a concern for us. The WMF gets millions of dollars in donations and have enough resources -- it's silly to employ a poorer solution at our end just for the sake of server resources.

    Plus, like I mentioned above, we have libelous content on talk pages of non-BLPs and it would be impractical to try and [[WP:OVER|suppress]] each of this libelous content.

    Why suppress? Simply removing will cause noindexing. It the material is that libelous, it has to be revdeled/suppressed anyway, regardless of whether the page is indexed. SD0001 (talk) 08:29, 29 August 2020 (UTC)
    Ran some numbers: turns out there exist just 13494 talk archives of BLPs. That's pretty trivial to noindex using a bot. SD0001 (talk) 16:04, 30 August 2020 (UTC)
  • Support per above. Also surprised this wasn't already the case. I can imagine your average Joe reader reacting with either disinterest or frustration when the contents of the page they were expecting to see does not match up with the contents of the page they're actually seeing. Net negative at best. -FASTILY 07:45, 20 August 2020 (UTC)
  • Strong oppose our talk pages are a valuable part of what makes Wikipedia unique. We should not be hiding it. —TheDJ (talkcontribs) 08:00, 20 August 2020 (UTC)
  • Support contra what TheDJ says above, our talk pages are too often at best embarassing and at time verging on the libelous, with doxing and sometimes unacceptable insults. I can point to at least one talk page which consists only of insults and rants. Our internal engine does work. Leaving defamatory content open to the public is IMHO unacceptable. Doug Weller talk 08:53, 20 August 2020 (UTC)
  • Strong oppose - I don't agree that talk pages aren't useful as a search result, both for readers and editors. Benjamin (talk) 09:55, 20 August 2020 (UTC)
  • Oppose When a reader lands on a talk page by accident, they will quickly see that it's not a normal Wikipedia article, as posts are signed, there are people replying to each other, &c. I think we can trust the reader to understand that it's a discussion page. If they were just looking for the article, there's a link at the top, which I think they will quickly find. Furthermore, as xaosflux pointed out, the template "BLP" contains __NOINDEX__, so libel is not really a concern. Talk page discussions can be pretty interesting, so I do think reader value would be lost if we deindex the entire Talk: namespace. PJvanMill)talk( 11:26, 20 August 2020 (UTC)
  • Oppose Search engines already employ sophisticated algorithms to help their users find what they want. Our talk pages are public and open to all, rather than being private and privileged. It may be that they are exactly what the searcher is looking for. We should leave such decisions to searchers and the providers rather than second-guessing them and pre-emptively censoring everything. If there's a problem, it's that our talk pages are too little understood and used. This proposal would make matters worse. Andrew🐉(talk) 13:50, 20 August 2020 (UTC)
  • Support Talk pages may be interesting but they are not the Wikipedia Content. The articles are the content, all the rest exists to support the process of making the content. — GhostInTheMachine talk to me 15:17, 20 August 2020 (UTC)
  • Oppose Talk pages are hidden enough, but are a fundamental part of Wikipedia. I don't think they should be hidden further, it's better just to remove problematic content as you see it then to implement this blanket proposal. Thanks. Mike Peel (talk) 16:09, 20 August 2020 (UTC)
  • Support While I get the "our search is insufficient" arguments (though I don't necessarily agree with them), I think about the number of BLP violations brought to talk pages in order to demean article subjects and then the idea of them showing up in search results? That makes my skin crawl.--Jorm (talk) 18:38, 20 August 2020 (UTC)
  • Comment - Special:PermaLink/862856598#Prevent new users from allowing search engine indexing of user pages caused spam in userspace to halve overnight. I am not aware of any systematic spamming in the talk namespace. MER-C 19:08, 20 August 2020 (UTC)
  • Oppose until such time that the MediaWiki search engine is significantly improved. (talk) 22:36, 20 August 2020 (UTC)
  • Support Talk pages could confuse readers. Depending on a user's search, the search engine might pull up a talk page (no search engine is perfect). P,TO 19104 (talk) (contribs) 23:03, 20 August 2020 (UTC)
  • Strategic support, with my actual !vote being an abstention because I'm not an expert on search engine results and thus feel WP:UNQUALIFIED to weigh in on the all the potential ramifications of this. But from the !votes above, I'm concerned that some editors are prioritizing their own desire to be able to search for pages on Google rather than putting the WP:READER first, so that pushes me into a strategic support to counterbalance. I find the support arguments above that talk pages are not part of the encyclopedia proper (as ill-defined a concept as that is at WP) and thus should not generally be appearing in Google search results persuasive. {{u|Sdkb}}talk 02:39, 21 August 2020 (UTC)
How does talk page indexing hurt the reader, and why should only pages part of the "encyclopedia proper" be indexed? – Teratix 03:20, 21 August 2020 (UTC)
Teratix, plenty of the support !votes here have made arguments as to why that would be, and why we wouldn't want internal pages appearing in Google results. I expand on my views about reader-facing vs. non-reader facing parts of Wikipedia here—part of what it boils down to is that we need to be able to distinguish between the product we work to create (an encyclopedia) and the efforts that go into creating that product. Going back to WP:Reader, the view I hold most strongly here is just that it's not appropriate to be !voting taking into account only or primarily our own desires to be able to find the internal pages that heavily concern us but don't 99% of Wikipedia's users, since we're not making Wikipedia just for ourselves but for the world. At least some people above very clearly seem to be centering their own needs rather than readers', thus my !vote. {{u|Sdkb}}talk 00:24, 22 August 2020 (UTC)
From what I've seen so far, supporting arguments boil down to vaguely waving at the possibility of reader confusion and the possible presentation of libel and misleading information. However, they have not presented any evidence that this is a significant problem, beyond a couple of isolated instances. The "reader-facing" and "non-reader facing" distinction is an interesting point (though I would dispute that talk pages would be non-reader facing), but merely invites another question – why should non-reader facing pages be deindexed? Finally, it's a bit disingenuous to assume opposers are only taking into account their own experiences. Perhaps they have merely found that whether or not talk pages are indexed has little impact on readers' experiences, and so have not included this consideration in their comments. – Teratix 02:06, 23 August 2020 (UTC)
I don't think the BLP concerns here are insignificant or restricted to isolated instances. We routinely have discussions on BLP talk pages over whether to include or exclude sensitive information that may affect privacy. We are a top ten website in the world, so anything we publish here, even on our talk pages, has the potential to expose the content to significantly more people than if we hadn't published it. Take Talk:2020 Twitter bitcoin scam#Premptive caution, which is a discussion that happened just a few weeks ago over whether we should name a 17-year-old who has been accused of committing a notable cybercrime. In the discussion right now, someone has pasted a link to the website of an obscure state county court with instructions on how to access court records. Yes, the information is technically public, but we have increased the exposure of the information by including it here (and it would be a violation of WP:BLPPRIMARY to depend on court records as the sole source for any BLP content). In other words, we are too lenient about what we tolerate on talk pages in routine discussions to make it a good idea for talk pages to be indexed. Mz7 (talk) 06:17, 23 August 2020 (UTC)
Since the link was posted on 1 August, the article has been viewed about 30,000 times, but the talk page has been only viewed 181 times. I'd say not everyone who viewed the talk page actually clicked the link (quite a few viewers are likely just there for editing purposes); the number of people who visited the talk page, scrolled to the bottom, clicked the link, actually searched for the record and would not have otherwise had the desire and ability to find it would be few to none. (And the amount who found it because the talk page was listed in search results would be even smaller) – Teratix 04:54, 24 August 2020 (UTC)
  • Support, and I'm also surprised this isn't the status quo. We are quite a bit more lenient with the kind of information we allow to stay on talk pages versus in the mainspace, particularly with respect to WP:BLP content. For example, we might use the talk page to discuss whether certain borderline information constitutes a BLP violation (e.g. victim names, crime allegations, full names and dates of birth, etc.), and even if the consensus is to omit the content from the article, in general the content remains visible on the talk page, which is problematic if readers can happen upon it via a Google search. The alternative would have to be to more liberally apply courtesy blanking to such discussions, which isn't routinely done today. I find the argument about MediaWiki's search function unconvincing; we can certainly live without Google search for talk page archives, especially at the benefit of reducing the probability that a reader will stumble across content that is not intended to be reader-facing. Mz7 (talk) 05:32, 21 August 2020 (UTC)
  • Support: Talk pages are internal discussions for the intended public-facing article namespace. There's an awful lot of inappropriate content contained in Talk space that has no need for beingindexed on external search engines. One also can't expect all users of search engines to understand how Wikipedia works and that the Talk pages can contain user-generated nonsense that would otherwise violate Wikipedia policies in articles. — MarkH21talk 06:21, 21 August 2020 (UTC)
  • Support: Wikipedia:Administration..." administrative namespaces are used to assist the building of content and should be seen to be mutually exclusive of content pages, except for cases where a linkage is required. In other words, administration pages should be in the background and not visible to the reader."--Moxy 🍁 10:11, 21 August 2020 (UTC)
  • Oppose, because talk pages are a very important part of our processes and shed light on our content. Everyone gets dumber if they get ignored. Nemo 11:08, 21 August 2020 (UTC)
  • Oppose I can't speak for other users, however I use a search engine (Google, in my case) to find talk pages. The search engine is just much more effective than Wikipedia's search bar, and I would have a lot of difficulty finding discussions if they weren't indexed. However, I recognize that this discussion is about the WP:READERs, not the users. As far as that is concerned, I don't really see the harm of keeping them indexed. Anyone is free to view the behind the scenes work that goes into each article, and I think it gives Wikipedia more credibility when people are exposed to the endless discussions that have helped build and maintain the articles that they read. The OP mentioned that readers may be confused by the talk pages that they encounter in search engine results. This may be true (and I'm not convinced that it is), but it is irrelevant. Not knowing what the talk page is doesn't make it any more difficult to read articles that they encounter. It just means that they'll click the link, see it isn't a regular article, and leave. It doesn't hinder the experience of someone that went straight to an article from the search engine results. --PuzzledvegetableIs it teatime already? 13:29, 21 August 2020 (UTC)
  • Support. I agree that the internal search engine is terrible. But Wikipedia is in the real world. The targets of libel don't care about our ability to find old talk page discussions. Yes, most BLP talk pages are noindexed, but the archives aren't, and libel can occur on non-BLP talk pages, too. Suffusion of Yellow (talk) 20:41, 21 August 2020 (UTC)
  • Support I think many people here assume too much of the casual reader. When people look up Paul A. Bonacci and click on the link (as two thousand have done in the last 30 days) and find as the first sentence is "This is a real case. Paul is a real person. This case needs to he heard, it is the 1st pizzagate. If you find yourself here, don't stop...keep digging, it's all there" Wikipedia itself is essentially spreading misinformation; our reputation as a trusted source is hurt every time this happens even though a select few readers may accurately surmise the purpose of the page. Our goal is give the public access to the world's knowledge, not to give editors a marginally more convenient searching tool for the talk namespace, and most certainly not to actively mislead them by linking to pages that are not part of the encyclopedia with content that is presented in a somewhat similar format to an article that violates all of Wikipedia's pillars. For the reader's sake, talk pages should not show up on google. Zoozaz1 (talk) 03:39, 22 August 2020 (UTC)
  • Oppose. Andrew Davidson hits the nail on the head with: If there's a problem, it's that our talk pages are too little understood and used. I'm not convinced like some of the opposers that a reader stumbling across a talk page will immediately understand what they're looking at. Our methods of discussion threading are now 20 years behind the times. But it should be easier and more common for a reader to find themselves on pages that are not articles. Someone finding a talk page could be a gateway to them learning more about what Wikipedia is and how it works. Readers should not believe that they are looking at a website of factual content that magically appears or has existed for all time, but an unfinished, imperfect work with a provenance that is constructed over time by collaboration and communication. Every editor is already a reader, but every reader should be an editor (if only in the sense that they know how to correct a typo or remove vandalism or falsehoods if they see it). — Bilorv (talk) 20:02, 22 August 2020 (UTC)
    • Bilorv, I agree that we are kind of behind in terms of talk pages and usability. I also agree that a reader that wants to know how Wikipedia works can view talk pages. It is important to remember that no page on Wikipedia is entirely private; we do have a few private wikis and the MediaWiki software does allow for hiding of pages, but none of those features are enabled on the English Wikipedia. Readers can still view discussion pages by clicking on the "Talk" or "Discussion" links at the top of every page. But even then, most readers are not super interested in how Wikipedia runs. And if they are, they can view our policies, guidelines, etc. and our tutorials themselves and/or try to make edits themselves (and get guidance). But most readers searching for topics on Google or Bing are not looking for talk pages, though. Aasim 08:53, 23 August 2020 (UTC)
  • Support The mainspace itself has its fair share of defamatory bias and POV commentary, but talkpages have even less control. And there are millions of them. Junkyards have a fence for a reason. --Pudeo (talk) 23:44, 22 August 2020 (UTC)
  • Support I remember once reporting a BLP concern and one reason (there were others) not to remove it was that it was on the talk page. We let more slide in this space than on others. If an editor is looking up an article on google they are looking for the article on google, not the behind the scenes process that led to that article being made. While we should not hide how we make the sausage, we don't need to send people looking for a butcher into the meat works. AIRcorn (talk) 02:22, 23 August 2020 (UTC)
  • Strong SUPPORT: The reader doesn't need to see how the sausage is made. Active editors know how to find the "talk" info they seek. GenQuest "Talk to Me" 16:59, 24 August 2020 (UTC)
  • Support' The process of how articles are improved is internal to the project, and, while public, should not be advertised to search engines more than necessary. Strangely enough, I can't remember having received talk page hits searching Google until recently, so I was living under the impression this would be the default already. --Matthiaspaul (talk) 18:45, 24 August 2020 (UTC)
  • Strong oppose - it is better to find things than to hide things. EllenCT (talk) 01:37, 25 August 2020 (UTC)
  • Oppose They're already not ranked very highly, and it's useful for people who want to be able to search them in particular with a better search engine than ours. Jackmcbarn (talk) 05:58, 26 August 2020 (UTC)
  • Mostly ambivalent, but on balance oppose per Jack. Really the argument in support is that talk pages are not helpful to readers and may contain completely false content (which is true), but indeed, they're not indexed very highly and the typical reader is unlikely to stumble across them by accident. There is a reason to keep them indexed, however, and that is (to be frank): MediaWiki's search can suck. ProcrastinatingReader (talk) 20:36, 26 August 2020 (UTC)
  • I'd support this if there was a reliable alternative way to find talk page consensuses, but there isn't so I've got to oppose it.—S Marshall T/C 13:01, 27 August 2020 (UTC)
  • Support If people want to see why we put something, then the talk page isn't difficult to find. However, I don't want server resources to be heavily wasted on this; I don't know much about computing but if it possible to set a limit on how much RAM(?) it is using to not slow down the website, that would be optimal. ping me when responding, gràcies! TheKaloo talk 23:35, 27 August 2020 (UTC)
  • Oppose per others above who have pointed out that external search engines are often critical for editors trying to identify old discussions. --Paul_012 (talk) 09:43, 28 August 2020 (UTC)
  • Oppose I think our readers are quite interested in the process of how articles are written. Comments on Talk:Kamala Harris made the news just two weeks ago, and that's only one of many articles on how Wikipedia handles current events which extensively cites talk page discussions (see [2] [3] [4] for a few more recent examples]). xkcd has done multiple comics satirizing talk pages. Making it harder to find talk page discussions and see how an article's content was formed makes Wikipedia less transparent and does our readers a disservice. TheCatalyst31 ReactionCreation 15:20, 29 August 2020 (UTC)
    I disagree. It is still possible to find talk page discussions by clicking on "Talk". Those that want to find talk pages can still use the extremely rudimentary "MediaWiki" search, which is pretty dated compared to modern search engines, but still usable. And as mentioned above, Talk:Kamala Harris is already deindexed. That means that major news publications like The Atlantic had to use MediaWiki's search anyway. Aasim 19:24, 29 August 2020 (UTC)
  • Support Talk pages are part of the internal discussion process, which is not, I believe, what readers are looking for. They are also more prone to abuse. While patrolling recently created talk pages without an associated article, I have seen several talk pages being used to create spam and attack pages to avoid detection, sometimes after the associated article got deleted and salted. These pages were then, as expected, still ranked highly in search results. - Flori4nK tc 22:00, 29 August 2020 (UTC)
  • Support Talk pages are part of Wikipedia's internal discussion process and hence it would be better if they are deindexed.Pharaoh of the Wizards (talk) 04:03, 1 September 2020 (UTC)
  • Oppose On balance, moving in the direction of less transparency seems bad to me. Running a bot to add a NOINDEX to all BLP Talk pages and their archives sounds pretty trivial, and that would adequately cover the privacy/libel concerns, in my view. Old archives slipping through and remaining indexed, an incident mentioned above, is a reason to tag more thoroughly, not to de-index the whole space. XOR'easter (talk) 18:47, 1 September 2020 (UTC)
  • Opposes general deindexing. Support BLP deindexing as a compromise. Complete deindexing reduces usability for editors, as the media wiki search is very poor. pburka (talk) 20:04, 1 September 2020 (UTC)
  • Support as content in talk pages could include false information, copyright violations, and all kinds of other content that is part of the sausage making of an open encyclopedia, but not the vetted content itself. People certainly can still find this information via WP's interface, but we don't need to promote it externally. --ZimZalaBim talk 00:27, 3 September 2020 (UTC)
  • Support, content in talk pages is not usable to search engine visitors, as described above. We should be trying to keep random people away from talk pages as a matter of privacy. Swordman97 talk to me 05:35, 3 September 2020 (UTC)
As a sidenote, deindexing talk pages will not lead to "less transparency". Talk pages are one of the first things you learn about when you become an editor, so it isn't that hard to find them at all. Swordman97 talk to me 05:40, 3 September 2020 (UTC)
  • Support. Users who are interested in the discussion are going to find the talk pages. The content of talk pages is for internal consumption and does not need to show up in search results. And the OP's comment on the sort of harmful content that might appear on talk pages is significant. If the problem is that the internal search engine is crap, then we should improve the internal search engine. Kahastok talk 20:40, 3 September 2020 (UTC)
  • Oppose Wikipedia's search function is fairly terrible for "fuzzy" searches, and makes searching anything other than articles onerous and unintuitive. I have often had to use Google to find a talk page discussion that I couldn't find with Wikipedia's search tools. --Ahecht (TALK
    ) 14:17, 4 September 2020 (UTC)
  • Oppose, we should keep as much searchable as possible. While MediaWiki search has improved a lot in the past 10 years, there is too little gain from this proposal for the inconvenience to editors that it adds. If necessary, use targeted deindexing. —Kusma (t·c) 09:54, 8 September 2020 (UTC)
  • Support – Talk pages contain many serious violations of BLP that are left unchecked and unverified. Allowing a page like Talk:Ilhan Omar to be indexed is irresponsible on our part. All talk spaces should be deindexed. This issue is not limited to pages that are themselves BLP. All talk pages are vulnerable to this BL issue and COPYVIO issues. --- C&C (Coffeeandcrumbs) 05:43, 10 September 2020 (UTC)
  • Oppose - the material needs to be searchable. That there are serious violations on the talkpages of BLPs, copyright violations, or other harmful content is a red herring: it is there anyway, whether or not people find it on Google. If it is a problem it simply needs to be removed and possibly even revdelled/oversighted. --Dirk Beetstra T C 13:55, 10 September 2020 (UTC)
  • Oppose as a solution looking for a problem per Beetstra. OhKayeSierra (talk) 12:51, 11 September 2020 (UTC)
  • Oppose for reasons expressed elsewhere by Andrew Davidson, Jackmcbarn, Nemo, and especially ProcrastinatingReader - namely, that the reality is that talk pages are already ranked pretty low in the vast majority of search results, and you often need to be deliberately looking for them in order to show up at all. The question of which page to direct searchers to is one for the search engines, who have pretty sophisticated methods for determining this, not us simply because we don't feel it's our best work. Many here are comparing the talk pages to an outdated, niche forum, which isn't entirely inaccurate. But the reality is that there are plenty of times when I've been using a search engine and wanted to find information others have posted on forums. Search engines don't exist just to point users to articlespace-quality results, and we should let the decision of what to look for lie with the users and the search engines, rather than decide for them. They're generally doing a fine job not giving too much prominence to talkspace anyway. (This discussion has served to bring up a good concern about BLP archives however, which I would support using a bot to automatically noindex given the additional special considerations there.) MarginalCost (talk) 04:20, 17 September 2020 (UTC)

Discussion (Deindexing talk pages)Edit

For one thing, I see that those that support deindexing talk pages seem to suggest that the Talk: namespace is not part of the encyclopedia proper and is often littered with inaccurate, defamatory material. For another thing, those that oppose seem to suggest that the MediaWiki search engine is poor compared to Google and Bing. Is there a way where we can figure out a solution that keeps talk pages hidden for readers but visible to those who are looking for them? Aasim 03:53, 9 September 2020 (UTC)

Is there a way someone could find it only if they use site-specific searching? Meaning that they write as part of the search. El Millo (talk) 04:03, 9 September 2020 (UTC)
That is what I am wondering. If there is a way to make talk pages hidden when doing a generic search (like "cars") and visible when doing a specific search (like " cars"), that would be great. Aasim 04:16, 9 September 2020 (UTC)
That's already what happens in practice. The main namespace has most pagerank etc. The fact that you can find a page in an external search engine when looking carefully for it doesn't mean that it would be normally displayed in search results. Deindexing seems to be a solution in search of a problem, until someone shows statistics of the real impressions and clicks of said pages in search engines. Nemo 18:40, 9 September 2020 (UTC)
I found Bing's search result removal policy: [5] According to them they will remove search results either from legal requests or through content control systems. Maybe read the page; do talk pages contain any of the following: copyright infringement, spam, sensitive personal information? The answer: it can have any of three at once.
Google says that it would be best to Contact the owner of the website to have personal information or copyright violations removed from the site. Basically, Google is putting the onus on us to make sure that our pages do not have bad content. Just putting the information out there. I am not sure about how likely this RFC is going to pass because there does not seem to be any consensus for or against. But hopefully we can work out a compromise that works for both readers and editors alike. Aasim 19:44, 15 September 2020 (UTC)

Displaying A-class topiconsEdit

Hello everyone, my name is Rebestalic

In short: Should we display A-class topicons for A-class articles?

The display of these topicons is inconsistent--before I entered into an interesting discussion with J Milburn, Nina Simone and the Battle of Pusan Perimeter had it on beside their Good Article topicons, while A-classers without the topicon included the one for the Atomic bombings of Hiroshima and Nagasaki.

J Milburn, who is a broom (REBESTALIC IS A TOADY ALERT), mentioned that he was 'not aware of any policy or guideline recommending their inclusion'. Perhaps now would be the time to make such a policy?

🤔 Rebestalic[leave a message....] 00:43, 27 August 2020 (UTC)

J Milburn, who is a broom (REBESTALIC IS A TOADY ALERT) What? ST47 (talk) 05:02, 27 August 2020 (UTC)
I believe this is a bit of light humour referencing J Milburn's administrator status. – Teratix 05:45, 27 August 2020 (UTC)
As a quick bit of background -- I came across an A-class article with a "topicon" by chance and removed it. I later checked, and found about 15 articles had A-class topicons, and removed them all. These articles were mostly military history, but there were a few of others, including one that decidedly was not A-class. Featured articles, featured lists, and GAs routinely have topicons. Off the top of my head, when we introduced topicons for GAs -- it was in my memory, but not that recently -- there was a centralised discussion about it. I don't have a very strong opinion about whether A class articles should have topicons (I lean against, simply because A class is not as centralised or codified as FA or GA, at least as far as I can see) but I don't think they should just be added in by a few editors who'd like to see them. If it's going to happen, there needs to be a central discussion about it. If this is that central discussion, so be it. Josh Milburn (talk) 07:26, 27 August 2020 (UTC)
@ST47: My apologies for not being as clear as I could be, Teratix is right with my horrific sense of humour Rebestalic[leave a message....] 21:22, 27 August 2020 (UTC)
  • Lean support although I have my doubts w/r/t decentralization. – John M Wolfson (talkcontribs) 23:58, 27 August 2020 (UTC)
  • Comment: Apart from MILHIST, what other projects actively conduct A-class reviews? Are the qualities of their A-class articles comparable? They should be if a topicon is to be consistently displayed for all such projects. Otherwise, approval could be on a project-by-project basis. --Paul_012 (talk) 09:38, 28 August 2020 (UTC)
Hey Paul 012, I actually asked a question about this just after I joined Wikipedia! It was at the Teahouse, and the replier directed me to the A-class articles category. I had a look at it just now, and it was mostly just empty categories. I haven't the faintest clue which category Nina Simone fits into, because I don't suppose she had much to do with military history
Consider the Grades section of the content assessment page though; on the column with the class codes, the Featured Article, Featured List, Good Article and A-class fields all have their topicons beside, while all the poorer-quality classes (like B- and C-class) don't. I wonder why there's no such thing as a 'Good List' as well? But thank you for giving your opinion to my thread! Very exciting for me Rebestalic[leave a message....] 11:10, 28 August 2020 (UTC)
  • Lean against - I prefer only having the plus/star, based on proper, centralised, peer review. For A-class to work, we'd have to review each project that wanted to offer them and decide that the project had a good enough system to handle that review, probably with a delisting process external to that project. Nosebagbear (talk) 14:23, 30 August 2020 (UTC)
  • Comment: We need to figure out, at a fundamental level, what it is we're hoping to achieve by having A-class as a designation before we can answer this question. I'm not sure we can even agree on whether A-class is higher or lower than GA, let alone expect readers coming across the topicon to be able to distinguish it. Has there been talk (other than my brief question here) about deprecating A-class and making review of military history articles some sort of subtrack within GA?
That said, generally speaking, I support (as I have in the past) making article ratings more available to readers. It's important for maintaining trust that we make it clear which parts of the encyclopedia they can generally trust and which are still under construction The stumbling block is making sure that ratings are accurate enough, and there's issues particularly with the ratings in the middle of the spectrum. {{u|Sdkb}}talk 20:51, 3 September 2020 (UTC)
  • Lean oppose. While receiving an A-class assessment is a good indication of article quality, it's not the product of any uniform or standardized peer-review process. It has a place (the article's talk page), but it's different from GA or FA in the sense that it (like every Wikiproject assessment) is completely localized. It shouldn't be elevated to the same place as a community-wide designation. -- ExParte talk 16:19, 5 September 2020 (UTC)
Changing my !vote to lean support.. While I do still have some misgivings about elevating something w/o a uniform standard like an A-class rating, WikiProjects are probably best qualified to assess the reliability of an article within their purview. And when an article receives that designation, it's a useful thing for a reader to be aware of so they can consider that when determining how much to lean on it. -- ExParte talk 07:56, 9 September 2020 (UTC)

Thanks for your contributions here, Ex Parte! Rebestalic[leave a message....] 01:51, 11 September 2020 (UTC)

  • I am not aware of any A class processes outside of MilHist. Are there any? If they were equivalent to what MilHist does I'd be open to this idea. If it's only MilHist that has an active process I'm opposed. Best, Barkeep49 (talk) 00:42, 24 September 2020 (UTC)
    Video games deprecated theirs in favor of GA, and I would guess most other WikiProjects basically never had an interesting/relevant A-class assessment. Looks like mostly MILHIST and Hurricanes with functioning A-class systems. --Izno (talk) 01:29, 24 September 2020 (UTC)
    Wow, so we really have an entire class that's functionally reserved for just two projects? If this were anywhere but Wikipedia, A-class would have been deprecated long ago. {{u|Sdkb}}talk 02:36, 24 September 2020 (UTC)
    There are have been previous discussions. The biggest reason why not is because the quality level allows WikiProjects to assess things as the best that WikiProject has to offer (rather than as the community has to offer). Ostensibly, it's also to indicate a different focus from what GA/FA have to require. Lastly, they are good stepping stones for the two projects to get their quality up on the different interests that GA/FA have. I don't see a fundamental issue with leaving the systems in place if it's working for those groups. --Izno (talk) 02:48, 24 September 2020 (UTC)
    Projects with A-class articles include Military History (629), Cyclones (133), US Roads (22), Chemicals (8), Cars (7), Japan (7), Carnival (3) Lebanon (2) and Science Fiction (2). While about three quarters belong to the first two, there are another 250 or so scattered across dozens of projects. Hawkeye7 (discuss) 03:10, 24 September 2020 (UTC)
  • Solid oppose. This classification is specific to the WikiProject and is not representative of the community review processes that GA and FA provide. (And, the categorization is basically-unused outside two particular projects.) --Izno (talk) 02:48, 24 September 2020 (UTC)
    FA does not provide this, so A class is the highest review process we have. Hawkeye7 (discuss) 03:10, 24 September 2020 (UTC)
  • Oppose since it's only really used by one project. It would be better to find some way to map MilHist's assessments onto those used by the wider community (e.g. providing a process to automatically recognise MilHist's A-class articles as GAs). – Joe (talk) 10:04, 24 September 2020 (UTC)

Migrate some uses of Template:Commons to Template:Commons categoryEdit

Hi all. We have {{Commons}} that provides general links to Commons and {{Commons category}} that links specifically to Commons categories. When used without parameters, {{Commons}} links to Commons search pages; when used with a parameter it uses that parameter to link specifically to that Commons gallery or category. Meanwhile, {{Commons category}} when used without a parameter uses Wikidata to link to Commons categories (where they are defined through sitelinks on Wikidata) or the named parameter where that is provided (which is cross-checked with the Commons category sitelinks on Wikidata to add it to tracking categories).

I would like to bot-migrate uses of {{Commons}} to {{Commonscat}} in circumstances like these:

  1. {{Commons}} is used without a parameter (= links to the search page) but a Commons category is sitelinked to the page/category
  2. {{Commons}} links to a Commons category
  3. {{Commons}} links to a non-existent or redirected gallery but a Commons category is sitelinked
  4. Optional: if {{Commons}} links to a non-existent or redirected gallery, with no Commons category, then a) the link could be removed or b) the parameter removed..

This could be done as a one-time run or run regularly to catch new cases. There are currently ~65k uses of {{Commons}} (compared with ~780k uses of {{Commons category}}). If this is OK, then I can submit a bot proposal - I already have semi-automated pywikibot code to do this that I can easily convert to a bot, I have been running it interactively in the last few days but given the number of cases and high accuracy rate this is probably better as a bot. (e.g., for case 1, [6], or for case 2, [7] - cases 3 and 4 aren't yet coded). This is part of my wider work to clean up enwp <--> wikidata <--> commons sitelinks, I can provide more background if needed.

(BTW, I'm not sure if this should be an RfC or just a straw poll, if anyone thinks it should be a RfC then feel free to add the tags.) Thanks. Mike Peel (talk) 18:17, 30 August 2020 (UTC)

  •   Support . Two notes: 1) On Commons there are many cross-ns #REDIRECTs (page_is_redirect = 1) pointing from galleries to categories (intentionally or as a remains of a cross-ns move). 2) Dest cats should be checked if they are redirects. They are tagged by templates and not #REDIRECTed but can be caught best by being a member of c:Category:Category redirects. --Achim (talk) 18:57, 30 August 2020 (UTC)
    @Achim55: I normally use code that checks for uses of commons:Template:Category redirect and a list of known redirects to that template - it may not catch them all but it works conservatively - if it can't find the template, it assumes that it is a valid gallery. Thanks. Mike Peel (talk) 19:06, 30 August 2020 (UTC)
    Mike, last word ^ should have been 'category' I think. Well, testing for the use of templates should work as well, but I suggest to check if your code covers the "cascading" c:Template:Invalid taxon category redirect too. Best, Achim (talk) 19:19, 30 August 2020 (UTC)
    • @Achim55: No, 'gallery' is correct, it uses the sitelinks to check for categories so it's only the gallery check that is more tricky. I'm always happy to improve code, but that is probably better discussed at the bot proposal - first we need to establish whether this is something we want to do as a community. Thanks. Mike Peel (talk) 19:23, 30 August 2020 (UTC)

  Suggestion I have an alternative, somewhat overlapping proposal that I think will achieve the same ends and require less bot editing and make things better for readers. I propose turning {{Commons}} back into a generic "link to the best item at Commons" template that it was before the semantics of Commons search changed. We could have {{Commons}} use Module:Commons link, as {{Commons-inline}} does. When {{Commons}} has no parameters, Module:Commons link would use Wikidata to find one of a Commons gallery or Commons category (if they exist). The module is "fail soft": if Wikidata is inconsistent, it falls back to Commons search. Using this module would cover Mike Peel's cases (1) and (3), above. I enthusiastically support using a bot to handle case (2) above (because the intent of the editor is clear: {{Commons|Category:Foo}} should clearly be {{Commons category|Foo}}). I bet that would be a one-time-run bot.

The use of this module is prototyped at Template:Commons/sandbox, with test cases at Template:Commons/testcases

Some further notes to answer questions that other editors may have:

  • About 2 years ago, the meaning of Commons search changed. When there was a search term "Foo", if there was a gallery called "Foo", readers would be taken directly to that gallery. If not, and if there was a category called "Foo", readers would be taken directly to that category. Otherwise it would fall back to a generic search for "Foo". This was much friendlier than the current situation. Module:Commons link (function getGalleryOrCategory) is designed to restore that behavior (as far as it can), using Wikidata. If it cannot, it will default back to search.
  • Module:Commons link is ready for prime-time. It is used on 25,000+ articles by {{Commons and category}}, {{Commons and category-inline}}, {{Commons-inline}}, and {{Sister links}}. It has test cases and I have received no complaints over the last several months.
  • Module:Commons link is fail-soft and non-intrusive:
    • If a parameter is provided, it uses that instead of searching through Wikidata
    • It looks in multiple Wikidata fields (e.g., sitelinks) for possible galleries and categories: if a gallery or category is available, it uses it. If Wikidata is self-contradictory, it gives up and falls back to Commons search.
    • Many thanks to RexxS and Mike Peel to advice on how to build this module: I relied on Module:WikidataIB for inspiration!
  • In case Mike Peel was wondering: if P373 is deprecated, Module:Commons link would still function without errors. It uses P373 as a possible source of gallery links, but if it is empty or removed, it would simply find fewer galleries.

I believe that Module:Commons link fulfills most of the goals of the proposal by Mike, while being automatically up-to-date when Commons sitelinks (e.g.) change.

What do other editors think of this? — hike395 (talk) 19:44, 30 August 2020 (UTC)

  • @Hike395: I was hoping to keep this focused on the specific issue of whether to use the {{Commons}} vs. {{Commons category}} templates as that's a practical step that we can take now. If we're going to turn this into a broader discussion, then I would like to see us use a single template that links to the gallery and/or category as they are available through the sitelinks on Wikidata, possibly through Module:Commons link if @RexxS: can confirm that this is compatible with Module:WikidataIB). Thanks. Mike Peel (talk) 20:02, 30 August 2020 (UTC)
    • @Mike Peel: Looking at Module:Commons link, I can confirm that it interacts with Wikidata in just the same way that WikidataIB does. Essentially, it adds multiple utility functions for working with categories and galleries on Commons, and two main calls to get the associated Category and Gallery respectively into Wikitext. --RexxS (talk) 23:11, 30 August 2020 (UTC)
@Mike Peel: Apologies for possibly randomizing the discussion. Some more notes:
  • If we get consensus around this, we can promote Template:Commons/sandbox to Template:Commons right away, and achieve part of what you desire from a bot run immediately, without waiting. It's a practical step we can take today. In this case, {{Commons}} would become what you are suggesting (a "template that links to the gallery and/or category as they are available through the sitelinks on Wikidata"), with extra checks from other properties for fallback and consistency.
  • Back in March, RexxS generously did a code review for Module:Commons link, and didn't see any problems going into production. Mike: did you have specific concerns about how Module:Commons link was different than Module:WikidataIB? There are four main entry points: getGallery, getCategory, getGalleryOrCategory (return one), getGalleryAndCategory (return both). Instead of checking Wikidata in series, bailing after the first item is found, Module:Commons link looks in all of the same places as Module:WikidataIB, and does not return a Commons link if any inconsistency is found.
  • In that same discussion, Mike brought up an interesting idea for combining Commons templates. Can we defer that discussion in favor of a simple call to Module:Commons link in {{Commons}}? As you said, the module call is a simple practical idea we can implement today. The Commons templates can always be merged later, if we get consensus.
More comments/suggestions/issues are welcome! — hike395 (talk) 23:09, 30 August 2020 (UTC)
@Hike395: Looking at this in more detail, I think the changes at Template:Commons/sandbox are a useful improvement to reduce the number of bad links, and I think you should make that change immediately (I can make it live if you don't have the permissions to do so). However {{Commons cat}} includes the tracking categories, in particular for cases where there is no defined parameter and no sitelink on Wikidata (= link to the search in this template), and where the local text doesn't match Wikidata. These are really useful for maintenance, but they become more complex to handle when you have both categories and galleries (in particular if you don't know which the editor wanted to link to). Pi bot is also set up to maintain the links to categories, which is part of why I want to migrate cases over to use {{Commons category}} where possible, without removing links to galleries. In the long term, I would like to see us using both templates without parameters (just using Wikidata), and linking to either/both the gallery and category (and maybe related categories), but that's a separate discussion.
Bottom line, I think you work is good and should be made live, but it's parallel to the specific proposal I've put forward here. I think both could go forward in parallel. Thanks. Mike Peel (talk) 19:01, 1 September 2020 (UTC)
@Mike Peel: Thanks! I just made it go live. I agree that Module:Commons link is complementary to your proposal. Your proposal contains a valuable set of cleanups that I think we should implement. I think we're just discussing the details of the cleanups at this point.
I'm more than happy to implement the tracking category logic from {{Commons category}} in Module:Commons link. That should be easy in Lua. If you agree, I can add that logic to {{Commons}}. I can also expose it as an entry point, so we can make {{Commons category}} a bit more compact (if you wish). I'll start work on that in Module:Commons link/sandbox. After implementing that, we won't need to change the template to get the tracking categories.
I am thinking that {{Commons}} and {{Commons category}} express different editor intent. The latter means "I really want to link to a category", while the former means "I want the best Commons thing, of some sort". I'm just trying to be super careful about having a bot make massive changes that may alter editor intent. Let me break down the possible cases you've outlined, and make a suggestion that should preserve editor intent.
  1. {{Commons}} has a first parameter that is a category --- clearly move to {{Commons category}}
  2. {{Commons}} has a first parameter that is a redirect to a category --- move to {{Commons category}} is very likely to be correct
  3. {{Commons}} has a first parameter that doesn't exist at Commons. There are two possibilities:
    • The editor made a mistake (likely) --- the right answer is to delete the first parameter and let Module:Commons link do its Wikidata magic.
    • The editor may have intended to invoke a Commons search (unlikely, but possible)
    We could simply delete the first parameter and ignore the unlikely case? Or I can add a |fallback= parameter to {{Commons}} and Module:Commons link, and have the Commons search execute after Wikidata fails. What do other editors think?
  4. {{Commons}} does not have a first parameter --- Now that we are using Module:Commons link, which is specifically designed for this case, I would leave this case alone. (Especially after I add the extra tracking categories).
To summarize, I support using a bot in my cases (1) and (2), above, oppose using a bot in my case (4), and let's discuss my case (3). I'll get to work on the tracking categories.
What do other editors think? Mike? — hike395 (talk) 14:37, 2 September 2020 (UTC)
@Hike395: I think we agree on your first one (my #2), and the second one that is part of my #3. Your third and fourth points assume that the link to search was correct (I'm automatically excluding any that link to an existing gallery here), I'm not sure that is a reasonable assumption. Particularly in categories, I think it makes sense to link to the Commons category rather than the search results, where (and only where) such a category exists. If there's no such sitelinked category, then my proposal wouldn't alter those cases. Perhaps the general question here is: do we want to link to search rather than an existing Commons category on the topic? Thanks. Mike Peel (talk) 17:55, 2 September 2020 (UTC)
@Mike Peel: I agree that search links are a bad user experience. However, now that Module:Commons link is used in {{Commons}}, my case #4 doesn't use search links any more. My case #4 now directly goes to the Commons category (if there is no corresponding Commons gallery, otherwise it will use that). I've written (but not yet tested) the tracking category logic in Lua. Soon there'll be no compelling reason to move case #4 over to {{Commons category}} (I think). — hike395 (talk) 19:16, 2 September 2020 (UTC) I
@Hike395: OK, that's good. The question then becomes, for the cases where the template links to Commons categories only, whether it's better to use {{Commons category}} to make it clear that it's a link to a Commons category. Then we keep the gallery and category lik maintenance separate. But the other way of looking at it is, it's the first step to merging to a single Commons template that sorts it out automatically. Thanks. Mike Peel (talk) 17:34, 3 September 2020 (UTC)

@Mike Peel: Instead of changing the template (which possibly alters editor intent, and would be incorrect if a new gallery shows up), should we change the output of the templates to warn editors (and readers) that Wikidata is taking them to a category? That is, if {{Commons}} (or related templates) find a category in Wikidata instead of a gallery, should we populate the sister link box with the label of Category:Foo instead of Foo ? Or would readers find that too confusing? 14:56, 6 September 2020 (UTC)

I think the general convention is to not show 'Category:' - the same as the categories at the bottom of an article don't have the prefix. My preference would still be to change the template. Thanks. Mike Peel (talk) 14:16, 12 September 2020 (UTC)
@Mike Peel: I still wonder if we can come to a compromise acceptable to both of us. How about this: can we change the output text for these kind of templates?
If the template links to a gallery, it could read something like
If it links to a category, it could read something like
If it falls back to some sort of search, it could read as it does today
and if {{Commons and category}} returns both, it could read
I like this, because it makes the Wikidata logic more transparent to both editors and readers. What do other editors think? — hike395 (talk) 00:58, 13 September 2020 (UTC)
@Hike395: That's the kind of solution I'd like to see us reach in the long term, but it's kinda beyond what I was proposing at this step. I'm puzzled why you don't like the idea of moving the category links over to the other template for now, though, where there isn't a defined parameter? We can always merge the templates in the future, if there is consensus to do so (and I think that needs wider discussion than we're seeing here so far). Thanks. Mike Peel (talk) 20:16, 13 September 2020 (UTC)

@Mike Peel: Here's one case: Editor A uses {{Commons}} on Foo, with only Commons:Category:Foo existing at Commons. Bot comes through and converts it to {{commons category}}. Nothing has changed. But then Editor B creates Commons:Foo. Without the bot, the page would auto-update to link to Commons:Foo. With the bot, the page would not auto-update. Why do we want to turn off auto-updating?

Here's another example. I come across an article that violate WP:IG: I transwiki the gallery over to Commons, and try to make it nice (include FPs, organize into sections, etc.). If the article has {{Commons}}, then I leave that alone, because some prior editor wanted some sort of Commons link. If the article has {{Commonscat}}, then I convert it to {{Commons and category}} because I know that some prior editor explicitly wanted to link to a Category, and they would be unhappy if I took their category link away. If a robot converts {{Commons}} to {{Commonscat}}, I don't know what editors intended. I could look back into the history, it's true, but why make me do the work for no functional difference?

Hope this helps explain. — hike395 (talk) 05:13, 16 September 2020 (UTC)

Succession boxes for US PresidentsEdit

Following on from the discussion started here:

Talk:Donald Trump#What happened to the succession boxes?

How does the community feel about succession boxes and their inclusion in the articles about US Presidents specifically? The following three options were presented on the talk page above:

  1. The succession boxes should be included in all U.S. presidents' BLPs.
  2. The succession boxes should be omitted from all U.S. presidents' BLPs.
  3. One size does not fit all. Cross-article consistency is less important than flexibility. Decide on a case-by-case basis at article level.

I genuinely believe they help navigation between articles, though they could often be trimmed down to avoid trivial items, and if they are too large, they can be collapsed into the Offices and distinctions box. That way if you are looking for them, they are there, but if not they are not taking up a lot of space at the bottom of the article. ScottishNardualElf (talk) 08:55, 1 September 2020 (UTC)

  • 2 - The information therein is somewhat redundant with the Preceded by and Succeeded by fields of {{Infobox officeholder}}, while far less visible and accessible being at the bottom of the article. What little anecdotal evidence we have (from editors who used to be only readers) suggests that readers rarely or never use the succession boxes. At Donald Trump, the boxes were removed after brief discussion in December 2018, and the only arguments in opposition to that have been that U.S. presidents' BLPs must be consistent. No one has even attempted to make the case that the boxes actually benefit readers enough to justify the space required, and I feel that would be a very difficult case to make. Ok, so let's make U.S. presidents' BLPs consistent. ―Mandruss  09:26, 1 September 2020 (UTC)
  • 2 - succession boxes are such an outdated navigation tool on We have as Mandruss pointed above, the relevant fields in the infobox, but also navigation templates such as {{US Presidents}} which already show the entire list. Succession boxes just add clutter as they are much more larger and offer no additional value. --Gonnym (talk) 10:28, 1 September 2020 (UTC)
  • 1 or 2 - but this should include all the US presidential & vice presidential nominees bios. GoodDay (talk) 14:16, 1 September 2020 (UTC)
  • 2 seem pretty redundant/useless now. We show the same information in better ways in articles. Showing succession for the Nobel Peace Prize (ref Obama) is not helpful. Succession for major office posts is already shown in infobox. I support broader removal from all such articles. Also noting that cobaltcigs's mockup below is a significant improvement, and in any case the boxes should be updated to that if kept. ProcrastinatingReader (talk) 13:50, 6 September 2020 (UTC)
  • 2 I think succession boxes in general have had their day. The infobox is much more useful, because it puts the short summary of the individaul write at the top of the article. If an individaul has a lot of offices that wouldd make the infobox too long, it's always possible to put some of the offices in a collapsed format, as is done with the infobox for John A. Macdonald. --Mr Serjeant Buzfuz (talk) 17:32, 7 September 2020 (UTC)
  • 1 – Succession boxes remain useful for cases where the inclusion of an office in the infobox of a given article wouldn't meet MOS:INFOBOXPURPOSE. For example, in the Canadian context, it's not uncommon for there to be "secondary" ministerial titles that are typically held alongside a more significant portfolio, such as Minister responsible for La Francophonie. Despite being a significant office, it simply wouldn't be important enough to include in the infobox in most cases. (talk) 05:38, 15 September 2020 (UTC)
  • 1 Not sure where you're getting "anecdotal evidence" from. I use them all the time for navigation. Perhaps among the most useful things on a page, particularly if a person has held multiple offices or secondary titles over their lifetime. The infobox at the top is not always the clearest nor complete, and sometimes troublesome to scroll all the way back up there if you're already at the bottom. Walrasiad (talk) 07:41, 17 September 2020 (UTC)

Flatten your succession boxes and/or absEdit

So I've suggested this before but here is my initial visual mock-up. What we know today as "succession boxes" should be flattened out to look roughly like this:

Ideally the template would also read each row's data (names, order, dates, annotations, whatever) by looking up {{PAGENAME}} on centralized lists (titled e.g. Module:Succession/President of the United States) and format the lookup results accordingly. So the calling syntax might be reduced to something like this (with various shorthand abbreviations allowed):

{{succession navbox|Illinois Senate|United States Senate|President of the United States}}

Unrecognized positions such as Community Organizer (Chicago) would be ignored and impossible for noobs to casually add. Such a system would greatly reduce screen waste, allow tighter control over accuracy, and protect against the random crap that existing succession boxes universally attract. I could probably create it within a few days, if there is interest. ―cobaltcigs 12:11, 1 September 2020 (UTC)

Considering that the existing boxes are collapsed, I don't think this is really relevant to this discussion (and it feels like a bit of a distracting hijack, to be honest). From what I've seen, the arguments against the boxes are not that they occupy too much screen real estate when temporarily expanded by a reader. There is no reason to believe that this would be more needed or used than the existing boxes. ―Mandruss  12:38, 1 September 2020 (UTC) (Strike after subsequent discussion.) ―Mandruss  13:35, 1 September 2020 (UTC)
Perhaps User:Gonnym would clarify Succession boxes just add clutter as they are much more larger in light of the fact that they are collapsed, but my reference to the space required was about other types of space: File size, post-expand include size, space in the edit window, and even the screen space required for the collapse bar. If the boxes are rarely used, even those relatively minor things are unjustified. Massive unnecessary clutter is usually a gradual accumulation of relatively minor things just like this – "hey, one more collapse bar won't hurt" – and we can only address them one at a time. ―Mandruss  13:03, 1 September 2020 (UTC)
A template shouldn't be huge even when expended if it doesn't need to. Compare the size of the succession section (Offices and distinctions) to Template:Barack Obama. Look at how much link data the navbox has compared to the succession one and yet the succession one is much larger and duplicates information presented elsewhere in the article, including right next to it with {{US Presidents}}. --Gonnym (talk) 13:17, 1 September 2020 (UTC)
@Gonnym: In that case, cobaltcigs's proposal would appear to address at least some of your concerns. Would you support it as a solution, then? ―Mandruss  13:23, 1 September 2020 (UTC)
No, not really. It is better than the current succession templates, but it's still not needed as it's still duplicating data right next to it. Using the above example, it's duplicating {{US Presidents}} and {{United States senators from Illinois}} with the 13th District seat seemingly not being important enough to warrant a navigation template. And again, all 3 are the first pieces of information right after his image in the infobox. --Gonnym (talk) 13:30, 1 September 2020 (UTC)
Fair enough - I am still learning the ropes here. ScottishNardualElf (talk) 22:25, 1 September 2020 (UTC)
@ScottishNardualElf: You might get more attention on this topic, if you make this discussion an RFC. GoodDay (talk) 15:33, 3 September 2020 (UTC)

So this proposal was actually intended as a compromise between the status quo and my (unpopular, I thought) personal opinion that totally getting rid of succession boxes would be better. Support for the latter seems higher than predicted, which is good. As long as we whack the {{portal bar}}s next. ―cobaltcigs 22:18, 10 September 2020 (UTC)

@Cobaltcigs: If you support option 2, feel free to indicate same in the preceding section, for clarity. ―Mandruss  15:14, 11 September 2020 (UTC)
  • I think the idea of flattenning the boxes is the best idea--and possibly not just for US presidents but in general. They're a rather primitive visual element, reminiscent of the earliest years of html. The basic information they give is useful--the prominence in the appearance of the article dadds nothing to that. DGG ( talk ) 00:55, 19 September 2020 (UTC)
  • Broadly support flattening but the sample doesn't work well without some kind of separator in a wide window (and particularly as the number of offices rises). If the middle column could be made relatively narrow, and the left and right columns were right and left aligned respectively it would keep things visually connected ~Hydronium~Hydroxide~(Talk)~ 02:28, 19 September 2020 (UTC)

Expansion of scope: succession boxesEdit

This question should be expanded to include all the US presidential & vice presidential candidate bios. GoodDay (talk) 14:13, 1 September 2020 (UTC)

Sure, but why stop there? What about use of the same boxes in the BLPs for other U.S. officeholders? What about non-U.S. officeholders? If you're expanding scope at all, the only logical place to stop expanding would be to include all uses of the boxes anywhere in the encyclopedia. That's a far larger question, and before you know it you have a months-long discussion, very possibly all wasted time due to a no-consensus outcome. I say we can take this on in smaller pieces without undue harm to the encyclopedia, but any consensus here would be a factor in future discussions about other pieces. If we reach a consensus for option 1, there probably won't be any future discussions anyway. ―Mandruss  14:44, 1 September 2020 (UTC)
It wasn't my decision to delete the succession boxes at Donald Trump, thus putting that article out-of-sync with the others. GoodDay (talk) 15:38, 1 September 2020 (UTC)
That again??! You're right, it wasn't your decision. It was a local consensus not precluded by a community consensus, as explained to you more than once. The cross-article consistency factor was argued, and it was not enough to sway consensus toward keep. Please cease making me keep explaining to you how Wikipedia works, you have been around far too long for that. You are becoming disruptive. ―Mandruss  15:49, 1 September 2020 (UTC)
I'm not interested in getting into personal insults with you, so let's not go down that path. GoodDay (talk) 16:13, 1 September 2020 (UTC)

Central notice banner discussion for "Wiki loves SDGs" on 19-26 September 2020Edit

I put up a central notice banner request for an online editathon that I am involved with for the period 19-26 September 2020. It would be for the English Wikipedia in those countries that don't already have another banner at the same time (there is one for Wiki loves Monuments and for fundraising also going up in September, it seems). I was told by an admin on Meta that it should be discussed on Village Pump, that's why I am writing here now (I hope I have put it in the right section). Here is the link to the discussion so far: . The admin advised me: "Hi @EMsmile:, in the meantime: is the English community okay with yet another global banner? Could you please share a link to a place where this was discussed? The English community sometimes is a bit hesitant to allow another banner, therefore it would be good in inform the community and seek consensus. " What do you all think? More details about the campaign is here: Or see for more information about the online editathon here. It's about the 17 Sustainable Development Goals and all the topics related to that (which are loads). EMsmile (talk) 11:13, 7 September 2020 (UTC)

  • I have the same opposition to this as I do to the current one - I don't really like the "Wiki Loves X" style, since if you asked us to openly campaign for their better implementation on-site, people would oppose on the grounds that we aren't supposed to be campaigning. Now, it won't be running in my country (UK), the editor is in GF, and it's not a major thing, so I'm willing to be neutral on the issue. Nosebagbear (talk) 10:49, 8 September 2020 (UTC)
Hi User:Nosebagbear, thanks for your comment. Just wondering what you meant with "the editor is in GF"? This is a campaign to get more people from the Global South (developing countries) to edit topics that are particularly (but not only) relevant to the Global South, and especially new female editors. It's a campaign to improve existing Wikipedia articles. In which sense do you mean "we aren't supposed to be campaigning"? Personally, I would have preferred "Wikipedia loves SDGs" over "Wiki loves SDGs" but others that were involved in starting this preferred the shorter version of the project title... EMsmile (talk) 14:07, 8 September 2020 (UTC)
@EMsmile: - I meant to just write "the editor is GF (good faith)", and just tripped up over the grammar. I share the preference for Wikipedia over Wiki, but I decided a while back it wasn't worth picking that as the hill to die on. Wikipedia doesn't campaign except on things that are inherent threats to our functionality (most recently, for example, there was a very staunch decline on blacking out for BLM). I've no objections to more/better articles on the SDGs at all. However "Wiki loves SDGs" isn't just a more pithy version of "Wiki(pedia) loves writing about the SDGs" - if you asked someone to tell you what it meant, they'd feel it read as Wikipedia pushing them, hard. Nosebagbear (talk) 14:13, 8 September 2020 (UTC)
If this is mainly creating/improving articles, I would recommend: 'Wiki writes . . .' or 'Wiki writes about . . .'. Alanscottwalker (talk) 14:21, 8 September 2020 (UTC)
It's mainly about improving articles and interlinking them better. Are you both saying you don't mind a banner on this, but you don't like if the banner says "Wiki loves SDGs"? Would you be happier if the banner had a different text? The banner is meant to alert people to join the week-long effort (during Global Goals Week) to improve SDG-related articles on Wikipedia (of which there are hundreds, see here). EMsmile (talk) 14:55, 8 September 2020 (UTC)
Who is Wiki? Do we know this person? A wiki is not sentient and so cannot love anything. Wikipedians may love other people (Wikipedians or not), but in this case they might be keen, enthusiastic, determined or they might wish to promote, encourage, enhance or even solicit, importune, invite. As for "SDG's" or "SDGs", just spell it out in full. Are we that short of space? So, all in all a horrible choice of wording. Or is the inherent wrongness just contrived to catch our attention? — GhostInTheMachine talk to me 17:34, 8 September 2020 (UTC)
  • Sounds great! Thanks for organizing. Some people don't love "Wiki Loves..." because it implies endorsement by everyone. Hence it was disappointing but not surprising when advertising a "Wiki Loves Pride" event was controversial. It is a fairly well established naming format (Wiki Loves Monuments, Wiki Loves Earth, etc.), though, and are the SDGs controversial? Are there people who don't want to be seen endorsing things like "no poverty" and "zero hunger"? Would support the notice under whichever name it winds up being, but since it seems like there's already some organizing behind this under that name, it's probably best to keep it as-is, noting for future organizers that "Wiki Loves" causes more hesitancy than other verbs. — Rhododendrites talk \\ 17:03, 8 September 2020 (UTC)
    Yes. Some might object to Wikipedia endorsing a designed-by-committee laundry list of technocratic platitudes papering over the absurdity of globalised capital fixing the social and ecological crises it created. But hey, there's always going to be someone who objects. I don't think that should stop anyone making a good faith effort to increase participation in the project. – Joe (talk) 18:07, 8 September 2020 (UTC)
Thanks for this link, User:Joe Roe. Those articles that criticise the SDGs and their process is exactly what I ALSO want to bring to Wikipedia. We already have a section on "reception" in the SDG article ( where those things can be discussed / cited. The section was called "criticisms" before but I was told as per WP:CRIT that's not the right way to do it. I definitely want to provide a balanced view and if there are scholars and NGOs who have criticised the SDGs then this ought to be included. It might even warrant a spin off article lated that deals specifically with that, like "Controversies about SDGs". Existing UN websites that explain the SDGs are obviously very biased and make it all sound clear and easy... Having said that, we do also want to edit all the SDG-related topics (and link them with SDG articles); these are topics like maternal mortality, FGM, birth registration, forced marriage but also climate change, eutrophication, ocean acidification and so forth (see list here). By saying that the editathon will be about SDG-related topics (not just the SDGs) we would actually cover a large number of articles, many of which are highly relevant to the Global South / developing countries - an area that has traditionally received less attention on Wikipedia, simply because editors are volunteers and tend to write about what they know and care about. If the editors are from Europe and North America then naturally they are less inclined to write about such topics which don't immediately affect them. EMsmile (talk) 04:22, 9 September 2020 (UTC)
  • This gives me pause: The nine most active volunteers will receive a cash prize at the end of the edit-a-thon of 100 Eur each (Wikipedia:Meetup/Online edit-a-thon SDGs September 2020#Prizes). You're vague about what "active" means and sending the message to potentially thousands of new editors that lots of edits = money could cause a mess. WLM's prizes get around this by making it clear they're for quality not quantity. – Joe (talk) 18:26, 8 September 2020 (UTC)
Thanks for pointing this out, Joe. I have changed it now to say: "The nine volunteers who have made the most valuable contributions during the editathon will receive a cash prize at the end of the edit-a-thon of 100 Eur each. The organizers will determine who the volunteers with the most valuable contributions were based on quality and quantity of their editing contributions. To make this judgement, the editors will carefully review the volunteers' contributions as per the data collected in the event's dashboard here. " (Wikipedia:Meetup/Online edit-a-thon SDGs September 2020#Prizes) I think valuable equates broadly to quality and quantity, would you agree? I couldn't find the exact criteria that WLM uses for their prizes (could you point me to the exact location if you have it? The link that you gave didn't show me that information).
  • How about this for a compromise with regards to the wording of the banner: We include both the long version and the short version. Short version is "Wiki loves SDGs". Long version is: "Wikipedians meet online to improve articles that touch on topics related to the Sustainable Development Goals"? (I am also not a big fan of the short version but I have been told by people with experience with volunteers and activities on SDGs that this would work and has potential to galvanise people into action, get them curious and get them to come to Wikipedia). Maybe the title "Wiki loves SDGs" works better outside of Wikipedia but for inside of Wikipedia we could more push the longer version? EMsmile (talk) 04:26, 9 September 2020 (UTC)
  • Oppose, for the following reasons:
    • The CentralNotice has been heavily overused recently. We should not have another broad campaign to all users now, especially with Fundraising season coming up. It's important to not use the banners too frequently.
    • SDGs are not exactly such a broad topic that the expected editing is likely to be sufficient to justify displaying the banner to such a broad audience (that is, the entire readership). Very few users are likely to have something to contribute to this.
    • Anything near the area of public policy is risky from a neutrality standpoint. It's difficult to simultaneously communicate that we'd like to write about these topics, but we are neutral and have no involvement in actually accomplishing any of these goals, and are not interested in supporting them. It's even harder when the name is "Wiki Loves SDGs".
  • --Yair rand (talk) 04:32, 9 September 2020 (UTC)
I just want to point out that the banner wouldn't be for the entire English Wikipedia readership but only for people in those countries who don't already have the Wiki loves Monuments banner or the Fundraising banner. If possible, I would like to have it visible for all readers in the "Global South" developing countries, or if that's too hard, all of Africa and Asia (which is where the SDGs are furthest behind). - Regarding the issue of implying support or not: Another option could perhaps be to say "Wiki loves sustainable development"? Or "Wiki loves sustainability"? as those would be concepts that Wikimedia Foundation has officially endorsed if I am not mistaken (see for example here where it says "Last year, the Wikimedia Foundation created a group called the Sustainability Consortium"? - With regards to overuse of banners: perhaps it depends which country you live in. I live in Australia and I find we get very few banners here. The only ones I have seen in the last 12 months seem to be Wiki loves monuments and perhaps a fundraising banner - at least I can't remember any other ones. Doesn't feel like overuse. Perhaps they get used more in the United States and Europe? I am not sure. (whether they actually attract more editors in the end I don't know either; I guess there is some research about that somewhere) EMsmile (talk) 06:45, 9 September 2020 (UTC)
Which of the large countries where English is widely spoken would the proposed banner appear in?--Wehwalt (talk) 14:06, 9 September 2020 (UTC)
Our focus would be on developing countries. We could go by this list (List of territorial entities where English is an official language) minus the countries where Wiki Loves Monuments has a banner in September (those are shown here), minus the countries where there is a fundraising banner (they are all not developing countries, i.e. US, GB, MZ, AU, CA, IE). Wiki Loves Monuments does not have many developing countries on the list, except for example Benin, Brazil, Egypt, India, Nepal, Uganda. So maybe keep it simple and only take countries in Africa, Asia and Carribean which would be these (taken from here):
Countries where English is a de jure and de facto official language
Nr Country Alpha-3 code Region Population1 Primary language?
5 Botswana BWA Africa 1,882,000 No
6 Burundi BDI Africa 10,114,505 No
7 Cameroon CMR Africa 22,534,532 No
11 Eswatini SWZ Africa 1,141,000 No
13 Gambia GMB Africa 1,709,000 No
14 Ghana GHA Africa 27,000,000 Yes (used as lingua franca)
20 Kenya KEN Africa 45,010,056 Yes (in business and education)
22 Lesotho LSO Africa 2,008,000 No
23 Liberia LBR Africa 3,750,000 Yes
24 Malawi MWI Africa 16,407,000 No
29 Namibia NAM Africa 2,074,000 No (used as lingua franca)
31 Nigeria NGA Africa 182,202,000 Yes (used as lingua franca)
37 Rwanda RWA Africa 11,262,564 No (but official and educational)
43 Sierra Leone SLE Africa 6,190,280 Yes
46 South Africa ZAF Africa 54,956,900 Yes (and official, educational and

lingua franca in formal economy)

47 South Sudan SSD Africa 12,340,000 No
48 Sudan SDN Africa 40,235,000 No
49 Tanzania TZA Africa 51,820,000 No
53 Uganda UGA Africa 37,873,253 No (but official and educational)
55 Zambia ZMB Africa 16,212,000 No
56 Zimbabwe ZWE Africa 13,061,239 No (used as lingua franca)
27 Mauritius MUS Africa / Indian Ocean 1,262,000 No
42 Seychelles SYC Africa / Indian Ocean 87,000 No
17 India IND Asia 1,247,540,000 No (but official and educational)
33 Pakistan PAK Asia 212,742,631 No (but official and educational)
36 Philippines PHL Asia 102,885,100 Yes (co-official with Filipino)
44 Singapore SGP Asia 5,469,700 Yes (used as lingua franca, mostly and widely spoken, and educational)
1 Antigua and Barbuda ATG Caribbean 85,000 Yes
2 Bahamas BHS Caribbean 331,000 Yes
3 Barbados BRB Caribbean 294,000 Yes
10 Dominica DMA Caribbean 73,000 Yes
15 Grenada GRD Caribbean 111,000 Yes (except for small French Creole population)
19 Jamaica JAM Caribbean 2,714,000 Yes
38 Saint Kitts and Nevis KNA Caribbean 50,000 Yes
39 Saint Lucia LCA Caribbean 165,000 Yes
40 Saint Vincent and the Grenadines VCT Caribbean 120,000 Yes
51 Trinidad and Tobago TTO Caribbean 1,333,000 Yes
4 Belize BLZ Central America 288,000 Yes

EMsmile (talk) 05:02, 10 September 2020 (UTC)

I feel a little drowned in information. Let me put it this way, of the US, Canada, UK, Australia, New Zealand, India, Pakistan, Eire, which of these would take the proposed banner?--Wehwalt (talk) 17:51, 10 September 2020 (UTC)
User:Wehwalt Of the list that you mentioned, only developing countries would get the Wiki loves SDG banner, so that's Pakistan and India from your list (but not India if it already has the Wiki loves Monuments banner at the same time).
Much obliged, thanks.--Wehwalt (talk) 06:51, 11 September 2020 (UTC)

As a resident of the Southern United States, I take great offense to any analogies implied by the term "Global South". Moreover, it's [geographically inaccurate]. I hope you don't intend for it to actually appear in the banners. ―cobaltcigs 00:37, 11 September 2020 (UTC)

User:cobaltcigs, yea well, the term global South exists and has its own controversies which are well explained in its Wikipedia article (Global South). Whether it "sticks" remains to be seen. Equally, someone living in Australia could take offence. Anyhow, I prefer to use the term developing countries but there are others who object to that term as well. See here. It's not easy. The banner would not include the term Global South, but would use the term "developing countries" or actually not mention the region at all. My proposal was: Short version is "Wiki loves SDGs". Long version is: "Wikipedians meet online to improve articles that touch on topics related to the Sustainable Development Goals". The SDGs are officially for the entire world, but of course it's the developing countries that have the hardest job to achieve them. EMsmile (talk) 06:34, 11 September 2020 (UTC)
Great project EMsmile, I love it. The global goals are worthy in itself to be thoroughly covered in Wikipedia as they have been agreed upon by more than 190 members of the UN in 2015. In 2019 the Wikimedia movement held its annual international conference Wikimania in Stockholm. The motto of the conference was: "Stronger Together: Wikimedia, Free Knowledge and the Sustainable Development Goals." The Wiki loves SDGs project, a one week virtual editathon, is a natural follow up to this conference. We owe it to the world to do this. It is the least thing we can do after we have gathered with a crowd in Stockholm over a year ago, and have been talking about what we can do. Ad Huikeshoven (talk) 14:28, 15 September 2020 (UTC)
Thanks, Ad Huikeshoven. That's really useful to be reminded of last year's Wikimania's theme. - If we get that banner up for those countries that I have listed above, would many of you agree with this banner title?: "Join us for "Wiki loves SDGs" during 19-26 September: Wikipedians meet online to improve articles related to the Sustainable Development Goals". The online platform that we'll use for interactions in that week is Workplace by Facebook by the way, see here. EMsmile (talk) 15:53, 15 September 2020 (UTC)
the draft of the banner is now visible here (see at the very top of the page): . It will only be displayed in certain countries, mainly developing countries (as discussed above). What do you think of the banner? Can you live with it? Any suggestions for improvements? EMsmile (talk) 03:26, 18 September 2020 (UTC)
  • WP is intended for information, not for advocacy. We may need to extend our coverage in this area, but we shouldn;t be making a moral principle out of it, or giving it undue visual prominencem or using using what will be to a non-WPedian unfamiliar abbreviations. We should just write the articles. If we need to organize to find the necessary information, that would be a good thing, but we shouldn;t mistake displaying prominent banners with the need to do actual work. DGG ( talk ) 00:59, 19 September 2020 (UTC)
So... did "we" decide to do this? Is it happening right now? — JohnFromPinckney (talk) 10:26, 24 September 2020 (UTC)

Oppose any banners, any place, any time. Please read the Wikipedia Mission Statement. GenQuest "Talk to Me" 11:13, 24 September 2020 (UTC)

Measures to curb sandbox abuse?Edit

I know this may have been proposed before, but would it be feasible to fix the MediaWiki software so that sandbox edits won't count towards autoconfirmed status, or alternatively, make the autoconfirmed privilege a little stricter while keeping to the project's goals of a free encyclopedia? I've seen vandalism from a certain troll whose name I won't mention through sock accounts abusing the sandbox just to get around the autoconfirmed protection even on pages with indef semi-protection in place. I am honestly incensed at this considering how persistent and relentless said troll was in disrupting the project and sowing discord amongst those who he rubs elbows with, but I digress. Blake Gripling (talk) 13:45, 10 September 2020 (UTC)

It would be pretty useless to limit, and counterproductive. I'd rather have someone goof around in their sandbox than insert random, incorrect commas on live articles. Must consider the purpose of autoconfirmed, which is a very minimum requirement and not meant to be hard to get. If you try change that, these "trolls" won't stop, you'll just inadvertently send the issues into mainspace. ProcrastinatingReader (talk) 15:38, 10 September 2020 (UTC)
It is possible to use other types of thresholds for granting access to automatic groups, but as PR notes above - the bar for "autoconfirmed" is meant to be very low - primarily as a screen against non-wikipedia bots and casual spammers/vandals. — xaosflux Talk 16:06, 10 September 2020 (UTC)
  • I know this doesn't directly address your original question, but if there's a specific page (or small set of pages) that are being abused, WP:ECP, could be applied. You can request this at WP:RFPP, or if you really feel it can't be discussed on-wiki, feel free to email me. -- RoySmith (talk) 16:20, 10 September 2020 (UTC)
  • This question comes up fairly regularly, most often "to limit the permission to the mainspace edits" in some form (I'm am pretty sure it's on WP:PEREN at this point). It would require significant rework in how automated permissions are granted. Users gaming permissions are routinely taken care of after the fact. --Izno (talk) 16:37, 10 September 2020 (UTC)
Strongly Oppose The sandbox is a sandbox. No damage is done to the wiki if someone vandalizes the Sandbox. Like yeah, you're a jerk if someone has made an experimental page there, but it's not permanent. This doesn't make sence. Also, if a sandbox is like practice, then it should count towards edits. No explanation needed. Arsonxists (talk) 00:19, 11 September 2020 (UTC)
Comment: To be clear, this isn't to prevent sandbox edits from being logged and counted towards one's contribution history, bur rather to keep abusive users from gaming the system by making test edits to qualify for autoconfirmed status. Blake Gripling (talk) 02:01, 11 September 2020 (UTC)
I am pretty sure that you have to wait 4 days before autoconfirmed status, even if you made 10 edits. I do get what you're saying, but ussually, abusers don't go to the Sandbox to get autoconfirmed status, they ussually just vandalize ones that anyone can edit.Arsonxists (talk) 14:50, 11 September 2020 (UTC)
And those who do, will find other ways to bypass the auto confirmed status another way. It's an open encyclopedia, this is the side effect of that mission statement. —TheDJ (talkcontribs) 14:36, 14 September 2020 (UTC)
  • I am inclined to agree with User: ProcrastinatingReader. It is better to have some one goof around in a sandbox than vandalise main articles, and if a Wikipedian does, for example, insert a blatant hoax, s/he is likely to get a message saying the sandbox is meant for experimentation Vorbee (talk) 15:30, 14 September 2020 (UTC)
  • @Blakegripling ph: Won't help, generating 10 edits without using the sandbox is a piece of cake. I think the 10 edits are more to stop sleepers from gaining autoconfirmed after 4 days. And well-meaning newbies, of course. I doubt it was ever intended to stop (serious) vandalism. — Alexis Jazz (talk or ping me) 16:57, 14 September 2020 (UTC)
    • It's actually kinda helpful, because if vandals want to vandalize a part of Wikipedia that's auto-protected, it may force the vandal to either not vandalize that part, delay the attack 4 days, or be a contrustive part of Wikipedia for a moment. So yeah, removing sandbox edit counting won't help that much. Arsonxists (talk) 18:46, 14 September 2020 (UTC)
  • Except they don't do the "constructive part of Wikipedia" bit well. Autocon-busters usually make either very minor one-character edits or null space edits to reach 10 edits. Whether or not the sandbox counts for these purposes is irrelevant because they'll just do these edits elsewhere. —A little blue Bori v^_^v Hasteur Hasteur Ha-- oh.... 20:41, 14 September 2020 (UTC)
  • Is what the proposer is saying that one's contributions to the sandbox should not count towards one edit count? Would there be a way to indicate, if a Wikipedian clicks on "Edit count", how many edits were merely contributions to the sandbox? Vorbee (talk) 07:50, 16 September 2020 (UTC)
  • I have just been on the Edit count function at Wikipedia, and whereas it tells one how many edits are to the talk pages, how many are to the main pages, how many are to User talk, how many are to category talk and so forth, it does not have a separate section saying how many edits are to the sandbox. I am not sure what category edits to the sandbox would fall under, and while I appreciate this might be technically difficult, I am wondering whether it would be feasible to introduce a section "Sandbox" in Edit count. Vorbee (talk) 06:41, 17 September 2020 (UTC)

Local Language requirementsEdit

Simply that where available place names should be accompanied by their local language name. EG The learning of Scots Gaelic (Gàidhlig) is increasing. So, placenames like Glasgow should also display as Glaschu,(Glasgow has the highest percentage of Gaelic speakers in Scotland) Fort William should display An Gearasdan. — Preceding unsigned comment added by Tartanthing (talkcontribs)

I think you mean that Glasgow has the highest absolute number, not the highest percentage. Phil Bridger (talk) 13:25, 12 September 2020 (UTC)
Aren't local names are already displayed in the article on Glasgow? – Teratix 04:10, 14 September 2020 (UTC)
They are at the Fort William, Highland article as well. Including alternate “local language” names for places is a fairly standard practice. Blueboar (talk) 11:36, 14 September 2020 (UTC)
  • I think a rule of thumb is that only names used in the local road signs are worth putting in, at least in the lead. Last time I was in Glasgow I don't remember seeing any "Glaschu" in signage. It is potentially misleading for readers from far away to suggest that the locals use a different name from that in the title, the way those in say Rome and Naples do. I see that Fort William railway station uses the Gaelic name (sometimes by itself) in platform signs etc, but Glasgow Central station does not. "Glaschu" is not the "local language" name at all - that is Glasgow. Johnbod (talk) 17:02, 14 September 2020 (UTC)
Johnbod are you suggesting that should apply to all place names or just Scottish ones? An example is Cambridge Bay which has the traditional name Iqaluktuuttiaq but there are not any road signs with that on it. Tartanthing the use of other names is common on Wikipedia as per the example in the previous sentence and Kiev or Kyiv. Perhaps the reason many Scottish place names are missing is because nobody added them yet. CambridgeBayWeather, Uqaqtuq (talk), Huliva 23:56, 15 September 2020 (UTC)
In terms of what we show right at the start of the lead, yes. I think we are frequently misleading readers by failing to distinguish between eg Belgian names, where both versions are actually used, and other places where they aren't. I said it was a rule of thumb - are you likely to hear Iqaluktuuttiaq on the street? Johnbod (talk) 03:01, 16 September 2020 (UTC)
Yes it is heard. There are several organizations using it in the name like the Ikaluktutiak Co-op and the Ikaluktutiak District Education Authority. Anybody speaking Inuinnaqtun or Inuktitut will use it. In those languages the proper name for Cambridge Bay is Iqaluktuuttiaq, spelt several different ways. In written documents Cambridge Bay is always translated as Iqaluktuuttiaq. CambridgeBayWeather, Uqaqtuq (talk), Huliva 18:29, 16 September 2020 (UTC)
(Belatedly) - oh well, that's fine then. But shouldn't they add it to the road signs? Johnbod (talk) 13:25, 23 September 2020 (UTC)j

Link to following Accessibility features on the top of home pageEdit

There should be an accessibility shortcuts to the following items on the top of the first and foremost page.

  1. , Font and rendering support, IPA, Braille etc.
  4. Wiki markup language support. (What is a markup language?, what is the Wiki markup language, its List of codes, cheatsheet etc.)

This is a keen request. This should be added on top of all pages, as an accessibility hyperlink. Even this should be added in all other Wikis and as well as Wikipedia home pages. Thank you in advance. RIT RAJARSHI (talk) 22:23, 13 September 2020 (UTC)

2 is already linked in the sidebar. 3 is irrelevant for the vast majority of articles without spoken versions, and there is already an appropriate template for articles that have spoken versions. 1 is also already linked by similar templates. 4 is irrelevant for everyone but users that edit with markup, which is an extremely small portion of all visitors to Wikipedia. – Teratix 01:59, 14 September 2020 (UTC)
Agreed. {{u|Sdkb}}talk 03:58, 14 September 2020 (UTC)

I agree some of the feature exists but the "how to use them" is not available directly on first page. The pages I linked are mostly some "help pages" and they should be linked in the main pages. RIT RAJARSHI (talk) 10:03, 14 September 2020 (UTC)

But why should the help pages be displayed on every article, where they will be irrelevant clutter the vast majority of the time? – Teratix 11:03, 14 September 2020 (UTC)
Not to distract, but "Spoken articles" should be linked to less, not more. Screen readers are fine nowadays. People who navigate Wikipedia this way want the current article spoken by their screen reader 99% of the time, and a random snapshot of unknown quality of the article as it was 6 years ago 1% of the time. And in the rare 1% of the time they might prefer a human spoken version (highly technical article? Lots of foreign words?), it usually doesn't exist, because very few WP articles have manually spoken versions. SnowFire (talk) 00:26, 15 September 2020 (UTC)

Always Show Column Headers in TablesEdit

Viewing long tables (both x and y axis) is really annoying, because the column headers are alllll the way at the top, but you're viewing a list of "yes" and "no" values in the fields, so you have no idea what they mean. You would need to memorize all of the table headers before viewing an entry several tens of entries down (such as "US Mobile" in this page's table: )

It would be very nice if the column labels would remain on screen at the top of the page, while scrolling through the table.

In modern web pages it is possible and somewhat common to show the "search" bar at the top of the page even when scrolling through contents, so this technique could easily be used.

Since this behavior could pose an issue on small screens with column headers that are very tall, this option should be implemented as a toggle button at the top left corner (first cell) of the table. — Preceding unsigned comment added by CambridgeBayWeather (talkcontribs) 23:56, 15 September 2020 (UTC)

  • Support This idea is pretty nice. Not only would it keep the reader from unessecary frustration, but the time wasted memorizing a table could be saved with this. Arsonxists (talk) 01:52, 16 September 2020 (UTC)
I don't know if that placement is the best, but potentially fixable col headers would be a welcome option (esp. if off by default, e.g., for smallish tables). — JohnFromPinckney (talk) 01:53, 16 September 2020 (UTC)
Maybe the point where it's enabled by default is 15 sections down, and 5 columns. A limit like that would organize the tables even better by eliminating the tables that don't need it and having it for the ones that don't. Arsonxists (talk) 02:02, 16 September 2020 (UTC)
  • Support - one shouldn't have to use an "experimental gadget" it should be available be default for all of our readers. Aza24 (talk) 22:22, 17 September 2020 (UTC)
  • This isn't something we need to support or oppose for. phab:T42763 has been open for 8 years so don't hold your breath waiting for the request to be fulfilled anytime soon. – SD0001 (talk) 03:51, 19 September 2020 (UTC)

Designating current seasons in infoboxesEdit

Looking at {{Infobox award}} as linked from e.g. Pulitzer Prize, it is not immediately clear that the globe and timer indicate the most recent year in which an award was given. It presents possible accessibility problems, and also causes confusion for editors because of the image's frequent use in the {{Current}} maintenance template, leading me to initially believe that there might be something in need of update. I propose that we switch to instead use "Current:", as I've demonstrated in the sandbox (see testcase here). Is that alright? Update: per below, I am expanding this proposal to include analogous changes at other infoboxes with similar circumstances. {{u|Sdkb}}talk 18:32, 16 September 2020 (UTC)Minor refactoring done to retain context during move.

Notified: Wikipedia talk:WikiProject Awards. {{u|Sdkb}}talk 18:35, 16 September 2020 (UTC)
Just as a note, {{Infobox football league}} and a dozen other sports seasons templates use this or similar versions of the "clock" image. I would suggest that the discussion get a little wider, maybe at one of the Village Pumps, to get consensus about the use of these images in general. Primefac (talk) 19:04, 16 September 2020 (UTC)
Primefac, thanks for pointing that out! I'll move this to VPR, since I think similar considerations would apply to all these templates. If anyone wants to list out the templates or propose specific alternative wording for some of the others (e.g. should it be Current season for {{Infobox football league}}?), that would be helpful. {{u|Sdkb}}talk 23:06, 16 September 2020 (UTC)
Support - Is that what that image means? I had no clue, and I often wondered what the heck it was. Clicking on the image simply takes you to the file itself, still providing no context. Even the infobox is edited, it's not very clear, and the template documentation doesn't really describe that an image is going to be used—it takes some serious connecting of the dots. At least in the {{Current}} template, the verbiage provides an explanation. If the discussion is widened, I'd have to see other cases, but with {{Infobox football league}} at least, I still don't find the image particularly helpful when I look at Premier League, but at least the football league template documentation uses the image, which is a step up from the Awards infobox. -2pou (talk) 19:31, 16 September 2020 (UTC)
Perhaps the word Current could also be in italics? I don't know if the rest agree. I've implemented it and in my opinion it looks better. El Millo (talk) 00:06, 17 September 2020 (UTC)
Support - I do not believe I have ever seen this before, but its meaning to me as a sighted user is fully opaque and therefore worth exactly zero. For unsighted users the usefulness is surely less than that (more confusion/frustration trying to use our site). If people don't like the word Current:, it seems we could drop it altogether: no image, no word; just the link to whatever current thingy would be there. — JohnFromPinckney (talk) 10:21, 17 September 2020 (UTC)
Support The fact that it took me 10 minutes to figure out what these people were trying to propose really just gives it away that it needs change. Arsonxists (talk) 16:25, 17 September 2020 (UTC)
Support any clarification over the old. I read the proposal thrice and looked at old and new and I still couldn't understand what the thing is supposed to be. I imagine the current version also violates accessibility in all sorts of ways. —  HELLKNOWZ   ▎TALK 22:41, 18 September 2020 (UTC)

CentralNotice banner for Indic Wikisource Proofreadthon 2020Edit

Dear colleagues, please comment on CentralNotice banner proposal for Indic Wikisource Proofreadthon 2020 for the Indic Wikisource contest. (1 Oct2020 - 15 Oct, all IPs from India, WPs,only). Thank you. Jayanta (CIS-A2K) (talk) 12:32, 18 September 2020 (UTC)

Implement "smart" custom toggles which act based on their stateEdit

Do you know how long an enhancement request takes to be reviewed at Phabricator? I created a task, phab:T262622, last week and it still hasn't been commented. I don't know the workflow there, so if such change would likely take more than 2-3 weeks, would it be adequate to implement the request (given it's accepted) here (at the MediaWiki namespace)? The script linked in the task is my sandbox. Alexiscoutinho (talk) 14:06, 18 September 2020 (UTC)

@Xaosflux and TheDJ:

RfC: Alexa Rankings in InfoboxesEdit

What should be done with Alexa rankings in infoboxes? -- GreenC 17:19, 18 September 2020 (UTC)

This is a follow-up to the well-attended discussion here about a year ago about what to do about Alexa Rankings in infoboxes. For example WebCite contains |alexa=  107,988 (December 2018)

Summary of problems:

  1. The Alexa numbers change monthly and quickly becomes misleading when outdated.
  2. The ranking data is proprietary (Amazon) and there is a tiered fee to access it via API, with the free tier limited to 1,000 queries a month. There are about 5,000 instances of {{infobox website}} that contain |alexa=.
  3. It can be web scraped.. but when done on a regular basis and loaded into Wikipedia it would almost certainly violate copyright or a terms of use rule, if not cause an outright IP block.
  4. The data can be manually checked and added to Wikipedia.. but in practice done sporadically see the WebCite example (2 years old as of this post), I have seen some over 5 years out of date.

The RfC proposes three options:

  1. Keep Alexa rankings in infoboxes as is currently done.
  2. Remove Alexa rankings from infoboxes entirely.
  3. Automate a solution that has no recurring article edits. Possibilities include:
    • Pull data from Alexa to local hosting (Commons tabular data, Wikidata, etc.) using the Amazon API at the rate of 1,000 per month. This would then display in the infobox via Lua. For example it could look like:
    • Create a new template {{webrank}} that displays static generic link(s). For example the Wikipedia infobox currently:
      |alexa=  13 (Global, August 2020)
      Would instead appear as: |webrank=Alexa, SimilarWeb
Automated solutions could be mixed ie. the top 1000 are done via API and the remainder via static links .. or some other idea. #3 is a single option for RfC purposes.

Please !vote your preference in order eg. "1 or 2 or 3 in that order" or however you want to word it.

Due to length of time previous participants pinged: @Wnt, Xaosflux, Izno, Phil Bridger, Ammarpad, UnitedStatesian, Lkolbly, Jc86035, Newslinger, Kaldari, Guy Macon, Objective3000, Headbomb, DGG, Moonythedwarf, and Arsonxists: -- GreenC 17:19, 18 September 2020 (UTC)

Survey (Alexa Rankings in Infoboxes)Edit

  • As in previous discussions, it should be removed. So I guess that's a bold 2. --Izno (talk) 18:42, 18 September 2020 (UTC)
  • Option 2 These rankings seem to hit more than one item in WP:NOT including WP:NOTDIRECTORY and WP:INDISCRIMINATE. What do the rankings even tell a reader - that some people at some point in time used Alexa for something. IMO they are of no more critical or scholarly value than IMDb ratings. Also why is preference being given to Alexa over other things like Siri? Didn't Ray Bradbury write a short story about one of these automated services taking over the children of an entire town or country. If he was still alive I guessing he would pen one now. MarnetteD|Talk 18:59, 18 September 2020 (UTC)
  • Option 2 The rankings are uncylopedic, as they change alot. Also: Arsonxists (talk) 19:30, 18 September 2020 (UTC)
  • Keep some sort of traffic metric. I'm new to this question, but at a basic level, the amount of traffic that a website receives is important encyclopedic information that is appropriate for an infobox. We can discuss whether that ought to be in the form of a ranking or in the form of monthly pageviews (is that available for most sites? it seems potentially more useful, especially for lower-ranked sites, since no one knows what 20,000th-most visited website actually means in practical terms), and if we keep a ranking, whether it ought to be from Alexa or somewhere else. But until we have some better alternative, I can't support just removing it. If option 3 with local hosting turns out to be feasible, that would seem the best. We're in 2020; we shouldn't be requiring editor work to update something that could be automated. {{u|Sdkb}}talk 19:49, 18 September 2020 (UTC)
  • Option 2 - They're not even accurate. O3000 (talk) 20:41, 18 September 2020 (UTC)
  • Option 2 They are unencyclopedic. Doesn't matter if we could convince Jeff Bezos to give it to us. We could also automate a feed into {{infobox company}} that pulled in the closing stock price of every public company. But is that what an encyclopedia exists for? No. Infoboxes are for data that is static (or near-static, like a website's owner); data that changes continuously does not belong in the encyclopedia. Much better to use a reliable, secondary source in the article text if a site's traffic is notable, e.g. "As of 2020, is one of the most heavily trafficked second-level domains on the internet" (with a reliable source in a ref tag). UnitedStatesian (talk) 20:50, 18 September 2020 (UTC)
  • Option 2 - The rankings are unencyclopedic, proprietary, inaccurate, constantly changing and a complete waste of time and effort. If a website is popular, or has been popular, we should explain that in the prose in the context of the website's history, not try to reflect the latest internet fads and trends in our infoboxes, without regard to the importance of history and longevity. Kaldari (talk) 20:52, 18 September 2020 (UTC)
  • Option 2 unstable and inconsistent.--Moxy 🍁 22:06, 18 September 2020 (UTC)
  • Option 2. It probably meant something way back when, but now? Not so much. Guy (help! - typo?) 22:07, 18 September 2020 (UTC)
  • Option 2. Anecdotally, I am yet to see an Alexa ranking that actually provided some useful information or was covered reliable sources. The problem is that it's an arbitrary number produced by an unclear algorithm that isn't basing it on something immediatelly tangible (like MetaCritic, for example). And reliable sources do not care to discuss this ranking, nor follow it on regular basis. Infoboxes are already a big dump of all the stats about a topic that don't have sourcing half the time. You'd think that an "Internet score" a website receives would be a big deal, but that's not how reliable sources treat this one. —  HELLKNOWZ   ▎TALK 22:36, 18 September 2020 (UTC)
  • Yup, Option 2, per almost all above, especially the several pointing out the non-encyclopaedic-ness; happy days, LindsayHello 23:16, 18 September 2020 (UTC)
  • Option 2 Unencyclopaedic and partisan faux rankings. Fiddle Faddle 23:39, 18 September 2020 (UTC)
  • Option 3 is the middle road. It recognizes the issues and addresses them - no watchlist churn, fully automated, no manual work required, data is kept up to date monthly for some fraction of the sites, and the rest static links (no ranking data displayed). As for accuracy of Alexa data this is address in the Alex wikipedia article and by JC in the previous discussion. As for unencylopedia, Wikipedia ranks many things, including itself on occasion. All 5,000 sites could be updated monthly with a cheap $25/year WMFoundation grant once the system is working down the road if there was community support for it. -- GreenC 00:54, 19 September 2020 (UTC)
  • Option 2. , but keep them as some sort of periodic table somewhere in the article. They're unstable, and confuse notability with popularity, but popularity is not irrelevant information. But putting the current value in thee infobox is overemphasis. DGG ( talk ) 01:14, 19 September 2020 (UTC)
  • Option 2:
...or just do a google search on "Buy Alexa Traffic".
If anyone with a credit card can inflate a statistic, the statistic is useless as a Wikipedia source. I'm just saying. --Guy Macon (talk) 13:02, 19 September 2020 (UTC)
  • Option 2 We are not shills for corporate America (or shouldn't be). GenQuest "Talk to Me" 13:10, 19 September 2020 (UTC)
  • Option 2 - they aren't a statement of fact about the subject since they can so easily be manipulated. They certainly do not belong in an Infobox. They can be misused for promoting a subject. Doug Weller talk 18:28, 21 September 2020 (UTC)

Discussion (Alexa Rankings in Infoboxes)Edit

My main problem with alexa is "What are we putting into it, and what are we getting out of it?" If we put in a bot, request data from Alexa, or just do it manually, it doesn't really matter if we are putting in more than what we get out of it. So, what are we getting out of Alexa? Do people really come to Wikipedia to know about the Alexa rank? Arsonxists (talk) 17:44, 18 September 2020 (UTC)
  • Have we reached out to Amazon? I'm a firm believer in giving tech giants the opportunity to do the right thing, so that we can hate on them with a clear conscience when they don't. But once in a while they surprise—is there some chance Amazon might be willing to provide us with an account that's not rate-limited so that we could update all the websites monthly? {{u|Sdkb}}talk 19:52, 18 September 2020 (UTC)
    • I doubt that, because Amazon would rather get money then trying to help a minor detail in an Infobox. Maybe if it was crucial to us, maybe we could convince them. But not like this. Arsonxists (talk) 20:00, 18 September 2020 (UTC)
      I imagine Amazon would like to help cement the position of a link to Alexa on every article on a popular website... But this is just an aside from the question of whether or not this information ought to be placed in infoboxes. isaacl (talk) 20:14, 18 September 2020 (UTC)
      • Pretty sure they would get the cemented position, and the money. Having Alexa ranks on here is still a win for Amazon. So they would probably refuse the free account, because why not get the money AND the advertisement? Arsonxists (talk) 20:31, 18 September 2020 (UTC)
        Because the money from one account is nothing to Amazon's revenue, while page rank is gold. And based on this discussion at present, it's far from clear that it's "pretty sure" the ranking information will remain. isaacl (talk) 22:03, 18 September 2020 (UTC)
  • @Sdkb: How is this info encyclopedic? A ranking that changes frequently isn't encyclopedic. Arsonxists (talk) 19:56, 18 September 2020 (UTC)
    @Arsonxists: the thing I said was encyclopedic was a numeric measure of a website's popularity, but an Alexa ranking is one such measure. I don't think the fact that it changes makes it less encyclopedic; it's no different than listing population counts or U.S. News college rankings (both of which we do). {{u|Sdkb}}talk 20:04, 18 September 2020 (UTC)
    @Sdkb: The thing is, things like U.S College elections votes stop changing after a certain amount of time, and U.S population estimates are just an estimate, but Alexa rankings never stop and are NOT an estimate. The ranks change every single day, meaning that it changes too much to be in. encyclopedia. Arsonxists (talk) 20:13, 18 September 2020 (UTC)
  • Increase/decrease icons tangent: In the previous discussion, I see that there was some question as to whether the green/red increase/decrease icons were inappropriate WP:Recentism. Personally, I don't see that as a dealbreaker, but I do think it's bad that the icons don't say what time period is being used for comparison. There's also some potential for better use of templates/automation due to the recent creation of {{fluc}}. {{u|Sdkb}}talk 20:01, 18 September 2020 (UTC)
  • @GreenC: Two things: one, this edit will not have notified anybody (not even Wnt, Xaosflux, Izno, Phil Bridger, Ammarpad, UnitedStatesian, Lkolbly, Jc86035, Newslinger, Kaldari, Guy Macon, Objective3000, Headbomb, DGG, Moonythedwarf, and Arsonxists) because you didn't sign it; two, what is your brief and neutral statement? At over 2,600 bytes, the statement above (from the {{rfc}} tag to the timestamp that I added for you) is far too long for Legobot (talk · contribs) to handle, and so it is not being shown correctly at Wikipedia:Requests for comment/Media, the arts, and architecture. The RfC may also not be publicised through WP:FRS until a shorter statement is provided. --Redrose64 🌹 (talk) 20:33, 18 September 2020 (UTC)
Thanks! -- GreenC 21:50, 18 September 2020 (UTC)
  • Is this something we could work with WikiData on and/or get a WMF grant? WikiData would probably love to host this kind of data and it could populate the infobox from there. A WMF grant could fund the fees for whatever the next tier is so we can make the ~5k requests a month that we need to update these. Wug·a·po·des 23:35, 18 September 2020 (UTC)
    • Looking at the fee structure GreenC linked, even if we wind up with 10k requests a month it winds up being like $5. Wug·a·po·des 23:37, 18 September 2020 (UTC)
Yeah it's cheap, $25 a year for current needs. Without institutional support there is no guarantee payments could be maintained in perpetuity. Regardless of the outcome here, it might still be hosted at Wikidata or Wikicommons, and used for other language wikis. -- GreenC 00:43, 19 September 2020 (UTC)
@I JethroBT (WMF): Could you help us navigate this? A $500 grant could keep this going for 20 years which is a bit longer than the 12 month max for Rapid Grants, so I don't think we'd qualify for any of the grants. Should we be looking at WMF programs other than grants? Wug·a·po·des 01:16, 19 September 2020 (UTC)

Annual visitors parameter?Edit

Okay, so it seems that, unless something changes, the Alexa parameter is on its way out. But I maintain that it is useful to have some sort of metric that indicates the popularity of a website. Would the community support having an |annual visitors= (or |annual pageviews=) parameter? It really doesn't seem all that different than having an annual visitors parameter for {{Infobox museum}}. {{u|Sdkb}}talk 00:47, 21 September 2020 (UTC)

Do you have a source for that data in mind that is likely to be both free of cost and freely licensed? --Izno (talk) 02:33, 21 September 2020 (UTC)
@Izno: I don't think there's any entity that collects that data at scale, so it'd come from individual websites. E.g. for Wikipedia, we'd cite as 882 million[1] Many websites don't release their numbers, but I think it'd be better to include it for the ones that do than to have nothing at all. {{u|Sdkb}}talk 04:21, 21 September 2020 (UTC)
Even for Wikipedia, the stats aren't clear. The figure of 882 million is a monthly rather than yearly figure and represents unique devices rather than visitors. Considering that people browse the internet on phones, PCs, laptops, games consoles, equating unique devices to visitors isn't straightforward. Richard Nevell (talk) 10:02, 21 September 2020 (UTC)


  1. ^ "Wikistats - Statistics For Wikimedia Projects". Wikimedia Foundation. Retrieved 21 September 2020.
But then we're facing WP:V and WP:RS issues. The only people who (possibly) know how many visitors they get are the sites themselves. (And: pageviews I'd believe before visitors.) Such an infobox param supposes we have somebody to trust for their values. — JohnFromPinckney (talk) 09:41, 21 September 2020 (UTC)

Issues raised by Citation botEdit

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
While there were three distinct questions, there was enough interplay between them that I am closing this based on the consensus of the entire discussion rather than merely question by question.

Whether to link
While some wished to do so only in certain circumstances (e.g. if there was a free version), there is consensus for including a link, when an online source is available, from the title text. There is consensus that removing a link requires human judgement.

What to link
There is consensus that what to link should be accorded respect when made by humans (see more in the following section). When deciding what to link in the title, the consensus is that sources which verify the information being cited and sources which are free are top priorities; a lesser factor to consider is whether it is a link to full text or partial (e.g. abstract only). At no time should we be linking to copyright violations.

Duplicate parameters and when to remove
There is consensus against removing a parameter just because it is a duplicate. However, there is an agreement that sometimes removing duplicates can be appropriate. This decision should be made on an article by article basis, unless it is a copyright violation for which there is consensus to remove. Questions that can help guide a discussion include:

  1. Does the functional impact, as currently experienced by readers, of the parameter exactly duplicate another parameter?
  2. Does including a duplicate link help to establish intent of the person adding the citation by helping them to say where they got it or otherwise enhance verifiability in some way?
  3. Is the parameter free or behind a paywall?
  4. Is the link dead? If yes does it make sense to rename it to a different parameter in keeping with question 2?
  5. What will best respect WP:CITEVAR?

These questions should be asked in concert with the consensus around whether and what to link.

Best, Barkeep49 (talk) 04:42, 19 September 2020 (UTC)

Many of you will note that the erstwhile User:Citation bot was blocked about two months ago. After copious discussion, the block has revealed some underlying issues about how we deal with citations, that seem to lack community consensus. The initial block was over Citation bot unlinking sources in reference titles if it was already linked to something like a DOI, or other unique identifier. I thank User:Levivich for the wording of the questions, whose text I snatched verbatim from WP:BOTN :) CaptainEek Edits Ho Cap'n! 20:39, 5 August 2020 (UTC)

I object to the nature of these questions. Each one muddles a principle:
  1. Should the titles in citations be linked, and if so, to what?
  2. Should the titles in citations be linked if that link is a duplicate of an identifier?
  3. Under what circumstances should a title link be removed from a citation, by human or by bot?
with its implementation:
  1. Should |url= be the means of linking to a source?
  2. Should |url= be allowed to duplicate another parameter (or vice-versa)?
  3. Should bots be allowed to make the decision on whether a title link is redundant?
--RexxS (talk) 14:21, 5 August 2020 (UTC)
@RexxS: You are welcome to ask those questions below, though it will make closing all of this quite interesting. I asked these because Levivich seemed to have done a good job summarizing the issues, and nobody objected to them in the last two weeks that they languished at BOTN. Again, I figured that someone needed to get the ball rolling, and that person has consistently been me. CaptainEek Edits Ho Cap'n! 18:46, 5 August 2020 (UTC)
@CaptainEek: An "interesting" close is usually a consequence of not asking straightforward questions. Levivich certainly did a good job of giving an overview of the multiple issues that needed to be decided, but that does not necessarily make a good choice for RfA questions, which should be as clear and focused as possible. I made this point in the prior debate. I'm grateful for you getting the ball rolling, but I still fear that it now be difficult to pick apart editors' opinions on the broad principles from debate on how those might be implemented. It's all too easy to divert attention from the "issues raised by Citation bot" by focusing on the coding of CS1/2 citations, which is a complete red-herring. --RexxS (talk) 21:25, 5 August 2020 (UTC)
  • Comment – there are various ways to link titles in cite templates, that is, apart from |url=,
    • |chapter-url= – for chapter titles
    • |title-link= and, alternatively, a wiki-link of the title
    • |series-link=, for titles of series
    • etc
I assume that these other methods of linking, and not exclusively |url=, are covered by this RfC too. --Francis Schonken (talk) 05:23, 24 August 2020 (UTC)
@Francis Schonken: your comments encouraging specific other people who have expressed opinions elsewhere to bring them here look like WP:CANVASSing to me. —David Eppstein (talk) 06:46, 24 August 2020 (UTC)
No intention to canvass specific people, just trying to get the discussion in one place, as I have done here too. Anyhow pinged the other participant in that talk discussion too, to avoid a perception of unequal treatment. Note that that other participant in that talk page section, i.e. Trappist the monk, had already been pinged here (by Headbomb), without anyone considering that, apparently, selective pinging inviting to participate here. --Francis Schonken (talk) 07:04, 24 August 2020 (UTC)
I was 100% unaware of this discussion until now, but that it quite possibly my own incompetence, I have added a link on the citation bot talk page. AManWithNoPlan (talk) 20:52, 24 August 2020 (UTC)
@AManWithNoPlan: you were notified of this discussion (via ping) on 5 August; and I posted a link to this ongoing RfC on the bot's talk page on 22 August. --Francis Schonken (talk) 04:14, 25 August 2020 (UTC)
I would like to emphasize that despite the fact that I was invited to this discussion, it didn't influence me. I already had unfinished replies laying around in my drafts folder for more than a week and was just lacking the time to finalize them.
As a general remark I would like to see much more constructive and solution-oriented thinking, assumptions of good faith, and less wikilawyering. It's not good for our communication culture and not for the project.
--Matthiaspaul (talk) 13:44, 1 September 2020 (UTC)
  • Comment – I'm apprehensive that the bot, by continued title de-linkings (see e.g. [8]) during the course of this RfC (of which the result is not yet known) would be creating an inadvertent fait accompli situation on many pages. See also WP:ANI#Citation bot. --Francis Schonken (talk) 04:40, 25 August 2020 (UTC)
  • Question The bot was stopped on 2020-06-08 but started again on 2020-08-16. Should it be still running during this discussion? — GhostInTheMachine talk to me 21:02, 3 September 2020 (UTC)

Title linkingEdit

1. Should the titles in citations be linked, and if so, to what (in other words, what should be in |url=)?

  • The title should be linked to free full versions of records when possible, with paywalled links as a distant 2nd option. That doesn't mean that |url= should be populated, however, if it's redundant to an identifier. In the case of a free full version of record, the identifier should be marked as free, so that the title is automatically linked. If the identifier doesn't link to the full full version of record, it can be provided too, but not in |url=. There's partial implementation for this in CS1, but this should be fully implemented. Headbomb {t · c · p · b} 01:46, 5 August 2020 (UTC)
  • Yes, to a free copy of the source or the closest thing to it. "Click on the title, get to the source" is something every reader knows and expects, and we should provide it. If there is a free (non-copyvio) version of the source, that should be linked under the title. If there isn't, then a copy of the source that provides a free preview, if available (e.g. Google Books or Amazon Books). Or, to an "official" copy of the source, if no free copy is available (e.g., whatever the DOI points to). Or, to a library catalog entry, to help the reader obtain the source (e.g. the Worldcat entry). Whatever we can do to get the reader to the source, that's what should be linked under the title in a citation. Lev!vich 01:47, 5 August 2020 (UTC)
  • Titles should be linked whenever there is free full text, as that is what our readers expect to find in linked titles. Our readers don't necessarily know what a PMC, PMID, DOI, SCID, or any other identifier is, but they know if they see a blue title, they can expect to read free full text. Titles should NOT be linked when they ONLY duplicate an abstract available in a DOI. PMC should continue to automatically link to the title, and editors should be able to manually add free full-text links via the URL parameter that are not copyvios but that are free full text. Titles should NOT link to book listings like at amazon or google books unless free full text is available; if the page is available on line, that can be linked in the page parameter. SandyGeorgia (Talk) 01:49, 5 August 2020 (UTC)
    • How sure are we that readers know blue title = free full text? I've asked several academics who are regular Wikipedia users whether they know why some refs have the titles linked and others do not. None knew. Adrian J. Hunter(talkcontribs) 06:57, 5 August 2020 (UTC)
      • They may not expect it to go to exclusively to the free, full text, but I believe that people do realize that it's meant to take them to the article/source (paywalled or otherwise). WhatamIdoing (talk) 14:59, 5 August 2020 (UTC)
      • How can you be an academic without knowing how to look up what is DOI, HDL, PMID, PMC, ArXiv, ProQuest, ISBN, OCLC etc. That is just mind boggling that someone who is supposed to be good at researching and looking stuff up can just throw up their hands at what link to click based on their institutional subscriptions and access.  — Chris Capoccia 💬 18:37, 6 August 2020 (UTC)
        • HDL means "high density lipoprotein", right? I wouldn't expect anyone to recognize the jargon from an unrelated field. WhatamIdoing (talk) 00:09, 7 August 2020 (UTC)
    • there is already a clear way of noting whether something is free text and it's the several icons added with parameters like url-access, doi-access etc. title link does not mean it's free text. it only means someone populated the url parameter with something. it could have even been populated with a broken link.  — Chris Capoccia 💬 14:31, 5 August 2020 (UTC)
      • I doubt that many readers know what those little icons mean. WhatamIdoing (talk) 14:57, 5 August 2020 (UTC)
        • All it takes is a quick mouse-over and the tooltip will tell you what they mean.  — Chris Capoccia 💬 20:11, 6 August 2020 (UTC)
          • Over half of our readers have no mouse, no mouse-over and no tooltips. --RexxS (talk) 21:54, 6 August 2020 (UTC)
            • On mobile, I would still prefer to click on the parameter as I have some idea where that is taking me. Title link does not show even a domain before you go there on mobile.  — Chris Capoccia 💬 22:47, 6 August 2020 (UTC)
  • Yes We link the article title of other sources (newspapers, websites) so no reason why we shouldn't also for journal papers. Readers should not have to follow a blue-underlined random collection of digits and letters (a code). As for only linking to free papers, it may be the only option at the moment to help the reader avoid disappointment that the link provided is not worth clicking. If we had a better way (icon?) to indicate paywalled links (which also applies to newspapers) then this may be less of an issue. -- Colin°Talk 09:27, 5 August 2020 (UTC)
  • Other: This question is confusingly stated. URL should only be populated with something unique that is not duplicate of parameters. The place to complain about parameter access = free not creating a title link is in the CS1. for example, doi-access=free currently creates a title link from the doi. there could be something similar for s2cid-access=free. Users are not stupid. they can click in more places than just the title. It will be perfectly fine for many articles to not have any title links displayed. This is no different than for books. lots of books just have ISBN and users have no problem clicking on that and navigating to how they want to find the book.  — Chris Capoccia 💬 12:07, 5 August 2020 (UTC)
  • Yes per SandyGeorgia. It's fine to do an identifier, but if there is a free version it should be linked in the title whether or not there is an identifier that links to the free version also. --Ealdgyth (talk) 13:40, 5 August 2020 (UTC)
  • Yes The title of a citation is the place where readers are accustomed find a link to the source. Other than a link to a copyright violation, there is no good reason why a link from the title should be removed. The title link should go to the most useful version of the source available. This is a different principle from its implementation (via one or another parameter, which is irrelevant to the principle). --RexxS (talk) 14:14, 5 August 2020 (UTC)
  • Yes, I prefer having links on the title, even if they're "duplicates" and "redundant". I prefer having the most useful URL, but "most useful" depends upon the reader's circumstances, so in the end, any link that makes sense to the editor is okay with me. And before we get too bothered about any of this, let's take a moment to remember that almost nobody reads the refs, and the better the article is, the fewer refs they click on. So let's do something sensible, but let's not spend too much effort trying to achieve perfection, and let's definitely not yell at other editors for putting the "wrong" duplicate and redundant link into the URL. WhatamIdoing (talk) 15:04, 5 August 2020 (UTC)
  • Wrong question. Titles should be linked when the source is a url that is used as a reference. Titles should not be linked when the reference is offline. Titles of references available both offline and online can sometimes be linked as a courtesy to readers. Titles of references that have better online identifiers than urls, such as dois or hdls, should probably not be linked in my opinion, because the link is redundant, but I know others disagree. Titles should not be linked when the link goes to a preliminary version of a publication that is missing the information the reference is used to source. The real answer is "it depends" and that we cannot make a rule for this sort of thing because any rule we make would be broken. In the end there is no substitute for human editorial judgement and intelligence. Trying to replace judgement and intelligence by rules is a mistake. —David Eppstein (talk) 06:38, 6 August 2020 (UTC)
  • Yes, the title should link to the "best" (most useful, free if available, etc.) source if it is online. I don't see an issue with duplicate links: if someone knows/cares about online identifiers and wishes to visit those directly, those links are available for them to specifically click on. Human judgment is going to be necessary in many cases to determine the "best" link, and in those cases a human can put that into the url= field; once that is populated, a bot shouldn't remove it even if it duplicates one of the online identifier links. If there is no manually chosen URL, I'm fine with the title being automatically linked to one of the online identifier URLs if one is available. I agree with WAID above that we really shouldn't overthink/overcomplicate this. CThomas3 (talk) 20:30, 6 August 2020 (UTC)
  • No Wikipedia is an encyclopedia not a search engine. It's the text of articles which is our main output, not the references, which readers pay little attention to. We're already seeing aggressive attempts by bots to insert link-spam; trying to pull readers to their site rather than the competition (e.g. Google Books vs Internet Archive, neither of which wrote or published the books that they are now claim-jumping.) We should not encourage this. Andrew🐉(talk) 11:55, 7 August 2020 (UTC)
  • yes there should be a link if the article can be referenced online, but not always needed. Whether free to access or not does not matter, but we should prefer free where it can be provided. Graeme Bartlett (talk) 12:00, 7 August 2020 (UTC)
  • Yes title link to the actual reference used for the citation. No harm in duplication. · · · Peter Southwood (talk): 14:28, 7 August 2020 (UTC)
  • No — The wikipedia is over-linked as is. A linked title is a link too many. —¿philoserf? (talk) 08:36, 8 August 2020 (UTC)
  • Yes, and to the specific page in question where possible. Adam Cuerden (talk)Has about 7.4% of all FPs 22:39, 9 August 2020 (UTC)
  • Titles should be linked whenever there is any online version of the source available that is not a copyvio. If ther is a free-to-read version that is complete, the link should go to that. if there is no fully free version, but there is a version with part of the source free, such as an abstract, the title should link to that. Failing either of those, the title should link to a fully paywalled version. All of that should be true regardless of whether or not the title link goes to the same place as some identifier link goes. DES (talk)DESiegel Contribs 00:57, 12 August 2020 (UTC)
  • I don't know. For umpteen years I've been linking article names to the source I found it at. An example of my practice can be seen here. Some have been to JSTOR or, some to, some journals have a website with free copies, such as Bulletin of the American Society of Papyrologists, & some to slightly sketchier sources. (No, none to SciHub, nor do I plan to. At least not yet.) I've always felt this was not entirely right, & sometimes thought setting out a source like JSTOR or doi separately would look more professional; it would match current practice with the ISBN template; of course if I ever submitted an article I largely wrote to the GA or FA process I would have to rewrite it beforehand to use one of these template, so there's that. Lastly, I have to admit that none of the votes above have convinced me to either continue my practice or change it. -- llywrch (talk) 06:36, 12 August 2020 (UTC)
  • Yes, if there is an a URL link inserted in the template, it should be dispalyed in the title, despite all other identifier. Like that, when you click on the title, you access the link inserted by the editors. --Anas1712 (talk) 00:00, 13 August 2020 (UTC)
  • Wrong question ... modules should be used to generate urls when there is a full text version, such as |pmc-access or |doi-access. No, there should not usually be any link to a paywalled source in the URL because it does not help our readership, very few people are willing to pay $$$ in order to check a WP reference. (Unless the content can be verified to a preview or there is no other identifier to uniquely identify the source). (t · c) buidhe 03:29, 13 August 2020 (UTC)
  • Example: I was just reading holocene extinction. I wanted to read one of the sources. The cite ref looks like this:

    Ceballos, Gerardo; Ehrlich, Paul R. (8 June 2018). "The misunderstood sixth mass extinction". Science. 360 (6393): 1080–1081. Bibcode:2018Sci...360.1080C. doi:10.1126/science.aau0191. OCLC 7673137938. PMID 29880679.

    I don't know which one to click on. Turns out none are free, but the second one (doi) will take you to a first-page preview. That second one should be the link for the title, so no one else has to check all four to figure that out. I will add the |url= to this citation. I hope no bot comes along and removes it because it duplicates an identifier. :-) Lev!vich 04:10, 16 August 2020 (UTC)

  • Yes. The title of a citation is the most intuitive place for readers to find a link to the source, and they shouldn't be expected to understand all the citation word salad to find out where the link otherwise might be. If there's no free source available, it should link to the most useful - and which that is should be down to the editor discretion. Boing! said Zebedee (talk) 16:33, 17 August 2020 (UTC)
  • Yes, to the most useful link, and failing that, at least to the WP:SAYWHEREYOUGOTIT link, per current guidance, if that was the source of the content that was added to the article. --Francis Schonken (talk) 04:28, 24 August 2020 (UTC)
  • Yes, but question simplifies too much. Titles should, whenever available, be linked to the most relevant, specific and suitable online resource. While it is nice if the link points to a free resource, being free is not (and never was) a requirement for a link to be provided, however, being relevant in the context of the citation is. By default, the link should point to where the cited source was found by the editor who added a citation in order to satisfy our core principle of verifiability (WP:V). If that happens to be a paywalled link or limited in other ways, this may make verification more difficult for readers, but this is irrelevant in regard to being a proper link in a citation or not. If multiple links are available, it should be in the editor's judgement which link to include, ideally it would be a deep link to the actual document (f.e. a PDF, ZIP, etc.), not only to a meta-page, because the document itself is the most relevant thing in regard to verifiability and the readers' interest who want to study that resource. Ideally, this document should be archived and an |archive-url= link provided as well. Since archived links cannot be given for identifier links, since |archive-url= and |url= should remain in sync, and also because identifier links often point to meta-pages only rather than the actual document supporting a statement, the link associated with the title should be provided by |url= and have priority over secondary links derived from identifier parameters. (Likewise for |chapter-url=.) So, ideally, |url= would point to the actual document, and the identifier links further down in the citation would point to various meta-pages providing additional context (and from which instances of the actual document are typically also available). If, however, the actual document would be already provided by a deep link through one the provided identifiers, |url= would be free to possibly provide an alternative (better qualitity, cheaper, fallback etc.) source for the document (as a convenience link) or to yet another relevant page not covered by the identifier links already. So, what's best in the interest of the readers and the project in regard to verifiability, readability, completeness, stability, availability, etc. actually depends on the circumstances, and it is necessary to apply good common sense on a citation-by-citation basis. --Matthiaspaul (talk) 20:00, 24 August 2020 (UTC)
  • A few people are answering the wrong question - but not all. This discussion is not about removing all title links, just redundant ones. AManWithNoPlan (talk) 11:30, 25 August 2020 (UTC)
    • If you read what people are telling you in this section, you'll realise that there are no redundant title links. Title links, where available, are desirable and your bot should not be removing them. --RexxS (talk) 22:22, 25 August 2020 (UTC)
      • I did read them and I am correct about some. I rufused to point out who since that would be be rude to squash peoples contributions durig a discussion and i trust any counting votes to not be so stupid as to just add up yes and no. AManWithNoPlan (talk) 00:51, 27 August 2020 (UTC)
  • Often Impossible to say where you got it or more correctly, add people and bots add more identifiers, there is no way that a reader can know this. Many citations start with a DOI, and then someone later adds the URL (research gate, handles, etc) or visa-versa. Only by looking over the editing log can you find where the very first reference is in the WP:SAYWHEREYOUGOTIT sense. BUT, that only tells you the first person to read the reference. You have no idea how later editors found it. Secondly, the original editor might have use a publisher URL, and then linked to the pubmed instead because the PMID was in the URL. AManWithNoPlan (talk) 16:14, 28 August 2020 (UTC)
  • Yes, using the title-link parameter, URL for clickable arrow. Titles in citations should be linked to a Wikipedia article about this source using the title-link parameter (e.g. |title-link=The Great Gatsby) and only in this case should the title appear in blue (not a common case). Clicking the arrow after the title should open the website defined in the Url parameter (e.g. |url= showing the title page of the source text. Other unique identifiers may be given such as DOI, ISBN, JSTOR, etc. but always in addition to the URL, as the reader may not understand them. The bot may update or correct the URL but should never remove it. Johannes Schade (talk) 16:12, 31 August 2020 (UTC)

Duplicate linkingEdit

2. Should the titles in citations be linked if that link is a duplicate of an identifier (DOI, PMC, PMID, etc.) (in other words, should we have |url= even when it is duplicative of, e.g., |doi=)?

  • No, in the sense that having a |url= that duplicates a |doi= is pointless redundancy. This is why we have |doi-access=free, to mark the DOI as free and have them automatically linked, and remove the necessary duplication. Headbomb {t · c · p · b} 01:41, 5 August 2020 (UTC)
  • Yes if and only if the DOI, PMC, or whatever contains freely accessible full text, no if it is only to an abstract or full text is paywalled. SandyGeorgia (Talk) 01:50, 5 August 2020 (UTC)
  • Yes, titles should be linked even if the link is duplicative of an identifier such as DOI, and regardless of whether it's free or paywalled. The reader knows and expects to click on the title to get to the source. The reader will probably not know what the links marked "DOI", "PMC", etc. are. Even if we put lock symbols next to them to identify which ones are free, and links to "DOI" and "PMC", etc., to explain what they are, this is just asking the reader to do more work to get to the source: (1) they have to know what DOI/PMC are or else look it up, (2) if there is more than one, they have to choose which one to click on, (3) if some are free and some are paywalled, they have to learn what the lock symbols mean, and (4) if there is more than one free one, they have to choose which free one to click on. "Click the title, get to the source" is what the reader knows and expects; whether the same thing is linked elsewhere in the citation is irrelevant to the reader. It is we, the editors, who should "pick" which version of the source is the "best" version for the reader, and we should put that as a link under the title. Then the reader just knows to click on that one to get to the best one. And even if it's not free, they'll know that's the place where they can obtain a copy. On top of the reasons to link the title, there are really no reasons AFAIK not to link the title to the best available source--who cares if the title link is duplicative of an identifier? Lev!vich 01:54, 5 August 2020 (UTC)
  • Yes. Ordinary readers assume that clicking on a title link will take them to that document. They may not know what a "DOI" is and what clicking on it achieves. – Finnusertop (talkcontribs) 08:54, 5 August 2020 (UTC)
  • Yes and no per Sandy. -- Colin°Talk 09:22, 5 August 2020 (UTC)
  • Other only by way of parameter - access = free. for example, doi-access=free. URLs that duplicate parameters should not be manually populated in URL and bots should be free to remove duplicate URLs and move URLs to parameters.  — Chris Capoccia 💬 12:09, 5 August 2020 (UTC)
  • Yes per Sandy and Colin. --Ealdgyth (talk) 13:41, 5 August 2020 (UTC)
  • Yes the links from identifiers are not relevant to most readers and the citation title should always link to the most useful online source that is not a copyright violation. The parenthetical question makes assumptions about the implementation that may or may not be true and muddies the issues, which should be a clear principle. --RexxS (talk) 14:26, 5 August 2020 (UTC)
  • Yes, I prefer including a "duplicate" URL. If an editor has placed a "duplicate" URL in the citation, then it should generally not be removed as being redundant. WhatamIdoing (talk) 15:08, 5 August 2020 (UTC)
  • I prefer no but I recognize that other editors might disagree. This is not the sort of thing we need rules over. As long as it is consistent within an article, WP:CITEVAR should be controlling. In particular we should not be hacking citation templates to force one side of this debate to get its way, and we should not be using robots to add or remove these links. Incidentally, it is important to recognize that some doi-linked citations DO NOT HAVE A TITLE to which a url can be linked, and are valid as citations with a doi but become invalid if a url is added; a bug in some citation templates related to this that broke the references in multiple articles was fixed only this week. —David Eppstein (talk) 06:40, 6 August 2020 (UTC)
  • Yes, I think it is important not to delete a URL that has been deliberately placed in the url= field, regardless of whether it duplicates one of the other available URLs. Even if the behavior of the template is currently such that the desired link will still appear without the explicit URL, that may not always be the case: for example, a different link may be automatically substituted if a new identifier is added, or someone may change the default behavior of the template. The only upside I see of deleting the link is saving a few bytes of storage space. CThomas3 (talk) 20:43, 6 August 2020 (UTC)
  • Yes no need to remove if a formatted ID duplicates the link. But also no need to add an identical link later if something like DOI covers it. The URL if given is what the reference supplier used to access the page. Graeme Bartlett (talk) 12:02, 7 August 2020 (UTC)
  • No Raw links are inferior to persistent identifiers because they tend to break over time. And, again, Wikipedia is an encyclopedia not a search engine. Andrew🐉(talk) 12:06, 7 August 2020 (UTC)
  • Yes link the title to the source actually used. No problem if it duplicates a DOI. Not needed if DOI is there from the start, but do not remove if it exists. · · · Peter Southwood (talk): 15:14, 7 August 2020 (UTC)
  • No — The wikipedia is over-linked as is. A redundant link is a link too many. —¿philoserf? (talk) 08:36, 8 August 2020 (UTC)
  • Yes, this is an enhancement of WP:V. Reducing steps between readers and sources is a good thing to do, and a link in the title is more accessible to those who are unfamiliar with persistent identifiers. (If a field other than url= automatically links the title to a specific webpage, I find that comes to much the same outcome for the reader and have no view on whether url= is preferable if it would link to the exact same page.) CMD (talk) 17:25, 9 August 2020 (UTC)
  • Yes It's simpler and can often avoid multiple clicks to actually get to a text. Adam Cuerden (talk)Has about 7.4% of all FPs 22:43, 9 August 2020 (UTC)
  • Yes The title link should always be present, even if it exactly duplicates an identifier link. If this link will be generated automatically by the template/module based on the other parameters, the |url= parameter can be left blank (or better yer, set to an HTML comment explaining why it is blank), but the title link should always be present, even if it is redundant to an identifier link. DES (talk)DESiegel Contribs 01:03, 12 August 2020 (UTC)
  • No. Per Headbomb. --Bsherr (talk) 02:17, 12 August 2020 (UTC)
  • It depends, if the URL is only "" or similar like that, no. But if it's the link is the one from the paper's own page on the academic journal's website, then I feel that it's not necessary to remove it, even if it's duplicating the "Doi" parameter . In fact, in several cases, the insertion of the web address of the paper in question makes it possible to add the date of access. However, when we apply CitationBot on a Wikipedia page, most of the time, in the cases mentioned above, the URL and the accessdate are deleted. Therefore, we cannot know when the reference was added. -- Anas1712 (talk) 00:00, 13 August 2020 (UTC)
    • Access dates are not relevant for papers published on specific dates. If you accessed doi:10.1007/lrr-2016-1 2 years ago, if you access it today, or access it in 2 years, you will always be presented with the same version of the paper. Access dates are relevant for websites that can change, like this story for NY Times. If you access it in three days, you may not see the same content you are seeing now. Headbomb {t · c · p · b} 20:30, 25 August 2020 (UTC)
      • [Slightly off-topic] Oddly enough, the documentation for {{Cite web}} claims "Access dates are not required for links to ... news articles with publication dates. I agree with your interpretation, Headbomb: even an online newspaper with a publication date can change after a while, and that documentation is badly flawed. --RexxS (talk) 22:31, 25 August 2020 (UTC)
        • Should be revised to cover online access of print sources. A NY Times article from 1993 can have a web version, but it'll still be stable, because then the NY Time was a print publication and there is no difference between the two. In 2020, when you cite the NY Times, you are likely citing the web version, which is not necessarily stable like the print edition is. Headbomb {t · c · p · b} 22:39, 25 August 2020 (UTC)
          Headbomb, Even in the print version of the NY Times, there would be several editions printed during the day, and coverage would get updated for breaking stories. I used to get the early edition of the NY Times at about 10 PM the night before the nominal publication date. I guess that ended in 1997, though:
          There were also regional editions; the version sold in the city was slightly different from that sold on Long Island, suburban New Jersey, etc. The bottom line is that just citing a date and page number for the NY Times isn't actually enough to definitively locate a printed article. You also need to know which edition. I assume this was equally true for other papers. I suspect the vast majority of people who cite articles don't do this. -- RoySmith (talk) 22:56, 25 August 2020 (UTC)
Then that's what |edition=Evening/Morning is for, not |access-date=. Headbomb {t · c · p · b} 22:57, 25 August 2020 (UTC)
  • Wrong question this functionality can and should be obtained using |doi-access=free and similar, rather than using a duplicated URL parameter. They should not be linked where it just takes the reader to a paywall, because that doesn't help them. It's wrong to assume that links to URL have been placed deliberately; most of them are likely automatic where people use the url to generate a citation. (t · c) buidhe 03:33, 13 August 2020 (UTC)
  • Yes. The title, as the most intuitive place to find it, is the most important place for the link. That other parameters might also link to the source is not a good justification for not having the link in the title. Boing! said Zebedee (talk) 16:38, 17 August 2020 (UTC)
  • This question doesn't mean anything, or the first wording means the opposite of the second (after "in other words"). "Linking" and "filling a certain parameter" are not the same thing. Discard all the answers above. Nemo 11:04, 21 August 2020 (UTC)
  • Yes it is appropriate to link the title even if that link is already present in the list of identifiers. As a reader I prefer clicking on a title than having to know how bibliographic identifiers work to select the most appropriate one. − Pintoch (talk) 11:34, 21 August 2020 (UTC)
  • Yes, among a choice of links in the template, the link of the title can, and probably should, duplicate the most useful one, or at least the WP:SAYWHEREYOUGOTIT one. --Francis Schonken (talk) 04:28, 24 August 2020 (UTC)
  • Yes We link titles as a standard practice, I think it would be confusing to the reader as to why some titles are linked and others are not. I think Rexx's point below about teaching computer skills is also relevant here. I like the WP:SAYWHEREYOUGOTIT point, I think the URL in the title should be the one where the source was originally procured from, even if that is going to duplicate things. CaptainEek Edits Ho Cap'n! 09:11, 24 August 2020 (UTC)
  • Yes whenever the DOI etc. leads to a paywall but the text is freely and legally available at a URL, even if that URL is a preprint etc. Certes (talk) 10:31, 24 August 2020 (UTC)
  • No unless it is a completely free copy, which should be generated by a template parameter. WP:SAYWHEREYOUGOTIT is not applied correctly here as it explicitly states " does not matter whether you read the material using an online service..." AManWithNoPlan (talk) 20:41, 24 August 2020 (UTC)
    • WP:SAYWHEREYOUGOTIT requires the editor adding content from an online resource like a PubMed abstract to give a link to the resource they used. The title link is the obvious place for that. Yet you're advocating removing those title links contrary to policy. --RexxS (talk) 21:06, 24 August 2020 (UTC)
  • It depends. If the link provided by |url= is pointing to exactly the same page as one of the links derived from the provided identifiers, we don't need to duplicate that link in |url=. (I'm impartial in regard to if links only resolving to exactly the same target page should be regarded as being "equal" as well, because the behaviour of resolvers and redirectors may change over time, and it may be good to have an alternative link.) As a convenience to users who don't know what identifiers are and never click on them, the title could still be linked to this page through (manual or priority-based automatic) auto-linking, however, it is important that editors always have full control if auto-linking should be provided by the template at all and if so, which identifier should be selected. If |url= or |title-link= are provided, they must always have priority over identifier-derived links. However, if the URL and the identifier link point to the same site, but not to exactly the same page (f.e. if the identifier link points to a meta-page, and the URL to the actual PDF), these links are by no means "equal", and the link provided through |url= should never be considered "a duplicate", "redundant" or "equivalent" to the identifier link. Since some users lump these definitions together semantically the exact wording is relevant here. --Matthiaspaul (talk) 20:43, 24 August 2020 (UTC)
Following up on my comment above, I would like to add that even in cases where the |url= is an exact duplicate of an identifier-derived link, I consider the removal of |url= inappropriate if |archive-url= is given as well. Some identifier-derived links are intended to be semi-permanent, but ultimately they are subject to link-rot as well, so it is good to keep archived versions around. If someone has gone the extra mile to provide an archived snapshot for such a link, we should be thankful for this contribution instead of destroying it. I would change my mind on this only if our citation templates would introduce means to provide link archives for identifier links as well. --Matthiaspaul (talk) 13:25, 1 September 2020 (UTC)
  • Yes. The arrow after the title should be linked to the website in the Url parameter even if other unique identifiers are provided. Johannes Schade (talk) 16:17, 31 August 2020 (UTC)

Link removalEdit

3. Under what circumstances should a title link be removed from a citation, by human or by bot (in other words, when should |url= be blanked)?

  • When redundant to identifiers, per Template:Cite journal#Identifiers, or when it's a paywalled link that doesn't add anything to the links already present e.g. a EBSCO paywall link does not add anything that a DOI already provides. Headbomb {t · c · p · b} 01:48, 5 August 2020 (UTC)
  • If the URL linked to the title does NOT go to free full text, and is repeated in another identifier, it can be removed. Other than that, no one (human or bot) should be removing links to free full text, particularly per WP:CITEVAR and the need to provide accessibility to readers. SandyGeorgia (Talk) 01:52, 5 August 2020 (UTC)
  • Not when redundant to identifiers for reasons in my !vote to Question 2 above. Never by a bot because the URL was likely placed there by a human being, who decided that this link was the best link for the reader. A bot shouldn't overrule that human decision. (Note: replacing dead URLs with live or archived URLs is not removing or blanking |url=, and thus could be done by a bot.) Only with good reason by a human - if it's copyvio, if it's a dead link, or if there's some other good reason. I trust humans to make these decisions on a case-by-case basis in a way that a bot cannot. I'm particularly concerned that people will take the time to carefully select URLs to link to, and it'll be erased en masse by a bot. (Which is kind of what led to this bot being blocked in the first place, I believe.) Lev!vich 01:58, 5 August 2020 (UTC)
    • There is zero reason to have both |pmc=91234 and |url= Likewise for having both |pmid=91234 and |url= There is likewise no issue to clean this pointless redundancy by bot. Headbomb {t · c · p · b} 02:00, 5 August 2020 (UTC)
      The reason to have both is what I said in my !vote in #2 above: to always make it so "click the title, get to the source", so the reader doesn't have to think about which of multiple links is the best one to click on. And I know that you've said that we should accomplish that by removing the |url parameter and instead having a blank |url parameter "auto-fill" effectively with the |doi or whatever, but that's not how CS1 templates work, and the maintainers have previously said that it's not how they're going to work any time soon. So until then... Lev!vich 02:04, 5 August 2020 (UTC)
      That neglects three things. 1) PMC already autolinks the title. 2) A PMID link will take the place of a free version of record, like PMC, if it's declared in the URL, or one that could be found, but isn't added yet. 3) If there's a consensus to always link the title, no matter what, then that can happen automatically and there's no need to have the pmid url in the url parameter when it can just be generated from the pmid parameter. Headbomb {t · c · p · b} 02:11, 5 August 2020 (UTC)
      When |pmc= already exists, and results in the same reader-facing output as a |url= with a link to the same PubMed Central page, then removing the redundant URL would fall afoul of WP:COSMETICBOT. WhatamIdoing (talk) 15:12, 5 August 2020 (UTC)
      Cosmetic doesn't prevent edits, if other stuff is happening. -- GreenC 15:18, 5 August 2020 (UTC)
      Yes, but that little "if" adds a layer of complexity, both in programming the bot and in all of us humans reading the unnecessary changes via diff. WhatamIdoing (talk) 23:14, 5 August 2020 (UTC)
  • What Sandy said. I don't quite understand what Headbomb is saying about autolinking. From a user point of view, I want article titles linked to the URL of the paper if it is available freely, with the official publisher URL in preference to the PMC URL. I don't want users to have to click on links that are only available in codes (PMC/PMID/DOI) because they won't all understand that, and isn't consistent with how other sources (newspapers, websites) work for linking in references. Any URLs in the codes are a bonus and I don't care if they duplicate the link in the title. -- Colin°Talk 09:16, 5 August 2020 (UTC)
    I think Headbomb means Help_talk:Citation_Style_1#Auto-linking_titles_with_free_DOIs and Wikipedia:Village_pump_(proposals)#Auto-linking_titles_in_citations_of_works_with_free-to-read_DOIs. The CS1|2 template will autolink the title. -- GreenC 14:25, 5 August 2020 (UTC)
  • Guiding principle must be that URLs can break and parameters are always preferred. URLs that should more properly be represented by parameters should be moved from the URL field and translated to the correct parameter. If the correct parameter is already present, the redundant URL should be deleted. URL should also be deleted for facilitating copyright violation, although I'm not sure this will be able to be managed by bots.  — Chris Capoccia 💬 12:12, 5 August 2020 (UTC)
  • Should not be removed if the url is to free text ... whether or not there is an identifier link and whether or not that identifier link is redundant. --Ealdgyth (talk) 13:43, 5 August 2020 (UTC)
    What about 'redundant autolinked title links'? -- GreenC 15:18, 5 August 2020 (UTC)
  • The citation title should always link to the most useful online source. The only reason to remove a title link is when it points to a copyright violation. That is a decision that can only be made (and debated) by a human. A bot should never make an edit that has the result for the readers of removing a link from a citation title. --RexxS (talk) 14:31, 5 August 2020 (UTC)
    • There is zero point in having both |pmid=91234 and |url= just for the sake of preserving a link. Or redundant links to paywalled resources. Headbomb {t · c · p · b} 14:36, 5 August 2020 (UTC)
      • But is there any point in flooding everyone's watchlists to remove the URL? WhatamIdoing (talk) 15:14, 5 August 2020 (UTC)
        So, the hard-coded URL dies or changes. It's trivial to fix the autolinking in the central CS1|2 cfg. But, IABot is going to detect the dead static URL in the individual cite, and add an archive URL. Now we have a cite that is not properly autolinking because there is a dead URL in |url= field taking priority, with an unneeded |archiveurl= that probably should be removed along with the static URL. OR, we can proactively remove the redundant URL to prevent a future mess. -- Green<span style="color:there should be a link on the title (and note that some of the people who voted No were answering a different question, whether |url= should be filled). #093;">C 15:28, 5 August 2020 (UTC)
        Or we could assume that scenarios based on PubMed Central (part of the US National Institutes of Health) going offline, or them not being able to find their own documents when given their own ID numbers, are just not very compelling. WhatamIdoing (talk) 23:20, 5 August 2020 (UTC)
      • There is every point in having a link from the title, and it shouldn't have a bot removing it. Nobody cares about the detail of the implementation except a bunch of techno-geeks. The reader comes first and they don't care what parameters we have in the wikitext, they just want to click the title to get to a source, and a bot should should never be making an edit that removes that from them. --RexxS (talk) 16:35, 5 August 2020 (UTC)
        If it's so trivial to fix the autolinking, why hasn't it been done after three months? Even then, the hard-coded url can still be needed when a free directly-accessible source is not linked from any identifiers. It's also necessary to allow an archived url to be directly linked from the citation title, which the bots seem incapable of sorting out – a far better solution than preemptively removing links in case they become dead links. --RexxS (talk) 16:35, 5 August 2020 (UTC)
        Because CS1 updates are basically contingent on User:Trappist the monk deciding it's time to do an update. It's not, in theory, a limitation, but you need to know LUA and to be an admin to update the CS1/2 modules. But this isn't a particularly hard thing to do for those with the skills. Headbomb {t · c · p · b} 18:06, 8 August 2020 (UTC)
        Ah, but RexxS does know Lua, and is an admin - indeed, when I have a lua problem, I prefer to go to RexxS and not Trappist. --Redrose64 🌹 (talk) 19:44, 8 August 2020 (UTC)
        Nevertheless, Trappist has put a huge amount of effort into creating and maintaining the CS1/2 modules. That means Trappist has a far better overview of the intricacies and features of that module than I have. I would not feel comfortable editing any of those modules, principally because I would automatically defer to the maintainer of a module to know better than I. The same would apply, for example, with Johnuniq's convert modules. --RexxS (talk) 20:55, 8 August 2020 (UTC)
        Can you verify if this is autolinking?
        In this example it would be redundant to add |url= because it is the same URL as is already generated - most everyone agrees about this. In terms of archives, is unlikely to completely die rather change its URL syntax (the base URL) which can be easily "fixed" in the template cfg, the same way we could with external link templates like {{gutenberg author}} should they ever change base URLs. If it did completely die we'd probably change to a different ID provider as the default autolinking. The bot's don't currently archive ID URLs at this point but given the uncertainty they should wait to determine the outcome, and there is no technical reason they could not do so. BTW my professional training is History. I suspect you are more techno geek than myself. But I don't hold it against you :) My interest is the humanities and the technology that makes it more accessible to a broader public. -- GreenC 20:35, 5 August 2020 (UTC)
        @GreenC: I can verify that the citation you quote is linking the title, but I seriously doubt that there's anything automatic about it. You'll appreciate that
        also has the title linked. Does that make the doi redundant? They all link the title to the source, so does messing with those actually benefit the reader?
        What about these citations? Why would we change the first for the second?
        How did this edit benefit the reader?
        FWIW my first degree was in electronic engineering, but that was in 1972 and there were no geeks in those days. :( --RexxS (talk) 22:15, 5 August 2020 (UTC)
        The |pmc=2732656 instructs the template to automatically generate a title URL. Which is my understanding of autolinking. The ID |pmc=2732656 and the |url= generate the same title link thus redundant, do we keep both anyway? You are correct we should not change the first for the second, since that would eliminate the title link with no new link being generated. Well you are about a generation, I'm 92' .. they were nerds when it meant something. -- GreenC 23:56, 5 August 2020 (UTC)
        @RexxS: The edit you questioned, removing a direct link to Semantic Scholar and replacing it by an S2CID id, benefits the reader by not misleading them into thinking that they can follow the link to find the actual reference, when in fact they will only find a landing page there telling them that they should have followed the DOI instead. —David Eppstein (talk) 06:47, 6 August 2020 (UTC)
        @David Eppstein: removing a link to a version of the source (which will then take them on to a full version) and replacing it with nothing does not benefit the reader. Most readers don't understand s2cid or doi, so editors should not be forcing them to fit their preferred way of working. When will they realise that the change needed in that edit was to link the title to a better site in order to improve it, not to remove it altogether and make it worse? --RexxS (talk) 16:24, 6 August 2020 (UTC)
        When you say that replacing a link on the title to a link on the S2CID is removing the link altogether, I think you are ridiculously overexaggerating the issue. And when you say that readers are incapable of understanding links described as identifiers and are only capable of finding and following links when those links are placed on the title of a reference, I think you are grossly underestimating the competence of readers. —David Eppstein (talk) 19:01, 6 August 2020 (UTC)
        And I think your personalisation of genuine issues detracts from the seriousness of the problems. Removing a link from a citation title should not be happening because readers expect the link to be there. You are attempting to brush the issue aside as if doesn't matter. Well it does. Likewise you are not displaying any understanding of the difficulties that ordinary readers experience in trying to make sense of a plethora of different acronyms and symbols. Not everybody is as technically gifted as you and you overestimate the willingness of a reader (who just wants to see a source) to learn jargon designed for use by academics who use it on a daily basis. --RexxS (talk) 21:51, 6 August 2020 (UTC)
        It's not a question of learning jargon. It's a question of being capable of noticing that something in the reference is linked and seeing where you go when you follow that link. If you can't do that, you also can't use Wikipedia, use the web, or follow links in titles. —David Eppstein (talk) 01:12, 7 August 2020 (UTC)
        If you'd spent as many years I have teaching adults, especially those as old as I am, basic computing skills, you'd soon revise your "being capable of noticing that something in the reference is linked and seeing where you go when you follow that link. If you can't do that, you also can't use Wikipedia, use the web, or follow links in titles. Giving folks predictable pathways, such as "clicking on a title takes you the source" is precisely how they become able to use Wikipedia, and use the web, and follow links in titles. --RexxS (talk) 16:49, 8 August 2020 (UTC)
  • Remove per Chris Capoccia and Headbomb, if the CS1|2 template is already autolinking the title field (per RfC consensus and ongoing discussions at Help_talk:Citation_Style_1) there is no logical reason or purpose to have a redundant URL in the |url= field. If the URL is not redundant ie. they are different URLs, it should not be removed since the |url= is a manual override of the autolink. -- GreenC 14:37, 5 August 2020 (UTC)
  • Only ever by a human, and only for the purposes of making the citation style within an article consistent with its prior state, per WP:CITEVAR. —David Eppstein (talk) 06:41, 6 August 2020 (UTC)
  • The bot shouldn't, and a human should only do so to consciously choose to a better/more appropriate link, not because it's redundant. CThomas3 (talk) 20:52, 6 August 2020 (UTC)
  • Only remove the link if it goes to a deprecated site, (such as copyright violating or dead) or is wrong. Don't bother removing it just because of PMC or DOI or the like. That is just cluttering up watchlists for no benefit. Of course the other parameters can be added even if there is a link in the title. Graeme Bartlett (talk) 12:07, 7 August 2020 (UTC)
  • Ban bots We can't have bots run by paid SEO editors fighting to insert their preferred links. Per WP:CITEVAR, the issue should be left to discretion of the human editor who actually used the source in question to support some text in the article. Andrew🐉(talk) 12:11, 7 August 2020 (UTC)
  • If it aint broke don't fix it. · · · Peter Southwood (talk): 15:18, 7 August 2020 (UTC)
    To clarify: I don't think it is broken and don't think it needs fixing. If the title link url works, leave it alone. · · · Peter Southwood (talk): 10:57, 9 August 2020 (UTC)
  • It is broke. Let’s fix it. Any redundantly linked title should have the |url= removed. The wikipedia is over-linked as is. A redundant link is a link too many. —¿philoserf? (talk) 08:36, 8 August 2020 (UTC)
  • The link from the title should never be removed, evven if it is redundant. If, and only if, the template/module will generate this link automatically based on other parameters, |url= may be set to blank, or better to an HTML comment explaining why, but not otherwise. All this is assuming that the article uses CS1 or CS@, of course. DES (talk)DESiegel Contribs 01:08, 12 August 2020 (UTC)
  • Never by a bot bots should not be going around second guessing decisions made by actual humans. I would support a bot identifying cases that need human attention, but never making these sorts of changes themselves. - Nick Thorne talk 23:54, 13 August 2020 (UTC)
  • Per RexxS above, the citation title should always link to the most useful online source (barring copyvio). I don't know if there might be cases where there's a good argument for not having the link (unlike Holmes, I don't claim to be able to eliminate all possibilities). But if there is, then it needs to be decided by a human. The link should never be removed by a bot. Boing! said Zebedee (talk) 16:44, 17 August 2020 (UTC)
  • Don't change, unlike there's an open-source access to the full paper, but that's the purpose of OABOT, so maybe allows in precise cases, but not to generalise to all. The primary policy is to not remove utile information that is already present. The objective of the bots in citation maintenance is to help the wikipedians to add informations and to automatise the search of informations, to make sure the citation is more precise and more accessible. Voilà, voilà. --Anas1712 (talk) 14:42, 18 August 2020 (UTC)
  • Don't remove title links on the basis that they duplicate identifiers. It is fine to remove a |url= if the template will generate the same link on the title via auto-linking, but not otherwise. − Pintoch (talk) 11:37, 21 August 2020 (UTC)
    • It's also more than fine to remove links that lead to databases without any possibility of free versions (like pubmed), to paywalled papers (like EBSCO and proxies), to preprints (like arxiv). Headbomb {t · c · p · b} 15:27, 22 August 2020 (UTC)
      • It's not fine to remove the link to where the editor found their source per WP:SAYWHEREYOUGOTIT. If they found their information at a PubMed abstract article, we should be giving the editor the ability to indicate that via the title link, and we should be giving the reader the opportunity to follow the intuitive link to the source used in writing the text. We should not be having those swept away by the bucketload by a capricious bot. --RexxS (talk) 21:03, 24 August 2020 (UTC)
  • The content of |url= should be decided on a case-by-case basis, by human editors, not modified by bot – a bot is welcome to address malformed links, permanently dead links etc, but should not modify the intent of human editors. --Francis Schonken (talk) 04:28, 24 August 2020 (UTC)
  • Never by bot and very rarely by human I cannot think of a good reason for a bot to remove the URL parameter. I cannot think of a reason beyond copyright violation for a human to remove the URL, though I assume there must be some reason I haven't dreamt up :) In general, Rexx's point about having consistently linked titles wins me over, and thus I think this is a good reason to keep titles linked. Humans can always use their best judgement to figure out if a link needs to go, but I see no need to have CitationBot doing that. CaptainEek Edits Ho Cap'n! 09:17, 24 August 2020 (UTC)
  • When redundant to identifiers Linking to non-free copies with the title leads to reader confusion when they expect a title link to actually link to something useful. Cannot believe that I was not aware this discussion was going on until now. AManWithNoPlan (talk) 20:44, 24 August 2020 (UTC)
    • Identifiers are inferior to title links because readers understand and expect title links. Your bot is happy to remove title links that go to pmc urls. Those sort of links – the ones used by the editor to add text – are useful title links, and no reader is going to be confused if they are allowed to follow those sort of links. --RexxS (talk) 21:03, 24 August 2020 (UTC)
  • Only when identical to other links. There is no point to keep an |url= link if it points to exactly the same page as an identifier-derived link. This is the only case when (automatic) removal of |url= is justified (except for if it would point to illegal contents which always justifies its removal), and this is also the only case for which we actually had community consensus. If |url= resolves to exactly the same page, |url= may be removed by a human after applying editorial judgement, but it should not be removed by a bot because a bot cannot apply the necessary editorial judgement, if the resolver will, with high certainty, resolve to the same page into the long-term future, or if it may change over time. A link pointing only to the same site (like links to the direct document vs. to a meta-page) is not "equal" and must therefore never be considered "redundant", "equivalent", "duplicative", etc., and consequently it must not be removed. (Since some users lump these definitions together semantically, the exact wording is important.) Also, |url= pointing to a non-free or restricted-access resource is never a valid reason to remove a link per our core policy on verifiability WP:V and the principle of WP:SAYWHEREYOUGOTIT. For that reason, also a dead |url= must not be removed (but |url-status=dead be set), as this would invalidate the citation. Of course, if it is possible to replace a (dead) link by a similarly authorative or better live URL, that's allowed for humans (and in some very limited cases it may also be allowable for a few highly regarded bots -- however, not for Citation Bot, which has a long track record of messing up citations and over the years has created way too much damage to the project to still have any credibility, IMO -- the quality of edits is much more important than the quantity). --Matthiaspaul (talk) 21:39, 24 August 2020 (UTC)
I would like to add that even in cases where the |url= is an exact duplicate of an identifier-derived link, they should not be removed if |archive-url= is given as well (unless citation templates introduce parameters to specify archive links for identifiers as well). Some identifier-derived links are intended to be semi-permanent, but ultimately they are subject to link-rot as well, so it is good to keep archived versions around. --Matthiaspaul (talk) 13:31, 1 September 2020 (UTC)
  • The bot never; a human might be justified to do so in rare special circumstances. Johannes Schade (talk) 16:26, 31 August 2020 (UTC)
  • Matthiaspaul says above As a convenience to users who don't know what identifiers are and never click on them, the title could still be linked to this page through (manual or priority-based automatic) auto-linking. I think in such cases removing |url= is OK; the parameter is freed up for some potential other URL, and in the meantime readers see no change since the title still has the auto-linked ID-derived URL. Of course the edit-summary should provide [a link to] a reassuring explanation of this. jnestorius(talk) 14:13, 3 September 2020 (UTC)
Yes, just in case this didn't became clear in my post above, if |url= points to exactly the same page as provided through an identifier link and there is no |archive-url=, then |url= serves no purpose and can be freed for better uses. (With |archive-url= being present I would not agree with the removal of |url= unless the citation templates would be improved to support archive links for identifier links as well.) What's also a problem is that Citation Bot has been caught to remove |url= also in cases where the identifier-derived links were not identical, but only pointed to the same site (meta page vs. deep link to document) or even to a different site altogether which just happened to contain similar information. This is something that I consider to be disruptive and unacceptable. That's why I pointed out that people have vastly different ideas what terms like "duplicative", "equivalent", or "redundant" mean, and that therefore the unambiguous terms "identical" or "equal" should be used. --Matthiaspaul (talk) 15:34, 3 September 2020 (UTC)
  • We need a better CS1/CS2 template, if title links are important I think that when no title-link is present, the template should always try to make one. If something-free is not set, then auto-link doi with the assumption that it is not free in the icons. I think wikipedia over links, but if we are going to insist on links, then let us make them just appear by magic. AManWithNoPlan (talk) 14:27, 3 September 2020 (UTC)
  • AManWithNoPlan has the right idea. I don't care if there's a url= field, but I do care that the title links to be best available url for the source. (We should make it as easy as possible for readers and editors to verify the content of our articles.) If titles can be linked automatically based on some of the other fields: great. If not, leave the url field alone. pburka (talk) 23:03, 5 September 2020 (UTC)
  • I also agree with AManWithNoPlan. It is the job of the CS1/CS2 template to create the best title link (with the appropriate |url-access=), not a bot. But this is off topic for Link removal. The |url= link should be removed if it is equivalent to the link created by a parameter used in the cite: |oclc= (|url=, |doi= (|url=, |pmc= (|url=, |pmid= (|url=, |jstor=, etc. It should also be removed if the bot adds the equivalent parameter to the cite. — User-duck (talk) 17:41, 6 September 2020 (UTC)
    • Off topic. Based on some of the WP:SAYWHEREYOUGOTIT arguments, |title-link= should not be a cite parameter. Wikipedia is not considered a reliable source and the book article seldom contains the referenced content. Personally, I think it should be more like "say where you can find it". — User-duck (talk) 17:41, 6 September 2020 (UTC)


I've unarchived this discussion as the issue is now back at WP:AN #Citation bot again. The discussion needs a summary of the consensus shown in the discussion.

I believe the consensuses demonstrated here are:

Title linking
Yes to a free link. Yes to other links.
Duplicate linking
Link removal

I suggest that an uninvolved admin evaluates the discussion and closes it with their own conclusion, but if that doesn't happen in the next few days, I propose to close this discussion in the manner I've outlined above. --RexxS (talk) 01:06, 19 September 2020 (UTC)

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.