Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• Consider developing your proposal at Village pump (idea lab).
• Proposed policy changes belong at Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.
• Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
• Software changes which have consensus should be filed at Phabricator.

Discussions are automatically archived after remaining inactive for nine days.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Get rid of stub tags

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). VanIsaac_WS^cont 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? VanIsaac_WS^cont 02:06, 22 June 2020 (UTC)

• https://www.mediawiki.org/wiki/ORES 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)

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)

• "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 ^{[dubious – discuss]} 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 ^{[dubious – discuss]} 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 ^{[dubious – discuss]} 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 (talk ⋅ contribs) 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)

How to get many more editors

A great way to encourage very many new people to start contributing to WP (and prevent many from complaining about or even trying to sue WP) would be to change the off-putting, formal, bland, boring "From Wikipedia, the free encyclopedia" at the top of every page to something more welcoming and more informative, f.ex. "From Wikipedia, the free encyclopedia that its users make and are responsible for". --Espoo (talk) 09:07, 9 July 2020 (UTC)

I don't think it would discourage anyone actually wanting to sue WP, but it might bump up how many people want to issue legal threats at individual users. It also sounds like we are in aggregate legally responsible for the nature of the pages Nosebagbear (talk) 09:45, 9 July 2020 (UTC)

Can you think of something else that wouldn't cause those misinterpretations but is welcoming and informative? --Espoo (talk) 13:50, 9 July 2020 (UTC)

I guess I don't see what you are seeing with the existing line, nor do I see how changing it would accomplish the goal you have. 331dot (talk) 13:56, 9 July 2020 (UTC)

Correct me if I'm wrong, but didn't the slogan use to say "The Free Encyclopedia That Anyone can Edit?" Anyone know when/why the last part was removed? – Anne drew 14:11, 9 July 2020 (UTC)

Wow, long memory! Not since 2010... history of MediaWiki:Tagline. Cabayi (talk) 14:29, 9 July 2020 (UTC)

@Anne drew Andrew and Drew and Cabayi: The slogan on the main page still says "the free encyclopedia that anyone can edit", the tagline at the top of the page was only extended to the full thing for two days in 2010, and both before and since has been the abbreviated version. --Yair rand (talk) 20:41, 9 July 2020 (UTC)

It looks like there's already been lots of discussion regarding this many years ago - see MediaWiki talk:Tagline/Archive 1#"that anyone can edit" Ed6767 talk! 15:35, 9 July 2020 (UTC)

There was also a proposal in 2017 to say just "From Wikipedia"; it never got a ton of discussion. {{u|Sdkb}} ^talk 20:07, 9 July 2020 (UTC)

The tagline we currently use for the Main page is the free encyclopedia that anyone can edit. Adding a link to our welcome tutorial in this way would certainly drive a ton of traffic to it, but we're already slated to add a link to a welcome tutorial from the left sidebar as a result of WP:SIDEBAR20, so this would be somewhat redundant to that. {{u|Sdkb}} ^talk 20:16, 9 July 2020 (UTC)

Having more than one link to the welcome tutorial wouldn't hurt anyone.

The main point is that the current tagline is what most readers see as the definition of what Wikipedia is (and even if some will glance at the left sidebar, even most of those will not see the future link to the tutorial in that list) and it misinforms them more than it informs them.

The most important thing they need to know is that this is just as much their encyclopedia as anyone else's and that we want to welcome them, not turn them off, and especially if they disagree with something they read on the page they're looking at.

The current tagline says nothing about that. Instead it says only 2 things about WP that are probably obvious to almost all readers -- that it's an encyclopedia and that it's free -- so it's a very sad waste of prime layout real estate and a very sadly wasted chance to inspire readers to become editors. In fact, since the word "free" confusingly has more than one meaning in English, this tagline even distracts the reader's attention from thinking about editing.

More specifically, the current tagline not only sadly wastes a great opportunity millions of times a week: it's off-putting, formal, bland, and boring. It makes readers think of Wikipedia as an institution that exists apart from them, something huge that exists like dozens of volumes of a traditional paper encyclopedia on a shelf. We need a more welcoming and more informative tagline. We probably don't even need to use the word encyclopedia and we probably need to say that comments on the discussion page are welcome and valuable:

Most people are afraid to edit articles due to language, content, and technical reasons and very confused by things most of us don't even think about like the wikitext markup and the very annoying habit of the first line of most articles being "hidden" by being without a free line after hatnotes and often many infobox lines. --Espoo (talk) 12:31, 11 July 2020 (UTC)

Espoo, I very much agree with this. My main concern is just keeping the tagline concise and streamlined, which is why I haven't expressed explicit support for any of the proposals so far. To reply to Blueboar below, yes, everyone knows that they could edit Wikipedia, but unless they're actively reminded of that fact, they're very unlikely to actually do so. We need to advertise if we want editing to be something that actually comes to mind. {{u|Sdkb}} ^talk 06:48, 12 July 2020 (UTC)

• Um... Wikipedia has existed for almost two decades now. An entire generation has grown up with it. I seriously doubt that there is a large pool of potential editors out there who don’t already know that our content is user generated and that “anyone” can contribute.

No, the real reason that we don’t have as many editors as we used to have is quite simple... there isn’t as much for new editors to do (the obvious topics have already been covered). And what still needs to be done isn’t as much fun. Blueboar (talk) 14:07, 11 July 2020 (UTC)

How about this for a radical idea:

• Long term editors organise the resurrection / reactivating of the many seemingly dormant projects.
• When a new editor submits their first draft article they are welcomed and mentored by a member of the relevant project.
• etc - you get the drift.

Downsize43 (talk) 21:56, 11 July 2020 (UTC)

Your idea sounds great Downsize43, Especially #2! W.K.W.W.K...ALL Lives matter FAQ 02:53, 12 July 2020 (UTC)

Great ideas, Downsize43, but they don't address the problem of people who don't edit despite reading something that is said in a clumsy or wrong way or that they know or are pretty sure is wrong.

Yes, most people know they could edit, but most don't dare to, don't know how to, find it too difficult or confusing, don't realize they could instead write on the talk page, weren't treated kindly when they once edited something, and other reasons.

Your suggestions mostly apply to readers who have already edited. Instead, we need to encourage and inspire the much larger number of readers who have never edited.

So, instead of "From Wikipedia, the free encyclopedia", how about something like this:

This is a Wikipedia article, so it's as reliable as its sources.

Help improve it by clicking here.

--Espoo (talk) 08:01, 12 July 2020 (UTC)

I don't think "This is a Wikipedia article, so it's as reliable as its sources." is an improvement. Dutchy45 (talk) 13:46, 12 July 2020 (UTC)

• I just want to point out that the tag line under discussion only appears at the top of a page if you are seeing it in “desktop view”... there IS no tag line (at all) when using mobile view. If the goal is to somehow attract new editors by changing the tag line, it will have limited effect. The cosmetic change won’t be seen by those using mobile devices. Blueboar (talk) 13:41, 12 July 2020 (UTC)

  Blueboar, I think it's appropriate not to have a tag line on mobile, where there is more limited space. But your point is definitely good to keep in mind. We've improved the way our introductory resources work on mobile a bunch recently, and there's certainly more work to do. {{u|Sdkb}} ^talk 17:54, 12 July 2020 (UTC)

Ok, ok, I know it's not an actual grammar rule that sentences shouldn't end in prepositions, but the above wording grates on my pedantic copy-editing self. I don't really think the wording as it stands is preventing anyone from editing. Retswerb (talk) 06:19, 14 July 2020 (UTC)

Maybe one day. We have done everything to show them they can edit the article. We have edit buttons at the top of each page. We have edit buttons in each section header. We have edit links in maintenance templates. Our front page says that anyone can edit it. It gets really repetitive and plus it prob will mess up with the horizontal layout. For now, I think the "From Wikipedia, the free encyclopedia" tagline is good. Aasim 08:10, 18 July 2020 (UTC)

Clickbait header. And the tagline is irrelevant. I know how newbies are treated. Very few users are capable of effectively helping newbies. Nearly everybody lacks the patience. So newbies run into walls and give up. The learning curve is still too high. That is partially a technical problem but mostly a community problem. Without good teachers, the learning curve will always be too high. - Alexis Jazz 01:26, 21 July 2020 (UTC)

