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

• WP:Paid-contribution disclosure#Conflict of interest guideline,
• in the WP:COI guideline whenever the ((request edit)) template is mentioned,
• in the WP:Simple conflict of interest edit request, and
• on WP:Edit requests.

Comments also welcome on improvements to the wizard itself.

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

• I had no idea this even existed! I'd actually suggest adding it to Talk Pages as well, in some fashion Nosebagbear (talk) 14:53, 5 September 2020 (UTC)
  • If you mean like a talk banner, then we have so many of those (and most are useless) that I don't think anyone bothers read them these days. Plus they're obscurely hidden on mobile devices. ProcrastinatingReader (talk) 13:52, 6 September 2020 (UTC)
• As said above, had no idea this existed. Something like this should be publicised more. I support this page being linked to from the aforementioned pages, it would make clearing up formatting much less of a pain. — Preceding unsigned comment added by Berrely (talk • contribs) 18:18, 5 September 2020 (UTC)
• Re:No idea this existed:That would be because it's new, please see Wikipedia_talk:Teahouse#Edit Request Wizard for more context. I would like to hear from editors capable of reviewing and testing bugs. If independent reviewers say it's ready, I would support too. Usedtobecool ☎️ 20:29, 5 September 2020 (UTC)
• Forgot to put my support for my own idea. I agree, some testing is needed. Hopefully in the course of this RfC someone will be able to confirm that all is working as expected. Test cases I've performed are here: User:Sam-2727/ERW Test Cases. Sam-2727 (talk) 00:12, 6 September 2020 (UTC)

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)

• 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)
• Oppose would serve only to make subtle vandalism easier. No benefit. DES ^(talk)_{DESiegel Contribs} 02:14, 13 August 2020 (UTC)
  • @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)

  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)

• 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)
• 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)
  • Question: How would the 794 citation templates in Module:College color/data be stored in Wikidata? --RexxS (talk) 23:11, 13 August 2020 (UTC)
    • @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)

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

      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)

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

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

      @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	no value edit ▼ 1 reference reference URL https://brand.cornell.edu/design-center/colors/ title Cornell University Brand Center (English) section, verse, paragraph, or clause Colors publisher Cornell University retrieved July 17, 2019 + add 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)

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

• outdented — GhostInTheMachine ^{talk to me} 10:16, 29 August 2020 (UTC)
• @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)

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

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

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

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

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

  @RexxS: My understanding of your argument is basically that the style of any given citation should never change. However, that's not quite what WP:CITEVAR says. It reads Editors should not attempt to change an article's established citation style (emphasis added). Citation style is set on a per-article basis, not a per-citation basis. Based on that policy, there is no reason that any given citation should have a set style; instead, it should be rendered in the style of the article it appears in. That's what the current policy would indicate, and frankly, what makes the most sense.

  Let me give an example. Suppose that I (a human editor) saw a citation-supported fact in ArticleA, and I decided that that fact (and its citation) would also be useful to include in ArticleB. In the process of copying this information over, I would surely edit the citation to convert it to the citation style of ArticleB, wouldn't I? If the citation from ArticleA is in ((citation)) style, but ArticleB uses ((cite web)), then I would need to convert that citation to use ((cite web)), right? If it is acceptable for me to change the style of a citation when moving it to a new article, then why shouldn't it be okay for Wikidata to do this as well? –IagoQnsi (talk) 17:59, 26 August 2020 (UTC)

  @IagoQnsi: You seem to misunderstand how this module is used. Each of the colour entries applies to effectively one article, and the data module stores not only the colour information for that article's team, but the citation style used in that article. That's how it works now. You want to change how it works to fit in with the ability of your scheme to store information, and to throw away the information about the style of citation to use. The editors who created and use this module make use of it in a simple way now; and you are going to ask them to either store locally a separate list of articles with their citation styles, or to insert the citation style manually in each article, for no reason other than your proposed solution can't function in the way that they are working now. That's the tail wagging the dog.

  Let's look at your example. You suppose that the colours for Team A, used in ArticleA might somehow be useful in ArticleB. I see no evidence of that ever being the case. Under the present system, that is still trivial to achieve when ArticleB has the same citation style as ArticleA; you just copy the relevant template over and it generates the citation for you. It would require manual updating of the citation if the styles were different. However, in your scheme, the citation would have to be locally set up in each ArticleA's case to match its existing style (you haven't given any examples of how that might be accomplished), and then set up again locally if you wanted to use it in ArticleB whether the style matched or not. I don't see that as an advantage. There is no demonstrated benefit of decoupling the citation style used in each team's article from the information stored in the module. At present there is effectively a one-to-one correspondence between article and entry in the data module, which allows a simple storage method. You are advocating using a more complex storage system (some info on Wikidata; some info locally) to allow for the possibility that somewhere the editors might want a two-to-one (or more) correspondence between article and colours info, but you haven't demonstrated any need or demand for that. --RexxS (talk) 19:06, 26 August 2020 (UTC)

  @RexxS: This module is not at all used on a single-article basis. Each school's colors are used on probably hundreds of articles each, as we have many many articles covering college sports. To give an example, the colors for Duke Blue Devils are transcluded in Duke University, Duke Blue Devils, Duke Blue Devils men's basketball, 1990–91 Duke Blue Devils men's basketball team, Atlantic Coast Conference, 2018–19 Atlantic Coast Conference men's basketball season, and every variation of those articles (i.e. other years/seasons, other sports). If we were to transfer the data to Wikidata, the colors would also be used by many pages on other editions of Wikipedia, which would all have their own citation styles presumably.

  Setting the style wouldn't be difficult. Presumably, we would default to CS1 style, which is used on an overwhelming majority of college sports articles that I've encountered. But this could be easily overridden either on a per-use basis (e.g. ((College color boxes|citation=cs2))) or on a per-article basis, using something like ((Use CS2)) (which could work in the same way that templates like ((Use mdy dates)) work currently). Presently, the module's citations are not transcluded onto articles at all, so this is all hypothetical for now. –IagoQnsi (talk) 19:52, 26 August 2020 (UTC)

  @IagoQnsi: At present, any article that wishes to use the citation stored in the module can do so trivially. The citations stored in the module are an almost equal mixture of ((cite web)) and ((cite manual)) with a couple of ((cite book)).

  You claim "Setting the style wouldn't be difficult ... this could be easily overridden ... using something like ((Use CS2))" Here's a citation: ((cite manual |url=http://www.thepacwest.com/documents/2015/6/22//pacWest_colorways_spring2015.pdf |title=Pacific West Conference Visual Identity Standards |accessdate=March 23, 2017)). I'd like you to show me how it isn't difficult to set CS2 for it. Please let me know roughly how long I'll need to wait for your solution. --RexxS (talk) 21:30, 27 August 2020 (UTC)

  @RexxS:If you have that citation stored in Wikidata, it's very easy to spit it out in either style. The parameters are exactly the same between ((cite manual)) and ((citation)); in fact, they both rely on the same underlying module. Our template would pass all the reference parameters to Module:Citation/CS1, then set the CitationClass to "citation" if the page uses CS2, or to one of the CS1 values (e.g. book, web, news, etc) if the page uses CS1. There would have to be a little bit of logic to decide which CS1 value to use — basically, if the reference includes a type of reference (P3865) value, we'd just use the CitationClass that corresponds to that media type; otherwise, we'd make a best guess based on the included properties, much like how ((citation)) does. –IagoQnsi (talk) 22:45, 27 August 2020 (UTC)

  @IagoQnsi: Okay, show me. I'm really interested in that "little bit of logic to decide which CS1 value to use". Then I'll ask you how you'll deal with chapter and article titles that are defined differently in CS1 and CS2. --RexxS (talk) 23:20, 27 August 2020 (UTC)

  @RexxS: If type of reference (P3865) is set, then we can just have a 1-to-1 array mapping of reference type items to CitationClass values (e.g. map book (Q571) to CitationClass='book', etc). If P3865 isn't set, then we look at what properties are set. A very rudimentary solution would be to use 'book' if volume/edition/page are set, and otherwise use 'web'. That's not a robust solution, sure, but it's already more than enough to handle all of the existing references on this module. I'm not proposing we migrate every citation on Wikipedia to Wikidata; I'm just proposing we migrate the ones in this module. The implementation will get better with time if it's being used and edge cases begin to crop up. –IagoQnsi (talk) 23:56, 27 August 2020 (UTC)

  @IagoQnsi: You don't seem to have shown me anything. And I'm afraid that type of reference (P3865) doesn't mean what you think it does. --RexxS (talk) 00:14, 28 August 2020 (UTC)

• 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)
• 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)
• Support. Exactly the sort of data Wikidata works best for. – Finnusertop (talk ⋅ contribs) 02:34, 14 August 2020 (UTC)
• 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)
  • @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)
• 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)
• 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)

  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)

  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)

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

  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)

  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)

• Support, per GreenC, Mike, and others. Rehman 13:26, 14 August 2020 (UTC)
• 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)
  • @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)
• 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)
  • @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)
    • Even so, there are still hundreds of entries in the module currently, so all of those entries will each be stored at their own separate location. The whole point of creating this in the first place was to store all the data at one centralized location to make it easy to monitor. Ejgreen77 (talk) 10:42, 26 August 2020 (UTC)
      • @Ejgreen77: We can have a bot update a page with the results of my above query, so that there's one centralized location for easy monitoring. –IagoQnsi (talk) 20:44, 27 August 2020 (UTC)
