Jump to content

Wikipedia:Village pump (proposals): Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
Line 965: Line 965:
*'''Strong SUPPORT''': The reader doesn't need to see how the [[Sausage making|sausage is made]]. Active editors know how to find the "talk" info they seek. [[User:GenQuest|<span style="color:Purple; text-shadow:brown 0.1em 0.2em 0.1em;">GenQuest</span>]] <small><sup>[[User_talk:GenQuest|<span style="color:Purple; text-shadow:brown 0.1em 0.2em 0.1em;">"Talk to Me"</span>]]</sup></small> 16:59, 24 August 2020 (UTC)
*'''Strong SUPPORT''': The reader doesn't need to see how the [[Sausage making|sausage is made]]. Active editors know how to find the "talk" info they seek. [[User:GenQuest|<span style="color:Purple; text-shadow:brown 0.1em 0.2em 0.1em;">GenQuest</span>]] <small><sup>[[User_talk:GenQuest|<span style="color:Purple; text-shadow:brown 0.1em 0.2em 0.1em;">"Talk to Me"</span>]]</sup></small> 16:59, 24 August 2020 (UTC)
*'''Support'''' The process of how articles are improved is internal to the project, and, while public, should not be advertised to search engines more than necessary. Strangely enough, I can't remember having received talk page hits searching Google until recently, so I was living under the impression this would be the default already. --[[User:Matthiaspaul|Matthiaspaul]] ([[User talk:Matthiaspaul|talk]]) 18:45, 24 August 2020 (UTC)
*'''Support'''' The process of how articles are improved is internal to the project, and, while public, should not be advertised to search engines more than necessary. Strangely enough, I can't remember having received talk page hits searching Google until recently, so I was living under the impression this would be the default already. --[[User:Matthiaspaul|Matthiaspaul]] ([[User talk:Matthiaspaul|talk]]) 18:45, 24 August 2020 (UTC)
*'''Strong oppose'’' - it is better to find things than to hide things. [[User:EllenCT|EllenCT]] ([[User talk:EllenCT|talk]]) 01:37, 25 August 2020 (UTC)
*'''Strong oppose''' - it is better to find things than to hide things. [[User:EllenCT|EllenCT]] ([[User talk:EllenCT|talk]]) 01:37, 25 August 2020 (UTC)


== Allow fair use non-freely licensed photos of politicians ==
== Allow fair use non-freely licensed photos of politicians ==

Revision as of 02:09, 25 August 2020

 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)

Deprecate parenthetical citations

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]

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]
  • 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. 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]
  • 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]
  • 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]
  • 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 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]
  • 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: 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]
  • 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]

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]

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]

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

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]

Synchronising short descriptions and Wikidata descriptions

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

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]

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]
        @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]
  • 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[1]. 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]
  • 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]
  • 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]
  • 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]

CHINESE SIMPLIFIED VS TRADITIONAL

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.

Please add the ability in Mobile Apps to select either simplified or traditional script. It would make life easier for Chinese readers — Preceding unsigned comment added by 2606:a000:101c:c6f5:b048:991f:7d1:5749 (talk) 22:05, 11 August 2020 (UTC)[reply]

Hi 2606..., this is not something we can set on the English Wikipedia - you can place a feature request on phabricator. — xaosflux Talk 13:38, 12 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.

What are proposals?

Are we getting married or somethang? Here's a proposal for you: explain shortly at the top of this page what this page is all about! --Palosirkka (talk) 09:38, 13 August 2020 (UTC)[reply]

There is an explanation box at the top of this page. 331dot (talk) 09:48, 13 August 2020 (UTC)[reply]
There is a box but it says nothing about what proposals are. --Palosirkka (talk) 09:52, 13 August 2020 (UTC)[reply]
It certainly does, right below the first sentence. 331dot (talk) 09:54, 13 August 2020 (UTC)[reply]
The box is a mess. "Before submitting: Proposed policy changes belong at Village pump (policy)." That's not a coherent sentence but a word salad. --Palosirkka (talk) 10:10, 13 August 2020 (UTC)[reply]
Palosirkka, this is already done and well documented on both the village pump main page and other locations. There's nothing for us to do here. Ed talk! 09:48, 13 August 2020 (UTC)[reply]
No it's not Ed. And I'm not talking about the main page or some other page but this very page. --Palosirkka (talk) 09:52, 13 August 2020 (UTC)[reply]
Palosirkka, "New proposals are discussed here." - I think that sums it up enough. Either way, you can edit this page and change it yourself? I don't know why exactly you needed a proposal here for something that's as trivial as a page edit, and really then this thread belongs on WT:VPR Ed talk! 10:01, 13 August 2020 (UTC)[reply]
I would gladly do it myself if I only knew what they are. --Palosirkka (talk) 10:07, 13 August 2020 (UTC)[reply]
I am pretty sure you are capable of using a dictionary. Ed talk! 10:17, 13 August 2020 (UTC)[reply]
Ed6767, I don't think it's necessary to be snarky. The box really doesn't give any guidance as to what types of proposals belong here. It details the types of proposals that don't belong here, so is the presumption that this page is for any proposals that don't belong somewhere else? Is it intended for a specific class of proposals (my guess: "ideas for changes that apply to the Wikipedia project as a whole, but do not involve policies, projects, software..." etc)? I watch this page to stay informed, but never really thought about its purpose, and I think Palosirkka asked a reasonable question (if a bit flippantly). Schazjmd (talk) 16:30, 13 August 2020 (UTC)[reply]
I believe a proposal in the sense used here is an idea for a change to this wiki that has been discussed enough to be fairly specific and reasonably thought through. The idea should already have been discussed in the Idea Lab or perhaps a talk page elsewhere. The intro to the page lists other places that are better for specific types of ideas. — GhostInTheMachine talk to me 10:40, 13 August 2020 (UTC)[reply]
The best evidence for "what a proposal is" can be found by reading 'proposal' aired on this page, following discussions, and participating in the process. No need for a definition when you should gather experience first. Use analogy. Evaluate the participation of other editors and their reactions to your ideas and arguments. — Neonorange (Phil) 23:20, 14 August 2020 (UTC)[reply]
This is an odd conversation to say the least. Regardless, the OP makes a good point (echoing what Schazjmd said) about the top of the page not explaining what kind of proposals belong here. Perhaps some examples of passed past proposals at the top would help. I myself am style unsure on how this proposal page can differ or overlap with changes made on the WT:MOS, that should at least be clarified at the top. Suggesting that the reader reads through proposals to understand what this page is, is like suggesting readers read through questions in the tea house to understand that it is a place for questions, rather than just telling them that at the top! Aza24 (talk) 00:46, 15 August 2020 (UTC)[reply]
Yeah, I don't think it's clear what type of proposals are meant to be proposed here. The brief descriptions at the top of the main Wikipedia:Village pump are a bit more helpful, but then the broad strokes there paint a picture that's not all quite really followed in practice. I think it will be more accurate to state that the village pump is the place to bring up pet projects (or pet peeves) that a proposer believes are too important to be discussed in the appropriate venue, and the choice of page – idea lab, proposals, or policy (in this order) – is largely dependent on how important the proposer believes themself to be. – Uanfala (talk) 17:36, 15 August 2020 (UTC)[reply]

Arbitrary break

Yikes, the threading here is a mess, so resetting with a break. But I agree with GhostInTheMachine. It's certainly an issue that some very half-baked ideas end up here, but I'm not sure there's much we can do about it, since the types of editors likely to propose half-baked ideas are also the sort not to read instructions (even in an editnotice). Regarding criteria, a few come to mind:

  1. Concrete and specific: You need to have a solution in mind, not just say "let's find a way to solve problem X". (Ironically, this means this thread doesn't qualify.)
  2. Developed: Especially for major proposals, there needs to be some clear work put into it, evidenced by a quality framework, prior work at the ideas lab or elsewhere, etc. Any thread that just gets dropped here with e.g. "Let's deprecate portals" and nothing else should be nipped before it spirals into a mess. (This problem affects RfCs, too, where it's very hard to terminate one that's non-neutral/unneeded/inappropriate/etc. once it gets going. I can't think of a single instance where people !voting "abort" actually got an RfC aborted.)
  3. Has broad implications: Most proposals should be hosted at specific project pages, etc., not the pump. Giving a {{Please see}} notice here should usually be sufficient, especially for more minor issues.

Regarding enforcement, is there a gadget available for easily moving threads from here to the idea lab or elsewhere? That would help.

Also, there's another dynamic at play here besides the newcomer spam: more experienced editors who want attention given to their still-undeveloped idea, and know that this page is a lot more closely monitored that the idea lab, which has fewer watchers and more junk to wade through. I've had some good experiences at the idea lab, but also times (e.g. recently) when I've had to basically plead to get a discussion going, and that wouldn't have been needed if I'd come here. Unfortunately, strict enforcement here of the criteria I propose above would actually make that dynamic worse, since there would be even more junk heaped on the idea lab. Perhaps we need a gadget there to transfer to the Teahouse.

The core problem is that we have no good way to enforce whatever rules/norms we have about appropriate discussions to start and ways to start them. From RfCs to WP:CENT to Talk:Donald Trump to here, if we could find a way to address that, we'd be a lot better off. {{u|Sdkb}} talk 21:24, 15 August 2020 (UTC)[reply]

I can't think of a single instance where people !voting "abort" actually got an RfC aborted See here. There have been other instances. --Redrose64 🌹 (talk) 22:50, 15 August 2020 (UTC)[reply]
Redrose64, fair enough. Our system can handle utterly obvious cases, but for anything short of that, it often breaks down. {{u|Sdkb}} talk 09:38, 16 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]

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]

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]

Add basic HTML syntax-checking on user signature field changes

Can we please add an HTML syntax check every time someone attempts to save a customized user signature? (Maybe even on preview; give them a chance to fix it.) I just added this comment at a User talk page, asking the user to fix their signature, and it's not the first time I've addressed a user about this topic.

The more obvious HTML mistakes, a missing font-end tag that turns an entire Talk page red, or a missing </sup> that leaves the whole page tiny and superscripted, are obvious enough that someone finds them and fixes them quickly. Less obvious errors like this one, leave the preview page syntax highlighting broken. And because they are more subtle and don't garble the rendered talk page but only the wikicode syntax highlighting, they stay around for much longer. This user's signature has been breaking Talk page syntax highlighting since 2014, but until now, I guess we never had a Watchlist Talk page in common that I edited, so I never noticed before. To be clear: I don't doubt that this is an innocent, good-faith mistake, but there's no reason for it not to have been caught at the outset.

I don't care much about fixing up all the pages where this must have happened before, but I don't see why we should let users just put whatever they want into their signature, and leave it to the community to mop up the mess in case of problems. HTML syntax checkers have been around forever, and are robust even for long, complex web pages. We shouldn't allow a Talk page to be inadvertently screwed up, because a custom user signature has invalid HTML syntax. Is it too much to ask to put the signature input field through the same level of validation before we allow it to be saved? Thanks, Mathglot (talk) 01:39, 19 August 2020 (UTC)[reply]

Mathglot, are you aware of mw:New requirements for user signatures? --AntiCompositeNumber (talk) 01:45, 19 August 2020 (UTC)[reply]
@AntiCompositeNumber:, I wasn't aware. For reference here, I'll just add that the relevant section there for this issue is #Proposal: signature validation requirements, and that it's being tracked in T140606. They do talk about certain types of errors including unbalanced <font> tags and others, and if I'm readiing it right, it would also catch the error I identified above as a misnested tag, so that's good news. Thanks for the link. I'm not a stranger to mediawiki (or to other sister projects and wikipedias) but my main presence is at en-wiki; and I'm not sure if mediawiki needs to advertise themselves more widely at sister projects, or if I need to widen my scope somehow so as not to miss such things. In any case, thanks for that link! Mathglot (talk) 03:18, 19 August 2020 (UTC)[reply]
Mathglot, That page doesn't make it exactly clear, but the relevant changes are deployed currently (see mw:New_requirements_for_user_signatures#Outcome). The only exception is the "obsolete HTML tag" lint error, which is not enforced on signatures. If you try to edit your signature to introduce a lint error, you should find that you can't. You can also use my tool to check someone else's signature for problems, in this case https://signatures.toolforge.org/check/en.wikipedia.org/Gourami%20Watcher. --AntiCompositeNumber (talk) 04:12, 19 August 2020 (UTC)[reply]
AntiCompositeNumber, that's really great to know, thanks! And it's good to have my analysis of where the problem lay in GW's sig confirmed by your tool, which nailed it. (I'm not bothered about obsolete HTML tags, as most browsers are forgiving about such things.) Mathglot (talk) 05:05, 19 August 2020 (UTC)/[reply]
It was raised at the technical village pump by Whatamidoing (WMF). See Wikipedia:Village pump (technical)/Archive 182 § Changes to custom signatures and Wikipedia:Village pump (technical)/Archive 182 § Custom signatures changing on Monday, where Whatamidoing said users with invalid signatures would be gradually contacted. isaacl (talk) 10:35, 19 August 2020 (UTC)[reply]
Looks like I need to clock in for a minute.  ;-) Yes, it's already happening. For enwiki, we started with ~1200 active editors (=edited during the last 30 days) with some error. Most of them have a problem called "plain-fancy-sig" that just means you have an unnecessarily ticked box in your prefs.
I and a couple of volunteers have individually contacted around 100 editors here so far, and several hundred others have fixed their sigs on their own (or stopped editing, unrelated to this. Our attrition rate for new editors is very high, so newbies who created a sig in June and then stopped editing aren't in the list any longer, and the newbies from July onwards can't make the same mistakes). https://signatures.toolforge.org/reports/en.wikipedia.org will probably update tomorrow, and we'll see how much difference it made. If the message seems to be working, then we'll contact the rest, in smallish batches.
If you are interested in helping/answering questions, then mw:New requirements for user signatures/Help is the central point for instructions. At this wiki, we're asking people to take their questions to WT:SIG, so that's the page for helpful folks to be watching. So far, it's received no questions, which I hope means that our instructions are clear.
The timeline for ending the "grandfather" period is officially "When I get around to it" (I'm the bottleneck, and the devs have agreed to wait on me). It's probably months from now (not weeks, not years). Less than 900 of the current 126,740 active registered editors need to even think about this, and about 700 of them have an error that's solved by unchecking a single box in their prefs. Whatamidoing (WMF) (talk) 04:08, 20 August 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]

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 [2]. 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]
  • 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]

Allow fair use non-freely licensed photos of politicians

This has legal implications and isn't going to happen, unless the WMF amend wmf:Resolution:Licensing policy, in particular resolution 3, in a way which will allow us in turn to amend Wikipedia:Non-free content criteria, in particular criterion 1. --Redrose64 🌹 (talk) 12:20, 21 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.

I recently attempted to make an edit to the page of Laura Loomer. She is a congressional candidate and a public figure. Currently, her picture is that of a blurry YouTube screenshot, and I sought to improve her page by replacing the screenshot with a clearer image. Unfortunately, there are no photos available of Ms. Loomer that have been explicitly released as free license or public domain. There are however, photos of Ms. Loomer that have been released on her campaign website, and can be inferred to be released for public distribution.

I had two admins (@MelbourneStar and @GorillaWarfare) explain to me that Wikipedia policy says that we cannot use images of living people unless they are explicitly free license. But I don't think this makes sense for a public figure, especially someone currently running for political office. In one edit, I suggested a picture of Ms. Loomer posing with a sign that had the words "Laura Loomer for congress." But because the photo was not explicitly marked as public domain, it is unusable on Wikipedia.

Just for a second forget about current policy. If Ms. Loomer did not want that photo distributed, would she have had it taken and posted on her campaign website? It makes no sense. I have been informed that this is long standing policy since possibly 2006, but perhaps it is time for fresh ideas? Other online publications like the New York Post and Politico use these kinds of photos routinely without fear of violating copyright. Why can't Wikipedia do the same? Even if it cost some money to access these photo databases, Wikipedia isn't broke. Surely they could possibly set aside funds.

Another thing to consider with politicians: Doesn't Wikipedia have a responsibility as the premier free Wikipedia to ensure the most concise and clear information possible? Especially for would be voters? Need I remind anyone that Wikipedia is banned in many dictatorships? Free, and clear information is vital to democracy. People look to Wikipedia for important information. And that includes politicians. If a politician does not have a clear photo, this could cause confusion in the poll booth.

Please reconsider this policy.

(SamMontana (talk) 04:36, 21 August 2020 (UTC))[reply]

This is pretty much non-negotiable as the requirement that we use free images of living persons comes from the WMF in the non-free resolution that applies to all Wikimedia projects. And we are not her to serve as a political platform for any politician, at all. If a running candidate is notable, we will give them encyclopedic coverage, not coverage as you would see as a candidate. Not our place at all do be doing that. --Masem (t) 04:45, 21 August 2020 (UTC)[reply]
No per Masem. Sorry, but as said above this is pretty much not really up for change, given that living persons can have a free photograph taken of them at a future date. – John M Wolfson (talk • contribs) 04:50, 21 August 2020 (UTC)[reply]
@John M Wolfson: But at a later date could be too late. This could affect the election. (SamMontana (talk) 04:55, 21 August 2020 (UTC))[reply]
SamMontana As said earlier, we are not here to influence elections in any particular direction (not to mention the idea of a Wikipedia article affecting an election's outcome striking me as implausible and risible), and I would highly encourage you to acquaint yourself better with our principles regarding fair-use and especially living persons (we are also not here to right great wrongs, actual or speculative). I have the feeling that this will be closed soon as it doesn't appear to have a chance to pass. – John M Wolfson (talk • contribs) 05:14, 21 August 2020 (UTC)[reply]
  • Oppose — Wikipedia doesn't get into the business of promoting political candidates, period, so talk of uploading images to satisfy voters is a non-starter. The solution to the problem put forward by SamMontana would be for the political candidate to release their photos under a free licence – not change our longstanding policy which ultimately upholds the Third Pillar. —MelbourneStar☆talk 05:21, 21 August 2020 (UTC)[reply]
Wikipedia has no firm rules. (SamMontana (talk) 05:42, 21 August 2020 (UTC))[reply]
Sorry, a longstanding and reasonable policy. Either way, I don't see it changing anytime soon, so I'm not sure if bludgeoning the process will be helpful. —MelbourneStar☆talk 05:50, 21 August 2020 (UTC)[reply]
Oh look I can cite "longstanding" rules too. The principles and spirit matter more than literal wording, and sometimes improving Wikipedia requires making exceptions. WP:5P5 (SamMontana (talk) 05:56, 21 August 2020 (UTC))[reply]
Even with some famous politicians it is difficult to find a decent free image of them for the infobox. They could easily solve this problem themselves by releasing one image that is CC licensed; some politicians have done this. However, the WP:NFCC rules cannot be bent and non-free images in the infobox are usually a no-no.--♦IanMacM♦ (talk to me) 05:56, 21 August 2020 (UTC)[reply]
Why can't it be bent? Wikipedia has no firm rules. Politicians aren't known for being tech savvy. (SamMontana (talk) 06:00, 21 August 2020 (UTC))[reply]
If we start paying for these sort of photos, why not pay for everything else? Or rather why would anyone continue to give stuff for free? If we were going to change policy it would be more logical to drop "fair use" altogether - politicians at the least would then start releasing openly licensed images as a matter of course. I'm actually not against the principle of the Foundation paying for content, I'd just rather they did so by buying reference books for active Wikimedians in countries without good public libraries (some of this already takes place). ϢereSpielChequers 06:18, 21 August 2020 (UTC)[reply]
  • Oppose: no non-free/fair-use pictures of living people, a picture can be taken or be made available. And if that is 'too late' then that is not Wikipedia's problem. If it is a problem for the neutral display of the elections, then go out there and get a picture, or remove the other pictures even if they are available. And yes, you can argue that Wikipedia does not have firm rules, but Wikipedia does have firm rules. Most rules on Wikipedia are not set in stone, but some of these rules are. One group of those are our policies that have legal implications, another set are the rules set out by WMF. --Dirk Beetstra T C 11:10, 21 August 2020 (UTC)[reply]
  • Close discussion I'm a little surprised myself that politicians and public figures who can certainly afford a professional photographer often don't care to make good photos of them freely available for all purposes, but that's their problem. As this proposal relates to a political campaign described by reliable sources as a publicity stunt with almost no chance of succeeding, I recommend closing this discussion as fruitless. Blythwood (talk) 11:30, 21 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.

Reworking Wiki app's "today in history" algorithm.

Hello, I recently got the wiki app and have immensely enjoy browsing it. I particularly like the "Today in history section." However, I find that the vast majority of articles it shows are, for lack of a better word, bad news. I would say that most days more than half of the articles are about terrorist attacks, railway accidents, or natural disasters. I personally don't find these articles very enjoyable to read. Please forgive my massive ignorance if the inner workings of Wikipedia, I have no idea how to solve this problem, or if this is the correct forum for suggesting this change. I am curious if anyone else has been bothered by this and if there would be a way to alter what articles in general appear in the "today in history" section. Thanks in advance, That01Llama — Preceding unsigned comment added by That01Llama (talk • contribs) 13:54, 21 August 2020 (UTC)[reply]

@That01Llama: These aren't generated by an algorithm; they're chosen by Wikipedia editors like you. The one in the home screen seems to be drawn from the same list on the main page, and the ones you get from pressing "More on this day" come from the day-of-year articles like August 21. The main page list criteria are at Wikipedia:Selected anniversaries; the day-of-year list criteria are described at Wikipedia:Days of the year. I would encourage you to find pleasant or enjoyable events that meet those criteria. Vahurzpu (talk) 17:34, 21 August 2020 (UTC)[reply]
That01Llama, this gets at a larger issue with the concept of news, which is that negative developments are more likely to be sudden (and thus able to be pegged with a date), whereas positive developments happen over time. Perhaps adding more birth dates of important people would be able to help counter this a bit. I'm not all that familiar with WP:OTD, though; you'd get more helpful feedback from posting there. {{u|Sdkb}} talk 22:11, 22 August 2020 (UTC)[reply]

Add 'last edit' column to xtools articleinfo

Please add a 'last edited' column to the xtools utility "articleinfo", and/or other method to help determine whether a user is a good candidate to be pinged to a current discussion at the article's Talk page. (I.e., pinging editors who haven't edited in a year is a waste of time and effort.)

I not infrequently use the very handy xmflabs tool, "articleinfo" (sample) to make up a ping-list of "concerned editors" to be notified about a discussion at the article Talk page. However, that could be up to 20 or 30 editors (top ten by edits, byte count, or authorship) so I usually drop any user from the list with no contributions in the last three months (or whatever threshold). But that takes up to 40 or 60 clicks to determine. A new date column in the tables in the Top editors section containing the date of the editor's last contribution to Wikipedia would make this a lot easier. (Even better: a font-height sparkline showing their contribution pattern of the last 6 months or so, if any, plus last-date.) Thanks, Mathglot (talk) 21:02, 24 August 2020 (UTC)[reply]

Manual Tag: "Error in edit summary"

WITHDRAWN
It seems I don't have the support I initally thought I had. P,TO 19104 (talk) (contribs) 22:30, 24 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 the idea lab, there was discussion regarding allowing users to edit their edit summaries, which admittedly doesn't isn't a very good idea. However a few other users (credits to [primarly] Majavah, xaosflux, and Sdkb) mentioned the possiblity of creating a new Manual Tag that would indicate "Error in edit summary". To quote Majavah:

On fiwiki there is a tag for "error in edit summary" that you can add to your own edits if you made a mistake in the summary. When adding a tag you can add a reason for tagging the edit which is shown on the tag management page. We could probably try a system like that here too. – Majavah talk · edits 19:34, 11 August 2020 (UTC)

Obviously this is hard to imagine, so I have created page on this proposal: Wikipedia:Editing Tags. Note: although this proposal features photos on how to change any tag, it is specfically about just adding a feature to add "Error in edit summary", unless there is consensus to allow editors to edit all tags. P,TO 19104 (talk) (contribs) 21:39, 24 August 2020 (UTC)[reply]

  • Although this could be useful, I have doubts about whether it's needed enough to justify the complexity it'd introduce or effort it'd take to introduce it. Errors in edit summaries significant enough to require marking aren't that common, and they can normally be handled well enough by subsequently making a dummy edit. {{u|Sdkb}} talk 21:44, 24 August 2020 (UTC)[reply]
Seems unnecessary. Just follow up with a WP:DUMMY comment, and rewrite the summary the way you wanted to say it. I haven't seen a case yet, where this would somehow not be sufficient remedy.
Bear in mind the following much more serious use case as a comparand, and even this does not require such a tag. It's the case of adding copied/translated text to an article; this involves a legal requirement in the Edit summary, namely, per Wikipedia's licensing requirements, it is obligatory to leave an attribution statement for added content that is copied or translated from another article. Not suprisingly, this isn't always followed, whether inadvertently, or not. The remedy for missing attribution is spelled out in WP:RIA, which is to simply supply the legally required, but missing attribution via a dummy edit. If that's good enough for the legal team, it should be good enough for an editor who forgot something in some previous edit summary. Mathglot (talk) 22:12, 24 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.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=974795109"