The learning curve is too high because things are too complex, and unnecessarily so. Things are too complex because (1) the natural tendency is always toward more complexity, and (2) there is nothing in our system to prevent that from happening. Few editors understand the cumulative costs of complexity, but any editor can participate in the development of the site's infrastructure. Do that for 19 years and you end up with a monumental mess, which is what we have. If you want good bridges, you don't let just anybody design them. In short, the problem is intractable without a sea change in project philosophy and a major overhaul of our system, which seem highly unlikely. Learn to live with it. ―Mandruss ☎ 11:57, 21 July 2020 (UTC)

Mandruss, that's extremely well put. It dovetails with some thoughts I recently expressed about beginner accessibility of policy pages. {{u|Sdkb}} ^talk 09:26, 27 July 2020 (UTC)

• Oppose changes - I don't see how any of the above will improve project involvement. -Indy beetle (talk) 04:18, 22 July 2020 (UTC)

Make future WP:ANI threads individual pages, like WP:AFD

Currently on WP:ANI there is one page in which editors discuss incidents. However, there are some issues with this approach:

• It is usually very active, and editors often encounter annoying edit conflicts
• ANI has over 1000 archive pages. This can make sifting through them all rather difficult, even with search, i.e. finding the archive through loads of results, scraping through them all, then finding the subsection (of which an archive can have many), then copying the permlink
• If a user wants to check on discussion for a specific case, they have to watch the entire page, meaning that their watchlist will likely be filled with irrelevant changes.
• ANI usually gets very long. This can make it harder to load on slower computers, and some bots or scripts may fail to edit it due to its often extreme length.

Due to these issues, I propose that a new subpage is made, either per thread, or per day on WP:ANI, similar to current process on WP:AFD and other similar pages, as this would resolve a large majority of these issues, along with a number of additional benefits. Ed6767 talk! 01:56, 22 July 2020 (UTC)

Interetsing idea. Technology-wise, I have never had any problem reading the ANI threads on my 2011 Macbook pro. The archive might be better managed though. ThatMontrealIP (talk) 02:29, 22 July 2020 (UTC)

• Support per nom, as this seems very reasonable, with the caveat that I'm not an expert in the technical functioning of these forums, so if there's some big downside I'm missing, feel free to discount my !vote. {{u|Sdkb}} ^talk 07:08, 22 July 2020 (UTC)
• Not going to happen due to the complexity. People who positively contribute at ANI won't want to click through to a hundred subpages and add them to their watchlist (and remove them after sufficient time to avoid the watchlist overhead). At ANI, people can search for a particular user name, article name, or date and quickly find all occurrences. That becomes a major undertaking with multiple subpages. Johnuniq (talk) 07:20, 22 July 2020 (UTC)
• Please don't. Johnuniq has it right. - Sitush (talk) 07:24, 22 July 2020 (UTC)
• It is not unusual for ANI to have spurious posts or vandalism; such pages would need to be deleted instead of merely reverted. 331dot (talk) 07:37, 22 July 2020 (UTC)

  Surely then that would be the benefit of having new daily pages for new threads then? You can still have the benefits of having shorter, more manageable pages, and also be able to revert vandalism as per usual then? Ed6767 talk! 10:19, 22 July 2020 (UTC)

All users can revert vandalism; only admins can delete pages. This would make more work for admins (if each discussion has a page) with little tangible benefit. Daily pages would require people to follow more pages, and require more archiving, and be harder to manage, not easier. 331dot (talk) 11:00, 22 July 2020 (UTC)

• Oppose- Edit conflicts generally affect edits to the same subsection. That is, if I am editing section "User:blerpyface is a fink" and someone else is editing section "User:fnordbot is broken" simultaneously, we will not run in to an edit conflict. Those that do happen come from editing the same section, and that problem would affect individual pages as well. As for the archives, yes, there are over a thousand of them. So what? Will replacing 1,000 archives containing multiple sections with tens of thousands of individual pages be any better? No. This proposal seems to me to be a solution in need of a problem. Reyk _YO! 10:34, 22 July 2020 (UTC)
• There are problems presented here, but I'm not sure if these are the right solutions? Regarding edit conflicts, Reyk is correct. Regarding searching, AfD is easier because the title of the AfD always follows the title of the article being discussed, (give or take nth nomination). ANI sections follow no titling pattern, so searching won't necessarily be improved in that sense. I suppose it could be easier to identify relevant sections from Special:Search though. The third point is reasonable, I suppose. But is it significant enough that it's worthwhile reworking the system? Obviously noting that doing this will mean watchlisting ANI itself for updates to any section stops working. ProcrastinatingReader (talk) 11:18, 22 July 2020 (UTC)
• Oppose - whereas AfD pages are functionally all independent, AN & ANI threads branch, merge, move etc all the time. There is also more need to be able to move around the full set smoothly, though that's a lesser issue. I also feel that edit conflicts are already within sections anyway, so branching into pages would be problematic. Don't get me wrong, there are benefits, particularly making it viable to watchlist individual discussions where the whole page would overwhelm a watchlist. But I think the issues outweigh the positives. Nosebagbear (talk) 12:44, 22 July 2020 (UTC)
• Strong oppose - the main purpose of ANB is to get the attention of an admin. It is possible to get an email every time a page is edited (I do for some pages I watch). It is not possible to do this every time a subpage is edited created. Plus, most threads are very short (like "Can you please block X because they did Y" or "Can you delete the page X that I created on accident"). We do occasionally have long discussions, but those very few cases when we have long ANB discussions do not warrant putting individual discussions on individual pages. AfD, though, gets hundreds of nominations per day, which warrants individual pages for these nominations. Plus, some of these nominations can get a very heated discussion. For these reasons, I strongly oppose this proposal. Aasim 20:30, 24 July 2020 (UTC)
• Support trial - one ANI page per editor, like how SPI does it. I think that would make a big difference to how discussions play out and it would cut down on "repeat offenders". There could also be a "general/misc" page for the more minor matters that don't merit their own page. Something like this is worth trying out I think. ANI desperately needs a shake up; it's next to useless and has been for years. Levivich ^{[dubious – discuss]} 07:05, 25 July 2020 (UTC)

  As the Wheel turns... --Izno (talk) 13:51, 25 July 2020 (UTC)

  Iztrue. Levivich ^{[dubious – discuss]} 14:26, 25 July 2020 (UTC)

  What would we name the equivalent of WP:LTA for this new AN? The naughty list? ProcrastinatingReader (talk) 21:23, 28 July 2020 (UTC)

  • @Levivich: How would this work for threads that are about something other than the conduct of a single editor? Looking at some recent threads there are examples of:

    Boomerangs - these would be initially filed under the name of the reported user and then have to be resorted to under the OP's name (is that a good use of editor time?)

    A pox on both your houses - both the OP and the reported user are found at fualt (copy and paste? redirects?) - one ended up discussion the behaviour of about 5 editors in detail and peripherally others editing the MoS topic area.

    Article problems - mostly off-topic, but they are still posted there and would need dealing with

    Broadening discussions - an editor was indef-blocked but then discussion continued about possible general sanctions for the topic area. Nobody would find that in the future under the reported editor's name.

    Dynamic IPs - single editors editing from an IP range, that may or may not be used by other editors now or in the future (no allegations of socking were made). Thryduulf (talk) 09:44, 29 July 2020 (UTC)

    @Thryduulf:

    • Boomerangs, pox on both your houses - calling for a boomerang is common, an actual boomerang is still rare. But it's a feature not a bug that a user's ANI subpage would show if the user had been the subject of bad-faith or boomeranged reports, by collecting those reports in one place. It's useful to know at a glance whether an editor has been brought to ANI five times and it's closed boomerang or no action every time and this is the sixth. Same with a "pox on both your houses". If both editors have an ANI subpage, it can be cross-referenced, I suppose, but I think my view is just let it be filed under the reported editor's name. If one editor has many "pox on both your houses" threads with multiple other editors, that pattern will become very easy to spot... i.e., who is the common denominator. Not so with the current system.
    • Article problems, dynamic IPs - just use the main ANI page as we do now; no subpage for these; archive them as we do now.
    • Broadening discussions - feature, not a bug, that any broadening would have to be discussed in a new thread somewhere else and could not/should not/would not be discussed at a user's subpage (and thus not at ANI). For example, general sanctions should not be discussed at ANI, it should be discussed at the pump, it's a community-wide concern and these things shouldn't be decided by ANI regulars, who as we all know are a small and self-selecting subset.

    I think of this idea as having the main ANI page like normal, but we split off threads into sub-pages organized by reported editor where appropriate. That way, all the ANIs against Levivich go to WP:ANI/Levivich, and anyone reading it can easily see history - good, bad, and ugly. The main WP:ANI page can just have a link to /Levivich, and that can be archived like normal (3 days or whatever). People involved in a report against Levivich can watchlist /Levivich and not have to watchlist the main ANI page, which I think will generate broader participation.

    And to Izno's point above, this is still different in qualitative ways from the old RFC/U, e.g. in format and prerequisites.

    One issue I don't know if anyone's brought up yet is that if threads are on a subpage, they won't automatically archive, which means discussions won't just go stale and fall off. I'm not sure if this is a good thing or a bad thing, but it would be interesting to try and see how it goes, that's why I support a trial. Levivich ^{[dubious – discuss]} 07:53, 31 July 2020 (UTC)