• 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)
  • @RexxS: Besides our disagreement on the issue of citation style, I haven't seen any discussion about the structure of the data. On the module talk page, I showed how I expected the data to be structured with an example: wikidata:Q2892868#P6364. I welcome criticism, but I haven't seen any yet. Cheers, IagoQnsi (talk) 20:38, 27 August 2020 (UTC)
  • @Mike Christie and Johnbod: You both cited RexxS's comment above as your reason for opposing the proposal. I am curious to know what parts of the Wikidata structure you find to not be usable. Is it the citation style concerns RexxS raised earlier in the discussion, or is it something else? No one else has weighed in on myself and RexxS's citation style thread, so I have no sense of the broader community opinion. Thanks, IagoQnsi (talk) 20:38, 27 August 2020 (UTC)

    • Mike said "per many of the above comments; RexxS sums it up well" & I said "per RexxS and others". I think RexxS's summary is clear enough, & there are many points others have made. Johnbod (talk) 21:16, 27 August 2020 (UTC)

      For me, the key point RexxS made is it is becoming increasingly apparent that it can no longer be trusted to maintain data in a usable structure. Updating short descriptions is a huge use of enwiki resources that could be better directed elsewhere, but it has to be done because vandalism to the corresponding Wikidata descriptions is, practically speaking, invisible to watchers here. That soured me on using Wikidata for anything that could be equally well done here. Unless there are obvious major benefits to the move, I don't want to see enwiki move information to where it cannot be monitored and managed (and protected) locally. Mike Christie (talk - contribs - library) 21:36, 27 August 2020 (UTC)

• 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)
  • @Johnuniq: Wikidata's protection policy says that all items used on over 500 pages should be semi-protected. Each school's colors are used on several hundred pages, and with the likely advent of other wikis making use of these colors, it is likely that a request for semi-protection would be approved if this proposal happened. –IagoQnsi (talk) 20:59, 27 August 2020 (UTC)
    • Anyone is welcome to copy all the data to Wikidata and set up whatever is needed to make it work in articles. Then test it at various Wikipedias (not enwiki) and see how it goes for six months. After that, come back and make a proposal to use it here. Johnuniq (talk) 23:48, 27 August 2020 (UTC)
• 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)
• Support this is a value in a template that a user currently can't edit in the way templates are usually edited in Wikipedia. Having to go to https://en.wikipedia.org/wiki/Module:College_color/data to edit the data is completely counterintuitive. ChristianKl ❪✉❫ 15:04, 26 August 2020 (UTC)

If having to go to another page on Wikipedia is counterintuitive ... wouldn’t having to go to a completely different WEBSITE (Wikidata) to edit be a lot MORE counterintuitive? Blueboar (talk) 16:41, 26 August 2020 (UTC)

@Blueboar: Using a Wikimedia sister site shouldn't be too hard; Commons doesn't seem to trip people up too much. If you're able to navigate the current chain of ((CBB roster)) --> ((CollegePrimaryStyle)) --> Module:College color --> Module:College color/data, you'll probably be able to figure out Wikidata too. –IagoQnsi (talk) 17:32, 26 August 2020 (UTC)

• Oppose, per many of the above comments; RexxS sums it up well. Mike Christie (talk - contribs - library) 17:36, 26 August 2020 (UTC)
• Oppose, per RexxS and others. Johnbod (talk) 18:06, 26 August 2020 (UTC)
• Comment - I have been thinking about why I am so negative about Wikidata. And have realized that it comes down to some very simple reasons. First, I am text oriented and not data oriented. I simply don’t see the world in terms of bits of data to be stored and retrieved. Second (And more important), I am an older person, and easily confused by all this whiz bang technotify stuff. I hate templates (with all their confusing parameters and fields) and avoid them if I can (for example, I don’t use citation templates, and still do all my citations by hand using <ref>text</ref> formatting.) However, I find templates a breeze compared to editing Wikidata. I tried, and very quickly gave up. To put it bluntly... I feel that I am UNABLE to edit wikidata. When we move things to Wikidata, they become out of my reach as an editor. If I needed to edit information pulled from Wikidata, I COULD not do so. So much for “anyone can edit”. Blueboar (talk) 21:53, 27 August 2020 (UTC)
• My opinion is that the citation discussion above is largely a red herring. That's a question of implementation and I'm pretty sure Trappist if no one else could provide a functioning citation in CS1 or CS2 for the reference data related to each color (and I can pick out at least one other user who could do it as he's basically done it already with another template).

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

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

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

  • @Izno: Good questions! I was not aware that any of the colors in this module were not official. How are these unofficial colors chosen? If they are being systematically derived from the official colors, then I imagine we could store only the official colors in Wikidata, and have our module on Wikipedia derive the accessible colors as it retrieves them. If they're being chosen some other way, then we might want to figure out some schema for storing them, perhaps using nature of statement (P5102) to distinguish official and unofficial colors. I think it'd be useful to have these unofficial colors stored in Wikidata as well; AA compliance is something that all Wikimedia projects would be interested in, not just us. It's just a matter of finding a good way to delineate them from the official colors.
  • As for the expensive operations issue, I didn't have a particular implementation in mind. One method that would be easy enough would be to have a bot update a local page every hour with the results of a query for all the college colors, and then have the template/module pull the color from there instead of directly from Wikidata. That wouldn't be such a great solution in the long-term if we were to expand this to be used for more than just college sports, but perhaps there are other ways to efficiently cache this that I'm not aware of, or perhaps it's something that could be raised with the Wikidata Lua developers.
  • We could also just allow a single expensive query to be used here. Most articles only use colors from a single school, so it wouldn't be a very big deal. There are a few articles such as Atlantic Coast Conference which use colors from many schools, and we'd want to have a better solution for them. We could perhaps have a bot use a SPARQL query to update articles that use many schools' colors on an hourly basis. But in the short term, I don't think there are any pages that use enough different schools' colors to hit the expensive function limit, so we don't necessarily have to have a finalized solution for this just yet. –IagoQnsi (talk) 23:42, 27 August 2020 (UTC)
• Oppose for now per Johnuniq. I am willing to reconsider after seeing it demonstrated and proved to work better than the current system in practice, including ease of use to people unfamiliar with either system, lower workload for editors, compliance with MoS, and resistance to vandalism. · · · Peter Southwood ^(talk): 13:55, 28 August 2020 (UTC)
• Oppose for exactly @Blueboar:'s reasons. Wikidata is highly technical. I understand text on English Wikipedia. I don't understand Wikidata at all. The more you move data from English Wikipedia to Wikidata, the more you are reducing my ability to edit English Wikipedia. Mr Serjeant Buzfuz (talk) 14:29, 6 September 2020 (UTC)
• Oppose you can state that WD is catching vandalism, but vandalism stays for days, weeks if you are lucky enough that the local wiki does not catch it. Buckingham Palace was officially opened in 1826, 2018, 2013, 1999, 2018 (again, now for 22 days), 2017, 2012 (for 4 months), 2012, 2012, 2011 (for a month), 1703 (for 8 months), (deleted) (for 2 months), 1200, (no value), 1020, 1720, 5555, 1720, 1715. Take your pick. Now, that is a number that people actually may know (and still we can't decide), but for colors? #FEFEFE or #FDFEFF? Just keep it local, easier to protect and easier to monitor. --Dirk Beetstra ^{T C} 15:17, 6 September 2020 (UTC)

Please see WT:PROTECT#RFC: Changing protection icons instead. Goose^(Talk!) 17:38, 7 September 2020 (UTC)

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

---

One thing that bugs me about the protection padlocks is that they consist of a mix of letters and shapes, which comes off as inconsistent to me. Therefore, I am proposing to update some of the protection padlocks to match their Commons counterparts, specifically the symbols for full protection and template protection:

I would also like to see the office protection and extended confirmed protection padlocks be updated to match the rest of the protection icons. The office protection padlock can be updated to have the logo of the WMF, while I am not too sure about how to update the extended confirmed protection padlock. Please provide your input on this idea. Goose^(Talk!) 04:30, 7 September 2020 (UTC)

• Inconsistency alone isn't really a particularly strong reason to change them - is there a particular issue with people not knowing what is being represented. The template protection one suggested is nice, but I'm not sure it's any more or less clear than the current "T" one. I am against the full protection one here as it's actually less inherently clear Nosebagbear (talk) 08:09, 7 September 2020 (UTC)
• I call WP:MULTI - this is already under discussion at WT:PROTECT#RFC: Changing protection icons. --Redrose64 🌹 (talk) 12:36, 7 September 2020 (UTC)

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

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

I'd note that we do have 1073 to log these, so it's not hard to track, but there's 32k hits. ProcrastinatingReader (talk) 14:13, 28 August 2020 (UTC)

Thank you, ProcrastinatingReader. I missed that the edit filter had already been implemented. Would you know if there's a way to get a de-duplicated list of users who have triggered the filter, so that spot checks can be done? --Paul_012 (talk) 17:02, 28 August 2020 (UTC)

That edit filter ought to be changed and set up to disallow the edit and then from this point forward this event should by all means be banned on this project, It's disruptive and to be very blunt it's a pain in the ass for us who have to go through everyones contribs checking each and every edit. –Davey2010^Talk 20:51, 30 August 2020 (UTC)

To be clear, the consensus on ANI was that it was not disruptive, and you don't need to check everyone's edits. Our normal community workflows probably caught many of the mistakes already, and there is no evidence that the quality of the edits is significantly different than other newcomer edits, Sadads (talk) 20:02, 9 September 2020 (UTC)

It's great that we have new editors as part of this, even if they aren't doing things quite right yet. I hope that you're welcoming them and teaching them how to best edit Wikipedia. Thanks. Mike Peel (talk) 19:35, 3 September 2020 (UTC)

+1 to what Mike said: most of the edits I have seen are constructive, and build on the work of other Wikimedia communities -- so please be thoughtful in engaging with folks. Sadads (talk) 20:02, 9 September 2020 (UTC)

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

1. https://en.wikipedia.org/wiki/Help:Multilingual_support , Font and rendering support, IPA, Braille etc.
2. https://www.mediawiki.org/wiki/Universal_Language_Selector
3. https://en.wikipedia.org/wiki/Wikipedia:Spoken_articles
4. Wiki markup language support. (What is a markup language?, what is the Wiki markup language, its List of codes, cheatsheet etc.)

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

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

Agreed. ((u|Sdkb)) ^talk 03:58, 14 September 2020 (UTC)

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

But why should the help pages be displayed on every article, where they will be irrelevant clutter the vast majority of the time? – Teratix ₵ 11:03, 14 September 2020 (UTC)

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

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

I would like to bot-migrate uses of ((Commons)) to ((Commonscat)) in circumstances like these:

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

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

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

• Support . Two notes: 1) On Commons there are many cross-ns #REDIRECTs (page_is_redirect = 1) pointing from galleries to categories (intentionally or as a remains of a cross-ns move). 2) Dest cats should be checked if they are redirects. They are tagged by templates and not #REDIRECTed but can be caught best by being a member of c:Category:Category redirects. --Achim (talk) 18:57, 30 August 2020 (UTC)

  @Achim55: I normally use code that checks for uses of commons:Template:Category redirect and a list of known redirects to that template - it may not catch them all but it works conservatively - if it can't find the template, it assumes that it is a valid gallery. Thanks. Mike Peel (talk) 19:06, 30 August 2020 (UTC)

  Mike, last word ^ should have been 'category' I think. Well, testing for the use of templates should work as well, but I suggest to check if your code covers the "cascading" c:Template:Invalid taxon category redirect too. Best, Achim (talk) 19:19, 30 August 2020 (UTC)

  • @Achim55: No, 'gallery' is correct, it uses the sitelinks to check for categories so it's only the gallery check that is more tricky. I'm always happy to improve code, but that is probably better discussed at the bot proposal - first we need to establish whether this is something we want to do as a community. Thanks. Mike Peel (talk) 19:23, 30 August 2020 (UTC)

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

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

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

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

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

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

• @Hike395: I was hoping to keep this focused on the specific issue of whether to use the ((Commons)) vs. ((Commons category)) templates as that's a practical step that we can take now. If we're going to turn this into a broader discussion, then I would like to see us use a single template that links to the gallery and/or category as they are available through the sitelinks on Wikidata, possibly through Module:Commons link if @RexxS: can confirm that this is compatible with Module:WikidataIB). Thanks. Mike Peel (talk) 20:02, 30 August 2020 (UTC)
  • @Mike Peel: Looking at Module:Commons link, I can confirm that it interacts with Wikidata in just the same way that WikidataIB does. Essentially, it adds multiple utility functions for working with categories and galleries on Commons, and two main calls to get the associated Category and Gallery respectively into Wikitext. --RexxS (talk) 23:11, 30 August 2020 (UTC)

