Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Seraphimblade (talk | contribs) at 18:13, 5 September 2020 (→Deprecate parenthetical citations: Final closure with statement.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New proposals are discussed here. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.


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)[reply]

I think you have actually identified two distinct issues here: 1) we don't have any evidence that stub tags are achieving their stated purpose, and 2) stub tags are conflicting with WikiProject assessments. For #1, I think an experiment could yield from interesting results. For #2, I think this would make a nice bot task to remove stub tags when a WikiProject assessment is upgraded from stub. It might be worth upgrading {{WPBannerMeta}} to generate a reassess flag for the bot to add when a stub tag is removed, but a WikiProject still has it assessed as a stub. For the experiment on #1, I would suggest:
  1. Get a list of something like 10,000 random articles, and remove any that are not assessed as a stub by WikiProjects, or have neither a stub tag nor a WikiProject banner on its talk page.
  2. Do an assessment of the remaining articles and remove any that aren't actually stubs.
  3. Split WikiProject claimed articles by stub-tagged or not, and remove/add stub tags to get each WikiProject's article count roughly even (shoot for at least 1/3 of each). Remove stub tags from the unclaimed articles to even out the total count, again going no less than 1/3 for either group.
  4. For the two groups, drop the top and bottom (quartile? ⅒th?) in terms of edit size, ignoring any bot edits, and compare the two groups by interest (number of edits by unique editors), engagement (number of non-revert, non-patrolling edits by registered editors), and overall article change (total prose added to article during experiment run time). VanIsaacWScont 14:17, 21 June 2020 (UTC)[reply]
    Thanks for your input. Abductive (reasoning) 23:07, 21 June 2020 (UTC)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
Yes. In fact, the MilHistBot is already capable of carrying out this task. Hawkeye7 (discuss) 22:57, 20 July 2020 (UTC)[reply]
AWB does something similar, too, by removing stub tags from articles that are above a (generous) size. WhatamIdoing (talk) 00:35, 7 August 2020 (UTC)[reply]
  • "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)[reply]
    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)[reply]
  • 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)[reply]
    @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)[reply]
  • 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)[reply]
    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)[reply]
    There are 3,399,601 stubs as of now. You can see the stats here. TryKid [dubious – discuss] 23:28, 22 June 2020 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • 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).[reply]
    • 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)[reply]
  • 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)[reply]
  • Oppose per MrSwagger21. - ZLEA T\C 02:52, 23 June 2020 (UTC)[reply]
  • 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)[reply]
  • Oppose no. They are helpful and low-key. Not in anybody's way. Regards, GenQuest "Talk to Me" 10:47, 23 June 2020 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    "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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support Stubs are messy and the visual clutter is immense for the reader.Epelerenon (talk) 05:25, 3 August 2020 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    Thank you Oulfis, this is exactly what I meant, and apologies for the confusion. — Bilorv (talk) 20:47, 4 August 2020 (UTC)[reply]
    Ok, thanks for the clarification. Johnbod (talk) 21:07, 4 August 2020 (UTC)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Strong Support - Useless garbage. Schierbecker (talk) 14:22, 5 August 2020 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support — My opinion is the stubs are graffiti and serve no useful purpose. —¿philoserf? (talk) 08:07, 8 August 2020 (UTC)[reply]
  • I think I fall on the oppose side of the s-o spectrum. I don't think it makes sense to rely on WP ratings (as noted above, many pages end up with stub tags but no WP tags). For utility, I do tend to agree that the "find short articles that could use expansion" side is fairly convincing from a utility-aesthetics spectrum. I do find it a bit obnoxious that sometimes these don't match the WP ratings, but that's a job for a bot (as noted above). If I have any pain point with stub tags, it's that they basically duplicate our category structure (whether on the article side or the WP side), and could use a much smaller tree from which to select a stub tag. (I might even suggest that we should remove all sub-stub tags and put the weight on proper categories and proper WP tags; editors interested in stubs for the categories of interest can use one of our intersection tools such as WP:PetScan.) From a visibility perspective, I actually kind of like the idea of going full {{ambox}} on them.

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

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

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

Deprecate parenthetical citations

This discussion has reached a consensus that inline parenthetical referencing should be deprecated. Please see the section #Parenthetical citation closure for details and rationale. Seraphimblade Talk to me 18:13, 5 September 2020 (UTC)[reply]

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

I propose that we formally deprecate the inline 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 FAs 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)[reply]

The most recent arbitrary break is the following: #Arbitrary break 4 (citations). Steel1943 (talk) 16:14, 4 September 2020 (UTC)[reply]
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)[reply]
Note upon note As to the other main wrinkle: use of The paper by Eek (2020) showed and Eek (p. 35). I also suggest this be phased out, in the interest of consistency. CaptainEek Edits Ho Cap'n!⚓ 20:09, 6 August 2020 (UTC)[reply]
CaptainEek, I think it would be a useful clarification here if in addition to stating your intent for the RfC you give an example of the wording change to CITEVAR (or elsewhere) that meets those intentions. Mike Christie (talk - contribs - library) 16:23, 31 August 2020 (UTC)[reply]
I don't want to speak for someone else, but I suppose a proposal to implement the proposed deprecation at WP:CITEVAR might look somewhat like this:

Add a bullet to WP:CITEVAR#Generally considered helpful:

  • Converting parenthetical references to numbered footnotes, unless either 1 or 2 below, or both, apply:
    1. The article is about a topic for which, in reliable sources, parenthetical references are commonly used, and there is an established consensus on the article's talk page that the article will only use parenthetical references.
    2. The conversion creates a mess.

This implementation proposal seeks a middle way between very hard implementation ideas (e.g., deprecate outright and/or enforce by bot) and softer implementation ideas (e.g. only deprecate for new pages), both directions already being elaborated in the survey area below. --Francis Schonken (talk) 09:13, 2 September 2020 (UTC)[reply]

Survey start (citations)

  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
  • Support not accepting it in new articles. As a reader, I find it the most unfriendly form of citation style in articles. edit to add clarification based on extensive following discussion: For new articles, I support not accepting the use of text-only citations in parentheses that do not create hyperlinked footnotes, such as (Smith, 2012). My understanding is that this RfC is not about any other type of parenthetical citation. end added text Schazjmd (talk) 19:51, 4 August 2020 (UTC)[reply]
  • Support It makes articles harder to read. ―Susmuffin Talk 19:55, 4 August 2020 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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. (See discussion below) 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)[reply]
  • 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)[reply]
  • 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!vich 01:03, 5 August 2020 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