• So, you want LiquidThreads or Flow, but with less functionality?--Jorm (talk) 15:12, 29 July 2020 (UTC)
• Support I know this has failed before, but I long for it. --Deepfriedokra (talk) 21:46, 30 July 2020 (UTC)
• Oppose I don't see how this would be particularly beneficial. LEPRICAVARK (talk) 15:14, 31 July 2020 (UTC)
• Meh - I like the "per day" to be honest but on the other hand I don't really see a problem with what we currently have. –Davey2010^Talk 15:21, 31 July 2020 (UTC)
• Oppose For a few reasons:

1. Less transparent on watchlists: you wouldn’t see the individual edits to the page on watchlists. I don’t currently WL the page, but when I did I only ever commented based on what I saw on my watchlist, not by visiting directly.
2. More dramah; less just outcomes related to 1 above, as a consequence of less transparency and visibility, you’ll have a list of ANI regulars, many drama seeking, who serve as the main commenters on each page. This in turn will lead to less desirable outcomes since editors who otherwise might mellow the atmosphere and help achieve an equitable result won’t be commenting as frequently.
3. RfC/U 2.0 RfCs on user conduct were made historical for a reason. Pages devoted to the behaviour of one editor are primarily going to attract their enemies and in turn lead to more arb cases since railroading leads people to seek review elsewhere. I’m aware there’s a recent trend to want a more active ArbCom on stuff that the community should be able to handle itself (ex. wikipedia:Arbitration/Requests/Case/Motorsports, recent calls for a SashiRolls case), but I personally think that community resolution is usually better.

I’m sure I could think of many more, but those were the three that came to mind first. As such, I’m opposing. TonyBallioni (talk) 16:19, 1 August 2020 (UTC)

Clearly display each Default setting at Special:Preferences

Tracked in Phabricator
Task T70689

Have you ever gone to Special:Preferences and wondered whether to "Restore all default settings", only to realise you have absolutely no idea which ones you might already have changed, or which helpful Gadget or Editing settings you might lose if you did so?

A recent Teahouse discussion has prompted me to propose a long-held feeling that a User's Preferences page should indicate the original Default setting (whether enabled or disabled). Only that way can a user who has, over some years, tweaked their Preferences appreciate what they've actually activated or disabled, and what they see differently from a brand new user.

This seems a reasonable and obvious thing to propose, and with no disbenefits. Or is this better put forward as a broader cross-wiki suggestion at https://meta.wikimedia.org/wiki/Help_talk:Preferences ? Nick Moyes (talk) 20:15, 25 July 2020 (UTC)

• Strong support - although, this is a MediaWiki issue will probably be better suited for phabricator instead of here Ed6767 talk! 20:26, 25 July 2020 (UTC)
• Support this being done, wherever it needs to be requested. This is an obvious no-brainer case of bad design. Phil Bridger (talk) 20:57, 25 July 2020 (UTC)
• The preferences pages can already be overwhelming. I don't think this would be a good idea. Starting a documentation of these defaults at e.g. Help:Preferences seems reasonable. --Izno (talk) 21:36, 25 July 2020 (UTC)

  Surely, some simple design ideas could resolve that concern? For example, items that are actively selected by default could be shown in bold. Hardly overwhelming. What I think is genuinely "overwhelming", is not being able to discern what was or was not once a default setting when looking at the Preference pages themselves . Nick Moyes (talk) 00:15, 26 July 2020 (UTC)

  Then you need to explain to both sighted and unsighted users what the bold means, and the latter group doesn't get anything for that besides some text to that effect, and the former still needs that to fit somewhere on the page in question. --Izno (talk) 00:37, 26 July 2020 (UTC)

  It can't be too much of an effort to append (default) to the end of default preference options? And it should look okay too from some tests I've done Ed6767 talk! 00:32, 26 July 2020 (UTC)

  On which resolutions? :) --Izno (talk) 00:37, 26 July 2020 (UTC)

  Personally, I'd rather to see them on the preferences page than on a separate help page (I'd more likely use MediaWiki:Gadgets-definition as a source of truth since it is more universal and I know that it won't be outdated). As for the page already being overwhelming, thoughts on the Wikimedia Commons approach of using a superscript "d" with tooltip (^d), along with a sentence at the top of the page that also explains what it means?  Hazard SJ  02:30, 26 July 2020 (UTC)

  Just noting that this is similar to what is done on Meta (different wording is used, and there is no sentence at the top of the page).  Hazard SJ  19:51, 2 August 2020 (UTC)

• Support per nom, assuming that it is implemented with good design that doesn't overwhelm the page. This request arose because we realized users who created an account prior to 2014 still don't have RefToolbar (the thing that allows you to click "cite web" etc.) enabled by default. Most big websites force new changes on all users, and while that wouldn't go over well here due to status quo bias from power users (i.e. ourselves), the least we should do is note when something has changed by marking the default. Personally, this would be useful for me since, even though I may not change any settings, marking the default would give me a cue as to when the appearance of something might differ from that of the average reader. {{u|Sdkb}} ^talk 04:49, 26 July 2020 (UTC)
• Support per nom and User:Sdkb. I've wondered about just what were the defaults myself. Regards, GenQuest ^{"Talk to Me"} 09:13, 26 July 2020 (UTC)
• Support. Then update Help:Preferences. Also link to Help:Preferences rather than MW:Help:Preferences. — GhostInTheMachine ^{talk to me} 09:56, 26 July 2020 (UTC)
• So there are a couple of ways to do this: (a) with a bunch of hacks to some of the labels, this would be local and would need to be done for each language a user may use - so I strongly oppose that in bulk (maybe for gadgets - since these are project-specific). phab:T70689 is already open to fix this mediawiki side, so I suggest anyone that wants this to be developed subscribe there and voice support. — xaosflux ^Talk 11:42, 26 July 2020 (UTC)

  Support for Gadgets - this is easy, and something that is actually directly an English Wikipedia on-wiki config. — xaosflux ^Talk 00:46, 1 August 2020 (UTC)

• Support A lot of support for this so far, I'll add my support with a slightly different twist. I have no plans to restore the defaults, but occasionally I will be in discussion with the new editor, and cannot recall whether some aspect e.g. automatic numbering of sections, is something they are likely to see or if it's something I enabled. (Not a great example because I do remember there are probably other examples.) I do have an alt count which probably has all defaults, but that's a bit of work to check on something.S Philbrick(Talk) 20:56, 30 July 2020 (UTC)

Wikipedia award ceremony

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.

---

To make things interesting let award our editors let make an award ceremony to give reward to editors. barnstars are giving any time by users. Let form an award commitee who will every year set up an award for editors. Users may vote up other users for this award and could also nominate each other. We can give award such as longest wikipedia staff and many other awards.Tbiw ^(talk) 06:16, 27 July 2020 (UTC)

Tbiw, you're describing WP:EOTW. {{u|Sdkb}} ^talk 09:08, 27 July 2020 (UTC)

No more better,bigger than WP:EOTWTbiw (talk) 11:02, 27 July 2020 (UTC)