@Mike Peel: Apologies for possibly randomizing the discussion. Some more notes:

• If we get consensus around this, we can promote Template:Commons/sandbox to Template:Commons right away, and achieve part of what you desire from a bot run immediately, without waiting. It's a practical step we can take today. In this case, ((Commons)) would become what you are suggesting (a "template that links to the gallery and/or category as they are available through the sitelinks on Wikidata"), with extra checks from other properties for fallback and consistency.
• Back in March, RexxS generously did a code review for Module:Commons link, and didn't see any problems going into production. Mike: did you have specific concerns about how Module:Commons link was different than Module:WikidataIB? There are four main entry points: getGallery, getCategory, getGalleryOrCategory (return one), getGalleryAndCategory (return both). Instead of checking Wikidata in series, bailing after the first item is found, Module:Commons link looks in all of the same places as Module:WikidataIB, and does not return a Commons link if any inconsistency is found.
• In that same discussion, Mike brought up an interesting idea for combining Commons templates. Can we defer that discussion in favor of a simple call to Module:Commons link in ((Commons))? As you said, the module call is a simple practical idea we can implement today. The Commons templates can always be merged later, if we get consensus.

More comments/suggestions/issues are welcome! — hike395 (talk) 23:09, 30 August 2020 (UTC)

@Hike395: Looking at this in more detail, I think the changes at Template:Commons/sandbox are a useful improvement to reduce the number of bad links, and I think you should make that change immediately (I can make it live if you don't have the permissions to do so). However ((Commons cat)) includes the tracking categories, in particular for cases where there is no defined parameter and no sitelink on Wikidata (= link to the search in this template), and where the local text doesn't match Wikidata. These are really useful for maintenance, but they become more complex to handle when you have both categories and galleries (in particular if you don't know which the editor wanted to link to). Pi bot is also set up to maintain the links to categories, which is part of why I want to migrate cases over to use ((Commons category)) where possible, without removing links to galleries. In the long term, I would like to see us using both templates without parameters (just using Wikidata), and linking to either/both the gallery and category (and maybe related categories), but that's a separate discussion.

Bottom line, I think you work is good and should be made live, but it's parallel to the specific proposal I've put forward here. I think both could go forward in parallel. Thanks. Mike Peel (talk) 19:01, 1 September 2020 (UTC)

@Mike Peel: Thanks! I just made it go live. I agree that Module:Commons link is complementary to your proposal. Your proposal contains a valuable set of cleanups that I think we should implement. I think we're just discussing the details of the cleanups at this point.

I'm more than happy to implement the tracking category logic from ((Commons category)) in Module:Commons link. That should be easy in Lua. If you agree, I can add that logic to ((Commons)). I can also expose it as an entry point, so we can make ((Commons category)) a bit more compact (if you wish). I'll start work on that in Module:Commons link/sandbox. After implementing that, we won't need to change the template to get the tracking categories.

I am thinking that ((Commons)) and ((Commons category)) express different editor intent. The latter means "I really want to link to a category", while the former means "I want the best Commons thing, of some sort". I'm just trying to be super careful about having a bot make massive changes that may alter editor intent. Let me break down the possible cases you've outlined, and make a suggestion that should preserve editor intent.

1. ((Commons)) has a first parameter that is a category --- clearly move to ((Commons category))
2. ((Commons)) has a first parameter that is a redirect to a category --- move to ((Commons category)) is very likely to be correct
3. ((Commons)) has a first parameter that doesn't exist at Commons. There are two possibilities:
   • The editor made a mistake (likely) --- the right answer is to delete the first parameter and let Module:Commons link do its Wikidata magic.
   • The editor may have intended to invoke a Commons search (unlikely, but possible)

   We could simply delete the first parameter and ignore the unlikely case? Or I can add a |fallback= parameter to ((Commons)) and Module:Commons link, and have the Commons search execute after Wikidata fails. What do other editors think?

4. ((Commons)) does not have a first parameter --- Now that we are using Module:Commons link, which is specifically designed for this case, I would leave this case alone. (Especially after I add the extra tracking categories).

To summarize, I support using a bot in my cases (1) and (2), above, oppose using a bot in my case (4), and let's discuss my case (3). I'll get to work on the tracking categories.

What do other editors think? Mike? — hike395 (talk) 14:37, 2 September 2020 (UTC)

@Hike395: I think we agree on your first one (my #2), and the second one that is part of my #3. Your third and fourth points assume that the link to search was correct (I'm automatically excluding any that link to an existing gallery here), I'm not sure that is a reasonable assumption. Particularly in categories, I think it makes sense to link to the Commons category rather than the search results, where (and only where) such a category exists. If there's no such sitelinked category, then my proposal wouldn't alter those cases. Perhaps the general question here is: do we want to link to search rather than an existing Commons category on the topic? Thanks. Mike Peel (talk) 17:55, 2 September 2020 (UTC)

@Mike Peel: I agree that search links are a bad user experience. However, now that Module:Commons link is used in ((Commons)), my case #4 doesn't use search links any more. My case #4 now directly goes to the Commons category (if there is no corresponding Commons gallery, otherwise it will use that). I've written (but not yet tested) the tracking category logic in Lua. Soon there'll be no compelling reason to move case #4 over to ((Commons category)) (I think). — hike395 (talk) 19:16, 2 September 2020 (UTC) I

@Hike395: OK, that's good. The question then becomes, for the cases where the template links to Commons categories only, whether it's better to use ((Commons category)) to make it clear that it's a link to a Commons category. Then we keep the gallery and category lik maintenance separate. But the other way of looking at it is, it's the first step to merging to a single Commons template that sorts it out automatically. Thanks. Mike Peel (talk) 17:34, 3 September 2020 (UTC)

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

I think the general convention is to not show 'Category:' - the same as the categories at the bottom of an article don't have the prefix. My preference would still be to change the template. Thanks. Mike Peel (talk) 14:16, 12 September 2020 (UTC)

@Mike Peel: I still wonder if we can come to a compromise acceptable to both of us. How about this: can we change the output text for these kind of templates?

If the template links to a gallery, it could read something like

Wikimedia Commons has a gallery for Foo

If it links to a category, it could read something like

Wikimedia Commons has a category for Foo

If it falls back to some sort of search, it could read as it does today

Wikimedia Commons has media related to Foo

and if ((Commons and category)) returns both, it could read

Wikimedia Commons has both a gallery and category for Foo

I like this, because it makes the Wikidata logic more transparent to both editors and readers. What do other editors think? — hike395 (talk) 00:58, 13 September 2020 (UTC)

@Hike395: That's the kind of solution I'd like to see us reach in the long term, but it's kinda beyond what I was proposing at this step. I'm puzzled why you don't like the idea of moving the category links over to the other template for now, though, where there isn't a defined parameter? We can always merge the templates in the future, if there is consensus to do so (and I think that needs wider discussion than we're seeing here so far). Thanks. Mike Peel (talk) 20:16, 13 September 2020 (UTC)

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

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

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

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)

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

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

From below, some talk page copy-paste "archives" may not be tagged like this. A bot may be suitable for this task if wanted. — xaosflux ^Talk 13:09, 20 August 2020 (UTC)

The most talk pages of BLP's are noindexed by way of having a template that inlcudes the NOINDEX directive is because those talk pages transclude Template:BLP, which contains a __NOINDEX__. Conventionally, the ((BLP)) is not used directly, but is done by means of either or both of ((WikiProject Biography|living=yes)) or ((WikiProject banner shell|blp=yes|1=...)). --Redrose64 🌹 (talk) 19:37, 20 August 2020 (UTC)

• Something I've just observed for a new page I created is that, even though it's not listed on Google yet since it hasn't been checked off at NPP, its talk page is listed. That's definitely not what we want. ((u|Sdkb)) ^talk 23:49, 31 August 2020 (UTC)

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

It would be pretty useless to limit, and counterproductive. I'd rather have someone goof around in their sandbox than insert random, incorrect commas on live articles. Must consider the purpose of autoconfirmed, which is a very minimum requirement and not meant to be hard to get. If you try change that, these "trolls" won't stop, you'll just inadvertently send the issues into mainspace. ProcrastinatingReader (talk) 15:38, 10 September 2020 (UTC)

It is possible to use other types of thresholds for granting access to automatic groups, but as PR notes above - the bar for "autoconfirmed" is meant to be very low - primarily as a screen against non-wikipedia bots and casual spammers/vandals. — xaosflux ^Talk 16:06, 10 September 2020 (UTC)

• I know this doesn't directly address your original question, but if there's a specific page (or small set of pages) that are being abused, WP:ECP, could be applied. You can request this at WP:RFPP, or if you really feel it can't be discussed on-wiki, feel free to email me. -- RoySmith (talk) 16:20, 10 September 2020 (UTC)
• This question comes up fairly regularly, most often "to limit the permission to the mainspace edits" in some form (I'm am pretty sure it's on WP:PEREN at this point). It would require significant rework in how automated permissions are granted. Users gaming permissions are routinely taken care of after the fact. --Izno (talk) 16:37, 10 September 2020 (UTC)

Strongly Oppose The sandbox is a sandbox. No damage is done to the wiki if someone vandalizes the Sandbox. Like yeah, you're a jerk if someone has made an experimental page there, but it's not permanent. This doesn't make sence. Also, if a sandbox is like practice, then it should count towards edits. No explanation needed. Arsonxists (talk) 00:19, 11 September 2020 (UTC)

Comment: To be clear, this isn't to prevent sandbox edits from being logged and counted towards one's contribution history, bur rather to keep abusive users from gaming the system by making test edits to qualify for autoconfirmed status. Blake Gripling (talk) 02:01, 11 September 2020 (UTC)

I am pretty sure that you have to wait 4 days before autoconfirmed status, even if you made 10 edits. I do get what you're saying, but ussually, abusers don't go to the Sandbox to get autoconfirmed status, they ussually just vandalize ones that anyone can edit.Arsonxists (talk) 14:50, 11 September 2020 (UTC)

And those who do, will find other ways to bypass the auto confirmed status another way. It's an open encyclopedia, this is the side effect of that mission statement. —TheDJ (talk • contribs) 14:36, 14 September 2020 (UTC)

• I am inclined to agree with User: ProcrastinatingReader. It is better to have some one goof around in a sandbox than vandalise main articles, and if a Wikipedian does, for example, insert a blatant hoax, s/he is likely to get a message saying the sandbox is meant for experimentation Vorbee (talk) 15:30, 14 September 2020 (UTC)
• @Blakegripling ph: Won't help, generating 10 edits without using the sandbox is a piece of cake. I think the 10 edits are more to stop sleepers from gaining autoconfirmed after 4 days. And well-meaning newbies, of course. I doubt it was ever intended to stop (serious) vandalism. — Alexis Jazz (talk or ping me) 16:57, 14 September 2020 (UTC)
  • It's actually kinda helpful, because if vandals want to vandalize a part of Wikipedia that's auto-protected, it may force the vandal to either not vandalize that part, delay the attack 4 days, or be a contrustive part of Wikipedia for a moment. So yeah, removing sandbox edit counting won't help that much. Arsonxists (talk) 18:46, 14 September 2020 (UTC)

• Except they don't do the "constructive part of Wikipedia" bit well. Autocon-busters usually make either very minor one-character edits or null space edits to reach 10 edits. Whether or not the sandbox counts for these purposes is irrelevant because they'll just do these edits elsewhere. —A little blue Bori v^_^v ^{Hasteur Hasteur Ha-- oh....} 20:41, 14 September 2020 (UTC)

• Is what the proposer is saying that one's contributions to the sandbox should not count towards one edit count? Would there be a way to indicate, if a Wikipedian clicks on "Edit count", how many edits were merely contributions to the sandbox? Vorbee (talk) 07:50, 16 September 2020 (UTC)
• I have just been on the Edit count function at Wikipedia, and whereas it tells one how many edits are to the talk pages, how many are to the main pages, how many are to User talk, how many are to category talk and so forth, it does not have a separate section saying how many edits are to the sandbox. I am not sure what category edits to the sandbox would fall under, and while I appreciate this might be technically difficult, I am wondering whether it would be feasible to introduce a section "Sandbox" in Edit count. Vorbee (talk) 06:41, 17 September 2020 (UTC)

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

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

@Xaosflux and TheDJ:

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

I think you have actually identified two distinct issues here: 1) we don't have any evidence that stub tags are achieving their stated purpose, and 2) stub tags are conflicting with WikiProject assessments. For #1, I think an experiment could yield from interesting results. For #2, I think this would make a nice bot task to remove stub tags when a WikiProject assessment is upgraded from stub. It might be worth upgrading ((WPBannerMeta)) to generate a reassess flag for the bot to add when a stub tag is removed, but a WikiProject still has it assessed as a stub. For the experiment on #1, I would suggest:

1. Get a list of something like 10,000 random articles, and remove any that are not assessed as a stub by WikiProjects, or have neither a stub tag nor a WikiProject banner on its talk page.
2. Do an assessment of the remaining articles and remove any that aren't actually stubs.
3. Split WikiProject claimed articles by stub-tagged or not, and remove/add stub tags to get each WikiProject's article count roughly even (shoot for at least 1/3 of each). Remove stub tags from the unclaimed articles to even out the total count, again going no less than 1/3 for either group.
4. For the two groups, drop the top and bottom (quartile? ⅒th?) in terms of edit size, ignoring any bot edits, and compare the two groups by interest (number of edits by unique editors), engagement (number of non-revert, non-patrolling edits by registered editors), and overall article change (total prose added to article during experiment run time). VanIsaac_WS^cont 14:17, 21 June 2020 (UTC)

   Thanks for your input. Abductive (reasoning) 23:07, 21 June 2020 (UTC)

• Oppose The OP doesn't present any evidence to support the proposal. Me, I'd rather eliminate project templates and assessments as I've never seen these do any good and they tend to stick around for longer. The stub templates are comparatively unobtrusive and have an encouraging and pleasant tone. Andrew🐉(talk) 22:47, 21 June 2020 (UTC)

  So, I present no evidence, then you say talk page assessments don't do any good, and also present no evidence. Abductive (reasoning) 23:07, 21 June 2020 (UTC)

  This is not my proposal and so it's not my responsibility to be providing evidence. But here's a couple of examples – both being articles that I created recently. Firstly, consider Ambarnaya. I created this with the ((river-stub)) tag. User:Catan0nymous added two more stub tags: ((Russia-stub)), ((Siberia-stub)) and user:Abune then consolidated the stubs into ((Russia-river-stub)) and ((Siberia-stub)). These tags seem to have three functions:

  1. Placing the article into the categories: Category:Siberia geography stubs and Category:Russia river stubs
  2. Displaying some appropriate icons -- maps of Russia and Siberia
  3. Advising the reader that the article is just a start and inviting them to help expand it

  My second example is List of longest-running radio programmes. In that case, I started out with the ((under construction)) tag because the page needed a good structure as a foundation and I wasn't sure what would be best. Once that was done, I removed the tag. By that time, the list structure was established and I used the ((dynamic list)) tag to indicated that the list was quite open-ended. That tag also invites the reader to add sourced entries and so I didn't see the need for a stub tag too.

  Neither of these cases indicate that stub tags are a problem that needs fixing. Sensible editors use them as they see fit and they don't seem to cause any trouble. One feature which helps is that, by convention, they are placed of the foot of an article, where they don't get in the way.

  Andrew🐉(talk) 08:00, 22 June 2020 (UTC)

  Andrew Davidson, I agree with the assessment system. It's absurd. Articles can be Stub, Start, C, B, GA, A, or FA. That's seven levels, which is absurd. The gradations are way to small, and the assessment criteria way to subjective. Class A articles are "Very useful to readers", but GA are, "Useful to nearly all readers". That's absurd. -- RoySmith (talk) 02:15, 22 June 2020 (UTC)

  The minimum acceptable standard for an article on the front page at ITN, OTD or DYK is effectively B class due to the requirement that they be fully referenced (the same goes for the de-stubathons), although we can't state that explicitly because B class ratings are in the hands of the projects. GA and FA are community assessments. B class articles are generally capable of becoming GA, but there is little incentive to submit them for review (GA is already backlogged enough), unless you are seeking to take it to DYK, FA or FT. Similarly, A class articles are generally capable of becoming FA after a review, but most cannot because each editor is limited in the number that can be submitted. So we have three categories (stub, start and C) for poor quality articles. The differences between them are fairly objective, but the value of the distinction is questionable. Hawkeye7 (discuss) 22:57, 20 July 2020 (UTC)

• Comment I doubt the suggested experiment would produce any clear results frankly. People are often reluctant to remove stub tags, or simply don't notice them. The wikiproject tags are just as prone to under-rate as the ones on the article in my experience. What might be more useful is a list of articles tagged as stubs where the article is over a certain size (not sure what). Reviewing these would I expect show most can be removed. Of course people still have to do this. Johnbod (talk) 23:59, 21 June 2020 (UTC)
  • The issue isn't so much as picking the certain size, it's defining what size is. The easy way out is to count the characters of wikitext, and you end up with quarry:query/46032. But plenty of those only have a half dozen or fewer sentences, despite their absolute length. —Cryptic 01:22, 22 June 2020 (UTC)

    Like Negombo_Polling_Division - but that has massive tables, no doubt like the other Sri Lankan electoral districts, & certainly isn't a stub. In fact I'm pretty sure most of these are mainly tables. But thanks. Johnbod (talk) 02:44, 22 June 2020 (UTC)

    • Do you know of any utilities for querying the size of the prose text? VanIsaac_WS^cont 02:06, 22 June 2020 (UTC)
      • https://www.mediawiki.org/wiki/ORES articlequality is not bad at all. I think it guesses based on discounting common words and repeated words, which is often a feature of lists and tables. Abductive (reasoning) 04:07, 22 June 2020 (UTC)

        I'm not sure how it works, but the MilHist Project has been using it with considerable success over the last few months to assess unassessed or incompletely assessed articles. Articles that are auto-assessed as B class are flagged for human review. Hawkeye7 (discuss) 22:57, 20 July 2020 (UTC)

        WPMED has been using it with success, and some of ORES's 'stub or not-stub' work was trained on medicine-related articles. See m:Research:Screening WikiProject Medicine articles for quality for a query that they ran for me a couple of times. I would be perfectly comfortable having an ORES-based bot set (and remove) all stub-class ratings for WPMED. WhatamIdoing (talk) 00:34, 7 August 2020 (UTC)

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

I don't see why, User:Encyclopædius. I won some sort of prize in one of your excellent contests, but when looking for articles to improve, I remember just removing the stub tag on about five for every one that actually was a stub. I don't agree with complete abolition, but they are in a serious mess & should be sorted out. Johnbod (talk) 13:58, 22 June 2020 (UTC)

Yup, and can you believe when I proposed a bot to control the inconsistency and remove stub tags from articles with over 1.5 kb readable prose and update the talk page tags some people opposed? Andrew Davidson for a start. † Encyclopædius 14:04, 22 June 2020 (UTC)

Can a bot at least go around and remove stub tags from all really huge articles that have talk page templates that claim Start-class or above? Then maybe work its way down to smaller articles until it on the verge of making errors? Abductive (reasoning) 04:18, 24 June 2020 (UTC)

Yes. In fact, the MilHistBot is already capable of carrying out this task. Hawkeye7 (discuss) 22:57, 20 July 2020 (UTC)

AWB does something similar, too, by removing stub tags from articles that are above a (generous) size. WhatamIdoing (talk) 00:35, 7 August 2020 (UTC)

• "stubs" help navigate articles that need attention. They typically are located at the very bottom of article and do not interfere with regular reader who has no intention to improve article. Basically nothing is wrong with "stubs" as far as I'm concerned. User:Abune (talk) 13:04, 22 June 2020 (UTC)

  Very true, User:Abune. Readers rarely notice them, and even if they do, it is hard to see that they have any negative impact. Some editors find them useful. What's the problem? (A: there isn't one). Edwardx (talk) 14:34, 22 June 2020 (UTC)

• Qualified support. I generally agree with the issues raised by the proposer. Stub tags are not particularly aesthetically pleasing, and do tend to linger after the article has been expanded to the point where they are no longer appropriate. Efforts to just find and remove them at that point become busywork. I am wondering if there is some template magic that can be applied so that stub tags on articles that are likely not stubs can turn invisible, and just show up as categories. BD2412 T 15:11, 22 June 2020 (UTC)

  @BD2412: no problem: Template magic. 10000 might be a tad much. Also you'd have to make all stub templates pass the forcestub parameter in order to be able to force the stub template on articles longer than 10000 bytes. - Alexis Jazz 01:16, 21 July 2020 (UTC)

• Simpler solution: If you come across an article that you think is no longer a stub... remove the tag. Problem solved. Blueboar (talk) 15:19, 22 June 2020 (UTC)

  Not really - pretty much no one who would know how to do this ever looks at these articles, all xxx,xxx of them (what is the number, does anyone know?). Johnbod (talk) 21:44, 22 June 2020 (UTC)

  There are 3,399,601 stubs as of now. You can see the stats here. TryKid ^{[dubious – discuss]} 23:28, 22 June 2020 (UTC)

  Yikes! Over half our articles. These are project ratings though. I see 4,310 "top importance" stubs! Thanks, Johnbod (talk) 01:28, 23 June 2020 (UTC)

  I'd like to see one of those top importance stubs. To make a start I followed TryKid's link to find Category:Stub-Class_articles. From this, I selected Category:Stub-Class Accounting articles because there is a systemic bias against business articles. Accounting standard looked promising and I found that this is assessed as High importance but Stub class. This is all coming from the project template as the article page doesn't have any tags. It could use some because I immediately noticed a blatant howler, "Accounting standards were largely written in the early 21st century." What I also notice is that while its talk page only had 7 readers in the last 30 days, the article itself had 2,481. I could now tag-bomb the article but what it really needs is improvement... Andrew🐉(talk) 08:55, 23 June 2020 (UTC)

  Yeah, 3M project rating stubs. The number of "tagged" stubs seems to be 2,265,086, from Category:All stub articles. This number looks more correct since many of the "top importance stubs" aren't stubs anymore and are already detagged but the talk page wasn't updated. As previously pointed out, even many of the "tagged" stubs aren't stubs. Maybe a bot that automatically upgrades project rating of stubs to "start" if a tag isn't found on the main page is needed. Blofeld's idea of automatic detagging if the article is above a certain size was also good. TryKid ^{[dubious – discuss]} 12:59, 23 June 2020 (UTC)

• Support In my early (2005) days, stub-sorting was one of my favorite hobbies, and it saddens me to finally deprecate the stub templates, but nowadays they are duplicative of the assessment templates on the talk page and thus unnecessary. -- King of ♥ ♦ ♣ ♠ 01:58, 23 June 2020 (UTC)
• Oppose, although a possible alternative is to link the stub tags to the WikiProject banner, if the article is assessed as a Stub class a bot adds the tag, if (hopefully when) the article is upgraded to Start or higher a bot removes the tag. Cavalryman (talk) 02:19, 23 June 2020 (UTC). Amended comment to oppose retaining alternate. Cavalryman (talk) 06:55, 27 July 2020 (UTC).
  • This is a very good idea. It fixes the discrepancy between main page and talk, while keeping some level of friendly encouragement at the main page. - Nabla (talk) 14:52, 27 June 2020 (UTC)
• Oppose While I agree that many of the problems you listed are real and affect Wikipedia, stub tags are necessary. They may not be very effective at getting readers/editors to add content to or destubify articles, but they make a vital contrast between what is and is not a reasonable length for an encyclopedic article. Most readers don’t care to browse Wikipedia’s myriad informational pages on article length, the different classes, prose, etc. Stub tags are simple, easily understood, and to-the-point. If we’re going to get rid of stub tags, why not just get rid of the stub classification altogether? It doesn't make sense. Improvements should be made, but we need them. Their importance to the project overrides any negative aspects. MrSwagger21 (talk) 02:26, 23 June 2020 (UTC)
• Oppose per MrSwagger21. - ZLEA _T\^C 02:52, 23 June 2020 (UTC)
• Comment on balancing editor and reader needs. Regarding editor needs (which we always tend to overprioritize, given the systemic bias introduced by who we are), my takeaway here is that it seems there's no evidence that the tags draw editors, and while it's perfectly plausible they do, this might be a good thing for someone to do a research study on. Regarding reader needs (which I don't see really getting proper attention here), the way we indicate article quality is a little quirky — we indicate GA/FA with a topicon, but stubs with a tag at the bottom, and nothing in between. I think there's a reasonable case to be made that stubs, given their low quality, ought to have the tags as a sort of warning. The counterargument would be WP:NODISCLAIMERS and the fact that there's a distinction between low quality and just short, and most stubs in my anecdotal experience are not lower quality than start/C class pages, just shorter. I'm not sure where I land on the necessity of stub tags, but I hope we'll consider how they impact the experience of non-editing readers, not just editors. I have brought up before that there is room for improvement in how we present content assessments to readers more generally (particularly, the difference between GAs and FAs is not made clear), and I'd like to see more work in that area. ((u|Sdkb)) ^talk 07:53, 23 June 2020 (UTC)
• Oppose no. They are helpful and low-key. Not in anybody's way. Regards, GenQuest ^{"Talk to Me"} 10:47, 23 June 2020 (UTC)
• Comment: sorry for the somewhat self-promo, but this is something that could hopefully be done with relatively little consternation were my proposal for an extension that adds categories from tags on the talk page successful. Such a move would allow the pages to retain the stub categories, without the duplication of effort in tagging the article with stub tags and also doing the assessments on the talk page. Naypta ☺ | ✉ talk page | 13:07, 23 June 2020 (UTC)
• weak oppose for now - People I talk to (non editors) are often not aware a talk page even exists for an article. If a stub tag encourages the occasional person to add content then I see that as a Good Thing. If there were some way of showing that there was no evidence that this occurs, then I'd support their deprecation. I should add that the proposal was worth bringing up and I did consider supporting, and I do think the topic is worth exploring. Cas Liber (talk · contribs) 04:54, 24 June 2020 (UTC)
• Conditional support. Stub templates are messy and outdated, and does not do what they are supposed to do, although they have other important uses. I suggest removing the templates, but replacing them with categories or a function within WikiProject banners. Rehman 05:21, 24 June 2020 (UTC)
• Support - simplification is good. What stubs do can/is/should be done in a talk page banner, e.g. wikiproject assessments. Bottom line is we should have one place where we record what state an article is in, and that one place should probably be in a talk page banner. Levivich ^{[dubious – discuss]} 19:26, 26 June 2020 (UTC)
• Oppose per Cas Liber. Stub tags are at worst benign. They're the literal bottom of the article and if a reader wants to ignore it, they can. I really can't understand how they can be seen as harmful. On the other hand, if they get 1 reader to help expand an article, the encyclopedia benefits greatly at pretty much no cost. They're a clear net positive. Putting them on the talk page may be convenient for us and our internal categorizations, but that's counterproductive for article improvement. Most people don't know about talk pages (seriously, ask your friends the last time they looked at an article talk page), so hiding the stub tags where only insiders will find them is in my mind a net negative. — Wug·a·po·des​ 21:37, 27 June 2020 (UTC)
• Oppose. Stub templates are a type of maintenance template. Because of their ubiquity, we've decided to put them at the bottom instead of the top of the page. They share all the pros and cons of other maintenance templates. One one hand, we think that – given the dynamic nature of Wikipedia – we should alert readers and editors if something is not right with an article. On the other hand, we don't know if more time is spent tagging or actually fixing articles. The main problem I see with stub templates is what others have pointed above. We have two systems to mark an artcle as a stub: stub templates and talk page banners. These are not always in synch. When this happens, the fault is with the editor who (de)stubs an article using only one method. The guideline at WP:DESTUB says to do it using both. I'm sure we're moving toward automatic article assesment (WP:ORES) at some pace. In the meantime, we should automatize getting rid of the discrepancies between stub templates and talk page assesments using a bot. – Finnusertop (talk ⋅ contribs) 23:20, 27 June 2020 (UTC)

  "we don't know if more time is spent tagging or actually fixing articles" Probably the first one, in my considered opinion. RandomCanadian (talk / contribs) 03:43, 5 July 2020 (UTC)

• Support A good solution, as already proposed by others, would be for categorisation via wikiproject banners on the talk page. RandomCanadian (talk / contribs) 03:43, 5 July 2020 (UTC) Striking sockpuppet.P-K3 (talk) 22:47, 8 July 2020 (UTC)
• Oppose I'm not joking in saying that this is normally how I find GAs to write. Stub tags are invaluable. TonyBallioni (talk) 02:17, 6 July 2020 (UTC)
• Oppose I hate creating articles (for some reason), I don't think I've created an article yet. I do help massively improve existing articles, and have plans to edit a couple of stub articles and make them more full. Stubs have their benefits, help find topics that may look interesting, and give one a chance to expand them. Also, what Tony said above. ProcrastinatingReader (talk) 12:23, 6 July 2020 (UTC)
• Comments: Leaning toward oppose, as the WikiProject placement on Talk pages make them less obvious to readers and editors, to the point that I tend to forget about them. I would also to interested to know:
  • Do all stub categories have associated WikiProjects?
  • Is if there an easy way to get a list of articles pages (as opposed to the talk pages; c.f. Category:Stub-Class video game articles to Category:Video game stubs) from the WikiProject categories?
  • Could WikiProject stubs be organized into subcategories like the stub templates?
• —Ost (talk) 22:27, 9 July 2020 (UTC)
• Weak Conditional support. As per @Rehman above. However, few editors may still use those stub templates. If they were at the top, maybe it would be diffwerent, but I say drop them and go with what Rehman said above. --Guitarist28 (talk) 14:32, 14 July 2020 (UTC)
• Oppose removal. I think the format of the tag should be changed, though. I am coming from the perspective of a wikiHowian, where stub tags are placed on top of stub articles. I think it would be more useful if the stub tag was in the form of other maintenance templates. Something like:
  
  This article has been tagged as a stub.That means that the article is off to a good start, but still does not provide complete encyclopedic coverage of the topic. Please help Wikipedia by expanding this article. (Learn how and when to remove this template message)
  
  That way, readers see what they can do to help Wikipedia. By having them at the top, readers can work on expanding the article, and then remove the stub tag once the article provides more coverage. Aasim 08:06, 18 July 2020 (UTC)

  Awesome Aasim, I like the idea of a more clear tag, although it should be ambiguous that it isn't a major issue with the article itself, and should actually encourage people to build the page, like:
  

  This article is a stub page.Anyone can help build Wikipedia by expanding this article. (Learn how and when to remove this template message)

  Ed6767 talk! 00:21, 21 July 2020 (UTC)

• Comment One badly needed step would be to go thru all of these stubs & verify that they are, in fact, stubs. In my own browsing thru articles I've found that a quarter should be re-graded to "Start" or better. And about 1 in 10 of the "Start" class should be regraded as "C" or better. (Since my experience is at odds with Johnbod above, maybe my evaluation is more strict than his?) In any case, I figure re-evaluating as many stubs as possible would help reduce the number of stubs in Wikipedia to less than half the total number. --llywrch (talk) 21:52, 20 July 2020 (UTC)

  There are two types of articles here: (1) articles that have already been re-graded as start or higher, but still have Category:Stub message templates on them; and (2) articles that are classed as stubs, but really are start or higher. Hawkeye7 (discuss) 22:57, 20 July 2020 (UTC)

  Possibly, or we're looking at different articles. I feel most assessors pretty much only take length into account, whereas for some subjects a few lines might be C or even higher. The official definitions for the classes are actually pretty generous, & I think most assessors are rather too strict (as well as judging mainly on length). Johnbod (talk) 00:08, 21 July 2020 (UTC)

  Responding to both comments together. Hawkeye7 the first case could easily be addressed with a bot -- & probably needs to be done in any case -- while the second describes the phenomenon I was talking about. Johnbod I suspect we might be looking at different articles, or groups of articles. When calling an article a "stub", I look more to how completely the article covers the topic than the length -- there are some notable historical personages about whom all we can write is limited to 2 or 3 sentences, which means we are stuck with what I call a "permastub" -- although if an article is, say, 5,000 bytes in size & marked as a "stub", I'm going to look hard at why it has that assessment instead of a "start" or "C" class. And sometimes it requires expert knowledge to know what information is available about a given topic, in order to know if the article completely covers it. -- llywrch (talk) 16:55, 21 July 2020 (UTC)

  Ah, perhaps different standards then - I stand with User:Grutness/Croughton-London rule of stubs, and indeed the official definition, though of course "the breadth of coverage expected from an encyclopedia" (which stubs lack) is wonderfully vague. But most articles in most print encyclopedias would be called "stubs" by most WP assessors imo. Johnbod (talk) 17:23, 21 July 2020 (UTC)

• While I support the idea, there are a few things we should consider:
  1. The public. Stub came to have meaning outside the editing community: The list gradually changing colour on Haskell's screen represented hundreds of women scientists who have either never had a Wikipedia entry, or whose lives and work are dismissed in a stub a few lines long.
  2. I'd favor something more descriptive, like ((Television needs production section)). Stub tagging is kinda lazy. (guilty as charged)
  3. I very much support an experiment. I would suggest we pick a number of articles. For half of them a hash is created and only the hash is published. For the other half you remove or hide the stub tag, but don't publish a list. Sure one could look at the contributions of the bot that does it, but we can't control that. We'll have to wait until a decent number of articles on the list has been improved beyond stub status, at which point we'd publish the list of still-stubbed articles and compare.
  4. As BD2412 suggested, Template magic. - Alexis Jazz 01:16, 21 July 2020 (UTC)
• Oppose the editors at College Football Project often use the stub tag to focus editing efforts and assist with improving articles.--Paul McDonald (talk) 13:20, 24 July 2020 (UTC)
• Oppose removing the stub templates, they do have a function. We possibly also need to:
  1. add an option for notes to the stub template
  2. explore a way to merge the stub flagging and the assessment systems
  3. create a bot task to find stub articles that have grown / had n edits / had a change of assessment. — GhostInTheMachine ^{talk to me} 13:05, 27 July 2020 (UTC)
• Comment - I have edited hundreds of music stub articles, mostly by adding RS to them. I find stubs useful for sorting, at least in this specific regard. Caro7200 (talk) 15:55, 29 July 2020 (UTC)
• Support completely rethinking what stub tags are and what they are supposed to achieve, and whether they do so. As I see it, there are three things we're trying to achieve: (i) tell people that the article isn't complete (ii) ask them to contribute and (iii) we sort the stub tags so people can concentrate on stubs in an area they're interested in. Point (i) is obvious without the tag, yet it often stay s on the article long after ceases being useful. Given how long some articles remain stubs, we are obviously not doing a great job with (ii). Stub sorting has been partially superseded by wikiproject tagging and a generally much improved category system. I must admit I like the fact that stub sorters are there (tagging an article as "stub" is a quick way to get an extra pair of eyes, as it summons a stub sorter within a few hours at most). But I haven't seen any recent evidence that tagging and categorizing stubs actually leads to much improvement at all, or that the duplication of stub/non-stub tagging on article plus talk page does anything useful. Having an easy way to display article quality (not just stub/not stub status) in any category or for any link in a list would be far more helpful. Not just stubs need improving. —Kusma (t·c) 22:47, 1 August 2020 (UTC)
• Comment I find it interesting that no one has mentioned Wikipedia: WikiProject Stub sorting, whose members might have something to contribute to this discussion (I also don't recognize any of the commenters here from the project). One of our members apparently just found this discussion yesterday (August 1) and posted a note on the WPSS talk page. I'll put my 2p in later when I have a chance to read through all the entries here. Cheers, Her Pegship (?) 20:32, 2 August 2020 (UTC)
• Oppose: I personally bookmark several stub categories relevant to my interests and periodically expand them, contradicting the claim that stub tags "don't get people to edit stub articles". I think the only actual problem here is articles that are no longer stubs, still being tagged as such. Sometimes I'm not sure when I'm improving articles very incrementally at what point they have stopped being stubs. I would support a bot to remove outdated stub tags based on talk page assessments, or on a length barrier beyond which an article is clearly not a stub. ~ oulfis 🌸(talk) 01:11, 3 August 2020 (UTC)
• Support Stubs are messy and the visual clutter is immense for the reader.Epelerenon (talk) 05:25, 3 August 2020 (UTC)
• Support The stub tags are a relic of an earlier era. Now that all articles get quality ratings from multiple projects on the talk page, having them also noted as stubs on the main article page is redundant. Time spent adding tags and finding the right categories, and then the time removing them, is time wasted. CaptainEek ^{Edits Ho Cap'n!}⚓ 06:57, 3 August 2020 (UTC)
• Oppose. While WikiProjects cover many topics, not all stub articles fall under the purview of a WikiProject, and not all the projects use assessment tags. I have no opinion on project assessment tags, but stub tags/types/cats are not only applicable and useful across the entire encyclopedia, but also a way to gauge which topics need maintenance of other kinds. (I do believe that the parameters of what constitutes a stub article should be revisited.) Last but certainly not least, the editors of Wikipedia:WikiProject Stub sorting have been faithfully maintaining, sorting, and standardizing stub types for over 15 years (that I know of), and eliminating the fruits of that work across the encyclopedia would be counterproductive. Her Pegship (?) 17:36, 3 August 2020 (UTC)
• Oppose: I'm frequently disgruntled by tags and tag-bombing. But I find the stub tags the least-intrusive and one of the most valuable of all the tags. Bot jobs of updating either the article or the talk page when one is changed would be valuable, but the tags do help editors find stubs in a category they're interested in. The stub categories and WikiProjects don't quite align, as I'm not the first to point out, and I think this is a feature not a bug. — Bilorv (talk) 23:13, 3 August 2020 (UTC)

  Inconsistency between article page tags and talk page project tags is certainly not a "feature" - it is purely the result of carelessness/sloppiness/ignorance on the part of editors. The stub definition is general - other quality ratings may vary with the relevance of an article to a particular project, but an article should either be or not be a stub for everyone. What would be the benefit of such a "feature"? Johnbod (talk) 01:28, 4 August 2020 (UTC)

  I believe what Bilorv means by "stub categories and WikiProjects don't quite align" is not inconsistency between ratings in the stub tags and the WikiProject assessments (ie the same article being called a stub one place and start-class another, which is a "bug"), but differences between stub categories and extant WikiProjects (ie an article being tagged as '18thC-novel-stub' even though there's no wikiproject for 18thC novels). I agree with Bilorv that this second kind of misalignment is a feature and not a bug, as it is useful to have stub categories be specific, whereas wikiprojects need to be rather broad. For the Great Britain and Ireland Destubathon, for example, it was extremely useful to have stubs categorized by quite specific geographic regions, even though it would be nonsense for a whole Shropshire wikiproject to exist. ~ oulfis 🌸(talk) 19:51, 4 August 2020 (UTC)

  Thank you Oulfis, this is exactly what I meant, and apologies for the confusion. — Bilorv (talk) 20:47, 4 August 2020 (UTC)

  Ok, thanks for the clarification. Johnbod (talk) 21:07, 4 August 2020 (UTC)

• Support. The stub tags are a subset of the project rating system (and predate projects). Several people have stated that they use the stub tags to find work to do. That's great, but they could do exactly the same thing by bookmarking the applicable project stub categories, such as Category:Stub-Class animal articles, or even Category:Stub-Class articles. As a software guy, I believe in DRY, and now that we have project ratings, stub tags violate that. -- RoySmith (talk) 01:55, 4 August 2020 (UTC)
  • The reference to DRY is amusingly misdirected. In my experience, articles don't usually get multiple stub tags but one often find a great proliferation of project tags on the talk page. and so I often use ((WikiProjectBannerShell)) to cut down on the clutter. For example, I recently updated Stonehenge which has 11 different project templates ranging from WikiProject Alternative Views to WikiProject World Heritage Sites – a project that is explicitly inactive. The various project ratings are inconsistent and there are other independent assessments too such as a Vital rating and GA review. If you want to cut down on repetitive clutter then the place to start is the talk page. Why, for example, is there not a single template for projects, which lists all the relevant projects in one combined list? Why does each project have to have its own separate template? It's not invented here, I suppose. Andrew🐉(talk) 09:59, 4 August 2020 (UTC)
• Comment: "all articles get quality ratings from multiple projects on the talk page"? No. They don't. I sort a lot of stubs, and frequently create the talk page and add project banners. Many readers don't know much about projects, they don't belong to one but just edit their own chosen subset of articles, or perform their favourite subset of Wikignoming. If the stub categories were abolished in the belief that projects do it all, we would need a maintenance category such as "Pages (other than dab pages or redirects) whose talk page has no project banner" - and even then the pages which have ((WP Bio)) but nothing more specific would end up lost. PamD 19:02, 4 August 2020 (UTC)
• Support - stub tags are just visual clutter. You can usually get the same information from WikiProject categories. Maintaining the same information in multiple places is a waste of time and effort (and screen space). Kaldari (talk) 20:35, 4 August 2020 (UTC)
• Support. No longer necessary. We presumably have quite a lot of left-over functionality that's no longer needed, and this would be a good start in clearing them up. DGG ( talk ) 00:26, 5 August 2020 (UTC)
• Strong Support - Useless garbage. Schierbecker (talk) 14:22, 5 August 2020 (UTC)
• Oppose - The stub tags are out of the way, do not interfere with reading the article and help in categorizing and drawing attention to articles in need of more content. Removing them would be counterproductive. A better use of our time would be a bot that removes stub tags from articles that are over a certain prose size in length. Ciridae (talk) 16:30, 5 August 2020 (UTC)
• Support. The sole potential benefit is ease of searching up very short articles to expand, and that can already be done with Wikiproject ratings. Meanwhile, I doubt readers in 2020 need stub tags anymore. SnowFire (talk) 21:39, 5 August 2020 (UTC)
• Oppose. The stub tags are linked into other portions of the encyclopedia, and work with the Wikiproject ratings, so removing them would cause a whole set of other problems. Frankly, I like the stub tags, they definitely have encouraged some readers to positively contribute to the project. In an era when Wikipedia is losing new contributors, shouldn't we be trying to attract more? It's also not like they are taking up space on servers, and don't clutter articles as nearly as much as the issue tags at the top. Modifying those seems to be a better way to achieve what the original poster wants. User:Heyoostorm^_talk! 16:26, 6 August 2020 (UTC)
• Support — My opinion is the stubs are graffiti and serve no useful purpose. —¿philoserf? (talk) 08:07, 8 August 2020 (UTC)
• I think I fall on the oppose side of the s-o spectrum. I don't think it makes sense to rely on WP ratings (as noted above, many pages end up with stub tags but no WP tags). For utility, I do tend to agree that the "find short articles that could use expansion" side is fairly convincing from a utility-aesthetics spectrum. I do find it a bit obnoxious that sometimes these don't match the WP ratings, but that's a job for a bot (as noted above). If I have any pain point with stub tags, it's that they basically duplicate our category structure (whether on the article side or the WP side), and could use a much smaller tree from which to select a stub tag. (I might even suggest that we should remove all sub-stub tags and put the weight on proper categories and proper WP tags; editors interested in stubs for the categories of interest can use one of our intersection tools such as WP:PetScan.) From a visibility perspective, I actually kind of like the idea of going full ((ambox)) on them.

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

• Support. Mandatory reading of Banner blindness as to why those things are useless for the average reader. Popo le Chien ^{throw a bone} 18:44, 10 August 2020 (UTC)
• Oppose deprecating stub templates. The visible part of the template is for the reader, not the editors. It sends the message that Wikipedia is not finished. It also soothes the reaction "WTH, is this all you have on the topic?" by saying "yes, we know this is incomplete". Banner blindness may apply to frequent readers, but we should also consider more casual readers. Compare ((User page)) and ((User sandbox)) which are also aimed at informing the uninitiated. Even though the call to action probably doesn't result in immediate action, it reinforces the "anybody can edit" idea. Pelagic ( messages ) – (17:23 Tue 11, AEST) 07:23, 11 August 2020 (UTC)
• Comments. Talk-page templates are suppressed on mobile, whilst stub tags aren't (though you may have to expand References or External Links, whatever the last section is). Also, it's not immediately obvious that the talk page should be where one looks for other article meta-data like quality rating. Pelagic ( messages ) – (17:23 Tue 11, AEST) 07:23, 11 August 2020 (UTC)
• Questions. If Encyclopædius and Rosiestep couldn't get consensus for a bot that directly updates stub and quality tags, how about a bot that adds them to a category for review, like Category:Not-stub stubs? Or some other interactive query? How resource-expensive is it to run an article through ORES, is the score calculated automatically on save/publish and stored with the revision, or would a bot that compares ORES scores to stub tags be costly to run? Pelagic ( messages ) – (17:23 Tue 11, AEST) 07:23, 11 August 2020 (UTC)

There is Wikipedia:Database reports/Long stubs, which has been updated recently. Don't know if there's a bot that can check the entries, or if it can only be done by human. Her Pegship (?) 17:36, 12 August 2020 (UTC)

• Support per DGG. I agree that they have outlived their usefulness. They also are a pit of make-work for gnome editors (stub sorting) who would otherwise be doing more useful things. Calliopejen1 (talk) 00:16, 16 August 2020 (UTC)

For some of us gnomes, stub sorting is the only aspect of editing WP we feel confident about. Not a reason to keep stubs...just saying. ;P Her Pegship (?) 00:52, 16 August 2020 (UTC)

• Support There are several articles on Wikipedia, which are long enough not be a stub article, but still classified as stub. Go to 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)

  What the Hindi and Bengali Wikipedias do with stub tags is their own business. Maybe they have rules that don't just concern article length - such as the amount of referencing, or the quality of the writing. Or maybe the person who creates these sub-100-word articles simply doesn't know about stub tags. Whatever the reason, it's nothing to do with us; we cannot tell them how to handle stub tags on their Wikipedias. --Redrose64 🌹 (talk) 15:14, 18 August 2020 (UTC)

  Yes, not many editors know how to add or remove Stub tags, what criteria must be fulfilled in order to classify some article as Stub or remove the Stub tag, which is the reason why I support the removal of Stub tags altogether. After all, the Stub tag in English Wikipedia can be very misleading sometimes (please go through this weblink 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)

  Hindi Wikipedia is nothing to do with us. If you want to change their practices, do so at their discussion forums, not here. --Redrose64 🌹 (talk) 17:00, 18 August 2020 (UTC)

• No? Someone can correct me if I'm mistaken, but I believe more than half the articles on the project are stubs? So... We're going to get rid of hundreds of templates and make edits to millions of articles because?...There is a general feeling of indifference to their usefulness? Sorry. That's not a project you undertake when the main argument is "meh". If you don't like em, don't use em. No one is going to drag you to ANI because you're just not particularly into stub sorting. GMG^talk 13:34, 18 August 2020 (UTC)
• Oppose, solution looking for a problem. Stifle (talk) 16:05, 21 August 2020 (UTC)
• Oppose. I'm unconvinced by the arguments for. I might be convinced that the stub information should not be visible on the article page, since readers aren't going to care -- they can already tell it's a short article, without needing us to help them out. I'd also be OK with some of the other suggestions made, such as making the stub tag invisible if a WikiProject has assessed the article above stub on the talk page, or hiding the tag above a certain article size. But getting rid of them is throwing out the baby with the bathwater; there are legitimate uses for stubs which outweigh the minor benefits discussed above. Mike Christie (talk - contribs - library) 16:20, 21 August 2020 (UTC)
• Oppose Having more than one way to group and access stub articles to work on is totally sensible, so this is a daft proposal. Removing them would only weaken the Project. That said 'stub' categorisation on an article page, whilst unnoticeable to the vast majority of readers, really does need to match with Talk page WikiProject assessments. I confess to often amending the latter, but forgetting to remove the former. If there isn't agreement for a bot to do the work of removing outdated stub tags, then at least a tool to identify the mismatch between talk pages might be valuable for some editors. Personally, what I find frustrating is to have to individually change three or four 'stub' assessments on Talk pages - one for each WikiProject, when that assessment is going to be the same across all of them. Quality assessments could really doing with being integrated so that only one needs to be changed, leaving just the 'importance' assessment to be specific to each individual WikiProject. Just thought I'd throw that out there. Nick Moyes (talk) 19:18, 21 August 2020 (UTC)  

Although in most cases they should be the same, & it is indeed a pain to have to change several, there are many cases where it is wholly appropriate to have different ratings for different projects, especially where a project only applies to a part of the subject. Obviously that is much more often the case for importance ratings, so you might well need to edit every line anyway. Johnbod (talk) 20:33, 21 August 2020 (UTC)

• Oppose - Stubs still have their uses and as noted above they don't interfere with readers as they're directly at the bottom of articles, They're harmless and IMHO I see no valid reason to remove or deprecate them. — Preceding unsigned comment added by Davey2010 (talk • contribs)
• Oppose. It is a long-standing policy that Wikipedia is a work in progress, and stub tags are one of the most visible reflections of that. However, there has been a trend towards intolerance of stubs, and stubs that would have been perfectly acceptable in 2006 are now routinely draftified without discussion. Stub tags serve as a reminder that stubs are a natural part of Wikipedia, and I'm concerned that removing them would further drive that intolerance. --Paul_012 (talk) 09:57, 28 August 2020 (UTC)
• Oppose - As a user of User:Anomie/linkclassifier.js the stub tags, and the corresponding categories, are what cause these links to appear a different colour as I am browsing Wikipedia, in turn I use this to find articles that I might be interested in improving. I would not be opposed to a redesign though.CSJJ104 (talk) 14:54, 30 August 2020 (UTC)
• Oppose – it's simply an invitation to expand the article, which is what wikipedia needs really. Removing stub notes is hiding the embarrassment that much of wikipedia has – inadequate research & topic coverage. – ishwar  (speak) 05:05, 31 August 2020 (UTC)
• Oppose – I agree with earlier comments that stubs are useful and help encourage readers to consider expanding the article. I've also seen too many perfectly acceptable stubs get AFD'd instead of someone taking the initiative to expand them. I really like Awesome Aasim and Ed6767's suggestion above for a "friendly" maintenance tag that encourages readers to expand the article. Carter (talk) 00:29, 1 September 2020 (UTC)
• Oppose – for five reasons: (1) I think they are useful for new editors. All that "Be Bold" stuff? I was terrified of making edits when I first signed up. I thought anything I did would get me called in front of the Wikipedia Star Chamber. But then I started seeing stubs notices on articles I was reading, actually inviting me to try to improve them. That's what got me started making (cautious) edits, to stub pages that I knew a bit about. Stub notes are invitations to new editors: "We really mean it — try to improve this article — give it a go!" (2) They're unobtrusive. Right at the bottom of the page, they don't interfere in reading the article at all. If you read that far, you get the acknowledgement that this article could be better, and the invitation to try to fix it. (3) By contrast, adding big hatnotes at the top of a page, as suggested upthread, is saying "This article is shite, you shouldn't rely on it, but feel free to try to make it better, if you can." It isn't really much of an inducement to read the article. (4) There's Talk pages? Who knew? Why wasn't I told? (5) As I've learnt more about stubs and the intricate connection with the categories, I find them very useful to see the inter-connections between different articles within the same topic, and particularly ones that need work. --Mr Serjeant Buzfuz (talk) 03:36, 1 September 2020 (UTC)
• Oppose – this is a huge issue and should be reviewed with its long-term effects in mind. While stub tags may not be directly effective in expanding stub articles, I think that stub tags are highly useful for Wikipedia, because they create a sense to every reader that "People like you can join Wikipedia". This is a vital part of how some readers become editors, and I'd say a good percentage of editors wouldn't have joined if it weren't for stub tags or other similar tags indicating how they could help; they wouldn't have known you can edit Wikipedia. If it weren't for stub tags Wikipedia would feel more like a book than an open community, and if it didn't have this inviting feel, if the number of editors in Wikipedia reduced, then the quality of articles in general would fall. I decided to oppose instead of to wait for the survey because I think that a survey couldn't show the effects I have in mind, as they would only be felt if a huge percentage of articles were used. While it's true that stubs may remain in articles after their class has increased, this is generally not an issue for the reader, especially since in larger articles stub tags are hard to realise. They only catch your attention if you're actually looking at a stub, when they are some of the few chinks of text in that article. While destubifying may be a hustle for editors, it is a necessity which arises from a necessary part of Wikipedia's structure.

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

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

    In your preferences, there is an appearance option called "Display an assessment of an article's quality in its page header". This is much nicer, as it displays the title of the article in a colour representing its current assessment. (documentation) Hawkeye7 (discuss) 19:42, 15 September 2020 (UTC)

• To avoid confusion, I point out that the proposalisto get rid of stub tags, not to remove articles which are so short as to be stubs. I dont think anyone is proposing that. DGG ( talk ) 22:32, 18 September 2020 (UTC)

Moved from Template talk:Infobox award § Using image for current award rather than text

 – ((u|Sdkb)) ^talk 23:12, 16 September 2020 (UTC)

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

Just as a note, ((Infobox football league)) and a dozen other sports seasons templates use this or similar versions of the "clock" image. I would suggest that the discussion get a little wider, maybe at one of the Village Pumps, to get consensus about the use of these images in general. Primefac (talk) 19:04, 16 September 2020 (UTC)

Primefac, thanks for pointing that out! I'll move this to VPR, since I think similar considerations would apply to all these templates. If anyone wants to list out the templates or propose specific alternative wording for some of the others (e.g. should it be Current season for ((Infobox football league))?), that would be helpful. ((u|Sdkb)) ^talk 23:06, 16 September 2020 (UTC)

Support - Is that what that image means? I had no clue, and I often wondered what the heck it was. Clicking on the image simply takes you to the file itself, still providing no context. Even the infobox is edited, it's not very clear, and the template documentation doesn't really describe that an image is going to be used—it takes some serious connecting of the dots. At least in the ((Current)) template, the verbiage provides an explanation. If the discussion is widened, I'd have to see other cases, but with ((Infobox football league)) at least, I still don't find the image particularly helpful when I look at Premier League, but at least the football league template documentation uses the image, which is a step up from the Awards infobox. -2pou (talk) 19:31, 16 September 2020 (UTC)

Perhaps the word Current could also be in italics? I don't know if the rest agree. I've implemented it and in my opinion it looks better. El Millo (talk) 00:06, 17 September 2020 (UTC)

Support - I do not believe I have ever seen this before, but its meaning to me as a sighted user is fully opaque and therefore worth exactly zero. For unsighted users the usefulness is surely less than that (more confusion/frustration trying to use our site). If people don't like the word Current:, it seems we could drop it altogether: no image, no word; just the link to whatever current thingy would be there. — JohnFromPinckney (talk) 10:21, 17 September 2020 (UTC)

Support The fact that it took me 10 minutes to figure out what these people were trying to propose really just gives it away that it needs change. Arsonxists (talk) 16:25, 17 September 2020 (UTC)

Support any clarification over the old. I read the proposal thrice and looked at old and new and I still couldn't understand what the thing is supposed to be. I imagine the current version also violates accessibility in all sorts of ways. —  HELLKNOWZ   ▎TALK 22:41, 18 September 2020 (UTC)

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

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

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

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

• Support This idea is pretty nice. Not only would it keep the reader from unessecary frustration, but the time wasted memorizing a table could be saved with this. Arsonxists (talk) 01:52, 16 September 2020 (UTC)

I don't know if that placement is the best, but potentially fixable col headers would be a welcome option (esp. if off by default, e.g., for smallish tables). — JohnFromPinckney (talk) 01:53, 16 September 2020 (UTC)

Maybe the point where it's enabled by default is 15 sections down, and 5 columns. A limit like that would organize the tables even better by eliminating the tables that don't need it and having it for the ones that don't. Arsonxists (talk) 02:02, 16 September 2020 (UTC)

• The issue has been discussed a few times before - see Help talk:Table#Sticky table headers? - and has been done for some of the COVID articles. Try the experimental gadget available through your preferences... — GhostInTheMachine ^{talk to me} 08:18, 16 September 2020 (UTC)

• Support - one shouldn't have to use an "experimental gadget" it should be available be default for all of our readers. Aza24 (talk) 22:22, 17 September 2020 (UTC)
• This isn't something we need to support or oppose for. phab:T42763 has been open for 8 years so don't hold your breath waiting for the request to be fulfilled anytime soon. – SD0001 (talk) 03:51, 19 September 2020 (UTC)