Given how rarely they are used, I find it doubtful that the demographic of new editors that you mention would be able to find out about parenthetical citations in the first place. To do so, one has to navigate the byzantine (for a newcomer, at least) network of meta-informational pages and find the appropriate MoS guideline, as opposed to figuring out a format that that has an example on almost every article. As for editors who import external material, I think that if they don't have the time to change the citation style (something that can easily be done with a script), then they probably don't have the time to properly vet the material and determine that it is suitable for Wikipedia. - Axisixa T C 01:11, 30 August 2020 (UTC)[reply]
  • 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).[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • @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)[reply]
      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)[reply]
      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)[reply]
  • Oppose – I can't add anything to those well argued opposing points above. -- Michael Bednarek (talk) 07:48, 6 August 2020 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
    • Biogeographist, from the Captain's comment above, I think that Psychotherapy would require no changes, even if this proposal were enforced retroactively. He actually seems to want a very minimal case, in which anything that looks like [1] ("little blue clicky numbers") is okay, and the only thing that gets deprecated is something that looks like "(Smith 2019)". Psychotherapy has plenty of little blue clicky numbers. WhatamIdoing (talk) 22:39, 6 August 2020 (UTC)[reply]
      Right, I took my quotation from Talk:Psychotherapy out of context. There it was part of an argument for why someone's bot should not strip author first names from citations (if I remember correctly). Here it supports the argument that the proposal ignores important differences between fields of study that would make author-date referencing more appropriate in some subjects than in others. Biogeographist (talk) 23:09, 6 August 2020 (UTC)[reply]
  • 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)[reply]
    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)[reply]
    @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)[reply]
    @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)[reply]
    @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)[reply]
    (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)[reply]
    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)[reply]
    @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)[reply]
    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)[reply]
    @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)[reply]
    @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)[reply]
    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)[reply]
    @Xaosflux: I often use {{sfn}} when I am citing multiple pages from one or more sources, e.g. Alphonse van Gèle. It does not clutter up the text, either for the editor or the reader, but allows for precise citations without having to replicate the complete source definition for each page or section cited. I would be strongly opposed to allowing editors to change from {{sfn}} to <ref></ref> style without discussion. That said, I see no need for any styles other than {{sfn}} and <ref>, which can be intermixed in one article, with either text or {{citation}} to format the source definition. Aymatth2 (talk) 00:59, 4 September 2020 (UTC)[reply]
    Hi @Aymatth2: thanks for the note, I've got no issue with that at all, as it actually is already using <ref>, just wrapped in another template. For example, {{sfn|Smith|Jones|Brown|Black|2005|p=25}} expands to <ref name="FOOTNOTESmithJonesBrownBlack200525">[[#CITEREFSmithJonesBrownBlack2005|Smith et al. 2005]], p. 25.<span class="error harv-error" style="display: none; font-size:100%"> sfn error: no target: CITEREFSmithJonesBrownBlack2005 ([[:Category:Harv and Sfn template errors|help]])</span></ref>. The only thing I'm suggesting is that we strongly support references that intergrate in to the references markup over the simple plain text pararenthicial format. — xaosflux Talk 01:24, 4 September 2020 (UTC)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    @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)[reply]
  • 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)[reply]
    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)[reply]
    Ref tags can be rescued. Parentheticals for which the corresponding citation is never added can not. BD2412 T 17:45, 6 August 2020 (UTC)[reply]
    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)[reply]
    The problem outlined by BD2412 can occur whenever a system of shortened citations is used. It doesn't matter if it's the in-line parenthetical citations discussed here, or shortened footnotes (as the ones produced by the ubiquitous {{sfn}}). – Uanfala (talk) 19:21, 17 August 2020 (UTC)[reply]
    Uanfala is correct, this problem isn't caused by parenthetical referencing. And the problem usually isn't even that difficult to fix. It usually arises when an editor copy-pastes some text from one article that uses short-form refs into another, and forgets to copy the corresponding full cites. For example, there were two cites missing from Main conjecture of Iwasawa theory, and it only took a few seconds to realise they were likely in Iwasawa theory, from which the article had been split. Problem solved. In the few cases where that doesn't work, a search on the wiki source text will usually find it. --NSH001 (talk) 14:20, 18 August 2020 (UTC)[reply]
  • 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 Reply to icon mention me on reply; thanks!)[reply]
    @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)[reply]
    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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    At the risk of repeating what I already said above, I agree that this is a terribly formulated proposal. Wikipedia:Parenthetical referencing covers a range of variants. I am more sympathetic to CaptainEek's new first amendment that permits {{sfn}} and the {{harv}} variants in footnotes, but I don't agree with the new second amendment that would ban even very occasional in-text {{harvtxt}} references (e.g. "Eek (2020) proposed") in articles that already use shortened footnotes. That second amendment strikes me as unreasonable since permitting occasional in-text {{harvtxt}} references in articles that already use shortened footnotes neither eschews hyperlinked references nor impedes readability, which were the original proposal's stated reasons for deprecating author-date citations. See Irish phonology for a featured article that sensibly mixes occasional in-text {{harvtxt}} references with shortened footnotes. It's perfectly readable, at least as readable as an article on phonology can be expected to be. Biogeographist (talk) 21:07, 6 August 2020 (UTC)[reply]
  • Oppose deprecating the style entirely, but I do rather like xaosflux's proposal above of making the <ref> citation style the "preferred" Wikipedia style (including any templates that generate such markup). I personally prefer the footnote style also, but per Wugapodes above, we already make life difficult enough for new editors, and while I am appreciative of the argument that ultimately we are serving the reader, I think we would be unnecessarily burdening new editors with even more rules while providing very little (though admittedly positive) overall reader benefit. However, establishing a preferred (but not rigidly enforced) style for citations allows contributors to provide proper citations in any way they are able, and others can come later, after the article has reached some semblance of stability, to adapt them to the preferred style. CThomas3 (talk) 21:14, 6 August 2020 (UTC)[reply]
    But it would be important to explicitly state that the "preferred" style does not exclude shortened footnotes, as clarified in CaptainEek's new first amendment. Biogeographist (talk) 21:32, 6 August 2020 (UTC)[reply]
    @Cthomas3: to clarify what I discussed with @Biogeographist: above, I think we should prefer referencing that uses ref tags and ref sections - but I'm not really picky about how we go about doing that (e.g. via a literal ref tag, via a template of pretty much any style that incorporates the ref tag, etc) - but that literal plain text parenthetical citations should be less preferred. — xaosflux Talk 13:42, 7 August 2020 (UTC)[reply]
    Xaosflux and Biogeographist, that's what I was trying to get at when I said "including any templates that generate such markup". I'm right there with you, I don't think we need to specify exactly how we generate the tags, just that anything that generates them is perfectly fine. And I certainly would not want to specifically exclude anything like shortened footnotes. CITEVAR would still apply to any valid style. CThomas3 (talk) 16:18, 7 August 2020 (UTC)[reply]
  • Strong support - This misinterpretation of this proposal is unbelievable since it so clearly refers to parenthetical citation that are in the text itself; hopefully Eek's amendments have made that clearer. The style used in article like Irish phonology and Battle of Red Cliffs simply hurts the reader and distracts them from the content, there's not much more to say than that. Some of these reasons for opposition are equally baffling, the average reader will not care who the author is, and throwing that in their face is pointless: the History of the discipline section in this article is hardly even readable. If a statement/idea is so importantly founded or thought of by a specific scholar, then a well written article would simply say something like: "John Smith suggested that...". There are also some serious assumptions about some imaginary groups of editors that will leave Wikipedia if their preferred citation style (Keep in mind – a citation style not at all commonly used nowadays) is removed. I used sfn and sometimes nested harv, but I wouldn't just leave Wikipedia if one were removed, I mean what?? If it's that easy for something to push you out of Wikipedia then I had no idea how you're still here. Aza24 (talk) 21:49, 6 August 2020 (UTC)[reply]
    Aza24 wrote: the average reader will not care who the author is. This may be true of Irish phonology § History of the discipline, so I agree that section may overdo it. When I said "occasional in-text {{harvtxt}} references" above I didn't mean in every sentence, more like once per paragraph if necessary or convenient. But it's just not true that in all fields all average readers will not care about authors. In humanities fields such as philosophy that are cross-generational conversations, it matters very much who said what and when they said it, and author-date referencing with a reference list sorted by author name makes sense. Biogeographist (talk) 22:09, 6 August 2020 (UTC)[reply]
    Glad to see that I am also interrogated by the same user who feels the need to go through every opposing viewpoint and pick out whatever they can to disagree with... But I'm sorry, what you're saying does not make sense. Every citation style dictates who the author is, every single one, if a reader is so inclined to see who the author is all they need is to hover over the ref, so I really have no idea what you're getting at. Putting the name in the citation of text does nothing but add unnecessary distraction and confusion. You seem to have completely ignored what I said about if the name is important or the idea is intrinsically linked with a certain individual then it should be in the text anyways, outside of the citation – something which is already common practice for well written articles. Aza24 (talk) 22:21, 6 August 2020 (UTC)[reply]
    I don't disagree with your statement that a well written article would simply say something like: "John Smith suggested that..." so I didn't address it. In fact that's typically how I write. I agree that articles with footnotes are generally better written. But I don't agree that every article with "occasional in-text {{harvtxt}} references" is necessarily badly written or unreadable enough to justify universally deprecating the style. Every citation style dictates who the author is, as you said, but not every citation style sorts the reference list by author. There are more advantages to sorting the reference list by author that I could list (such as easily seeing at a glance which works by an author are cited). This makes perfect sense to me, but if it doesn't make sense to you then I can understand that you would strongly support the proposal. And regarding your comment that I am a user who feels the need to go through every opposing viewpoint and pick out whatever they can to disagree with, that's not true: The comment immediately above yours is on "my side" of the debate, but I responded to that one too because I had information to add. And if I think of additional information that expands the conversation, why shouldn't I add it? Biogeographist (talk) 23:09, 6 August 2020 (UTC)[reply]
  • Support - I'm a psychologist who eschews APA style whenever possible. The parenthetical citations interrupt the flow of the text; they require flipping back and forth (print) or scanning back and forth; and the style permits lazy referencing in which the author does not have to specify where in a document he/she/they find support for their argument or statement. I realize this proposal is not about APA style per se. I simply wish to explain my support for discharging most forms of parenthetical citation on the English Wikipedia. // The "second type" of deprecation seems preferable: "editors can replace this unless there is a specific consensus against doing so" (see the astute comment by AntiCompositeNumber near the beginning of this section).   - Mark D Worthen PsyD (talk) (I'm a man—traditional male pronouns are fine.) 00:06, 7 August 2020 (UTC)[reply]
    Markworthen wrote: the style permits lazy referencing in which the author does not have to specify where in a document he/she/they find support for their argument or statement. This is a major problem in too much social-science scholarship, but can be an issue with standard ref tags too—hence the {{page needed}} tag. See Common factors theory for an example of an article in psychology, much of which I wrote, that uses author-date style in shortened footnotes with plenty of page numbers. Biogeographist (talk) 00:28, 7 August 2020 (UTC)[reply]
    Excellent points Biogeographist. In this instance Wikipedia is requiring a higher level of scholarship when it comes to reliable sources than many prominent psych journals. // Btw, Common factors theory a very good article on an important subject.  - Mark D Worthen PsyD (talk) (I'm a man—traditional male pronouns are fine.) 00:00, 8 August 2020 (UTC)[reply]
    @Markworthen: All ref styles used on Wikipedia permit lazy referencing in which the author does not have to specify where in a document he/she/they find support for their argument or statement - whatever style I use, I am not forced to enter a page number, nor is there any kind of warning or error message should I forget. Parenthetical refs are no different in this regard: moreover, there is nothing about them which hinders the provision of a page number. The article Actuary has been mentioned; here, I see that some (but by no means all) of the refs explicitly show a page number, for instance (Trowbridge 1989, p. 7) at the end of the opening paragraph. Where page numbers are omitted from the parenthetical refs, either it's a source without page numbers (such as a web page) or the page numbers are provided in the full citation. --Redrose64 🌹 (talk) 11:46, 8 August 2020 (UTC)[reply]
    Redrose64 - Good point. I was specifically talking about my frustrations with APA style, but you highlight an important difference between the formal styles (APA, Bluebook, Chicago, etc.) and Wikipedia. I know that editors often ask for specific page numbers to support a statement, so there's at least some awareness of this topic. But do you think we need to place greater emphasis on the importance of specific page citations?   - Mark D Worthen PsyD (talk) (I'm a man—traditional male pronouns are fine.) 02:38, 9 August 2020 (UTC)[reply]
    I am not familiar with APA or those others - different academic institutions may set their own rules, and they might forbid the use of page numbers, I don't know. I have a book which I picked up one day when I was at Hertford College, Oxford, for an interview:
    • Fisher, David; Hanstock, Terry (1998). Citing References. Oxford: Blackwell. ISBN 1-85377-992-X.
    This book explicitly shows how to give a page number with a parenthetical ref. Academic institutions may require their students to adhere to particular rules when submitting their work, but we are not bound in that manner. If the source uses them, page numbers (or similar) are great to have, in the interests of WP:V; but that page (which is a core content policy document) mentions them just once - in the sentence (Cite the source clearly, ideally giving page number(s) – though sometimes a section, chapter, or other division may be appropriate instead; see Wikipedia:Citing sources for details of how to do this. Besides WP:CITE, it's covered more fully at Help:References and page numbers; and both of these include sections on parenthetical refs that show how to provide page numbers (see Wikipedia:Citing sources#Parenthetical referencing; Help:References and page numbers#Parenthetical referencing) so it's not as if the practice is either hidden away or discouraged, although WP:V could do with improvement in regard to page numbers in general.
    My point is that opposing a parenthetical style on the grounds that it may sometimes used without page numbers is a fallacious argument. I have yet to find a ref style used on Wikipedia that prohibits or discourages the use of page numbers, other than the obsolete WP:CS:EMBED method. --Redrose64 🌹 (talk) 14:17, 9 August 2020 (UTC)[reply]
  • Support the "second type" of deprecation, i.e. "editors can replace this unless there is a specific consensus against doing so". There are good uses of in-prose parenthetical citations, especially for print usages, and there are Wikipedia editors like me who use parenthetical citations in real life. But on Wikipedia, which is primarily online, this is quite unwieldy, and relatively rarely used in favor of footnotes (using <ref></ref> tags) and a reference list. Having parenthetical citations right in the prose may go so far to be be distracting and unhelpful, since there is no footnotes list (or a reduced one) provided in this format. Even the {{sfn}}-style and {{harv}}-style templates in footnotes are easier to comprehend.
    I understand that there are people who feel comfortable with parenthetical referencing, and that some people will remain opposed to this proposal. However, there are better ways of referencing on Wikipedia, in particular footnotes. In the end, these types of references are supposed to convey information to the reader, but the reader's experience can be hindered by putting parenthetical citations right in the prose, rather than in small, relatively inobtrusive brackets. epicgenius (talk) 01:08, 7 August 2020 (UTC)[reply]
    • @Epicgenius: so to be clear, do you support a different proposal than the one we're discussing, one that only applies to in-prose parenthetical citations that are intended purely as a reference and not as part of the article text? Or do you support the proposal we're actually discussing which even after two levels of attempted clarification still explicitly applies to examples like the Irish phonology link above where the main text of the article discusses authorship of publications? If the latter, which circumlocutions for discussing authorship in-text would you find to be acceptable alternatives, and why? —David Eppstein (talk) 01:24, 7 August 2020 (UTC)[reply]
      David Eppstein, I'm responding to what CaptainEek said in their first clarification: 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)". I am supporting the proposal all of the other comments seem to be replying to. As for the Irish phonology link, that would be treated as discussion of scholarly work rather than as examples of parenthetical citations (e.g. Some statement is mentioned in Scholar (2020). as opposed to Some statement. (Scholar 2020). It would be unnecessary to convert these to footnotes, and I would not support changing this if it's already in the article. epicgenius (talk) 14:31, 7 August 2020 (UTC)[reply]
  • Accept articles that indicate their sourcing in any manner, Support formally allowing&encouraging conversion of plaintext cites to <ref> cites. Update WP:Parenthetical_referencing to indicate that it is adequate if used, but that it can and should be upgraded to a proper ref. Alsee (talk) 02:50, 7 August 2020 (UTC)[reply]
  • Support – my take would be different (allowing the system to co-exist with the others) if I hadn't encountered some stubborness by adherents of the system to cling to it where it is really not suitable (example). Wikipedia is aiming at a broad readership (both scholarly and non-scholarly). In scholarship references-by-numbered-footnotes are used in all disciplines: no scholar has any difficulty understanding such system of referencing (even when writing about philosophical topics etc). For broad readership outside scholarship, numbered footnotes are far more easily digested. So adopting a fade-out scenario seems perfectly acceptable to me. In a first step, WP:CITEVAR could be updated saying that it is up to the proponent of harvard references that that referencing system is most commonly used in reliable sources when writing about the topic of the article. All other articles, where that can't be demonstrated, can then be transformed to numbered footnotes by editors willing to do so. I suppose such transformations should however never be operated by bot, while likely too counterproductive (too error-prone: a fix-by-bot may introduce more problems than it resolves). --Francis Schonken (talk) 08:03, 7 August 2020 (UTC)[reply]
  • Support I support to deprecate parenthetical citations like (Smith 2020) in new articles and also support converting existing articles into a style using clickable indices like[1] - not in a brute-force mass-movement hammering it down on all articles no matter what, but with good common sense applied: If an editor feels the urge to convert an article, s/he should not be hindered doing so, unless there is a clear consensus (based on good reasons why that is the style to be used in an article, not just road-block mentality) to continue to use parenthetical citations in that article, or unless an editor hanging on to parenthetical citations is still in the process of actively editing an article (so s/he isn't confused or discouraged). However, the default without such a consensus should be to allow the conversion rather than to rule it out it by some strange outgrow of WP:CITEVAR. Progress is important for us.
Some editors have brought forward the argument that our citation styles are difficult to grasp for new editors and that they should not be discouraged from editing because we need new editors, and therefore they should use whatever style they are used to. That's fine with me to a certain degree, however, there is also an argument to be made about existing editors (not) being discouraged from contributing to articles using (distracting to read and non-functional) parenthetical citations:
I have made the experience that some (typically not very well developed) articles are basically WP:OWNed by some editors who enforce parenthetical citations without adding anything to the article (any more). Some of them once contributed to the article years ago, others never added anything but just revert for the sake of it, even if the article is lacking and the contributions brought major additions. Such editors are basically just sitting there blocking out a significant portion of the potential degrees of future development of an article. So, for as long as these editors are actively contributing to an article, I think, they should have their way for the sake of it, but in the end, we are not here for ego-trips but to write an encyclopedia, and since articles are never complete and finished, our priority must be on improving article contents and functionality, not pleasing editors. Also, while CS1/CS2 citation templates might be difficult to master (in particular some esoteric special cases), using basic <ref>...</ref> wiki syntax is really easy stuff. So, if such editors don't contribute to an article for half a year or a year, the "grand-father clause" should automatically time out, so that, for the benefit of the article and the project as a whole, other editors feel more encouraged to contribute their stuff to such articles as well.
--Matthiaspaul (talk) 11:28, 7 August 2020 (UTC)[reply]
  • Strong support having a diversity of reference styles is not good for Wikipedia look. This is a hard to use style so let's deprecate it. We can say that a featured article must not contain this style of referencing. Graeme Bartlett (talk) 11:57, 7 August 2020 (UTC)[reply]
  • Support per Alsee (accept and change) and other arguments above regarding page clutter and readability. · · · Peter Southwood (talk): 14:20, 7 August 2020 (UTC)[reply]
  • Support per Alsee. – Majavah talk · edits 15:19, 7 August 2020 (UTC)[reply]
  • Oppose "A foolish consistency is the hobgoblin of little minds...". Andrew🐉(talk) 20:49, 7 August 2020 (UTC)[reply]
  • I'll Support per the principle of avoiding/eliminating unnecessary complexity. The encyclopedia generally does not benefit from multiple methods of accomplishing the same thing. I haven't seen an Oppose argument that outweighs that for me. I oppose limiting this (or virtually anything) to new articles, as most articles of real significance have already been created. ―Mandruss ☎ 23:59, 7 August 2020 (UTC)[reply]
  • Support — We must simplify the reference system. This is a good small step. —¿philoserf? (talk) 08:30, 8 August 2020 (UTC)[reply]
  • Oppose as the thin end of the wedge etc. I don't like this system at all, but it is dying the death naturally. Nor do I like the promoting of the horrible sfn style in the proposal. Johnbod (talk) 13:04, 8 August 2020 (UTC)[reply]
  • Tentative support. The arguments of Wugapodes et al are entirely valid, but as far as I can see this proposal wouldn't disallow articles written using that style, just as article written entirely without inline citations are not currently disallowed. Our software gives us the ability to link inline citations with corresponding bibliography entries, and doing this hugely improves accessibility. Given that, our citation guidelines should allow editors to switch to a format allowing that, without going to the trouble of having to obtain consensus first. As things stand, the original author's preference for an inaccessible style carries a lot of weight, and that's what I think needs to change. We should guard against this change becoming another thing to bite newbies with. Vanamonde (Talk) 16:04, 8 August 2020 (UTC)[reply]
    Parenthetical refs can also link to the corresponding bibliography entries, this is what {{harv}} does. --Redrose64 🌹 (talk) 16:39, 8 August 2020 (UTC)[reply]
    @Redrose64: Until it says so explicitly, I'm going to proceed in the belief that this proposal refers only to what the layman would describe as parenthetical refs, rather than the broader interpretation you and David Eppstein are proposing. As far as I am concerned, the sfn format is still a footnote format, that has author-date citations in the footnotes; it's not adding author-dates to the text itself. CaptainEek If you're proposing getting rid of harv citations, you need to make it explicit. If you're not, and I don't think you are, that might be worth clarifying in the proposal also. Vanamonde (Talk) 15:07, 9 August 2020 (UTC)[reply]
    Vanamonxe93 You are correct, I mean the narrow interpretation. As I have clarified at the top, I only mean inline citations, not the sfn/harv templates. The goal here is to make little blue numbers, not destroy all parenthetical citations. CaptainEek Edits Ho Cap'n!⚓ 19:06, 9 August 2020 (UTC)[reply]
    (edit conflict) I'm not suggesting that {{sfn}} and {{harv}} are the same - they're not, although the method that these use to link to the the corresponding bibliography entry is the same. Nor am I proposing we get rid of anything. I'm pointing out a fallacy, i.e. the claim that some have made that parenthetical refs cannot link to the corresponding bibliography entries when they demonstrably can. Using Actuary as an example, look at the lead section - there are ten parenthetical refs in the lead section, and every single one of them has a link to the corresponding bibliography entry. Click any you like: they all work. --Redrose64 🌹 (talk) 19:12, 9 August 2020 (UTC)[reply]
    @Redrose64: Okay, that's a fair point, but how many articles with parenthetical citations use that syntax? Also, with respect to that article, I'd argue that the added clutter is still a substantial concern; and at the very least, we need to give editors the ability to add that syntax to an article that uses unformatted parenthetical citations, which is also currently forbidden by CITEVAR without a consensus building exercise. Vanamonde (Talk) 16:06, 10 August 2020 (UTC)[reply]
    Almost seven thousand. --Redrose64 🌹 (talk) 17:49, 10 August 2020 (UTC)[reply]
  • Support per nominator. — Slade ☯ 10:00, 2 September 2020 (UTC)[reply]
  • Support per nom. There's no reason to be using kludgy reference formatting when we have tools that handle things much better and make the reading experience for regular users of Wikipedia better. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 23:49, 2 September 2020 (UTC)[reply]
  • Support per nom. this project is an encyclopedia, not a paper. Clone commando sev (talk) 00:06, 3 September 2020 (UTC)[reply]
  • Support - This is not a printed encyclopedia, or a college research paper typed double-spaced on an IBM Selectric with gobs of Wite-Out. It's time to abandon buggy whips and embrace accessibility, usability, and hypertext. - MrX 🖋 12:09, 3 September 2020 (UTC)[reply]
  • Support per nom. Anonimu (talk) 17:21, 3 September 2020 (UTC)[reply]
  • Support the "moving away from" part. If someone were to use in-line citations, I dont' think their contributions should be stripped automatically, but maybe these sort of articles could just be tagged with a "citation clean-up" notice. Something like that. All things considered, I'd love to see all Wikipedia articles use the same citation style, for consistency sake.--Gen. Quon (Talk) 19:00, 3 September 2020 (UTC)[reply]

Arbitrary break 1 (citations)

  • Strongly oppose per David Eppstein & DGG. In addition, I support xaosflux's above position of adopting the <ref> style citations as the preferred style; not deprecating paranthetical citations, though. 0qd (talk) 18:08, 8 August 2020 (UTC)[reply]
  • Support for a different option I see some support for deprecation of this option going forward while leaving existing articles and change that use this format. I'm going to suggest the exact opposite. This is inspired by @Wugapodes: support for allowing new editors to adopt a variety of styles (it's hard enough to start editing without imposing a potentially new referencing style – why not just let them do something they already know), as well as the observation that permitting multiple styles is jarring to the reader. Per WP:CITEVAR, we properly discourage multiple styles within an article (which means if a brand-new editor at an edit-a-thon wants to work on an existing article rather than a brand-new article they need to learn the style), but it is only a little less jarring to see different styles from article to article.
    We should:
    1. Pick a house style
    2. Allow new editors to use any style that works
    3. Task a bot to do the conversion to the house style
    Permitted exceptions where warranted (I don't pretend to have surveyed all citation styles, and there might be a good reason for a different style in some article or some special class of articles.)--S Philbrick(Talk) 18:09, 8 August 2020 (UTC)[reply]
    @Sphilbrick: While I generally like your idea, I would caution that getting a bot to interpret free-form citations would be exceedingly difficult, if not impossible. Especially if you're talking about articles created by users not familiar with Wikipedia, it's going to be a mess of different fields in different pieces, some random bare links, etc. I tried to write a citation parser once and failed; existing tools like AnyStyle are more for consistently-formatted academic citations than things found on Wikipedia. Vahurzpu (talk) 18:48, 8 August 2020 (UTC)[reply]
    Vahurzpu, I will not be surprised at all to find that some styles, or even worse, bare links aren't amenable to bot conversion. If we write the bot carefully, we will be careful not to force a style on something that doesn't support it, and leave that for humans to address. I don't pretend my proposal will solve every citation problem, but I think it's a step in the right direction.--S Philbrick(Talk) 18:54, 8 August 2020 (UTC)[reply]
    This proposal was deliberately not life, the universe, and everything. If you're interested in pursuing yours, I'd suggest some WP:VPI or WT:CITE time shaping how you think this would work. I know I've seen some light support for the idea that we should establish a house citation style, but I don't know whether 'light' is really enough to get a 'VPPRO nod' for it.--Izno (talk) 23:26, 9 August 2020 (UTC)[reply]
  • Support the proposal, which is directed at the beneficial goal of reducing clutter in the prose. Readability is important, and even for numbered references, we have wariness of clutter. The concerns raised mostly relate to specific interpretations and wording which can be discussed once the intended principle of the matter is established. I disagree that this change will throw off new users, given it is essentially proposing using whatever style they want, but putting <ref></ref> around it (rather than the misinterpretation that it will standardise a particular reference format). Adding two short tags is not remotely an equivalent hurdle to learning a new citation style. It is far less onerous than asking users to flesh out bare urls, which is a common and expected practice. I further suspect almost everyone who uses that citation style in other work will have faced far more onerous and annoying citation formatting reqiurements. This change would presumably be a MOS issue, rather than a matter of strict policy, and so would not be something that new articles get rejected over, or that editors get bitten over, more than any other part of MOS. CMD (talk) 19:25, 8 August 2020 (UTC)[reply]
    Um... people do get bitten over MOS issues. Blueboar (talk) 19:40, 8 August 2020 (UTC)[reply]
    Yes, and I don't think this proposal would exacerbate that issue as has been suggested. CMD (talk) 16:58, 9 August 2020 (UTC)[reply]
  • Opposed. This is yet another proposal that has the potential to discourage productive contributors in the name of consistency and uniformity. We may end up with a limited number of editors trying to control but failing to grow and maintain the entire Wikipedia. With fewer editors watching articles, we could easily be overwhelmed with vandalism. --Robert.Allen (talk) 19:29, 8 August 2020 (UTC)[reply]
  • Strong oppose. Parenthetical cites are an excellent style when used with explanatory footnotes. While it is possible to mix explanatory footnotes with citation footnotes, it's much cleaner to have citations and explanations clearly distinct.
    That means parenthetical cites are especially good for highly technical articles, where explanatory footnotes are most likely to be useful. We shouldn't try to shoehorn all articles into a single style, when topic-based considerations can favor one or the other. --Trovatore (talk) 19:39, 8 August 2020 (UTC)[reply]
  • Support second option (i.e. "editors can replace this unless there is a specific consensus against doing so"). Looking at actuary: yuck. It's awful. Unequivocally. The fact that it's still allowed to exist as an FA in 2020 is a prime example of how Wikipedia is often overly resistant to change.
To get a little more specific, I'm not persuaded that there's anything better about parenthetical citations for readers, even (as argued above) for humanities subjects where the author is more important—Aza24 dispatched that argument. And Markworthen's point about them allowing lazier citing that introduces ambiguity is also compelling.
Regarding beginner-friendliness (which I do think is of critical importance, as anyone familiar with my editing work knows), Wug's points persuade me enough not to support the third option, although only barely. It's important to note that there is some additional confusion that is introduced for beginners by not having a single unified citation style, and editor effort spent improving documentation for parenthetical citations is effort that would be better directed toward Citation Style 1 documentation. But on balance, I do think it's a little easier to just tell them they can cite however they want. That's just not a compelling enough justification to outweigh all the other considerations, though. Regarding WP:BITE, no one should be having an article declined at AfC or deleted at AfD because it uses different citation style, since AfC is supposed to be solely about whether an article would survive at AfD, and at AfD WP:Deletion is not cleanup. And I just don't see someone being outraged because the article they wrote had parenthetical citations converted into footnotes. The best solution for not biting newcomers is for experienced editors to not bite newcomers.
Regarding importing, under the second option, that would still be permitted, since something is better than nothing. The point here is to formally acknowledge that parenthetical citations are inferior, not to mass-delete everything that contains them.[hyperbole] The second option will appropriately set the groundwork for us to later, once our main citation tools have been further improved, apply a stronger form of deprecation.
Lastly, to those arguing that this flies in the face of WP:CITEVAR, I find that utterly unpersuasive. There is nothing sacred about guidelines established a decade ago, since WP:Consensus can change. And in this case, it should. {{u|Sdkb}} talk 19:50, 8 August 2020 (UTC)[reply]
  • Weakly support, to the extent that we should discourage the style in favor of inline refs: it's too wordy, doesn't indicate page numbers, etc., and in an FA or GA discussion I'd support asking or even requiring the authors to move away from it. However, per User:DGG's and others' points, we have much, much more trouble with articles without any citations at all, and even a poor style of citation is several orders of magnitude better than none at all, we do not want to have any conflicts over such a trivial thing, an risk discouraging an otherwise productive new or moderately new editor who is using this style, we want to applaud that they are using any citations at all. --GRuban (talk) 21:11, 8 August 2020 (UTC)[reply]
    @GRuban: You state it's too wordy - Author, year and page: how is this more wordy than any other style? Also, you claim doesn't indicate page numbers - of course it can. See WP:PAREN#Inline citation in the body of the article, sixth bullet; WP:PAREN#Page numbers; and WP:REFPAGE#Parenthetical referencing. --Redrose64 🌹 (talk) 14:38, 9 August 2020 (UTC)[reply]
    @Redrose64: Because it's inline. Captain Eek's example from Actuary at the top of this proposal is an excellent example: half the content is dedicated to the citations, which is distracting to the reader who's trying to just read, rather than verify. We do need to provide verifications, but our primary goal is to provide actual readable content, right? Standard inline ref style would have been seven small superscript numbers that would be easier be read over. Also, inline parenthetical citations need to be repeated every time they're used, so it's a name and a year in parentheses every time - or, if it's actually as you write, then a name, a year, a colon, and a page number, in parentheses every time, even longer! Again, as I wrote, this is secondary to having citations at all, but doing so less verbosely in the main content of our article and saving all the details to the end is just more legible. --GRuban (talk) 14:53, 9 August 2020 (UTC)[reply]
  • Support for "preferred-but-not-required" approach. If a subject is notable, we shouldn’t be giving newbies grief at AfC about formatting and such, and I wouldn't want this adding to it. Also Wugapodes makes a good point about the copy-paste use case.
    I'd like us to say that an editor is free to upgrade plain-text citations to any kind of linked <ref> footnotes (including sfn, list-defined refs, etc.) without needing to consult each time, unless there's a local consensus against it. Currently CITEVAR's defer to the style used by the first major contributor means first writer wins. That could change. And "upgrade" could be a good way to express it.
    It's not just readability, software supported references give the reader extra conveniences, like mw:Reference Tooltips; plus others have mentioned programmatic detection of references.
    If you have a need to mention the author and year in-text, and don’t want a "circumlocution" like In 2020, Pelagic et al. found that..., then I would go as far as to recommend a construct like Pelagic et al. (2020) found that ...[1] – i.e. provide a clickable ref in addition to the "author (year)". For an article where the refs are already alphabetical order (or some other order like date), you can retain that via list-defined refs.
    – Pelagic ( messages · Z ) – (18:48 Sun 09, AEST) 08:48, 9 August 2020 (UTC)[reply]
    Pelagic wrote: For an article where the refs are already alphabetical order (or some other order like date), you can retain that via list-defined refs. Is this true? I have never seen list-defined references display a reference list (in the final rendered HTML) in any other order but the sequence of citation in the text. List-defined references can be in arbitrary order in the reference list markup, but I don't know how to make the reference list display in alphabetical order (or some other order like date) in the final rendered HTML, so I have always used author-date referencing for that purpose. Biogeographist (talk) 13:20, 9 August 2020 (UTC)[reply]
    Apologies, @Biogeographist, you’re right. I was thinking of a situation where another editor re-ordered list-defined ref's in an article I was working on, but that’s because they wanted them alphabetised in the source code not the rendered result. I’ve struck out my mistake above.
    So, to produce an alphabetic output list, are we left with shortened footnotes, using {{sfn}} and {{refbegin}}, as the only alternative to naked parenthetical style? That produces nice results where there are many cited pages in a few books, but could it be clunky otherwise?
    It would be interesting to have a feature where the reader could sort the more common reflist-style by author, date, or order of occurrence as it suits them (similar to how tables are sortable).
    – Pelagic ( messages ) – (07:38 Wed 12, AEST) 21:38, 11 August 2020 (UTC)[reply]
  • Support any kind of standardization that contributes to a consistent reading experience across articles. ~ ToBeFree (talk) 13:54, 9 August 2020 (UTC)[reply]
  • Support, Actuary is a perfect example of what's wrong with this style. Readers expect to see the traditional blue number following a statement in a Wikipedia article. Inline parenthetical citations clutter the article, and because they are not commonly used, established editors won't necessarily know how to add citations. The beauty of the footnote system is that all you need to do is insert a <ref> tag with a {{cite}} template, and it formats itself. Most editors are not as familiar with {{harvnb}} and the like, and as a result, I am inclined to think that allowing parenthetical inline citations will discourage other editors from contributing to the article. As others have already stated, this isn't a reason to decline such articles at AFC, but it's time we start standardizing our citation style, and deprecating PIC's is a good place to start. --PuzzledvegetableIs it teatime already? 13:58, 9 August 2020 (UTC)[reply]
    Comment No, it's not a "perfect example" of what's wrong with this style. As I've pointed out several times already, the "problems" there can be dealt with using normal editing, without any need to ditch parenthetical referencing. --NSH001 (talk) 08:51, 30 August 2020 (UTC)[reply]
  • Comment Owing to contuied concerns, I have added a single word the the original proposal text: "inline", which is what I intended and explained originally. I apologise for any confusion, as I did not even realize that folks called sfn/harv referencing styles parenthetical :) CaptainEek Edits Ho Cap'n!⚓ 19:16, 9 August 2020 (UTC)[reply]
    @CaptainEek: But that's precisely what is causing confusion: you write folks called sfn/harv referencing styles parenthetical as if {{sfn}} and {{harv}} do similar jobs - they don't.
    {{sfn}} is essentially {{harvnb}} wrapped in <ref>...</ref> - it makes a little [1], and in the ref displayed later in the page there are no parentheses (the letters "nb" stand for "no brackets").
    {{harv}} is essentially {{harvnb}} wrapped in parentheses, but there is no little [1] or similar.
    So whilst {{harvnb}} is common to both, the end result is very different. It's like the Coventry Climax FW engine - you could find that in such diverse machines as fire pumps, forklift trucks and racing cars, but nobody would claim that these were the same as each other. --Redrose64 🌹 (talk) 22:17, 9 August 2020 (UTC)[reply]
    As I said in my first amending comment: I am okay with sfn. I am not okay with harv on its own. Harv templates need to be in ref tags, so that they make a little blue number. CaptainEek Edits Ho Cap'n!⚓ 22:20, 9 August 2020 (UTC)[reply]
    Again you're mixing them up. The {{harv}} template is not intended for placing inside <ref>...</ref> tags, it is used standalone. If you want to put something related to {{harv}} inside <ref>...</ref>, you should use {{harvnb}} or {{harvcolnb}}. --Redrose64 🌹 (talk) 23:08, 9 August 2020 (UTC)[reply]
  • Support. Agreed that the parenthical style leads to clutter, and we should aim to present are articles neatly. With that said, DGG (who opposes) makes a very fair point that the wiki markup for inline citations is novel to most new users, and we should not be rejecting articles just because they use the wrong style of citation. What I think deprecation should mean is that an article with parenthical style can be changed to a preferred style by any editor, and newbie editors who use it should be encouraged, in a way that doesn't bite, to use the preferred styles. Sjakkalle (Check!) 19:35, 9 August 2020 (UTC)[reply]
  • Oppose formally "deprecating". I support the general principle of saying that footnotes are preferred, and encouraging people to move away from simple parenthetical citations, but to me "deprecating" seems to be a step beyond that, and inevitably will lead to conflict over citation styles. Andrew Gray (talk) 20:05, 9 August 2020 (UTC)[reply]
  • Oppose. Per most of the opposes above, particularly Wugapodes. The benefits to the reader seem minor; in fact readers used to scientific articles may well prefer the parenthetical form. The annoyance to editors who prefer parenthetical references is likely to be real. If this form of citation is dying out, let it die of its own accord; if it's not, it's because some editors like it. On a procedural note, I think anything that can be seen as chipping away at CITEVAR should be advertised as widely as possible; where have notices been left so far? Mike Christie (talk - contribs - library) 20:39, 9 August 2020 (UTC)[reply]
    Mike Christie, This is currently on the centralized discussion template, which is about as visible as it gets. I also left notes on some of the MOS project pages to advertise it. I believe another user also spread it to some of the WikiProjects. CaptainEek Edits Ho Cap'n!⚓ 22:40, 9 August 2020 (UTC)[reply]
    CaptainEek: I think a watchlist notice would be justified; if you've no objections I can request it or you can. I'll mention it at WT:FAC, which is read by a lot of content writers who may not watch other forums. Mike Christie (talk - contribs - library) 00:11, 10 August 2020 (UTC)[reply]
    Mike Christie I think a watchlist notice is probably overkill, I can't recall the last time a policy RfC was a notice like that. But I have no objections to posting it at WT:FAC. CaptainEek Edits Ho Cap'n!⚓ 00:14, 10 August 2020 (UTC)[reply]
    I agree with Mike C. The more visibility, the better. This is one of those matters that anyone will be angry that they missed saying their piece. Especially if she/he is on the losing side. -- llywrch (talk) 21:38, 10 August 2020 (UTC)[reply]
    I might as well repeat what I've said elsewhere (I see others making similar points far above): "The rfc "question" is extremely unclearly worded, and has already been messed about with twice at least while the rfc was running, including a far-from-minor bolt-on. As a result, "supports" and "opposes" often appear to be talking about different views, and different bits. I don't see how any policy-changing conclusion can really be drawn from what is currently a fairly finely balance tally of votes - for different things. There would have to be another stage to discuss properly-drafted proposals, and vote on a range of options. It might be too soon to raise the fyrd at this point." Johnbod (talk) 21:50, 10 August 2020 (UTC)[reply]
  • Support deprecation, which I expect will be akin to making CITEVAR not apply anymore where a style using inline parenthetical citations are used (and I get the gist most above have come to that as the preferred state). I think most above have made it obvious why. I might be persuaded the occasional "Name et al did this thing (date/year).<ref/>" or "Name et al (date/year) did this thing.<ref/>" is reasonably short, but I don't think that will be necessary in the general case.

    As for the concerns for biting, I think the statement in WP:CITE's lead is already sufficient (and if you see BITING, call out the user): While you should try to write citations correctly, what matters most is that you provide enough information to identify the source. Others will improve the formatting if needed.

    As for suppositions about comfort, I hated parenthetical referencing from the minute I started being asked to supply citations in high school, and the style I grew up with was MLA. Which was predominantly parenthetical. :) Let's move on from the paper way of doing things. --Izno (talk) 23:19, 9 August 2020 (UTC)[reply]

  • Support. I'm very glad someone made this proposal, and still cannot believe people in 2006 thought it was a good idea to allow this kind of citation for a website aimed at the general public. Best way to confuse the casual reader. T8612 (talk) 00:49, 10 August 2020 (UTC)[reply]
  • Support encouraging use of <ref> and allowing conversion of in-prose parenthetical references like "(Smith 2020)" or "Smith (2020)" to use <ref> in some manner without the need for additional consensus on each individual article. Articles should not be deleted or rejected from AFC for using parenthetical style instead of <ref>, at most they might be tagged for cleanup if not just converted. For that matter, I'd also like {{rp}} to be deprecated in the same manner, even {{sfn}} is better than that mess. Anomie⚔ 00:58, 10 August 2020 (UTC)[reply]
  • Strongly Support. Would also support deprecation IRL. GPinkerton (talk) 01:35, 10 August 2020 (UTC)[reply]
  • Oppose per CITEVAR --Guerillero | Parlez Moi 02:10, 10 August 2020 (UTC)[reply]
  • Support – I use such references in real life on a daily basis, but they are not suited for Wikipedia. Given that we have technology available to minimise the disruption that such citations cause to the text, I think we should do so. I've been very happy to use the Harvard referencing templates. While others here seem to imply that this would discourage newcomers, on the contrary, WikiGnomes will come along and fix such things for them, ideally teaching them how to do it themselves! This is how most of this work gets done on Wikipedia, and there's no reason why it can't happen here. RGloucester — ☎ 13:44, 10 August 2020 (UTC)[reply]
  • Oppose - this appears to be an attempt to abolish CITEVAR and forcing everybody to use the "one true" referencing system, as can be seen by User Anomie's comments, where they admit that their aim is to ban all short form referencing styles other than some mysterious "Book Referencing system which doesn't even exist yet - it seems designed to drive away editors in droves - and despite what the proposers say, this will undoubtly be used to bite content creators - just as the fact that the cite xx templates are supported by editing tools is used by ediotrs to force use of these templates, with frequent claims that they are "official".Nigel Ish (talk) 16:29, 10 August 2020 (UTC)[reply]
    You're assuming a lot of bad faith here. T8612 (talk) 19:26, 10 August 2020 (UTC)[reply]
  • Support a move away from parenthetical citations (per Alsee). I think that Wugapodes' concerns are worth considering in the sense that as things get more codified over time, people get more concerned about enforcing "the rules" (consider how much blood has been shed over MOS disputes), but on the flip side something like Trio sonata is a humongous mess. bibliomaniac15 19:13, 10 August 2020 (UTC)[reply]
    Not a comparison worth drawing. People get battlegroundy over MoS stuff for the specific reason that all fluent and even wannabe-fluent users of a language have an innate sense of mastery of the language and of what is "right" and "wrong" in it (i.e., what they were taught), even though those absolutist and prescriptivist feelings are objectively and linguistically nonsensical for the most part. Writing style is mostly arbitrary and subjective, and the main reasons we (like all other major publishers) have a house style on all those writing nit-picks is to present a fairly uniform reading experience, and to put to bed various tedious "style wars" that turn recurrent and circular. By contrast, no one is under a psychological illusion that one citation style is innately Right and another one an error. Everyone who even knows what a citation is knows that they come in different formats. Everyone of around high-school or higher education has already learned that they have to format citations differently for different classes, and everyone who publishes papers or other material professionally is entirely used to having to format citations to suit particular journals or other publishers (or to have the editors make that change for them). So, likening MoS squabbles to CITEVAR squabbles is a false analogy. They're only similar in that people get grouchy about it, and the word "style" is involved.  — SMcCandlish ☏ ¢ 😼  02:23, 11 August 2020 (UTC)[reply]
    That is entirely reasonable, and I have no objections to that. But I also find it impossible to underestimate the singular ability of Wikipedians to debate about petty stuff... bibliomaniac15 02:43, 1 September 2020 (UTC)[reply]
  • Support I've suggested even mild versions of this before and gotten shot down, but it's the basic bare minimum of enforcing useful standards for our readers and editors. I don't find the concerns that it's going to materially affect contributions, since those people weren't reading our style guides to begin with. Der Wohltemperierte Fuchs talk 20:55, 10 August 2020 (UTC)[reply]
    I dislike parenthetical citations too, but the point of CITEVAR is to let editors who work on an article use what they like, not necessarily what others like. First they came for parenthetical citations, and I supported the RfC, because I don't use parenthetical citations... Mike Christie (talk - contribs - library) 21:23, 10 August 2020 (UTC)[reply]
    Godwin's law. Please, for the love of [anything you swear by], do not again trivialize the Holocaust to engage in false-equivalence analogies and slippery-slope fallacies about citation formatting trivia. That's just so wrong in so many ways. If there were an actual slippery slope here, the end result of it would be just an entirely consistent citation style, which would actually be easier on everyone, from readers to editors. In what possible reality tunnel is that comparable to state-organized mass-murder of millions? FFS. If you didn't know the source of the phrase, I could let it slide, but you linked right to it and know exactly what you're doing.  — SMcCandlish ☏ ¢ 😼  02:23, 11 August 2020 (UTC)[reply]
    Struck, since if you find it offensive no doubt others will too. I meant only to pick up the theme of escalation, not any of the other connotations. And shorn of the offensive metaphor I still think that’s the case. Mike Christie (talk - contribs - library) 02:45, 11 August 2020 (UTC)[reply]
  • Support - yes, time we used a form of referencing that suits an online encyclopedia. Parenthetical references have always been a carry-forward from some academic traditions rather than something which suits Wikipedia or its readers. That's not to say contributions with parenthetical references should be rejected, but we should establish the ref tags and templates as the preferred method of providing reference information. The Land (talk) 22:02, 10 August 2020 (UTC)[reply]
  • Support for most of the reasons already given. In short, we should – like pretty much every other publisher on the planet – move toward a consistent in-house citation style. Even if we preserve various forms of field-specific divergence, we do not need to have every imaginable citation style running around on here, especially ones that only make sense in a paper context, like inline parentheticals. See also WP:NOT#JOURNAL. Mimicking old paper journal style is just annoying clutter for our readers, who are not academics and do not need things like "(Johnson 2005 pp. 345–352)" thrust in their face every sentence or so, when [7] will do just fine.  — SMcCandlish ☏ ¢ 😼  02:23, 11 August 2020 (UTC)[reply]
  • Strong support. One of the biggest turn-offs for newbies. It almost certainly contributes to our high departure rate, and inhibits account creation by anons. It's a bore for established editors, too. Tony (talk) 02:46, 11 August 2020 (UTC)[reply]
    @Tony1: What is your evidence for your claim that parenthetical citations is one of the biggest turn-offs for newbies, or that it almost certainly contributes to our high departure rate? Surely, it's much more of a turn-off for them - or even a reason to quit - when their content additions are frequently reverted on the grounds of being unsourced (even considering valid WP:BLP reverts). I've never once come across a newbie - or indeed an oldie - who has remarked something like "I've just found an article that uses parenthetical citations, and I can't work out how to do it, therefore I'm outta here." There are plenty who have quit because we won't let them create a page about the band they just formed in Bob's dad's garage.
    I'm even more at a loss to see how parenthetical citations inhibits account creation by anons - I completely fail to see the connection. --Redrose64 🌹 (talk) 11:27, 11 August 2020 (UTC)[reply]
    No, it is unlikely to be a turn-off for newbies, when it isn't that common. I can easily suggest a much more likely candidate. Suppose you're a newbie and you open a page in edit in edit mode, and you see this heap of incomprehensible and unreadable crap (taken from a page I happend to be looking at just before I first saw your post):
    During the war, Israel also damaged hospitals,<ref name=Haaretz-empty-Al-Wafa>{{cite web|last1=Cohen|first1=Gili; Hass,Amira; Khoury,Jack|title=Israel bombs empty Gaza hospital, calling it Hamas command center|url=http://www.haaretz.com/news/diplomacy-defense/.premium-1.606912|website=haaretz.com|publisher=Haaretz Daily Newspaper Ltd.|accessdate=12 August 2014}}</ref> alleging they were concealing "hidden missiles".<ref name="washpost-hospitals">[http://www.washingtonpost.com/blogs/worldviews/wp/2014/07/22/in-the-fight-between-israel-and-hamas-gazas-hospitals-are-in-the-middle] "Gaza's hospitals in the middle between Israel and Hamas", ''washingtonpost.com''; accessed 23 July 2014.</ref> A Finnish reporter team from [[Helsingin Sanomat]] life at the Gaza [[Al-Shifa hospital]] reported seeing rockets fired from near the Al-Shifa hospital.<ref>{{cite web|title=Reporter for Helsingin Sanomat confirms longstanding Israeli claims that Hamas missiles launched from the Shifa compound|url=http://www.timesofisrael.com/finnish-tv-rockets-fired-from-gaza-hospital/}}</ref><ref>[http://www.ynetnews.com/articles/0,7340,L-4553643,00.html] "VIDEO: Finnish reporter sees rockets fired from Gaza hospital", [[ynet]], 2 August 2014.</ref> However, two Norwegian doctors who have been working at the hospital for decades have denied there was militant presence nearby, saying the last armed man they saw by the building was an Israeli doctor at the time of the [[First Intifada]].<ref>{{cite news|url=http://www.haaretz.com/weekend/twilight-zone/.premium-1.608239|title='Israel has stolen Gaza's future, and its hope'|date=2 August 2014|publisher=Haaretz}}</ref> The Washington Post described Al-Shifa hospital as a "de facto headquarters for Hamas leaders, who can be seen in the hallways and offices."<ref>https://www.washingtonpost.com/world/middle_east/while-israel-held-its-fire-the-militant-group-hamas-did-not/2014/07/15/116fd3d7-3c0f-4413-94a9-2ab16af1445d_story.html</ref> Nick Casey of the [[Wall Street Journal]] tweeted a photo of a Hamas official using Al-Shifa hospital for media interviews, but later deleted the tweet.<ref>http://www.jpost.com/Operation-Protective-Edge/Gaza-reporters-tweets-Hamas-using-human-shields-368689#</ref> French-Palestinian journalist Radjaa Abu Dagg reported being interrogated by an armed Hamas member inside Al-Shifa hospital and ordered to leave Gaza.<ref>http://www.tabletmag.com/scroll/180730/top-secret-hamas-command-bunker-in-gaza-revealed</ref><ref>http://actualite-israel.com/les-menaces-du-hamas-sur-un-journaliste-tu-dois-quitter-gaza-au-p-410595/</ref><ref>http://www.algemeiner.com/2014/07/24/french-journalist-describes-interrogation-at-hamas-headquarters-next-to-emergency-room-at-gazas-al-shifa-hospital/</ref>
I doubt that more than one person in a thousand will want to edit Wikipedia after looking at that dungheap. How's that for "clutter"? --NSH001 (talk) 13:28, 18 August 2020 (UTC)[reply]
@NSH001: Your argument falls apart when you consider that new users are more likely to use the visual editor anyway. Noahfgodard (talk) 21:40, 29 August 2020 (UTC)[reply]
  • @NSH001: That's why I like list-defined references. But they do have the down-side that you need two separate section-edits to add text and reference. Pelagic ( messages ) – (17:27 Thu 20, AEST) 07:27, 20 August 2020 (UTC)[reply]
    Indeed so. There are four different ways of gettting rid of dungheaps, and list-defined references is one of them. Each method has both advantages and disadvantages. I have written a tool (the ETVP script) which offers the choice of all four. You can see examples of its use at User:NSH001/ETVP/examples. But bear in mind that the ETVP script is private, so that only I can use it, although it might eventually become publicly available. --NSH001 (talk) 09:39, 20 August 2020 (UTC)[reply]
  • Oppose Firstly, a pragmatic reason - adding citations from British History Online is cumbersome without bare formatted citations, because they are not provided in a Wikipedia compatible template so can't just be cut and pasted in. So unless a gnome is prepared to follow people and fix these up, I don't think it's practical. The second reason is, I believe this has the opportunity to make Wikipedia:Arbitration/Requests/Case/Civility in infobox discussions look like a vicarage tea party (at least if threads like these are anything to go by). Please, let's focus on making the encyclopedia better for the readers and not arising mighty conflicts from trivial things. Ritchie333 (talk) (cont) 09:32, 11 August 2020 (UTC)[reply]
  • Oppose My mind was blown at the realisation Wikipedia doesn't even have a single standard citation format. Until such time as it does, it would seem cruel and unusual to start signling out individual forms as if they were somehow inferior, but the rest are cool beans, just use whatever you want, mix it up even. And besides, does Wikipedia ready need to be telling people who are used to using this particular format as part of their everyday writing, to get the hell out of here with their stupidness? Jenga Fet (talk) 19:41, 11 August 2020 (UTC)[reply]
  • Oppose. I suppose it is what I am used to from my academic background, but I like to read in the text who has written the reference and when, rather than have to move the cursor to find out. Secondly, it is often necessary to say what was written in a particular article. It looks much neater to write "Smith (1999) argued this", than "5 argued this". Having said that, I mostly do write using Wikipedia's common referencing style: but I want to retain the choice not to. Jmchutchinson (talk) 19:46, 11 August 2020 (UTC)[reply]
    "Smith argued this5". CMD (talk) 04:11, 12 August 2020 (UTC)[reply]
  • Support strong deprecation of this seldom used style that's at odds with how most editors work. In my academic papers I do use inline bracketed author/year style when I can, but for an encyclopedia it's really just a disruption to the reader, and in this case also to us writers who have to work on such articles. Dicklyon (talk) 00:37, 12 August 2020 (UTC)[reply]
  • SUPPORT I would suggest that this proposal is the opposite of CREEP as simplifying things such as referencing isn't a bad thing. Remember the K.I.S.S. principle is more helpful than hindrance to the newbies. Regards, GenQuest "Talk to Me" 03:01, 12 August 2020 (UTC)[reply]
    Very odd arguments. Parenthetical refs are extremely simple to do, above all for those not used to mark-up or templates. It's the reader who suffers from them. In practice they are these days almost exclusively used by newbies, who may well just leave their stuff unreferenced if told not to use them. Johnbod (talk) 04:08, 12 August 2020 (UTC)[reply]
  • Oppose First of all, this proposal is not well thought out. It does not make clear just which styles it is prohibiting. Secondly, I do not agree that all parenthetical styles get in the way for a reader, and of the ones that do, the sfn system, where a little blue number links to a parenthetical, which in turn links to a bibliography entry is in my view more confusing and harder to read (not just writer) than the form where an in-line parentheticl links directly to a bibliography entry. There are advantages to a bibliography orderd by author, or in some cases to one by date, particularly when sources cover a wide rangem of time. There is an advantage to the reader knowing witjhout following anything just who said what and when in some topics, as is pointed out above. But most of all, I think this weakening or abolition of WP:CITEVAR would set of a huge round of edit-warring. If we are going to start deprecating unusual citation formats, how about the much harder for non-specialist readers style of Bluebook, which some editors insist on in legal topics? How about mandating the use of citation templates, or at least the use of <ref>...</ref> tags? I'd actually love mandating list-defined references, but not many would agree. I can see a general statement that styles that use ref tags are favored. I'd like to add a statement favoring the use of citation templates. But we have enough trouble getting new editors to move beyond bare URLs. I think this will have little gain, adn the potential for major problems and a major time sink. DES (talk)DESiegel Contribs 15:59, 12 August 2020 (UTC)[reply]
  • Support no downside as far as I can see to preferring footnotes. The inline (Smith 2008) citations are in 99% of cases excessively distracting and actively work to prevent verifiability (page numbers); also per BD2412's point. (t · c) buidhe 21:42, 12 August 2020 (UTC)[reply]
    Whether any given citation will have page numbers or not is independed of the citation style. Every style allows you to have page numbers, and it's editor choice whether to supply them or not in each instance. – Uanfala (talk) 19:21, 17 August 2020 (UTC)[reply]
  • Support ... to an extent. I tried to read all the above comments and I'm glad I did – because some very good opposing points were made (eg, by Wugapodes) which I wouldn't have considered at all. But after a couple of editors mentioned the Actuary article, I just had to follow the link there, and it really looks terrible. The inline parenthetical citations do no one any favours; it's a very poor visual presentation, and yet so easily avoided. I'd like to see them strongly discouraged here, if nothing else. As for considering new users, which is important, I think they should be advised to place all references (however they've chosen to word the content) within ref tags. I agree with the sentiment expressed above that adding these tags shouldn't present too much of a challenge for anyone. In academia and in general reference works, inline parenthetical citations are still widely used, yes, but I've found when writing articles here on 1960s popular music and society that titles by university presses in Oxford, Cambridge, Harvard, Chicago and the like will revert to footnote or endnote citations for books aimed at a more general readership. It seems to me we should follow that approach, because of the broad readership that Wikipedia attracts and to ensure information is presented on the page without unnecessary distractions.
I don't support advocating the use of only a "software-supported footnote system" instead (if I've understood the term correctly – it doesn't seem to me that WhatamIdoing got a clear answer above when asking for some clarification). Nor the idea that we should be looking to move towards a single citation method, as has been suggested also. If "software-supported" means cite 1/2 templates, then no, definitely not. I think the less control that is placed with a chosen few cite-template editors – with regard to options allowed within certain parameters and therefore how details are rendered on the page – the better. JG66 (talk) 12:05, 13 August 2020 (UTC)[reply]
  • Support I don't come across this style very often here and looking at a few of the mentioned articles above I can see why. They are an eyesore that results in a sea of blue and inhibit the flow of the article. Some sentences are more reference than actual words. We have a standard style in as much as the vast majority of our articles use the little ref numbers and we are big enough and have been around long enough that this is the expected style for most users and readers. It should be encouraged to the point where changing any inline refs to numbers is not controversial, but the refs should not be outright deleted, converted to a completely different style or used as a bludgeon on newbies that might use it because that is the only style they know. Much like we wikify well meanong, but poorly formed articles at the moment. AIRcorn (talk) 23:02, 13 August 2020 (UTC)[reply]
  • Oppose. I don't like this style, but that's no reason to tell people to stop using it. And, eventually, someone is going to use this RFC as a justification to come after a citation style that I do like. NinjaRobotPirate (talk) 15:31, 14 August 2020 (UTC)[reply]
  • Strong oppose per DGG, David Eppstein and others. We need to make adding references as easy as possible. Issues of consistency and style are tertiary at best. Paul August ☎ 15:55, 15 August 2020 (UTC)[reply]
  • Support in the sense that this gives others the prerogative to convert parenthetical to footnote. Obviously parenthetical is better than nothing at all. But footnotes are better for readers and they have organically become our house style. Nothing about this makes references harder to add, as others have said. If some prefer doing parentheticals, gnomes will pass by and switch them over. Calliopejen1 (talk) 00:14, 16 August 2020 (UTC)[reply]
  • Comment. I have posted a request for a watchlist notice for this RfC here; please comment there if you have an opinion. Mike Christie (talk - contribs - library) 19:19, 16 August 2020 (UTC)[reply]
  • Strongly oppose deprecation of any citation style. Much as I loathe certain styles, WP:CITEVAR is as much a bulwark against divisive and ultimately pointless edit-warring as WP:ENGVAR and WP:ERA. Our core policies include WP:V, but they do not include WP:MOS; consistency of appearance within an article is desirable, between articles is a minor matter or even counter-productive, since some readers' preferences and fields' conventions will inevitably not be represented after non-conforming pages are changed to conform. Encouraging people to provide citations, and further encouraging them to go beyond bare links and in-line links on text in doing so, is a high priority and this would discourage some, in-line references are doing no harm, and I would rather have the gnomes perform useful tasks; there's already far too much tinkering with citation formats using AWB. Yngvadottir (talk) 23:43, 16 August 2020 (UTC)[reply]
  • Oppose complete deprecation wihout prejudice against preffering other styles in the vast majority of cases per those above. — Godsy (TALKCONT) 13:12, 17 August 2020 (UTC)[reply]
  • Support We no longer need to tolerate other styles. The sorts of editors some of you think will come to Wikipedia with parenthetical references either don't exist or can learn another way. Chris Troutman (talk) 13:46, 17 August 2020 (UTC)[reply]
  • Strong support It is both confusing and hypocritical to enforce WP:MOS to gain uniformity of appearance in every other aspect of or appearance except referencing. Good quality, standardised presentation of information is essential, and references are one of the most important elements of our pages. Yet our guidance on how to do it has been woefully inadequate for years, and we have allowed multiple approaches to referencing, which I doubt no publisher or journal would countenance. And I say this as an author of books and papers who has used parenthetical referencing in print.
Just read through the lead of Actuary to appreciate how laughable it is to have this awkward and glaringly different style to reference presentation within a Wikipedia article, and then consider that Feature Article candidates have to fuss over whether em- or en-dashes are used correctly, and innumerable other minutiae. Our non-standard approach to encouraging one form of referencing seems akin to the The Emperor's New Clothes. We can all see there's an issue, but we've gone along for so long believing having multiple standards is OK that it has become ingrained, and we refuse to see there's a problem. Rather than worry about putting off academic contributors who are, by definition, relatively clever individuals who are capable of adapting, we should worry about ensuring all other new editors are encouraged to use one style for inline citations and be willing to see articles actively converted to that preferred house style for referencing, just as we do for everything else here.
The argument for keeping inline parenthetical citations on Wikipedia because social scientists and others prefer it is akin to me, as a naturalist, demanding that we allow capital letters for common names of plants and animals in all articles directly about a species because that's how naturalists prefer to see them written, because it avoids confusion. Wikipedia agreed one approach on that, and we should stick to it; we should now accept the blindingly obvious, and start cleaning up the multiple approaches we have too long tolerated and encouraged for referencing. Nick Moyes (talk) 23:36, 17 August 2020 (UTC)[reply]
  • Support. The obvious benefits far outweigh the (mostly theoretical) costs. Yilloslime (talk) 03:27, 18 August 2020 (UTC)[reply]
  • Very strong oppose. In my opinion, this proposal is a non-starter and should never be allowed to pass.
    The proposer mentions the Actuary article. Since I am an actuary myself (but long retired) this article has been on my watchlist from almost the day I joined Wikipedia in 2006. The article was written by the excellent User:Avraham ("Avi" for short) – another actuary - one of Wikipedia's best admins and bureaucrats, widely respected for his consistent hard work, integrity, sound judgement, and scrupulous adherence to Wikipedia's policies. Sadly he's not very active on Wikipedia at the moment, but it would be good to see him back and contributing to this discussion.
    Anyway, the citation style on Actuary has never bothered me. It's not my preferred style, but there is nothing wrong with it. If the "clutter" bothers people that much, there are a few simple changes that I've mentioned on Talk:Actuary to deal with it such as reducing the number of citations in the lead (per policy, a lead without any citations at all is perfectly fine if the material is sourced elsewhere in the article) and, as far as possible, keeping citations to the end of sentences.
    No, the "problem" (if it is a problem, which I don't think it is) is not the citation style but the particular arrangement of citations on that article, easily fixed. It is also worth noting that this is a Featured Article, and if the citation style really were a problem, it would have been dealt with by FA reviewers by now. I quote from what I wrote on talk:Actuary,

    Firstly, I remain unconvinced by the "complaints" argument. Rather, they appear to me as people saying, "I haven't seen this before, therefore I don't like it". Like anything new, it is possible to get used to it, and maybe eventually appreciate its advantages

    It just so happens that recently I have been doing more editing on mathematics articles. There are good reasons for not using superscripted citations in mathematics articles. One of them is obvious: superscripts, when placed next to a mathematical expression, can easily be misinterpreted as part of the expression. (The same applies to chemistry formulae). But the objection goes much further than that.
    Take an article I happened to be working on quite recently: monster group, which is written using parenthetical referencing. Then think how you would change it to use superscripted referencing. Firstly, the job wouldn't be easy, and secondly the result would be worse, not better. The last thing we need is a policy change that would make (some) articles worse. And I say "No, thank you" to the endless, counter-productive, time-wasting edit-warring that would result.
    No, we should allow editors to use, at their discretion, whatever is the best citation style for a particular article. And if someone thinks the citation style on an individual article should be changed, we already have in place policies that work fine: WP:CITEVAR and WP:CITESTYLE.
    Now let's deal with some of the points raised by the proposer and others here.
    • The proposer opens by referring to an Arbcom case from 2006 that underpins the current WP:CITEVAR, opining that things have changed since then, and arguing from that that we should deprecate in-line parenthetical referencing. Now some things have indeed changed since then. The biggest issue, as I remember it from 2006, was whether or not manual citations should be converted to use citation templates. Some very well known and high-profile editors argued firmly against using citation templates. The result was a policy that Wikipedia neither encourages nor discourages the use of cite templates (I'm paraphrasing here). As far as I'm aware this policy still stands, de jure. But in practice every day I see editors busy converting manual citations into templates. (By the way, they do a very bad job of this, because the citation-generating tools they use are so bad.) Mostly, this policy is de facto ignored.
      Back in 2006, there was strong justification for avoiding cite templates. Because of technical limitations, the range of options they offered was inadequate, and they were computationally very inefficient (in plain English: very slow). An article citing about 400 sources using templates took around 5 minutes to load (I'm thinking of Gaza War (2008–2009)). Those editors favouring manual citations liked the detailed control they could have, which was not afforded by the then-available templates. Nowadays, thanks to some hard work by some brilliant technical people, these objections have mostly been met, and the new templates run several orders of magnitude faster than the old ones. So I personally strongly favour the use of templates, but nevertheless I still think, on principle, that editors should be allowed to use manual citations if they wish.
      The point I am (laboriously) coming to is this: Yes, things move on, which does make a difference on the question of cite templates. But there is no comparable change – or "moving on" – that makes any difference at all to the question of parenthetical referencing.
    • The main objection – that it "clutters" the text – is a matter of personal taste, not of principle. Once you get used to it, you begin to appreciate its advantages. On articles like monster group, the advantages over superscripted referencing are obvious. Parenthetical referencing reads naturally and easily there, much better than superscripted citations would do.
      Like short-form referencing and list-defined references, parenthetical referencing has the advantage of moving the clutter of huge citation templates out of the body of the article. It shares, with short-form referencing, the advantage of providing a nice, neat, alphabetically ordered bibliographic listing at the end of the article. On top of that, it has the advantage over short-form of dispensing completely with a "citations" section, and of requiring one less click to get there. Readers can also see, right there in the text, who has written the source, and when, complete with page number(s) if applicable. No need to carefully manoeuvre the mouse either to hover over the superscript or click on it to see what lies underneath.
      Coming back to Actuary again, such minor objections as exist can be dealt with by normal editing to the lead. Just read through the whole article again, please. Apart from the lead, it reads perfectly fine and easily. There is no need to ditch parenthetical referencing.
    • I haven't bothered to repeat the points made by Wugapodes, but I urge readers to go back and read them. Similarly for the excellent contributions made by users DGG, David Eppstein and Finnusertop.
  • This is a bad change on principle, for the same reason that I favour allowing editors to use manually formatted citations if they wish to, even though I am personally strongly in favour of using cite templates.
    This is a really, really bad proposal. Just think about the obvious stupidity of banning a perfectly fine citation style, that is indeed the best for some articles, just because someone might have put a few too many citations in the lead of one particular article. This proposal should be firmly buried where it belongs, six feet under, and permanently, with no hope of resurrection, please. --NSH001 (talk) 07:43, 18 August 2020 (UTC)[reply]
  • Support proposal. While I understand the wishes of editors to use the style they are most comfortable with, in a more wide view, that is counterproductive to the wiki. Readers going from one article to another and wishing to check the sources need to adjust to a new style. The inline style is much less reader friendly than the ref style that allows the reader to view the source without cluttering the text and without forcing them to scroll down the page, leaving the spot they were at. --Gonnym (talk) 08:36, 18 August 2020 (UTC)[reply]
    Err, parenthetical referencing doesn't "force" anyone to scroll down the page, nor leave the place they were at. Quite the opposite. --NSH001 (talk) 09:04, 18 August 2020 (UTC)P[reply]
    Please use my words in the context they were written - allows the reader to view the source [...] without forcing them to scroll down the page - you cannot view a complete source of "(Thomas 2012) without scrolling down the page. --Gonnym (talk) 09:38, 18 August 2020 (UTC)[reply]
    Yes you can, provided the page is using one of the {{harv}} family of templates. I suppose this is another example of the poorly expressed nature of the proposal, which mentions in-line text parenthetical citations, but then goes on to object about Actuary, whose parenthetical citations are entirely template based. --NSH001 (talk)
  • Support per proposal: parenthetical citations clutter the text and make reading more difficult. Having read all of the counter-arguments above, and checked all of the example pages, none of it persuades me that the benefits of keeping the style outweigh the disadvantages. MichaelMaggs (talk) 09:57, 18 August 2020 (UTC)[reply]
  • Oppose. First off, I don't see a need for such a new rule, as in-line parenthetical citations are already pretty rare, and in articles aimed at the most general readership they are almost non-existent. On the other hand, in some specialised articles (think for example of obscure topics in abstract algebra), they are likely to be as familiar to the readers as they are to the writers of those articles. And even when <ref>-formatted citations are used there would sometimes be a case where the fact of who wrote the cited text, or when they wrote it, is of encyclopedic relevance. Then a parenthetical citation is the most economic way to convey that fact; the alternative of using a footnote and then expanding the prose with the relevant information would actually add more clutter. And as pointed out by NSH001, on some topics (like mathematics), references in the form of superscript numbers have the potential to interfere with the content. Furthermore, as has been explained by Wugapodes, DGG, Finnusertop and others, banning this citation style will deter potential new editors that we do not want deterred, and enforcing the ban will drive away existing editors that we don't want driven away.
    Yes, in some cases (including articles aimed at a general audience, like Actuary), converting away from in-line parenthetical citations will lead to improved presentation. Instead of adopting a blanket ban, editors can instead consider attempting thoughtful conversions (like at the actuary article, but as pointed out by NSH001, even then it may not necessarily be the best solution). It also seems to me that the advantages for readability have been overstated in this discussion. Parenthetical references make it a lot easier for a reader to go back and forth between the text and the sources (especially in comparison with the {{sfn}} system where they have to always click through the footnotes). – Uanfala (talk) 14:43, 18 August 2020 (UTC)[reply]
    • Our articles are supposed to be "understandable to as many as possible" and "written in simple English language as non-experts can understand properly" (Stevertigo et al 2005). This is particularly important in specialized articles about obscure topics. We shouldn't be dividing the encyclopedia into "accessible" and "experts-only" sections. pburka (talk) 16:30, 1 September 2020 (UTC)[reply]
      • Well, our articles have to be accessible to the people will read them. I don't think we should try making articles accessible to people who will not read them. How, and why, would we try to make Enantioselective synthesis or M-estimator easily comprehensible by a completely lay audience? For a reader to end up looking up any of those topics in the first place they will need to have had some interest in and familiarity with the broader academic subjects. – Uanfala (talk) 19:15, 2 September 2020 (UTC)[reply]
  • Support. The nomination sums up quite well why this would be a good idea, with the key takeaway that it is reader experience that is all-important here, with editor experience a secondary consideration to that. And articles such as Actuary, with its awkward insertion of refs in and amongst the text, provide the perfect example of why that style should be deprecated. Of course, this does not mean that we reject anyone's submissions or go around deleting text, because they've only supplied cites in the inline format. It just means that the arcane rule prohibiting gnomes from converting such cites into the standard footnote format should be scrapped. As a final point, it was said above that the present permissive arrangements prevent disputes because editors can just do what they like, and changing the format is banned. I would argue the contrary - standardising on one format is what really gets rid of disputes, because once that format is established, there is no basis for ever again having to discuss which one should be used even where two regular editors on an article disagree. Cheers  — Amakuru (talk) 15:11, 18 August 2020 (UTC)[reply]
  • Support progressive deprecation. The plethora of citation styles exists to the detriment of visual consistency. I see no reason why parenthetical citations cannot easily be put within ref tags. If editors want to copy in some CC text for a new article, it wouldn't stop another editor who likes working on cites to come in afterwards and put them into the defined style. -- Ohc ¡digame! 08:38, 19 August 2020 (UTC)[reply]
  • Support For a host of reasons already mentioned. If there are really {potential} editors out there who find it an insurmountable technical challenge to write <ref>Bloggs 2003</ref> instead of (Bloggs 2003), they probably aren't going to last long here anyway. Chuntuk (talk) 10:59, 19 August 2020 (UTC)[reply]
  • Support formally preferring footnote-style citations, oppose formal deprecation of inline parenthetical citations. Support allowing / encouraging gnomes to convert inline parenthetical citations to footnotes without the requirement of adding content, provided the article is not in the process of being built out by an editor employing parenthetical citations. With respect to User:NSH001 and awareness of my own potential ignorance, the benefits of using parenthetical over footnote citations in monster group are anything but obvious to me. I would additionally assert that the blockquoted wikitext example from human shield in response to User:Tony1's support does not meaningfully impugn the edit-side readability of footnoted citations, as there is no guidance to editors either to define their named references in the text of the prose where they first occur, nor to do so without non-rendering whitespace in the template call parameters, although I will readily grant that most editors do in fact engage in both of those practices. I don't think there's any reason why we can't prefer footnoted citations and also ask editors to try to make their references legible enough that the article prose can still be understandable in the edit window without too much effort. <3 Folly Mox (talk) 20:48, 19 August 2020 (UTC)[reply]
    Tony1 made an assertion about what he thought drove editors away; I responded why I thought that was unlikely, and gave a much more likely explanation why newbies are driven away. There's a good reason I call it the dungheap citation style. I state on my talk page why it will drive me away if it can't be fixed. If it almost drives me away, an editor with 14+ years experience, just imagine what a newbie is going to think. I stay because I can still work on articles that are not in the dungheap style, and I have developed a tool (the ETVP script) I can use to get rid of dungheaps, although its use is restricted by WP:CITEVAR and WP:CITESTYLE (as it should be).
    My main point in replying to Tony was to correct his assertion about what drives potential editors away. I remain very strongly opposed to the proposal to deprecate a whole valid and useful citation style (in the process overturning long-standing policies that have been proven to work) – as I'm glad to see you do too. That doesn't mean I'm against footnotes, far from it (it's still possible to use footnotes without creating a dungheap). All the articles I've ever written have used footnotes. Authors should use whatever is the right style for the topic, and that might be parenthetical, list-defined references, or short-form, or even a mixture of these, if sensible.
    You might wish to bold the "oppose" part of your response, for clarity. On monster group, User Uanfala makes some useful comments above. Encouraging gnomes to go around converting parenthetical to something else, without first gaining consensus on the talk page, is a really, really bad idea, which will just lead to time wasting and edit-warring. --NSH001 (talk) 22:58, 19 August 2020 (UTC)[reply]
  • Support. They're used in a vanishingly small minority of articles and are very distracting and unexpected in those articles. We should aim for some baseline level of consistency in how we present our articles to the world. This, that and the other (talk) 10:19, 21 August 2020 (UTC)[reply]
  • Strong support because the in-line format is disruptive to the reader (the person we exist to serve), and probably harder than other formats for editors (especially newer ones) to get right; we should be aiming at making both reading and editing easier; happy days, LindsayHello 10:57, 21 August 2020 (UTC)[reply]
  • Comment.
    • Many of the contributions I see here are based on a quick and superficial look at the Actuary article. The problems there can be easily fixed by normal editing, as I've outlined at talk:Actuary. You're all trying to cure the wrong problem.
    • It's silly to ban a valid and useful citation style for the wrong reason.
    • Parenthetical referencing actually has some compelling advantages. I've highlighted some of them in my earlier contribution.
    • In some cases, parenthetical referencing actually improves the appearance of the article.
    • Here are some articles using parenthetical referencing: Falling cat problem, Fréchet algebra, Graph algebra, Harmonic Maass form, Mock modular form, Monster group, W-algebra. None of these would be improved by switching to superscripted citations. Mandating such a change smacks of Stalinist/Soviet-era totalitarianism. Not to speak of the colossal waste of time involved. And, by the way, trying to change the style in those articles wouldn't be easy.
    • My view remains that parenthetical referencing is an underused and under-appreciated citation style. It isn't my usual or preferred style, but this RfC has resulted in my appreciating its advantages more fully. I'm already using it partly, and in a very small way.
    • Think of parenthetical referencing as a variant of short-form, which nobody here seems to have any objection to. It's very close to short-form in many ways (as shown by the fact that the {{sfn}}} and {{harv}} families of templates work in basically the same way). Parenthetical gives you the advantage of getting rid of a whole section at the end, and making it a little easier to access the full citations. The trade-off is the "cost" of a small amount of additional text in the body of the article. That "cost" can be minimised by careful editing, most notably by keeping citations as far as possible to the end of sentences.
    • Like short-form (see, I told you, it has a lot in common with short-form!) it gives you a nice, neat, alphabetically-ordered bibliographic list of citations at the end, in contrast to {{reflist}} where the order is more-or-less random (the order in which the cites appear in the wikitext).
      --NSH001 (talk) 13:26, 21 August 2020 (UTC)[reply]
  • Support, in-line format is cluttery and less accessible. No need to mass-change existing articles, let's just not add any more of it. Stifle (talk) 15:39, 21 August 2020 (UTC)[reply]
  • Strong Support. Parenthetical "citations" are hideous and reader-hostile, and I hate them with every fiber of my being. –♠Vami_IV†♠ 18:46, 21 August 2020 (UTC)[reply]
but I truly the current "cite" format, tho I use it to conform to existing style when convenient. We each have our own very strong preferences, and judging by what type of format we individually" hate " is not cooperative nor productive. DGG ( talk ) 03:18, 24 August 2020 (UTC)[reply]
  • Support In none of the few articles that use this that I have seen have inline citations been an improvement; they are clutter. I think it's okay to mention the source as part of the prose ("Author (2020) says...") when appropriate, but "This is a fact (Author 2020)" and not using the standard footnote citations should not be done. Reywas92Talk 07:20, 22 August 2020 (UTC)[reply]
  • Support not introducing them into new articles and grandfathering in articles that already use parenthetical inline citations.--Esprit15d • talk • contribs 11:34, 24 August 2020 (UTC)[reply]
  • Support not introducing them into new articles, or at least discouraging their use, but grandfathering in articles that already use parenthetical inline citations. I think this is the compromise I've been waiting for. Certes (talk) 12:06, 24 August 2020 (UTC)[reply]
  • Continuing to oppose: If I had to recommend any single style, I'd not only permit but recommend parenthetical citations for any but the most complicated articles--they're immensely easier to write, and I find them easier to easy to read. It's obvious not everyone agrees--most people seem to prefer other styles, and I think that our system of permitting any consistent style whatever has merits. DGG ( talk ) 18:27, 25 August 2020 (UTC)[reply]
I disagree that in-line parenthetical references are immensely easier to write. Ref-tag citations can be as simple as copy-pasting a URL between two ref tags and you're done (I know, bare URLs are not recommended...). In-line citations require something in the main text and a full entry in the post-article section. --HyperGaruda (talk) 20:25, 28 August 2020 (UTC)[reply]
Have you ever done any training of new editors? I'm guessing not. Parenthetical references (which I don't like at all) require zero knowledge of wiki mark-up, which is a big barrier in itself for most new editors. Johnbod (talk) 02:47, 29 August 2020 (UTC)[reply]
  • Support Lake Ptolemy is an example of a GA that uses parenthetical referencing. And it looks awful and unWikipedia-ish, like a college paper. Even readers are bound to wonder whether they've landed at the wrong website when they see this. SD0001 (talk) 15:57, 28 August 2020 (UTC)[reply]
the way I'd word this is that WP is so well noted for a confusing style of citation and writing, and an obsolete appearance and awkward layout, that anything simple and clear looks like it isn't WP. DGG ( talk ) 04:02, 29 August 2020 (UTC)[reply]
Really? Is that your best argument? Some misplaced nostalgia for messyness? --Francis Schonken (talk) 04:41, 29 August 2020 (UTC)[reply]
It's arguable whether the parenthetical style is "simple and clear" for anyone other than academics. It comes back to the question of whether we write WP for the experts or for the lay readers. Subject experts would probably prefer to see parenthetical referencing. But I'd reckon the majority of readers aren't academics, and haven't come across this style except from a few college papers written all those years ago.
That being said, the {{harv}} and {{sfn}} templates are syntactically very similar, so it'd possible to have a gadget that makes {{sfn}}s show up like {{harv}}s (or vice versa) as per the user's preference. SD0001 (talk) 05:10, 29 August 2020 (UTC)[reply]
Comment No wonder you thought that Lake Ptolemy looked bad. Whoever wrote it incorrectly put the citations after punctuation. The result was that all the in-line citations appeared to start sentences and clauses to which they had absolutely no relevance at all, and were disconnected from the statements they were supposed to support, making the whole thing unreadable. I'm surprised it passed GA in that condition. Anyway, I fixed it here using my ETVP script. I think it reads perfectly fine now, and the citations now support the statements they're supposed to.
But the main point that should be drawn from this is that I keep seeing so many editors taking a quick, superficial look and failing to identify the real problem (and the real problem isn't parenthetical citations). --NSH001 (talk) 05:03, 30 August 2020 (UTC)[reply]
But that's exactly what so many of our readers do: take a quick, superficial look -- and articles with inline parentheticals in blue, indistinguishable from links, reduce the readability and approachability of the article. Retswerb (talk) 06:20, 31 August 2020 (UTC)[reply]
No, no, no, you've completely missed the point. Here I am talking about editors in a RfC being superficial, and as a result coming to the wrong conclusion. The whole point is that any problems with Actuary can be fixed by normal editing, without ditching parenthetical citations. The problem there is not parenthetical citations, yet people here keep on responding as if it were. But since you raise the point that (allegedly) parenthetical citations reduce readability, that's not true in general either. A parenthetical cite (PC) at the end of a paragraph never interrupts the text (and in fact is a slight improvement); similarly a PC at the end of a sentence is little or no interruption. A PC of the form "(Smith 1990) found that ..." also reads perfectly fine. I'll concede that a PC in the middle of a sentence can sometimes be intrusive, but careful editing can usually avoid that. Plus the attractiveness or otherwise of the format is a matter of taste or opinion. And it certainly doesn't justify a Stalinist/totalitarian ban on a valid and useful citation style. --NSH001 (talk) 08:20, 31 August 2020 (UTC)[reply]
  • Great example! This would seem to violate WP:OVERLINK to me: There's so much blue repeating the authors' names, the clutter makes it harder to skim or read the article. No one needs to read the authors' names over and over as they try to read the actually meaningful content. And no, the location of the punctuation is not the issue, it still looks awful! How in the world are numbered footnotes confusing? Reywas92Talk 02:27, 1 September 2020 (UTC)[reply]
  • Support: I stumbled upon this discussion after gazing in awe at Sepermeru. It felt like the entire citation shebang was used as in-line reference, making me sometimes wonder where the main text would continue. At the very least the ban on undiscussed style conversion from in-line parenthetical refs should be lifted. I would not mourn if in-line parenthetical referencing were completely deprecated, but it might be step too far for some. --HyperGaruda (talk) 20:14, 28 August 2020 (UTC)[reply]
  • Support - articles that use this archaic style are hard to read and hard to verify. I felt that way when I was a student and nothing has changed! Simply use ref-tag in-line citations like the vast majority of articles. GiantSnowman 20:44, 29 August 2020 (UTC)[reply]
    Comment No, they're not "hard to verify". As long as they're making proper use of the {{harv}} family of templates, and a proper target exists in the bibliography, they're actually slightly easier to verify. --NSH001 (talk) 09:08, 30 August 2020 (UTC)[reply]
  • Support per standartization, consistency, ease of maintenance, and readability. —  HELLKNOWZ   ▎TALK 20:56, 29 August 2020 (UTC)[reply]
  • Support - it should be discouraged on new articles; and editors should feel free to transition existing articles. Refs are easy to program and mass update, and keep the text clean. We shouldn't let limitations that exist on physical paper dictate what we do in an online encyclopedia where technology can be used to provide even better features. — Starforce13 21:03, 29 August 2020 (UTC)[reply]
  • Support VisualEditor and other tools have improved the ability to add/edit refs without using the in-line shorthands. Thosbsamsgom (talk) 21:11, 29 August 2020 (UTC)[reply]
  • Support per Thosbsamsgom. There was a reason to allow different styles back before VisualEditor and the related tools made it trivially easy to create citations in the standard format. Now there is no such reason, and a number of reasons to demand consistency. The strongest is ease of verification: even a bare, non template-ified reference formatted using ref tags is vastly easier to check than an inline parenthetical ref. AleatoryPonderings (talk) 21:20, 29 August 2020 (UTC)[reply]
  • Support - I have a personal preference not to see parenthetical citations, but if it were just my personal preference I wouldn't be !voting here. The reason I'm throwing in for the support camp is indirect: the citation toolbar in the Visual Editor (or whatever it's called these days) which allows easy creation and editing of citations has been, in my experience, the single most important development for the new user learning process. That is, it makes citations easy. It has major limitations and drawbacks at present (don't get me started on the ":0" naming, for example), but it's a great step in the right direction. I would support most measures which try to standardize the way citations are input. That's not to say there should be inflexibility in the way we display citations, however. The more we can standardize the input process, the easier it is for new users and the easier it is to develop tools that work -- to provide flexibility in the display, to streamline complicated processes (even for experienced editors), to automatically fix errors, to make more powerful bots, etc. I know this isn't a proposal for standardization, but it's a step in the right direction, away from a process that's far removed from the way the vast majority of editors do things (and the way all of our new user training materials say to do). — Rhododendrites talk \\ 21:20, 29 August 2020 (UTC)[reply]
  • Support - I don;t feel stringly about this, but I'm supportin' because inline parentheticals don't gather the references in a separate section which can be easily browsed. Beyond My Ken (talk) 21:26, 29 August 2020 (UTC)[reply]
Actually, that's exactly what they do do. Johnbod (talk) 21:50, 29 August 2020 (UTC)[reply]
@Noahfgodard: I don't understand your comment. You support deprecating parenthetical short-references as long as the templates that generate parenthetical short-references are still used? That makes no sense. Note that the wording of the RFC does not distinguish between references like (Author 2020) (a reference that in most cases clutters the text and would be better as a footnote), references like "Author1 (2018) wrote that ... but Author2 (2020) disagreed, writing..." (a parenthetical reference where the author name is part of the article text and is presumably relevant as content rather than purely as a reference), and references using sfn (parenthetical references within footnotes), and later clarifications by the proposer have indicated hostility to all of these forms). —David Eppstein (talk) 01:44, 31 August 2020 (UTC)[reply]
@David Eppstein: To quote the proposer, "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)." Thus, the third option you provide is appropriate, but inline parantheticals are not. That being said, it seems like perhaps I (and the proposer) misunderstand the use of Template:Harv, in that I (we) support the use/function of Template:sfn, but likely not that of Template:Harv. Noahfgodard (talk) 03:25, 31 August 2020 (UTC)[reply]

Arbitrary break 2 (citations)

  • Strong support – As others have noted, just look at the articles on Sepermeru and actuaries for how awful this looks. Plus, if all citations in an article are enclosed in <ref> tags, it's much easier for the references to be processed via scripting. I am also very surprised that anyone is opposed to this. Brad (talk) 21:18, 29 August 2020 (UTC)[reply]
    Comment Wrong on both counts. The Sepermeru article has nothing to do with the parenthetical style (or any other style), and the "problems" on Actuary can be dealt with by normal editing, as I've already pointed out, more than once. --NSH001 (talk) 05:45, 30 August 2020 (UTC)[reply]
  • Oppose. Lots of new editors, particularly academics, are used to using parenthetical citations. Forcing them to learn a different style - either from the outset or after another editor or bot has changed what they wrote to use a different style - would be one more barrier to entry and we have too many barriers already. Clayoquot (talk | contribs) 22:02, 29 August 2020 (UTC)[reply]
  • Support for the sake of consistency and as the version used on a lesser amount of articles. Steel1943 (talk) 22:43, 29 August 2020 (UTC)[reply]
  • Support. It's OK to have a standard and this change would enable prose generally easier for the reader. I don't support enforcement in a draconian way that discourages inexperienced editors from contributing. Airborne84 (talk) 22:46, 29 August 2020 (UTC)[reply]
  • Strong Oppose. we should welcome citations in any form at the encyclopedia anyone can edit. Feoffer (talk) 22:48, 29 August 2020 (UTC)[reply]
  • Oppose (for now) mostly per David E. and DGG, but the "for now" is when visual editor is available on every page and inserting and editing footnotes is easy for new users, I can see revisiting this discussion. But at present, the way of editing a footnote is still far too difficult, while parenthetical citation with bibliography is much easier. -- Michael Scott Cuthbert (talk) 22:59, 29 August 2020 (UTC)[reply]
  • Strongly Support This proposal will help standardize the content in our project. I don't think this proposal should or will cause an editor's work to be reverted if they use inline parenthetical citation style. Instead, another editor can come along and wikify it. Academics, people and students who write papers off-wiki have to adhere to the preferences of who they are submitting their papers to for publication or evaluation. I think it's expected that Wikipedia has their own style and we ask editors who publish with us to adhere to it or expect someone to come along and "fix" it. The most persuasive argument for its removal is parenthetical citations make articles harder to read because of the extra "clutter". Numbered citations are less cumbersome and should be encouraged for our project. Z1720 (talk) 23:03, 29 August 2020 (UTC)[reply]
  • Support simplifying the referencing system and hyperlinks are more intuitive for non-academic readers. Cheers, 1292simon (talk) 23:07, 29 August 2020 (UTC)[reply]
  • Oppose per Yngvadottir. --JBL (talk) 23:08, 29 August 2020 (UTC)[reply]
  • Strong Support. There are many more readers of Wikpedia than editors, and many more readers who just want to read the article to get information out of it and not study it as if it were in a learned journal asking for peer review, and I'm quite sure that through-readers are more numerous than conscientious citation-checkers.[citation needed]. From WP:NOT: "Wikipedia articles should not read like...Academic language". I'd claim even further: the more academically abstruse a subject is, the more we should aid understanding for an intelligent reader, and a fluent reading experience is essential for that. Even if you understand its meaning (and how many readers actually do so?) the parenthetical citation is a log rolled in the path of understanding and can break up the mental parsing of a well-written sentence or paragraph. To be honest, I've always even hated little blue superscript numbers because they are like a little thorn in my eyeball; even those little things get mentally "read" and break up the prose (yes, I know I could CSS them into invisibility). What's more, I support encouraging editors to convert them to <ref>-style citations when they come across them. Have I mentioned how much I despise them? David Brooks (talk) 23:13, 29 August 2020 (UTC)[reply]
  • Oppose per Wugapodes but also mainly as this is unenforceable and I am generally opposed to unenforceable non-policies. I don’t think I’ve read the MOS once in my time as an editor and I have 11 GAs and a featured list to my name (less than many, but it’s also not nothing.) Anyone who is a competent enough writer who wants to use parenthetical citations is going to use them anyway and that’s okay. This change would have no actual impact on the way people write articles because 1) most people don’t use it anyway and 2) IAR is best used on MOS type stuff, which this is, so the people who want to keep using it if it fits their subject matter will anyway.
    Tl;dr: this would be unenforceable and it’s not common enough now where even if it was enforced it would have any impact. TonyBallioni (talk) 23:15, 29 August 2020 (UTC)[reply]
  • Support for the benefit of the typical reader. Tdslk (talk) 23:16, 29 August 2020 (UTC)[reply]
  • Support per most of the above. Inline citations are disruptive to the smooth flow of reading a text and I have personally always used the Chicago Manual of Style wherever possible. That said, I don't think we need to be uber-dogmatic about this. Where articles exist with inline citations, if there is a reasonable argument for why they are best in that situation and they are supported by a strong local consensus, then let them be. But I do think their use should generally be discouraged. -Ad Orientem (talk) 23:27, 29 August 2020 (UTC)[reply]
  • Oppose per CITEVAR. I don't see a convincing reason for this and fear it will deter new editors who are used to this style. --Tom (LT) (talk) 23:35, 29 August 2020 (UTC)[reply]
  • Support Yes, citations in this style will almost certainly make an article difficult to read. 41618CCEC (talk) 23:37, 29 August 2020 (UTC)[reply]
  • Oppose It's not worth forcing it sooner than it naturally would, which we would expect it to if it ought to at all. Usedtobecool ☎️ 23:41, 29 August 2020 (UTC)[reply]
  • Oppose Using a certain style of citation should be optional, not forced on other contributors simply because another editor doesn't like it or doesn't know how to implement it in articles. Or it looks "better" or "more organized"...whatever the hell that means. The only thing that matters is that content is supported by a citation. I'm sure if this passes, another similar discussion will occur concerning era-style via WP:ERA where this community decides to force other editors to use only one era-style, and I'm sure such a discussion will backfire. I prefer the "academic" style...whatever the hell that means. People, if you don't want an academic-style article, there's the Simple English Wikipedia. Jerm (talk) 23:48, 29 August 2020 (UTC)[reply]
  • Oppose Wikipedia shouldn't be dictating that perfectly fine citation styles are unacceptable without a pretty good reason, and the only reasons I've seen is that individual editors don't like it and for consistency; if we truly wanted consistency over individual choice, however, then we would mandate a specific style. We shouldn't be making it harder for academic newcomers to contribute, and all I see out of this proposal is a step in that direction. Zoozaz1 (talk) 23:50, 29 August 2020 (UTC)[reply]
  • Strong support: While most articles obviously use a footnote style of reference, the few that use parenthetical references appear jarring, I think to readers and editors alike. For readers, it breaks up the text flow and is massively inconsistent with most articles. As an editor, they annoy me because (1) they are hard to track throughout any article longer than a stub, (2) they are often broken (e.g. just an author's last name and year of publication, but no corresponding footnote), (3) MediaWiki's <ref> system and our citation templates are more flexible through the use of abstraction, (4) they encourage the omission of a page number, and (5) they work well for books and journal papers, but not for websites (i.e. {{cite web}}), which account for upwards of 90% of the sources I encounter on all topics outside of liberal arts and medicine. To those concerned about discouraging new editors, I would reiterate the above proposal is for replacing parenthetical references with standard footnote-based ones; there is no need to pounce on editors who contribute content with parenthetical references. – voidxor 00:06, 30 August 2020 (UTC)[reply]
  • Support I lean to standardization so the encyclopedia looks more cohesive and recognizable to the reader. This style is rarely used and looks awful. When I first saw an article with these citations, my first thought was that I was on the wrong site or the page citations were rendering improperly. MB 00:12, 30 August 2020 (UTC)[reply]
  • Support. Clunky and messy. Bye bye, parentheses! 👋 —Biscuit-in-Chief :-) (/tɔːk/ – /ˈkɒntɹɪbs/) 00:16, 30 August 2020 (UTC)[reply]
  • Support. Check Actuary to see how god awful it looks. Moriori (talk) 00:22, 30 August 2020 (UTC)[reply]
Yeah, that is pretty clunky. We really should discourage its use. -Ad Orientem (talk) 00:40, 30 August 2020 (UTC)[reply]
@Moriori and Ad Orientem: And Aristobulus I? Jerm (talk) 00:58, 30 August 2020 (UTC)[reply]
This looks fine. This is not using parenthetical citations... Reywas92Talk 02:38, 1 September 2020 (UTC)[reply]
  • Support. We're an online encyclopaedia - let's embrace that. Popcornfud (talk) 01:20, 30 August 2020 (UTC)[reply]
  • Support - These look awful and IMHO shouldn't be in articles unless absolutely necessary, Agreed with the above they're confusing and make reading articles hard work!. –Davey2010Talk 01:33, 30 August 2020 (UTC)[reply]
  • Support - We're not an academic journal and have no reason to look like one. Some consistency to our style should be expected for ease of use. I realize this may take some adjustment for new editors coming from academia - if some resources can be created to ease their transition, I imagine that would be worth investing effort. In the end, our users will benefit from a consistent reading experience across all our articles. Radagast (talk) 02:04, 30 August 2020 (UTC)[reply]
  • Oppose - The important thing is the citation, not the style of it. If parenthetical citations are not preferred for an article, they can be reformatted to the preferred style. I personally hate the cite template and find it very difficult to use, so it must be even worse for inexperienced editors. Let them have their parenthetical citations. MaxBrowne2 (talk) 02:20, 30 August 2020 (UTC)[reply]
  • Oppose outright deprecation but support updating WP:Parenthetical referencing to strongly encourage the conversion of existing parenthetical citations to the software-supported footnote system (per Alsee). Armadillopteryx 02:31, 30 August 2020 (UTC)[reply]
  • Support, although I rarely see this on Wikipedia any more. Anyway, the parenthetical style is prone to gaming, it's messy, and it interrupts the flow of information and text. One of the reasons Wikipedia has whatever respect it now does is because of our use of footnoted and instantly checkable and generally clickable citations (and barring that "citation needed" tags). Parenthetical citations are obviously a step backward into lazy, distracting, less-accurate referencing, and should not be tolerated at this point. Softlavender (talk) 02:35, 30 August 2020 (UTC)[reply]
  • Support This isn't a paper publication, so no need to adhere to a paper journals' style, and it makes for a cleaner, more readable body text. I wouldn't refuse an article submission if that's how it was submitted, but I would convert it to use {{harv}} inside {{sfn}} pretty early on. (Not that I'm necessarily a fan of those, either, as they require multiple edits to add in both the footnote and the bibliographic reference, and for the reader require multiple clicks to find the full ref, but I digress.) oknazevad (talk) 03:02, 30 August 2020 (UTC)[reply]
  • Support I find it a rather jarring style. It works, yes. But it is not good for readability. I'm not buying the "it hurts new editors" argument, as an experienced editor can simply tell them to place it in a ref tag, which is not that hard to do. -Indy beetle (talk) 03:46, 30 August 2020 (UTC)[reply]
  • Support – Took a read through the page and some of the pages mentioned and agree that the pages look messy and the citation style makes the pages harder to read. I can't even imagine how it looks to readers. QueerFilmNerdtalk 04:00, 30 August 2020 (UTC)[reply]
  • Oppose, per Mike Christie's argument: "If this form of citation is dying out, let it die of its own accord; if it's not, it's because some editors like it." SarahSV (talk) 04:04, 30 August 2020 (UTC)[reply]
  • Support for consistency. Standardized appearance is a Good Thing. Cas Liber (talk · contribs) 04:27, 30 August 2020 (UTC)[reply]
  • Support - Oh man I have not had to use that crap in a long long time and even that it was too recent. It does not work well for an online encyclopedia as demonstrated by the example page and should be discouraged by force. It is a disservice to the reader. PackMecEng (talk) 04:33, 30 August 2020 (UTC)[reply]
  • Strong support. This is already the case broadly except in some niche subject areas, and is much much easier to read. I don't think anyone is arguing that inline citations are worse than no citations at all, or that articles be rejected because they have inline citations, but no one should have to argue the point if they want to convert inline citations to the proper format. Frickeg (talk) 04:37, 30 August 2020 (UTC)[reply]
  • Oppose – What is important is not the citation style, but that statements are cited. Some contributors are most comfortable with inline parenthetical referencing. Giving them the freedom to use it encourages their contributions. Having more editors writing more content serves the WP:READER in a more meaningful way than a consistent citation style across articles would. Some subjects are clearer with inline parenthetical referencing than with ref tags. If the consensus is that they make a particular article harder to read, the citation style of that article can be changed. But a citation style should not be deprecated merely on the grounds of personal preference. --Worldbruce (talk) 04:43, 30 August 2020 (UTC)[reply]
  • Strongly oppose Parenthetical referencing is vastly superior for both readers and editors. (1) For readers, they immediately see the author and date, and often the page number. Likely they will know the author. Seeing the date tells how old the information is. Given this information, there is a good chance that they will immediately know the source. (2) For editors, the reference is neatly and concisely contained in the text, making it easy to see where it begins and ends. The other style can go on for hundreds of characters, making it very hard for the editor to see where it begins and ends, making it very difficult to edit that section of text. I wrote about this on my user page years ago, see User:Bubba73#Why_I_like_Parenthetical_referencing_(also_known_as_the_author-date_system_and_Harvard_Referencing). Bubba73 You talkin' to me? 04:46, 30 August 2020 (UTC)[reply]
    @Bubba73: This reaction confuses me, because I feel like it's begging the question of who a "typical" Wikipedia reader is and what they want. Some of your arguments:

    For readers, they immediately see the author and date, and often the page number.

    Agreed, but I find it odd seeing that characterized as a positive. "Most readers" (meaning, laypersons — the "average reader" who isn't an academic) don't want their reading to be interrupted with irrelevant (to them) details like the name of the author a claim is referenced to.

    Likely they will know the author.

    That is just patently false. The average reader is not familiar with the authors of research papers being cited inline in article text on Wikipedia. The average reader is not so thoroughly steeped in academia that every time they catch a cold, they sneeze corduroy.

    Seeing the date tells how old the information is.

    That's a fair point. I question how interested in even that information the "average reader" really is, but it's a (tepid) argument for parenthetical citations.

    Given this information, there is a good chance that they will immediately know the source.

    We're back to patently false, now. Who are these people you're talking about!? The "average reader" I'm experienced with has absolutely no familiarity with the writings of "D'Arcy 2005", "Krutov 2006", or "Bader & Gold 2003", to pick three random examples from Actuary. ...Those combinations of name and year don't tell me anything at all, I can say that for sure. Are they meaningful to you? (Not "do you find them useful?" or "do you want them to be visible in the text?", we've established that. I'm asking, do those identifiers alone tell you anything about the works being referenced? — Aside from the age of the information, I already gave you that one.)
    It just feels like at least one of us is projecting quite a bit of their personal POV onto this idea of the strawman "average" visitor to Wikipedia. (I mean, I can say that I'm definitely guilty of this to some degree...) Maybe what we need here is an objective picture of Wikipedia's core audience. To consider this proposal and its impact on the Wikipedia readership (as opposed to its author/editor community) in the proper frame of reference, it's important to understand how people consume the site's content and what they expect from it. -- FeRDNYC (talk) 09:38, 30 August 2020 (UTC)[reply]
    FeRDNYC, I don't think an encyclopedia with six million articles can have a single coherent target audience. While Bubba73's statements certainly don't apply to the most common types of readers, they largely do apply to readers who visit the specialised types of articles that normally use parenthetical referencing (Actuary being a notable exception). – Uanfala (talk) 12:48, 30 August 2020 (UTC)[reply]
  • Support While hardly any articles use this style, we're not in the 1970s anymore. This is the World Wide Web, where we can have 'new', smoother techniques like inline sourcing. Have a painful glance at parenthetical references in action at Actuary.ThatMontrealIP (talk) 05:01, 30 August 2020 (UTC)[reply]
  • Support Those saying that the citation style isn't important are misguided. Wikipedia itself it a tool for those to explore other sources and to read more on a topic for details that might not be included in or appropriate for a Wikipedia article. Additionally, it's old, archaic, and meant to be used in physical text, not online. Utilizing templates and the Wikipedia software is a better, cleaner, more adaptable, and more streamlined option. Nihlus 05:19, 30 August 2020 (UTC)[reply]
  • Strong support it is the most disruptive citation style we currently allow in terms of reading flow. It should be deprecated. Peacemaker67 (click to talk to me) 05:24, 30 August 2020 (UTC)[reply]
  • Oppose. While I also hate the brackets citation style and it often makes me confused, I get along with it as I read the article more. People have different styles, you can't force them to just use CS1 or CS2 or CS100, yknow what I mean? By letting more citation styles on Wikipedia we allow more people of different citation backgrounds to edit, thus increasing Wikipedia's diversity and accessibility in terms of who can edit. Overall, I cannot see how deprecating it would increase readership. GeraldWL 05:30, 30 August 2020 (UTC)[reply]
  • Fully support. As the full reference is shown when hovering, the parenthetical citation style is not needed at all. -- BhagyaMani (talk) 06:09, 30 August 2020 (UTC)[reply]
  • Comment on broader picture. Above I wrote about continuing to support the parenthetical citation style limited to disciplines that commonly use them, an idea that, afaics, received zero traction in this RfC. A list of such disciplines is given at Wikipedia:Parenthetical referencing#Pros and cons versus other referencing systems: "... humanities, society, arts, and culture ..." Looking at that section of the guidance, it seems to me that a "con" is missing. Parenthetical citations are used in these disciplines mostly when writing an essay, or another type of contribution to the field about something that was not yet written before. In other words, when the author has to prove a point. This contrasts with what we're doing at Wikipedia: we have no new points to make (WP:NOR). So, a contraindication for using them would seem to me that parenthetical referencing systems may create the (wrong) impression that Wikipedia articles are a sort of (tendentious) essays in which summaries are made to prove a point. --Francis Schonken (talk) 06:22, 30 August 2020 (UTC)[reply]
  • Support, because:
  • Less inline text makes for easier reading - less text that most readers will skip over anyway - and we exist for the benefit of the readers, not the editors. We are a general encyclopedia, not an academic journal, should use whatever is easiest for general readers, not academia, or editors. (Do we have any metrics on how many people read the citation details?)
  • We have a Manual of Style for a reason - consistent styling makes for easier reading - if the same conventions apply to all articles it's easier to follow what they mean. Consistency should apply to all aspects, including citations as they appear in body text (independently of how they appear in the "References" section). For someone who is not familiar with inline parenthetical referencing it can merely obfuscate the meaning - is the author the Wikipedia article trying to tell me something with the parenthetical text?
  • Disallowing inline parenthetical citation should not prevent new editors from adding material or deter them from continuing to edit - any more than our other MOS guidelines stops people from Over-Capitalising, using "illogical quotation style," etc. Experienced editors merely follow and edit the article to comply with MOS, as we do for so many other style issues, preferably with a link to the relevant guideline in the edit summary. Wikipedia is a communal effort - it's OK for subject matter experts to add material in the wrong "style" and experienced editors to "fix" it.
Mitch Ames (talk) 06:52, 30 August 2020 (UTC)[reply]
Exactly! Did that many times -- "fix" it -- and nobody never complained. -- BhagyaMani (talk) 07:49, 30 August 2020 (UTC)[reply]
  • Support anything to try and keep to less overall citation styles. Certainly not nuke on sight, but we should try to replace these with a more consistent style Best Wishes, Lee Vilenski (talk • contribs) 07:37, 30 August 2020 (UTC)[reply]
  • Support per Puzzledvegetable --Amkilpatrick (talk) 07:49, 30 August 2020 (UTC)[reply]
  • Oppose there are type of articles where each style works best. Citing multiple pages out of the same book can't be done well with our more standard referencing, for example. We should allow our editors the choice to select which style works best for the type of article being written. ~~ Alex Noble/1-2/TRB 07:59, 30 August 2020 (UTC)[reply]
    Citing multiple pages out of the same book can't be done well with our more standard referencing — {{Rp}} works for me. Mitch Ames (talk) 08:15, 30 August 2020 (UTC)[reply]
    Fantastic. Why have I never seen this before? — JohnFromPinckney (talk) 09:02, 30 August 2020 (UTC)[reply]
    JohnFromPinckney Well I used it almost the moment it appeared. See Holocaust Educational Trust, an article I started. But usually I find short-form is better for handling different page numbers (as is parenthetical, by the way). --NSH001 (talk) 09:26, 30 August 2020 (UTC)[reply]
  • Support - Free-floating parenthetical refs, with no link to a fully-cited ref or footnote, leave the text open to question regarding its Verifiability. That's my main reason to phase out that style. DonFB (talk) 08:25, 30 August 2020 (UTC)[reply]
    Comment But that's not what we're talking about (the same thing can happen in other styles, too). And, incidentally, as long as a valid target CS1/2 cite template exists in the biblio listing at the end, my ETVP script can fix them. --NSH001 (talk) 08:42, 30 August 2020 (UTC)[reply]
  • @CaptainEek: Would {{quote}} be allowed if the attribution to the source is supplied with a date? Thincat (talk) 08:57, 30 August 2020 (UTC)[reply]
  • Strongly oppose Of the many, many problems Wikipedia has, people referencing articles using a perfectly acceptable style really isn't one of the big ones. I understand the desire for some form of uniformity and prefer using ref tags myself, but this flies in the face of CITEVAR which, for me, is a big deal. Ultimately using parenthetical referencing at least ensures people learn how to reference "properly" - unlike a reliance on cite template helpers which simply ensure the same people continue to confuse the publisher and the work, for example, and doesn't promote the idea that there are different ways of producing references. Like others, I have a feeling that this is a move towards the "one true style" as well, which is something I would feel uncomfortable dealing with, and allows a license for the interpretation of its outcome to lead to the wholesale removal of a range of referencing styles. Please ping me in some way if there's response to this as I'll not see it otherwise. Blue Square Thing (talk) 09:38, 30 August 2020 (UTC)[reply]
  • Support: If there wasn't an expectation that editors use the citation style that already exists in the article - and this is how WP:CITEVAR is usually interpreted - the counter-argument that this style causes no harm would be correct. But since we do have this expectation, it forces people to familiarize themselves with unusual citation styles whenever they want to edit articles using them, or else jump through hoops or simply slap their own preferred style in instead. I think it's reasonable to discuss and implement a reduction in citation styles so that folks only have to learn a limited number of them. Yes, I did write Lake Ptolemy with parentheticals but changing them to harv style is no issue there. Jo-Jo Eumerus (talk) 09:48, 30 August 2020 (UTC)[reply]
  • Oppose because it would discourage new editors with backgrounds in fields that use that style, including some fields (such as some of the humanities) that are probably under-represented among editors. A very casual reader -- who likely won't read past the lead -- might stop reading because of parentheses "clutter", but it's doubtful that the citation style will dissuade a reader who reads past the lead. It would make sense to discourage the parenthetical citation style in the lead, where citations are often unnecessary anyway. But we don't need new rules that might further limit our pool of editors. NightHeron (talk) 10:41, 30 August 2020 (UTC)[reply]
  • Strong oppose. This would be the thin end of the wedge of imposing standard citation templates. I can see the issue with readability, but the real cause of that problem is not parenthetical citations. Rather, it is the ridiculously high density of citations demanded by many reviewers on Wikipedia. Citation density has now gone way beyond anything found anywhere in scholarship. It has even gone way beyond anything that is demanded in Wikipedia policy. Fix that problem, and the issue with parenthetical citation goes away. SpinningSpark 11:06, 30 August 2020 (UTC)[reply]
    • Academia does not have an WP:OR policy, quite the opposite. This is the reason Wikipedia have so many citations, and that is good, not a problem. ― Hebsen (talk) 11:44, 30 August 2020 (UTC)[reply]
      • @Hebsen: Yes, Wikipedia is different from Acedemia, but please point to another encyclopaedia that has citation densities at this order of magnitude. Brittanica doesn't do it, nor does any online encyclopaedia except those cloned from Wikipedia. SpinningSpark 12:22, 30 August 2020 (UTC)[reply]
        • You misunderstand. Other encyclopedias does not have an WP:OR policy; in fact they do not need sources, because there are some experts or an institutions behind them, guaranteeing their reliability. Contrary to Wikipedia, which is crowdsourced and thus per se unreliable (sources make the content they support reliable). ― Hebsen (talk) 19:05, 30 August 2020 (UTC)[reply]
  • Support. I see no problem in discouraging editors from avoiding a minimal use of a style that properly formats notes as notes. It's simply better for the preponderance of the reader base to avoid just letting editors stuff more didascalia inline. Our visual formatting of notes has improved substantially over time, allowing readers to actually see the "Foobar 2020, p. 14" reference text nearly inline just by doing something seamless with their mouse, so whoever is used to the format can basically have nearly the same experience. Just like we should no longer use a gazillion inline <ref name=foo>{{cite bar | ... | page = 14 | ... }}</ref> tags, and should instead simply use {{efn|Foo|2020}}, we should not tell people to use raw inline references either. --Joy [shallot] (talk) 11:10, 30 August 2020 (UTC)[reply]
  • Support deprecation. It is fine that articles are still there with parenthetical citations, it is fine that articles are created with parenthetical citations, but I do think that it is a good idea to, slowly slowly, migrate all those to one standard citation style. Although parenthetical citations fulfill our needs of sourcing, you basically have to scroll down, identify which citation is linked to the reference (and possibly check the reference). With the <ref> tags you hover over the number and get the reference directly, generally including a link to the actual source if you want to check further. I would oppose throwing messages at editors who keep creating articles with parenthetical citations because it is deprecated, I would oppose enforced (and/or bot) move from parenthetical citations to other citation styles, I would oppose nuking on sight. However, articles should not be changed (back) towards using parenthetical citations, and changing over to using <ref> tags should be encouraged. --Dirk Beetstra T C 11:24, 30 August 2020 (UTC)[reply]
  • Weak support. Nom have given a number of reasons why parenthetical citations should be avoided. I would add the following two: (a) A good wikipedia article has A LOT of references (I count 107 in the ~3200-word article) because every claim need one, so the format need to be compact (a non-compact format actively discourage citations unless absolutely nessesary); and (b) The use of footnotes have become the de facto Wikipedia standard to such an extend that readers expect to see it, so us not using it confusing for the reader and harder to decode. It total, I think all the drawbacks of the style outweight the potential advantages it might have in specific articles or topics. There is not that big a difference between using parenthetical referencing and shortened footnotes.
Remember also that deprecation does not mean that it is not allowed, but rather that it is acceptable to change to another citation style. I don't buy that it will make it harder for newcomers to contribute, as newcomer often just use whatever they like, e.g. bare urls or parenthesis. In fact, I think it parenthethical citations make it harder for newcomers to contribute to such articles, because the editor's citation system automatically creates footnotes.
The support is weak because I don't care that much. ― Hebsen (talk) 11:44, 30 August 2020 (UTC)[reply]
  • Oppose – Although I don't use parenthetical citations and prefer the citation method more commonly used in Wikipedia, the parenthetical style is far from unusual in books and online sources, and I think editors should have the freedom to use it if is one they are at ease with. Tim riley talk 12:47, 30 August 2020 (UTC)[reply]
  • Support. We write for our readers, not for ourselves. And our readers appreciate standardization, readability and usability - all of which point towards the deprecation of inline citations. Sandstein 12:57, 30 August 2020 (UTC)[reply]
  • Oppose: Were such a flimsy IDONTLIKEIT argument posed in a deletion discussion, the jeers would be heavy. I'm not enthusiastic about parenthetical citation myself, but vox populi notwithstanding, there are many non-Village Pump readers and editors who use them, and I haven't heard a reason to ban them ("deprecate," in this context, is weasel wording) that's more trouble than it's worth. For all the "standardization" worship that goes on here, any reader who flees in horror in seeing a citation style not to his preference is a goofball. Ravenswing 13:26, 30 August 2020 (UTC)[reply]
  • Support a MOS preference for footnotes. No editor should convert footnotes to inline parenthetical citations, and editors should be permitted to replace inline citations with footnotes. pburka (talk) 13:38, 30 August 2020 (UTC)[reply]
  • Support A more standardised citation style is preferable, and a casual reader may be confused by parenthetical citiations. I normally see parenthetical citations in journal articles, theses, and academic publications meant for fellow academics, and they are useful for easy identification of authors whom they would normally recognised, or want to recognise, and where who says what is important. This is not so for Wikipedia where the casual readers would not know nor care who wrote the referenced source. Having parenthetical citations merely clutters up the article without imparting useful information for a casual reader. Hzh (talk) 13:45, 30 August 2020 (UTC)[reply]
  • Support They do make the articles, much more difficult to read. ~mitch~ (talk)
  • Support because they make the articles hard to read, and articles should be written with the readers in mind. I'm not persuaded by the argument that this will deter new editors from contributing, because really how hard is it to put <ref></ref> around a citation? It's right there under the edit box! Richard75 (talk) 14:46, 30 August 2020 (UTC)[reply]
  • Support. This isn't a major issue for me, but I find that when I come across the rare article that is formatted that way, it just looks so 1980s to me. Citevar isn't an end in itself, and although I agree with other editors that what matters most is having sources in whatever format, I also think it would be a net positive to move in this direction. I see "deprecation" as something that should be regarded here as soft deprecation, so that, if an editor wants to revise the citation style, that should be considered acceptable, but still subject to discussion if someone else objects. If there is consensus at a given page to stick with the parenthetical style, that's OK too. --Tryptofish (talk) 14:52, 30 August 2020 (UTC)[reply]
  • Support: the ridding of abomination is a duty to all. (And whaatever anyone says, pace, but Actuary is literally an object lesson.) ——Serial 15:51, 30 August 2020 (UTC)[reply]
  • Support It's clutter and makes it harder to read articles (Actuary is eyewatering). Like Richard75, I don't buy the arguments that this will deter new users – should we abolish MOS:DATE because new users regularly write out dates like "24th of April" and don't like being corrected? I also don't see how this is 'the thin edge of the wedge' regarding WP:CITEVAR. I can't stand {{cite}} and its variants and never use them, but I can't see how this will lead to their imposition. Number 57 15:57, 30 August 2020 (UTC)[reply]
  • Oppose. An outright ban (assuming that's what "deprecate" is intended to mean) would preclude both parenthetical usages even when they are genuinely part of the textual information. Example:
After two leading American researchers claimed to have found independently that water is not actually wet (Jones 1996, García 1997), several Canadians soon responded[fn multiple sources] ... Pérouse (1998) was especially vociferous...
Ban, no. As is so often the case, that absolute could -- and almost certainly would -- backfire, precluding useful cases, resulting in text less informative than amateurish overuse of excessive listing is annoying. The perennial Wikipedia compromise: it's true that the text should be accessible to Uncle Everett and Aunt Gladys; it's also true that this isn't Pee-wee's Playhouse, but an encyclopedia. Barefoot through the chollas (talk) 16:22, 30 August 2020 (UTC)[reply]
  • Support In general, having a consistent formatting style makes for a better experience, both on the side of editors and readers. Wikipedia should not expect people to learn multiple different citation methods. PieThrowerChamp (talk) 16:28, 30 August 2020 (UTC)[reply]
  • Support per the example of Actuary, which is visually cluttered and disorienting. I think most readers are used to the numbered citations that are used in the vast majority of Wikipedia articles. —Granger (talk · contribs) 16:35, 30 August 2020 (UTC)[reply]
  • Strong support. Verbosity is horrendous. Article text should be as compressed as possible.Untitled50reg (talk) 16:43, 30 August 2020 (UTC)[reply]
  • Support this is 2020, we have a myriad of tools available to us, and this is one more example of Wikipedia's ineptitude to adapt to modern web standards. The examples given of parenthetical citations are atrocious. ɱ (talk) 16:47, 30 August 2020 (UTC)[reply]
  • Support The fact that we tolerate a diversity of citation styles the product of historical anomaly. Wherever possible, wee should work toward streamlining citation styles. This one is not especially common and is not conducive to quickly accessing information in an article. Ergo Sum 17:05, 30 August 2020 (UTC)[reply]
  • Support  White Whirlwind  18:51, 30 August 2020 (UTC)[reply]
  • Mild oppose. As DGG said, the important thing is that articles and their individual claims be cited. Airbornemihir (talk) 20:48, 30 August 2020 (UTC)[reply]
  • Oppose Parenthetical citations are a convenient and widely-used format. The online Stanford Encyclopedia of Philosophy has inline (author year, page) citations in the main text without any apparent readability problems. Wikipedia's WP:CITEVAR is an indispensable anti-edit-warring feature not a bug. No one would argue for deprecating WP:ERA because of their idiosyncratic opinion that BCE/CE is more "cluttered" than BC/AD. Keahapana (talk) 22:22, 30 August 2020 (UTC)[reply]
  • Support While I fully agree that what really matters is that there are citations and that this information can be displayed in many different ways including inline parenthetical citations there is significant value in standardization and several disadvantages with this specific format. I thus believe that there should be a preference against this specific citation format, but it should be considered far better than no citations at all. --Trialpears (talk) 22:41, 30 August 2020 (UTC)[reply]
  • Oppose: "A foolish consistency is the hobgoblin of little minds". Gog the Mild (talk) 22:59, 30 August 2020 (UTC)[reply]
  • Oppose, mainly due to the malformulation of the proposal, as pointed by David Eppstein. I cannot fully tell what is being proposed to be deprecated or not. I strongly oppose deprecation of any parenthetical reference of the type linked, or "clickable", such as my favourite one Template:Harvp. I do support deprecation of non-clickable ones; if that is what you meant (and it seems so), make sure to write a proposal that sums it up and make it clearer. Thanks for taking the initiative, though. Walwal20 talk ▾ contribs 23:31, 30 August 2020 (UTC)[reply]
    • Strong oppose. The nominator proposes putting every citation, linked or not, within a <ref> tag, and I think his arguments to do so are not convincing enough. Inline citations of type Mackey & Glass (1998) are extremely useful when what is being said was clearly said is an important result achieved by these authors. I think placing it in a ref tag would greatly diminish the importance of the authors, and I can see this to be undue in many contexts. Walwal20 talk ▾ contribs 00:01, 31 August 2020 (UTC)[reply]
  • Support the formal notion of citation preference, oppose banning parenthetical. Looking at some of the articles for the parenthetical, I can see why some people would like to use them. However, I think it should be discouraged for the many other reasons in this discussion. Integral Python click here to argue with me 23:52, 30 August 2020 (UTC)[reply]
  • Support discouraging or disallowing it except in specific circumstances. I read actuary and agree it really clutters the text, hurts the aesthetics, and looks inconsistent with the rest of Wikipedia. Besides, it discourages adding more specific citations any additional ones will make the cluttering worse. I thought about cleaning it up but I was worried it would be controversial because one is not supposed to change an existing style without a consensus/good reason. HaEr48 (talk) 00:21, 31 August 2020 (UTC)[reply]
  • Strong support to phasing the citation system out. I've read all the opposing arguments carefully and find them unpersuasive. It makes for unpleasant reading and introduces unnecessary clutter into Wikipedia articles. The more popular system is also not that difficult to figure out, especially given that there are templates to generate citations. Kohlrabi Pickle (talk) 02:36, 31 August 2020 (UTC)[reply]
  • Support of phasing out citation system. It seem just an academic excuse to get noticed.War (talk) 02:53, 31 August 2020 (UTC)[reply]
  • Oppose – When I have encountered parenthetical citations, I've considered them candidates for conversion; but I don't think of them as inherently intrusive or confusing. I've encountered at least one experienced editor who has expressed distaste for sfn templates, which aren't the most graceful solution for their purpose and for which parenthetical references seem a useful substitute. Added to that is the fact that when articles have many hundreds (~5–700) of citation templates, the templates seem to be the cause of the inordinately slow rendering of such pages on underpowered devices (e.g. a netbook). Although such overly referenced pages are the least likely to adopt the parenthetical style, it's another reason why the present citation templates aren't the complete answer to referencing (awaiting the day when referencing is done through Wikidata identifiers that can specify not just the source but also the source's relevant supporting text). Dhtwiki (talk) 03:57, 31 August 2020 (UTC)[reply]
  • Support - more consistency can't hurt. In fact, I didn't know Wikipedia used this citation method. Anarchyte (talk • work) 04:38, 31 August 2020 (UTC)[reply]
  • Oppose – i want to see the citation without having to move to my mouse to footnote number and/or have to click on the footnote. However, consistency is important. So, picking just one for the entire site is best. (But, you know which one i would choose that though....) – ishwar  (speak) 05:01, 31 August 2020 (UTC)[reply]
  • Oppose Consistency in form is far, far less important than consistency in other standards, those for researching and writing...and those require researchers and writers, who may bring with them their own preferences about style. Why alienate the worker bees to placate the dronesgnomes? Qwirkle (talk) 05:53, 31 August 2020 (UTC)[reply]
  • Support of deprecating parenthetical citation system.— al-Shimoni (talk) 06:32, 31 August 2020 (UTC)[reply]
  • Support. I was a little on the fence until looking at Actuary, and then taking a peek at some of the other pages mentioned above as examples of why we should keep using inline parentheticals (Falling cat problem, Monster group, etc.) sealed the deal for me. So. Much. Blue. Retswerb (talk) 06:34, 31 August 2020 (UTC)[reply]
  • Support but keep in mind that deprecation is not a clear-on-sight process. It is fair to say that most readers find the footnoting system more convenient as they can view the footnote directly without having to scroll all the way back up to continue. Besides, as other editors mentioned, the vast amounts of blue (almost like WP:OVERLINKing) proves to be inconvenient. So, on the long run, as Wikipedia is meant to serve WP:READERS, the general style (footnotes) is more convenient as compared to the inline WP:HARVARD style. However, it's no big deal, and the changing process has WP:NODEADLINES. Eumat114 (Message) 06:45, 31 August 2020 (UTC)[reply]
  • Support At AFC we encourage the disuse of the parenthetical system. Deprecating it makes that encouragement even easier to give Fiddle Faddle 07:29, 31 August 2020 (UTC)[reply]
  • Support Parenthetical citations look messy and make articles less accessible and harder to read. Davidelit (Talk) 09:10, 31 August 2020 (UTC)[reply]
  • Support the citations pad out "normal" article text and distract from the content proper. Granted, there would have to be some effort cleaning out what's there, but deprecating it would help in stemming the flow of new articles styled that way. Juxlos (talk) 09:59, 31 August 2020 (UTC)[reply]
  • Strong support I am not so far from being a novice in Wikipedia and find that what makes citing a pain is the bewildering choice offered, not the lack thereof; the eternal "yes but also" in the MOS. Wikipedia needs a house style. CITEVAR should go. <ref></ref> and Sfn. Johannes Schade (talk) 11:24, 31 August 2020 (UTC)[reply]
  • Oppose I would have said support until a supporter's comment directed me to pages (such as Irish phonology) where the Name (date) format is hyperlinked to the full citation. With this, a mouse hover one time lets you see what that source is, and subsequent citations don't require a second check because you've got a name/date, which is far easier to recall than a footnote number. This is the reason why generally, paper journals favour named citation over footnote/endnotes. (I had only previously seen non-linked citations, which are inferior to a hyperlinked number). One of the problems Wikipedia faces is the variable quality even within what the community says passes as reliable sources. It's helpful for those more familiar with a topic to be able to see more quickly the level of reliance on better or worse sources. OsFish (talk) 14:52, 31 August 2020 (UTC)[reply]
  • Strong oppose. I don't think we need to ban things like this to begin with. All the rationales given are effectively using examples of bad editing as if this proves there is no good way of using such citations which is clearly incorrect. This type of citation can be quite useful in certain situations. Having the option available is a good thing.--Andrew Lancaster (talk) 07:26, 1 September 2020 (UTC)[reply]
  • Support, but only as a standard for new articles. If info was referenced in parenthesis inline before, the info should not be removed because of the ref. form, but the ref. should be updated.Paradise Chronicle (talk) 20:16, 1 September 2020 (UTC)[reply]

Arbitrary break 3 (citations)

  • Oppose, mainly per Wugapodes, and DGG. We should remove obstacles to editors creating content. The parenthetical notes can always be converted later, but no need to discourage their use. Modern readers are well used to skimming over non-critical mark-up. Gleeanon409 (talk) 10:40, 31 August 2020 (UTC)[reply]
  • Strong support separating citations from the text into footnotes is important for making the overall text both accessible and usable by machines for different tasks (i.e. evaluating if a sentence needs a citation). Sadads (talk) 12:07, 31 August 2020 (UTC)[reply]
  • Strong support - Seems to me to be a more user/reader-friendly way to cite sources. I feel Harvard-style referencing can seem overly-academic, particularly if applied to sources that are not books, journal articles, etc. Paul W (talk) 12:33, 31 August 2020 (UTC)[reply]
  • Support per Alsee's comments in the main discussion. – The Grid (talk) 12:40, 31 August 2020 (UTC)[reply]
  • Support - As someone who has spent a lot of time patrolling new pages, I have never seen inline parenthetical citations used. However, I have seen many examples of footnotes without inline citations. In those situations, the page can either be tagged or incline citations can just be added. Here, if someone were to ever use inline parenthetical, the page could be tagged as having improper citations, or it could simply be manually fixed by conversion to footnotes. I cannot imagine how passing this would create a barrier to new content creators. Ultimately, WP has a massive MOS which is often misapplied or ignored. Why would adding something new to the MOS harm the project? I think the average user is going to understand what footnotes are. ‡ Єl Cid of Valencia talk 13:02, 31 August 2020 (UTC)[reply]
  • Strong Support I think that removing inline citations improves the look of the articles. I also think it standardizes referencing and supports KISS. If anyone wants to see the citation they can just mouse over it. I think most readers can figure that out. --Ian Korman (talk) 14:06, 31 August 2020 (UTC)[reply]
  • Comment Agreed that the usage of parentheticals in Actuary is excessive and unnecessary. In the first three paragraphs, all could be footnoted, with little or no loss to textual information.
Does that license banning all parenthetical references, or would that be a bit like banning wine from dinner nationwide because a tiny percentage of the population are given to guzzling large amounts of “liquor” at any time? Does the extreme case of Actuary justify banning all parentheticals?
Point: Best to do surgery with a scalpel rather than a chainsaw. There’s a crucial distinction between backgrounded sources, rightly footnoted, and references that, yes, could be footnoted, but that are not just references, but genuinely informative parts of the text, such as in recounting the well-known war instigated by Smith in his landmark publication – Smith (1999) brought about a basic reassessment… Barefoot through the chollas (talk) 14:31, 31 August 2020 (UTC)[reply]
  • Support: inline parenthetical citations create lot of confusion and nearby wikilinks make things worse.--Deepak G Goswami (talk) 14:53, 31 August 2020 (UTC)[reply]
  • Strong oppose: Such a way to turn a non issue into an issue. Just for the sake of "ILIKEITHISWAY" editors with experience in such citation style might be driven away from Wikipedia. Also in quote boxes, informational notes, meta-context and other specific contexts inline parenthetical references are possibly a better option, anyways. Recommendation not to turn paragraphs into a forest of family names & dates? Ok. Full ban irrespective of context? No way --Asqueladd (talk) 15:06, 31 August 2020 (UTC)[reply]
  • Strong oppose: Inline parenthetical citations are particularly useful when there is a need to reference multiple separate pages from the same source. Which is often the case when dealing with articles of old topics. Using parenthetical citations actual result in less clutter in those cases because it becomes easier to point to specific pages. For instance, "John Doe 1990, p. 3" and "John Doe 1990, pp. 33–35" as separate inline citations are more specific to the material being sourced than the other method in which it would either be "...pp. 3–35..." or a repetition of the entire reference template and source. David Eppstein lists many valid points and it would be a net negative to actively discourage a particular referencing format, especially when that format is widely accepted in publications and has uses unique to it. — The Most Comfortable Chair 15:20, 31 August 2020 (UTC)[reply]
My bad on misunderstanding exactly what had been proposed. I would still reaffirm my oppose. Discouraging a referencing style that is accepted and employed in certain areas may discourage new editors from those areas from contributing. As others have pointed out that its use is rare as it is, and if it results in too much clutter in an article, it can easily be converted to other referencing formats. I do not see any benefits to an outright prohibition. It is a non-issue. — The Most Comfortable Chair 06:56, 1 September 2020 (UTC)[reply]
{{sfn}} and {{r}} can both be used to reference multiple separate pages from the same source without using parenthetical citations. --Ahecht (TALK
PAGE) 20:53, 31 August 2020 (UTC)[reply]
  • Although I strongly support changes to policy and practice that make editing easier without compromising quality and maintainability, I am opposed to this specific proposal because it's so poorly written that I honestly do not understand what exactly is being proposed. (That is quite disappointing in an RfC that is being advertised to all logged-in editors.) Moreover, it does not appear that the Visual Editor currently supports adding and editing citations in a way that also makes articles easy for editors not using that editor. That would, of course, also have to support citations that point to specific portions of a document (page, section, etc.). When it reaches that state, we should revisit this kind of proposal. ElKevbo (talk) 15:27, 31 August 2020 (UTC)[reply]
  • Strong oppose per DGG, David Eppstein et.al. As a humanities student the Harvard system was drilled into me when I started at university many decades ago. Deprecating any widely used proper referencing system is a sure way to discourage newbies who are comfortable using such references (subject specialist academics for example, the most sought after new editors we need). Not only is this proposal a solution in search of a problem, it will in fact exacerbate the very problem it claims to be addressing. Roger (Dodger67) (talk) 16:34, 31 August 2020 (UTC)[reply]
  • Support In the beginning, when we moved from just asking that articles end with a list of references to requiring inline citations, the goal was to encourage the latter so no one citation style was demanded.

    That time is long past us now. Our technology has improved, for one. Using inline parentheticals seems quaint and outdated to me, and, I'm sure, lots of other editors. Perhaps there are still some articles somewhere that use {{ref}}, the first citation system I remember using. I resisted at first the move to {{cite}} and {{reflist}}, since the latter columnized notes no matter how few there were, which I thought looked silly in an article with only two or three sources, but that issue has now long been corrected. And it manages note numbering automatically. Inline parentheticals still require manual, hands-on reference management.

    Further, the community has voted with its keyboards. {{Cite}} is clearly the winner.

    We are also moving, more and more each year, to an era when the data structuring allowed by Wikidata (something that was just an idle pipe dream back in 2008 for most of the community) will facilitate the translation and importation of references across all Wikimedia projects. This can't work with inline parentheticals.

    And lastly I believe that the inline-parenthetical style is wrong for an encyclopedia, any encyclopedia. It's more appropriate to the sort of academic journals where the majority of readers are those who keep up with the field in question and might reasonably be expected to know the work being cited just by the author and year. We write Wikipedia for a lot more people than that.

    Writing references that way, I also think, actually slightly encourages the insertion of original research because of these academic associations and connotations.

    It's time, indeed it's been way past time for a long time, that we deprecate this style for new articles and encourage the conversion of those articles that still use it to Harvard referencing, which is more conducive to the way we do things now. Daniel Case (talk) 17:03, 31 August 2020 (UTC)[reply]

  • Strong support: This proposal will make articles much easier to read and retain all relevant information. GrammarDamner how are things? 17:17, 31 August 2020 (UTC)[reply]
  • Strong support: Many of the opposers above aren't taking into account that we're just talking about inline parenthetical citations, not any kind of parenthetical citation. Many others think that we would for some reason treat a newbie who uses them as a vandal or sistematically revert their edits were this change to be implemented, when that is far from what is being proposed. The same way that some users just put the link in-between ref tags and afterwards another user comes in and uses a proper citation template, some other user will come in afterwards and change the inline parenthetical to a {{sfn}} or something of the sort. Any newbie that uses inline will have the freedom to do that, they just won't be able to keep an article that way just because they like it. El Millo (talk) 17:29, 31 August 2020 (UTC)[reply]
    • But parenthetical references are by definition in-line (in parenthesis, within the text), aren't they? Of course, I can't speak for others, but the concern about newbies is for those of them who would look up the help pages about referencing and find out that the style they know how to use they can't use here, they can be put off contributing. And this is not completely analogous to how we handle bare urls: most uses of parenthetical referencing are careful, considered choices and editors who have made those choices and then gone to the trouble of implementing them will probably not be happy if others come by and reverse them "because just so". – Uanfala (talk) 17:52, 31 August 2020 (UTC)[reply]
    • It is clear from the comment not far above by Fiddle that AFC are already denying their victims the freedom to do that, so far without the slightest authority from the community. The proposal is so vague that that what we're talking about is highly unclear, as is evident in a high proportion of the comments above. You are making one set of assumptions; other are just as entitled to make completely different ones as to what is proposed. Johnbod (talk) 17:55, 31 August 2020 (UTC)[reply]
      • Many opposers cite referencing different pages of the same book as an argument, when that can perfectly be done with {{sfn}}, so while technically parenthetical citations are inline by definition, the same style of citations can be wrapped within ref tags and the problem is solved. That was what I was referring to. I guess I would be more in favor of saying it is the preferred style without outright deprecating it, but I'll still support this proposal. By "preferred style", I mean that there would be no need to get consensus in order to change one article from inline to reftag-style references, because there would already be a consensus for the latter in the community at large. El Millo (talk) 18:31, 31 August 2020 (UTC)[reply]
      • What? No way does Fiddles comment equate to denying their victims anything. This is ridiculous hyperbole. Also if 99% of the commentators understand the proposal clearly and one percent don't the problem is probably with the 1%. AIRcorn (talk) 22:11, 31 August 2020 (UTC)[reply]
          • "He says "At AFC we encourage the disuse of the parenthetical system. Deprecating it makes that encouragement even easier to give Fiddle Faddle" - "encourage the disuse" surely means not allowing articles to pass if they use parenthetical refs. What else could it mean? It is clear from the votes who go into any detail that voters on both sides have widely divergent ideas about what the proposal does or should mean. Johnbod (talk) 13:43, 1 September 2020 (UTC)[reply]
  • I don't feel strongly enough to bold, but I think I'm mostly with xaosflux. Don't ban or proscribe inline parentheticals, but change CITEVAR to allow any good-faith conversion to the standard citation style (i.e., without having to separately find consensus for it). (I don't plan to watch this discussion, so ping me if needed.) --BDD (talk) 18:16, 31 August 2020 (UTC)[reply]
  • Support for AntiCompositeNumber's first and second types of deprecation: stating formally that hypertext endnote citations are Wikipedia's preferred citation style and preauthorizing the noncontroversial conversion of inline parenthetical citations to the more user-friendly endnote style. If a new editor (or any editor) prefers to use the parenthetical style, then they should still be free to do so, but any other editor who wants to make the article easier to read should be free to jump in and change the citations to Wikipedia's preferred style. -Bryan Rutherford (talk) 20:02, 31 August 2020 (UTC)[reply]
  • Support These types of citations are becoming less common with time. At this point, all they do is create an inconvenience for readers, because they make the article look messy. It is time to move on. Scorpions13256 (talk) 20:06, 31 August 2020 (UTC)[reply]
  • Strong support These types of references are distracting because of how uncommon they are on Wikipedia, and it's much cleaner and more readable to have these delegated to a ref tag. Wikipedia is online, and people should be making use of the tools that offers. Every time I see people using * † ‡ etc for footnotes I always change those to EFNs because hyperlinks should be used when possible. Same idea goes with inline parenthetical citations, it's much clearer without.  Nixinova   T   C   20:25, 31 August 2020 (UTC)[reply]
  • Support Wikipedia is hypertext, there's no reason we should be sticking to conventions based on print publications that require cluttering up articles with citation names when the full citation could just be a click away. There are plenty of ways around the "multiple citations to different sections of the same source" problem, including using Shortened footnotes (via {{sfn}}) or using {{r}} to add a page or section name in superscript. There's also the upcoming meta:WMDE Technical Wishes/Book referencing, which allows you to do something like <ref extends="previosreference">Page 25</ref>. --Ahecht (TALK
    PAGE    ) 20:53, 31 August 2020 (UTC)[reply]
  • Support. Parenthetical references are cumbersome and distracting from the average reader's perspective. Wikipedia is not paper, and we should take full advantage of its capabilities for inline citations. --Sable232 (talk) 22:05, 31 August 2020 (UTC)[reply]
  • Support articles are written for readers, not authors. This isn't a University press designed for elites. It's for everybody. Also, there's this thing called hypertext. -Rob (talk) 22:13, 31 August 2020 (UTC)[reply]
  • Oppose-The most important thing is getting articles well sourced. Forcing editors to avoid parenthetical style, particularly those with expertise in some filed and who are used to that style, only adds to the discouragement people complain about who attempt to edit here. Does anyone have any evidence this citation style is a real problem with actual readers? When I tell people I edit a lot on Wikipedia, I hear all sorts of stories. I've never heard anyone mention parenthetical references as a problem, but I get complaints all the time about how bureaucratic we are.--agr (talk) 23:17, 31 August 2020 (UTC)[reply]
    That's probably because articles with this kind of citation style are very rare. I for one have never encountered one on my own, not counting those that have been put as examples in this RfC, of course. El Millo (talk) 02:12, 1 September 2020 (UTC)[reply]
    If they are rare, why make a contentious policy change? Get local consensus and go change the few that have high visibility.--agr (talk) 12:28, 3 September 2020 (UTC)[reply]
    In my mind, this policy change would make official and clear the preference for ref tags over parenthetical notation. It isn't banning parentheticals, but it does make clear for an editor who is trying to write to Wikipedia standards what the preferred style is.Carter (talk) 13:01, 3 September 2020 (UTC)[reply]
  • Strong support for both discouraging new use and for replacing them unless there is a specific consensus against doing so. Nick Number (talk) 23:58, 31 August 2020 (UTC)[reply]
  • Support. Hypertext allows for sources to be easily jumped to or to pop up when hovered over. Depreciating parenthetical citations doesn't ban their use, and there are some cases where it may make sense, but the preferred should be reftags. Carter (talk) 00:17, 1 September 2020 (UTC)[reply]
  • Support With the condition that talk page consensus is reached before retroactively changing any existing articles to a different format. Tonystewart14 (talk) 00:31, 1 September 2020 (UTC)[reply]
Under this condition, how would this proposal differ from already existing guidelines? – Teratix ₵ 03:18, 1 September 2020 (UTC)[reply]
  • Support As per extensive arguments above. Loopy30 (talk) 01:58, 1 September 2020 (UTC)[reply]
  • Support. I was of two minds about this, since in my entire career, writing in two academic backgrounds and one professional, I've always used footnotes, not parenthetical cites, and I was afraid I was letting my personal experience bias me. Then I tried to read the Actuary article. If that is a valid use of parenthetical in-line cites, and it seems it is, then I think it needs to be stomped out as quickly as possible. That style makes it extremely difficult to read the article. Footnotes are, I think, more commonly understood and more accessible. A strong preference for footnotes, with parentheticals gently deprecated (just like bare urls need to be fixed) would be my option. Mr Serjeant Buzfuz (talk) 03:53, 1 September 2020 (UTC)[reply]
  • Support for future articles. It simplifies reading and gives more consistency over the whole Wikipedia. Existing articles using the format can be converted over time without rush. --Ita140188 (talk) 05:26, 1 September 2020 (UTC)[reply]
  • Support. Especially for a general audience, minimizing the obtrusiveness of citations is important. Based on the clarifications of the proposal, I'm quite satisfied that this is an appropriate way to address a citation style that is already unpopular on Wikipedia and (imo) detracts from readability. ― biggins (talk) 07:45, 1 September 2020 (UTC)[reply]
  • Support. Wikipedia serves the general public. It is not an arm of academia and parenthetical references are a mess to read and edit. Pyxis Solitary (yak). L not Q. 07:50, 1 September 2020 (UTC)[reply]
  • Oppose per Wugapodes et al. The disadvantages outweigh the minimal advantage of slightly easier readability. Jakob.scholbach (talk) 08:01, 1 September 2020 (UTC)[reply]
  • Support per some others' arguments. Would rather not repeat. Flyer22 Frozen (talk) 08:37, 1 September 2020 (UTC)[reply]
  • Support - others have once again said what I would have said here. stwalkerster (talk) 10:40, 1 September 2020 (UTC)[reply]
  • Support, provided we don't beat newbies over the head with it. Parenthetical cites are a holdover from the pen and paper days, there really isn't an advantage over footnote templates. If people want they can just hover or click on the blue numbers, it's not much of a hassle and worth the tradeoff to make reading easier. Now that we have the digital technology to make cites less intrusive, let's embrace it instead of clinging onto the past. - AMorozov 〈talk〉 10:56, 1 September 2020 (UTC)[reply]
  • Support Other editors have expanded on this in much more detail, but I believe footnotes are vastly more consistent, readable, and user-friendly. I don't buy that this is going to make it harder to contribute to Wikipedia. If a new editor starts editing with parenthetical citations then another editor will simply come along and edit those - much like how things work everywhere else on the encyclopedia. Sam Walton (talk) 10:58, 1 September 2020 (UTC)[reply]
  • Support. The amendment to the MOS should make it clear that Harvard citations remain welcome (and in many cases are most appropriate) provided they are enclosed in ref tags. If done properly, mouse over the reference number will pop up Smith (2008) with a hot link to the specific publication. --John Maynard Friedman (talk) 12:47, 1 September 2020 (UTC)[reply]
  • Support Readability is the principal concern of the wiki. Other problems are secondary. Cabayi (talk) 13:19, 1 September 2020 (UTC)[reply]
  • Support Wikipedia is not a scholarly journal, and readers should not be burdened by intrusive footnotes. In fact, if I had my way, the default mode of Wikipedia would not show footnotes at all; you'd click a button to turn them on, if you are really interested in the sources. --Kent G. Budge (talk) 13:53, 1 September 2020 (UTC)[reply]
Kent G. Budge, In general, I agree that we should enable readers to consume our content in whatever way is most useful to them. And, indeed, our HTML markup is sufficiently structured that hiding the references is probably one line of added CSS.
But, I'm going to push back on the idea that hiding the references should be the default. It's important that we make it clear to our readers that we're just a WP:TERTIARY source. Showing the references by default frames how we expect readers to treat what we say, i.e. with an appropriate dose of skepticism and a need to fact-check everything. If we hide the references by default, that encourages people to just trust us without verification. -- RoySmith (talk) 14:26, 1 September 2020 (UTC)[reply]
And yet, the printed encyclopedias I grew up with did not have footnotes at all. They'd simply identify the contributor for each article, and there was a separate contributors page listing the credentials of each.
This doesn't work for Wikipedia because Wikipedia requires no credentials of its authors. Instead, it requires reliable sources of its authors. I think it follows that the citations are primarily there for authors and editors, not for the reading public. Though I acknowledge it is a truism that serious researchers do not come to Wikipedia for information; they come to it for its lists of sources.
But I should emphasize, before this gets off track, that I'm not actually proposing to turn off citations by default any time soon. I made that comment to emphasize that I think citations should be as unobtrusive as reasonably possible, to minimize the burden on readers. --Kent G. Budge (talk) 14:36, 1 September 2020 (UTC)[reply]
  • Support Parenthetical citations distract from the fluidity of reading the text. It puts the onus on readers to obtain a text and flip through pages to see if the reference even supports to claim. I view these parenthetical citations as simply "lazy", and the notion that they might be fixed later... well, we know that reality rarely pans out. -AppleBsTime (talk) 15:20, 1 September 2020 (UTC)[reply]
  • Oppose CaptainEek’s explanations of the proposal has phrases that are vague (“a lot has changed since then” and “our style grows more standardized and formal”), and I’d like to know what’s meant. The proposal appears to be solving a problem that CaptainEek suggests is a small problem. Respecting what’s said in the numerous oppositions above: CaptainEek’s suggested solution will replace a small problem with other small problems. A more important and serious citation problem is accuracy and verifiability—not getting persnickety about style with editors who may be new, who may be accurate, who may be academic, who should be encouraged not discouraged.(Einbildungskraft) (talk) 15:29, 1 September 2020 (UTC)[reply]
  • Comment TL;DR: MOS RfCs are a valid way to settle down on a preferred in-house style. They are not a valid way to determine user experience facts. When the RfC rest heavily on such facts (as is the case here) seek out the facts first.
This RfC might be a valid straw poll or consensus-building of what reference style Wikipedia editors prefer, but determining what the readers prefer is a different story. An RfC about citation styles is bound to suffer from large selection bias towards editors who care about such things, therefore, who already have a much higher familiarity with references than the average editor let alone reader.
My understanding of the average Wikipedia reader, based on IRL interactions, is that they do not care about citations and would only check them if a claim looked outlandish. If my sampling was representative, the best solution in terms of readability for the audience would be to hide references from readers, or maybe have a button to toogle them on or off (with default off), and probably let editors use whatever they want in the backstage.
Is my sampling/feeling a good approximation of the average Wikipedia reader? Probably not. But probably neither is that of someone who writes Most people have encountered parenthetical citation styles at some point in their lives. (Most academics, sure, most Wikipedia editors, maybe, but certainly not most Wikipedia readers, let alone most people.) I am singling out Wugapodes here because it was easy to extract one sentence to criticize but other arguments about what readers want are dubious as well.
For instance, many supporters say that Wikipedia footnotes are good usability, or at least better usability than parenthetical. That is how I personally feel as well but is it really the case for the average reader? The only evidence is see, which is highly circumstancial, is that few if any modern websites use linked footnotes, in particular news websites, whose income depends on how readable they are (and whose average reader is probably similar to Wikipedia's). This suggests that footnotes in websites are poor design for some reason. Does the reason apply to Wikipedia though?
TigraanClick here to contact me 15:31, 1 September 2020 (UTC)[reply]
@Tigraan: This isn't just my personal feeling; there is a sizeable body of literature in education and information science on how to teach in-text source attribution at the primary and secondary school levels. Vieyra and Weaver (2016) give an overview of this literature and point out that while students at the secondary school level are not particularly good at creating in text citations they are at least prevelant. They received 198 essays from students between grades 6 and 12 and 32% of those essays contained in text citations (nearly all had reference pages). This rate varied by grade level, with high schoolers far more likely to provide in text citations (peaking at 10th and 11th grades where the majority contained in text citations; see figure 1). They also report a survey of college faculty where they asked for faculty perceptions of how much practice first year college students had in high school with in text citations, and of the 23 faculty they surveyed all but 3 pereived students as having had at least minimal practice with in text citation. As a curricular point, the Amerian Association of School Librarians and its membership have been working to improve student competence in citation, and just searching the internet for secondary school library websites will show a significant number providing information on MLA and APA citation styles (e.g., Garfield HS, Ladysmith Library) often with pointers to Purdue OWL which describes in text citation formats for those styles. Test prep resources for high school standardized tests like the Advanced Placement exams likewise recommend students use some kind of in text attribution in order to receive high marks (example from Spring Grove School District). While my phrasing may not have been the most precise, you cannot just hand-wave away the literature on teaching in text citation to middle schoolers and high schoolers which suggests a sizeable proportion of our readership have encountered it. — Wug·a·po·des​ 21:15, 1 September 2020 (UTC)[reply]
"Attribute your arguments to sources" is not the same thing as "use (author, year) style"; indeed, the crux of this RfC is the citation style to use, not to forego citations entirely. From your first ref, table 2 seems to include an example of numbered references. It also says about a third of science faculty think students have had at least moderate practice (...) using a standard citation style (35%); although what faculty thinks is different from the reality, and a "standard citation style" is not necessarily (author, year). As to the latter arguments, whether resources are available in libraries for motivated students is irrelevant to the question of whether the majority of students will use them.
Also, this tells us about US students. I am fairly sure that science fairs (for instance), cited in your ref as a context where proper citation is needed, are not a thing in the UK (they certainly aren't in France). English-language-Wikipedia is not US-Wikipedia (if anything, by population, it would be India-Wikipedia). TigraanClick here to contact me 09:01, 2 September 2020 (UTC)[reply]
It's obvious you didn't even read the paper. Table 2 isn't about in text citations and the paper explicitly says that two sentences prior: The presence and completeness of citations in the reference page at the end of the report was evaluated using the rubric in Table 2 (emphasis added). The examples are numbered examples, not examples of numbered footnotes. If they were meant to be examples of numbered footnotes, we wouldn't expect the authors to suddenly switch from numbered to non-numbered footnotes for level 3 despite keeping the same bibliographic citation. If you want the table on in-text citations, you should read Table 1 which is conveniently titled "in-text citations". Yes, faculty may not be the perfect survey group, but what evidence have you presented to support your claims that their perceptions are disconnected from reality? I doubt the connection is as tenuous as you suggest given that faculty perceptions are in line with the other results in the paper as well as the independent examples I provided.
I also suggest you read the Wikimedia pageview statistics by country which contradicts your claims about readership. We had 3 billion pageviews from the US last month which is the plurality of our 9 billion page views. India constituted 700 million, and the UK 800 million, so I'd like some evidence for you're claim that we're the India-Wikipedia, especially considering less than 11% of India's population speaks English. Further, the Ladysmith Library example I provided is from British Columbia, Canada and was chosen specifically for its representation of a non US perspective. Have I done a complete literature review and survey of international curricula? No, of course not; I have other things to do. If the evidence I've presented does not satisfy you, I suggest you do your own research to support your position instead of trying to force an argument from ignorance. You've made two claims that are easily shown to be false, so I simply do not trust your intuition. — Wug·a·po·des​ 20:30, 2 September 2020 (UTC)[reply]
If the list of references at the end of a paper is numbered, obviously the in-text cite marks are numbers rather than author-year. (Having author-year cite marks and giving the ref list as a numbered list by order of appearance would make no sense.) The table examples are numbered at the two locations where multiple refs are given, but I agree it does not prove conclusively that authors intended to demonstrate a numbered ref scheme.
Even if "35% of faculty think students have moderate practice using a standard CS" implied "35% of students have moderate practice using a standard CS", that in turn means neither that the majority (51%) of students have practiced a standard CS, nor that said standard was (author, year). My remark about faculty perceptions was intended as a concession that things might be better than faculty perceives (because faculty might expect higher standards of students than what would suffice).
As to the country viewing stats, I admit I am somewhat surprised, but my main point was that even if US page views were 90% of all traffic it would not warrant aligning Wikipedia practices on US practices.
I do not have a position on the RfC precisely because I have not seen evidence that footnotes refs are more or less user-friendly than (author, year). If you had shown that (author, year) is something that a large fraction of US students use or read during high school (or at least is significantly more common than numbered references), it would not be a direct proof (says nothing about the situation outside US, more common ≠ better for UX, etc.) but it would have moved me to oppose because every other argument I have read here is anecdotal evidence. I do not think that your refs show that, but at least I commend you for trying to bring facts to the table. TigraanClick here to contact me 10:34, 3 September 2020 (UTC)[reply]
  • Oppose Wikipeda does not 'move forward' by growing a more standardized and formal style, it moves foward by increasing it's scope along with the accuracy and verifiability of the information contained within it. That end relies on encouraging any potential editor to contribute, and anything that may potentially erodes or discourages that contribution, must offer something significant and meaningful in return. This is indeed a very rare form of citation style, but it's not difficult to comprehend and with thousands of pages crying off for references why on earth would we wish to erode the variety of ways in which it can be done. While I do understand the urge for a more unified style, I don't think the case is made for removing this option. Mighty Antar (talk) 16:04, 1 September 2020 (UTC)[reply]
  • Oppose. I would add the word strong, but I don't think that sways closing admins, and the strength of my support for WP:CITEVAR is, I hope, pretty well known. In a perfect world, the Wikipedia would have a house style, but with citation bot and its operators causing ongoing disruption,[1] this is far from a perfect world, and we should not do anything that gives more authority to bots than to readers and new editors. Every new editor will be familiar with a different style, and many existing editors (indeed, Featured articles) use inline citation styles that are common to that content area. In the current environment, this proposal would simply lead to more bot control, disruption, and errors introduced by bot operators. I strongly oppose any move to take citation style away from the editors who write articles, and I equally as strongly hope that these bot issues will subside so that someday we might be able to work towards a house style, without disruption. SandyGeorgia (Talk) 16:16, 1 September 2020 (UTC)[reply]
  • Support: As an academic, I've never liked the parenthetical style, anyway, but I find it to be awfully distracting and rather disastrous on an online encyclopedia, where it would be easier to link a user to an in-line citation than otherwise (I mean, as a user, I don't have time to check every reference just to find, say, "Public, John Q., et al." at the bottom of the page; and that's what parenthetical style always becomes, ultimately. Still, SandyGeorgia has a good point, and I should hope that we can continually work toward a general house style that can be standardized for all users. — Javert2113 (Siarad.|¤) 16:54, 1 September 2020 (UTC)[reply]
  • Strongly support: I find the reference styles easy to learn and the superscript blue numbers reveal the reference's text by putting the cursor atop it. A reader can ignore the superscript numbers or use their cursor and easily see the pertinent sources. Using a style that is handy for typewritten on paper essays seems to be avoiding the advantages of Wikipedia. I am not an expert on all the techniques for references, but I have learned a lot, enough to use short format and then full format in a separate list for long articles on major novels, and get them to link together as easily as the superscript number links to the Reference list. I find that to be a good way to add the references, and it pushes me to find the complete reference, including the year, the isbn if published after 1970, the journal name if it is a journal. Typing a reference in short form in parentheses creates the problem of finding the full length reference somewhere in the article, and hard to take advantage of any online copies of the reference. Making it standard to use ref and /ref seems logical to me. --Prairieplant (talk) 17:37, 1 September 2020 (UTC)[reply]
  • Support Time to get rid of the annoying things. Only in death does duty end (talk) 17:43, 1 September 2020 (UTC)[reply]
  • Support. As a sort of new-ish editor, the lack of a single standard reference style when I began editing Wikipedia was by far one of the most difficult parts of the project to adapt to. I think that, overall, WP:CITEVAR increases rather than reduces the barriers for new editors. Every time I wanted to contribute to a different article, I was faced with learning a new citation style to match what already existed, and it was very difficult to identify how the different options compared to each other. This proposal, obviously, would not solve that problem, but I mention it to support the idea that allowing many options does not by definition make referencing easer for newcomers. The fact that Wikipedia theoretically allowed inline/non-footnoted citations in no way simplified my experience of learning to contribute, even though inline parenthetical citations were my 'native' format in my academic work; for a while I didn't even know it was allowed, and when I did learn, it increased my confusion substantially about how to approach citations. I support deprecating non-footnoted citations, by saying they are not preferred and that editors are encouraged to convert them. I would also support adding more functionality to the reflist template, such as allowing sources to be listed alphabetically or by date. I would also support a change in documentation about WP:CITEVAR to express to new editors the ideas I've seen described in this discussion, that variation in citations is meant to allow a lowering of barriers, rather than a raising of standards. The lowering-of-barriers interpretation on CITEVAR could be emphasized by, for example, describing a "minimal viable citation" (which I'd imagine is, 'the plaintext you'd list in a normal bibliography, but inside <ref> tags'). ~ oulfis 🌸(talk) 21:52, 1 September 2020 (UTC)[reply]
I want to emphasize that I support this proposal as a new editor who is an academic specialist accustomed to inline parenthetical citations (the kind of person I see many saying would be scared away by a ban on inline parentheticals) and that I support it because fewer options would have given me a smoother learning experience by making it clear what I was actually supposed to learn. It was totally baffling that a non-footnoted citation could be acceptable, when everything I knew from using Wikipedia as a reader suggested that the little clicky blue numbers were the standard. ~ oulfis 🌸(talk) 22:07, 1 September 2020 (UTC)[reply]
  • Support. They're already effectively depreciated. In addition, we aren't a scientific journal. Inline citations are meant for highly academic discourse where instantly checking sources is top priority. We are an encyclopedia, where the citations are meant for other editors more than readers in the main. Adam Cuerden (talk)Has about 7.4% of all FPs 22:00, 1 September 2020 (UTC)[reply]
  • Support When citations are done this way, it makes it a lot harder to find if the information is true that required the citation in the first place. Andrew nyr (talk, contribs) 22:02, 1 September 2020 (UTC)[reply]
  • Support - favoring the second option. I publish papers universally using parenthetical citations, and on paper it's fine, but it really is a bad fit for Wikipedia, where there are several superior options available that are not available in print. I feel it's best if we discourage the practice here. Dyanega (talk) 22:48, 1 September 2020 (UTC)[reply]
  • Support phasing out parenthetical citations and tightening MOS accordingly. Footnotes are more reader-friendly because they do not break the flow of the text and are automatically linked to the full citation, and footnotes are more editor-friendly because they eliminate unnecessary copy-paste jobs and manual cross-checks, as well as inevitable errors, to the benefit of readers and new editors who can more easily be taught a single consistent way of formatting references. (WP:CITEVAR causes unnecessary discussion and diverts attention to technicalities rather than article content.) While we don't have to strictly adhere to an outside style-guide or nuke every parenthetical citation on sight, it would be to everyone's benefit to universally establish footnotes—a consistent and easily accessible style. ComplexRational (talk) 01:23, 2 September 2020 (UTC)[reply]
  • Strong support let's not make it any harder on our readers than it already is. Ed [talk] [majestic titan] 02:02, 2 September 2020 (UTC)[reply]
  • Support per nom. Cbl62 (talk) 02:35, 2 September 2020 (UTC)[reply]
  • Support deprecation. UpdateNerd (talk) 05:40, 2 September 2020 (UTC)[reply]
  • Slight Support. Thank to you the nominator for providing the example of Actuary as an article using the citation style which I don't believe I've seen in my years on this site. I agree that the style looks messy. I don't think it will have any great effect pushing away new contributors - so long as those in the new article pipeline are not overly harsh on incorrect citation styles - and actually a citation style as archaic and unusual as this one might equally push away experienced contributers who might have no idea why this one article is so different from the rest. // Lollipoplollipoplollipop :: talk 07:11, 2 September 2020 (UTC)[reply]
  • Oppose deprecation. As many said, it is not our business to limit and constrain contributions. This style actually promotes well referenced and verifiable writing. Personally (being an academic) I find it readable and I actually prefer it (more accurately, I prefer the "first time mentioned" referencing, but this is close). --Muhandes (talk) 08:23, 2 September 2020 (UTC)[reply]
  • Support preferred style being footnotes but not making parenthetical cites "wrong". I personally strongly dislike parenthetical cites but it's not unreasonable for somebody to prefer them. And what I don't want is somebody who contributes good content turned off from editing because of grief they catch over their citation style. This is why Wikipedia doesn't have a set citation style: we value substance over style. That said, it should be perfectly fine to change from parenthetical to footnotes if an editor thinks it improves the article: the Actuary example is a perfect candidate for improvement by change of citation style. But, if somebody objects, then it should go the traditional route: talk page and if the discussion gets tied up with no clear consensus, then the current style should prevail. Jason Quinn (talk) 09:31, 2 September 2020 (UTC)[reply]
  • Support Inline citations make an article far less readable. A lay-reader primarily needs the article to be accessible, and even be able to scan it quickly. Lay-people only need to consult the references occasionally –and Wikipedia is primarily for lay-persons. Deprecation should be applied lightly though! As best practice rather than a requirement for contributors. I feel there should be a guideline on this topic, rather than have articles like Karlheinz Stockhausen which desperately needs fewer inline citations, but has no consensus to make the change entirely because "WP guidelines don't require it". –DTysen (talk) 11:34, 2 September 2020 (UTC)[reply]
  • Oppose - the nomination, and many of the supports, seem to be little more than WP:IDONTLIKEIT. I very rarely come across an article referenced this way, let alone new ones, and a very small minority doesn't justify a ban purely on personal taste. — O Still Small Voice of Clam 19:14, 2 September 2020 (UTC)[reply]
  • Conditional Support - this is a good idea, will improve readability, and improve consistency. That said, let's try not to be WP:JERKs if people slip into old habits, and offer guidance (tools? bots?) to help editors fix the format. Shooterwalker (talk) 19:25, 2 September 2020 (UTC)[reply]
  • Strong Oppose, per Wugapodes, DGG, Clayoquot, and several others (including Tigraan's comment, which questions assumptions made by even Opposers). This reeks of WP:IDONTLIKEIT and falls into the trap of assuming that what WP editors are most used to using is magically what's best. I'm an academic who uses inline parenthetical citations professionally and find it neither distracting, nor a disruption to flow, nor a style that leads to laziness in leaving out crucial info like page numbers, nor a ton of other personal preferential and/or anecdotal claims by Support !votes/voters. Finally I think removing a perfectly acceptable citation format will only limit new user participation; it certainly isn't going to improve the quality of citations overall, since citation quality is more about inclusion of information than it is about the format of that inclusion. Short of actual data showing what readers want, such arguments should be disregarded. What we're left with is arguments about what citations should be/convey, and in such a discussion, I don't see a compelling reason to eliminate inline parentheticals. --Pinchme123 (talk) 19:54, 2 September 2020 (UTC)[reply]
  • Support in weak form. I agree that in order not to discourage new editors, it should continue to be possible to use inline refs for new articles and edits. If WP (1) established linked refs as the preferred option and (2) therefore allowed (or even encouraged) the conversion of inline refs to linked refs, I can't imagine many technologically unsophisticated editors objecting to the resulting change. IF this is once agreed here, I don't see the need to establish a separate consensus on every page; the conversion should be noted on the talk page with a link to the standards page, however. Clean Copytalk 20:29, 2 September 2020 (UTC)[reply]
  • Support – Just because CITEVAR exists does not mean we can't change it or get rid of it. This format may work for academic publications but, in those settings, the author is at times offering original analysis and original research (OR), for which citation is not required. We, by policy, prohibit OR. This means that, by way of WP:V, we require a LOT more citations to be placed in text. Footnotes are the only way to make sure the citations are not distracting from the prose. Another problem is that we are not a print encyclopedia and our articles are constantly changing. This makes in-line parenthetical citation styles unworkable and almost impossible for improvement. This citation style is a form of WP:OWN and has been used to fend off editors from making improvements. Citation templates in the age of the Visual Editor are extremely easy to learn how to use. I learned how to use them in less than 2 edits. The Visual Editor may even be the reason I joined Wikipedia and continued to edit for so long. Footnotes work! They work so well that considering any other format as a better option moving forward, even as an exception, is nonsense and not going to help us build the best encyclopedia we can. All articles using this format should be changed to footnotes style without any prejudice levied against the editor who in the past or future uses them. If a sourced article on a notable subject is submitted with this format in use, the article should be accepted and then changed to footnotes. --- C&C (Coffeeandcrumbs) 00:07, 3 September 2020 (UTC)[reply]
  • Support Below the reference line, I don't care what style gets used. Above the line however, its a different story. Parentheticals are messy and impede readability. If you don't link in-line and the full citations, it can be difficult to find sources and there is a much greater risk of outright forgetting the full citation than if footnotes are used. I've seen people bring up citation styles like Bluebook (aka legal citations) to justify the continued usage of the parenthetical policy. However, Bluebook citations are footnotes, so the above they don't cause the above the line issues of parentheticals. Additionally, the types of sources you would use for legal articles have unique citation information that would be difficult to reflect with a standard citation. This is not true of parenthetical citations. I've seen some people argue that parentheticals are easy to use for new members. However, its really not that difficult to type in <r.ef>source</r.ef> and every editor has a cite tab in the editing screen which will automatically create citations if you enter the information. Spirit of Eagle (talk) 01:18, 3 September 2020 (UTC)[reply]
  • Support – In addition to all the other reasons, reducing the number of citation styles makes it easier to merge articles or move sections from one article to another. We should deprecate, but we should invite newbies to use it if the are comfortable with it and then ask for help in converting to a more acceptable style. -Arch dude (talk) 01:27, 3 September 2020 (UTC)[reply]
  • Support per the arguments already made above regarding readability, consistency, and the fact that we're a digital encyclopedia, not a paper encyclopedia nor an academic journal. Some1 (talk) 05:58, 3 September 2020 (UTC)[reply]
  • Strongly Oppose - I've written for many sources which have strong style guidelines, and which enforce them. Wikipedia is not one of those, and citations are a glorious mess. I cannot express how strongly I am against the idea that only documents which are online are valid citations, which appears to be the logic behind one of the arguments of some supporters. If, in the case of a particular article, inline citations cause that particular article to become unreadable, that's something to thrash out in the GA or FA evaluation. It's very much not a priority for all articles, particularly in the destubification stage. AKAF (talk) 06:06, 3 September 2020 (UTC)[reply]
  • Weak oppose - per Wugapodes. Parenthetical style is better for new contributors, worse for readers.
Given it suits some highly academic articles just fine, it should be kept as a valid option to lower the friction for new users. --Spacepine (talk) 08:56, 3 September 2020 (UTC)[reply]
  • Support any and all steps towards standardisation. We already ask that additions to existing articles retain existing citation styles, so we're already asking many new users to learn a new style. It is far less onerous to expect everyone to learn a single house style than to expect everyone to learn a multitude of different styles dependant on what article they happen to be editing. Lowercaserho (talk) 09:09, 3 September 2020 (UTC)[reply]
  • Oppose per DGG and others. What matters most is that the article has citations and the citations be usable. You alienate a lot of people otherwise. Dennis Brown - 2¢ 09:15, 3 September 2020 (UTC)[reply]
  • Support having a consistent citation style, towards which this proposal is a small step. Too much is said here about the needs of editors, but Wikipedia doesn't exist for the editors; it exists for the readers. Allowing a mass of different styles is like using a different style on each page of a book. We should take a more professional approach to our structure. Zerotalk 15:49, 3 September 2020 (UTC)[reply]
  • Support As long as we are saying this is "deprecation", so that 1) we elimination policy/guideline/MOS support for the style (though retain enough to establish that it was once supported but now deprecated) 2) existing articles with the citation are in no immediate rush to be fixed and that changing a style on an article still needs to be subject to discussion per WP:CITEVAR) and 3) only after a separate RFC to establish some process/deadline to actually go through and set sunset periods/deadlines after which editors can go through and start changing the paren refs to citation template versions. Basically, we just don't want new articles and new editors to use this style. --Masem (t) 16:02, 3 September 2020 (UTC)[reply]
  • Support since footer citations are the better choice Germartin1 (talk) 21:03, 3 September 2020 (UTC)[reply]

Arbitrary break 4 (citations)

  • Oppose. We should be able to write articles in a text edit mode without being required to interrupt typing/train-of-thought to reference various arcane sets of template syntax rule sets. Dcattell (talk) 19:23, 3 September 2020 (UTC)[reply]
  • Support. I mostly use {{sfn}} citations, but others like <ref> style citations. Either way, the reader sees text that is not cluttered up with citation details, but they can click on a link like [12] to see what is being cited. With text-type parenthetical citations the reader sees cluttered text, and the clutter may just be an imaginary source added to make a junk article look more authoritative, as in:
The Riverside Garage Girls are the sharpest prog electro rock band in the north city (Janssens 2020, p. 169).
Text-type parenthetical citations are a relic of clumsy old-style print citations. They have no place in Wikipedia. Aymatth2 (talk) 20:58, 3 September 2020 (UTC)[reply]
  • Strongly Oppose. Clearly prejudicial to offline sources Horatius At The Bridge (talk) 22:23, 3 September 2020 (UTC)[reply]
  • Oppose. Solution in search of a problem. Given that WP is wide open to many different citation styles, there is no particular reason to exclude this one. Wasted Time R (talk) 22:29, 3 September 2020 (UTC)[reply]
  • Support. When looking at the bibliography section I find it useful to be able to identify where (or if) the books are used in the article, this is quite easy to do if there is a footnotes section, but not if the article uses this citation style. EdwardUK (talk) 00:03, 4 September 2020 (UTC)[reply]
  • Support, per EdwardUK. Having the footnotes all tidily at the bottom of the article and being able to jump back up to them inline is useful for the reader, and ultimately it's the reader's ease we should be thinking of. Horatius At The Bridge's oppose makes no sense - whether a source is offline or not has no bearing on whether citations in parenthesis are used. I have cited dozens of offline sources quite successfully using ref tags and sfn-based reflists; conversely, the hideous beast that is Actuary uses parenthetical citations to cite websites. ♠PMC♠ (talk) 04:21, 4 September 2020 (UTC)[reply]
As per AKAF above: " I cannot express how strongly I am against the idea that only documents which are online are valid citations, which appears to be the logic behind one of the arguments of some supporters.." hope that helps you to understand my position a little better Horatius At The Bridge (talk) 11:17, 4 September 2020 (UTC)[reply]
Not really. As I said, offline sources are not solely cited by people using parenthetical citations, and parenthetical citations are not solely used to cite offline sources. The validity of offline sources (on either side) is a red herring that distracts from the real issue at hand, which is whether or not to continue to allow the use of a cluttered, confusing citation style. ♠PMC♠ (talk) 07:28, 5 September 2020 (UTC)[reply]
That presumes that the style is cluttered and confusing, i.e. it is begging the question. Some readers want to see the provenance of an idea on the spot; some know the art of skimming and can read around parenthetical cites almost seamlessly. Given how little serious research has been done on the supposed focus of Wikipedia, the reader, we have absolutely no verifiable (in the factual sense, not Wiki’s hijacking of it) idea whether these are a net plus or minus or not from the reader’s perspective. Qwirkle (talk) 10:25, 5 September 2020 (UTC)[reply]
  • Oppose. Firstly, if the number of articles which utilize this method is as vanishingly small as the OP and others have claimed, then how much of an issue can they pose to the readership? Secondly, though the Harvard method is certainly not my preferred style, and in encountering one or two of these articles I have at first found it a bit offputting, when I laid my prejudices aside, I found them pretty easy to read, and not only that, I realized they actually have an advantage in that one can see at a glance exactly who is being cited and how often, instead of having to hover one's mouse over the links to find out. What's so terrible about that? Additionally, I found the argument of one user above that superscripted cites can make mathematical articles confusing to be persuasive. Finally, I'm concerned that deprecating the style might discourage some users from contributing, or worse, drive some away, given that people can be very attached to their preferred formats. And after all, it's not as if we are going to suddenly have a consistent style if we get rid of this one - people have all kinds of different approaches within the accepted parameters, and even the citation templates themselves yield inconsistent formatting (such as presenting dates near the beginning, in parenthesis, and having them near the end, with no parenthesis etc). I can, I think, accept the notion that we have a preferred style, but deprecating styles that some folks just appear not to like doesn't seem like such a great idea to me. Gatoclass (talk) 12:06, 4 September 2020 (UTC)[reply]
    Hovering the mouse only works if you have popups enabled; many editors enabled popups so long ago that they don't realize it's not a default. So the comparison is actually between having to click on the footnote and be taken to the bottom of the page, and then having to find your way back (many readers won't know to hit alt-left-arrow on their browser), or instead just seeing the citation right there. Like Johnbod I never use parenthetical citations, but to be honest, for those readers who care about what a statement is cited to, parentheticals are probably the most convenient form of citation, not the least. Mike Christie (talk - contribs - library) 14:29, 4 September 2020 (UTC)[reply]

Discussion (citations)

Question: what happens to a new editor now who is adding good content on a page using a different citation style than what is in use on a page? --Dirk Beetstra T C 11:31, 3 September 2020 (UTC)[reply]

In my experience, editors who care about that article will convert the reference to the article's established style. -- Michael Bednarek (talk) 12:18, 3 September 2020 (UTC)[reply]
Michael Bednarek, that is what I mean. So if this passes, instead of a conversion of parenthetical citations to <ref>-tag style or vice versa (depending on established style), such articles would now just be converted unidirectional (hence, always removing the parenthetical citations). The only difference may be that (if this passes) we will see that articles that were created with parenthetical citations would be moved over to <>-ref tags when someone feels like doing so. Dirk Beetstra T C 14:44, 3 September 2020 (UTC)[reply]
There are many different interpretations above of what this extremely vaguely worded proposal would mean - I'm not sure your one has actually been articulated previously, but no doubt many supporters think this. Other views expressed above by "supporters" include: a) there should be talk page consensus first, b) talk page objections can stop a conversion, c) a bot will automatically convert articles, d) if coming through Afc, the article would not be allowed into articlespace without conversion, e) articles on some subject areas should be exempt, perhaps after individual discussions. Many supporters only support "deprecation" in new articles - old ones to be left as at present. These options by no means exhaust what supporters support. Johnbod (talk) 15:54, 3 September 2020 (UTC)[reply]
Question: isn't this proposal consistent with both the wiki mark-up and the visual editor? Both editing options provide the mechanism to use footnotes, with no mention of parenthetical citations. For instance, the wiki markup editing box uses the imperative: "Cite your sources: < ref > < /ref >", while the Visual Editor explains in some detail how to provide footnote citations: Getting started: the visual editor's toolbar and Editing references. If the software is already set up on the basis of footnote citations rather than parenthetical citations, then shouldn't the policy be in favour of footnote citations? Isn't that the least confusing option for a new editor, to follow the citation system set out by the wiki software itself? --Mr Serjeant Buzfuz (talk) 04:54, 4 September 2020 (UTC)[reply]
Answer: No. Although I don't like & never use parentheticals myself, one big advantage they do have, for technically nervous new editors already used to them, is that they are pure text and don't need any help from the software. I'm guessing you've never run any training wikithons etc, or you would know how daunting most first steps editors find all the templated systems. Johnbod (talk) 12:03, 4 September 2020 (UTC)[reply]
I second Johnbod's point about newbies. I too have helped run editathons for new editors, and confirm that anything which makes their tentative and nervous efforts easier is a Good Thing. Tim riley talk 21:35, 4 September 2020 (UTC)[reply]
  • The profusion of differing interpretations above is one of my main worries about this proposal. I could fairly comfortably support a slightly limited form of Beetstra's proposal (the main difference I can think of being an exception for the fairly uncommon situation where an article needs to contrast different versions of the same person's views on a topic, in which case being able to differentiate inline between, say, Eek (2019), Eek (2020a) and Eek (2020b) may be the clearest way of doing so), but "supports" seem to range right through from something like Beetstra's proposal under very limited circumstances right the way through to insisting on {{cite}} complete with all parameters under all circumstances. And the "opposes" seem scarcely less varied in what precisely they are opposing. I rather sympathise with whoever has to take a decision on the screeds of opinions above - whatever they come up with is likely to get more vociferous criticism than agreement and, indeed, my sympathy for them won't necessarily extend to their decision. PWilkinson (talk) 11:38, 4 September 2020 (UTC)[reply]
    @PWilkinson and Johnbod:, my question was more specific. Now you obviously have editors who use parenthetical citations on pages where <ref> tags are used, and ‘’vice versa’’. Now, I ‘’presume’’ that these newbies don’t get crucified, quartered, or beheaded. Now, we are going to, if this passes, deprecate parenthetical citations. Deprecate, not forbid. Why is the oppose side soooo afraid that they, as well as newbies who may be used to parenthetical citations, will be crucified, quartered and beheaded?
    I turn inline external links into plain external link-refs. I do not take the effort of turning them into parenthetical citations or full cite refs. I haven’t been crucified, quartered or beheaded. Some came, saw, and made hem into cite-template-refs. Or not. Dirk Beetstra T C 19:35, 4 September 2020 (UTC)[reply]
And what does "deprecate" mean exactly? In practice, the citebandits who have already been roaming WP for years, illegally descending on articles and converting them to their preferred style (usually sfn these days) will make short work of any articles they find with parentheticals, often introducing mistakes of various kinds. They will soon be looking for the next style to ban. WP:CITEVAR already rightly bans mixed styles, as you recognise above. It is clear that many supporters think that no new articles with parentheticals will be allowed, and many opposers fear other styles will soon be attacked if this passes. Both groups are probably right. Johnbod (talk) 21:43, 4 September 2020 (UTC)[reply]
More or less what Johnbod has said, except that I have rather more sympathy with what you are suggesting (and what I think CaptainEek is intending underneath all the vagueness and attempted clarifications) than I gather Johnbod does. We have quite a number of enthusiastic but relatively inexperienced Wikipedia editors who take the most advisory of guidelines, intended to be applied with care and only in particular circumstances and ways, and treat their first hurried reading of it as unbreakable Holy Writ, applicable universally and literally. In this case, I think that most existing articles with inline parenthetical citations probably would be improved if those citations were either surrounded with <>-ref tags or modified into {{sfn}} templates - but also that a number of those articles will contain lesser or greater numbers of such citations which will require greater sensitivity to preserve the sense and grammaticality of the article text, and some cases where this is effectively impossible (and so such citations are best kept); and also that a number of newbie editors will find it easier at least at first to be allowed to use inline parenthetical citations without communal disapproval, keeping the need to worry about tags or templates to a reasonable minimum and letting them concentrate on writing article text until they gain greater Wikipedia proficiency. PWilkinson (talk) 12:49, 5 September 2020 (UTC)[reply]
PWilkinson, I just don’t expect that editors will be really scared away because they are creating articles in ‘the wrong citation style’. Just like now, when a new editor adds a different citation style than established in an article. They will be informed maybe, but more likely someone will just come and convert it. Yes, there will be some editors who overzealously push a guideline, but I have seen other editors trouting them around more than joining the dramah. But maybe that is just me. Dirk Beetstra T C 13:00, 5 September 2020 (UTC)[reply]

Parenthetical citation closure

Before starting the close rationale, I would like to thank the participants of this discussion for putting forth their well-reasoned arguments. The substantial majority of people who commented provided rationales for why they thought as they did rather than bare "votes", and while clearly some editors on both sides feel rather strongly about this matter, discussion did not degenerate into incivility and sniping. That is much appreciated.
While discussions of this nature are not determined by counting hands, the level of support and opposition is not entirely irrelevant either. In this discussion, support for the proposal by the standard formulation (support/(support+oppose)) ran to approximately 71%. That is a ratio at which rough consensus behind a proposal is generally considered to be possible.
In this instance, both supporters and opposers raised valid, clearly outlined concerns. Supporters primarily raised the concerns that this citation style is (for Wikipedia) nonstandard, that it makes it more difficult to distinguish between references and article content, and that it is confusing to readers used to the more common methods of referencing. Supporters sometimes called attention to existing articles in which they believed that this style of citation lowered their quality (actuary being a commonly cited example). Opposers raised concerns that newer editors may be discouraged by being told not to use this style, that some freely-licensed works may need work to change reference styles if they are to be used wholesale, and that some experienced editors who prefer this style may also be discouraged by its removal. Many opposers found the comments made by Wugapodes and DGG to be particularly on point.
Both sides raised valid, well-reasoned arguments in support of their positions. In such an instance, the substantial level of support over opposition indicates that a substantial majority of the community is dissatisfied with this style of referencing. Accordingly, this discussion has reached a consensus to deprecate inline parenthetical references. Some important points raised during the discussion and regarding implementation details are:
  • This discussion supports the deprecation only of parenthetical style citations directly inlined into articles. It does not deprecate the use of the entire citation format when it is used within <ref></ref> tags, nor the use of the {{sfn}} and {{harv}} templates.
  • This discussion is not an authorization to use bots, scripts, or other automated tools to change existing articles en masse. That should not be done without a separate consensus behind it.
  • This discussion provided only a rough proposal for particular wording changes to relevant policy, specifically WP:CITEVAR. Discussion should take place at relevant policy pages, especially WT:CITE, to decide on changes to wording, and if need be followup requests for comment may be initiated. Those discussions should focus on how, not whether, the wording changes should be made, as the latter decision has already been made here. Additionally, WP:PAREN will have its current text replaced with an explanatory note and be marked historical.
  • The point was raised by several, including many who support this change, that articles should not be declined at AfC solely on the grounds of using parenthetical citations. This assertion did not receive any substantial opposition.
  • At existing articles, discussion of how best to convert parenthetical citations into currently accepted formats should be held if there is objection to a particular method. There is no rush and no need for edit wars. However, once again, discussion should center around how rather than whether the change is to be made, as the latter is decided here.

Once again, many thanks to the participants here for your well-considered thoughts and exemplary conduct in this discussion. Seraphimblade Talk to me 18:13, 5 September 2020 (UTC)[reply]

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

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)[reply]

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)[reply]
@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)[reply]
@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)[reply]
  • Comment – there are various ways to link titles in cite templates, that is, apart from |url=,
    • |chapter-url= – for chapter titles
    • |title-link= and, alternatively, a wiki-link of the title
    • |series-link=, for titles of series
    • etc
I assume that these other methods of linking, and not exclusively |url=, are covered by this RfC too. --Francis Schonken (talk) 05:23, 24 August 2020 (UTC)[reply]
@Francis Schonken: your comments encouraging specific other people who have expressed opinions elsewhere to bring them here look like WP:CANVASSing to me. —David Eppstein (talk) 06:46, 24 August 2020 (UTC)[reply]
No intention to canvass specific people, just trying to get the discussion in one place, as I have done here too. Anyhow pinged the other participant in that talk discussion too, to avoid a perception of unequal treatment. Note that that other participant in that talk page section, i.e. Trappist the monk, had already been pinged here (by Headbomb), without anyone considering that, apparently, selective pinging inviting to participate here. --Francis Schonken (talk) 07:04, 24 August 2020 (UTC)[reply]
I was 100% unaware of this discussion until now, but that it quite possibly my own incompetence, I have added a link on the citation bot talk page. AManWithNoPlan (talk) 20:52, 24 August 2020 (UTC)[reply]
@AManWithNoPlan: you were notified of this discussion (via ping) on 5 August; and I posted a link to this ongoing RfC on the bot's talk page on 22 August. --Francis Schonken (talk) 04:14, 25 August 2020 (UTC)[reply]
I would like to emphasize that despite the fact that I was invited to this discussion, it didn't influence me. I already had unfinished replies laying around in my drafts folder for more than a week and was just lacking the time to finalize them.
As a general remark I would like to see much more constructive and solution-oriented thinking, assumptions of good faith, and less wikilawyering. It's not good for our communication culture and not for the project.
--Matthiaspaul (talk) 13:44, 1 September 2020 (UTC)[reply]

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)[reply]
  • Yes, to a free copy of the source or the closest thing to it. "Click on the title, get to the source" is something every reader knows and expects, and we should provide it. If there is a free (non-copyvio) version of the source, that should be linked under the title. If there isn't, then a copy of the source that provides a free preview, if available (e.g. Google Books or Amazon Books). Or, to an "official" copy of the source, if no free copy is available (e.g., whatever the DOI points to). Or, to a library catalog entry, to help the reader obtain the source (e.g. the Worldcat entry). Whatever we can do to get the reader to the source, that's what should be linked under the title in a citation. Lev!vich 01:47, 5 August 2020 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Yes, the title should link to the "best" (most useful, free if available, etc.) source if it is online. I don't see an issue with duplicate links: if someone knows/cares about online identifiers and wishes to visit those directly, those links are available for them to specifically click on. Human judgment is going to be necessary in many cases to determine the "best" link, and in those cases a human can put that into the url= field; once that is populated, a bot shouldn't remove it even if it duplicates one of the online identifier links. If there is no manually chosen URL, I'm fine with the title being automatically linked to one of the online identifier URLs if one is available. I agree with WAID above that we really shouldn't overthink/overcomplicate this. CThomas3 (talk) 20:30, 6 August 2020 (UTC)[reply]
  • No Wikipedia is an encyclopedia not a search engine. It's the text of articles which is our main output, not the references, which readers pay little attention to. We're already seeing aggressive attempts by bots to insert link-spam; trying to pull readers to their site rather than the competition (e.g. Google Books vs Internet Archive, neither of which wrote or published the books that they are now claim-jumping.) We should not encourage this. Andrew🐉(talk) 11:55, 7 August 2020 (UTC)[reply]
  • yes there should be a link if the article can be referenced online, but not always needed. Whether free to access or not does not matter, but we should prefer free where it can be provided. Graeme Bartlett (talk) 12:00, 7 August 2020 (UTC)[reply]
  • Yes title link to the actual reference used for the citation. No harm in duplication. · · · Peter Southwood (talk): 14:28, 7 August 2020 (UTC)[reply]
  • No — The wikipedia is over-linked as is. A linked title is a link too many. —¿philoserf? (talk) 08:36, 8 August 2020 (UTC)[reply]
  • Yes, and to the specific page in question where possible. Adam Cuerden (talk)Has about 7.4% of all FPs 22:39, 9 August 2020 (UTC)[reply]
  • Titles should be linked whenever there is any online version of the source available that is not a copyvio. If ther is a free-to-read version that is complete, the link should go to that. if there is no fully free version, but there is a version with part of the source free, such as an abstract, the title should link to that. Failing either of those, the title should link to a fully paywalled version. All of that should be true regardless of whether or not the title link goes to the same place as some identifier link goes. DES (talk)DESiegel Contribs 00:57, 12 August 2020 (UTC)[reply]
  • I don't know. For umpteen years I've been linking article names to the source I found it at. An example of my practice can be seen here. Some have been to JSTOR or persee.fr, some to academia.edu, some journals have a website with free copies, such as Bulletin of the American Society of Papyrologists, & some to slightly sketchier sources. (No, none to SciHub, nor do I plan to. At least not yet.) I've always felt this was not entirely right, & sometimes thought setting out a source like JSTOR or doi separately would look more professional; it would match current practice with the ISBN template; of course if I ever submitted an article I largely wrote to the GA or FA process I would have to rewrite it beforehand to use one of these template, so there's that. Lastly, I have to admit that none of the votes above have convinced me to either continue my practice or change it. -- llywrch (talk) 06:36, 12 August 2020 (UTC)[reply]
  • Yes, if there is an a URL link inserted in the template, it should be dispalyed in the title, despite all other identifier. Like that, when you click on the title, you access the link inserted by the editors. --Anas1712 (talk) 00:00, 13 August 2020 (UTC)[reply]
  • Wrong question ... modules should be used to generate urls when there is a full text version, such as |pmc-access or |doi-access. No, there should not usually be any link to a paywalled source in the URL because it does not help our readership, very few people are willing to pay $$$ in order to check a WP reference. (Unless the content can be verified to a preview or there is no other identifier to uniquely identify the source). (t · c) buidhe 03:29, 13 August 2020 (UTC)[reply]
  • Example: I was just reading holocene extinction. I wanted to read one of the sources. The cite ref looks like this:

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

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

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

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

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)[reply]
  • 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)[reply]
  • Not when redundant to identifiers for reasons in my !vote to Question 2 above. Never by a bot because the URL was likely placed there by a human being, who decided that this link was the best link for the reader. A bot shouldn't overrule that human decision. (Note: replacing dead URLs with live or archived URLs is not removing or blanking |url=, and thus could be done by a bot.) Only with good reason by a human - if it's copyvio, if it's a dead link, or if there's some other good reason. I trust humans to make these decisions on a case-by-case basis in a way that a bot cannot. I'm particularly concerned that people will take the time to carefully select URLs to link to, and it'll be erased en masse by a bot. (Which is kind of what led to this bot being blocked in the first place, I believe.) Lev!vich 01:58, 5 August 2020 (UTC)[reply]
    • 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)[reply]
      The reason to have both is what I said in my !vote in #2 above: to always make it so "click the title, get to the source", so the reader doesn't have to think about which of multiple links is the best one to click on. And I know that you've said that we should accomplish that by removing the |url parameter and instead having a blank |url parameter "auto-fill" effectively with the |doi or whatever, but that's not how CS1 templates work, and the maintainers have previously said that it's not how they're going to work any time soon. So until then... Lev!vich 02:04, 5 August 2020 (UTC)[reply]
      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)[reply]
      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)[reply]
      Cosmetic doesn't prevent edits, if other stuff is happening. -- GreenC 15:18, 5 August 2020 (UTC)[reply]
      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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
    What about 'redundant autolinked title links'? -- GreenC 15:18, 5 August 2020 (UTC)[reply]
  • 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)[reply]
    • 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)[reply]
      • But is there any point in flooding everyone's watchlists to remove the URL? WhatamIdoing (talk) 15:14, 5 August 2020 (UTC)[reply]
        So, the hard-coded URL dies or changes. It's trivial to fix the autolinking in the central CS1|2 cfg. But, IABot is going to detect the dead static URL in the individual cite, and add an archive URL. Now we have a cite that is not properly autolinking because there is a dead URL in |url= field taking priority, with an unneeded |archiveurl= that probably should be removed along with the static URL. OR, we can proactively remove the redundant URL to prevent a future mess. -- Green<span style="color:there should be a link on the title (and note that some of the people who voted No were answering a different question, whether |url= should be filled). #093;">C 15:28, 5 August 2020 (UTC)
        Or we could assume that scenarios based on PubMed Central (part of the US National Institutes of Health) going offline, or them not being able to find their own documents when given their own ID numbers, are just not very compelling. WhatamIdoing (talk) 23:20, 5 August 2020 (UTC)[reply]
      • 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)[reply]
        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)[reply]
        Because CS1 updates are basically contingent on User:Trappist the monk deciding it's time to do an update. It's not, in theory, a limitation, but you need to know LUA and to be an admin to update the CS1/2 modules. But this isn't a particularly hard thing to do for those with the skills. Headbomb {t · c · p · b} 18:06, 8 August 2020 (UTC)[reply]
        Ah, but RexxS does know Lua, and is an admin - indeed, when I have a lua problem, I prefer to go to RexxS and not Trappist. --Redrose64 🌹 (talk) 19:44, 8 August 2020 (UTC)[reply]
        Nevertheless, Trappist has put a huge amount of effort into creating and maintaining the CS1/2 modules. That means Trappist has a far better overview of the intricacies and features of that module than I have. I would not feel comfortable editing any of those modules, principally because I would automatically defer to the maintainer of a module to know better than I. The same would apply, for example, with Johnuniq's convert modules. --RexxS (talk) 20:55, 8 August 2020 (UTC)[reply]
        Can you verify if this is autolinking?
        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)[reply]
        @GreenC: I can verify that the citation you quote is linking the title, but I seriously doubt that there's anything automatic about it. You'll appreciate that
        also has the title linked. Does that make the doi redundant? They all link the title to the source, so does messing with those actually benefit the reader?
        What about these citations? Why would we change the first for the second?
        How did this edit benefit the reader?
        FWIW my first degree was in electronic engineering, but that was in 1972 and there were no geeks in those days. :( --RexxS (talk) 22:15, 5 August 2020 (UTC)[reply]
        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)[reply]
        @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)[reply]
        @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)[reply]
        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)[reply]
        And I think your personalisation of genuine issues detracts from the seriousness of the problems. Removing a link from a citation title should not be happening because readers expect the link to be there. You are attempting to brush the issue aside as if doesn't matter. Well it does. Likewise you are not displaying any understanding of the difficulties that ordinary readers experience in trying to make sense of a plethora of different acronyms and symbols. Not everybody is as technically gifted as you and you overestimate the willingness of a reader (who just wants to see a source) to learn jargon designed for use by academics who use it on a daily basis. --RexxS (talk) 21:51, 6 August 2020 (UTC)[reply]
        It's not a question of learning jargon. It's a question of being capable of noticing that something in the reference is linked and seeing where you go when you follow that link. If you can't do that, you also can't use Wikipedia, use the web, or follow links in titles. —David Eppstein (talk) 01:12, 7 August 2020 (UTC)[reply]
        If you'd spent as many years I have teaching adults, especially those as old as I am, basic computing skills, you'd soon revise your "being capable of noticing that something in the reference is linked and seeing where you go when you follow that link. If you can't do that, you also can't use Wikipedia, use the web, or follow links in titles. Giving folks predictable pathways, such as "clicking on a title takes you the source" is precisely how they become able to use Wikipedia, and use the web, and follow links in titles. --RexxS (talk) 16:49, 8 August 2020 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • The bot shouldn't, and a human should only do so to consciously choose to a better/more appropriate link, not because it's redundant. CThomas3 (talk) 20:52, 6 August 2020 (UTC)[reply]
  • Only remove the link if it goes to a deprecated site, (such as copyright violating or dead) or is wrong. Don't bother removing it just because of PMC or DOI or the like. That is just cluttering up watchlists for no benefit. Of course the other parameters can be added even if there is a link in the title. Graeme Bartlett (talk) 12:07, 7 August 2020 (UTC)[reply]
  • Ban bots We can't have bots run by paid SEO editors fighting to insert their preferred links. Per WP:CITEVAR, the issue should be left to discretion of the human editor who actually used the source in question to support some text in the article. Andrew🐉(talk) 12:11, 7 August 2020 (UTC)[reply]
  • If it aint broke don't fix it. · · · Peter Southwood (talk): 15:18, 7 August 2020 (UTC)[reply]
    To clarify: I don't think it is broken and don't think it needs fixing. If the title link url works, leave it alone. · · · Peter Southwood (talk): 10:57, 9 August 2020 (UTC)[reply]
  • It is broke. Let’s fix it. Any redundantly linked title should have the |url= removed. The wikipedia is over-linked as is. A redundant link is a link too many. —¿philoserf? (talk) 08:36, 8 August 2020 (UTC)[reply]
  • The link from the title should never be removed, evven if it is redundant. If, and only if, the template/module will generate this link automatically based on other parameters, |url= may be set to blank, or better to an HTML comment explaining why, but not otherwise. All this is assuming that the article uses CS1 or CS@, of course. DES (talk)DESiegel Contribs 01:08, 12 August 2020 (UTC)[reply]
  • Never by a bot bots should not be going around second guessing decisions made by actual humans. I would support a bot identifying cases that need human attention, but never making these sorts of changes themselves. - Nick Thorne talk 23:54, 13 August 2020 (UTC)[reply]
  • Per RexxS above, the citation title should always link to the most useful online source (barring copyvio). I don't know if there might be cases where there's a good argument for not having the link (unlike Holmes, I don't claim to be able to eliminate all possibilities). But if there is, then it needs to be decided by a human. The link should never be removed by a bot. Boing! said Zebedee (talk) 16:44, 17 August 2020 (UTC)[reply]
  • Don't change, unlike there's an open-source access to the full paper, but that's the purpose of OABOT, so maybe allows in precise cases, but not to generalise to all. The primary policy is to not remove utile information that is already present. The objective of the bots in citation maintenance is to help the wikipedians to add informations and to automatise the search of informations, to make sure the citation is more precise and more accessible. Voilà, voilà. --Anas1712 (talk) 14:42, 18 August 2020 (UTC)[reply]
  • Don't remove title links on the basis that they duplicate identifiers. It is fine to remove a |url= if the template will generate the same link on the title via auto-linking, but not otherwise. − Pintoch (talk) 11:37, 21 August 2020 (UTC)[reply]
    • It's also more than fine to remove links that lead to databases without any possibility of free versions (like pubmed), to paywalled papers (like EBSCO and proxies), to preprints (like arxiv). Headbomb {t · c · p · b} 15:27, 22 August 2020 (UTC)[reply]
      • It's not fine to remove the link to where the editor found their source per WP:SAYWHEREYOUGOTIT. If they found their information at a PubMed abstract article, we should be giving the editor the ability to indicate that via the title link, and we should be giving the reader the opportunity to follow the intuitive link to the source used in writing the text. We should not be having those swept away by the bucketload by a capricious bot. --RexxS (talk) 21:03, 24 August 2020 (UTC)[reply]
  • The content of |url= should be decided on a case-by-case basis, by human editors, not modified by bot – a bot is welcome to address malformed links, permanently dead links etc, but should not modify the intent of human editors. --Francis Schonken (talk) 04:28, 24 August 2020 (UTC)[reply]
  • Never by bot and very rarely by human I cannot think of a good reason for a bot to remove the URL parameter. I cannot think of a reason beyond copyright violation for a human to remove the URL, though I assume there must be some reason I haven't dreamt up :) In general, Rexx's point about having consistently linked titles wins me over, and thus I think this is a good reason to keep titles linked. Humans can always use their best judgement to figure out if a link needs to go, but I see no need to have CitationBot doing that. CaptainEek Edits Ho Cap'n!⚓ 09:17, 24 August 2020 (UTC)[reply]
  • When redundant to identifiers Linking to non-free copies with the title leads to reader confusion when they expect a title link to actually link to something useful. Cannot believe that I was not aware this discussion was going on until now. AManWithNoPlan (talk) 20:44, 24 August 2020 (UTC)[reply]
    • Identifiers are inferior to title links because readers understand and expect title links. Your bot is happy to remove title links that go to pmc urls. Those sort of links – the ones used by the editor to add text – are useful title links, and no reader is going to be confused if they are allowed to follow those sort of links. --RexxS (talk) 21:03, 24 August 2020 (UTC)[reply]
  • Only when identical to other links. There is no point to keep an |url= link if it points to exactly the same page as an identifier-derived link. This is the only case when (automatic) removal of |url= is justified (except for if it would point to illegal contents which always justifies its removal), and this is also the only case for which we actually had community consensus. If |url= resolves to exactly the same page, |url= may be removed by a human after applying editorial judgement, but it should not be removed by a bot because a bot cannot apply the necessary editorial judgement, if the resolver will, with high certainty, resolve to the same page into the long-term future, or if it may change over time. A link pointing only to the same site (like links to the direct document vs. to a meta-page) is not "equal" and must therefore never be considered "redundant", "equivalent", "duplicative", etc., and consequently it must not be removed. (Since some users lump these definitions together semantically, the exact wording is important.) Also, |url= pointing to a non-free or restricted-access resource is never a valid reason to remove a link per our core policy on verifiability WP:V and the principle of WP:SAYWHEREYOUGOTIT. For that reason, also a dead |url= must not be removed (but |url-status=dead be set), as this would invalidate the citation. Of course, if it is possible to replace a (dead) link by a similarly authorative or better live URL, that's allowed for humans (and in some very limited cases it may also be allowable for a few highly regarded bots -- however, not for Citation Bot, which has a long track record of messing up citations and over the years has created way too much damage to the project to still have any credibility, IMO -- the quality of edits is much more important than the quantity). --Matthiaspaul (talk) 21:39, 24 August 2020 (UTC)[reply]
I would like to add that even in cases where the |url= is an exact duplicate of an identifier-derived link, they should not be removed if |archive-url= is given as well (unless citation templates introduce parameters to specify archive links for identifiers as well). Some identifier-derived links are intended to be semi-permanent, but ultimately they are subject to link-rot as well, so it is good to keep archived versions around. --Matthiaspaul (talk) 13:31, 1 September 2020 (UTC)[reply]
  • The bot never; a human might be justified to do so in rare special circumstances. Johannes Schade (talk) 16:26, 31 August 2020 (UTC)[reply]
  • Matthiaspaul says above As a convenience to users who don't know what identifiers are and never click on them, the title could still be linked to this page through (manual or priority-based automatic) auto-linking. I think in such cases removing |url= is OK; the parameter is freed up for some potential other URL, and in the meantime readers see no change since the title still has the auto-linked ID-derived URL. Of course the edit-summary should provide [a link to] a reassuring explanation of this. jnestorius(talk) 14:13, 3 September 2020 (UTC)[reply]
Yes, just in case this didn't became clear in my post above, if |url= points to exactly the same page as provided through an identifier link and there is no |archive-url=, then |url= serves no purpose and can be freed for better uses. (With |archive-url= being present I would not agree with the removal of |url= unless the citation templates would be improved to support archive links for identifier links as well.) What's also a problem is that Citation Bot has been caught to remove |url= also in cases where the identifier-derived links were not identical, but only pointed to the same site (meta page vs. deep link to document) or even to a different site altogether which just happened to contain similar information. This is something that I consider to be disruptive and unacceptable. That's why I pointed out that people have vastly different ideas what terms like "duplicative", "equivalent", or "redundant" mean, and that therefore the unambiguous terms "identical" or "equal" should be used. --Matthiaspaul (talk) 15:34, 3 September 2020 (UTC)[reply]
  • We need a better CS1/CS2 template, if title links are important I think that when no title-link is present, the template should always try to make one. If something-free is not set, then auto-link doi with the assumption that it is not free in the icons. I think wikipedia over links, but if we are going to insist on links, then let us make them just appear by magic. AManWithNoPlan (talk) 14:27, 3 September 2020 (UTC)[reply]

Synchronising short descriptions and Wikidata descriptions

NO
There is a clear consensus against indiscriminately syncing Wikidata descriptions to Wikipedia short descriptions with bots. D1 and D2 are out of scope, as unenforceable by the English Wikipedia editing community; D1 received some support for whatever it's worth. E2 is out of the question; the very idea of it was strongly rejected. There is a clear, albeit not as strong, consensus against E1, as proposed. Discriminate alternatives to E1 (more limited, more selective, more human oversight) may be worth exploring. Usedtobecool ☎️ 11:15, 5 September 2020 (UTC)[reply]

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

Should a bot synchronise short descriptions and Wikidata descriptions? Mike Peel (talk) 21:34, 6 August 2020 (UTC)[reply]

Hi all. Enwp recently gained 'short descriptions', which is "a concise explanation of the scope of the page" (for the background, see the links at Wikipedia:Short_description#History). These are currently a local override for the English language descriptions from Wikidata for 2.3 million articles (1/3 of the articles here), but this may change soon so that only the local descriptions are used (removing them from 2/3 of articles). I think that it is important that the short descriptions and the Wikidata descriptions are kept in sync as much as possible. That is both because the descriptions are most visible on enwp, but also because the English Wikidata descriptions are used in many other places, in particular (from my point of view) in the infoboxes in Wikimedia Commons categories. As such, I am proposing four options for bot tasks to synchronise them, namely:

  1. On Wikidata, option D1: If there is no English description from Wikidata, then import the short description from English Wikipedia
  2. On Wikidata, option D2: If Wikidata has an English description, but it doesn't match the English Wikipedia short descriptions, then replace the Wikidata description with the enwp short description
  3. Here, option E1: If there is no short description here, then import the English description from Wikidata.
  4. Here, option E2: If the short description here does not match Wikidata, then replace the short description here with that from Wikidata.

I started a discussion on Wikidata about the first two, which you're welcome to participate in. There are also discussions on both bot proposal pages. I initially started a thread here at Wikipedia_talk:Short_description#Copying_short_descriptions_to_Wikidata, but discussions on Wikidata led to the bot proposal here, and discussion there in turn suggested an RfC. I assert that these descriptions are too short to be eligible for copyright (which could be an issue since we use CC-BY-SA here but CC-0 on Wikidata) - I've emailed WMF legal to confirm this.

I know that this is a controversial discussion: this thread, and the thread I started on Wikidata, are aimed at starting discussions about how we keep things in sync. I am open coding to up other cross-wiki bot scripts if needed. I think it is in the best interests of both projects to work together. What do you think? Thanks. Mike Peel (talk) 21:34, 6 August 2020 (UTC)[reply]

Survey

I would support D1 and E1 as they are just importing what is available. D2 and E2 could result in a better description being replaced, so a solution to prevent that would be needed. Emir of Wikipedia (talk) 21:38, 6 August 2020 (UTC) (please Reply to icon mention me on reply; thanks!)[reply]
@Emir of Wikipedia: Is there a way to automatically tell which one is better, or would it need a human to check it? Thanks. Mike Peel (talk) 21:48, 6 August 2020 (UTC)[reply]
Better is somewhat subjective, so it would have to be human probably. Emir of Wikipedia (talk) 21:52, 6 August 2020 (UTC)[reply]
  • Support D1 & E1; oppose D2 & E2. Copying to fill empty slots is fine, but automated overwriting is a recipe for fierce conflicts. --BrownHairedGirl (talk) • (contribs) 21:46, 6 August 2020 (UTC)[reply]
  • Comment on D1 and D2: These are Wikidata content decisions for the Wikidata community to decide. Has the Wikidata community delegated its decision-making authority regarding English-language Wikidata descriptions to the English Wikipedia? – Jonesey95 (talk) 21:57, 6 August 2020 (UTC)[reply]
    Indeed, which is why I said "I started a discussion on Wikidata about the first two, which you're welcome to participate in." Thanks. Mike Peel (talk) 11:20, 7 August 2020 (UTC)[reply]
  • Partial Support of E1: Some of the descriptions are poorly written, and others are far too long to comply with our guidelines. I would support importing a limited set of short descriptions for certain categories of articles, like animal/plant species and footballers, where the descriptions can be checked for appropriate length and parsed against category membership here at en.WP. Oppose E2, because local short descriptions are usually better than those at Wikidata, as has been shown at the Wikidata discussion linked above. – Jonesey95 (talk) 21:57, 6 August 2020 (UTC)[reply]
    Jonesey95, Do you have any suggestions on how to identify acceptable short descriptions from Wikidata for this purpose? It could be a useful option if it is sufficiently reliable. Cheers, · · · Peter Southwood (talk): 10:47, 7 August 2020 (UTC)[reply]
    I have populated a few thousand short descriptions, and some categories of articles appear to be pretty consistent in their quality. Sportspeople of various types tend to have reliable short descriptions, as do fossils, for example. A human could identify a parent category on Wikipedia like Category:Association football players, or dig down into a subcategory like Category:English footballers (22,000 articles). Within those categories, exclude articles that already have a short description, then run a report that shows the Wikidata description for each article. A human could look at a report on 1,000 articles at a time, manually eliminate pages with bad Wikidata descriptions, and do a batch import of the rest. It wouldn't be an automated bot process, but I think that once you got the system set up, it would be quick to process many thousands of articles per hour. You could ask on the project page for likely categories. In footballers alone, you could probably add 100,000+ short descriptions in a couple of days. The same process could be used for species, books, movies, and other items where the Wikidata bot that created descriptions had an easy time processing the lead sentence (or whatever information it used). – Jonesey95 (talk) 16:02, 7 August 2020 (UTC)[reply]
    Jonesey95 That would make it semi-automated, in that there would be an editor taking the responsibility for checking the batch. I support that in principle. · · · Peter Southwood (talk): 08:01, 28 August 2020 (UTC)[reply]
  • Partial support. D1 and D2 are a matter for Wikidata; if I were more involved there I'd support D1 but have reservations about D2. E1 is good in principle but risks importing vandalised or Wikidata-specific descriptions (made-up example: "philosophical concept; for the verb use Q12345 instead"). Oppose E2, but perhaps we should report cases somewhere. Is there value in maintaining a list/category/whatever of descriptions which deliberately differ between enwiki and Wikidata, and downsizing D2/E2 to "find and report differences not on that list"? Certes (talk) 22:14, 6 August 2020 (UTC)[reply]
    Someone is a step ahead of me. See also Category:Short description is different from Wikidata, Module:SDcat and WT:Short description#Adding tracking categories. Certes (talk) 23:23, 6 August 2020 (UTC)[reply]
    If we do adopt E1, for some or all pages, we should tag imported descriptions (hidden category:Short description imported from Wikidata?), so we can gradually go through them, improve if necessary then remove the tag. Certes (talk) 11:08, 11 August 2020 (UTC)[reply]
  • Strong oppose E2, as it defeats the point of the introduction of {{short description}} entirely. * Pppery * it has begun... 22:37, 6 August 2020 (UTC)[reply]
    @Pppery: How would you suggest we resolve those differences? Thanks. Mike Peel (talk) 23:01, 6 August 2020 (UTC)[reply]
    A tracking category could be used to find articles with short descriptions different from the Wikidata short descriptions. The Shortdesc Helper could be used by editors to import (with or without modification, based on WP's guidelines) or export (with the Wikidata community's consent) the better description. – Jonesey95 (talk) 23:20, 6 August 2020 (UTC)[reply]
  • I've split my !votes into separate lines to make tallying easier for the closer:
    1. Strong support D1, E1 as obvious improvements. We can remove redundant descriptions like "List article" once the Wikidata link is turned off.
    2. Weak support D2 because it's more likely that enwiki will have a better description than wikidata, since there are many more active editors and far fewer articles/items on enwiki than on wikidata.
    3. Weak oppose E2 for the reason above. These are weak, because I recognise that there will be many exceptions to the general case, and some care will be needed to implement any overwriting. --RexxS (talk) 22:57, 6 August 2020 (UTC)[reply]
  • Comment – does the result of an en-wiki Rfc have any bearing on what Wikidata decides to do? I can hear Lydia's voice saying, "Not happening." This Rfc may be pointless. Mathglot (talk) 23:16, 6 August 2020 (UTC)[reply]
  • Wikidata and Wikipedia.en are separate projects, and do not NEED to be in sync.
    Ideally I would support E3 - we don’t pay any attention to Wikidata, and write our own short descriptions. However, I do realize that this would be extremely labor intensive, so (begrudgingly) I would accept E-1 - as long as we can subsequently amend any descriptions if we wish to. I would oppose E-2. Blueboar (talk) 23:36, 6 August 2020 (UTC)[reply]
    • This is the status quo for the last couple of years. Not so much labour intensive as most people probably still don't know about them and don't have the tool that makes them easy. Changing them at any time is also easy with the gadget. Making the gadget default would probably accelerate the process quite a bit.· · · Peter Southwood (talk): 13:54, 7 August 2020 (UTC)[reply]
  • Oppose: The original error was someone assuming that Wikidata item-descriptions and EnWiki article descriptions were (or should be) the same or interchangeable. Wikidata item-descriptions and EnWiki article-descriptions serve different purposes, and under different policies. Wikidata can and should have descriptions that do not belong here, and we can and should have descriptions that do not belong there. It would be disruptive to pressure either community to make them the same. (Importing Wikidata descriptions may have been acceptable as part of a one-time process&cleanup had Wikidata-descriptions been shut off immediately, but obviously that did not happen.)
    1. D1 - Out of scope. It is an internal matter for the Wikidata community.
    2. D1 - Out of scope. It is an internal matter for the Wikidata community.
    3. E1 - Oppose:
      • A bot should not overwrite (or potentially editwar) deliberately blank descriptions.
      • The Short description helper gadget makes it trivially easy to import Wikidata descriptions, after human review considers the Wikidata version to be appropriate for Enwiki purposes and under local policies&guidelines, and they consider it an improvement. We shouldn't be importing stuff without consideration of whether it belongs here at all.
    4. E2 - Hard Oppose. It would make more sense to propose rolling back the local system completely, going back to automatic display of Wikidata descriptions. Spoiler alert: That will not get consensus. There was overwhelming consensus to kill the original system of displaying Wikidata descriptions here. Alsee (talk) 01:56, 7 August 2020 (UTC)[reply]
    There is no such thing as "a deliberately blank description". When the short description is missing or empty, the software provides the Wikidata value instead, which is out of our control. If we imported the Wikidata value into a previously blank short description, we would lose nothing and gain the ability to edit the short description to fit our policies and protect it with our anti-vandalism measures. --RexxS (talk) 16:53, 7 August 2020 (UTC)[reply]
  • Oppose any bot editing, especially E2. If Wikidata would like to import EnWP descriptions, thats fine by me, and I'd support that, but its really up to WikiData folks. But I don't think we should be importing Wikdata descriptions. If you use the shortDescription tool, you can already do that, and the WikiData descriptions are almost always machine generated garbage. They are very quick to make, and I add a short description to every article I visit. Most don't have WikiData descriptions when I create new descriptions anyway. E2 is highly problematic in my view: it would make vandalism of short descriptions easy, cause edit wars, and be all around not good. CaptainEek Edits Ho Cap'n!⚓ 05:55, 7 August 2020 (UTC)[reply]
  • Thanks Mike Peel for raising this as a discussion, but have to agree with Alsee that D1 and D2 are out of scope for the en-WP community to decide, and E1 and E2 should be Opposed as (regrettably) too open an invitation for inaccuracies and crosswiki vandalism. Shortdesc additions are progressing well on en-WP, let's just let that continue in its current form. -- Euryalus (talk) 06:02, 7 August 2020 (UTC)[reply]
  • Strongly support syncing as a general concept. Wikidata descriptions and en-WP short descriptions are fundamentally the same thing: short descriptions. Are there occasional instances where they might properly diverge? Sure. But does that mean they should be totally split, leading to probably thousands of hours of duplicated (i.e. wasted) editor effort to create the same thing in two separate places? Absolutely not.
It's important to connect this to the bigger picture here. The success of the Wikimedia movement is fundamentally predicated on having enough people to do the work. That's the main reason we delete non-notable pages. Whenever we choose to fork, that literally doubles the amount of work to be done, which when you multiply by 6 million, comes out to a gargantuan cost in editor effort. Thus, preventing forks needs to be one of our highest priorities. Worse, once a fork has been made, re-integrating becomes harder and harder over time. I recognize that there are a lot of challenges to doing so here, both because of the initial reasons for the fork and because of the hurdles from the divergence so far, but at a fundamental level, that is the path we need to be on.
Regarding the specific proposals, D1 and D2 are decisions for Wikidata to make, not us, so those are out of scope. E1 may make sense, and E2 definitely doesn't make sense, since where they diverge, en-WP descriptions tend to be better (due to the larger user base). I think what's likely to happen is that Wikidata will at some point recognize (perhaps now, perhaps in a few years) that en-WP descriptions are better and seek to adopt them. The question then becomes how to handle the situations where they are supposed to be different. Some further discussion is needed over at Wikidata to define what exactly those circumstances are, and how best to handle them (probably through some technical modification, so that e.g. "for the verb use Q12345 instead" can be tacked on to the en-WP short description). {{u|Sdkb}} talk 07:21, 7 August 2020 (UTC)[reply]
This would be a good point if it can be shown that Wikidata descriptions and Wiikipedia short descriptions do in fact have a sufficiently close match in uses. On Wikipedia we have a reasonably good idea of what the uses for short descriptions are, and we can expand them as an when we like, but where is it defined on Wikidata? Also there are fairly clearly quite a number of types of case where 'no short description' would be most appropriate on Wikipedia. This may not be true for Wikidata. Note that on Wikidata it is not even possible to provide a reference for the description. On Wikipedia we can use the article as the source, and if we find it necessary or desirable, we can make a way to add a reference.
Since they are considered content on Wikpedia, the proper place for them is on Wikipedia, where they can be created and maintained by Wikipedians. If there is no point in duplication, then transclude them to Wikidata. Then they also cannot be vandalised on Wikidata (2 problems solved - not duplicating and more eyes on the content.)
In the bigger picture the independent projects of The Wikipedia movement tend to rub along together much better when it is left to the community of each project to decide which content from other projects they choose to use. Trying to convince them that they must use another project's content because the other project thinks it is better is often met with stubborn resistance and a selection of good reasons why it would not work, which the proposers failed to think of, because they don't have to deal with the problems which they don't see as problems. Cheers, · · · Peter Southwood (talk): 13:36, 7 August 2020 (UTC)[reply]
  • Oppose E1: e.g. for disambiguation pages, enwiki may decide that no short description is needed (if the page already has "disambig" or something similar in the title), while Wikidata will have "Wikimedia disambiguation page" as the short desc. Importing this would be counterproductive. Strong oppose E2 as completely missing the point of why this whole effort has been done in the first place. If we wanted our descriptions to be the same as those on Wikidata, we wouldn't have bothered with the "short desc" in the first place. As has been said, D1 and D2 are completely out of scope for a discussion here (just like E1 and E2 would be out of scope for a discussion at Wikidata). Fram (talk) 07:28, 7 August 2020 (UTC)[reply]
    It's easy enough to avoid pages that use {{Disambiguation}} if you want. Thanks. Mike Peel (talk) 11:20, 7 August 2020 (UTC)[reply]
    Yes, disambiguation pages need a standard short description or none at all. They are special because they describe their title rather than one of its possible meanings. Venus needs something to tell the reader that it's about a planet rather than a deity or a clam. Mercury is about "mercury" in all its senses. Certes (talk) 11:32, 7 August 2020 (UTC)[reply]
    It doesn't matter if enwiki decides that certain articles should have no short description, because the software doesn't allow it. The current choice is between a description automatically taken from Wikidata where we have no control of it, or creating a description on enwiki that we can edit to fit our policies and guard against vandalism. --RexxS (talk) 16:53, 7 August 2020 (UTC)[reply]
    The software doesn't allow it yet: the WMF promised they would turn this off when we reached the 2 million mark, but "surprise" they haven't done anything to actually achieve this and have been "working on it" for months now. But if and when the WMF does what they promised, then a "blank" short description on enwiki will be perfectly possible technically. Fram (talk) 17:19, 7 August 2020 (UTC)[reply]
    Jam tomorrow. But this is now. If and when the WMF turn off Wikidata short descriptions from enwiki, it will be a simple bot job to remove all of the useless boilerplate descriptions like "List article", including any that we import from Wikidata today. But in the meantime, we get control and vandal patrol over the ones that we've put here, instead of relying on Wikidata to control this bit of our content. --RexxS (talk) 11:45, 10 August 2020 (UTC)[reply]
    No idea what you mean by "Jam tomorrow". In any case; with E1, we import all Wikidata descriptions (which are shown now anyway, so no improvement now) and then we're stuck with that unsupervised mass import when the WMF keeps it promise of turning off Wikidata descriptions. Bsically, E1 is a way to undo the community RfC on Wikidata descriptions for the millions of articles that don't have a shortdesc yet (assuming they have one on Wikidata, which often isn't the case as well). Then we could just as easily had copied the descriptions in the first place; but the community decided against this, because of the quality issues. These quality issues haven't magically disappeared in the meantime, so there is no reason to import these now anyway. Better no descriptions than blindly importing the Wikidata ones; and better good descriptions than no descriptions. Fram (talk) 15:31, 10 August 2020 (UTC)[reply]
    "Jam tomorrow" is a phrase from Alice's dialogue with the White Queen. I think you'll find the conversation quoted in our Jam tomorrow article eerily reminiscent of our interactions with the WMF teams. I can sympathise with your position if I can bring myself to believe that that a tomorrow will arrive when the Wikidata descriptions are actually turned off, but we've been bitten like that once already. --RexxS (talk) 15:51, 10 August 2020 (UTC)[reply]
    The rule is, jam to-morrow and jam yesterday——but never jam to-day. - Lewis Carroll, Through the Looking-Glass, and What Alice Found There, chapter V. --Redrose64 🌹 (talk) 16:46, 10 August 2020 (UTC)[reply]
    Thanks, both. Fram (talk) 10:09, 11 August 2020 (UTC)[reply]
  • Oppose E1/E2 – E1, because a lot of times, especially with naturally descriptive titles which can't be improved upon or better described briefly, empty is what you want. And also partly for reasons given by Alsee (and Fram). Likewise E2, because of the genesis and raison d'etre of short descriptions (and per A & F). Mathglot (talk) 09:15, 7 August 2020 (UTC)[reply]
  • Oppose E1 as a bot action. All imports of short descriptions from Wikidata are at the discretion of a live editor, who will be held responsible for their being appropriate. Multiple inappropriate imports may lead to a block. There is already significant consensus for this item on en:WP. · · · Peter Southwood (talk): 09:37, 7 August 2020 (UTC)[reply]
  • Oppose E2 There is fairly broad-based and long-standing existing consensus on this point that does not look likely to be changed here. This would be a blockable offence. · · · Peter Southwood (talk): 09:37, 7 August 2020 (UTC)[reply]
  • Comment on D1 and D2 Not our circus, not our monkeys. This is something to take up with the Wikidata community, it is outside of our competence to decide, They are welcome to do it if they choose. · · · Peter Southwood (talk): 09:37, 7 August 2020 (UTC)[reply]
    I have notified the Wikipedia:WikiProject Short descriptions on its talk page. Anyone may feel welcome to check and ensure that the notification is appropriately neutral in tone. Cheers, · · · Peter Southwood (talk): 09:58, 7 August 2020 (UTC)[reply]
  • D1 and D2 are out of scope for an enwiki RfC, so won't comment on them here (I understand there is a discussion on wikidata, but this is just to cover this for sake of completeness)
  • Strong oppose E2, as this is essentially the situation we had before {{short description}} but with added bot edits. If the community feels this is OK, then surely we just keep using the descriptions from wikidata? I have not fully looked into the benefits / disadvantages of wikidata being used for short descriptions, so this oppose is based on the idea that having a bot periodically import is not as good of an idea compared to automatic server side syncing (which is what we had before).
  • Oppose E1. If the community has issues over short descriptions being inaccurate or that labels are not always a good idea for short descriptions, then mass importing would be disruptive. Also a proportion would likely be incorrect or needing of improvement. The userscript which imports short descriptions seems to be doing a good job of covering the issue, by having an editor verify the short description before importing it. Dreamy Jazz talk to me | my contributions 11:39, 7 August 2020 (UTC)[reply]
  • Oppose importing into English Wikipedia, as many short descriptions on Wikidata are overgeneric and not useful. For Wikidata imports, please discuss it there. Graeme Bartlett (talk) 12:11, 7 August 2020 (UTC)[reply]
  • Comment on alternative to E1: write our own bot. Nearly six 3.7 million Wikipedia articles don't have any short description, and they should. For those, it would be better as a last resort to take the Wikidata bot-texts than to expect editors here to fix up that number of articles manually within a reasonable time. But those aren't the only options. Someone populated the Wikidata texts using a fairly simple bot, and there's no reason why the Wikipedia community here couldn't do the same, but with more sophistication. There's already an active group of editors working on WikiProject Short descriptions, and bot-assistance has been requested (by me and others). With a suitable commitment from a skilled bot writer, I'm confident there would be enough eyes to ensure a high level both of reliablity and of usefulness for our purposes. It takes a huge amount of time to edit and check each new SD manually if the article has to be opened each time, but if a bot writer could provide draft texts in a table format for manual review before updating, the manual effort would be far less. I, and I'm sure several others, would be only too happy to help with the technical specifications of such a bot, though I'm not able to do the actual coding. MichaelMaggs (talk) 13:07, 7 August 2020 (UTC)[reply]
    See also: PearBOT 5. Certes (talk) 13:58, 7 August 2020 (UTC)[reply]
    @MichaelMaggs: In principle I could help with this, as I can code and operate pywikibot scripts (which is what started this whole discussion). I'm not sure there is consensus to do this, though, given the anti-bot comments in this discussion. Perhaps you can draft specifications that you think would get consensus, I can code something up, and we can add an extra option to this discussion to see if it would be OK (or start another discussion)? Thanks. Mike Peel (talk) 19:15, 7 August 2020 (UTC)[reply]
    @Mike Peel: Thanks Mike, that would be most helpful. I don’t think there will be serious objections to auto-generating new SDs from entirely within Wikipedia, as that’s already been done on a sporadic basis by several editors at WikiProject Short descriptions, and indeed is recommended there; the objections above are more to the importation of rather poor-quality Wikidata descriptions. I’ve set out more details of a proposal at Wikipedia talk:WikiProject Short descriptions#Miniproject to generate new short descriptions by category. MichaelMaggs (talk) 10:17, 8 August 2020 (UTC)[reply]
  • Oppose E1 & E2 (the only ones we need to decide here on English Wikipedia, what Wikidata does is their own decision that should be made on their own project) per Alsee. And didn't we already pretty much decide on E1 and E2 in the past, so why are we doing this again? --Ealdgyth (talk) 13:13, 7 August 2020 (UTC)[reply]
  • Strongly Oppose E2. Regarding E1, Dreamy Jazz wrote (above), "The userscript which imports short descriptions seems to be doing a good job of covering the issue, by having an editor verify the short description before importing it." - I agree. Thus, I Oppose E1 if it means an autonomous bot filling in short descriptions from Wikidata.  - Mark D Worthen PsyD (talk) (I'm a man—traditional male pronouns are fine.) 00:16, 8 August 2020 (UTC)[reply]
    The script is a fine tool, but it would work better if more people used it. Getting them to use it requires them to know that it exists, and that short descriptions are needed. Not everyone cares, or is interested. I think they are useful when of reasonable quality, and mostly worth the effort, but not everyone shares this view.· · · Peter Southwood (talk): 08:18, 8 August 2020 (UTC)[reply]
  • Support D1 & E1; Strongly oppose D2 & E2 — In my experience we want content control here. I have found graffiti and worse in wikidata. Make this wiki the authority and import what wikidata has so we may correct it. —¿philoserf? (talk) 08:27, 8 August 2020 (UTC)[reply]
  • D1 & D2 are not for us to address here. Oppose E1 as needing clearer definition. Strongly Oppose E2 as being the opposite of consensus and would undo much progress. — GhostInTheMachine talk to me 15:24, 8 August 2020 (UTC)[reply]
  • Support E1, oppose E2, Wikidata can do what it wants regarding D1 & D2. Really I'm fine with synching in either direction but in cases where data exists in both places, local data must always override remote, otherwise there's an enormous vulnerability to remote disruption we cannot use local tools to prevent. Ivanvector (Talk/Edits) 14:29, 10 August 2020 (UTC)[reply]
    Sorry to question you, but did you really mean to oppose E1? That's the case where English Wikipedia has no local description (so the software uses the remote description from Wikidata anyway). Wouldn't importing that remote description at least make it easier to edit here, and reduce the chance of it being vandalised? — Preceding unsigned comment added by RexxS (talk • contribs) 15:11, 10 August 2020 (UTC)[reply]
    If I've understood correctly, that's true only until the promised change occurs. Afterwards, E1 moves us from no description to a blindly imported description which can be edited or removed. That's not obviously bad, but it's different. Certes (talk) 15:50, 10 August 2020 (UTC)[reply]
    Apologies if I've misunderstood the options. If there is no description here already, importing the description from Wikidata ought to be harmless, it's what users see anyway. My only really strong opinion is that if there is a description here, Wikidata should not overwrite it. Ivanvector (Talk/Edits) 00:17, 11 August 2020 (UTC)[reply]
    @Ivanvector: What you describe then is neutral on D1/D2, support for E1 (If there is no short description here, then import the English description from Wikidata.) and oppose for E2 (If the short description here does not match Wikidata, then replace the short description here with that from Wikidata.) --Redrose64 🌹 (talk) 09:15, 11 August 2020 (UTC)[reply]
    Yep, you're right, my mistake. Changed my comment. Ivanvector (Talk/Edits) 10:00, 11 August 2020 (UTC)[reply]
  • Strongly oppose both E1 and E2. Until Wikidata has much better verification, I don't want anything from Wikidata imported into EN articles. DES (talk)DESiegel Contribs 01:17, 12 August 2020 (UTC)[reply]
  • Support E1, Oppose E2. No opinion on D1 and D2 which are up to the Wikidata community. I see comments such as DESiegel's above about not wanting anything from Wikidata, and I sympathize, but as a practical matter it's already happening since in the cases that fall under E1 we are displaying the Wikidata text. What E1 would do is immediately make vandalism to the description visible on watchlists here, and that's a big plus. It also means we can quit worrying about vandalism to Wikidata since it would have no effect here. E2 makes no sense in the light of previous community decisions to have the short description here override whatever is in Wikidata. Mike Christie (talk - contribs - library) 18:19, 13 August 2020 (UTC)[reply]
    Mike Christie you make a valid point that once the Wikidata descriptions are copied to WP any vandalism on Wikidata becomes irrelevant and we can improve them here, but until that is done, they are our responsibility for BLP etc. Who would be held responsible? The bot owner? The person who authorises the bot run? Also, does anyone know how many of the outstanding SDs actually still have a Wikidata version available to copy? I guess it would be in the order of a million but could be out by a lot. · · · Peter Southwood (talk): 14:26, 28 August 2020 (UTC)[reply]
    Well, tell me if I'm wrong, but anything that we would consider vandalism is already showing up, right? E.g. if a BLP has a short description of "convicted criminal" in Wikidata, we're seeing that on mobile search now, but can't detect it here in enwiki. If we import it we have not made things worse. If someone were to go to that article, as they might do now, to set up the short description, instead of seeing "Convicted criminal" - Import - Import and edit they'd see Short description: Convicted criminal. So it wouldn't have any negative effect on our current drive to put in short descriptions, and would have the beneficial effect of preventing future vandalism on Wikidata from affecting us. Plus many of the bot edits would get reviewed (we would want them to be spaced out, not a flood of two million edits in a month) and that would have the additional benefit of cleaning up some of the incoming short descriptions if they are in fact vandalism. I don't see much of a negative. What am I missing? Mike Christie (talk - contribs - library) 15:15, 28 August 2020 (UTC)[reply]
    You're right about the current situation. What's missing is that the WMF has promised to stop displaying Wikidata descriptions, which will get rid of many descriptions (good or bad) but not those imported per E1 or E2. Certes (talk) 15:45, 28 August 2020 (UTC)[reply]
    I was under the impression that the promise to stop displaying Wikidata descriptions has not been implemented even though we have enough short descriptions to meet the requirement they set, and there's no date given for them to make that change. I agree that if we believe it's going to happen soon that makes a difference, but I also think the functionality is genuinely useful in mobile, and if most of the descriptions are correct (and I would guess the great majority are) then we might as well import them and fix them. That saves a lot of editor time on putting in short descriptions too so I suspect it would be a net benefit. Do we have evidence the WMF is really going to make the change soon? If so I would change to weak support for E1. Mike Christie (talk - contribs - library) 16:42, 28 August 2020 (UTC)[reply]
    For me, the WMF keeping its promise is a necessary assumption, in the sense that if they don't then I intend to stop editing and will no longer care about the outcome. However, that's slightly off-topic and I can understand that other editors have different opinions and objectives. Certes (talk) 17:18, 28 August 2020 (UTC)[reply]
  • Support E2, but only support E1 after the Wikidata descriptions are actually ignored. I don't want to see even more redundant edits in my watchlist until it's really necessary. Nemo 11:06, 21 August 2020 (UTC)[reply]
  • D1 and D2 are obviously not for us to decide. E2 would defeat the purpose of local short descriptions. Unsure about E1: it sounds like a good idea, and I certainly welcome the prospect of my watchlist never again getting cluttered by human editors importing descriptions from wikidata. On the other hand, it appears that imported descriptions do sometimes (often?) need to be changed, and they won't get changed unless either a human imports them or they get noticed by watchers (a bot eliminates the first and reduces the likelihood for the second). – Uanfala (talk) 18:03, 21 August 2020 (UTC)[reply]
  • Strong oppose E2 because en.Wikipedia content should be controlled by en.Wikipedia, not overridden by a different project with different quality standards and different compunctions about low-quality mass bot text-creation. Oppose D1 and D2 because we should not be making decisions here about what gets stored on Wikidata. Oppose E1 on the general principle that Wikidata content is sufficiently dubious that every instance of copying text from Wikidata into en.Wikipedia should require a human to pay attention to it and check its validity, not just mass-copy by bots. —David Eppstein (talk) 07:08, 22 August 2020 (UTC)[reply]
  • Oppose E1 & E2, no comment on D1 & D2 which are matters for the Wikidata community to decide. Noting that a description on Wikidata is a "descriptive phrase for an item, property or query" while a description on Wikipedia is a "concise explanation of the scope of the [article or other mainspace] page"; these are not the same thing. Also noting that Wikidata is a wiki and hence it is inherently unreliable; we should not be importing anything from Wikidata. --Malcolmxl5 (talk) 15:11, 25 August 2020 (UTC)[reply]
  • Oppose E1, strongly oppose E2 No to E2 per many above. As for E1, I find the quality of Wikidata short descriptions too erratic for wholesale import. Some are far too long, others are so trivial they are pointless and still others are simply incorrect. I would not oppose a tool that would allow a category-worth of SDs to be reviewed together, with check boxes, allowing all the checked Wikidata SDs to be imported at once. That would speed things up without omitting human editor review of this highly visible content. We already have a user script that allows the page SDs in a category to be listed. See #Script to show short descriptions in category listings, below. It could be used as a basis for a review script.--agr (talk) 23:42, 31 August 2020 (UTC)[reply]
  • Strong oppose E1 and E2: I don't know how many folks have been looking into and editing the short descriptions and all, but I can confirm that ArnoldReinhold is right: put kindly, the Wikidate short-descriptions are simply "too erratic". I would call them bad, quite frankly, and unsuited for import onto our Wikipedia. — Javert2113 (Siarad.|¤) 16:59, 1 September 2020 (UTC)[reply]

Possible alternatives

I cannot see the proposals above getting acceptance, but part of the problem that they are intended to resolve is real. We need a lot more short descriptions, and sooner is better than later. They do not have to be perfect, just good enough, as they can be improved at any time. I throw these in to stimulate thought and discussion, including better proposals.· · · Peter Southwood (talk): 08:18, 8 August 2020 (UTC)[reply]

  1. A semi-automated system which goes through a category and provides suggestions, one of which can be selected and if necessary edited before saving. One of the suggestions would be the Wikidata description, because it is there, and is fairly often usable as is, and quite often can be edited into something better. The script for other options could be designed around the category. I don't know if this would be more or less work than just using the gadget and a moderately informed brain.
  2. Relatively small bot runs per category followed by manual checks for quality.
  3. Semi-automatic runs, where the bot opens and displays the proposed SD, and the user must accept it as appropriate to save.
  4. Do a major bot run on the whole encyclopedia adding a maintenance category Category:Articles without a short description where relevant, to keep track of what is left to do.
  5. Request NPP to consider adding SD wherever they can - Could even make a reasonable SD a condition of passing review, but I am not going to try to push more work onto NPP if they don't want it.
  6. Make the gadget active by default to logged in users. An RfC would be necessary as otherwise there is likely to be strong pushback.
  7. If Wikidata want to synchronise their descriptions to match those used on Wikipedias, they are welcome to update Wikidata by any means they choose that does not change Wikipedia short descriptions by automated process.

Peter Southwood (talk): 08:18, 8 August 2020 (UTC)[reply]

  • Question: I have nothing against short descriptions, but WHY is there a rush to add them? I don’t understand the idea that sooner is better than later. I would think a slow and deliberate approach would be better... enlighten me. Blueboar (talk) 18:21, 8 August 2020 (UTC)[reply]
    @Blueboar: Because the WMF have given us a two million target, beyond which they will allow us a lot more control. See also WT:SHORTDESC and its archives. --Redrose64 🌹 (talk) 20:04, 8 August 2020 (UTC)[reply]
    I’m still confused... why is WMF in such a rush? Blueboar (talk) 20:30, 8 August 2020 (UTC)[reply]
    @Blueboar: Because things will break after WMF turns off the usage of the descriptions from Wikidata, which sucks. Thanks. Mike Peel (talk) 20:19, 8 August 2020 (UTC)[reply]
    What will break? Blueboar (talk) 20:30, 8 August 2020 (UTC)[reply]
    Currently the "short description" is used in certain scenarios related to mobile search and Wikipedia app usage; if no short description is there, the description from Wikidata is used instead. The functionality is extremely useful to navigate Wikipedia content on small devices which account for roughly half of the reader base.
    The enwiki community requested to ditch usage of Wikidata descriptions once ~2 million local descriptions have been created, which is the case meanwhile. Nevertheless, there are currently 2.4 million articles which have a Wikidata description, but not a local English Wikipedia short description. When the usage of Wikidata descriptions is ditched now, a really large fraction of the enwiki content becomes substantially less accessible for millions of readers. —MisterSynergy (talk) 20:41, 8 August 2020 (UTC)[reply]
    Ah... so nothing will actually BREAK. People will still be able to read and edit WP. It just won’t be as mobile friendly as it could be. Thanks. Got it. Blueboar (talk) 20:59, 8 August 2020 (UTC)[reply]
    The WMF may already have turned off Wikidata descriptions. I've not seen any announcement but I no longer see short descriptions on, for example, Abdomen, neither in mobile view nor with the gadget. Some but not all other editors still see the description, so perhaps only some servers have been updated. The change doesn't seem to have broken anything other than removing some descriptions. Certes (talk) 20:51, 8 August 2020 (UTC)[reply]
  • Many of these seem like good ideas. But #6? Definitely not, since not all logged in users are editors. Remember the WP:READER. {{u|Sdkb}} talk 20:24, 8 August 2020 (UTC)[reply]
    Why would people log in just to read? How often does this happen?
    In what way would making the gadget active by default inconvenience anyone who does not intend to edit? · · · Peter Southwood (talk): 11:05, 9 August 2020 (UTC)[reply]
    Logging in allows you to set some preferences a reader might want to set.
    Short descriptions are not intended to be seen by desktop readers on a page. Showing them through the gadget would significantly change their purpose, and clutter the top of every page. Also, the gadget does not format them well enough for usage that widespread (it's unclear what exactly they are to the unaware, and the indent is a bit weird; that's fine for editors but wouldn't be for readers). {{u|Sdkb}} talk 20:12, 9 August 2020 (UTC)[reply]
    Short descriptions were indeed not originally intended to be seen by desktop readers. It is more debatable whether being able to see them is an advantage or a disadvantage to desktop readers. The display can be changed to something more aesthetically pleasing, if anyone could work out what that might be, Or it can be left as opt in, to avoid potentially inconveniencing the readers whose opinions are currently untested, and take a lot longer to finish the job because most editors don't know they should exist. · · · Peter Southwood (talk): 18:48, 13 August 2020 (UTC)[reply]
    The question of how many desktop readers who do not edit actually log in remains. Is it significant? Is it known? Can it be measured? · · · Peter Southwood (talk): 18:52, 13 August 2020 (UTC)[reply]

Script to show short descriptions in category listings

I'd like to call attention to a recently created user script that might be helpful in this discussion: Wikipedia_talk:WikiProject_Short_descriptions#Script_to_show_shortdescs_of_all_pages_in_a_category. I requested this script and SD0001 was kind enough to write it. In addition to aiding in editing short descriptions, I think it may have value in getting a general sense of the quality of local and Wikidata SDs. I would suggest trying it out on some categories you are familiar with.--agr (talk) 23:26, 31 August 2020 (UTC)[reply]

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

Remove the Draft namespace from $wgNamespacesWithSubpages

In the main namespace, there are no subpages, so / is just a character in an article name like any other. Pages in the Draft namespace are generally supposed to have the same name as they would in the main namespace once accepted, so it doesn't make sense to have subpages there either. For example, Draft:Andreas Hedlund (arranger/orchestrator) shouldn't be considered a subpage of Draft:Andreas Hedlund (arranger, and Draft:9/11 Review Commission shouldn't be considered a subpage of Draft:9. And to my knowledge, there's no legitimate, intentional subpages in use in the Draft namespace. As such, I propose that we have the Draft namespace be removed from $wgNamespacesWithSubpages. Jackmcbarn (talk) 04:12, 10 August 2020 (UTC)[reply]

Current pages under consideration: quarry:query/47324. Plenty of intentional ones there, so I guess this comes down to what you consider to be "legitimate". —Cryptic 05:19, 10 August 2020 (UTC)[reply]
Almost all of those look like they're either (1) using slashes in a way not meant to be subpages, (2) leftovers from someone moving "User:Foo/Bar" to "Draft:Foo/Bar" instead of directly to "Draft:Bar", or (3) a result of people using the Draft namespace for things other than drafting articles. Would you consider any of those legitimate, or do you think there's some other group that I'm underestimating the number of? Jackmcbarn (talk) 23:25, 10 August 2020 (UTC)[reply]
I think that if I were editing a lot of draft articles at once, I might want to name them Draft:RexxS/Foo, Draft:RexxS/Bar, etc. to keep them together, but that would probably work almost identically if subpages were disallowed. Of course I could simply use my own userspace for the drafting if I really wanted subpages, so I can't see any problem with removing draft namespace from $wgNamespacesWithSubpages. Can we be sure what will happen to the current set of draft pages containing the / character when the configuration is changed? --RexxS (talk) 17:41, 11 August 2020 (UTC)[reply]
@RexxS: Nothing at all will happen to drafts that currently have a slash in their title. They'll still be accessible at their current names. Also, users will still be able to make drafts with those titles. The only thing this change would do is change the output of {{BASEPAGENAME}} and {{SUBPAGENAME}}, get rid of the automatic breadcrumb links to parent pages, etc. Jackmcbarn (talk) 20:53, 11 August 2020 (UTC)[reply]
@Jackmcbarn: yes, I'd figured out those that you mentioned, it's just the "etc." that I was concerned about --RexxS (talk) 21:01, 11 August 2020 (UTC)[reply]
@RexxS: Having checked the MediaWiki documentation, I see only two other effects: any relative links will break, so "[[/bar]]" on "Draft:Foo" would now link to "/bar" instead of "Draft:Foo/bar", and moving drafts would no longer show an option to move their subpages. Since drafts are supposed to eventually become articles, and those kinds of links wouldn't be valid in mainspace, I don't consider that much of a loss, and I also don't think we move drafts with their subpages very often (if ever). Jackmcbarn (talk) 21:19, 11 August 2020 (UTC)[reply]
Might Draft: space be used for a round-robin move of a page with subpages, e.g. a template complete with /doc, /sandbox and /testcases, or a portal? Certes (talk) 21:28, 11 August 2020 (UTC)[reply]
@Certes: you could just as easily use your own userspace for the temporary pages. --RexxS (talk) 21:36, 11 August 2020 (UTC)[reply]
@Certes and RexxS: WP:ROUNDROBIN currently recommends using a subpage of Draft:Move for that purpose, a behavior which is mirrored by the popular pageswap user script. I'm not sure whether that functionality requires access to the MediaWiki-side "move subpages" option (which would be the only thing truly affected by this change, as far as I can tell), but it is certainly worth noting that this change may disrupt the currently accepted flow for round-robin moves. Nathan2055talk - contribs 01:54, 23 August 2020 (UTC)[reply]
@Nathan2055: We would be foolish to allow the currently suggested route for doing round-robin page moves to become a block to implementing a useful proposal. It is trivial to update advice when circumstances change. Nevertheless, for single page moves, the current advice would work identically whether draft-space or user-space were used as the temporary location. An admin who is contemplating moving a page along with all its subpages would need to understand the limitations of the namespace that they were using for the temporary pages. Perhaps we could agree to use User:Example/Move as the root for such moves. --RexxS (talk) 17:30, 23 August 2020 (UTC)[reply]
  • Support Users who want to organize their drafts using subpages can use their userspace; users who want to do round-robin page moves with subpages can use userspace or project space; the remaining use cases would be invalid in mainspace so I don't see a loss. DYK has lots of problems with slashes because its namespace has subpages when main doesn't, so this would likely make some dev's life easier in the future too. — Wug·a·po·des​ 20:47, 20 August 2020 (UTC)[reply]

Migrate college color data to Wikidata

There is a discussion ongoing about migrating some sports team color data from a local Lua module to Wikidata: Module talk:College color#Proposal: Migrate to Wikidata. –IagoQnsi (talk) 07:35, 11 August 2020 (UTC)[reply]

  • Yet another case of “Hey, we could use Wikidata to do this thing we already do”. No thanks. Blueboar (talk) 21:50, 11 August 2020 (UTC)[reply]
  • Oppose would serve only to make subtle vandalism easier. No benefit. DES (talk)DESiegel Contribs 02:14, 13 August 2020 (UTC)[reply]
    • @DESiegel: As I discussed on the module talk page, there are plenty of ways to monitor the data and combat vandalism. Here's a query that shows the most recent changes to color properties for college sports teams. A bot could be easily configured to update a page here on Wikipedia with those query results, and show those colors visually so that incorrect colors could be easily spotted. If vandalism did become rampant, Wikidata has the same protection tools we have on Wikipedia, and iirc, policy there says highly-visible items are eligible for indefinite protection if needed.
    As for the "no benefit" part, it's true that this has limited benefit to English Wikipedia. But it has great potential to benefit other Wikipedias and the rest of the Wikimedia community. Having a freely-available regularly-updated reference-backed database of college sports team colors is of great value to the general public; I can foresee these being used for cool data visualizations. –IagoQnsi (talk) 00:09, 14 August 2020 (UTC)[reply]
    If those running Wikidata want to import this data, they are free to do so and other projects are free to use it. At this point, I do not trust sourcing and validation done on Wikidata, and I strongly object to any information in any en.Wikipedia article being automatically imported from Wikidata. No exceptions. I opined in an RFC some years ago that we should make no use at all of Wikidata in articles, and i stand by that view today. I object to any and every expansion of use of Wikidata here. DES (talk)DESiegel Contribs 00:15, 14 August 2020 (UTC)[reply]
  • Support The benefits are many and I think IagoQnsi could have more to say. Centralizing the data so it is accessible to all 300+ wikis just makes sense. Only need to change data in a single place instead of 300. Monitor for vandalism in one place. Fix mistakes in one place. etc.. There are tools and methods for vandalism monitoring, that would be part of the deal for acceptance a robust method. As noted by IagoQnsi, there are future applications not currently available that could be built with a central color database, not just college sports teams. -- GreenC 02:54, 13 August 2020 (UTC)[reply]
  • Support Module:College color/data is a horrible hack to store data, it should never have been created, and it's a usability nightmare for anyone that wants to change something in it. Wikidata can handle this in a more user-friendly and cross-wiki way, with better monitoring tools via constraint violations and data queries. Thanks. Mike Peel (talk) 19:45, 13 August 2020 (UTC)[reply]
    • Question: How would the 794 citation templates in Module:College color/data be stored in Wikidata? --RexxS (talk) 23:11, 13 August 2020 (UTC)[reply]
      • @RexxS: Wikidata supports attaching references to statements; see wikidata:Help:Sources. I ran a script against all the reference templates to get the full list of parameters they use, which are as follows: access-date, archive-date, archive-url, date, language, page, publisher, title, url, url-status, website, work, year. All of those have corresponding properties in Wikidata, so they can be imported pretty easily. The properties 'publisher', 'website', and 'work' will have to be mapped to Wikidata items (because the corresponding Wikidata properties takes an item rather than a string). However, I just checked, and there are less than 100 uses of all those properties combined, so they'll be easy to reconcile with OpenRefine. –IagoQnsi (talk) 23:45, 13 August 2020 (UTC)[reply]
        @IagoQnsi: Please have a look at MOS:INDENTMIX. You've just made a mess of this thread for anybody using a screen reader. (reply: Fixed! –IagoQnsi (talk) 01:35, 14 August 2020 (UTC))Not quite. --RexxS (talk) 01:50, 14 August 2020 (UTC)[reply]
        Yes, I'm sure most of the parameters can be stored on Wikidata, even if you have to create hundreds of new Wikidata entries to accommodate the mismatch of datatypes (and more every time new citations are added). How do you intend to store the type of citation template used, so that the citation can be accurately reconstructed? Given those sort of problems, you need to ask yourself if Wikidata really is the best place to store this kind of data. --RexxS (talk) 00:51, 14 August 2020 (UTC)[reply]
        @RexxS: I don't expect I'll have to create many new items, if any at all. As I said, those 794 citations combined have <100 uses of parameters that have to be mapped to Wikidata items. And most/all of those uses won't require new items – most of the references were published by a university, and we already have WD items for every university.
        As for the type of template used, all of these citations use either {{cite web}} or {{cite manual}}. The distinction seems a bit arbitrary (i.e. many of the 'cite web' ones seem like they should be considered manuals), but I could store type of reference (P3865)=user guide (Q1057179) for the 'cite manual' ones if you'd like. But ultimately, the goal here is not to be able to generate the exact same underlying wikitext, but to generate a citation with the same semantic meaning. Really, the outcome is that the citations will be much cleaner – on Wikipedia, you often end up with information rather randomly distributed between 'work' and 'publisher' and 'title', but Wikidata forces you to be more consistent. –IagoQnsi (talk) 01:35, 14 August 2020 (UTC)[reply]
        @IagoQnsi: I think you may find that the editors using college colours are likely to be quite interested in recreating the exact underlying wikitext. Have you considered the workflow for an editor adding an entry to the Scribunto module (not simple, but there are plenty of examples to copy and the citation uses a format they will be familiar with), with that for adding a college colour to Wikidata, including all the work in deconstructing a citation into multiple non-obvious reference qualifiers. Worth thinking about. --RexxS (talk) 01:50, 14 August 2020 (UTC)[reply]
        @RexxS: It's not that we couldn't recreate them exactly as written; it's that it makes far more sense to clean them up so they appear better than how they're currently written. There's no reason to perfectly preserve messy stuff like |title=Color {{!}} Brand and Messaging {{!}} University of Colorado at Boulder. For example, take this citation: {{cite web |url=https://brand.cornell.edu/design-center/colors/ |title=Colors |publisher=Cornell University Brand Center |accessdate=July 17, 2019}} It's not worth creating a new item for "Cornell University Brand Center", so when I transfer it to Wikidata, I will likely transform it to look like this:
Wikidata example reference
Property
Normal rank no value edit
▼ 1 reference
+ add value
      • This isn't exactly the same, but it's basically a neutral change, if not an improvement. And if I plug that data back into {{citation}}, you get this perfectly cromulent citation: "Colors", Cornell University Brand Center, Cornell University, retrieved July 17, 2019 (for comparison, here's the original citation: "Colors". Cornell University Brand Center. Retrieved July 17, 2019.). –IagoQnsi (talk) 02:29, 14 August 2020 (UTC)[reply]
        @IagoQnsi: Please try to observe MOS:INDENTMIX. It's not very kind on screen readers to screw up the indenting as you do.
        If you read WP:CITEVAR, I think you'll find that the changes you have made are far from neutral. Aside from the obvious re-assignment of title and publisher, you've changed the citation style from {{cite web}} to {{citation}}, which should never happen. You also set the accessdate in mdy format. How did you recover that piece of information from your Wikidata record? These are the sort of problems I've been grappling with for the last seven years with Module:WikidataIB and I'd be fascinated to see how you think you've solved them. --RexxS (talk) 03:51, 14 August 2020 (UTC)[reply]
  • outdented — GhostInTheMachine talk to me 10:16, 29 August 2020 (UTC)[reply]
  • @RexxS: I understand the need to not change citations that are already perfectly fine, but that is not the case here. If you look through the citations in this module, there's little consistency between them. They alternate between quotes and italics; some are randomly in all caps; the name of the publisher is sometimes in the title field, sometimes in the work/website field, and sometimes entirely absent. In general, these all look like the authors pasted in their URL, clicked "autofill" in their citation tool of choice, and called it a day. I would be more than happy to preserve any existing citation style, but there just isn't one here.
  • Separating content from style is really the whole purpose of Wikidata You can display info from Wikidata with any citation style, any date format, even any language you want. If you want to show one of these citations in an article that's using {{citation}}, you can do that; if you want to use {{cite web}} or anything else, you can do that too. The goal of migrating to Wikidata is not to force any particular presentation style; it's simply to separate the data from the presentation. –IagoQnsi (talk) 06:18, 14 August 2020 (UTC)[reply]
    @IagoQnsi: I'm afraid you're mistaken about the citations stored in Module:College color/data. Apart from one access-date in ISO format, they are remarkably consistent. There is not one single example of italics hard-coded into the citations. Your complaint about "quotes and italics" is a consequence of MOS:ITAL: "Use italics for the titles of works (such as books, films, television series, named exhibitions, computer games, music albums, and paintings). The titles of articles, chapters, songs, episodes, research papers and other short works instead take double quotation marks. The citation templates are smart enough to use the appropriate formatting to match our Manual of Style. The citation style used is WP:CS1 and you'll run into huge problems if you think you can flip to another style at will. You're going to have to preserve the citations style used however it is stored, so that problem will need to be cracked before Wikidata becomes a viable storage mechanism for citations.
    Separating content from presentation is an artefact of Wikidata, not its purpose (that would be "storing data"). Unfortunately, Wikidata is currently structured to accommodate import of plain data, with little thought given to how it is to exported and re-used. If it is to be used as a database back-end for a Wikipedia article, it needs to be capable of respecting any presentation options that are currently in use in that article. The citation templates can do a lot of that work for you (they can even detect the date format in articles that have set one), but deciding on the style of citation that should be used in a particular article is currently the stumbling block for attempts to store citations in any format other than wiki-text. --RexxS (talk) 12:45, 14 August 2020 (UTC)[reply]
    @RexxS: If citation style was stored on Wikidata, it would cause violations of WP:CITEVAR, not prevent them. Here's how that would play out: ClaimX on Wikidata is used in two Wikipedia articles – ArticleA (which uses {{cite web}}) and ArticleB (which uses {{citation}}). Now, suppose User:Example updates ClaimX to use {{cite web}}. In this hypothetical, we are storing style information in Wikidata, which means ClaimX will now appear in ArticleB with {{cite web}}. Oh no, this violates WP:CITEVAR!
    Thus, this is how we do it instead: ClaimX on Wikidata has a citation with no defined style. ArticleA and ArticleB both import ClaimX, but they each render it in a different style. User:Example makes an edit to ClaimX. Because Wikidata does not store citation style information, the citation will continue to appear in {{cite web}} on ArticleA and in {{citation}} on ArticleB. The citations remain consistent, WP:CITEVAR is obeyed, and everyone is happy. –IagoQnsi (talk) 05:31, 18 August 2020 (UTC)[reply]
    @IagoQnsi: You think "ArticleA and ArticleB both import ClaimX, but they each render it in a different style." so the citation has to be hand-crafted for each article, thus defeating the object of the Module:College color, which is intended to render the information automatically. Just look at Module:College color/doc #Test table for an obvious example. The table is generated by one line: {{#invoke:{{BASEPAGENAME}}/contrast |testtable |style=background:#FDFDFD }}, but your solution would require 1132 rows to be written out individually so that you can supply the references in the format you want.
    The whole point of Module:College color is that it stores the citation style for each team along with its colour scheme. The advantage of that is that Abilene Christian Wildcats doesn't have to have the same reference style as Youngstown State Penguins. The downside is that if another article about Abilene Christian Wildcats is written, it needs the same citation style as the base article, but that's the route that the writers and maintainers have taken, and I don't see that you should be forcing them into doing a lot more work in each article just to avoid storing the citation style, which your solution can't deliver. --RexxS (talk) 17:17, 18 August 2020 (UTC)[reply]
    @RexxS: The citations wouldn't have to be rendered individually; you'd have a template/module which renders all of them, and you just tell that template how to style all of them. Something like: {{#invoke:{{BASEPAGENAME}}/contrast |testtable |style=background:#FDFDFD |citation-style=CS1 |date-format=mdy }} –IagoQnsi (talk) 20:11, 18 August 2020 (UTC)[reply]
    @IagoQnsi: So you write another template/module with 1132 rows just to display all of them? We already have a module that does that in one line. Otherwise, how does {{#invoke:{{BASEPAGENAME}}/contrast |testtable |style=background:#FDFDFD '''|citation-style=CS1''' |date-format=mdy }} know what the value of |citation-style= is? You've told me that you're not going to store it on Wikidata with the rest of the data. --RexxS (talk) 02:24, 19 August 2020 (UTC)[reply]
    @RexxS: My understanding of your argument is basically that the style of any given citation should never change. However, that's not quite what WP:CITEVAR says. It reads Editors should not attempt to change an article's established citation style (emphasis added). Citation style is set on a per-article basis, not a per-citation basis. Based on that policy, there is no reason that any given citation should have a set style; instead, it should be rendered in the style of the article it appears in. That's what the current policy would indicate, and frankly, what makes the most sense.
    Let me give an example. Suppose that I (a human editor) saw a citation-supported fact in ArticleA, and I decided that that fact (and its citation) would also be useful to include in ArticleB. In the process of copying this information over, I would surely edit the citation to convert it to the citation style of ArticleB, wouldn't I? If the citation from ArticleA is in {{citation}} style, but ArticleB uses {{cite web}}, then I would need to convert that citation to use {{cite web}}, right? If it is acceptable for me to change the style of a citation when moving it to a new article, then why shouldn't it be okay for Wikidata to do this as well? –IagoQnsi (talk) 17:59, 26 August 2020 (UTC)[reply]
    @IagoQnsi: You seem to misunderstand how this module is used. Each of the colour entries applies to effectively one article, and the data module stores not only the colour information for that article's team, but the citation style used in that article. That's how it works now. You want to change how it works to fit in with the ability of your scheme to store information, and to throw away the information about the style of citation to use. The editors who created and use this module make use of it in a simple way now; and you are going to ask them to either store locally a separate list of articles with their citation styles, or to insert the citation style manually in each article, for no reason other than your proposed solution can't function in the way that they are working now. That's the tail wagging the dog.
    Let's look at your example. You suppose that the colours for Team A, used in ArticleA might somehow be useful in ArticleB. I see no evidence of that ever being the case. Under the present system, that is still trivial to achieve when ArticleB has the same citation style as ArticleA; you just copy the relevant template over and it generates the citation for you. It would require manual updating of the citation if the styles were different. However, in your scheme, the citation would have to be locally set up in each ArticleA's case to match its existing style (you haven't given any examples of how that might be accomplished), and then set up again locally if you wanted to use it in ArticleB whether the style matched or not. I don't see that as an advantage. There is no demonstrated benefit of decoupling the citation style used in each team's article from the information stored in the module. At present there is effectively a one-to-one correspondence between article and entry in the data module, which allows a simple storage method. You are advocating using a more complex storage system (some info on Wikidata; some info locally) to allow for the possibility that somewhere the editors might want a two-to-one (or more) correspondence between article and colours info, but you haven't demonstrated any need or demand for that. --RexxS (talk) 19:06, 26 August 2020 (UTC)[reply]
    @RexxS: This module is not at all used on a single-article basis. Each school's colors are used on probably hundreds of articles each, as we have many many articles covering college sports. To give an example, the colors for Duke Blue Devils are transcluded in Duke University, Duke Blue Devils, Duke Blue Devils men's basketball, 1990–91 Duke Blue Devils men's basketball team, Atlantic Coast Conference, 2018–19 Atlantic Coast Conference men's basketball season, and every variation of those articles (i.e. other years/seasons, other sports). If we were to transfer the data to Wikidata, the colors would also be used by many pages on other editions of Wikipedia, which would all have their own citation styles presumably.
    Setting the style wouldn't be difficult. Presumably, we would default to CS1 style, which is used on an overwhelming majority of college sports articles that I've encountered. But this could be easily overridden either on a per-use basis (e.g. {{College color boxes|citation=cs2}}) or on a per-article basis, using something like {{Use CS2}} (which could work in the same way that templates like {{Use mdy dates}} work currently). Presently, the module's citations are not transcluded onto articles at all, so this is all hypothetical for now. –IagoQnsi (talk) 19:52, 26 August 2020 (UTC)[reply]
    @IagoQnsi: At present, any article that wishes to use the citation stored in the module can do so trivially. The citations stored in the module are an almost equal mixture of {{cite web}} and {{cite manual}} with a couple of {{cite book}}.
    You claim "Setting the style wouldn't be difficult ... this could be easily overridden ... using something like {{Use CS2}}" Here's a citation: {{cite manual |url=http://www.thepacwest.com/documents/2015/6/22//pacWest_colorways_spring2015.pdf |title=Pacific West Conference Visual Identity Standards |accessdate=March 23, 2017}}. I'd like you to show me how it isn't difficult to set CS2 for it. Please let me know roughly how long I'll need to wait for your solution. --RexxS (talk) 21:30, 27 August 2020 (UTC)[reply]
    @RexxS:If you have that citation stored in Wikidata, it's very easy to spit it out in either style. The parameters are exactly the same between {{cite manual}} and {{citation}}; in fact, they both rely on the same underlying module. Our template would pass all the reference parameters to Module:Citation/CS1, then set the CitationClass to "citation" if the page uses CS2, or to one of the CS1 values (e.g. book, web, news, etc) if the page uses CS1. There would have to be a little bit of logic to decide which CS1 value to use — basically, if the reference includes a type of reference (P3865) value, we'd just use the CitationClass that corresponds to that media type; otherwise, we'd make a best guess based on the included properties, much like how {{citation}} does. –IagoQnsi (talk) 22:45, 27 August 2020 (UTC)[reply]
    @IagoQnsi: Okay, show me. I'm really interested in that "little bit of logic to decide which CS1 value to use". Then I'll ask you how you'll deal with chapter and article titles that are defined differently in CS1 and CS2. --RexxS (talk) 23:20, 27 August 2020 (UTC)[reply]
    @RexxS: If type of reference (P3865) is set, then we can just have a 1-to-1 array mapping of reference type items to CitationClass values (e.g. map book (Q571) to CitationClass='book', etc). If P3865 isn't set, then we look at what properties are set. A very rudimentary solution would be to use 'book' if volume/edition/page are set, and otherwise use 'web'. That's not a robust solution, sure, but it's already more than enough to handle all of the existing references on this module. I'm not proposing we migrate every citation on Wikipedia to Wikidata; I'm just proposing we migrate the ones in this module. The implementation will get better with time if it's being used and edge cases begin to crop up. –IagoQnsi (talk) 23:56, 27 August 2020 (UTC)[reply]
    @IagoQnsi: You don't seem to have shown me anything. And I'm afraid that type of reference (P3865) doesn't mean what you think it does. --RexxS (talk) 00:14, 28 August 2020 (UTC)[reply]
  • Oppose, as I will continue to oppose any of the many attempts to cause this project to rely more on Wikidata via the back door. DEsiegel has it right in this instance. However bad things might be here, they are not better there. - Sitush (talk) 19:48, 13 August 2020 (UTC) But, hang on, the discussion seems to be elsewhere? - Sitush (talk) 19:49, 13 August 2020 (UTC)[reply]
  • Support I'm usually suspicious of migrating things to WikiData, but this seems low risk in terms of vandalism. Most people will recognize if the value is not a color, and even if subtle, it should be obvious from all the images what the correct colors are. Others note that there are content improvements that can be made if migrated, so seems like a net improvement. — Wug·a·po·des​ 19:57, 13 August 2020 (UTC)[reply]
  • Support. Exactly the sort of data Wikidata works best for. – Finnusertop (talk ⋅ contribs) 02:34, 14 August 2020 (UTC)[reply]
  • Oppose. Above, IagoOnsi claims "there are plenty of ways to monitor the data and combat vandalism." and adds a query that one can use. Problems; this is an extra step one must take (not integrated with the watchlist), on a different site, and gives poor results. Not only does it not show what was changed or in which diff (only a date), but it includes changes having nothing to do with changing the colour. E.g. there is an entry for 24 May 2020 for the Portland Pilots; but the only change on that date is a bot adding a Chinese label[3]. The query doesn't filter out or indicate bot changes. Apparently the query shows pages where the official colour has been changed at some time in the past, and shows the date of the most recent change to the Wikidata item, no matter what that change was. Which means that contrary to the claim, it is impossible to monitor this with that query, as the most recent entries will not show recent changes to colour, but any recent change whatsoever. I see no reason to change a woking system to one that is harder to monitor. It would be better, if there is a need for the other Wiki-languages, to write a bot that copies changes to the module here, over to Wikidata, keeping Wikidata in sync with us. But giving control of this to Wikidata? No, thanks. Fram (talk) 11:51, 14 August 2020 (UTC)[reply]
    • @Fram: Apologies for that issue with the query; I didn't catch that. However, the approach of having a bot update a list with a query would still work as intended. If we had a bot update a locally-stored list with the results of this query every day/hour/whatever, then it would be easy to monitor changes by adding the list page to your watchlist. The list page would only get updated when a color is changed. –IagoQnsi (talk) 04:46, 18 August 2020 (UTC)[reply]
  • Oppose per DES. and Fram. Suggest someone from Wikidata make a copy of this material and post it there for use on other wikipedias if they want it. But zero benefit for en-WP in migrating our own hosting of this data, and non-zero risk in terms of reduced editability by local contributors. -- Euryalus (talk) 12:10, 14 August 2020 (UTC)[reply]
  • Oppose in practice. It's a noble idea which could work well if Wikidata had as many eyes on it as enwiki does. However, it's so tempting to change one's rival's colour scheme to poop and vomit, and a casual editor who notices may not find their way through the maze of code and data to the source of the problem. mw:Multilingual Templates and Modules may be a good alternative. Certes (talk) 12:40, 14 August 2020 (UTC)[reply]
    Why would multilingual templates on MediaWiki.org be less prone to vandalism than statements on Wikidata? * Pppery * it has begun... 13:52, 14 August 2020 (UTC)[reply]
    A good question. Perhaps they are harder to find and edit, and would be on the coder's watchlist. If mw: is prone to vandalism then we should leave things as they are. Certes (talk) 13:58, 14 August 2020 (UTC)[reply]
    (ec) I guess that, unlike the free for all Wikidata is, the intention is to make those multilingual templates only editable by a group comparable to our template-editors (but obviously not restricted to enwiki editors)? If not, then this is not a solution of course. Fram (talk) 14:00, 14 August 2020 (UTC)[reply]
    I'm probably not the best person to answer this because I strongly oppose Multilingual Templates and Modules for reasons unrelated to their proneness to vandalism (which I explained best at mw:Global templates/Discuss/oppose), but I'm not aware of any established plan to restrict who can edit them. Furthermore, non-trivial multilingual templates often depend on tabular data on Commons, which likewise might need to be protected to prevent vandalism. * Pppery * it has begun... 14:39, 14 August 2020 (UTC)[reply]
    It appears that that project has shifted to using a tool instead of a bot, which obviates the concern about vandalism to the templates themselves. There is still the, probably more important, concern about vandalism to Commons datasets the template uses, and of course my independent concern about perpetuation of code bloat. * Pppery * it has begun... 16:24, 14 August 2020 (UTC)[reply]
  • Support, per GreenC, Mike, and others. Rehman 13:26, 14 August 2020 (UTC)[reply]
  • Oppose This seems very much like a solution in search of a problem, since, as DESiegel says, Wikidata could import data from the English Wikipedia module and therefore help other wikis even if this proposal fails. * Pppery * it has begun... 13:52, 14 August 2020 (UTC)[reply]
    • @Pppery: It's easy enough to have a bot import the data once, but it's hard to keep the data in sync as time goes on. Any new edits on enwiki need to be re-imported, either manually or by a periodically running bot (but there's no easy way for a typical Wikidata user to be sure that such a bot is still up and running). And if new edits are made on Wikidata, it creates a conflict that can't be resolved by a bot. The overall effect is that anyone using the color data via Wikidata is getting an inferior/untrustworthy version of it. –IagoQnsi (talk) 05:14, 18 August 2020 (UTC)[reply]
  • Oppose per Fram, Certes, Euryalus, and Pppery. The whole point of creating this in the first place was to have all the color data collected at one centralized location. If WD wants to make a copy of this to help other wikis, that's fine, but spreading this data out over hundreds of pages is literally what we had before this module was created. Nobody wants to go back to that chaos. Ejgreen77 (talk) 07:37, 16 August 2020 (UTC)[reply]
    • @Ejgreen77: This wouldn't create chaos like existed in the pre-module days. The issue we used to have is that the colors were stored in dozens of articles, and had to be manually synced. On Wikidata, just like in the module, they will only be stored in one place: the team's item. All the dozens of articles about, say, Duke Blue Devils teams will pull the school colors from Duke Blue Devils (Q2907160). And it's easy to query Wikidata to show all the colors on one page, such as with this query. –IagoQnsi (talk) 05:01, 18 August 2020 (UTC)[reply]
      • Even so, there are still hundreds of entries in the module currently, so all of those entries will each be stored at their own separate location. The whole point of creating this in the first place was to store all the data at one centralized location to make it easy to monitor. Ejgreen77 (talk) 10:42, 26 August 2020 (UTC)[reply]
  • Oppose While there may be some valid uses of Wikidata to store information for use on Wikipedia, it is becoming increasingly apparent that it can no longer be trusted to maintain data in a usable structure. This collection of related data is best kept in a single location under enwiki control. --RexxS (talk) 18:42, 16 August 2020 (UTC)[reply]
    • @RexxS: Besides our disagreement on the issue of citation style, I haven't seen any discussion about the structure of the data. On the module talk page, I showed how I expected the data to be structured with an example: wikidata:Q2892868#P6364. I welcome criticism, but I haven't seen any yet. Cheers, IagoQnsi (talk) 20:38, 27 August 2020 (UTC)[reply]
    • @Mike Christie and Johnbod: You both cited RexxS's comment above as your reason for opposing the proposal. I am curious to know what parts of the Wikidata structure you find to not be usable. Is it the citation style concerns RexxS raised earlier in the discussion, or is it something else? No one else has weighed in on myself and RexxS's citation style thread, so I have no sense of the broader community opinion. Thanks, IagoQnsi (talk) 20:38, 27 August 2020 (UTC)[reply]
      • Mike said "per many of the above comments; RexxS sums it up well" & I said "per RexxS and others". I think RexxS's summary is clear enough, & there are many points others have made. Johnbod (talk) 21:16, 27 August 2020 (UTC)[reply]
        For me, the key point RexxS made is it is becoming increasingly apparent that it can no longer be trusted to maintain data in a usable structure. Updating short descriptions is a huge use of enwiki resources that could be better directed elsewhere, but it has to be done because vandalism to the corresponding Wikidata descriptions is, practically speaking, invisible to watchers here. That soured me on using Wikidata for anything that could be equally well done here. Unless there are obvious major benefits to the move, I don't want to see enwiki move information to where it cannot be monitored and managed (and protected) locally. Mike Christie (talk - contribs - library) 21:36, 27 August 2020 (UTC)[reply]
  • Oppose now Proponents of this idea are free to copy color information to Wikidata and to develop modules for use on other Wikipedias. After six months of successful operation, this proposal could be considered for enwiki. However, until then, having all the information on one page is known to work and is known to resist subtle errors and outright vandalism. At enwiki, anyone can propose a color change but only template editors can edit. At Wikidata, any IP can change colors in any of the 1140 locations. Johnuniq (talk) 09:52, 18 August 2020 (UTC)[reply]
    • @Johnuniq: Wikidata's protection policy says that all items used on over 500 pages should be semi-protected. Each school's colors are used on several hundred pages, and with the likely advent of other wikis making use of these colors, it is likely that a request for semi-protection would be approved if this proposal happened. –IagoQnsi (talk) 20:59, 27 August 2020 (UTC)[reply]
      • Anyone is welcome to copy all the data to Wikidata and set up whatever is needed to make it work in articles. Then test it at various Wikipedias (not enwiki) and see how it goes for six months. After that, come back and make a proposal to use it here. Johnuniq (talk) 23:48, 27 August 2020 (UTC)[reply]
  • Support per all of the support !votes above. I only recently started interacting with the whole college colors apparatus, and it's a horrible hack that requires a template-protected edit request just to add a missing school. This is an ideal value to store at Wikidata, where it can be available to all languages and others who seek to use it. Regarding abuse, I just don't see vandals really wanting to change Foobar University from red to blue or succeeding at doing so off the radar. {{u|Sdkb}} talk 07:46, 24 August 2020 (UTC)[reply]
  • Support this is a value in a template that a user currently can't edit in the way templates are usually edited in Wikipedia. Having to go to https://en.wikipedia.org/wiki/Module:College_color/data to edit the data is completely counterintuitive. ChristianKl ❪✉❫ 15:04, 26 August 2020 (UTC)[reply]
If having to go to another page on Wikipedia is counterintuitive ... wouldn’t having to go to a completely different WEBSITE (Wikidata) to edit be a lot MORE counterintuitive? Blueboar (talk) 16:41, 26 August 2020 (UTC)[reply]
@Blueboar: Using a Wikimedia sister site shouldn't be too hard; Commons doesn't seem to trip people up too much. If you're able to navigate the current chain of {{CBB roster}} --> {{CollegePrimaryStyle}} --> Module:College color --> Module:College color/data, you'll probably be able to figure out Wikidata too. –IagoQnsi (talk) 17:32, 26 August 2020 (UTC)[reply]
  • Oppose, per many of the above comments; RexxS sums it up well. Mike Christie (talk - contribs - library) 17:36, 26 August 2020 (UTC)[reply]
  • Oppose, per RexxS and others. Johnbod (talk) 18:06, 26 August 2020 (UTC)[reply]
  • Comment - I have been thinking about why I am so negative about Wikidata. And have realized that it comes down to some very simple reasons. First, I am text oriented and not data oriented. I simply don’t see the world in terms of bits of data to be stored and retrieved. Second (And more important), I am an older person, and easily confused by all this whiz bang technotify stuff. I hate templates (with all their confusing parameters and fields) and avoid them if I can (for example, I don’t use citation templates, and still do all my citations by hand using <ref>text</ref> formatting.) However, I find templates a breeze compared to editing Wikidata. I tried, and very quickly gave up. To put it bluntly... I feel that I am UNABLE to edit wikidata. When we move things to Wikidata, they become out of my reach as an editor. If I needed to edit information pulled from Wikidata, I COULD not do so. So much for “anyone can edit”. Blueboar (talk) 21:53, 27 August 2020 (UTC)[reply]
  • My opinion is that the citation discussion above is largely a red herring. That's a question of implementation and I'm pretty sure Trappist if no one else could provide a functioning citation in CS1 or CS2 for the reference data related to each color (and I can pick out at least one other user who could do it as he's basically done it already with another template).

    I have at least one or two interests of discussion, the first of which is the question of implementation of the colors. From memory (mobile > me), the college colors module doesn't always provide true colors in the interest of accessibility and being able to ensure that fore and background colors meet AA compliance (or sometimes we add colors in the particular school theme which moderate this question but which are not official). This is not data that Wikidata should want to take and I certainly would not want to foist it on them. How would you propose working around that (assuming my question is not off base)?

    My second interest pertains to use not on the main school page (navboxes among others), which can sometimes add to the expensive operation count. Do you have an implementation in mind which would sort that?

    Given the use in navboxes, I am unsure if this is data we should use from Wikidata. It is almost certainly data they would be interested in (pending q1) and so moving/copying the data there would no doubt be appreciated. --Izno (talk) 21:57, 27 August 2020 (UTC)[reply]

    • @Izno: Good questions! I was not aware that any of the colors in this module were not official. How are these unofficial colors chosen? If they are being systematically derived from the official colors, then I imagine we could store only the official colors in Wikidata, and have our module on Wikipedia derive the accessible colors as it retrieves them. If they're being chosen some other way, then we might want to figure out some schema for storing them, perhaps using nature of statement (P5102) to distinguish official and unofficial colors. I think it'd be useful to have these unofficial colors stored in Wikidata as well; AA compliance is something that all Wikimedia projects would be interested in, not just us. It's just a matter of finding a good way to delineate them from the official colors.
    • As for the expensive operations issue, I didn't have a particular implementation in mind. One method that would be easy enough would be to have a bot update a local page every hour with the results of a query for all the college colors, and then have the template/module pull the color from there instead of directly from Wikidata. That wouldn't be such a great solution in the long-term if we were to expand this to be used for more than just college sports, but perhaps there are other ways to efficiently cache this that I'm not aware of, or perhaps it's something that could be raised with the Wikidata Lua developers.
    • We could also just allow a single expensive query to be used here. Most articles only use colors from a single school, so it wouldn't be a very big deal. There are a few articles such as Atlantic Coast Conference which use colors from many schools, and we'd want to have a better solution for them. We could perhaps have a bot use a SPARQL query to update articles that use many schools' colors on an hourly basis. But in the short term, I don't think there are any pages that use enough different schools' colors to hit the expensive function limit, so we don't necessarily have to have a finalized solution for this just yet. –IagoQnsi (talk) 23:42, 27 August 2020 (UTC)[reply]
  • Oppose for now per Johnuniq. I am willing to reconsider after seeing it demonstrated and proved to work better than the current system in practice, including ease of use to people unfamiliar with either system, lower workload for editors, compliance with MoS, and resistance to vandalism. · · · Peter Southwood (talk): 13:55, 28 August 2020 (UTC)[reply]

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

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

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

Survey: IMDb in the infobox

Survey: Critic review aggregations in the infobox

E.g. Rotten Tomatoes, Metacritic

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

Survey: Rotten Tomatoes vs. Metacritic for infobox

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

Misplaced !votes

General discussion

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

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

Auto-minimize Draft tags for Visual Editor like we do with cleanup/AfD tags

I’ve had bad user experiences (UX) while looking at Draft articles through the Visual Editor, which I use almost exclusively.

Instead of seeing the article itself, they’ll have massive templates that have to be scrolled through every time you want to see—let alone edit—the article.

In contrast, when I look at an article in main space that has a cleanup or AfD tag, it’s unobtrusive and minimized, and expands when you click on it. I think the various Draft tags should be likewise automatically minimized until they are clicked on. I think newer users especially would feel more comfortable continuing to improve the article if there wasn’t massive rejection tags atop them that have to be traversed every instance. Gleeanon409 (talk) 13:19, 18 August 2020 (UTC)[reply]

Gleeanon409, sounds reasonable to me. I'm not sure what the technical mechanisms at play are. {{u|Sdkb}} talk 19:06, 18 August 2020 (UTC)[reply]
Gleeanon409, could you please give me a couple of links to a "worst-case" draft, and a contrasting article with cleanup or AFD tags? I can file a bug report if the problem is in the VisualEditor instead of in the template design. Whatamidoing (WMF) (talk) 04:10, 20 August 2020 (UTC)[reply]
@Whatamidoing (WMF):,Dumb Show vs. Draft:Tor'i Brooks. Gleeanon409 (talk) 07:26, 20 August 2020 (UTC)[reply]

What needs to take place to make this happen? Gleeanon409 (talk) 12:46, 24 August 2020 (UTC)[reply]

@Gleeanon409, it looks like the problem is that the (very large) AFC box has several collapsed sections. When those are expanded, the whole thing is enormous. This can't be fixed in the visual editor, which treats all collapsisble content the same, and specifically uncollapses them (e.g., so you can make sure that you've added the correct navbox). But it might be possible to fix this in the template, using something like {{if preview}} to keep the content collapsed state. @Evad37, do you think that might work? Whatamidoing (WMF) (talk) 17:28, 24 August 2020 (UTC)[reply]
@Whatamidoing (WMF): Template:If preview doesn't work with visual editor - e.g. https://en.wikipedia.org/w/index.php?title=Template:If_preview/doc&veaction=edit shows the "when saved" values in the examples column, not the "when previewed" values. - Evad37 [talk] 01:16, 27 August 2020 (UTC)[reply]
Well, there goes that idea. Maybe we should take this to WP:VPT? Whatamidoing (WMF) (talk) 01:35, 2 September 2020 (UTC)[reply]

Deindexing talk pages

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

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

Technical notes

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

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

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

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

Discussion (deindexing talk pages)

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

    Adding __NOINDEX__ to the millions of archives

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

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

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

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

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

Flag edits for review

Discussed a bit at Wikipedia:Village pump (idea lab)#Flag edit for review? where I was encouraged to bring my idea here to see whether there might be community consensus. My idea is that we establish, similar to the thanks functionality, the ability to flag edits for review by other editors. This could be useful in cases where an editor sees a problematic edit but doesn't have the time to address the problem properly, or when an editor sees an edit that they feel is potentially problematic, but they don't have the experience or confidence to know for certain and don't wish to stick their foot in it with an inappropriate revert. Flagged edits could be highlighted in watchlists, and perhaps captured for review in other manners as well. There could also be a mechanism whereby editors could unflag edits that they believed to be comfortably unproblematic.

Beyond tagging other editors' edits for review, this functionality might more easily allow editors to ask others to review their work. I'm unsure how much this might actually be used in such a capacity, but it doesn't seem like a bad idea. As an example, I've sometimes tried to edit tables but haven't been able to get them looking the way I intended. Flagging my edit would be a quick way to get the attention of other editors.

It was suggested at the linked discussion that this could be technically accomplished without significant difficulty thusly: "extend the changetags right to more users (admins + rollbackers?) and create a new tag named "flagged for review"(?)".

There are some obvious potentials for problems here, which were also discussed at the idea lab: for instance, it might be easy enough to harass another editor by flagging their edits, and enabling this functionality might make editors less likely to "push the button" themselves. In the end though, I'm not sure there's a good way to establish whether this enhancement would be abused enough to be a concern without making it available and seeing how it goes.

I welcome other editors' opinions on this; thanks for your time! DonIago (talk) 14:31, 25 August 2020 (UTC)[reply]

  • @Doniago: I don't like the idea of adding a tag or a template in the hopes that another volunteer will take on the work. I think that it would be better instead to revert the potentially problematic edit and then start a discussion on the article's talk page, following WP:BRD. Or not revert it and post on the talk page about it. If you don't have time to do even that much, then just come back to it later when you can be WP:BOLD and fix whatever might be wrong. There is also WP:RCP recent changes patrol that is watching for problematic stuff. RudolfRed (talk) 16:45, 25 August 2020 (UTC)[reply]
  • Doniago, we already have a feature like that. It is called Pending Changes. When this is enabled, all edits must be approved before they are visible to readers.
I have edited wikiHow, a separate wiki, and they do just that. But the reason why they can do that is because their community is small enough that it is easy to revert vandals. But on Wikipedia, we have 10-40 edits per second. If all of those edits had to be reviewed before hand, then it would create an unnecessary burden on editors.
We do have anti vandalism bots revert potentially problematic edits and we do have ORES which shows edits that likely need review, but we do not force every single edit to be patrolled. That would create a huge burden on editors managing backlogs. In theory, we could do that, but in practice, we don't. Aasim 18:25, 25 August 2020 (UTC)[reply]
I think you misunderstood me; my proposal is for a manual feature that would allow human editors to tag edits as potentially problematic. I'm not proposing any sort of backend process to automatically tag edits as needing review. DonIago (talk) 18:51, 25 August 2020 (UTC)[reply]
I think they are saying what is the point of that if you can just undo edits. Emir of Wikipedia (talk) 21:20, 25 August 2020 (UTC)[reply]
And his response is that there are non-clear edits where someone doesn't feel confident undoing (even undoing and starting a discussion) but thinks someone else might be better able to make a discussion. I'm personally unsure whether the positives outweigh the negatives of reducing number of clearcut action. Nosebagbear (talk) 21:23, 25 August 2020 (UTC)[reply]
The German Wikipedia has enabled something like "Pending changes"/"Flagged revisions" as well. It differs in the details from our configuration. Either way, the proposal here is kind-of-the-other-way-around, changes are published by default, but could be flagged for review (without unpublishing them until reverted) if someone finds them questionable. So, it's on a middle ground between the extremes. I like that. --Matthiaspaul (talk) 18:39, 28 August 2020 (UTC)[reply]
  • I would like to see something along these lines. As a gnome, my watchlist flags many changes on topics I know little about. Today, for example, an IP changed the ethnic origins of several dances, which is suspicious but not obviously wrong. I've left a message at a Wikiproject in the hope that someone with a clue will check, but the process might be smoother if there were some sort of flag I could wave. Certes (talk) 22:08, 25 August 2020 (UTC)[reply]
Certes, if I remember correctly, admins have the ability to edit tags for a particular diff. That means if there are two bad edits, they can mark it as vandalism. Bots can do the same. But it would be nice if this can be expanded to rollbackers so we can apply appropriate tags to an edit. Aasim 22:34, 25 August 2020 (UTC)[reply]
The flag might be most useful for non-admins; something an ordinary editor can use to say "please can an expert take a look at this?". If it's for admins only then it might still be useful, but possibly not worth bothering to implement for a small audience who already have other methods available. Certes (talk) 23:31, 25 August 2020 (UTC)[reply]
  • I'm skeptical of this idea because it's not clear what the limits on such a feature would be. Without clearer guidelines on when it would be appropriate to assign an edit a vague "needs review" tag, I fear it would lead to a similar situation we saw with {{cleanup}}, which is an article maintenance tag that reads simply, "This article may require cleanup to meet Wikipedia's quality standards". For many years some editors placed this extremely vague tag without providing any elaboration on how the articles needed cleanup. This was clearly undesirable, and in 2012 a request for comment finally made the |reason= parameter of the tag mandatory. On a similar vein, this proposal does not seem different from the creation of an inline version of {{cleanup}}, which is undesirable if there is a more specific tag that would better inform why the content needs attention, e.g. {{citation needed}}, {{dubious}}, or {{POV statement}}. See also Template:Inline cleanup tags for more of these alternatives. Mz7 (talk) 01:25, 26 August 2020 (UTC)[reply]
I agree that implementing the cleanup template without requiring clarification was a misstep. That said, I don't think the reasons why one might find themselves wanting to use this tag can be easily pigeonholed into existing or possibly new templates; if they could be, I'd be advocating for the creation of a new template right now. :)
As an arbitrary example - I'm reviewing my watchlist, and I see a film article listed on it. The diff shows that an editor has restructured some existing text addressing the film's reception, and added information regarding how great (or terrible!) several well-known film directors considered the film to be. Is this information appropriate for addition to the article? Yes, because they're well-known film directors and their opinions matter. No, because they aren't known for being film critics and their opinions don't deserve more weight than others. Maybe, because it is multiple film directors weighing in on a classic film. I'd like to dig through this, but one of those life circumstances comes up that requires I step away for an unknown duration. There isn't time for me to start a cogent Talk page discussion, and there isn't really an appropriate template that immediately comes to mind. If I can flag the edit, then even if nobody else gets to it anytime soon, it will still be outstanding, and perhaps I myself will see it.
I hope this is helpful! I agree with other editors in that I'm not really sure how great an idea this is or whether the potential cons outweigh the pros, but it seemed to merit a hearing at least. Cheers! DonIago (talk) 17:24, 26 August 2020 (UTC)[reply]
  • I believe Huggle has similar functionality, but that would only really appear to blatant vandalism (which is basically the purpose of Huggle). As far as this functionality goes, it would require development effort, and as everyone knows: you're only going to get the dev time to implement a non-trivial feature if you top the Community Wishlist for 3-4 years in a row, then wait another 3-5 years for resource allocation. Even then it's a maybe. So realistically, probably not happening. Closest we could get to this is a userscript which provides a button to send an edit into a central repository (like WP:CCI), or just an easier way to send an edit to a certain Wikipedian's talk page for them to look at. But I imagine the functionality would quickly get overwhelmed, to be honest. ProcrastinatingReader (talk) 20:41, 26 August 2020 (UTC)[reply]
    @ProcrastinatingReader: This doesn't require any development time as the infrastructure already exists. The only changes needed is the extension of the changetags right to user groups other than admins (which is trivial) and creating a new tag (which can done locally by an admin). The only thing that's really required here is the community consensus. – SD0001 (talk) 10:18, 31 August 2020 (UTC)[reply]
    SD0001, if I understand correctly, giving those changetags rights also allows people to remove tags? example url, and see rights: Add and remove arbitrary tags on individual revisions and log entries (changetags). I don't think it's possible to unbundle that functionality, and obviously we don't want to allow people to be able to remove tags. Whilst we could sidestep it (eg a bot reverting any removals of tags that aren't this tag, or patrollers viewing the log for tag changes), I still indifferent about it. A better way may be to 'tag' revisions using a script (add into Twinkle, perhaps?) which adds a hidden template to an article with revisions as its parameters. A bot compiles a list of such revisions (ie, transclusions of the template with specified revisions). ProcrastinatingReader (talk) 11:27, 31 August 2020 (UTC)[reply]
    Meh, if someone has the right to add tags, it is natural to let them remove tags as well. I don't see what's controversial about that. "Tagging" revisions using a script creates a new entry in the page history, plus the tag would have to be removed as well which clutters the history. OTOH by using the native tagging feature, we're only cluttering the tag log which no one is looking at. – SD0001 (talk) 11:48, 31 August 2020 (UTC)[reply]
    SD0001, what I mean is: the issue is that they'd be able to remove existing tags (like editor used, mobile, etc.). Removing the tags they've added is fine, but not the other tags. ProcrastinatingReader (talk) 12:16, 31 August 2020 (UTC)[reply]
  • I like this proposal, in particular if the flagger would be able to specify a reason from a predefined list of possible reasons, or even to leave a visible comment, so that it would be easier for other editors to know what they should be looking for.
There is some potential for abuse, so we should allow this only for logged in users beyond some threshold, but the threshold should be reasonably low so that many users could use it. It could also be useful to select if the review-tag should be publicly visible or only for personal use, listed in a special internal list for later review (when time allows).
The alternative today is to improve on an edit (ideal, but often not possible due to lack of time), revert it or open a talk page thread, but the later two options often create unnecessary stress and drama for issues that could be solved in much more subtle, relaxed and friendly ways given enough time and man-power to look at an edit.
--Matthiaspaul (talk) 18:39, 28 August 2020 (UTC)[reply]
I imagine adding a predefined list would make this more technically complex, but I'm not sure whether it would be significantly more complex. I'm not sure about a visible comment, as at that point you could pretty much make a dummy edit. Agreed on limiting it to logged-in users. As newer editors are perhaps more likely to rely on this functionality were it available, I concur that a low threshold would be nice as well.
My feeling is that a review-tag should be publicly visible so that other editors can review as well and possibly address the issue...or if they feel there's no issue, untag the edit.
Thanks for your thoughts! DonIago (talk) 19:18, 28 August 2020 (UTC)[reply]
The facility to specify a reason also already exists, see Special:log/tag. – SD0001 (talk) 10:22, 31 August 2020 (UTC)[reply]
I'm concerned that this could become a "troll's charter". Following a user around flagging everything they're doing, or flagging an edit because you disagree with a political or other stance, or maybe an MP or similar could flag an edit which is a truth they're inconvenienced by. What safeguards are there to stop edit tagging becoming manipulative? doktorb wordsdeeds 10:02, 2 September 2020 (UTC)[reply]
Besides the fact that that would be harassment and a blockable offense? DonIago (talk) 13:51, 2 September 2020 (UTC)[reply]

Displaying A-class topicons

Hello everyone, my name is Rebestalic

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

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

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

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

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

Move protected topicons

Do we really need them? I've always thought they're a pretty useless icon to have, and it just adds bloat. Almost nobody is trying to move these articles, the icon is just clutter and should be removed imo. Wild example, Frank Sinatra. If it's the categorisation we need, we can keep the template/bot as now, and just edit {{pp-move}} to remove the topicon part. ProcrastinatingReader (talk) 17:52, 27 August 2020 (UTC)[reply]

Agree. {{u|Sdkb}} talk 08:51, 31 August 2020 (UTC)[reply]
  • Remove. The menu does not offer the move option (if you do not have the permission to move the article), which has to be enough of a clue should somebody try to move it. There is a small logic for having the protection status (maybe with the reason stated) as one of the items at the start of the talk page. — GhostInTheMachine talk to me 09:22, 31 August 2020 (UTC)[reply]
    The move menu offers the option if you can move the page. A page can be move protected at, for example, the extended confirmed level, leaving the option to move it available to you but not newer editors. ~ Amory (u • t • c) 10:13, 31 August 2020 (UTC)[reply]
    I think that's what Ghost was getting at? That one can only see the move button if you have the permission to move it. ProcrastinatingReader (talk) 12:47, 31 August 2020 (UTC)[reply]
    Indeed, thus: the move button is a reliable indicator of whether or not you can move a page, but not a reliable indicator of whether a page is move-protected, which is what the icon indicates. Similar for "view source" vs "edit" for edit protection. ~ Amory (u • t • c) 18:30, 31 August 2020 (UTC)[reply]
    Ah, I follow now. Does that specific case matter, though? I mean, almost all editors (and certainly 99.9% of readers) don't really care if a page is move protected, regardless of whether they can move it. Maybe an editor here or there does (and they can click "page information"), and such editors would usually be regular editors of the page, but imo it doesn't justify showing that useless icon to every single editor & non-logged-in reader. If should be shown at all, I think it should be opt-in (by means of a gadget, or so), rather than default for all. ProcrastinatingReader (talk) 19:37, 31 August 2020 (UTC)[reply]
    I've not expressed an opinion, just pointing out that the two are not interchangeable as they do not convey the same information; whether it matters is up to you. Readers can never move a page (assuming readers==not-logged-in), so the icon is actually the only way to convey the information. Again, I analogize to "view source" for edit protection. ~ Amory (u • t • c) 00:12, 1 September 2020 (UTC)[reply]
    so the icon is actually the only way to convey the information what about clicking "Page information", eg [8] ProcrastinatingReader (talk) 11:00, 1 September 2020 (UTC)[reply]

Cleaning up after #WPWP edits

As a result of the Wikipedia Pages Wanting Photos campaign running on Meta since July and ending this 31 August, there have been a lot of poor-quality edits by editors who are unfamiliar with the image use policy/MOS and/or just don't care about quality. Some had incorrect image placement, some introduced bad captions, some inserted totally irrelevant images, and some completely broke infoboxes and other templates. Since a lot of the affected articles are of obscure unwatched topics, a coordinated clean-up effort might be needed. Maybe a centralised noticeboard to identify problematic editors and check their contributions? There was earlier discussion at AN but it didn't seem to reach any conclusion. --Paul_012 (talk) 09:27, 28 August 2020 (UTC)[reply]

I'd note that we do have 1073 to log these, so it's not hard to track, but there's 32k hits. ProcrastinatingReader (talk) 14:13, 28 August 2020 (UTC)[reply]
Thank you, ProcrastinatingReader. I missed that the edit filter had already been implemented. Would you know if there's a way to get a de-duplicated list of users who have triggered the filter, so that spot checks can be done? --Paul_012 (talk) 17:02, 28 August 2020 (UTC)[reply]
That edit filter ought to be changed and set up to disallow the edit and then from this point forward this event should by all means be banned on this project, It's disruptive and to be very blunt it's a pain in the ass for us who have to go through everyones contribs checking each and every edit. –Davey2010Talk 20:51, 30 August 2020 (UTC)[reply]
It's great that we have new editors as part of this, even if they aren't doing things quite right yet. I hope that you're welcoming them and teaching them how to best edit Wikipedia. Thanks. Mike Peel (talk) 19:35, 3 September 2020 (UTC)[reply]

Blanking expired editnotices

Notification of a discussion at Wikipedia talk:Editnotice proposing maintenance cleanup of expired editnotices by blanking, here. ProcrastinatingReader (talk) 14:08, 28 August 2020 (UTC)[reply]

Add ESRB/CERO/PEGI rating to video game listings.

As the name suggests, it would be very beneficial to add the game's rating to the right side information panel.

This could also have the added advantage of linking back to the ratings page (because CERO A, B, C, etc to me is very confusing unless you look at their meanings/age range).

As there are many systems around the world, maybe either a regional setting based on site translation (like UK only seeing PEGI, Germany only seeing USK, etc), and having the .com article contain the main release areas (usually Japan, North America, and Europe). --2600:1702:260:9100:C184:A0D6:6368:8E56 (talk) 05:27, 29 August 2020 (UTC)[reply]

They used be included but were removed by consensus years ago Template talk:Infobox video game/Archive 11#Propose removal of ratings section.. Any proposal to add them again would need to explain what changed since that discussion and WP:VG should be informed of this discussion.--67.68.208.64 (talk) 13:40, 29 August 2020 (UTC)[reply]
We remove them because there are so many, not all games get them, and that no other media that has ratings (like film and TV) also includes them. If the rating is of importance (like for being banned in a country) we'll cover it in the body. --Masem (t) 20:47, 29 August 2020 (UTC)[reply]
The worldwide aspect makes this such a non-starter for me. A worldwide game is rated on several different boards (and they do get changed over time). As Masem says if a game has anything particularly notable about its rating, it can be prosified. Best Wishes, Lee Vilenski (talk • contribs) 07:39, 30 August 2020 (UTC)[reply]
Oppose strongly The ratings provide little in context. The only time they provide value is when there's controversy surrounding it and the articles for those games usually have those details described. – The Grid (talk) 14:20, 31 August 2020 (UTC)[reply]

Second Wikipedia Blackout??

WP:SNOW
Getting a bit chilly towards the end of August... Ed talk! 16:44, 30 August 2020 (UTC)[reply]

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


In case you do not know, US transactions with TikTok and WeChat will be banned soon. I just watched a video by Vox [9] about how such a ban poses a threat to the open Internet. I was wondering should we black out Wikipedia on the day the site gets banned? We did this in 2012 when Congress was considering SOPA and PIPA. I think raising awareness of this issue may help raise issues about the current threats in the United States to the open Internet.

"But it is Chinese apps getting banned, not Wikipedia!" - firstly, this is in the United States, a country that has for a long time embraced the open Internet and secondly, the Internet landscape across all countries is changing rapidly to embrace censorship and block freedom of speech. If we decide to black out Wikipedia for a second time, how long should we do it, what pages should be blocked (if any), and when should we stop the blackout? We want a free and open Internet. Sure not everyone likes TikTok, but if TikTok is banned in the US, who will be next? Google? Wikipedia? We do not know. And while it may be two Chinese apps, this will have long-lasting effects on how we view the Internet.

I am not making this proposal lightly, I recognize the amount of disruption it may cause to readers, editors, and the like. If this gets turned down, I will completely understand. After all, we are not supposed to promote a cause first, but I think given that we have done so before in 2012 means we could do so again. This may be a case of WP:IAR that we can invoke just this once.

If we were to black out Wikipedia a second time, I would suggest it be blacked out from 16 September to 18 September affecting all mainspace and portal pages except pages related to censorship and the threat the open Internet has. I recognize it may cause a lot of disruption to people accessing online resources, but it gives us what us Wikipedians want: a free and open Internet where we can access content freely and safely. We do not want websites blocked because people use them to organize sellouts or boycotts or to get revenge for COVID-19; by blocking content, it greatly impacts Freedom of Information.

I do not want this to sound super political, but an open Internet is what us Wikipedians have been fighting for for the past 19 years. We do not want paywalls or government censorship of Internet content; we want the ability to freely access and communicate information when needed. Aasim 09:30, 30 August 2020 (UTC)[reply]

  • Oppose- this is not the same as the SOPA/PIPA nonsense. Reyk YO! 13:07, 30 August 2020 (UTC)[reply]
  • Blackouts should be reserved for potentially existential crises, considering the huge negative impacts they have on readers. Using them for anything else cheapens them. – Teratix ₵ 13:09, 30 August 2020 (UTC)[reply]
  • Oppose I'm not opposed in principle to political action as a project when something directly threatens our work. But "some app" that teenagers use to share dance videos is pretty daggum far down the list of threats. GMGtalk 13:15, 30 August 2020 (UTC)[reply]
  • Oppose I am not opposed to any blackout, but they should only be used when there's an existential threat to Wikipedia (or potentially a sister project, if such a division could happen). Given that en-wiki opted against a blackout on the EU copyright amendments, it's going to take a truly drastic action to trigger another blackout. Nosebagbear (talk) 14:20, 30 August 2020 (UTC)[reply]
  • Oppose. This would be seen as a political protest, and we really need to stay out of politics. -- RoySmith (talk) 14:24, 30 August 2020 (UTC)[reply]
  • Oppose While there are existential risks at play with the TikTok/WeChat bans, they presently are very specific and do not directly threaten WP's model. Something like the various Section 230 laws and EOs being thrown around do, but so far its hard to do what affect they have so no need yet to cry wolf. --Masem (t) 14:30, 30 August 2020 (UTC)[reply]
  • Strong oppose per Blueboar. ―Mandruss ☎ 14:35, 30 August 2020 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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

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

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

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

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

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

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

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

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

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

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

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

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

Succession boxes for US Presidents

Following on from the discussion started here:

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

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

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

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

  • 2 - The information therein is somewhat redundant with the Preceded by and Succeeded by fields of {{Infobox officeholder}}, while far less visible and accessible being at the bottom of the article. What little anecdotal evidence we have (from editors who used to be only readers) suggests that readers rarely or never use the succession boxes. At Donald Trump, the boxes were removed after brief discussion in December 2018, and the only arguments in opposition to that have been that U.S. presidents' BLPs must be consistent. No one has even attempted to make the case that the boxes actually benefit readers enough to justify the space required, and I feel that would be a very difficult case to make. Ok, so let's make U.S. presidents' BLPs consistent. ―Mandruss ☎ 09:26, 1 September 2020 (UTC)[reply]
  • 2 - succession boxes are such an outdated navigation tool on en.wiki. We have as Mandruss pointed above, the relevant fields in the infobox, but also navigation templates such as {{US Presidents}} which already show the entire list. Succession boxes just add clutter as they are much more larger and offer no additional value. --Gonnym (talk) 10:28, 1 September 2020 (UTC)[reply]
  • 1 or 2 - but this should include all the US presidential & vice presidential nominees bios. GoodDay (talk) 14:16, 1 September 2020 (UTC)[reply]

Flatten your succession boxes and/or abs

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

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

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

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

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

Expansion of scope: succession boxes

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

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

Globally locked users should have their usernames in strikeout style

There's a gadget (Special:Preferences#mw-prefsection-gadgets / Appearance / Strike out usernames that have been blocked) which strikes usernames if they've been blocked. It seems (obvious) to me it should do the same for globally locked users. Has this been discussed before? Is there some reason it doesn't, other than it hasn't been implemented yet? -- RoySmith (talk) 13:22, 1 September 2020 (UTC)[reply]

RoySmith, there's a slow discussion/request at MediaWiki talk:Gadget-markblocked.js#Globally locked and blocked users Cabayi (talk) 13:54, 1 September 2020 (UTC)[reply]
Ah, cool. I've opened T261752, as suggested in that thread. -- RoySmith (talk) 14:08, 1 September 2020 (UTC)[reply]

Talk pages

On the talk pages of articles, it is often said "The talk page is for discussion of the article in Wikipedia, not for general discussion of the subject". However, if one reads what is said in talk pages, quite often the talk gets to be on the subject more than the article. Apart from abolishing talk pages altogether, which would be quite a radical proposal, should we allow discussion of the subject? Vorbee (talk) 06:05, 4 September 2020 (UTC)[reply]

  • At first take, I would say no. The guideline is a viable tool for intervening in disruptive discussions at talk pages. If anything, it should probably be upgraded to a citable policy instead of scrapped. VanIsaacWScont 06:17, 4 September 2020 (UTC)[reply]
  • This has always puzzled me. If I want to seek opinions on whether to add something to the article then this must result in discussion of the subject, more so than the article. If I want to suggest that someone with the requisite subject knowledge might add something to an article then ditto. Etc. Downsize43 (talk) 06:59, 4 September 2020 (UTC)[reply]
  • I think the issue's about to what extent some users might arrive at an article talk page and start a discussion about the subject (offering opinions, treating the page as a forum), compared with when a specific, content-related thread widens in scope to become more of a general discussion. I agree that wider discussion of the subject is often inevitable and, most importantly, it can be beneficial to a genuine content-related discussion, because context is often needed rather than focusing on the one point in isolation. I've seen editors shut down the more blatant chat variety, citing WP:NOTFORUM (#4), which is very sensible. Unless there are some pressing examples, I'd say the guideline works well and is applied well. JG66 (talk) 07:19, 4 September 2020 (UTC)[reply]

Thank you for your kind and helpful comments. I see this issue is already discussed at Wikipedia: Perennial proposals, under Section 3.4. Vorbee (talk) 07:48, 4 September 2020 (UTC)[reply]

Adding the Edit Request Wizard to various information and policy pages

Some users with a conflict of interest or being paid to edit struggle to properly format edit requests. The WP:Edit Request Wizard handles the formatting automatically, and is supposed to encourage proper wording of requests. Should this tool be mentioned in policy and information pages regarding WP:Conflict of interest and paid editing? Specifically, I propose linking to it in these pages:

Comments also welcome on improvements to the wizard itself.

Sam-2727 (talk) 20:02, 4 September 2020 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=976895063"