As I mentioned in the earlier thread in the idea lab, Editor of the Week is different. isaacl (talk) 22:40, 28 July 2020 (UTC)

Sorry, this proposal isn't going to go anywhere. Awards are useful insofar as they encourage helpful editing, but once you start organising full-blown award committees, you've made Wikipedia more about social networking rather than building an encyclopedia. – Teratix ₵ 12:24, 27 July 2020 (UTC)

Wikimedian of the Year is a thing already. Thryduulf (talk) 14:07, 27 July 2020 (UTC)

And a pretty controversial one, which makes the whole idea dead.--Ymblanter (talk) 14:25, 27 July 2020 (UTC)

And there are multiple other things organized at places like Wikimania and other meetups, like the best tool award and things like that. Ed6767 talk! 15:35, 27 July 2020 (UTC)

 Request withdrawn

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

Proposal: Bundle the edit filter manager group with the administrator toolset

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

---

I think this is necessary because similarly to other permissions, we do have some non-admins who hold this permission. This is the only permission that administrators can grant themselves that gives them access to more functions. For example, if an admin granted themselves the rollback user right, that would be redundant because rollback is already bundled into the toolset. I think we should make it easy for admins to edit edit filters. Interstellarity (talk) 20:10, 28 July 2020 (UTC)

• Support: I don't see much value in keeping EFM separate if admins can self-grant at will. No security benefit from having them unbundled - if an admin account is compromised, then the person who compromised the account can just give themselves EFM (plus, you know, we're dealing with a compromised admin account). Also, changing an edit filter is a pretty deliberate process (navigate to the appropriate page, make your changes, save - not like rollback where we accidentally click a single button) so I don't think that there is significant risk of an admin accidentally messing something up if they aren't actively trying to tweak an edit filter. GeneralNotability (talk) 20:17, 28 July 2020 (UTC)
• Oppose – edit filter manager is a highly-sensitive user right, as there is a high risk of screwing something up if you don't know what you're doing. We trust administrators with the ability to self-determine whether they are competent to modify edit filters, and the extra step of flipping that bit is a public declaration that an admin is interested in working in this area. Removing this safeguard could expose the project to additional risk from those who wade into this area by accident or without realizing the sensitivity of their actions. While this safeguard may seem pointless, it's not – it's an intentional redundancy, like a lid over a switch. – bradv🍁 20:45, 28 July 2020 (UTC)

  I recognize your concern that EFM is an extra safeguard, but we (theoretically) trust admins to not click buttons if they don't know what they're doing, and as I said in my !support it's pretty hard to "accidentally" modify an edit filter. I concede that you can do a lot of damage with an edit filter, but I think that the average admin can be trusted to not screw around with the edit filter if they don't know what they're doing, just like we can trust the average admin to not, say, apply a rangeblock if they don't know how IP netmasks work. GeneralNotability (talk) 21:14, 28 July 2020 (UTC)

• Weak oppose. On Commons, translation admin is kept separate for the very reason Bradv says. Now I don't think one can "accidentally" touch an edit filter as easily as one can mess up a translated page, so I would not support keeping the separate right for that reason alone. However, it does serve as a useful catalog of which admins are active in the maintenance of edit filters. -- King of ♥ ♦ ♣ ♠ 20:56, 28 July 2020 (UTC)
• Oppose per Bradv --DannyS712 (talk) 20:58, 28 July 2020 (UTC)
• Oppose – I agree with Bradv's comment in its entirety. Keeping them separate has always served an important technical distinction, given the potency of the edit filter's application and the bit of technical knowledge needed to use it properly. This slight technical barrier is a good way to have them at least ask themselves briefly whether they know what they are doing, and it also allows community members to identify easily who among the administrators is willing to manage edit filters. Mz7 (talk) 21:02, 28 July 2020 (UTC)
• Oppose per bradv. I'm also confused, why is I think we should make it easy for admins to edit edit filters desirable? Given the vast damage someone who doesn't understand regex well can do, I think this is one area we don't want to make easier for more admins, unless they know what they're doing. ProcrastinatingReader (talk) 21:13, 28 July 2020 (UTC)
• Question Do you think we should let admins decide for themselves if they can be granted the edit filter manager user right or should someone else grant the right for them like bureaucrats? Interstellarity (talk) 21:31, 28 July 2020 (UTC)

  My view would be that an admin should indicate (without having to demonstrate) that they have at least a basic understanding of regex. A process similar to IAdmin would be sensible, minus the admin requirement. But this seems to be a classic case of WP:IFITAINTBROKE. There's no demonstrated problem with how things are done currently, so I don't see the point of this proposal, personally. ProcrastinatingReader (talk) 21:36, 28 July 2020 (UTC)

• Oppose Just because I have admin rights doesn't mean I'm competent in highly technical areas like this. If I could do real harm by 'being bold' then I welcome some 'hand-holding' until another skilled person says I understand what I'm doing. Nick Moyes (talk) 21:53, 28 July 2020 (UTC)
• Oppose, per bradv. Das komputermaschine is nicht fur gerfinger-poken und mittengrabben. --AntiCompositeNumber (talk) 22:09, 28 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.

Mp4 videos please

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

---

I would want to appeal to wikicommons to include Mp4 format videos in the videos it uploads on commons. Most smartphones are compatible with Mp4. Except Wikipedia isn't sensitive to all users of it platform. The ogg, ogv, etc videos do not play on smart phones. I have tried it on Java, Android smart phones they are not playable.

I think you would want to ask on Wikimedia commons, as it is a separate project.ThatMontrealIP (talk) 21:17, 31 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.

Add a sub-page called Meta in the Village Pump

In two websites, StackExchange (URL) and Reddit (URL) there is a space called Meta to help the new-comers or settled users discuss the site features in the case of problem or just being curious; and also, teaching them how to use the site; also, it is possible to have main-site-unrelated content such as entertainment, etc. to be included in it. It can be helpful if we also have a look-alike feature here. Aminabzz (talk) 15:15, 2 August 2020 (UTC)

Aminabzz, This sounds like a cross between WP:VPT, WP:VPP and WP:TEA, so I'm not seeing much point. As for encouraging entertainment, it's not that we're all grouches here, but we have a different mission from StackExchange or Reddit. Both of those are commercial sites, and the bottom line is how many users, how many clicks, how much traffic. Our bottom line is writing an encyclopedia. -- RoySmith (talk) 15:30, 2 August 2020 (UTC)

@Aminabzz: We do have such forums, only under different names. Incidentally, welcome to Wikipedia. If you have questions about how this project works, then I would encourage you to ask at The Teahouse, which is our dedicated forum for new users to seek advice and assistance. GMG^talk 15:52, 2 August 2020 (UTC)

Just to add to the negativity shown to your idea, the existing Village Pump pages and the Teahouse are already places designed for discussion about Wikipedia. The name is also problematical, as there is already a project called Meta where issues that apply across Wikimedia sites, including the Wikipedias in many languages, are discussed. By design we don't allow site-unrelated content such as entertainment to be included anywhere, because this is a project with particular aims that don't include being a social media site. Phil Bridger (talk) 16:21, 2 August 2020 (UTC)

Adding and using a template called Falseredirect for pages that redirect somewhere else, but need separate pages

Sorry if it isn't the best place to post this, if it's the case, please say me on what page it's better to post it.

Basically, on Russian Wikipedia there's a template that is used in the beginning of a page where another page redirects, but where the said page need a separate article instead of redirecting because its a different topic, such as :
"Page" redirects here. This topic needs a separate article.
This is a very useful template, but I haven't seen it on English wikipedia, the only other languages are languages of Russia, and neither I've seen any template that acts the same way. So where to ask people to implement this template into English Wikipedia? Of course, I can translate this template myself, but it won't be used and will probably deleted. Cappyinator (talk) 10:49, 3 August 2020 (UTC)

We have the template {{R with possibilities}}, but it goes on the redirect rather than the target article. Can you give an example of where this could be useful? If a title shouldn't redirect to another article then surely it's better to write at least a short stub or delete the redirect altogether and make the title a red link? Phil Bridger (talk) 10:59, 3 August 2020 (UTC)

My template is useful for people who will for example automatically be redirected from Super Mario 64 DS to Super Mario 64 (it's how it is currently on Russian Wiki. They'll know that this is a different topic that needs a different article, just like Template:Redirect does fow showing people there's a disambiguation page about other topics of the same name as the redirect. And for Wikipedia editors, this'll show them what page they could create. As for your template, I couldn't clearly see where there is written that a new page can be created instead of the redirect so your template isn't very clear. And also, it shows on a redirect page, which you won't see if you specifically don't go to the redirect page, unlike mine, where both readers and editors will clearly see there's a redirect that needs a separate page.

Cappyinator (talk) 18:33, 4 August 2020 (UTC)

I think the idea is to display a hatnote saying something like "Wikipedia doesn't have an article on [redirected-from title]. You can [piped link to editor|write one]!" It's a bit problematic on this wiki, though: {{R with possibilities}} checks for draft titles and I think we'd want this template to do the same; also, English Wikipedia requires editors to be autoconfirmed before creating articles in main space (but not for overwriting a redirect - still, consensus is already kind of against this). Interesting idea, though. Ivanvector (^Talk/_Edits) 15:12, 3 August 2020 (UTC)

I want more parity between versions. You say the difference is that you need to be autoconfirmed to create articles? If you want either only confirmed users to create articles or you want that people would create articles with draft titles, you could link here : "Wikipedia doesn't have an article on [redirected-from title]. You can [piped link to Incubator editor|write one]!". And also there's many cases where there's a redirect and a separate page needed, because the main page is related and maybe has a section for the redirect, and so creating a red link would be bad.

I'm sorry if I coudn't explain to you properly why this template can be useful, but I think another user from a Russian wiki could explain to you better. Since you were from a wiki that didn't use this template, you would think it's useless, but anyone from a russian wiki would tell to you how useful it is. Cappyinator (talk) 18:49, 4 August 2020 (UTC)

Deprecate parenthetical citations

I propose that we formally deprecate the parenthetical citation style.

Wikipedia has long valued different styles of citation, and we do formally protect a wide range of citation styles. There was even a 2006 ArbCom case that ruled on the issue. However that was 14 years ago, and a lot has changed since then. As Wikipedia moves forward, and our style grows more standardized and formal, I question the utility of the rarely used parenthetical citation style. This style exists because it is used in scientific papers and college essays. However, papers and essays do not have the benefit of being online; thus they cannot have expandable footnotes with fancy coding. Parenthetical citations also clutter the text and make reading more difficult. See for example Actuary, which is one the bare handful of FA's with parenthetical citation style. It includes sentences like In various studies, being an actuary was ranked number one or two multiple times since 2010 (Thomas 2012, Weber 2013, CareerCast 2015) and in the top 20 for most of the past decade (CareerCast 2014, CareerCast 2016, CNN Money 2017, CareerCast 2019). which is cluttered, and unnecessarily long because of the citations. At the end of the day, our goal is to serve the WP:READER. The best way we can do that is to provide easy to read articles, free from inline clutter. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:38, 5 August 2020 (UTC)

• Support As nom. I do understand that there will be some tactical challenges to deprecating, but I do not believe they are insurmountable, and that they can be solved here by discussion. CaptainEek ^{Edits Ho Cap'n!}⚓ 19:37, 4 August 2020 (UTC)
• Question Deprecations can go a few ways. There's deprecation where we just say "this is no longer a good idea, new articles shouldn't do this", there's deprecation where we say "editors can replace this unless there is a specific consensus against doing so", and "editors should remove this when found". Which form of deprecation is this proposal aiming for? --AntiCompositeNumber (talk) 19:43, 4 August 2020 (UTC)

  AntiCompositeNumber, One of the first two options: "new articles shouldn't do this", or "replace unless consensus is against it". I do not think we should remove it in all places at any cost. I left it a bit open-ended, however, because I think it up to the community to decide which version they think best. CaptainEek ^{Edits Ho Cap'n!}⚓ 19:46, 4 August 2020 (UTC)

  Nineteen years and 6 million articles in, I'd say option 1 would have so little overall effect as to be fairly pointless. ―Mandruss ☎ 08:28, 5 August 2020 (UTC)

• Support not accepting it in new articles. As a reader, I find it the most unfriendly form of citation style in articles. Schazjmd (talk) 19:51, 4 August 2020 (UTC)
• Support It makes articles harder to read. ―Susmuffin ^Talk 19:55, 4 August 2020 (UTC)
• Support to the extent of not allowing any new articles using the style, and allowing updating of existing examples to templates unless consensus is against it. The learning curve here is minimal, especially with the citation tools in both source and visual editor, and the gain in legibility is very substantial. --Elmidae (talk · contribs) 22:28, 4 August 2020 (UTC)
• I weakly support deprecating parenthetical citations moving forward, and formally preferring our software-supported footnote system—which in my opinion is clearly superior—but I'm tepid about converting existing articles, especially where that would be frustrating to some editors. The last thing I want to see is some otherwise productive contributor hounded for their citation style preference, especially "less technical" users who are uncomfortable with our XML-like footnote syntax. A formal preference is one thing, but a strong rule to not use a particular style is another. VisualEditor ameliorates this problem but does not eliminate it. {{Nihiltres |talk |edits}} 22:39, 4 August 2020 (UTC)
  • CaptainEek and Nihiltres, does "our software-supported footnote system" mean <ref> tags, or does it encompass templates such as Template:sfn and Template:Harv? I'm not sure whether the goal is to produce the little blue clicky numbers, or to make it possible for a bot to reliably determine whether there are refs on a page, or to produce a certain amount of standardization for editors (i.e., so the citation skills you learn in one place will transfer to all articles). WhatamIdoing (talk) 15:18, 5 August 2020 (UTC)

    WhatamIdoing, I do include sfn as software supported, I only support harvard as long as they are in ref tags. The goal is to make those little blue numbers, to make a greater amount of standardization, and to make it easier for our readers. CaptainEek ^{Edits Ho Cap'n!}⚓ 19:34, 6 August 2020 (UTC)

• Support making it the status quo for new articles, and for older articles, permitting others to change the citation style to non-parenthetical (but not automatically demoting FAs and GAs just because they're still using the parenthetical style). Sam-2727 (talk) 23:12, 4 August 2020 (UTC)
• Oppose I think, on balance, this is a net negative. I definitely agree that inline, parenthetical citations, are nowhere near our preferred style or the style which readers necessarily expect from us, but I think the harms are overstated. It is a rare format on Wikipedia but it's not a rare format; I would be surprised if most of our readers are completely unfamiliar with parenthetical citation styles. Does it disrupt the flow of prose? Probably, but just like the little blue numbers and {{cn}} tags we have inline, readers quickly learn to ignore it and skim past. These are definitely not ideal, but I doubt parenthetical citation styles are causing us to lose significant readership. What makes me oppose is that, in discussions like these, people tend to overlook the benefits of allowing unpopular citation variants.
  Most people have encountered parenthetical citation styles at some point in their lives. Imagine if I told you that to participate effectively on Wikipedia you not only needed to learn a new citation style, but the technological trappings that go along with using it. Most people hate citation styles anyway, so in pitching an edit-a-thon or recruiting editors, it is much easier to get people excited about contributing when I can say "just cite it as you would in one of your papers". That line works for students and professors alike; they already know how to do parenthetical citations, and allowing parenthetical citations lowers the learning curve for many people. VisualEditor has helped, but it's not perfect and not everyone likes using it (among computer programmers I work with, they actually like the source text over the WYSIWYG editor). Among subject matter experts, the parenthetical citation is the dominant style. Many academics and journals publish open access articles under terms compatible with our license. Allowing parenthetical citations means that if an academic publishes an open-access article in a journal that licenses it under CC-BY-SA, we can just copy the lit review section and we've got a new article peer-reviewed and written by a subject matter expert. By deprecating this citation form, it also increases the opportunities for newbie biting. If someone writes a nice article that happens to use parenthetical citations (or copies a properly licensed journal article), and NP patroller comes by and suddenly changes the entire thing, that will be discouraging at best. This isn't even farfetched, wholesale citation style changes and the interpersonal disputes that arose from them are what led to the citevar ArbCom case, so I'm not keen to open the doors to that again. Similarly discouraging is writing an article and immediately being told there were unwritten citation rules you had to learn before participating. Having a lax policy on citation styles is a benefit for the project.
  None of these are reasons to encourage the use of parenthetical citation, but they are reasons we should not forbid it. Per WP:CITEVAR, we can already change citation styles by consensus, so this proposal would only close the door on a lot of possible benefits. Saying "use any citation style you like" is a benefit, and we should not change that general principle. If any page could be improved by changing the citation style, be bold (but not reckless) or start a discussion to change it. But the encyclopedia is not improved by a blanket deprecation or prohibition of an otherwise valid and well-used citation style. The harms in my opinion vastly outweigh the benefits of mildly improved prose. — Wug·a·po·des​ 23:16, 4 August 2020 (UTC)
• Strong oppose The important thing is that articles be cited. Just how they are cited is much less important. Once we have a citation, it can be improved. Many unsophisticated users do not know how to format a citation in any of our preferred methods, and we should do everything possible to encourage them to add the reference anyway, in whatever method they choose, however informal. The official citation methods in Wikipedia are among the most complicated part of the project that the ordinary article-writer will see. In our efforts to standardize them, we have also made them more intimidating. It would be very counter-productive for a beginning writer to try to add an article and fail to get it accepted because they could not figure out how to cite it. After many years here, and decades working with citations more generally in the academic and library world, I have never seen a system as complicated and poorly documented as ours (We have equally poor documentation elsewhere, but not for a function so important and so frequent), I know all the various devices to help people get a citation in one of the currently correct formats; I sometimes use them, though I have not yet succeeded in always getting what I intend. But I also know (or at least know of) the various devices and bots we have for improving citations; or, more exactly, forcing them into our preferred formats. What I'm saying here has been said more fully just above by Wugapodes . DGG ( talk ) 00:48, 5 August 2020 (UTC)
• Support - noting that this proposal isn't to "nuke on cite sight" but to "move away from", and I support moving away from parenthetical cites. That might mean discouraging them in the policy docs, not accepting them in new articles, and/or changing articles that use them to a different style (but in a non-disruptive, not-mass-nuking way). Wikipedia is for a general audience; it's not like a peer-reviewed journal; and our global audience, which skews very young (we're writing for what level of reader comprehension?) will not be familiar with parenthetical cites. Footnotes are much more common outside academia -- in fact, parenthetical cites really aren't used outside of formal academic writing, the kind governed by, e.g. MLA or APA style guides. They break up the prose -- in my view, it's not a "minor" prose improvement, but a major one, to get rid of the parentheticals. And they are much more distracting than footnotes. I mean, just look: Here's a sentence with a parenthetical citation. (Levivich 2014). Here's a sentence with a footnote.^[1] I think the footnote scans much easier. As to creating cites, the easiest citation to create is <ref>bare url</ref>. The second-easiest way to add a reference is to click the "cite" button (whether or not one is using a visual editor). Whereas actually create parenthetical citations in a wiki article (that links to the actual bibliography item), one must master citation templates that are more obscure than {{cite}}, like {{harv}}. I mean, just read WP:PAREN, it ain't easy. So, new users are not going to be going for parenthetical cites. And, indeed, that's why parenthetical cites are rare, whereas ref tags in bare URLs, and visual-editor citations (you know, the lovely <ref name=":1"> ones) are much more common.
  TLDR: Parenthetical cites are harder on readers and harder for new editors; it's time to get rid of it. ^Lev!v^ich 01:03, 5 August 2020 (UTC)
• Support. There's nothing wrong with parenthetical citations, but we should aim for consistent formatting wherever possible and footnote citations are the overwhelming de facto standard. Re. Wugapodes and DGG's opposes: this isn't going to stop new editors using parenthetical citations. It just means somebody will come along later and standardize them, as happens when newbies use unformatted citations, or title case in headings, or any number of other WP:MOS details, without any great fuss. I think the idea that it will deter academics and students is also a red herring. Even within a field, different publications insist on different citation styles. I don't think people find it surprising or off-putting to learn that Wikipedia has a house style too. – Joe (talk) 07:35, 5 August 2020 (UTC)
• Oppose per Wugapodes. To recap, deprecating parenthetical citations (even for just new articles, and in fact, especially for new articles) will hurt the following groups of editors: 1) New editors. New editors must be able to contribute quality content with the least amount of hassle around things that are unrelated to our core principles like verifiability. Out of all citation styles, some newbies may be most familiar with parenthetical citations (say, because of a background in academia). Indeed (contra Levivich above), parenthetical citations are the only kind of citation style one is able to produce with absolutely no knowledge about wikitext (such as ref tags) or templates. 2) Editors who import public domain or freely licensed material. For this to be convenient, the number one priority should be to easily import the material in the first place. Any "wikifying" is secondary. Converting the citation style of the source material can be a chore, and there might be instances where there are exceptionally tricky situations, such as a source repeatedly using "In Smith (2008), it is argued..." and other shorthand that fundamentally alters how prose is organized. I've personally experienced this when harmonizing articles that inconsistently mix the two citation styles. 3) Established editors who prefer parenthetical citations. If for some the choice is between contributing using that style or stop contributing, we all lose. 4) In the end, all editors (and readers) are benefited. I never use parenthetical citations; It's not my preferred style. But for those who do, it helps them to contribute and that's what we want to encourage, not discourage. Citations are there to ensure WP:V and parenthetical citations do that just as well as any other style. A consistent citation style is required within one article, but we've agreed not to require consistency among all articles when it comes to citation (and date, and English) variety. The current policy already allows changing an article's citation style on a case-by-case basis. Thus, if CaptainEek in good faith finds parenthetical citations unsuitable for Actuary, they can ask for it to be changed. – Finnusertop (talk ⋅ contribs) 08:25, 5 August 2020 (UTC)
• Support formally preferring our software-supported footnote system and permitting others to change the citation style to non-parenthetical for older articles. We should not reject an article at AFC because of parenthetical citations, but there should be no bias shown towards anyone who takes it upon themselves to retrospectively upgrade existing articles to software-supported footnote systems. Cavalryman (talk) 11:04, 5 August 2020 (UTC).
• Support for consistency. The manual of style takes all sorts of arbitrary positions, and this is far more noticeable than most. I should note that, if Category:Use Harvard referencing is accurate, there are less than a thousand of our more than six million articles that use this style. I would support formally deprecating it and allowing users to migrate the style of existing articles, but I would stop short of disallowing new articles with the style. Just start considering {{Use Harvard referencing}} a maintenance tag, and people who care about this sort of thing (possibly including myself) will be able to migrate the syntax, just as people copy-edit articles to make them comply with WP:MOS. I should also note that the ArbCom case was mostly in the context of a single disruptive user edit-warring over style issues, and the preservation of citation styles, in particular, seems (to me) almost incidental to the case. Vahurzpu (talk) 15:56, 5 August 2020 (UTC)
• Oppose per the above !votes in opposition. The claim that parenthetical citations "clutter the text and make reading more difficult" seems more a matter of taste than something empirically supported; if the style was so fundamentally bad, surely style guides everywhere would warn against it, serious publications wouldn't use it, and schools wouldn't teach it. XOR'easter (talk) 06:30, 6 August 2020 (UTC)
• Strongly oppose. There are multiple valid uses of parenthetical citations, even in articles using Wikipedia's more-common footnoted references: referring to a publication in-text by Author (Year) in contexts where that is encyclopedic information rather than mere reference-clutter; referring to a different page in an earlier footnote by putting a parenthetical citation into another footnote; giving a shortened footnote to a reference in an article that (because there are many references or many reused references) keeps footnotes short and has a longer bibliography of complete references separate from the footnotes. This proposal makes no distinction among these uses, nor among the other now-less-common use of having inline parenthetical citations in place of footnotes, but just declares them all invalid. It is an overbroad solution to a non-problem. It is the foolish consistency that we have all been warned about. It is WP:CREEPy. It is a slippery slope that flies in the face of WP:CITEVAR and sets a bad precedent that is likely to be made worse by future removals of allowed variations in citations. And it will make far too much makework for gnomes instead of encouraging editors to do the real work of content creation and cleanup. —David Eppstein (talk) 06:32, 6 August 2020 (UTC)
  • @CaptainEek: without parenthetical referencing, how exactly do you propose to format articles in which many footnotes refer to different pages within the same book, such as (to pick a Good Article example) Hypatia? (Actually Hypatia uses the parenthesis-free Author Year style in its footnotes but it's more or less the same concept as the one this proposal would ban.) Do you think the entire citation to the book should be repeated over and over in each separate footnote? Do you think that magically parenthetical referencing within footnotes would be excluded from your deprecation even though your proposal says nothing about such exclusions? —David Eppstein (talk) 19:09, 6 August 2020 (UTC)

    David Eppstein, Hypatia does not seem to use parenthetical style? It uses our supported sfn system, which I think is fine and dandy. Perhaps there's a misunderstanding as to what I mean by the parenthetical style? I only refer to the practice of inline parenthetical references that do not create references that can be auto-compiled into a reference list. CaptainEek ^{Edits Ho Cap'n!}⚓ 19:21, 6 August 2020 (UTC)

    If you think that is not parenthetical style then you need to make your proposal much much more specific to match what you think more closely to what the proposal actually says. The sfn system is an example of parenthetical style (within footnotes). It is irrelevant that the article happens to use harvnb instead of harv or harvtxt within the formatting (so that the footnotes are formatted as Author Year rather than (Author Year) or Author (Year)) — that is not the level of detail of referencing style that we should be legislating. Your proposal deprecates parenthetical style everywhere, not merely parenthetical style used inline purely for referencing. For another example, look at the article text of Dehn invariant — at one point the article states "Dehn, in his 1900 habilitation thesis..." while later on it has the text "As Dehn (1901) observed...". The second example is a parenthetical reference. Your proposal would deprecate it. So you may have thought you were proposing only a change to referencing style, but are actually proposing to impose constraints on the content of our articles. If you did not intend such sweeping changes, I suggest you withdraw your proposal and think harder about what it is you actually intend to accomplish before proposing innocuous-appearing changes that have much more significant effects than intended. —David Eppstein (talk) 19:30, 6 August 2020 (UTC)

• Oppose – I can't add anything to those well argued opposing points above. -- Michael Bednarek (talk) 07:48, 6 August 2020 (UTC)
• Support This one is a toughy since I hate parenthetical citations, but this seems like CREEP and I'm therefore surprised that it has received the amount of support that it has (and I'm still not sure it'll pass). What swings me to this position anyway is that a) nobody reads the MoS before they join, so they're not going to be like "Oh boy, I can't wait to add a Wikipedia article!" and then be shocked and disheartened by our fairly large set of style minutiae, b) readers will always be orders of magnitude more numerous than editors, and footnotes are ultimately more reader-friendly than parenthetical citations (if only slightly), and c) Levivich et al. have convinced me that this is a gentler solution than how it might appear. This might (emphasis might) also improve accessibility by having citations be special footnotes for the use of screen-reading software (not to mention being focusable) rather than plain text. – John M Wolfson (talk • contribs) 11:07, 6 August 2020 (UTC)
• Strongly oppose: The proposal wrongly assumes that there are only two citation styles: author-date and footnote. But there is also a hybrid style (call it short-cites) where short citations (author-date) are used within footnotes using {{harvtxt}} & {{harvnb}} & {{sfn}} templates. When using this hybrid style, it is occasionally useful to use a {{harvtxt}} template within the article body, even though the overall style is short-cites, thereby avoiding the readability problems of author-date style mentioned in the proposal. A major benefit of author-date and short-cite styles is that the reference list is (typically) sorted by author name, which is extremely helpful in fields such as the humanities and some social studies where author names are especially important. I have discussed why this is so at Talk:Psychotherapy § Citation style, where I wrote: Second, your assertion that Wikipedia users don't care about author names disregards the variability in the subject matter of Wikipedia articles and in the purposes of Wikipedia users. The importance of authors may vary by field: in the humanities, where the subject matter is often personal experiences and opinions, who authored a source is often extremely important; in the empirical sciences, where the subject matter is often impersonal data and models, who authored a source is less important. The proposal completely ignores such differences between fields of study. The proposal claims that the author-date style exists because it is used in scientific papers and college essays. This is wrong. In fact, scientific papers in many scientific fields don't use author-date style. In the fields where author-date style is used, it is for a good reason, often related to the benefit of having a reference list that is (typically) sorted by author name. Editors can be encouraged to avoid the worst readability problems of author-date style without a global ban of all author-date citations. In conclusion, this is a terrible proposal that misunderstands the purpose of citation-style diversity. Biogeographist (talk) 11:15, 6 August 2020 (UTC)
• Oppose however, I wouldn't mind if we adopted the <ref> style citations as the preferred style, even to the point of allowing editors to refactor other styles to that style - provided it can be done in a very careful manner (certainly not to an article that is actively being created - maybe on something like an article that hasn't had a citation updated in over a year or something like that). — xaosflux ^Talk 14:03, 6 August 2020 (UTC)

Xaosflux wrote: even to the point of allowing editors to refactor other styles. WP:CITEVAR already permits such refactoring, when there is consensus. And if there is well-reasoned opposition to such refactoring in a particular article, then the refactoring shouldn't be done. Biogeographist (talk) 14:45, 6 August 2020 (UTC)

@Biogeographist: basically I'm in favor of strengthening that, and preferring that inline-footnote style is "preferred" - to the length that if an article has become somewhat stable changing to that form shouldn't require determining a page consensus first. Just my opinion though, — xaosflux ^Talk 16:17, 6 August 2020 (UTC)

@Xaosflux: So it's your opinion that even shortened footnotes (author-date style within footnotes: {{sfn}}) are illegitimate and should be refactored? Biogeographist (talk) 16:38, 6 August 2020 (UTC)

@Xaosflux and Biogeographist: To my understanding, {{sfn}} is NOT considered a parenthetical citation style as discussed here (i.e., it's not covered at Wikipedia:Parenthetical referencing). It's not something we can effectively get rid of, in any case, because it is meant as the go-to approach for citing individual page numbers in a multiply cited work. I'd strongly oppose throwing that out. --Elmidae (talk · contribs) 16:46, 6 August 2020 (UTC)

(edit conflict) @Biogeographist: absolutely not, I don't think any of the reference styles are illegitimate; just that there is a benefit to preferring one. I'm not speaking so much to the markup style, just the results here as well - regarding your mention of {{sfn}}: it actually does result in a <ref> style result already (the output of the module invocation is a ref tag). An example of what I'm talking about would be the references in Lottery paradox for example. — xaosflux ^Talk 16:52, 6 August 2020 (UTC)

Specifically, in my Lottery paradox example, I think it would benefit the reader more to use a more data-integrated reference style here - not that there is anything wrong with the current referencing. I keep meaning to refactor this one (as I already got OK from the primary author) but keep not getting around to it. — xaosflux ^Talk 16:56, 6 August 2020 (UTC)

@Elmidae and Xaosflux: See Wikipedia:Citation templates § Harvard reference and shortened footnote examples and Template:Harvard citation documentation, both of which group Harvard (author-date) citations and shortened footnotes together. Wikipedia:Parenthetical referencing § Examples lists Irish phonology as an example of a featured article that uses author-date citations, and Irish phonology uses a combination of {{Sfn}} in addition to inline {{Harvcoltxt}} and {{Harvcolnb}}. Wikipedia:Author-date referencing and Wikipedia:Harvard referencing redirect to Wikipedia:Parenthetical referencing. Therefore, "Harvard", "author-date", and "parenthetical" all refer to the same citation style. If you are arguing in favor of deprecating author-date referencing, you are arguing in favor of deprecating all of those templates. And the effect is the same if you are arguing in favor of refactoring all author-date referencing to standard footnotes after an article becomes stable. Biogeographist (talk) 17:05, 6 August 2020 (UTC)

All of those templates are invoking Module:Footnotes - so they are already using data-integrated citations. Did you see the example I specifically referred to above that is just using free-text citations? That is what I think should be less-preferred (though it is 100x better than not having citations and therefore shouldn't be disallowed by editors - especially ones that don't care or don't know other ways). — xaosflux ^Talk 17:19, 6 August 2020 (UTC)

@Xaosflux: I saw your example. But the proposal here is to deprecate even the author-date referencing that invokes Module:Footnotes: see the example cited in the original proposal, Actuary. We need some new terms to differentiate between author-date referencing that does and does not invoke Module:Footnotes. Biogeographist (talk) 17:35, 6 August 2020 (UTC)

@Biogeographist: the proposer specifically says I propose that we formally deprecate the parenthetical citation style. - it doesn't say only ones using certain markup templates. My suggestion is that using markup and the auto-references section should be preferred to using plain text parenthetical citations and plain text manual references sections. — xaosflux ^Talk 17:47, 6 August 2020 (UTC)

Xaosflux wrote: My suggestion is that using markup and the auto-references section should be preferred to using plain text parenthetical citations and plain text manual references sections. By "markup" I assume you mean author-date referencing that invokes Module:Footnotes. Fair enough. That's more specific than your !vote above. It's also more specific than the original proposal above, which proposes deprecating all author-date referencing, whether it does or does not invoke Module:Footnotes. Biogeographist (talk) 17:56, 6 August 2020 (UTC)

• Strong support. The goal of a reference is to transmit information. There is no fundamental advantage of one style over the other, so having a proliferation of styles just makes it harder for tools to manage the data. -- RoySmith (talk) 16:00, 6 August 2020 (UTC)

RoySmith wrote: There is no fundamental advantage of one style over the other but I mentioned a major advantage of author-date and short-cites styles above. Other advantages are listed at Parenthetical referencing § Advantages. Biogeographist (talk) 16:38, 6 August 2020 (UTC)

Biogeographist, I assume you are referring to A major benefit of author-date and short-cite styles is that the reference list is (typically) sorted by author name, which is extremely helpful in fields such as the humanities and some social studies where author names are especially important. I think you've missed the point. How a list is sorted is a matter of presentation. If the underlying data were stored in a uniform, machine-parsable, format, it would be trivial to build a tool which sorted the references any way you wanted. -- RoySmith (talk) 17:16, 6 August 2020 (UTC)

@RoySmith: Ah, I see. You're right, I missed the point. Does your tool already exist, or is it hypothetical? Better build the tool first before banning author-date referencing! We have to see how well your tool works before we decide to use it instead. Biogeographist (talk) 17:35, 6 August 2020 (UTC)

• Strong support. More than once I have come across an article with parenthetical citations like (Smith 2008) in the text and no other referent in the article indicating who "Smith" is or what any such person wrote in 2008. This sort of error is made possible when the items of information are allowed to become detached in the first place, so that the editor writing the content can forget to even include the referenced citation, or another editor reusing a piece of content can forget to port it over. BD2412 T 16:25, 6 August 2020 (UTC)

The disadvantages that BD2412 mentioned also occur with ref tags: More than once I have come across duplicate ref tags, or ref tags with incomplete citation information. Negligent editors are not a good reason to globally ban author-date citations, since editors can be just as negligent with ref tags. Biogeographist (talk) 16:38, 6 August 2020 (UTC)

Ref tags can be rescued. Parentheticals for which the corresponding citation is never added can not. BD2412 T 17:45, 6 August 2020 (UTC)

I'm fairly sure that I've had to remove unrecoverable ref tags more than once. There's no difference. In both cases it's a lack of sufficient info that impedes verifiability. Biogeographist (talk) 17:50, 6 August 2020 (UTC)

• Comment References can be nested with template:refn. This can preserve the citation style, and reduce clutter. --Emir of Wikipedia (talk) 16:56, 6 August 2020 (UTC) (please  mention me on reply; thanks!)

@Emir of Wikipedia: I don't see the relevance to this discussion. Can you give an example of how nesting references with {{refn}} applies to author-date referencing? Biogeographist (talk) 17:10, 6 August 2020 (UTC)

Biogeographist, an example is the first reference in this edit. The parenthetical citations would be preserved in the reference list, but they would not clutter the article. Emir of Wikipedia (talk) 17:15, 6 August 2020 (UTC)

@Emir of Wikipedia: Thanks. Your edit is basically a shortened footnote. Shortened footnotes are used, for example, in Irish phonology which is listed in Wikipedia:Parenthetical referencing § Examples as an example of a featured article that uses author-date citations. It's funny that your chosen example edit was in Actuary, since I just proposed converting that article to shortened footnotes: see Talk:Actuary § Shortened footnotes proposal, August 2020. Biogeographist (talk) 17:35, 6 August 2020 (UTC)

The proposal does not say that shortened parenthetical citations are ok within footnotes. It just says they are to be deprecated in general, wherever they might appear. So this suggestion is not compliant with the proposed deprecation. —David Eppstein (talk) 19:13, 6 August 2020 (UTC)

David Eppstein, That is not what I meant for the proposal to say, and I'm sorry if that was misconstrued. As suggested by the Actuary article, my problem was only with the non-footnote parentheticals. I am perfectly fine with sfn, and think that turning existing parentheticals into sfn's is one of the ideal solutions here. CaptainEek ^{Edits Ho Cap'n!}⚓ 19:23, 6 August 2020 (UTC)

Proposals that get enacted within Wikipedia MOS and guidelines often turn out to be interpreted by stubborn and gnomish editors who insist that the actual wording of the proposal, and not its original intent, should be adhered to rigidly throughout the encyclopedia. So if that interpretation is not what you intended, then your proposal is flawed, and should be fixed before we accidentally break a lot of articles that are properly referenced by forcing their references into a more constrained format that cannot accomodate the flexibility required for short citations or whatever. —David Eppstein (talk) 19:41, 6 August 2020 (UTC)

Note There has been some confusion about the wording, so let me clear that up. I am not proposing we ban ALL parenthetical references. I am merely proposing that we do not use inline, non software based, text parentheticals. This is NOT a proposal to ban Template:sfn, or Template:Harv (as long as it is properly nested in a ref tag). The only goal is to make it so that instead of seeing Ipsum lorem facto (Eek, 2020), we end up with Ipsum lorem facto with a little blue ref number at the end, which leads to a footnote that can still say "(Eek, 2020)". As I mentioned below, I think the best solution to existing references is to simply convert them to sfn. CaptainEek ^{Edits Ho Cap'n!}⚓ 19:44, 6 August 2020 (UTC)

Issues raised by Citation bot

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)

Title linking

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!v^ich 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^{(talk•contribs)} 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)
• 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)

• 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)

Duplicate linking

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=https://doi.org/... 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!v^ich 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 (talk ⋅ contribs) 08:54, 5 August 2020 (UTC)
• Yes 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)

Link removal

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!v^ich 01:58, 5 August 2020 (UTC)
  • There is zero reason to have both |pmc=91234 and |url=https://www.ncbi.nlm.nih.gov/pmc/articles/PMC91234/. Likewise for having both |pmid=91234 and |url=https://pubmed.ncbi.nlm.nih.gov/91234. 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!v^ich 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=https://pubmed.ncbi.nlm.nih.gov/91234 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. -- GreenC 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)

      Can you verify if this is autolinking?

      • Hoffman S.J.; Lavis J.N.; Bennett S. (2009). "The Use of Research Evidence in Two International Organizations' Recommendations about Health Systems". Healthcare Policy. 5 (1): 66–86. doi:10.12927/hcpol.2009.21005.

      In this example it would be redundant to add |url=https://doi.org/10.12927/hcpol.2009.21005 because it is the same URL as is already generated - most everyone agrees about this. In terms of archives, doi.org 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

      • Hoffman S.J.; Lavis J.N.; Bennett S. (2009). "The Use of Research Evidence in Two International Organizations' Recommendations about Health Systems". Healthcare Policy. 5 (1): 66–86. PMC 2732656.

      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?

      • Coulter DA, Huguenard JR, Prince DA (June 1989). "Characterization of ethosuximide reduction of low-threshold calcium current in thalamic neurons". Annals of Neurology. 25 (6): 582–93. doi:10.1002/ana.410250610. PMID 2545161.
      • Coulter DA, Huguenard JR, Prince DA (June 1989). "Characterization of ethosuximide reduction of low-threshold calcium current in thalamic neurons". Annals of Neurology. 25 (6): 582–93. doi:10.1002/ana.410250610. PMID 2545161. S2CID 20670160.

      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=https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2732656 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)

• 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)