Wikipedia:Village pump (proposals)/Archive 194

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Mass creation of pages on fish species

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

---

I was told through a talk page message to come here and submit this as a proposal even though it has been an ongoing process for a few months. I have been creating large numbers of pages on fish species and most of them are very short due to the relative scarcity of information on many of these species. I was informed that what I have been doing is considered "bot-like editing", so I am posting this here since apparently it needs to be discussed. I should note that I started this process back in December and this is the first time I have been notified that it is bot-like in nature, so this is the first time I am posting about it here or in any similar location.

I apologize if I am not carrying out this proposal process correctly as I am rather new here and frankly still a bit confused about this whole thing. This is not really a proposal, but I was told to verify that there is a consensus for creating such pages before continuing to do so. Lumpsucker (talk) 16:30, 30 August 2022 (UTC)

WikiProject Tree of Life and WikiProject Fishes have been informed of this discussion. BilledMammal (talk) 02:55, 31 August 2022 (UTC)

Thank you for bringing this here. To provide some context, I noticed that Lumpsucher had been engaged in the mass creation of articles on fish, and requested that they seek consensus for this, here or at another suitable location, as mass creation requires an affirmative consensus per WP:MASSCREATE and to avoid creating WP:FAIT issues.

Of these articles, the majority are small, near-identical articles (eg, Hypostomus brevis, Hypostomus argus, Hypostomus johnii, Hypostomus agna) that I believe are better suited as entries in a list than as stand alone articles. BilledMammal (talk) 16:41, 30 August 2022 (UTC)

• I said in a recent discussion about dam articles that instead of stand-alone pages, it's better to have lists of dams. Same here. Pages like Hypostomus brevis, Hypostomus argus, Hypostomus johnii, Hypostomus agna would be better off if they were either listings in a table, or sections, of Hypostomus. One of the reasons is context: Hypostomus brevis doesn't tell me that this particular species of catfish is one of 100+ species of Hypostomus. It says brevis is 7.4 inches but I don't know if that's big or small for a Hypostomus species. It tells me that brevis is in the Parana River but it doesn't tell me if all these catfish in the Parana, or just rivers, or just South America, or what. Hypostomus gives me way, way more information -- even about the brevis specis -- than Hypostomus brevis. That's why it's better to combine these one- or two-sentence stubs about list entries into one list. Levivich 16:56, 30 August 2022 (UTC)
  • Adding: for me it's not about WP:GNG--named fish species will likely meet GNG--it's about WP:PAGEDECIDE: even if the topics are notable, the brevity of the article content means "listification" will provide the reader with more information and context than stand-alone pages. Levivich 02:13, 31 August 2022 (UTC)
• Support creation of articles on fish species. There is consensus that they are notable and short articles on species have been accepted for a long time. BeanieFan11 (talk) 17:01, 30 August 2022 (UTC)

  This is why I have been doing it this way and not through lists. These sorts of articles have been the convention for quite some time as far as I know and I have yet to see a genus article where information on the species is presented in the form of a list. Lumpsucker (talk) 17:19, 30 August 2022 (UTC)

• Agree completely with Levivich. I think we're all aware of WP:SPECIESOUTCOMES here, which suggests species-level articles are typically kept. But to the question of what should we do: I think tiny stub articles serve our encyclopedic purpose poorly (per Levivich's points above). A more helpful way to include this information would be to host it at whatever taxonomic level we can support a half-decent well-contextualized encyclopedia article. In some cases that may be the genus; in others an even-higher order taxon. It just depends on how well-covered the organisms are in sources. Some flexibility may be required, as we're aiming to create a high-quality encyclopedia here, not a rigid rule set for where to host each tidbit of information. Ajpolino (talk) 17:12, 30 August 2022 (UTC)
• Oppose mass creation of stub articles, on fish species or otherwise. Agree with Levivich and Ajpolino (especially the "quality over quantity" point) and would add that the guiding principle should be this: database entries alone are insufficient to support an encyclopedic article, whether that database is of actors, fish species, geographic features or some other group. Remember that the notability guideline requires 'significant coverage," and databases do not provide this. I suggest that at a minimum the creator add as a reference the scientific paper in which the species was described (and maybe even some of the information from said paper). UnitedStatesian (talk) 17:29, 30 August 2022 (UTC)

  Unfortunately, a lot of these species description articles are paywalled. Quetzal1964 (talk) 12:21, 15 October 2022 (UTC)

• Support article creation We have precedent for creating species articles and guidelines confirming the appropriateness of this. That said, we could revisit the subject with a broader discussion. If anyone wants to start that discussion, they are going to have to do some background work. Things that I would expect to see are 1) list of previous discussions on this topic and 2) some summary of the previous discussions. I estimate this to be 1-2 hours of preparation for a good new discussion. Even with a new discussion though, I personally would not expect the community to reverse the precedent, because new technology is making information, data, and media more accessible at scale. I acknowledge that stub articles are problematic if they were to persist indefinitely without development, but my feeling is that we can reasonably expect good development of these articles soon. It has been some years since the project was active, but previously I contributed to the commons:User:Open Access Media Importer Bot which, among other things, pulled photos of species from open access scientific journals for upload to Wikimedia Commons. Some of those images are at commons:Commons:Open Access File of the Day. Technology for doing such activity has gotten much less expensive in the 10 years since that import project was running, so I expect something similar to happen eventually. Because of this, I do not see stubby Wikipedia articles as a problem, because I see them getting more content within years, and translated into other Wikipedia language versions not long after that. Bluerasberry (talk) 17:34, 30 August 2022 (UTC)
• Oppose The community has become wary of mass stub creation ( as these seem to be) even if in the past such stubs were acceptable. a far better solution would be to expand the...famiky? pages (the level just above species. then you can have searchable redirects to these. when a non stub species article can be created, just add the link then. User:Masem 18:25, 30 August 2022 (UTC)

  Genus, King Philip Could Only Find Girl Scouts Andre🚐 20:09, 30 August 2022 (UTC)

• Oppose. I have been guilty of this exact thing in the past (cfe. Synapturanus ajuricaba) but I believe that we should stop the mass creation of stubs in the future. If a genus has no associated species articles, then try covering all the species in sections on the genus article and split out the most substantial sections into their own article. casualdejekyll 18:38, 30 August 2022 (UTC)
• I see nothing wrong with this user's creations. I wouldn't even call it "mass creation"; the user is averaging two articles per day (since the first day the user created an article) on subjects that are all notable (and articles like these have had consensus for a long time). BeanieFan11 (talk) 18:41, 30 August 2022 (UTC)

  The problem isn't as much the quantity of the articles as the quality of the articles. They're stubs. Sourced stubs, sure, but if they weren't on such an obviously notable subject they don't have the sourcing to show the notability. casualdejekyll 18:50, 30 August 2022 (UTC)

  An article being a stub is not a problem. BeanieFan11 (talk) 18:52, 30 August 2022 (UTC)

  An article being a stub that does not pass GNG is. As UnitedStatesian said, database entries alone are insufficient to support an encyclopedic article. casualdejekyll 18:53, 30 August 2022 (UTC)

  Not all subjects have to pass GNG. NPOL, NPROF (I believe), and NSPECIES only require that subjects (that meet the criteria) need to be verifiable, which is the case with the articles this user is creating. BeanieFan11 (talk) 18:59, 30 August 2022 (UTC)

  only NPROF does not require any long term requirement to show GNG type presumed notability. NSPECIES is a general outcome and NOT an SNG Masem (t) 19:15, 30 August 2022 (UTC)

  That's kind of the issue at hand here I think. If they don't pass GNG they should be merged into a list. Andre🚐 20:01, 30 August 2022 (UTC)

  they pass GNG every species is written about in multiple sources independent of the subject. Gnangarra 10:46, 31 August 2022 (UTC)

• Question: how does this fit into Wikispecies? Looking at a typical example Hypostomus multidens vs Hypostomus multidens. Wikispecies has about 800,000 pages which is more than 10% of Enwiki, in case the idea is to allow every page Wikispecies have a twin at Enwiki per WP:SPECIESOUTCOMES. -- GreenC 18:54, 30 August 2022 (UTC)

  Great point. Maybe they should go there. Andre🚐 19:59, 30 August 2022 (UTC)

  Wikispecies is, from what I've heard on WP:DISCORD, widely considered to be a ghost town and redundant to Wikidata. To use an analogy to another group of related things where there are clear winners and losers, Wikispecies is the Michigan's Adventure to Wikipedia's Cedar Point. casualdejekyll 23:05, 30 August 2022 (UTC)

  That's a shame, it had a really cool logo Andre🚐 23:06, 30 August 2022 (UTC)

• Oppose If there is only a line or two to say, they are better as a section or in a list at the genus level. Johnbod (talk) 18:56, 30 August 2022 (UTC)
• I agree that WP should cover these species… BUT… that does not mean we should have separate stand alone articles for each of them. If all we can say is one or two lines (effectively noting that they exist and not much else) then we should cover them in section or list within a larger, genus level, “parent” article. Blueboar (talk) 19:06, 30 August 2022 (UTC)

  Good idea. Andre🚐 20:00, 30 August 2022 (UTC)

• I don't think an RFC has been started, but I am of the opinion that we do not need sub-stubs for subjects for which GNG has not been met. I think it is best to incorporate what information can be reliably sourced about those subjects into higher-level articles. - Donald Albury 19:52, 30 August 2022 (UTC)

  I concur with Donald Albury. I don't know a lot about ichthyology, but when it comes to plants, there are a ton of variations. So we don't need every article on a ficus. I count about 10 red links on the ficus page. Maybe all the ficuses (fici?) will eventually be written about, but possibly not, and that's totally OK. We should only write about species that have significant coverage in the published reliable work. Andre🚐 19:59, 30 August 2022 (UTC)

• Oppose, as said by multiple people already, these are better covered in a single article. Agree with Blueboar, the "topic" is still covered in the encyclopedia, just not with a separate article. The same goes for many other things in addition to minor species. MB 20:03, 30 August 2022 (UTC)
• WP:PAGEDECIDE leans against creating stubs when a broader article would serve readers better. Slywriter (talk) 20:36, 30 August 2022 (UTC)
• Comment: I think User:Casualdejekyll outlines exactly the right approach. Start by creating larger articles with sections, then divide out the sections as sufficient content develops. BD2412 T 21:35, 30 August 2022 (UTC)
• Support this creation of stub articles for species. This user is not using an automated bot, nor a creation rate to be considered as "mass creation". Using biological databases as references is valuable as an indicator of peer-reviewed secondary sources of the species notability - not like a sports almanac of trivial facts. Now, do I think a stub should be created for every species? Probably not, it would be impossible for a start. Many genus level articles could more readily summarize all the information for their species than a series of stubs. But for a topic such as fish, with many active editors, it is not inconceivable that someone else may come along and add an image or other information that will grow the article, although maybe not for 5-10 years. In the long-term approach (that is measured in decades, not months), species stubs are an asset and not something to be dissuaded from creating.
  

The present creation of species stubs is well within established consensus and I would expect any serious proposal to attempt to reverse this be presented with both the proper background preparation (as detailed by Blueraspberry above) and a wide prior notification within the WP:TOL (Tree of Life) projects. Loopy30 (talk) 22:50, 30 August 2022 (UTC)

Mass creation doesn't need to be at bot speed to be a problem. Masem (t) 23:11, 30 August 2022 (UTC)

We would expect pre discussion of mass creation to be at a community wide location like WP:VPP. Wikiprojects are in general too insular for mass creation (though are a good first check). Masem (t) 23:25, 30 August 2022 (UTC)

The present creation of species stubs is well within established consensus - could you link that consensus for me? As far as I am aware, no such consensus exists. BilledMammal (talk) 23:29, 30 August 2022 (UTC)

Listed in WP:OUTCOMES for a good decade now (see shortcut WP:NSPECIES); and I went through the entirety of the past 6.5 years of AfDs listed at Organisms deletion sorting archive and cannot find so much as a single AfD that involved an actual, valid, non-fictional species being closed as delete (individual plants/animals, plant cultivars, cannabis strains, breeds of domesticated animals, "dubious" and invalid taxa, fictional species/cryptozoology stuff, etc.? Sure. Actual valid species? Nope. Not as much as one of them in the past 6.5 years) or even no consensus.

Of course it's possible that if a discussion happens, it turns out to show that consensus has, in fact, changed--but as things stand, there absolutely is plenty of evidence of consensus for the keeping-by-default of valid species articles. From that, it logically follows there is consensus for creation of valid species articles, too. AddWittyNameHere 01:31, 31 August 2022 (UTC)

using OUTCOMES to support mass creation is absolutely the wrong approach (its circular reasoning) Masem (t) 01:40, 31 August 2022 (UTC)

No, circular reasoning would be if I stated "this sums up that such articles are generally kept; therefore we shouldn't delete this specific example of it". What I'm saying is "this sums up that such articles are generally kept (and evidence shows that summary to remain correct even when it comes to the current state of things); from this follows that there is at utter minimum an implied consensus for the existence, and therefore creation, of such articles."

I don't disagree it could be a good idea to confirm whether that implied consensus is, indeed, still the wider en.wiki consensus. But it's not circular reasoning to recognize that, up until this discussion where the implied consensus was challenged, such consensus was effectively in place. AddWittyNameHere 01:54, 31 August 2022 (UTC)

I believe it is very unlikely that a proposal to create a guideline granting presumed notability (and an exemption from WP:NOTDATABASE) to species would find a consensus; given this probable inability to get a formal consensus, I cannot see an implied consensus.

I would also note that we're not discussing individual article creations; we are discussing mass creations. Actions taken at scale can be problematic and against consensus even when smaller number of actions would not be - for example, creating stubs on five WP:GEOLAND-compliant locations is not an issue, but creating stubs on 5000 is. BilledMammal (talk) 02:11, 31 August 2022 (UTC)

we are discussing mass creations - Are we, though? I'd argue that 2-3 per day (as seems to be pretty much the average in this case) fits perfectly into Alternatives to simply creating mass quantities of content pages include creating the pages in small batches right from WP:MASSCREATION. AddWittyNameHere 02:22, 31 August 2022 (UTC)

Yes; the relevant line is While no specific definition of "large-scale" was decided, a suggestion of "anything more than 25 or 50" was not opposed. - Lumpsucker has created hundreds of near-identical articles on fish. BilledMammal (talk) 02:32, 31 August 2022 (UTC)

The problem with that line is that it is so imprecise as to be entirely useless: it gives absolutely no strictures other than a vague indicator of number. It doesn't say they have to be stubs. It doesn't say they have to be on similar subjects. It doesn't specify in what time-span.

If we want to apply that line as-is, practically every content creator who has been around a while is a mass-creator by default, regardless of the quality, subject or frequency of their articles. We have over 10000 editors with at least 68 non-redirect mainspace page creations to their name. I highly doubt the intention was that they'd all be deemed mass creators who'd need prior approval before creating more articles. AddWittyNameHere 01:50, 1 September 2022 (UTC)

For what it's worth, the just-opened RfC on mass-creation currently says "Rapid and/or mass creation/deletion" refers to more than 25 per day, with a note the definition may need workshopping during the RfC. By that definition, Lumpsucker very much is not engaging in mass-creation. AddWittyNameHere 01:56, 1 September 2022 (UTC)

WP:OUTCOMES is not one of Wikipedia's policies or guidelines, as it has not been thoroughly vetted by the community. It's not an WP:SNG (which are guidelines). Levivich 02:03, 31 August 2022 (UTC)

• Support the "mass" creation of species stubs with the proviso that at least one non-database RS is used as a reference. As an example, I found a source for Hypostomus agna and added some tidbits of info, such that now the species article contains information beyond what is given in the genus article. The substub->stub conversion took less than 5 minutes. I've written hundreds of stubs on lichen species and intend to continue doing so until there's one for each of the 20,000 or so lichens. Esculenta (talk) 01:12, 31 August 2022 (UTC)
• Question Can anybody point me to some previous examples where editors have requested consensus/permission to mass create articles in a semi-automated way? I realize that is what WP:MASSCREATE calls for, but it's not something I'm aware of being followed in practice.Plantdrew (talk) 01:24, 31 August 2022 (UTC)

@Plantdrew: The essay Wikipedia:Bot-created articles has links to relevant history here. Particularly for plants and animals, you'll typically find that Lsjbot has mass created stubs in other languages already for many species. In practice, I think the answer is that automated creation of articles is more or less not done on English Wikipedia anymore? Steven Walling • talk 01:49, 31 August 2022 (UTC)

@Plantdrew: Wikipedia:Bots/Noticeboard#Dams articles Levivich 01:58, 31 August 2022 (UTC)

That was the one and only time that was done (at least that I can recall). BeanieFan11 (talk) 02:04, 31 August 2022 (UTC)

I found some examples in the BRFA archives (1, 2, 3, 4, 5, 6). –xeno^talk 02:12, 31 August 2022 (UTC)

Every one of those editors, like Lumpsucker, deserve our thanks for seeking community input on this. Levivich 02:44, 31 August 2022 (UTC)

Xeno, thank you for digging up those examples. Those are all seeking permission for fully automated article creation. I assume Xeno would have discovered any requests for approval for semi-automated article creation, and by absence of examples, no such requests exist (aside from the recent case for Japanese dams). Plantdrew (talk) 15:32, 31 August 2022 (UTC)

Because WP:MASSCREATE says Any large-scale automated or semi-automated content page creation task must be approved at Wikipedia:Bots/Requests for approval, I don't think the automated/semi-automated distinction is relevant. Levivich 17:58, 1 September 2022 (UTC)

• Support Animals and plants that have references to a species description are notable because there is plenty of highly reliable source material about them, even if the initial stubs are usually small. To get an accepted species description, a scientist typically has to go through peer review and have the description presented in an academic journal. An accepted species description is arguably even more reliable than say, census data used to populate stubs about tiny towns or census-designated places, and it's really easy to create one or two of these stubs manually every day once you know where to find the free online science databases and/or get a few books handy. In addition to the original species description, most of these are also covered in other reliable sources like monographs about a particular genus. Most of these scientific papers, even for rare and endangered species, are easily findable via Google Scholar or JSTOR if you search for the scientific names. TL;DR: Since there are almost always multiple highly reliable sources exclusively covering the subject these species pass the basic test of notability. Steven Walling • talk 02:08, 31 August 2022 (UTC)

  I think this argument is persuasive to a point. However, some old genus and species names have been around for a while and usually there isn't much information about them. Right? I mean could you break down a couple of really obscure fish for us? Or how about those red-linked ficus? Andre🚐 02:16, 31 August 2022 (UTC)

Ficus is one of the largest genera of plants on the planet, and there are quite a large number of scientific papers and whole books written just about various species within it. We could most definitely create reliably sourced articles about almost all of them. Just like with all subjects though, if we can't find enough source material... then don't. Each article has to be considered on its own merits, but to propose that we categorically can't have stubs about individual plant and animal species is just plain wrong when you look at WP:N and more than a decade of discussion at AFD. Steven Walling • talk 03:20, 31 August 2022 (UTC)

I didn't say we can't have stubs, but many of these are substubs. An article needs to say why it's important and why we should care, IMHO. Andre🚐 03:34, 31 August 2022 (UTC)

Why? I'm not convinced an article needs to say why it's important. Ortizesp (talk) 16:09, 5 October 2022 (UTC)

It does. Andre🚐 16:19, 5 October 2022 (UTC)

@Andrevan, that only applies to people, individual animals (like racehorses), organizations that aren't schools, web content (e.g., specific websites such as YouTube), organized events (such as the Olympics), and musical recordings (such as The Beatles (album)). To quote the policy, "it does not apply to articles about...products, books, films, TV programs, software, or other creative works, nor to entire species of animals" (emphasis in the original). I'd add that it doesn't apply to geographical locations, either. WhatamIdoing (talk) 23:00, 5 October 2022 (UTC)

Yes, that's true, and thank you for clarifying and pointing out that there is a specific carve-out for species and for the other examples mentioned, but not because those articles are exempt from the requirement of a credible claim of significance. It's because it's assumed that their notability requirements will cover that requirement. Because as we've discussed, to even be an independent species requires you to demonstrate significance by virtue of what a species is. Andre🚐 23:08, 5 October 2022 (UTC)

The page you linked says "This is an explanatory essay about the several sections of Wikipedia:Criteria for speedy deletion." You seem to think it apples to every subject, and not just the ones that are relevant to "the several sections of Wikipedia:Criteria for speedy deletion".

What makes you think that every page is required to have a claim of significance? You won't find a requirement for that in any policy. Subjects are notable (or not) no matter what state the article is in, including if there are zero sources and no claim of any significance whatsoever. As a pure matter of practicality, if you can explain why a subject matters and toss a few impressive-looking citations onto the page, then that will stop an editor who doesn't know anything about the subject from trying to delete the article, but the subject's notable (or not) no matter what's on the page. WhatamIdoing (talk) 23:38, 5 October 2022 (UTC)

Yes, the page I linked is an essay explaining it, and not a policy. However an article which falls under a speedy deletion criterion of not having such claim of significance, for the categories to which such policy applies, will be deleted. And indeed the spirit of notability of being "worthy of note" is essentially synonymous in my view with a "significance," and it's kind of at the core of notability. Per WP:SUSTAINED, a topic is "notable" in Wikipedia terms only if the outside world has already "taken notice of it". for a significant period of time. The test of notability is not notability itself: notability is whether the world has taken note due to something worth noting. Why did you note it? That's what significance is. The intrinsic characteristic we're trying to test with tests of notability. Andre🚐 23:55, 5 October 2022 (UTC)

There is nothing in WP:N or any other guideline or policy that says an article about (e.g.) a book needs to say anything about its significance. Notability is independent of article contents.

• Notable book + article makes a credible claim of significance = notable
• Notable book + article makes no claim of significance = still notable

The presence or absence of a claim of significance in the article is not a requirement except for the specific subjects named in CSD. WhatamIdoing (talk) 19:17, 6 October 2022 (UTC)

Well, while that requirement doesn't exist explicitly, we do have a requirement of WP:SIGCOV, ie not a passing mention. Sources will end up having to explain the subject in some amount of depth. The rules are principles and the principle of notability, in my mind, is tied to the subject's significance, not only by the CSD policy. Notability is a property of the subject, not the article - but the subject still needs to have significance demonstrated by virtue of significant coverage in the material. Andre🚐 19:59, 6 October 2022 (UTC)

I think you might be missing my main complaint. You wrote: An article needs to say why it's important. Notice which word I bolded.

Now you are here telling me that the sources need to talk about the subject in some amount of depth. Sure, that's fine, but the sources (which need to amount to significant coverage) are not the article (which is what your original statement was about). The article does not need to say why the subject is important. WhatamIdoing (talk) 04:10, 7 October 2022 (UTC)

The sources need to say it and that should make it into the article as well, IMHO. That wouldn't necessarily be a valid CSD criterion but it is still nonetheless something the article should do: tell the reader why they should care about the thing. Andre🚐 14:31, 7 October 2022 (UTC)

• I just did a search on JSTOR and Google Scholar for the first fish I mentioned, Hypostomus brevis. There were some passing mentions, but no WP:SIGCOV. In addition, WP:N isn't the only reason these articles are problematic; WP:NOTDATABASE also applies.

  We also need to consider the interests of the reader. Even for the ones that are notable, readers are better served by the inclusion of content at Hypostomus than they are by a standalone micro-stub. BilledMammal (talk) 02:23, 31 August 2022 (UTC)

A Google Books search shows several mentions of that species in books (significant coverage doesn't have to be in sources you can read for free online after a cursory search) and there are probably even more sources out there that you and I can't find because we're not familiar with the journals that cover Hypostomus or other fish. Just because an article is small right now does not mean it's not notable. That's a logical fallacy and if we followed that argument we wouldn't have Wikipedia as it exists today. As for improving the genus article... we can have our cake and eat it too. There's nothing stopping expansion of the genus article and having a stub. There are thousands of examples of this in the encyclopedia right now. Since most of our traffic comes from Google, you'd have to redirect and merge millions of species stubs to the genus articles for your theory to work. Steven Walling • talk 03:12, 31 August 2022 (UTC)

In addition, for older species which were previously in other genera, many of the older resources will resultingly have used the at-the-time valid binomial, not the current one. Searching for just the current one is typically a good way to miss the bulk of older sources. (Though in this case, the majority of older sources are likely not going to be available online, anyway: digitization for old non-English sources lags a fair bit behind that of old English sources, and this particular fish species occurs solely outside the Anglosphere) AddWittyNameHere 03:30, 31 August 2022 (UTC)

• I also did a search on Google Scholar for Hypostomus brevis. Looks like GNG is met pretty easily. There are additional sources available (Monographs about fish in Brazil, in Portuguese). Esculenta (talk) 05:40, 31 August 2022 (UTC)

  Two of those sources are clearly trivial coverage; the third, the Portuguese language source, might count towards GNG, but doesn't meet it on its own.

  However, that is getting off topic; the issue is that sources like these aren't being included when these articles are created. Instead, they are being mass created by duplicating database entries; we should instead be encouraging the editor to add this information to the genus article where it will be of more benefit to the reader than in a micro-stub - of course, if editors are able to find sources that permit them to create an actual article on the subject that would be of more benefit to readers than the genus article, then they are encouraged to do so. BilledMammal (talk) 05:56, 31 August 2022 (UTC)

• Comment. What are we actually voting on here? The mass creation of articles on fish by Lumpsucker? If so, what is the scope; how many articles will be created, what genus of fish will be covered, etc? I suggest everyone hold off from voting until there is a formal proposal to vote on. BilledMammal (talk) 02:23, 31 August 2022 (UTC)

  We're not voting. This is a discussion. Andre🚐 02:28, 31 August 2022 (UTC)

  Sorry, meant !voting, in reference to the various bolded "support" and "oppose" !votes. BilledMammal (talk) 02:42, 31 August 2022 (UTC)

  On pages like this which have proposals on them, people start doing that sometimes. That's why in the old days people used to say voting is evil. And the reason why we put the ! (which means a logical not) in front a vote is to remind everyone that WP:NOTDEMOCRACY. In theory, though I guess it's increasingly less common in practice, the best arguments should prevail in a rough consensus (not a tally). All of that to say, nobody formally proposed anything and nothing's being voted on, that's the answer to your question. Andre🚐 02:45, 31 August 2022 (UTC)

  I should probably clear something up. There is no vote being called here. This discussion here would not exist were it not for the fact that BilledMammal specifically recommended I start it here, as this topic is inherently not a formal proposal. Lumpsucker (talk) 02:59, 31 August 2022 (UTC)

  It might be a good idea if you made a formal proposal and we can open an RfC on the basis of it. In particular, what is the scope of your proposed mass creation; can you give us a rough idea of what articles you will be creating? (ie, about 100 articles on species within the genus x, about 50 articles on species within the genus y, etc) BilledMammal (talk) 03:03, 31 August 2022 (UTC)

  A proposal and a formal RFC is not necessary or helpful, and you shouldn't push the discussion into that, as it's clear from this discussion that there is not a consensus for Lumpsucker to continue without some further limitations on the activities. Andre🚐 03:09, 31 August 2022 (UTC)

• I Support the creation of animals and plants that are able to be referenced to a species description. Less work for someone else to expand in the future. If a creator has a high error rate of content that is a separate issue regardless of number of articles created. Limiting stub creation makes it very complicated - what is the cap. How big does an article need to be before editor is allowed to make another etc. Massive headache and bureaucratic creep. Cas Liber (talk · contribs) 02:52, 31 August 2022 (UTC)
• Here's my suggestion: just stop creating new articles unless you can add 1-2 sentences explaining why they are notable and significant. Andre🚐 03:22, 31 August 2022 (UTC)

creating articles of 1 or 2 sentences plus an infobox is exactly what is being argued against by BilledMammal, and running around wikipedia disrupting good editors. Gnangarra 04:06, 31 August 2022 (UTC)

But I looked at the articles. Some, indeed, are ok. Hypostomus commersoni looks OK, it even has a pic, and it appears in the aquarium trade. It's not the most lengthy or interesting article but it seems to barely qualify. Hypostomus carvalhoi, Hypostomus chrysostiktos, Hypostomus crassicauda, Hypostomus simios Hypostomus corantijni, Hypostomus brevicauda. These don't assert notability or explain significance. It just says they're a fish, in a certain river basin, they grow to this size, and breathe air. The end. The links are to databases only. I don't see why those articles couldn't all be in the Hypostomus article. Andre🚐 04:15, 31 August 2022 (UTC)

Stating its a species of fish, plant, insect, animal. fungi or is establishing notability and data bases are are the where you get the official taxonomy from along with common names, or synonyms and previous naming. Gnangarra 06:02, 31 August 2022 (UTC)

That is not how notability works on WP. There is no special presumption of notability just because you can define its species. we need significant coverage, which 1or 2 sentences do not do. Masem (t) 07:23, 31 August 2022 (UTC)

That is the very definition of notable for species, and has been for 20 years. If you want to overturn notability of species then this isnt the place Gnangarra 09:00, 31 August 2022 (UTC)

"This" meaning this specific thread, probably not. But if the Village Pump isn't the right place, then I don't know what is. casualdejekyll 16:29, 31 August 2022 (UTC)

• the practice of creating stubs about any Notable topic has been standard since the very first edit occurred on Wikipedia 20 years ago. On any given day I photograph 10 species within 100 miles of here that dont have an article every single one of the are notable. Its dam sight easier to add a photo, and additional information when the article has already been started. As someone who has spent many years doing outreach at various Universities having these articles already created also makes it easier to teach others how to edit Wikipedia as they cant create articles in the first few days of creating an account, standard practice has always been to create stubs in areas where the students will be writing. You'll also note that these articles are one WMF KPI's for events if you look over at Outreach dashboards. Gnangarra 04:06, 31 August 2022 (UTC)
• I think the idea that instead of stubs, species should be listed in list articles makes perfect sense. That species are notable by default does not automatically imply that a standalone stub is the best way to present information on the species. If a given species' section expands too much, then we can split off a dedicated article for it. Jo-Jo Eumerus (talk) 10:09, 31 August 2022 (UTC)
• Support the continued creation of stub articles for the reasons given above by Loopy and others. I don't see how the 2-3 articles a day by Lumpsucker counts as automated or semi-automated, as each will be separately evualated when created. If the creation was automated using a bot I would want guidelines and limits, but this isn't the case. Stubs are useful as they make it easy for people to extend the articles, when article creation with appropriate taxoboxes, taxonbars and categories is more of a barrier. —  Jts1882 | talk  12:03, 31 August 2022 (UTC)

  If the creation was automated using a bot I would want guidelines and limits Idk whether it could actually be automated (it sounds as if it might be possible to some extent) but assuming it could be, what guidelines and limits would you suggest? Selfstudier (talk) 12:42, 31 August 2022 (UTC)

• Comment. From the guidelines at the page header above: "This page is for concrete, actionable proposals." - I would posit that the discussion has now strayed greatly from that requirement and has instead become merely discourse for any prejudices different editors wish to air (dislike of stubs, mis-characterization of non-automated user edits as "bot-like", perceived excessive article creation rates of 2/day, validity of species notability guidelines, or their preferred layout of genus/species/list articles). If there is actually any problem that can be identified here (ie. disruptive editing, creation of non-notable articles, incorrect facts included in the article text, etc) then that can be addressed as a separate issue. It is clear that WP:MASSCREATE does not apply in this situation, in fact the low-rate production of human-reviewed articles is specifically mentioned as a legitimate alternative to semi-automated or automated edits.

The ongoing non-automated creation of new species articles by various editors has been the status quo here for twenty years and there is no need to pressure another editor for them to now ask permission to be able to create such articles. If you feel that this type of activity is detrimental to the encyclopedia, then the onus would be on you to gather the necessary information yourself (again, as recommended by Blueraspberry above) and propose a "concrete, actionable proposal" to overturn the status quo. Loopy30 (talk) 14:13, 31 August 2022 (UTC)

The “Status quo” is that most articles on species are kept… but that does not mean that ALL articles on species should be kept. Most species will have enough sourcing to justify an article… but there will be exceptions. Those exceptions can be covered in larger articles. Blueboar (talk) 14:27, 31 August 2022 (UTC)

It has not be proven that anywhere near the majority of recently created species articles are themselves lacking sources or not notable. At best its come to perhaps 1 or 2 individual articles which could be new species, synonyms of depreciated binomials, or poorly documented though even then these articles havent been proven as not meeting GNG. The sole complaint is that the volume of creating 2 or 3 articles on species a day is too much. Some editors are very good at replicating what is a whole of project agreed MOS for such articles and implementing that consistency. What we then have is the bonus that all species articles start with universally consistent format for other contributors to follow and integrates these with Wikimedia Commons, Wikidata, and Wikispecies while facilitating Outreach activities to bring new editors to Wikipedia. Gnangarra 14:51, 31 August 2022 (UTC)

• Support Fish species articles have an astronomically low potential for abuse; they aren't likely to be spammy or sources of promotion, they aren't likely to contain controversial information, they aren't likely to misrepresent things, they aren't likely to cause WP:BLP issues, etc. etc. Given the low potential of abuse and the fact that they will only be created based on published, reliable sources, I say go for it. --Jayron32 15:03, 31 August 2022 (UTC)

  That is a good point. There isn't a lot of fish POV pushing that I know of. Though IMHO, I prefer my fish & chips to be haddock over cod or sole. Andre🚐 15:31, 31 August 2022 (UTC)

  it is not that these are going to be spam targets or the like. WP has a problem with creation of underrepresented topics like women's studies and other minrities, which still tend to struggle due to poor non primary sourcing. we continue to thumb our noses when we allow stubby articles on things like fish species and sports players but these attempts to expand in underrepresented areas are expected to have more fully fleshed out articles. its why the community has soured of mass article creation that leaves stubby article behind even if these could be notable topics. it's lazy work. Masem (t) 19:59, 31 August 2022 (UTC)

  The problem I've noticed is that we keep these pages around of an expectation that "eventually someone will improve them" but it never really happens except in rare cases. See also Wikipedia:Don't_hope_the_house_will_build_itself, Wikipedia:An unfinished house is a real problem. casualdejekyll 20:10, 31 August 2022 (UTC)

  exactly. if it takes a bit more work to write a full two paragragh stub that includes demonstration of meeting the GNG, that would be different, but these here are all two sentence stubs with no clear notability, nor any expectation they will be improved to meet that. Masem (t) 20:17, 31 August 2022 (UTC)

• Support creation of stubs for species. Of course it would be better if more substantial articles were being created. But it is absurd to suggest that an editor can create no more than 25-50 stubs in the course of their Wikipedia career (or needs to seek permission to do so). Plantdrew (talk) 16:54, 31 August 2022 (UTC)
• oppose creation of taxonomy-only stubs. If at least some description were put in for each one I would be supportive. Mangoe (talk) 19:50, 31 August 2022 (UTC)

  None of these are taxonomy-only. Lumpsucker (talk) 20:21, 31 August 2022 (UTC)

• Oppose. I while ago I did a lot of work Assessing hundreds (or thousands?) of fish articles. To do this I looked at their pageviews, and there are huge numbers of fish articles that receive about one pageview per month, and there were some that had one pageview in five years. These stubs are not helpful, and arguably non-encyclopedic. Abductive (reasoning) 20:57, 31 August 2022 (UTC)
• Support editor's preference to create articles. Species have long had implied notability, and there can be no WP:N objection to these stubs. The project is entirely manual and at the stated rate of creation displays neither bot nor bot-like activity; the fact that some articles are very similar speaks more to the similarity of the species involved than evidence of bot-like editing. Beyond that, nobody has invoked any policy or guideline prohibiting the work, which means it should be left to the editor's own discretion. Every editor is free to edit in whatever way they think fit, provided they do so in accordance with policy and guidelines. We shouldn't be attempting to create new rules on the hoof in this thread to force an obviously committed editor to comply with some other editors' "lists are best" preferences. Suggest, by all means; compel, no. MichaelMaggs (talk) 22:17, 31 August 2022 (UTC)
• This discussion is a waste of time. First off, creating 500 short articles in the space of 9 months isn't "mass creation" in any meaningful sense of the term. Leaving the creator what looks like a templated warning about bot [?!] editing and urging them to get permission at the village pump [??] was poor form. Still, when undertaking a big project that's going to affect a large number of articles (even if the project is slow-going), it's a good idea to first post about it in a relevant place, like  WT:FISH. This is not so much asking for permission as soliciting suggestions (this can, for example, help identify the best taxonomy sources: you wouldn't want to spend months working on something only to later find out your work was based on outdated information).
  So, what are we trying to do here? Some sort of rehearsal for Wikipedia:Arbitration Committee/Requests for comment/Article creation at scale, or just an exercise in venting our frustrations at the low-quality mass stub creations of those high-profile recently banned editors in other topic areas? Rethinking how we present information about obscure species will certainly be worth it, and I second some of Levivich's ideas above; however, treating the species only in a list at the genus articles is not the done thing, and we can't expect people to suddenly have to start asking our opinion before doing things the same way they have been done in the past 20 years. Any talk of species articles needing to "demonstrate notability" is nonsense (as clear from reading Steven Walling's comment).
  Personally, I don't think it's a good idea to create stubs that very few people will ever read (obscure species are among the least read articles in the encyclopedia), and I wouldn't be spending my time on that, but it's up to individual editors to decide how they're going to spend their time, and they shouldn't be pushed into asking for approval for medium-scale manual creations. Uanfala (talk) 22:30, 31 August 2022 (UTC)

  After watching this discussion unfold I have to agree with you. I was under the impression that there was a logical precedent for sending editors here and describing their edits as "bot-like", but it seems as though that may not be as true as I thought it was. After reading this message I will probably continue editing in the way that I have been editing. If any editor here believes that there is a logical reason to modify an individual page of mine, they are free to do so. I encourage expanding and editing small articles of all sorts. Lumpsucker (talk) 23:44, 31 August 2022 (UTC)

  Probably best to wait for Wikipedia:Arbitration Committee/Requests for comment/Article creation at scale. Levivich 23:48, 31 August 2022 (UTC)

  I don't exactly know how all of this works, so I might take a month or so off from editing to see what happens there. Lumpsucker (talk) 00:03, 1 September 2022 (UTC)

  @Lumpsucker: Please don't be discouraged from creating articles. Anyone can start a discussion on the Village Pump, it doesn't mean you are required to do anything, unless there's been a consensus declared. One of Wikipedia's core principles is to be bold, so the last thing in the world is that you should think you have to wait for someone's permission to edit. Especially since there is no agreement via an articles for deletion discussion that any of these articles are not notable and should be removed, you're doing helpful work. My only suggestion would be to try find a second source up front for each stub, not just a taxonomy database. If you aren't comfortable proceeding alone, WikiProject Fishes or other editors like myself who are supportive of writing species articles would be happy to help review and expand stubs. Steven Walling • talk 19:52, 1 September 2022 (UTC)

  Steven is correct, you may continue creating articles, but you might find that if you create an article sourced only to fishbase and another generic database site, it will end up at AFD. Andre🚐 20:09, 1 September 2022 (UTC)

  And to just to be clear Lumpsucker, if you're not familiar with AFD, that's also just like this discussion. Any random editor can propose any article for deletion at any time, and then we discuss it as a community. It would be extremely unusual for a legitimate named species to actually be deleted. What will more likely happen is that someone will just help expand the sources and then it will be kept. So don't let Andre's threatening talk stop you. Steven Walling • talk 21:04, 1 September 2022 (UTC)

  Hmm, it's not a threat, nor is it an idle statement, just a description of what might happen, I didn't say I would be the one doing it. Andre🚐 21:07, 1 September 2022 (UTC)

  Before creating any other articles, I am planning on expanding a few of my smallest articles as I already have been doing. Some of those were only created with a single source and are less than 1 KB in length, and I am looking to improve most of the articles of that size that I made. Lumpsucker (talk) 00:12, 2 September 2022 (UTC)

  I think this comment is important because it shows you are listening to the feedback and adjusting, so I would say there's no problem with your continued doing that. Andre🚐 05:36, 2 September 2022 (UTC)

  +1 to @Uanfala. WhatamIdoing (talk) 23:45, 31 August 2022 (UTC)

Also, I wonder how many people have actually looked at the articles in question? I looked at this one, which I transclude here so that you won't even have to go to the trouble of clicking through to an article:

---

Hypostomus robinii

---

(I'd tell you that I picked the name randomly, but it'd be more accurate to say that I picked it arbitrarily, on the basis of its bird-like name.)

I see above people like Levivich talking about "one- or two-sentence stubs" and Blueboar saying "If all we can say is one or two lines", but this is four sentences plus an infobox. That's not what I'm seeing in these articles.

Hypostomus chrysostiktos has four sentences, an infobox, and three sources (one of which is a scholarly paper). Hypostomus ericae has four sentences, an infobox, and two sources. These are typical. Then there are the not-so-typical ones, like Pseudacanthicus pirarara, which has 500 words, four sources, and an ==In popular culture== section. Pseudancistrus megacephalus has 250 words and 11 sources. Chaetostoma platyrhynchus has 250 words and 7 sources. Pseudoqolus, with six sentences and four sources, is about a genus.

So I wonder: If you actually look at the articles, why would anyone want to discourage this editor? WhatamIdoing (talk) 23:46, 31 August 2022 (UTC)

I removed the transcription, as I found it very confusing reading through the page only to encounter an article; I hope you don't mind.

However, to be clear we don't want to discourage articles like Pseudacanthicus pirarara and Chaetostoma platyrhynchus; they aren't mass created, they aren't WP:NOTDATABASE violations, they demonstrate notability, and they are more useful to the reader than the higher level article would be.

What we do want to discourage is articles like the ones I referenced above, and the ones like Hypostomus ericae, which are mass created on the basis of a template, and where the information would be more useful for the reader in a higher level article. BilledMammal (talk) 23:54, 31 August 2022 (UTC)

Hypostomus ericae has five sentences, three sources, and an infobox. One of the sources is a scholarly journal article. Why would you want to discourage the creation of an article like that? WhatamIdoing (talk) 03:09, 1 September 2022 (UTC)

This was the version at the time of my comment. Database-replications like that are not useful for readers; they are better off being sent to a parent article where that information can be included until an editor has time to write a more comprehensive article. BilledMammal (talk) 03:17, 1 September 2022 (UTC)

Yes, it's longer now though. So it shouldn't so clearly be AFD'd or merged. So if every new stub started out this long, I bet there wouldn't be a dispute. Just don't create it if you can't make it this long. Andre🚐 03:20, 1 September 2022 (UTC)

I bet there wouldn't be a dispute; you would be right. If that was what was happening, I wouldn't have asked them to come here and get approval for mass creation, because they wouldn't be engaged in mass creation. BilledMammal (talk) 03:48, 1 September 2022 (UTC)

At the time of your comment, H. ericae contained four sentences, two sources, and an infobox. That is not normally a size that we are concerned about. The (historical) page defining substubs said "Substubs are usually no longer than a dictionary definition, and usually contain information that anyone would know." I don't think that describes any of these articles. They are longer than a dictionary definition, and almost none of the information in them is something that anyone would know.

Your assertion that articles "like that are not useful for readers" is your personal opinion. I personally benefited from a series of equally short (or worse) species article just a couple of weeks ago (for a plant, rather than a fish). As a result, my personal opinion is that your personal opinion is wrong. I could believe that these articles a not interesting to very many readers, but that's not the same as them never being useful to anyone at all.

I think that the general principle you should be considering is related to Wikipedia:Deletion is not cleanup. It's actually okay to create a species stub with a few sentences, two sources, and an infobox. Not all articles have to be long ones, and they definitely don't have to be long articles on the day that they're created. WhatamIdoing (talk) 05:47, 1 September 2022 (UTC)

• Oppose mass creation of any group of articles, period. Mass creations can sometimes lead to mass Prods or mass AfDs. The latter of which can get messy. GoodDay (talk) 00:02, 1 September 2022 (UTC)
• Agree with Uanfala and WhatamIdoing. If someone wants to go around and create a bunch of species articles like Hypostomus robinii, then great. That really shouldn't be problematic. If it would only be a single line derived from basic taxonomy and/or if we were talking about some tens or hundreds of thousands, then sure we should have a discussion, but this should be a non-issue. It sure seems like some people are just against the idea of creating stubs at all, and the specter of "mass creation" (500 manually created articles, with acceptable sourcing, created over 9 months is not what I'd call "mass creation" of the sort that's controversial) provides a convenient mechanism for action. — Rhododendrites ^talk \\ 03:24, 1 September 2022 (UTC)

  I think there probably wouldn't be an issue if substubs such as this "article," weren't created: "Hypostomus chrysostiktos is a species of catfish in the family Loricariidae. It is native to South America, where it occurs in the Paraguaçu River basin in Brazil. It is typically seen in blackwater portions of rivers with rocky substrates at elevations of 50 to 662 m (164 to 2172 ft) above sea level. The species reaches 26 cm (10.2 inches) SL and is believed to be a facultative air-breather." Andre🚐 03:29, 1 September 2022 (UTC)

  You keep using this word "substubs" like an article with just 3-4 referenced sentences is too short to exist, which is not something there is consensus for. 18 years ago there was in fact a discussion about the essay Wikipedia:Substub which not only ended up with a consensus that very short articles are fine, but we don't even mark such articles separately from other stubs, even though according to WP:STUB there is no consensus on how big a stub is. There's no minimum required length for a Wikipedia article, only that it passes the bar for verifiability and notability. Steven Walling • talk 04:42, 1 September 2022 (UTC)

  There's no minimum required length for a Wikipedia article, only that it passes the bar for verifiability and notability. - it also needs to meet the requirements of WP:PAGEDECIDE and not violate WP:NOT. "Microstubs" or "Substubs", whatever you prefer to call them, often struggle to do so. BilledMammal (talk) 04:45, 1 September 2022 (UTC)

  I never said there were length requirements for articles, but articles do need to be encyclopedic and informative. The reason why substubs don't exist anymore per se, as I remember it, and like you said it was a very long time ago, is the advent of bright line notability requirements and referencing requirements. Back then, you could just make pages that were 1 or 2 sentences long and put {{substub}}, no references, and it would still be debated at VFD (as it was called then), and plenty of pages existed for a while before getting deleted that were all kinds of fictional characters and stuff that we today, will merge into a list article to avoid too much fancruft (to use another old wiki slang term). As I remember it, the reason why the template and the categories for substubs were done away with had a lot to do with there not being many substubs that could justify their existence. There subsequently was the requirement that articles had to assert notability. And now of course there is NPP, drafts, etc. Andre🚐 04:49, 1 September 2022 (UTC)

  "substubs" aren't a thing (well, other than a rhetorical tool). I don't see a problem with starting Hypostomus chrysostiktos the way Lumpsucker did. Expand it if you can, propose a merge if you want. All regular editorial decisions remain in place. It doesn't "create work" for other people because nobody is obliged to improve anything and as it stands it's completely policy compliant. — Rhododendrites ^talk \\ 19:47, 1 September 2022 (UTC)

  Substubs were a thing but let's not get hung up on terminology. I think tagging substubs stopped being necessary in part because WP:CSD began to cover A7,A9,and A11. Per this essay, Wikipedia:Credible claim of significance. You're right, no policy is being violated, it's not "making new work," but that is separate from whether all of these articles created should be kept at an AFD and not merged, which I think is a worthwhile question. Not saying Lumpsucker was the bad guy, but he should take note of the community's feedback good and bad for the article work. Andre🚐 21:02, 1 September 2022 (UTC)

  If someone wants to create a bunch of species articles like the current status of Hypostomus robinii, then great; we wouldn't be here if that was what was happening. However, that isn't what was happening; this is what was created, and that is an issue. BilledMammal (talk) 03:39, 1 September 2022 (UTC)

  Exactly, so, if the fish team could simply agree to make all the articles be up to that par or close to it, we'd have no problems. Andre🚐 04:51, 1 September 2022 (UTC)

  Hypostomus robinii as originally created was a perfectly good stub. It managed in its four sentences to include eight or nine separate facts about the species, in addition to comprehensive taxonomic information. It's now been further expanded to Hypostomus robinii. The encyclopedia is working as it should. MichaelMaggs (talk) 08:36, 1 September 2022 (UTC)

  I'm astounded that the initial version of Hypostomus robinii is being presented as an example of a bad stub. This thread started over concerns about semi-automated editing. Some of Lumpsucker's fish articles could have beeen generated by just copy-pasting a template and changing the species, river system where it occurs and standard length. The initial version of H. robinii includes a common name, diet, and more detail on habitat and distribution than just naming a single river system. I'll acknowledge that the only sources are databases, but it wasn't created in a semi-automated way by copy-pasting and changing a few variables (and FishBase has it's range as Central America:Trinidad, while the article places Trinidad in the Caribbean which I think is more accurate and shows Lumpsucker didn't just blindly insert variables from FishBase). Plantdrew (talk) 16:56, 1 September 2022 (UTC)

  I don't see anybody presenting Hypostomus robinii as an example of a bad stub. It's not even relevant to this discussion, as has been pointed out above. Levivich 17:56, 1 September 2022 (UTC)

  To clarify for you, at the start of this thread indent, BilledMammal suggests that the initial version Hypostomus robinii "is an issue". Esculenta (talk) 18:06, 1 September 2022 (UTC)

  Thanks, and sorry, I misread that comment. Levivich 18:20, 1 September 2022 (UTC)

  If someone wants to create a bunch of species articles like the current status of Hypostomus robinii, then great; we wouldn't be here if that was what was happening. True. What happened is someone manually started an article on a notable subject with two sources. Someone else came along and improved it. This is a wiki, after all. I would like it if people would improve an article they create rather than leave it a stub, but unless you find consensus for that, this sort of article isn't allowed. I didn't support Lugnuts' creation of single-sentence stubs based on databases because the databases didn't provide any real information and didn't actually ensure notability. An identified species will have some actual paperwork behind it, and indeed the starting version of this article has more than a single sentence with statistics. It may not be ideal, but it's completely in line with wikipolicy. — Rhododendrites ^talk \\ 19:47, 1 September 2022 (UTC)

  These several recent ANIs with mass creation and the upcoming RFC mandated by sending about mass creation and deletion are signs the community dies not want someone to mass create stubs with questionable notability. A two paragraph article may be a stub but if it shown 403 or 4 good sources for significant coverage, we are far less likely to conplain. I think it is more dose don't want editors creating mass articles with low level effort (like just pulling from databases or finding one source and calling it good). mass creation with more effort will draw less attention. they may be stubs still but they are in a better place for expansion Masem (t) 20:03, 1 September 2022 (UTC)

• It is not clear that a problem exists. The topics are notable in that a reliable source definitively exists for every recognised described species. Two articles per day on clearly notable topics is not mass creation, and most of the articles discussed here in any detail appear to be better than sub-stubs by a significant margin. While there are debatable advantages to the utility of conbining such articles, not necessrily as lists per se, but as sections in an article on a higher taxon, (actually my personal preference), the articles in general appear to be fully legitimate, with possible exceptions which have not been specified. The editor was requested to seek comment here, which they have done. I thank them for that as it displays the attitude of collegial discussion and open-mindedness we officially strive for. Unfortunately some of the comment lacks grounding in policy, guidance or tradition, but that is pretty normal, as everyone thinks they are an expert. Expressing a personal preference, opinion or bias as a !vote gives it no extra weight or validity. Cheers, · · · Peter Southwood ^(talk): 05:29, 2 September 2022 (UTC)

  I concur with this Andre🚐 05:35, 2 September 2022 (UTC)

• [ec] It might be helpful if some of our editors did a little research on the process of taxon description and publishing, and the inclusion criteria of taxonomic databases before expressing their opinions on notabilty or lack thereof of a published taxon. · · · Peter Southwood ^(talk): 05:40, 2 September 2022 (UTC)

  Thank-you for the suggestion that we shoul learn more about Taxanomic databases before commenting. it is quite a fascinating topic. To summarise paid and volunteer work to create a taxanomic machine readable database that links physical material, media, and the written word.

  Problems are poor countries/organisations, uncontrolled/non-updated/non-validated subsets, secondary databases inability to create 'semantic and syntactic information that would improve the fitness of these data", and difficulties with occourence datasets ( Birdwatching etc) [1] [2][3][4]

  Best practise seems to be to link dynamicially Amphibia Web Wakelamp d[@-@]b (talk) 13:10, 20 September 2022 (UTC)

• Oppose creation of species articles cited only to database listings. These species can be covered in list articles. Support the creation of species articles that cite and summarize significant prose coverage of the species in reliable sources. Cullen328 (talk) 05:56, 2 September 2022 (UTC)

  Concur with this nuance also Andre🚐 05:58, 2 September 2022 (UTC)

• Support. The sentiment that "mass creation from databases is bad" is close to right, but not quite there, in my opinion. Turning an accurate entry in an external public database into a stub is, in my opinion, neutral or very close to it. It doesn't really improve things—the reader could probably just as easily pull it from the original database, probably in a more useful format than Wikipedia prose—but it's not really harmful, either, the offense to some editors' taste notwithstanding. The damage occurs when the external database is not accurate (or if the mass creator is not accurately transcribing that information). In the case of biology stubs, this usually takes the form of a species being listed under a name that is no longer current or a name that was never really published. In the case of the sports stubs, my impression is that there have been widespread errors (depending on the creator) in birth and death dates, which events they competed in, standing etc. In the case of the geography stubs, places that are not, and never have been, concentrations of population have been misrepresented as being so (a single house or a landmark being misrepresented as a village). Propagating and disseminating external error, rather than correcting it through the power of many eyeballs, is directly damaging to the encyclopedia. All that said, I see no problem with the initial version of Hypostomus robinii that BilledMammal deprecates. In particular, I would note that it's sourced to two databases that appear to be substantially independent of each other. In my experience (I would note that I sink a fair bit of my leisure time into helping correct non-Wikipedia taxonomic databases), that's likely to avoid most of the damage caused by the really problematic mass creations described above, and also to limit the rate of creation to something relatively modest. Choess (talk) 15:53, 2 September 2022 (UTC)
• Oppose Bulk creation of database stubs. More substantive content and sourcing is expected for each article. A List of Hypostomus species that compiles content for comparison and context would be welcome. Reywas92^Talk 18:21, 2 September 2022 (UTC)
• Strongly Oppose From their point of view we are creating a Wikipedia:Wikipedia_clones designed to reduce their traffic, and break thier community. We are doing the same thing on reptiles and other small databases. We also don't have as much information, our cite does not mention that we use thier cite, and we will have no one actively updating the information. Wakelamp d[@-@]b (talk) 04:49, 3 September 2022 (UTC)
• what an amazing waste of effort this discussion is producing, the simple answer is put the data base in Wikidata like we are asked to do then generate list articles from there. No where in the discussion has it been shown these stubs arent notable subjects, nor that the creation of them is causing any disruption to the project its a simple case of "I dont like it" therefore noone can do it. Gnangarra 14:18, 3 September 2022 (UTC)

  Totally agree - except I would actually get wikidata to negotitate with the site that is maintaining it, If a user searchs for it, they get shown a wikidata created page, Wakelamp d[@-@]b (talk) 14:59, 4 September 2022 (UTC)

• Support The OP's recent creations such as Hypostomus dardanelos and Parotocinclus hardmani look perfectly reasonable and respectable. A separate page for each such species is sensible as the page will then readily support an infobox and appropriate imagery such as a picture of the creature and map of its distribution. Lumpsucker's editing of such subjects is commendable as it seems quite fluent and encyclopedic. It does not seem especially bot-like or high volume and so no special process or permission is required. As for species, there are certainly a lot of them but so it goes and it's not a problem. Our policy is WP:NOTPAPER which states clearly that "there is no practical limit" and so we should not invent one just to be difficult. Andrew🐉(talk) 20:23, 3 September 2022 (UTC)
• Oppose - send the bot-like mass creations to WikiSpecies – we need articles at en.WP not taxosentences that are basically definitions or more like WikiData that Google can use. Let the WMF capitalize on these BOTs and then they can use that money to get en.WP the tools we need to build this encyclopedia as the encyclopedia it was intended to be. As for all the support votes - if this Proposal passes, all the editors who voted support will be automatically added as NPP reviewers on assignment and your dedicated job will be to review all BOT-like creations. Atsme 💬 📧 21:15, 4 September 2022 (UTC) ^{Correction: bot-like not bots. Apologies for the error and thank you for pointing it out to me Lumpsucker and Andrevan. I really would like to see WikiSpecies used for this purpose.} Atsme 💬 📧 03:15, 5 September 2022 (UTC)

  I don't know if I am understanding this message correctly, but this discussion is not about bot-created articles. Lumpsucker (talk) 22:26, 4 September 2022 (UTC)

  Atsme misunderstood the discussion. Atsme, these are human-created articles being discussed. Andre🚐 22:31, 4 September 2022 (UTC)

• Moral support for Lumpsucker and since nothing was being proposed, nothing is being opposed. Lumpsucker has already stated they will improve these articles and will abide by policy. Andre🚐 22:32, 4 September 2022 (UTC)
• Oppose until a WP:BRFA has been passed, then support. Generally oppose bot-like edits with user accounts. AKAF (talk) 09:55, 6 September 2022 (UTC)

@AKAF: The question is how would you define bot-like edits? That seems to be the crux of the disagreement, because to me the original version of this article that was used as an example for this discussion doesn't look bot-like at all–it has two sources and original content not written using a template. The current version has since been expanded to be decent stub that's even better. The original creator was doing 1-2 of these a day, which is plenty slow enough that the other editors in WikiProject Fishes or related projects can review them and hardly the scale that only a bot or script could achieve. Steven Walling • talk 21:01, 7 September 2022 (UTC)

@Steven Walling: The original version was actually written using a template:

NAME is a species of catfish in the family Loricariidae. It is native to South America, where it occurs AREA OF OCCURRENCE. The species reaches LENGTH cm (LENGTH inches) SL and is believed to be a facultative air-breather.

Compare it to the other examples I provided, like Hypostomus argus and Hypostomus johnii. BilledMammal (talk) 02:08, 8 September 2022 (UTC)

Ok but I still don't agree that's a bot-like set of articles created. There's a human being reading the source material and applying that knowledge to original article content, which is subsequently being edited and expanded by others. How is this harmful rather than helpful? We now have more verifiable knowledge in the encyclopedia that has been reviewed by humans, not bots which are dumb and don't understand the meaning of sources. That's the problem with bot creation (that they're often incorrect, because the bot doesn't actually understand the sources) and why we don't allow bot-created articles generally. This is totally different in outcome. Steven Walling • talk 17:37, 8 September 2022 (UTC)

If the source is reliable, a bot is actually better than a human; the human makes transcription mistakes, the bot does not.

As for why we don't want micro-stubs like these, Levivich and Casualdejekyll has said it well. Readers are better served by a list or general article than they are by these microstubs. I would also mention that we aren't just here to build a large encyclopedia, we are here to build a quality encyclopaedia, and the proliferation of micro-stubs like these reduce the quality. BilledMammal (talk) 23:52, 8 September 2022 (UTC)

"micro-stubs like these reduce the quality"

This is false and not in alignment with core editing policy. Having a small, well-referenced article does not detract from the quality of other articles. More importantly, it's inherent to the nature of the wiki that we have articles of varying size and quality. Wikipedia is a work in progress and perfection everywhere is not required. Steven Walling • talk 16:26, 9 September 2022 (UTC)

I have to agree with this - how do micro-stubs reduce the quality of good articles? Regardless of whether you think such an article should be merged or kept, I don't see the additive production of small articles reducing the quality of the overall work. Andre🚐 16:28, 9 September 2022 (UTC)

I agree that @Lumpsucker 's 500 articles are not an issue ( and I thank them for their work), but this discussion is about the general case. The reduction in the quality of good articles is in perception. If a study was done on Wikipedia accuracy, 86% (6.5/7.5 Millions would be based on stubs/starts/unassessed)

We shouldn't create something that we will not update Nearly all updates on stubs are by bots, but with no content as @Andrevan' s example indicated. We have a higher Google page rank, so readers will view our less accurate version, at the expense of the community that we online database strip mined. Wakelamp d[@-@]b (talk) 02:22, 11 September 2022 (UTC)

I think you made a good point Wakelamp about the smaller communities. Since Lumpsucker is trying to create Wikipedia-quality entries, hopefully, there will still be a place on the Internet for Fishbase to create entries for things that may not make a good Wiki entry at present, or maybe ever. Some species may not be attested much. Who knows why. There's no rule in natural history that says everything will be documented verifiably. Andre🚐 02:25, 11 September 2022 (UTC)

• Oppose mass creation but this one is borderline on being mass creation Maybe slow down and do a thorough source search for material for each article and put the material in. North8000 (talk) 21:12, 7 September 2022 (UTC)
•  Support. 2 articles a day is nowhere near mass creation. — Qwerfjkltalk 20:35, 8 September 2022 (UTC)
• oppose Levivich and BD2412 have the right idea here. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 22:16, 8 September 2022 (UTC)
• Uh-Oh we want to be careful here because "Support" is being used for two opposite opinions ("SUPPORT OP's suggestion of reigning hn these articles" but also "SUPPORT the continued creation of these articles"; and vice versa for "Oppose". Just pointing this out. Herostratus (talk) 01:57, 9 September 2022 (UTC)
• Well, I think these articles are fine. I think the argument is between "let's have lists" and "let's have individual articles". I think that people who don't think we should publish this material at all are in a minority compared to people who do but can't agree on the format.

So, it's basically a matter of opinion. It's the Wikipedia not ExxonMobile, so it one editor wants to create a long list and another a bunch of small articles, I'm just glad to have the info. I'm not big on telling "you can't do that, you have to do it my way" to people who have just spent hundreds of hours creating content, and might stop if annoyed. Generally and withing reason, stare decisis is the rule for formatting, giving deference to the person who did, I don't know, the actual work of creating the encyclopedia, and also to prevent sterile warring about one editors personal preferance over another. We don't need a rule for everything, and we don't need to be busybodies.

On the merits, I happen to like the articles better. That's just me. A proponent opines "One of the reasons [for having lists instead] is context: Hypostomus brevis doesn't tell me that this particular species of catfish is one of 100+ species of Hypostomus". Well it could, so go add it. But it's a reasonable point otherwise. But if there are 100+ entries on "List of Hypostomus species" when we get to them, that's a pretty long article. If you're including the infobox (much shorter, granted) and a picture, you're getting into a lot of these, and 100+ pictures for short entries makes it hard to have good formatting -- and easy reading. And the References section will be hundreds of entries long. Finding the references for only say Hypostomus brevis in particular will harder to do. Many of the refs will be just page numbers, and then you have to and find the first ref to the book I suppose. Navigation -- either your Table of Contents will be 100+ entries long which is rididulous, or you'll have to figure out some other scheme.

I just don't think it's easier to navigate a large article that is 100's entries long than 100+ individual articles. This sort of thing is studied somewhere I'm sure, and I think it's very likely that a human factors engineer or user interface designer would barf at a TOC that large. Sure you can divide the species into groups -- by Subgenus, or geographical location, or whatever -- but then accessing an individual species is hard.

But then, you can make the list shorter if you omit some information. Why omit inforation that we already have -- I don't think our readers can't handle these amounts of detail. So, sure you can omit say "...and is believed to be a facultative air-breather" from maybe the articles for a whole subgenus and put it in a section header ("All of the following are believed to be facultative air-breathers"), but then you are spreading out information about the entity into two places -- not a service to the reader. Or you can just have subgenus sections and just describe things common to all the species in that subgenus, or something. If that's how you roll. I don't.

Another thing about lists is that they can be attractive nuisences forjust destroying some information. You know, like "Geez this list is long. Do we really need say 'The fish was first formally described by John Treadwell Nichols in 1919'? That doesn't tell anything about the species itself, and we can make the list a lot more managable if we leave out the discovery info". I'm not super on board with that either. Herostratus (talk) 01:57, 9 September 2022 (UTC)

This is a very good point. I am a reader. I am not "served" by enormous lists, which take a while to load on my machine and are virtually impossible to edit for more than a few characters without the page hanging. Gnomingstuff (talk) 12:53, 16 September 2022 (UTC)

• Support -- The crusade against valid encyclopedic content just because the articles happen to be short was absurd from the beginning and remains absurd (not least because of the mountain of undetected vandalism, PR-speak, fan-speak, un-copyedited, and generally embarrassingly written content that is actually embarrassing to the project, as opposed to neutrally-written, academic, inobtrusive entries on, in this case, fish). The vilification of the people who make them is worse. There should not have to be a topic where one can support or oppose improving the encyclopedia! Gnomingstuff (talk) 12:45, 16 September 2022 (UTC)
• Oppose mass creation of "sub-stub articles" (per Donald Albury), on fish species or otherwise, per Levivich and Ajpolino and UnitedStatesian. Rationale: 1)- Data bases have errors. There is no actual secondary sources with significant coverage to confirm the information. I became weary of all the GNIS populated places articles that, with no proper outside sourcing, showed things like empty fields. What we end up with is just copied wording from a database to an article page, 2)- by creating these glorified dictionary entries there is too much important information missing and what is included in pieced from the database information. I know it is not the actually reasoning but since Wikipedia is gungho on stats and it does look good for article creation, 3)- it makes sense to put these in proper lists where silly things like Wikipedia:Reliable sources: Wikipedia articles should be based on reliable, published sources, making sure that all majority and significant minority views that have appeared in those sources are covered (NPOV), covers content and not notability. 4)- Article that are basically prose of database information is not encyclopedic. We can create short uninformative stubs of the "92 genera and just over 680 species" of the Loricariidae but how does that help Wikipedia except possible showing it is still growing. Why do we want to sacrifice quality for quantity? 5)- It would be better to "try covering all the species in sections on the genus article and split out the most substantial sections into their own article.", per casualdejekyll. Agree with "two sentence stubs with no clear notability, nor any expectation they will be improved to meet that." per Masem -- Otr500 (talk) 05:49, 18 September 2022 (UTC)

  @Otr500, you say that "Data bases have errors". Are you aware of any errors in these databases? Telling editors that they shouldn't rely on these sources because similarly formatted sources in a completely unrelated field have problems would be an example of a Faulty generalization.

  As for whether it contains SIGCOV, as an example, I went through one reputable fish-species secondary database to see how much of an article I could write. You can read the results here. The short answer is that if you define SIGCOV as meaning 'contains enough information to write more than a doomed permastub', then this database definitely contains SIGCOV. WhatamIdoing (talk) 17:36, 19 September 2022 (UTC)

  I have seen errors in FishBase. Lumpsucker (talk) 18:12, 19 September 2022 (UTC)

  Reply: (actually to WhatamIdoing) I did not yet look at the example (yet) for I was looking elsewhere. Hypostomus johnii contains two sources, both databases (ITIS and FishBase) and "IF" this (I assume scholarly) abstract is considered reliable then the 2007 update (redescription) seems to indicate that Steindachner (1877) may have confused the Hypostomus johnii with congeners in the São Francisco River. "If" this is true then the article, using just database information, is flawed. A preliminary survey (Burgess, W.E., 1989) apparently centered only on Siluriformes (catfish) and not on individual species. This is the very first example I randomly picked. I suppose if you found one that could be considered SIGCOV, I would have to say (the only one I checked so far) does not pass.

  In no way do I want to hinder an editor from creating or improving articles. I am just attempting to show there should be more to an article that the use of only a database, which in essence is just a database copied into prose form possible to satisfy WP:SPECIESOUTCOMES: at least a brief description must have been published in a reliable academic publication to be recognized as correct or valid., but I question if a database satisfies "academic publication" when there is no description and an editor has to create prose from the content.

  When Wikipedia was striving to be a world encyclopedia it was common to create an article with one source, no source, or the source located in the "External links". We have nothing to prove now except improving the quality of even stub articles and the accuracy of any created article. I don't assume an article (even stub) is "doomed" because it only has a database listing.I think moving forward an editor should do at least some research and not just create I think that 900 articles (I am pretty sure I read that) a year , almost 2 1/2 articles a day, to some, can be considered mass creating if just copying material into prose from a database. Although there is no hurry for improvements I can't see any way a vast majority of these can ever be be checked/expanded, especially since the author has commented continuing the status quo, knowing consensus has previously considered species notable for inclusion.

  "If" consensus deems an editor can create as many articles as desired, especially using only database content converted to prose, I would hope that editor reads the negative rational here. casualdejekyll stated: "They're stubs. Sourced stubs, sure, if they weren't on such an obviously notable subject they don't have the sourcing to show the notability", and that is a sad realization. Since sourcing on any considered notable subjects (we can leave out "presumed" and add fish species to automatically notable), would be exempt from some standards, we can just create 1000's and not worry about any sourcing at all or accuracy. If there is still a presumption of notability then reliable sourcing is still required.

  In defense of the singled out editor one can look at the project Wikipedia:WikiProject Fishes/Assessment#Quality scale (Stub: more detailed criteria): "The article is either a very short article or a rough collection of information that will need much work to become a meaningful article.", and "may be little more than a dictionary definition" to see justification for stubby-stubs. However, it also includes "Although Stub-class articles are the lowest class of the normal classes, they are adequate enough to be an accepted article, though they do have risks of being dropped from being an article altogether." This appears to support that there is presumed and not inherit notability (arguemnts to avoid).

  WP:SIGCOV states: "Significant coverage" addresses the topic directly and in detail, so that no original research is needed to extract the content. and I can't see justification in a database listing and 1000's of articles created from them. The editors comments below might have missed the one I checked as I see some issues. Donald Albury (below) seems to have hit the nail on the head, having "no objection to using a database to find subjects for creating articles, as long as each article is also supported by at least one reliable source other than the database." A list could be created for the articles that did not follow that criteria or could be placed in a higher-level article. I do agree with above statements that articles on species would very likely not be deleted at AFD, although some other course of action could be the result. -- Otr500 (talk)

  Special important Note: If we are concerned only with article creations concerning the above editor, the issue is solved per positive comments from the editor that stated: Before creating any other articles, I am planning on expanding a few of my smallest articles as I already have been doing. Some of those were only created with a single source and are less than 1 KB in length, and I am looking to improve most of the articles of that size that I made. I hope these improvements will include more than database content. That is all I need here since I do not foresee starting any AFD on species. "If" anyone does start an RFC on "mass article creation", please ping me, on species or any other subject. -- Otr500 (talk) 20:52, 19 September 2022 (UTC)

  @Otr500:, the link to that abstract doesn't work for me, but I assume it's the same as publication as this one althought that was published in 2017 rather than 2007 (but if H. johniihad be redescribed in 2007, another redescription in 2017 would probably be unnecessary). The authors examined the same specimens (allegedly) from the São Francisco River that Steindachner did, and did not find them to be anything other than H. johnii. It may be the case that H. johnii did occur in the São Francisco River in 1877, but has since been extirpated; it may be the case that the specimens weren't actually collected in the São Francisco River but were mislabelled as such (which should not be a problem for Wikipedia; Wikipedia:Verifiability, not truth). The cover of Burgess's book promises a "complete checklist of the genera and species".

  The reliable academic publication that SPECIESOUTCOMES refers to is, in this case, Steindachner's 1877 original description of the species, available on BHL. It's in German and runs not quite 2 pages. Few species articles currently cite the original description directly (but there's almost always an indirect citation with the authority in the taxobox). Original descriptions may not be available online; BHL has a lot of taxonomic literature that is out of copyright, but uploading a publication that describes a single species isn't going to be a high priority for them. Other original descriptions may not be out of copyright. Many are in a foreign language (particularly Latin in the 19th century). The original description of a species described a long time ago may not be sufficient to distinguish it from the larger number of related species that are known now (this is why H. johnii was redescribed in 2017).

  SPECIESOUTCOMES begins with Species that have a correct name (botany) or valid name (zoology) are generally kept.. So far in this thread, nobody has mentioned why species articles are sourced to taxonomic databases. The database is the source that shows that a name is correct/valid. Taxonomy is subjective to a degree; taxonomists can disagree about whether two populations represent different subspecies, or aren't worth recognizing as taxonomically distinct at all; going the other way they can disagree about whether there are two species or one species with two subspecies. If we are going to present a list of species regarded as valid/correct in a genus article, that list needs to come from a single source, and in 2022 that source is usually going to be a taxonomic database (we can't just piece together a list of species in a genus from the original descriptions; there are several times as many species that have been described as are currently recognized by a consensus of taxonomists). Original descriptions are primary sources; the act of describing a species means that the person doing so thinks it is valid. Taxonomic databases are secondary or tertiary sources that show that somebody other than the original describer agrees a species is valid.

  @WhatamIdoing:'s example doesn't mention the most important fact; it is a valid species, according to FishBase. Probably because that's taken as a given; taxonomic databases list invalid species as well as valid ones, and absolutely nobody is churning out sub-stubs for species that aren't considered valid. There are two high quality taxonomic databases for fish; the other Catalog of Fishes. For the vast majority of fish species, both databases are in agreement as to their validity. WikiProject Fishes has chosen to follow FishBase (in the early years of Wikipedia, it wasn't possible to link directly to species records in Catalog of Fishes). Every article for fish species should cite FishBase; that's the baseline to establish that the species is valid. Fish articles ought to cite the original description (if it was described recently); or a detailed rediscription (if it was described long ago). If there is active disagreement among taxonomists about the validity of a species, that ought to be mentioned as well (e.g. in article for species X "Catalog of Fishes recognizes species X and Y as distinct, but FishBase considers Y a synonym of X). Plantdrew (talk) 21:22, 20 September 2022 (UTC)

  I think this is that problem of most editors not knowing the subject area. Otr500 writes I question if a database satisfies "academic publication". The database isn't the academic publication, but these two databases don't include species unless there really was an academic publication. The real-world process for the would-be fish discoverer is:

  1. See a fish.
  2. Figure out that it's never been described in a peer-reviewed scientific journal.
  3. Publish a description that contains a description sufficient for other scientists to differentiate your new fish from other fish plus your choice of name (which must follow certain rules) in a peer-reviewed scientific journal. (Fun fact: until 10 years ago, only journals printed on paper were acceptable. It is still true that only "reputable" peer-reviewed journals are acceptable.)
  4. FishBase reads your journal article and makes a record for the fish.

  From the Wikipedia editor's perspective, if it's in one of these databases and marked as having a valid name (a "valid name" is a special thing in the real world, and it is not the same as having, say, a grammatically correct name), then Wikipedia editors [should] know, with 100% certainty, that steps 1, 2, and 3 have happened in the real world. Even if you don't have the peer-reviewed scientific journal article, you know that it was published, because publishing that peer-reviewed article is the only way to get a valid name.

  But if you feel a need to check on whether this mandatory process really was followed for any particular entry that claims to have a valid name, then using Entomocorus benjamini as an example, FishBase says, in the very first line/title of the database record that the original description was written by Carl H. Eigenmann in 1917, like this:

  Entomocorus benjamini Eigenmann, 1917

  All four of the words are links. If you click on the last one (the year), it gives you the full bibliographic citation for the original peer-reviewed scientific journal article. Skeptical editors don't have to wonder whether there was an academic publication. You just have to click on the link in the database entry and find out. WhatamIdoing (talk) 01:09, 21 September 2022 (UTC)

• Support. I've never understood people who devote themselves to deleting useful properly sourced information. I looked at all the fish articles mentioned in this thread and don't see a problem with any of them. Some are short; so what, lots of articles start off short. Some even stay short because there aren't many sources, but that has never been an excuse for deletion if what is there is notable and properly sourced. Moreover, the claim that a species of life can be non-notable is frankly obscene. If Wikipedia had an article on every known species on Earth, that would be the most extraordinary achievement in the life of the encyclopedia. Lift your horizons. Zero^talk 08:48, 18 September 2022 (UTC)

  You're way too long in the tooth to be referring to merger as "deletion" or ignoring altogether WP:PAGEDECIDE (the section of the notability guideline dedicated entirely to the idea that just because a topic is notable doesn't necessarily mean it's best to have a stand-alone page). Levivich (talk) 14:32, 20 September 2022 (UTC)

• Comment I have not expressed an opinion on this set of creations, and I do not have the time available to review the articles, but, since my name has been invoked, I want to clarify that while I would like to see a consensus of the community to prevent articles being created based solely on a database, I have no objection to using a database to find subjects for creating articles, as long as each article is also supported by at least one reliable source other than the database. I also feel that list articles are fine for subjects for which sufficient material from reliable source has not yet been found to support a stand-alone article. YMMV. - Donald Albury 20:49, 18 September 2022 (UTC)

WIkidata is looking at negotiating to be the central hub in DE Wakelamp d[@-@]b (talk) 08:18, 24 September 2022 (UTC)

• Strongest possible support, the antagonism towards microstubs and stubs, and deletionist policies in general go against the spirit of Wikipedia. If the pages are too short for your liking, then expand them. If you can't expand them, then move on with your life and expand the next article. Nothing is gained from removing information.--Ortizesp (talk) 16:12, 5 October 2022 (UTC)

  But, there are many stubs that will never be expanded, and are basically useless, or even harmful. Having an article about a place for which nothing can be found, except a name on a map, is not helping the encyclopedia, yet I was only able to remove one after spending many hours searching for anything about it. I might add that the stub in question (Hasan, Florida) had existed for years and had been edited 72 times, mainly adding and deleting unsourced, often nonsense, material, before it was deleted, a waste of a lot of time and effort. What is so terrible about asking someone who is creating an article to provide a citation or two to establish notability. Donald Albury 18:47, 5 October 2022 (UTC)

  There are many longer articles that, despite having been expanded, are useless and even harmful, and yet we don't call for deleting longer articles. Maybe size isn't the key point?

  You can "provide a citation or two" – or twelve, for that matter – without actually expanding the article. Also, no matter how many citations you provide, someone with a different POV is still free to declare that it doesn't establish notability. I remember seeing a major hospital at AFD. It was the size of Royal Derby Hospital, attached to a university and a medical school, and it had a bunch of independent sources, but that didn't stop an editor from trying to claim that it wasn't really notable. (He lost; the article was kept.) I think the real question here is not about whether it's a stub, but whether can you write an article to convince me that the subject is notable, when I already don't want to believe you because I think your favorite subject is unimportant and useless. WhatamIdoing (talk) 23:08, 5 October 2022 (UTC)

  @Gnangarra and Gnan: Maritime park for Editathons : Based on your comment "You'll also note that these articles are one WMF KPI's for events if you look over at Outreach dashboards." Should fish species be segregated from bot creation , so it is available for editathons now and in the future? (The Meta bot created drafts of thousands of women bios earlier this year.)

  How do these articles get updated based on new information? And would people be in favour of automated updates of existing articles - say to add new journal references?

• @AddWittyNameHere: " digitization for old non-English sources" made me think that I would be rapt if WMF raised a 100 M a year if they helped fund scanning of old journals/supported small databases/Bought ancient Author rights, or paid for ethno-groups to scan their languages BUT ONLY IF they wished)

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.

Category for Summer Olympic host citiesh

Hello! Can you add a category for Summer Olympic host cities. The category should then be named Host cities for Summer Olympics and the same should count for Winter Olympics then it should be named Host cities for Winter Olympics. Yours sincerely, Sondre 88.88.4.178 (talk) 14:52, 19 October 2022 (UTC)

The host cities display {{Olympic Summer Games Host Cities}} or {{Olympic Winter Games Host Cities}} at the bottom. I don't think a category is needed. It doesn't seem important enough for a large city to clutter up the list of categories. PrimeHunter (talk) 15:59, 19 October 2022 (UTC)

Per WP:CLN, not every thing needs a category. Many major cities (basically all of the host cities are major cities) already suffer from overcategorization, and adding one more to the mix is a Bad Idea. People can find the list in many ways, such as at the navigation templates linked by PrimeHunter, or List of Olympic Games host cities. Categorization is not required, and not needed, here, as a navigational tool. --Jayron32 16:10, 19 October 2022 (UTC)

Recommend using {{TextDiff}} for edit requests

I think this template should be recommended to users making an edit request by including it in the Edit Request Wizard preloads and mentioning it in WP:ER. Aaron Liu (talk) 15:05, 22 October 2022 (UTC)

• This was mentioned at Wikipedia talk:Edit requests#An incredibly helpful suggestion? a while ago. I think that filling in a template is probably asking too much of users who likely don't have any wiki editing experience. As it stands, the vast majority of edit requests don't follow the existing directions, so adding filling in a template will probably not be very productive. ScottishFinnishRadish (talk) 15:26, 22 October 2022 (UTC)

  Yes but there are still people who follow them. Your argument sounds a bit like the Nirvana fallacy. Aaron Liu (talk) 15:31, 22 October 2022 (UTC)

  So what you're proposing is requiring the 5 or so percent of those requesting edits who follow the instructions to jump through further hoops and learn additional wikimarkup, while the remaining 95 percent who weren't going to follow the instructions anyway continue to not follow them, and now have another template added to the request?
  It's not really like the Nirvana fallacy, it's more like taking a work flow that already isn't followed and adding an additional step that won't be followed and will seldom provide a benefit over the current work flow. ScottishFinnishRadish (talk) 01:26, 23 October 2022 (UTC)

  Nah I'm not proposing to add an requirement, I'm proposing to merely recommend this, unless adding the template to the ERW preloads constitutes requiring. Aaron Liu (talk) 01:29, 23 October 2022 (UTC)

I would oppose this, I don't see how it would be an improvement.

I don't see how this would be useful to people reviewing requests. I think we can assume (or at least hope) that everyone answering edit requests should at the minimum know how to edit wikitext, so I don't see why it would be necessary to tell them exactly what to change.

This makes it much more complex to submit an edit request, which is especially problematic given that a lot of edit requests come from newbies. Instead of "change the 13 to 14 in the infobox citing example.com" someone submitting an edit request would now have to learn how to use the diff template, how to do infobox markup and how to use citation templates to show what they want to change. Even if they get that right the effort may be wasted and the reviewer may have to re-do the edit anyway if they miss any of the other intricacies that come with editing, WP:CITEVAR and WP:ENGVAR for example.

As the radish states people can't follow the existing instructions "say what you want changing and provide a reason and/or a source", so adding more complexity and instructions seems like a step in the wrong direction. If anything we need a simpler edit request system that guides people through the process in small steps, I've often thought a javascript form like the one we have at WP:RFP would be a good idea. 192.76.8.93 (talk) 01:07, 23 October 2022 (UTC)

@192.76.8.93: 1. What I propose is not a requirement but a recommendation.

2. Why would newbies need to learn infobox markup and citation templates? I think they'll just do something like

−

Sue, Mary, Star Trek, p.13

+

Sue, Mary, Star Trek, p.14

instead of digging into the wikitext.

3. The Edit Request Wizard exists. That's what the prelaods I mentioned are referring to. Aaron Liu (talk) 01:26, 23 October 2022 (UTC)

 Not done: please provide reliable sources that support the change you want to be made.
Now they need to figure out where to add a reference in the template. There's not many situations where it would work as well as just saying what has to be changed and providing a link, and even fewer where it would be more effective, and even fewer still where it would be beneficial and actually used. ScottishFinnishRadish (talk) 01:31, 23 October 2022 (UTC)

With or without my recommendation the problem you mentioned doesn't change. People not providing reliable sources is a separate issue that isn't affected by my proposal. Aaron Liu (talk) 14:38, 23 October 2022 (UTC)

The message that people read when they go to submit an edit request should be as short and simple as possible to give people the best possible chance of completing an edit request successfully, because they are used by complete newbies who don't know anything about editing here. The instructions should not be cluttered up with recommendations to use obscure templates and other advanced features of mediawiki mark-up - a significant chunk of people who submit edit requests won't know what a template is or even what a diff is.

You have completely misunderstood the example I gave. Imagine you have an article on a city, which in it's infobox states it has a population of 123,456 people sourced to a census from 2010. You want to submit an edit request that this number is updated to 134,567 people sourced to a census from 2020. Instead of just saying "change value x to value y using this source" the person submitting an edit request needs to figure out what infobox parameters to change, how to format the updated citation, then they need to get this to display in the diff template. Even if they do this it would be a massive waste of time on their part, because anyone responding to edit requests should be able to edit an infobox themselves without needing to be walked through exactly what wikitext to change.

The edit request wizard is one of the old wikitext based forms and a lot of people already struggle to complete it. Adding more text and more complex instructions does not strike me as helpful. 192.76.8.93 (talk) 17:22, 23 October 2022 (UTC)

@192.76.8.93:Again, there is no reason to assume a newbie would think they'll need to format an updated citation (even though the ERW also tells you to format as a citation but let's skip that). There are multiple ways to do one thing. For the detailed example you made, these are what I'm suggesting:1.

−

123456

+

134567 https://example.com/2020census or maybe a formatting version

−

123456

+

134567

2.by reason of https://example.com/2020census (mentioning refernece outside of textdiff) Aaron Liu (talk) 20:20, 23 October 2022 (UTC)

Wikipedia reliability

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

---

I recently made a mockup of a proposed functionality that would allow several new uses of wikipedia. I posted to the policy section recently, but only got a few replies calling me stupid.

I am pretty sure this is a good idea and many editors feel the underlying problem each day,

So nowyou know about it too. Thanks for looking into it. Nowakki (talk) 13:08, 23 October 2022 (UTC)

Seems like a classic "solution in search of a problem" thing. Zaathras (talk) 13:15, 23 October 2022 (UTC)

Unless your current activity requires you to calculate the average time of production of these 5 ships, in which case you are busy for 3 minutes going through a bunch of pdfs.

this is also not the worst that can happen. if a table relies on the proper matching of 2 or 3 primary source tables, it may take you an hour to verify it. and when you have done so, wouldn't you want to communicate your result the the next in line? Nowakki (talk) 18:48, 23 October 2022 (UTC)

How would your proposal change sources? For what I can tell before and after you still need to see the cited source. Aaron Liu (talk) 20:47, 23 October 2022 (UTC)

if you know with 98% certainty that the original source is properly cited and you are editing an article that does not have to be ultimately finished today, and a reference you insert in the new article will become flagged if the citation turns out to be errorneous. all this taken together, you can (choose to) quote wikipedia. which you can't at this point in time, because the tools are not there to make it work. Nowakki (talk) 21:05, 23 October 2022 (UTC)

@Nowakki:, please read WP:FORUMSHOP. - Donald Albury 14:39, 23 October 2022 (UTC)

yes. i would like a vote on that proposal.

you only need to post once for it to be voted on? that's amazing. Nowakki (talk) 15:35, 23 October 2022 (UTC)

Nowakki, a couple of points. Disagreeing with you is not calling you stupid. And a certain proficiency, which includes the use of capital letters, with the written English language is expected of anyone who contributes to an English-language encyclopedia. You will be taken more seriously if you demonstrate it, as you have done in your first edit here, but in few other places. Phil Bridger (talk) 18:36, 23 October 2022 (UTC)

what do you think about the proposal? Nowakki (talk) 18:44, 23 October 2022 (UTC)

First of all, please read WP:!VOTE. Secondly raising a denied and thoroughly discussed proposal again without any changes won't change anything and only hogs discussion resources. Aaron Liu (talk) 20:46, 23 October 2022 (UTC)

it's not obvious who read which forum. i posted it in the policy forum and nobody seemed to care very much.

then i reposted it here (proposals). i don't know if everyone is reading both forums or not.

i intend to post to the idea forum next.

thoroughly discussed means for example: Wikipedia:Flagged revisions

we are not even close to that. Nowakki (talk) 21:03, 23 October 2022 (UTC)

It's not true that "nobody seemed to care very much". Multiple others did care enough to respond. It's just that they opposed your idea. Your plan seems the very definition of WP:FORUMSHOPping. You're not winning support by your behavior and your proposal isn't gaining support on its merits, whatever others think they might be. DMacks (talk) 21:21, 23 October 2022 (UTC)

I didn't get it. Could someone summarize this for me? Nowakki you could also try using Google Translate. Aaron Liu (talk) 20:32, 23 October 2022 (UTC)

translate into what language? Nowakki (talk) 20:58, 23 October 2022 (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.

Block notification

Tracked in Phabricator
Task T100974

For editors who have provided an e-mail address, would it be practical to send a no-reply notification automatically if their account is blocked, either indefinitely or for a limited period? Seems to me to be a very AGF thing to do. Orange Mike | Talk 14:27, 28 October 2022 (UTC)

@Orangemike: there is not currently a mechanism to do that, so this isn't a choice we can make here on the English Wikipedia. You can follow phab:T100974 for more on the potential development of this idea. — xaosflux ^Talk 16:31, 28 October 2022 (UTC)

Warn users when adding an external link in body text in articles

A common mistake from new editors that I've been seeing is using external links within sentences in the body of articles, like this:

In March 2015 he told a newspaper that, by 2017, "we should no longer have REP in the way we do now", adding that if the Government finds it too challenging to run power lines into communities, it will use solar.

After an edit like that is done, the external link needs to refactored into a reference, like this:

In March 2015 he told a newspaper that, by 2017, "we should no longer have REP in the way we do now", adding that if the Government finds it too challenging to run power lines into communities, it will use solar."

The Visual Editor actually encourages doing this by making the functionality for adding external links be extremely prominent. It is rarely, if ever, appropriate to have external links in an article unless they are within ref tags, an External links section, or an infobox.

I propose that when someone uses the Visual Editor to add an external link to the body of an article, user subpage (e.g. a user sandbox), or draft, the software should give some sort of error message suggesting that the user add a citation to the end of the sentence instead. This error message should not come up in non-article pages (e.g. User pages), if the link is being added to a section named "External links", or if the link is being added within a template.

If there is consensus for this idea, I'll file a Phabricator ticket. Clayoquot (talk | contribs) 16:23, 28 October 2022 (UTC)

Not sure. I fear that a warning may make new users give up and not make the edit. Good faith external links in the body are a small problem and not worth potentially losing a newbie. (Also, many newbies write internal links as external ones, another easily fixed non-problem). —Kusma (talk) 18:24, 28 October 2022 (UTC)

A simpler solution may be to change the red text in the VE to a note about not adding external links to bodies?

• Enter a full URL, e.g. https://example.org (now)
• External links normally should not be placed in the body of an article (proposed)

People now that an external link needs an url. They do not know that theyre not supposed to link to external websites. More than half the time, the link is not a faulty citation, but a faulty wikilink.

If we go for a "warning" instead, we could frame it as a tip. Warnings/error messages are scary. —Femke 🐦 (talk) 18:38, 28 October 2022 (UTC)

I would support this. Seems like the best non-intrusive solution. Thebiguglyalien (talk) 20:02, 29 October 2022 (UTC)

If a user does indeed want to add a citation, I'd rather not discourage them from adding the external link, at least not without pointing them in the right direction of how to add it. I don't quite understand how you suggest to frame it as a "tip" as there as so many possible cases; my imagination only comes up with some Clippy style horror (so better not ask me to design this ). —Kusma (talk) 09:32, 30 October 2022 (UTC)

It could be similar to what we do when people link to a disambiguation page (meta:Community Wishlist Survey 2021/Warn when linking to disambiguation pages). I see that @Sdkb mentioned this very proposal on the talk page of that new feature. I can think of two cases only (citations or wikilinks), which would be feasible in a pop-up. Am I overlooking a different case?

In the long-term, what I would like to see is that new editors are guided way more by the interface to learn straightforward policies/guidelines. In that way, the first interaction they have with a human is more likely a thanks rather than a revert. Proposals like this need to be A/B tested, as they may have negative consequences. That would mean that we have to get one of the WMF teams on board (I think The Editing Team makes most sense?).

In the meantime, do think my proposal to change the text in VE may also have negative consequences? —Femke 🐦 (talk) 10:04, 30 October 2022 (UTC)

The long term plan sounds very sensible. Your proposed text only says what not to do (don't insert external links in the body!) instead of saying what to do (when you do insert one, either use a wikilink or just use a ref tag around the link and you'll make us happy for the moment), which may be bad but that would need to be researched. —Kusma (talk) 10:17, 30 October 2022 (UTC)

What about: (Option B)

• Don't add external links to the body of an article. Add a citation or a wikilink instead.

This does simplify the policy, as there are a few rare instances where it is appropriate to add external links to the body of the article. A more accurate but more verbose option would be:

(Option C).

• External links normally should not be placed in the body of an article. Add a citation or a wikilink instead.

Both alternatives should then link to the appropriate interface element in visual editor. —Femke 🐦 (talk) 10:47, 30 October 2022 (UTC)

Option B probably works. —Kusma (talk) 10:53, 30 October 2022 (UTC)

The Editing is definitely the right team for this question. How do you expect them to handle differentiate between desirable and undesirable external links, such as:

==External links==

* [https://example.com Official website]

The question of whether it would discourage citations is something that could be measured through an A/B test: give half the users the warning, and not the rest, and see if the warned users add the same or fewer links+citations. Volunteer-me was reminding someone the other day that Wikipedia:Citing sources is clear about the priority: it's better to have a badly formatted source, which any experienced editor can fix, than to not have a source. I'd consider the project to be a failure if it resulted in fewer incorrectly formatted sources because it resulted in fewer sources overall. Whatamidoing (WMF) (talk) 02:26, 1 November 2022 (UTC)

I've been thinking about the A/B testing, and the tests I've come up with are quite labour-intensive, requiring the manual classification of ~500 EL addtions. With the hesitation in this thread, I'm not quite sure it's worth the effort. Happy to expand on my ideas if you want to hear them.

I do think there is a chance this would result in a net-increase in (correct + incorrectly formatted) citations. Now, experienced editors sometimes remove ELs from bodies even if they're meant as a citation (given the fact that it's more often meant as spam or as wikilink-replacement). If the citations aren't disguised as spam, they're more likely to stay. —Femke 🐦 (talk) 20:37, 1 November 2022 (UTC)

I'm pretty sure that the mw:ORES work included semi-automated way of reviewing edits, so it would take about as long as looking through the diffs for 500 edits at Special:RecentChanges. Two hours work, maybe? Whatamidoing (WMF) (talk) 18:56, 4 November 2022 (UTC)

What if there were two buttons: to insert as a link and to insert as a reference, like this? — Alexis Jazz (talk or ping me) 17:58, 30 October 2022 (UTC)

Thanks everyone. So after reflecting on the comments, I don't think my idea of having a warning was a good idea. WhatamIdoing's comment reminded me that any edit that says what the source is is way way better than an unsourced edit. So we should aim for as little friction as possible in the process of submitting an edit.

Regarding the idea of changing the text in the dialog box, I'm wary of doing that. The current field label

Enter a full URL, e.g. https://example.org seems useful. Adding advisory text to dialog boxes creates clutter and slows down all users of the dialog box, not just the people who would otherwise make the particular error that we have in mind. And I'd like to avoid jargon such as "body text". I don't think Alexis Jazz's proposal would solve this particular problem since this is a case where the user intends to add an external link rather than a citation, but do I like their general approach of trying to prevent errors.

Perhaps a better solution would be a semi-automated editing tool that makes it easier to clean up this problem. Clayoquot (talk | contribs) 14:48, 1 November 2022 (UTC)

@Clayoquot, User:Novem Linguae/Scripts/DraftCleaner.js converts external links to references (amongst the other cleanup it does). — Qwerfjkltalk 17:06, 1 November 2022 (UTC)

Clayoquot, I don't think Alexis Jazz's proposal would solve this particular problem since this is a case where the user intends to add an external link rather than a citation, but do I like their general approach of trying to prevent errors. The idea would be that the user intends to do that and while on that path is given a choice: actual link, or reference. Because it seems the problem currently happens before this point: the user picked the "link" button over the "cite" button. I guess (but no idea really) that new users don't associate "cite" with "links", especially given that right next to the "cite" button there's a "link" button which indicates the cite button isn't for links. Why don't we combine those buttons? — Alexis Jazz (talk or ping me) 19:38, 1 November 2022 (UTC)

I think that would increase the error rate. To get to the external links, users in VE now have to click twice. First on link, and then on external link. For cites, it's accessible via a single click. The Factotum script makes the distance to add link and add reference smaller, which may give the impression (to new users) that they're equally valid actions. Which is untrue for adding ELs to articles. —Femke 🐦 (talk) 20:33, 1 November 2022 (UTC)

Femke, it makes the distance for wikilinks, external links and references equal. I'd hesitate to say either of those is less equally valid than the other, it depends on the context. They all have their uses. Is it really a good idea to Increase distance to discourage using certain features? — Alexis Jazz (talk or ping me) 20:55, 1 November 2022 (UTC)

Oh yes. Not for the experienced users of Factotum, but for new users who almost always do the wrong thing with external links. We should not invite them to make mistakes, and be welcomed with a revert. —Femke 🐦 (talk) 21:15, 1 November 2022 (UTC)

References

RfC for proposal at MINREF

The proposal at Wikipedia_talk:Inline_citation#Alternate_proposal_for_valid_challenges is requesting users to make a decision about their vote regarding the differences between content removal related to missing citations, and the ordinary removal of content not related to missing citations, and if we should clarify that difference. Your participation is appreciated. Huggums537 (talk) 20:44, 7 November 2022 (UTC)

Dab page link highlight

I have enabled (in my Preferences) the gadget Display links to disambiguation pages in orange. Very helpful for editing, but the color is too close to red (for my eyes). Could such links be bolded as well, to make them stand out among the redlinks, which are a less egregious problem. Doug butler (talk) 04:32, 6 November 2022 (UTC)

• @Doug butler, add
  

  a.mw-disambig { font-weight: bold; }
  

  to Special:MyPage/common.css — Qwerfjkltalk 08:43, 6 November 2022 (UTC)

@Qwerfjkl Many thanks for the tip, so clearly presented. I had absolutely no idea what I was doing but created User:Doug butler/common.css and pasted your text. Including a check in the sandbox took less than a minute. I should have learned JavaScript back when I had a few neurons :) Doug butler (talk) 11:17, 6 November 2022 (UTC)

I have had a gadget for a long time (I forget where I got it, even) that highlights disambiguation page in yellow, makes links to pages nominated for deletion magenta, and various other color codings like that. BD2412 T 22:54, 6 November 2022 (UTC)

I believe this is it:

 importScript('User:Anomie/linkclassifier.js'); // Linkback: [[User:Anomie/linkclassifier.js]]
 importStylesheet('User:Anomie/linkclassifier.css'); // Linkback: [[User:Anomie/linkclassifier.css]]
 

BD2412 T 22:56, 6 November 2022 (UTC)

Sounds great but I have trouble finding ripe strawberries :) Doug butler (talk) 21:27, 7 November 2022 (UTC)

@Italic 163.44.197.123 (talk) 05:18, 8 November 2022 (UTC)

Proposal: Mark retired editors

Moved to Wikipedia:Village pump (idea lab)

— xaosflux ^Talk 16:32, 8 November 2022 (UTC)

undirecting certain John Mellencamp singles

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

---

There are many John Mellencamp singles to need to undirected to create their own separate articles. Also,some other John Mellencamp singles do NOT have Wikipedia pages. His singles are notable. Talk — Preceding unsigned comment added by TimCougar (talk • contribs) 01:33, 31 October 2022 (UTC)

@TimCougar You don't need to make a proposal like this here. If you think a single meets the criteria of WP:NSINGLE then go ahead, remove the redirect and create a free-standing article about the single. Nthep (talk) 20:21, 31 October 2022 (UTC)

Sorry about that. TimCougar (talk) 10:58, 1 November 2022 (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.

Proposal to make WP:LONGDAB a guideline

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Wikipedia talk:Organizing disambiguation pages by subject area#RfC: make this page a guideline

This is a proposal to elevate an essay to guideline status; there's also a more specific suggestion to merge it into MOS:DAB.  — SMcCandlish ☏ ¢ 😼  20:55, 10 November 2022 (UTC)

Extended-confirmed protection for TFAs

Recently many TFAs are extended-confirmed locked because of vandalism caused by auto-confirmed accounts. It seems that there's someone that is dedicated enough to intentionally lock these articles up, seemingly just because they can. Evidence: Megalograptus, Borodino-class battlecruiser, Sayfo, Second Punic War (4 most recent TFAs), and more.

Is it by any means possible for the TFA protector bot to ECP FAs pre-emptively? Magnatyrannus (talk | contribs) 01:50, 22 October 2022 (UTC)

Replying so that this thread doesn't get archived... Magnatyrannus (talk | contribs) 01:35, 31 October 2022 (UTC)

I would be hesitant to preemptively protect these as they often see productive editing when not protected due to vandalism. ScottishFinnishRadish (talk) 01:39, 31 October 2022 (UTC)

I'll try to look into the specifics of what prompted this in a bit. From a technical perspective it is certainly possible but probably unwise, admitting I'm generally in favor of allowing new and unregistered users to edit unless there is very good reason not to. 74.73.224.126 (talk) 23:00, 7 November 2022 (UTC)

Well, it depends on whether most of the constructive edits on such TFAs are from Extended-confirmed users or auto-confirmed or non-registered users. --Magnatyrannus (talk | contribs) 23:17, 7 November 2022 (UTC)

That's a fair point, and we could do some analysis grouping TFA editors into those with 0-9, 10-499, and 500+ edits. That aside, the numbers game isn't really the best way to look at this. Reverts are cheap, error checking is not. It takes far less time to revert a dozen disruptive edits than to go over even a single mid-sized section for issues, so I'm willing to deal with a fair amount of random disruption to get those adventitious catches by new and unregistered users that were not spotted during review. I will admit that when dealing with determined LTAs semi, and even ECP may be the only way to control disruption, which is why I need to look over the histories you referenced when I have some time. 74.73.224.126 (talk) 23:53, 7 November 2022 (UTC)

I looked this over earlier. I can understand why you made this suggestion, and there are clearly one or more LTAs periodically conducting sustained vandalism on TFAs, but it's not continuous (from spot checking going back 6 months), and the page is pretty closely monitored. Now, sometimes bad edits have stayed live for 10-15 minutes, but that's usually the result of novice autoconfirmed editors breaking templates/formatting due to not understanding how they work; once autoconfirmed an accounts edits are less likely to be flagged for review by the tools RCPs use which explains the lag.

Obviously we want to leave oversightable content up for the least time practical (true everywhere), but using preemptive ECP or even semi, is a rather blunt solution, using a sledgehammer to crack a nut if you will.

I am open to adding adding a note, somewhat similar to the TFA 3RR exception, that allows sysops considerable leeway in applying either semi or ECP to TFA, even preemptively, but also encourages the use of judgement and cautions against protecting casually, and yes that would need a lot of wordsmithing.

If an LTA has added oversightable content to a page a few days in a row then it may make sense to apply preemptive ECP for a short time, just don't publicly say how long or they'll wait it out, so they get discouraged and move onto something else. Another related tactic is to apply protection for the full day when disruption starts then later manually remove at an unpredictable time so the LTA isn't waiting to jump back on and disrupt again.

In the past we have had even worse LTAs attack TFA and protection was applied preemptively (essentially per IAR) without too much of a fuss, but only for a limited period of time. There's also a few LTAs that have made it their mission to force us to protect as many pages as possible because they despise our open nature, and I really don't want to let them have their way.

I also think that people exaggerate the effect of vandalism on the reputations of individual articles or Wikipedia as a whole. Wikipedia vandalism is an internet meme, everyone knows about it, and recognizes what it is. Some may even become involved in editing for the first time by reverting or removing it I did, a long time ago. What really harms our reputation are non-obvious errors, especially if they propagate and are later traced back to us. I saw a random IP fix a subtle category error on a TFA a few weeks back that had eluded all review; I'm willing to press the undo button a lot of times to get those kind of fixes.

Anyway I'm willing to hear you out if you have any ideas. I'll be on Wikibreak again for a few weeks, or maybe a few months starting sometime tomorrow. But even if this archives you're always welcome to leave a message on my talk page. 74.73.224.126 (talk) 23:15, 10 November 2022 (UTC)

Enable features by default

There are three features which it might be best to enable by default for new users. First, automatically adding any page that you edit to your watchlist. That didn't happen for me until I changed my settings. Secondly, an edit button specifically for the introduction of an article. Third, having the diff display, with additions highlighted and deletions crossed out, whenever you run your cursor over a link to a diff. Is there any downside to enabling these features by default? DefThree (talk) 20:03, 11 November 2022 (UTC)

@Hi DefThree; regarding #1, that ended up getting turned off on purpose as it was causing some issues with extremely large watch lists. The second is available in gadgets under Add an [edit] link for the lead section of a page. We don't like to push too many "gadgets" to default, but there is an outstanding software request for this (phab:T2156) that you can follow up on. The "navigation popups" gadget does provide what you are asking for third already as well (same that it is not default, as another navigation popup is already). The default popup tool is called "Popups" (a/k/a "Page Previews" and you can request features be added to that using this form. — xaosflux ^Talk 00:24, 12 November 2022 (UTC)

Automatically added pages to watchlist isn't an appropriate default. It's a disaster if you edit large numbers of pages, and most people don't want to watch every page where they make a passing or minor edit. Alsee (talk) 08:23, 18 November 2022 (UTC)

National Froggy Day

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.

---

national froggy day is now on September 19th. celebrate the froggy 205.137.37.23 (talk) 13:42, 17 November 2022 (UTC)

Man, we missed it by 2 months. 🐸 ~ ONUnicorn^{(Talk|Contribs)}problem solving 13:44, 17 November 2022 (UTC)

On a more serious note, Do you have a source for September 19 being National Froggy day? It seems to be International Talk Like a Pirate Day, but not National Froggy Day. I see that March 20 is World Frog Day (although we don't seem to have an article about World Frog Day - but we do for World Sparrow Day on the same date). October 21 seems to be American Frog Day (also no article in our encyclopedia, sadly). And apparently, April 28 is Save The Frogs day, which we also don't have an article about. Then of course there is May 13, which is National Frog Jumping Day. So, plenty of opportunities to celebrate the froggy, but none on September 19 as far as I can tell. But also, plenty of opportunities to expand Wikipedia's coverage of froggy related festivities. ~ ONUnicorn^{(Talk|Contribs)}problem solving 15:05, 17 November 2022 (UTC)

Whenever Froggy Day is this young lady is ready for it :-) MarnetteD|Talk 15:12, 17 November 2022 (UTC)

Are we sure that it isn't a celebration of this "Froggy"? --User:Khajidha (talk) (contributions) 15:38, 17 November 2022 (UTC)

• Strong support. Thebiguglyalien (talk) 01:10, 18 November 2022 (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.

Moved the Draft:Sari Katha Article in mainspace.

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

---

I request to your team.plese,move to draft Article on mainspace it is ready to mainspace. Golmala (talk) 14:17, 22 November 2022 (UTC)

This isn't the place for such a request. You need to submit the draft for review. - David Biddulph (talk) 14:20, 22 November 2022 (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.

discussion at Template talk:High-use

Please see Template talk:High-use § Different wording?.

—Trappist the monk (talk) 14:44, 24 November 2022 (UTC)

Signpost to top active 100 k 20 k editors (non admin)- counter WMF

This is in the formulation stage, so no support or oppose is required yet, Reworded twice on 26/11/2022 AEST

1. WMF problems : WMF have argued in the past that The Village pump editors only represent a few grouchy enWP editors, rather than active Editors, The current RfC has had similar questions. WMF and WP will always be in conflict and have different interests, and WP is not congruent with WMFs hierarchial management, non-measurement, and centralised system architecture.
2. Editor Retention  : Strong communities need effective communication. Our community is becoming less strong, as editors and admins are declining, off-wiki communication is increasing, and personally there seems to be a lot more undisclosed coi.
3. WMF is the main communication for Wikis, and for most editors via media release (which are targeted towards donors and prestige, WMF Editor retention work is focused on critiques of the community, rather than emphasising strengths.

What makes a strong Community? Sense_of_community#Four_elements_of_sense_of_community

1. Membership (boundaries, emotional safety, a sense of belonging and identification, personal investment, and a common symbol system)
2. Influence "Influence works both ways: members need to feel that they have some influence in the group, and some influence by the group on its members is needed for group cohesion."
3. Integration and fulfillment of needs
4. Members feel rewarded - "it includes shared history and shared participation"

These are all based on successful communication

Communication : The internet as an analogy for Wikipedia Editor communication Malcolm Gladwell discussed in The Tipping Point, that social networks (not big tech ones) are similar to computer networks; an need people who act as "connectors" of network hubs linking diverse groups, and Mavens (who are specialists in various areas), and persuaders who help reach consensus,

• Mavens - Concetrated on Village, AfD, ANI, NPP, Women in Red,. composed totally of Mavens
• Connectors that link multiple areas/projects - Some editors, and the suggestion is Signpost
• Persuaders/Enthusiasts - here and there
• network hubs - We have transient nodes on articles (self-organised by watchlists, but with incomplete coverage of all articles), projects (but most are inactive) and don't have good tools to see. Overall with most talk we woul be better off hving a forrum that writes to wikie
• Cenral hubs - WMF are currently filling this role
• packet success rates - Successful new articles (not AfD, not NPP) (20 %??), templates acted on (close to zero), and Talk page topics about 10%
• network type - Wikipedia is a partly decentralised network with many missing connections (if an editor adds a talk on stub then they will get no answer, there is low social/human connectivity (human to human interactions through talk pages) for most editors (effective organisations run at about 25 % I think,) WMF is a fundamentally incompatable with WP, as it a cenrralised organisation, with very poor connection with WP and between departments, and a total mismatch of goals. The geographic spread is not actually decentralisation of power, but is more about status/PR/donations and diffusion of responsibility and possible opposition.

A newsletter for editors, is a first step towards becoming a distributed network with better communication which is not dependant on WMF, and will increase up retention Seven_Ages_of_Wikipedians. Proposal ' ''We address the "unrepresentative" by sending the top 100k current editors (excluding current admins and subscribers) a Special Banner Complaint Edition, with a link allowing them to add their names to support, oppose, neutral pages, of Signpost and an option to unsubscribe. It is unasked for, but we need to increase community, to fix a number of issues caused by WMF neglect. '

Prior Discussions I have raised this idea on idea labs previously [1] and 2. Wakelamp d[@-@]b (talk) 12:41, 23 November 2022 (UTC) Wakelamp d[@-@]b (talk) 15:07, 25 November 2022 (UTC)

• IMHO, I don't think that will solve the problem: most of those top 100k current editors either aren't informed on the matter, or don't have an opinion about it. Most of the changes on Wikipedia (& the other projects, such as Wikisource, Commons, & so forth) are done by a minority of volunteers devoted to that one portion: writing content, managing NPP, managing AfD, etc. Not the same minority -- just to be clear -- but different minorities, who are usually informed about the topic. The problem is that when a group active on Wikipedia (or one of the other projects) addresses the Foundation about an issue, the Foundation's response is to dismiss their concerns out of hand as the complaints of a grouchy minority who do not represent the entire community. While this is sometimes the case, far more often it is a legitimate concern that needs to be acknowledged & taken seriously -- which often does not happen.

  Of course this is just my opinion, YMMV & all that, but it is based on roughly 20 years of watching how events unfold here. -- llywrch (talk) 18:59, 23 November 2022 (UTC)

  @Llywrch "I don't think that will solve the problem: most of those top 100k current editors either aren't informed on the matter, or don't have an opinion about it. " A WP editors having no opinion - where is this legendary beast?  : -). On banners for instance, editing on Android (I don't turn banners off) is particularly galling as there are two screens of nags.

  WP's success is based on the self organisating sub-groups that you mention, but people need to be part of a community, and WP need new editors NPOV is not eternal or universal - there are newer references, and communities change. Wakelamp d[@-@]b (talk) 05:07, 24 November 2022 (UTC)

This isn't a good idea. It goes against what the user talk page is for, that being to discuss information relevant to a user. Since it would be impossible to gather a list of 100k people who care about a certain topic then the more approprate style of notification would be a watchlist message or something. Terasail^[✉️] 03:52, 24 November 2022 (UTC)

What I am trying to say is that MMS removes the choice of a user to participate or not in a specific area since they would get a notification of the new messsage (and likeley and email to accompany it) which ins't ideal. Some people just want to correct spelling mistakes and not get bothered by wiki politics... Terasail^[✉️] 03:55, 24 November 2022 (UTC)

Good point about the email, Can you override prefeences and not send email notification for a message?

With the "just doing spelling editor" example , would you be happy if they were sent the newsletter, but not have it related to the current problems with WMF? The rough cost/benefits look good.

• Benefits - 130 k editor hours (52 years) .
• Costs - 1.7 K hours (0.7 year)

Note : Benefit (hours) = 2.5 h/w*52 w/y*100 k editors * 0.01 staying an extra year. Benefits (year) = Benefits (hrs)/2500hrs/year (Assumes 2500 hours/year ( 40 hour/week for 52 weeks/year))

Benefit Assumptions - 1 % of editors that receive the newsletter, decide to edit for a year longer (using the clickthrough rate for emails to existing customers as a guide), The median hours spent on WP for the 100 K is I think 2.5 hours/week.

Cost Assumptions - 1 minute per unwanted email No editors leaves after receiving emails ( based on the loss of customers after receiving one email to a company they did business with) Wakelamp d[@-@]b (talk) 06:43, 24 November 2022 (UTC)

• What kind of proposals do you want to include in this newsletter? Is it everything discussed at Village pump or every formal RfC? Will it be a monthly newsletter or is it sent out only for wide reaching RfCs? I think sending a newsletter with a link allowing them to add their names to support, oppose, neutral pages to 100k editors will make things less like discussions and more like voting, which is not how consensus is formed in Wikipedia. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 07:07, 24 November 2022 (UTC)

Generally agreed with @ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ and Llywrch: I don't think this would be helpful here. Also, in contrast to some past incidents, I don't think many people believe this past discussion 'only represents a few grouchy enWP editors'; the WMF has lately been taking feedback like this and the Open Letter on Commons seriously and addressing the underlying issues [rather than the emotion of the most frustrated participants]. – SJ + 18:49, 24 November 2022 (UTC)

Thank-you both for your feedback. I have reworded the proposal, including clarifiing that the newsletter is Wikipedia Signpost, and removed the widespread consensus option (as I agree that WMF seem to be engaging, and will change the letter, and then spend a few million on a wide spread community consultation). I think the Current RfCs have enough participants, but it often seems to get lost in the middle,. There are a lot more probles with WMF - the mission, internal disfunction, and no WP IT strategy I do have high hopes for the new IT director, - but they has to cope with 7 different IT areas, and an enormous amount of vanity and "mission" related projects. Wakelamp d[@-@]b (talk) 15:07, 25 November 2022 (UTC)

Naming convention for treaties

Where there is a need to differentiate between treaties that share names using the year signed, it appears many articles use the following format in their titles: Treaty of title (year signed). I believe this is bad formatting.

Examples where this is used this include:

• Treaty of the Creek Agency (1818)
• Treaty of Fort Laramie (1851)
• Treaty of Fort Laramie (1868)

I propose using a convention similar to election articles by listing the year before the title.

I propose that treaty articles titles should instead look like the one I used at 1833 Treaty of Chicago.

I propose renaming all treaty articles using the convention of listing the year in parentheses after the title.

Thoughts? SecretName101 (talk) 19:45, 26 November 2022 (UTC)

Why? Phil Bridger (talk) 20:32, 26 November 2022 (UTC)

I'd use the natural language title: either the formal title of the document or the way it is most commonly referred, either at the time or since. So, Fort Laramie Treaty of 1851 but Treaty of Fort Laramie (1868). Looking at the List of treaties between the Potawatomi and the United States, the two treaties of Chicago stick out; I would revert to their contemporary names (with qualifiers where disambiguation is needed). – SJ + 03:49, 27 November 2022 (UTC)

I agree with @Sj's opinion. That order also matches a government style manual. I think it's bettet as treaties are often mentioned without a year,, and the date is less important then the dtreaty name.

Is the purpose of having the year first to be do with search or sort order? Would addional categories (although categories on treaties can be very long with UN treaties) or redirects help?

Wakelamp d[@-@]b (talk) 07:08, 27 November 2022 (UTC)

Wikipedia policy is to name an article as what its subject is usually called in English. This can then be disambiguated with something in parentheses. Both Treaties of Utrecht are commonly called "Treaty of Utrecht", so we have articles Treaty of Utrecht and Treaty of Utrecht (1474). Sources don't call them "1713 Treaty of Utrecht" or "1474 Treaty of Utrecht", and so we don't use those as titles. Maproom (talk) 21:04, 27 November 2022 (UTC)

Do not mark popular vote winners or list popular vote changes in staggered term legislative elections for chambers where not all geographies get to vote at once

I have had an issue with these listings, most notably when it comes to US Senate elections (where while there are 50 states, only 33 or 34 are up regularly at each cycle). This also applies to elections for a number of US State Legislatives chambers, and possibly some other chambers at the international level. I went over the issue in detail here, but not once has anyone replied to me, and I feel like the issue needs to be discussed thoroughly. The crux of the issue is that you are essentially comparing apples to oranges when you compare such nationally aggregated vote totals. The core of the case is that the classes of 33 or 34 US Senate seats regularly up each cycle are not at all equal in partisanship, so in many cases, the party that nominally recieved more votes nationally, or the vote percentage swing from one cycle to the next can very well be an artifact of which geographies are up. In the context of the US Senate, based on modern US political party coalitions this means that class 1 and class 3 elections are both going to produce national vote totals that are more Democratic than they should be if you simply add up each parties votes across each race in the seats that were up without making any adjustment, while class 2 elections are going to have the opposite issue of being more Republican. Regarding the 2020 US Senate elections page, some editors want to highlight vote data showing Republicans winning more votes than Democrats nationally, and to include a swing metric showing a shift of over 20 points in voter preference from the 2018 elections (part of which is an artifact of the issue I described, another part an artifact of uncontested races, most notably with regard to the lack of a Republican on the 2018 general election ballot in California due to the top 2 blanket primary system, with only between 6 and 7 points of it being a real result of voter preferences changing). I can tolerate it if people wish to not use estimates for elections that never happened in the way I did to arrive at my numbers when totalling data on wikipedia, but if we avoid doing that, we still need to be honest about the fact that the nominal totals have flaws as I have described. MappedTables (talk) 05:26, 14 November 2022 (UTC)

I agree with you that this comparison is not encyclopedic for US Senate seats where there is a more or less random sorting into three groups and it should be obvious that random sorting of 100 seats into three groups results in groups that have different characteristics. If it was 1000 seats, it probably would not be much of a problem. This is reflected in reality. I have been closely following US elections since 1972, and every cycle, I hear analysts saying long before the election, "The Senate prospects for Party A are better this year than for Party B". On the other hand, similar comparisons for the US House of Representatives are valid, since every seat is won or lost in every election cycle. If reliable sources report that Party A won 55% of the seats but only won 45% of the cumulative popular vote, then that is encyclopedic content that sheds light on gerrymandering and democracy. Cullen328 (talk) 06:03, 14 November 2022 (UTC)

I've noticed this as well, and I think you're correct. It's misleading to add up the popular votes of each election in cases like this. Thebiguglyalien (talk) 13:17, 14 November 2022 (UTC)

We are supposed to summarize what the preponderance of reliable sources say. If a preponderance of reliable sources make such comparisons, we include them, but should neither overemphasize nor underemphasize such analysis. - Donald Albury 16:02, 14 November 2022 (UTC)

I side against this recommendation overall.

In the case of U.S. Senate elections, I disagree completely. This could actually mislead in another way. Since states are awarded senators without any proportion to population, without the context of popular vote, a seat swing could be wrongly thought to represent that the vast majority that voted for Senate in a cycle "must have heavily supported that party". Think that the vote count is representative of the cumulative will of the states that participated. There are cases where that would be GROSSLY WRONG: for instance, the 2018 U.S. Senate election.

I'll concede, removing that info from infoboxes is not without complete merit. It could mislead those not understanding context in one way. But, in the case of U.S. Senate, removing it misleads in another way. Also, some of other things that will likely be the norm in election articles do mislead without understood context. For instance: result maps. We will probably always be adhering to the popular practice of use maps representative of geography rather than either maps giving equal size to all constituencies or maps representing constituencies in sizes that are proportional to their population.

Perhaps remove it from infoboxes of elections such as Illinois' state senate in years they stagger the seats. But even then, not critically necessary.

If we do remove this info from inboxes, it should still be included somewhere in articles. This is factual information useful to some that some people will be looking for. We shouldn't make it impossible to find it on this project. SecretName101 (talk) 21:06, 15 November 2022 (UTC)

It seems like you are misunderstanding what I am saying with regard to popular vote totals. I am only asking for the swings to be outright removed. With regard to the popular vote totals, I am calling for winners to not be marked in bold text like this, not for those to be removed as well. MappedTables (talk) 00:45, 16 November 2022 (UTC)

Okay, I better understand now SecretName101 (talk) 15:36, 16 November 2022 (UTC)

As the classes are stable, shouldn't the 6 year cycles be compared? It's won't be apples to apples as the Presidential will only be in every other iteration, but more accurate than comparing 2 year cycles. Slywriter (talk) 00:50, 16 November 2022 (UTC)

Comparing the 2022 Senate votes to those of 2018 is also very inaccurate. Did the Corona crisis affect the vote patterns? Possibly, but no way to know for certain. Nor can we know if the assault on the Capitol in 2021, purportedly triggered by Trump; Biden's policies as president; or the Russian attack on Ukraine - if any of these may have had major changes on voter opinions. Animal lover |666| 12:17, 16 November 2022 (UTC)

I think you mean 2016 to 2018. That'd be a six-year difference.

"These things may have motivated a change in turnout between these cycles" does not make sense to me as a reason to avoid indicating changes. SecretName101 (talk) 15:38, 16 November 2022 (UTC)

I see nothing persuasive about picking two arbitrary events to say 2 year periods make sense. National turnout is influenced by serveral independent statutory factors (and other less definable ones that are beyond scope): 6 year Senate terms, 4 year Presidential terms, vacant Senate seats, Governor's election and incumbency of the Presidency. Class I will be in 2024 with a Presidential, 2030 without a Presidential. They may or may not also have Governor's race in their state during one of those.

Tl;Dr Given numerous variables and arbitrary ways to compare by Class at least comes closer to apples to apples. Slywriter (talk) 16:00, 16 November 2022 (UTC)

There is a similar issue with UK by-elections ("special elections" as you'd call them) where comparisons can't be made like-for-like. The only statistically correct comparison is from one general election to the next The only way to compare accurately is from the election where Group X were last elected, term-for-term, like-for-like. doktorb _words^deeds 12:21, 16 November 2022 (UTC)

Any actual change is statistically correct. It will not illustrate the full picture of underlying reasons for changes in turnout, but it most certainly cannot be called statistically incorrect. SecretName101 (talk) 16:26, 16 November 2022 (UTC)

I disagree to a point. Yes, comparing last year with this year provides numbers to crunch and conclusions to be made. But for term-for-term, like-for-like comparison, to indicate exactly how a specific candidate or party has gone on after a full electoral cycle, the comparison has to be from the previous election *of that cycle*. doktorb _words^deeds 17:26, 16 November 2022 (UTC)

• Oppose Change While I agree with this proposal purely on the merit, I think that if the popular vote of a particular election with this issue is widely reported in notable sources, it's our responsibility to report the data, and let people use it how they may. Us ignoring it treads too much on WP:NOR for my liking, even though, again, I fundamentally agree with you. By the same token, I don't think we should stretch to include the popular vote for an election format that has this issue if the popular vote is not widely reported.

CoffeeCrumbs (talk) 14:35, 24 November 2022 (UTC)

I agree with you. I think we should keep the popular vote part but remove the swing part because comparing senate elections of different states is, as the op said, comparing apples to oranges. —CX Zoom[he/him] ^{(let's talk • {C•X})} 15:04, 29 November 2022 (UTC)

User:BeenAroundAWhile user subpages

User:BeenAroundAWhile passed away earlier this year. I note that he left behind over two dozen subpages in his user space. Some of these he had blanked, as was his prerogative. Some contain what appear to be drafts or revisions of either existing articles (including multiple pages with content on the Veiled Prophet Parade and Ball) or planned articles. Someone should go through these more thoroughly to see if there is anything of use to the encyclopedia. Cheers! BD2412 T 20:42, 29 November 2022 (UTC)

Establishing a guideline outline preferred dimensions (aspect ratio) for images in the inboxes for biographies and elections

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.

---

Correct me if I am wrong, but there does not appear to be either a guideline or official policy outlining what the preferred dimensions for images in inboxes for biographies and elections.

I believe that there should be an agreed-upon preferred aspect ratio. Particularly to avoid disputes over the dimensions/crops that should be used in infoboxes. I also beleive these dimensions should be 3x4, though I'll delve into my arguments for that later.

The main reason I believe there should an agreed-upon recommended dimension for infobox images of biographies is consistency between articles. It is aesthetically displeasing to avoid vast variance in what dimensions are used in biography infoboxes. It helps create a more standardized identity for this project if there is constistency. Furthermore, it is particularly displeasing in biographies of officeholders for there to be variance in dimensions. When readers are navigating between predecessors and successors using infobox links, it looks best if the images in both articles' inboxes have the same dimensions.

One reason that I believe this should be the case for election articles is also for consistency between difference election articles. A second reason is that I believe that the images of different candidates in election boxes ideally should be of identical aspect ratio. It looks sloppy when they are different dimensions. Guidance in what dimensions to use would be useful in cropping the images of candidates to match each other. Additionally, when navigating using infobox links between preceding/subsequent elections, it looks sloppy when there is a noticeable variance between articles in the aspect ratio of images used for candidates. Again, a more consistent style creates a better identity for our project.

Now on the case for the recommended dimensions to be 3x4:

• These dimensions are aestheticly pleasing in inboxes. I believe it falls perfectly in a Goldilocks zone of not being overly tall nor overly wide.
• This crop maintains a common convention of portraits being greater in height than in width, and does so without making the portrait overly tall.
• These dimensions are easy to remember, and are therefore easy to input into the CropTool. Any crop dimension using decimals instead of whole numbers would be less intuitive/user-friendly when utilizing the "custom" aspect ratio tool in the CropTool for this reason.
• The dimensions have proven to be broadly accepted on this project. They have been applied in a plethora of election articles and biographic articles, which demonstrates a lack of community objection to how this aspect ratio looks. THOUSANDS of biographic and election articles are making use of this aspect ratio for their illustrating images, and have for years. I have never seen images in this aspect ratio removed for objections to the aspect ratio.

I will note, that I myself have made extensive use of this aspect ratio in both biographies and election inboxes, and have seen others do so as well. I am not sure how widely it was already being used by other editors before me as an unofficial style policy, but images of aspect ratios that at least resemble 3x4 were in good use as long as I can remember, particularly in election articles. 3x4 aspect ratio images are now very common for these uses, regardless of when they were popularized. I would like to see this be affirmed as best practice.
Moved from the Policy village pump

SecretName101 (talk) 17:19, 15 November 2022 (UTC)

If I came across someone cropping previously-chosen images for infoboxes (or anywhere else for that matter) just to suit a 'preferred aspect ratio', I'd report them for vandalism. AndyTheGrump (talk) 01:59, 16 November 2022 (UTC)

Most infobox images are on low-trafficked pages and not “selected” via any discussed consensus to begin with. If you thought someone did a bad job cropping an image, you could create an alternate crop with the crop tool and insert it yourself.

on pages where discussion would arise, various crops could be created and a preferred crop could be selected. Often, cropping infobox portraits to 3x4 only eliminates unneeded background space or parts of a lower torso in the least-extreme crops. SecretName101 (talk) 03:20, 16 November 2022 (UTC)

Also, that seems like a gross misunderstanding of what constitutes Wikipedia:Vandalism. But I'll let that slide from this discussion. SecretName101 (talk) 03:30, 16 November 2022 (UTC)

This image [5] doesn't conform to your preferred 3*4 aspect ratio. Are you going to take the excess off the top, the bottom, or a bit of both? AndyTheGrump (talk) 03:43, 16 November 2022 (UTC)

That is a strawman argument. Since I am proposing a guideline that only would apply to infoboxes of articles that are biographies (especially of officeholders) or articles that focus on an election.

That is an artwork. On a page where the central topic is the piece of artwork itself, any artwork should clearly be presented in its original aspect ratio. SecretName101 (talk) 03:54, 16 November 2022 (UTC)

Also, I am proposing this be a guideline, not a rule. Thereby allowing for reasonable exception should need arise. SecretName101 (talk) 03:56, 16 November 2022 (UTC)

Aesthetics applies everywhere. Portrait photography, and the cropping of photographs, is art. At least, it should be. Imposition of arbitrary numeric restraints on aesthetic choice is morally unjustifiable, and Wikipedia should have no part in such facile authoritarianism. Leave that to the book-burners... AndyTheGrump (talk) 04:02, 16 November 2022 (UTC)

.....okkkayyyyy.....

That is absurdly extreme.

The idea of identifying recommended style standards to areas of an encyclopedic project (we have many such standards already) being likened to authoritarianism and being called "morally unjustifiable". This is the most absurd thing I have seen today. I truly hope you are not serious and are just being a provocateur.

You just took a literally modest proposal and acted as though it was proposing an idiomatic modest proposal (see: A Modest Proposal if you do not know the origin of the idiom). SecretName101 (talk) 04:08, 16 November 2022 (UTC)

There is nothing 'modest' about your proposal to hack lumps out of images just to conform with your own arbitrary preferred aspect ratio. The proposal is absurd. It is extreme. It is obnoxious. It is contrary to the spirit of Wikipedia. We reflect the world (including its portrait photographers). We don't impose our will on it. And yes, I am familiar with Swift. And Orwell. I'd recommend reading the latter - though take note that his most famous work wasn't written as an instruction manual. AndyTheGrump (talk) 04:21, 16 November 2022 (UTC)

Good f-ing lord, that is obscene. Publications regularly crop images. Wikipedia already regularly crops and adjusts images. Even sometimes adjusting more than just aspect (color correcting, adjusting exposure etc.)

There is no Orwellian censorship in formatting images that have fallen under licenses that permit derivative works (such as cropped versions). And there is no violation of the will of photographers that have released public-domain licensed work. They have released their images in such a manner that permits cropped versions to be distributed. SecretName101 (talk) 04:30, 16 November 2022 (UTC)

If people are 'adjusting images' for legitimate reasons, fine. Your reason isn't legitimate. It is arbitrary, authoritarian, and idiotic. Or it would be if anyone took it seriously. Which thankfully doesn't appear to be happening. Most of us can live without trying to impose integer ratios on the universe. AndyTheGrump (talk) 05:18, 16 November 2022 (UTC)

Can you stop accusing me authoritarianism. Either you lack an understanding of what I have outlined, you lack understanding of authoritarianism, or you are launching an ad-hominem attack on me in violation of policy.

Creating a recommended standard via consensus cannot reasonably be called "authoritarianism", so I am advising you this is a likely ad hominem attack and asking you to cease that behavior immediately. Particularly in light of your history of expressed antipathy and discourteous attitudes towards me. SecretName101 (talk) 06:05, 16 November 2022 (UTC)

I see no evidence of 'consensus'. Instead I see a single individual proposing arbitrary restraints on the aspect ration of images for no better reason than that particular individual finds the use of other aspect ratios displeasing. As for our 'history', remind us again what the outcome of that interaction was, and what the 'consensus' resulted in... AndyTheGrump (talk) 06:12, 16 November 2022 (UTC)

I am requesting consensus HERE. That's the whole purpose of proposing something here.

I suspect that the whole purpose of your nonsense here might be to flood this discussion with an obscene length of tirades so that others will see it and go "too long, won't read". Due to the extended length you are contributing with distracting tirades, I believe it is most useful to collapse part of this chat per Wikipedia:Refactoring talk pages SecretName101 (talk) 06:20, 16 November 2022 (UTC)

I have collapsed a back and forth with User:AndyTheGrump that was "otherwise distracting material" and have done this for the purposes of "improving the clarity and readability" of this discussion per Wikipedia:Refactoring talk pages. Any other discussion can continue below, but the same discussion should be continued within between the collapsed templates. SecretName101 (talk) 06:24, 16 November 2022 (UTC)

And I have reverted your grossly improper attempts to hide my objections to your proposal. AndyTheGrump (talk) 06:27, 16 November 2022 (UTC)

Will admin(s) please help determine whether it is appropriate as in this edit or in this edit apply Wikipedia:Refactoring talk pages to AndyTheGrump's lengthy contributions here. Leaving it as is is to the detriment of clarity and readability. I believe it constitutes "otherwise distracting material" and borders on off-topic. I believe resectioning, as in the second edit, is well justified due to the length of this divergent tangent. SecretName101 (talk) 06:43, 16 November 2022 (UTC)

Note that the above was only posted after I twice had to revert SecretName101's attempts to cordon off my legitimate objections to this proposal, and after I informed SecretName101 that any further attempts to do so would be reported at ANI. This absurd attempt to WP:OWN a Village Pump page should be seen for what it is. AndyTheGrump (talk) 06:49, 16 November 2022 (UTC)

Each time you objected to the two different forms of refactoring, I have permitted your revert to stand and not re-implemented my change. After my first attempt using a hide template, I tried the very different form of resectioning. I figured since you objected to "attempts to hide", a compromise alternative you might agree to would be resectioning since it does not include the any collapsible aspect. Since you also didn't like that either, I have asked for admin help address this. SecretName101 (talk) 07:00, 16 November 2022 (UTC)

You are in no position to 'permit' anything. And I'm not interested in 'compromising' with someone who attempts to cordon off legitimate commentary on a proposal. If you don't like having your aspect-ratio-policing proposals described as 'absurd', don't make absurd aspect-ratio-policing proposals. And if you don't like having them described as 'authoritarian', you should probably try behaving in a less authoritarian manner here. AndyTheGrump (talk) 07:07, 16 November 2022 (UTC)

You have now described me outright as authoritarian. I will ask you again to cease utilizing ad hominem attacks and refrain from hostility. SecretName101 (talk) 07:09, 16 November 2022 (UTC)

I described your proposal and your behaviour as authoritarian. The evidence for both can be seen. AndyTheGrump (talk) 07:11, 16 November 2022 (UTC)

Chocolate and naps for both editors in this thread. Yall. 98.246.75.122 (talk) 07:20, 16 November 2022 (UTC)

Probably a good idea. Meanwhile those of you that are awake might like to take a look through SecretName101's recent editing history, and see for themselves the barely-skimming-the-skullbone consequences of imposing 4x3 aspect ratios to the detriment of aesthetics... AndyTheGrump (talk) 07:33, 16 November 2022 (UTC)

Back from my nap. See here [6] for what happens when people with the aesthetic taste of a potato-peeling machine impose arbitrary rules on images. Viewer discretion advised... AndyTheGrump (talk) 14:34, 16 November 2022 (UTC)

) Example one was not the image in use. A different derivative version of that image was already in use. This goes for other examples you included as well. You also chose to exclude descriptive edit summaries on a number of these that explained the rationale behind a number of those crops (making the size or centering of the individual in the photo match the photo opposite to it in an election infobox, for intance). Your choice to intentionally omit context and mislead is atrocious. For instance you put in File:Quentin Palfrey (3x4a).jpg and derided how close-up the image was, but omitted any way of others know seeing the context it was intentionally loyal to the crop previously in use File:Quentin Palfrey (cropped).jpg.

If you wanted to be non-misleading, you'd have included the diffs at which crops were applied so individuals could compare how these changes looked when added. But no. SecretName101 (talk) 15:52, 16 November 2022 (UTC)

I presented evidence of what happens when someone with no aesthetic taste crops images in order to comply with an arbitrary aspect ratio. You provided the evidence. AndyTheGrump (talk) 16:01, 16 November 2022 (UTC)

No, you framed an incomplete picture. In many cases extremely misleading illustration. Perhaps deliberately. I'd recommend you instead provide diffs of changes where you think a page was actually worsened. SecretName101 (talk) 16:03, 16 November 2022 (UTC)

If I wanted advice on picture-framing, I certainly wouldn't ask you. AndyTheGrump (talk) 16:06, 16 November 2022 (UTC)

Please drop your pattern of incivility towards me. Your interactions with me on this project feel uncivil every time. You ridicule, condescend, antagonize, and generally act unprofessionally towards me on a frequent basis. SecretName101 (talk) 16:12, 16 November 2022 (UTC)

And I apologize for any ways I may have been uncivil in return. SecretName101 (talk) 16:17, 16 November 2022 (UTC)

• I presume by this point that this whole discussion is a waste of time, but on the off chance that anybody is reading this: prescribing a particular aspect ratio for image cropping seems pointless at best and counterproductive at worst. Whatever aspect ratio is chosen, there will inevitably be cases where slavishly trying to fit that ratio will force us to either leave in elements that would be better cropped out, or crop out elements that would be better left in. The idea that prescribing a particular aspect ratio will prevent disputes is optimistic at best. There will still be plenty of scope for disputing exactly how a particular image should be cropped, and it's not hard to think of situations where a mandated aspect ratio would force editors who would have previously been able to agree on a crop at some other aspect ratio into a dispute. Inconsistency in image aspect ratios simply isn't a major problem, but mandating fixed aspect ratios is likely to create problems. Caeciliusinhorto-public (talk) 16:17, 16 November 2022 (UTC)

  Hi, appreciate your contribution. I will note I am not at all proposing a "mandated" apsect ratio that would "force" anything. Just the creation of a guideline that would be a recommended practice. SecretName101 (talk) 16:20, 16 November 2022 (UTC)

  I requested this be a recommended guideline rather than a rule for the reasons of broadly permitting reasonable exceptions when they arise. SecretName101 (talk) 16:22, 16 November 2022 (UTC)

  @SecretName101, our guidelines are "rules". Sure, we don't usually call them by that word, and we allow some sensible exceptions (we allow sensible exceptions even to most things that we call "policies"), but the fact is that our Wikipedia:Policies and guidelines are actually rules. Furthermore, even if you write down something very weak and mushy, like "As a strictly optional suggestion that any editor is allowed to reject, we suggest...", someone will try to enforce that suggestion inappropriately. WhatamIdoing (talk) 17:10, 17 November 2022 (UTC)

• Oppose What bothers one person as "aesthetically displeasing" is not a sound basis for enshrining something in a guideline. I am not aesthetically displeased in any way by variance in aspect ratios of pictures. --Jayron32 17:36, 16 November 2022 (UTC)
• Comment. I hope you're all aware that, to present a cropped image in an infobox, you don't need to crop the version of the image at Commons, nor to upload a cropped version there. You can just present the image cropped. There's an example of how to do that in an infobox at User:Maproom/cropping.   Maproom (talk) 18:27, 16 November 2022 (UTC)
• Oppose per Wikipedia:Avoid instruction creep. The aspect ratio of the image at P. B. Van Trump is just fine. Cullen328 (talk) 19:48, 16 November 2022 (UTC)

  This revealing gallery demonstrates that SecretName101 really ought to abandon this misguided campaign. OMG. Most photographers think that a portrait that skims the top of the subject's head is flawed, and take several photos to later select the best. This editor actively creates such bad images by priotizing an arbitrary aspect ratio over common sense. Cullen328 (talk) 20:06, 16 November 2022 (UTC)

  As I mentioned in an earlier thread, the gallery is deceptively presented. In some cases it uses uncropped full versions of images that were already using cropped versions before they were replaced. It also omits edit descriptions of some changes that would give better context related to the crop, and also does not include the diffs which would provide you the full representation of how they changed infoboxes in appearance. A lot of things they ridicule in each of the crops they cherry-picked were actually present in the crops already being utilized, so are not due to 3x4 cropping. They also blow-up the these images, so that lower-resolution images look blurrier in their gallery than they do in the actual infoboxes (many of these were for elections infoboxes where the size of the images are as small as x150px and the images do not look poor as they do blown up to what seems triple that size).

I would recommend you provide a list of difs you take issue with instead of citing a manipulatively-presented gallery. SecretName101 (talk) 20:22, 16 November 2022 (UTC)

Additionally, your example of P Van Trump's image would also not be affected even if this were a rule (which it's not, it'd be a guideline), since it is located outside of an infobox. SecretName101 (talk) 20:29, 16 November 2022 (UTC)

The fact of the matter is that every single cropped image on Andy's example page is really bad. If you cannot acknowledge that, then I recommend that you stop cropping images. Cullen328 (talk) 20:40, 16 November 2022 (UTC)

The Huckabee images, for instance, are no worse than what was already in use. You cannot find a high-def image of Mike contemporary with that era that is free to use. And, oddly, Sarah Huckabee Sanders lacks any shot on Commons that is not a candid. So, sadly we are left with less-than ideal options for both of their elections. "Inflate him instead, into a blur" is an intentionally misleading complaint, since the gallery inflated the image up to a size much greater than in the infobox for the election, and because the crop previously used in that infobox would look equally bad blown up. SecretName101 (talk) 20:46, 16 November 2022 (UTC)

Given that the main justification for your proposal other than your own personal preference is the supposed benefit of consistency, the fact that this guideline would apply to infobox images but not other lead images seems bizarre. If consistency is so important, we should have a guideline that applies across the board – not just to some subset of infobox images. Caeciliusinhorto (talk) 20:38, 16 November 2022 (UTC)

SNot really. This would be concerned with consistency between the appearance of infoboxes. It's not inconsistent to have images outside of infoboxes unaffected by this. The aspect of images becomes more noticeable when you have a consistent frame (a standard-width infobox) that it is recessed in that provides a visual comparison point with images in other articles. Standalone lead images are no recessed inside a usually standardized-width frame, so are not much a concern. SecretName101 (talk) 20:41, 16 November 2022 (UTC)

@Caeciliusinhorto: this is a complete misunderstanding of the point of this proposal. Election infoboxes are supposed to have a relatively standardized look across the project, and standardizing the guidelines for creating them is common sense. The point here isn't "all pictures of people should have the same aspect ratio", but that the pictures used in one particular type of infobox should be cropped to that ratio, so all of those infoboxes display in the same manner. Elli (talk | contribs) 10:54, 17 November 2022 (UTC)

@Elli: that's precisely what I'm confused by. Why do election and biography infoboxes have a unique need for standardisation which doesn't apply to other content? Caeciliusinhorto (talk) 11:11, 17 November 2022 (UTC)

Because election infoboxes have multiple images (one for each candidate), and having them at different aspect ratios looks weird? And having every election infobox across the site look slightly different because aspect ratios for the images in them are different would be pointless. There is no benefit really to not standardizing the ratios here. Elli (talk | contribs) 11:19, 17 November 2022 (UTC)

That logic makes no sense: the proposal is for this guideline to apply to both election and biographical infoboxes, but biographical infoboxes don't have multiple lead images, while there are other infobox templates (e.g. {{Infobox sports rivalry}} which are likely to have multiple images but the guideline wouldn't apply to. And even fixing the aspect ratio election infoboxes still won't look the same because the number of candidates in any given election varies: the last five UK Labour Party leadership elections have had five different numbers of candidates. I'm still not convinced that the problem you identify is in fact problematic, but if it is then this proposal doesn't solve it. Caeciliusinhorto-public (talk) 12:48, 17 November 2022 (UTC)

• I oppose this proposal on its merit and the overwhelming likelyhood that its codification would not serve to improve Wikipedia. While the proposal is clearly given in sincerity and good faith, its opposition should not be taken as a personal affront (it is not). It is collegial dissent where the best interests of Wikipedia has moved others to a different conclusion than that which this proposal is premised upon. Best regards. --John Cline (talk) 09:13, 17 November 2022 (UTC)
• I am very disappointed with AndyTheGrump's conduct here, starting with them viewing this as vandalism and then creating a misleading gallery to argue against cropping images in one particular context. This probably should not have been brought to VPP, but it would be a good idea to establish a suggested aspect ratio for images in election infoboxes. Pretty much every crop presented in Andy's gallery is precisely what should be done; for these boxes, we should focus on the head/upper body of the figure and crop extraneous surroundings. And yeah, for some politicians, we don't have a good picture of them in particular, so we need to crop them out of a larger image. That's not ideal, but it's what we have to work with. I don't see the need to codify this as a guideline but the strong opposition this has gotten is discouraging and shows to me that many editors have commented without fully considering the issue that is being discussed here. Elli (talk | contribs) 10:51, 17 November 2022 (UTC)

  Please provide examples from outside Wikipedia where the creators have considered it appropriate to crop a closeup portrait from a larger image to the extent that the top of the head is a few pixels below to top of the crop. You won't find them. Nobody does that for a conventional portrait. It is ugly, and unnecessary. AndyTheGrump (talk) 11:05, 17 November 2022 (UTC)

  Our point in infoboxes is not to have a "conventional portrait", though. It's meant to be more in line with how other sites that report elections show candidate headshots, for example, check out The New York Times. While they have better pictures than we do, they do a similarly close-up crop (except they do a square crop, because they put the headshot in a circle; the idea is the same, though). Elli (talk | contribs) 11:21, 17 November 2022 (UTC)

  Who's 'point' is that? Where was it decided that infoboxes for biographies of politicians were a special case, and that cropping right to the top of their heads was appropriate? [7][8][9] AndyTheGrump (talk) 12:19, 17 November 2022 (UTC)

  I am not really talking about our biographies here. I'm talking about our election articles. Elli (talk | contribs) 13:18, 17 November 2022 (UTC)

  You may not be, but SecretName101 was: I myself have made extensive use of this aspect ratio in both biographies and election inboxes... I've shown the results. And if election article portraits need special treatment, it needs to be done properly, by someone who understands how to crop an image just for that purpose. As Maproom points out above, there are ways to do that without having to crop content on Commons at all. Messing up biography infoboxes with ugly crops just to make election articles 'consistent' was totally the wrong approach. AndyTheGrump (talk) 14:25, 17 November 2022 (UTC)

  Well sure, and I generally agree with you that biographies don't need crops that are as aggressive. When I crop images, I almost always crop to a new file, which avoids that issue. Elli (talk | contribs) 15:20, 17 November 2022 (UTC)

• Oppose. Images should be individually evaluated for whether cropping is appropriate, and what dimensions are individually most appropriate. Fidgeting the crop of images trying to force arbitrary consistency is clearly not vandalism (as someone suggested), however it is both unnecessary and unhelpful. Also Wikipedia:Avoid instruction creep. Alsee (talk) 08:55, 18 November 2022 (UTC)
• Comment: Both sides have presented decent arguments and I'm not sure what to go with at the moment. But damn! @AndyTheGrump has been overly aggressive from the get-go where they proceeded to assume bad faith on SilentName101's part (namely vandalism). Not cool. — Python Drink (talk) 23:11, 19 November 2022 (UTC)

@Caeciliusinhorto-public: My preferred result is for both electionbox and biographical infoboxes (parituclarly those of officeholders) to have this as a recommended guideline. But that doesn't mean the consensus reached here cannot be "yes on election article infoboxes, no on biographies". These discussions are to reach consensuses, and that consensus can differ from the original proposal. So if you think you'd support one but not the other, you can make that your declared position here. SecretName101 (talk) 23:47, 19 November 2022 (UTC)

• Oppose, the aspect ratio doesn't affect the information-content of the article in any way. The likely outcomes of such a rule would be new editors feeling they're being niggled-at, as the images in their articles get twiddled-with and cropped, and the inevitable passive-aggressive template messages about approved ratios accumulate on their talk-pages; (2) a lot of editors who ought to be doing something more useful will waste lifetimes whizzing around shaving bits off the tops and sides of otherwise innocent photos. Elemimele (talk) 13:14, 20 November 2022 (UTC)
• Oppose – I really don't see the point in doing these crops. Whenever I click an image on Wikipedia, I want to see the whole image and not have to go dig around the file history to find the uncropped version (if it even exists and they weren't overwritten). I agree with Alsee in that I don't think this is to the extreme to call it vandalism, but is largely unhelpful and unnecessary.♠JCW555 (talk)♠ 19:50, 20 November 2022 (UTC)
• Oppose I generally support cropping infobox portraits, especially male politicians, to remove expanses of suits & ties, but we don't need a policy on it. Mr van Trump is fine as he is. Johnbod (talk) 15:47, 22 November 2022 (UTC)
• Oppose I can't see that this needs to be set in stone. A correctly cropped image is a good thing, but systematically setting them to a specific proportion without consider the content of the image just seems disruptive. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 17:37, 22 November 2022 (UTC)
• Oppose. Obviously. Trout to the OP for wasting everyone's time with such a badly thought out "proposal". The flaws are well demonstrated (and illustrated), so I don't need to repeat them. Is it snowing yet? Begoon 13:34, 27 November 2022 (UTC)

  @Begoon, please refrain from being nasty towards others. Just because you feel someonems proposal is flawed, does not mean you should take a belittling, condescending tone towards them. Keep this project civil and welcoming. ❤️ SecretName101 (talk) 18:28, 27 November 2022 (UTC)

  This page is for discussing proposals, not singing Kumbaya. My reaction stands. It was badly thought out, as thoroughly discussed above. If you waste other editors' time by submitting half-baked proposals then it's not out of order to propose a "Trout", which is pretty gentle, quite honestly, given your performance here. I'm not sure where you think you can stick the award winning, all-purpose, last-resort whine of those bereft of an actual argument "uncivil" on my post - I don't believe I was rude to you, just your demonstrably bad idea. As for "welcoming" - you've been here a while, so I'm not sure what you mean by that? What's particularly disappointing is that, even after very clear explanations of why this is a poor proposal, you keep bludgeoning the discussion and trying to take some kind of position that you can't be wrong and it must just be that everyone is picking on you. It's ok to be wrong, you know, and there are even ways to concede that, and gracefully back away... Just saying... ¯\_(ツ)_/¯ (the little "heart" thing is lovely though - did you add that just for me?) Begoon 10:13, 29 November 2022 (UTC)

  Tone matters not just in the context of the person you're talking to, because also others may be looking over the page and wondering whether this page is a safe place to bring their own ideas. That's one of the reasons that we discourage behaviors that have been called "dogpiling" and "brigading" or "kicking someone when he's down". We don't need a bunch of people to formally vote against a proposal when it's clear that a proposal isn't getting any traction, especially if they don't have any new information to add. WhatamIdoing (talk) 02:22, 30 November 2022 (UTC)

• I agree with the OP that infoboxes often ought to be cropped to a headshot, particularly in election campaigns where our sources do the same, and generally infoboxes with multiple photos should have some consistency for overall aesthetic purposes. But I agree with most of the responders that putting this in a guideline, especially with specific recommendations like 3x4, seems like instruction creep. It doesn't seem like there's a big problem here that needs solving by creating additional rules or guidelines, and the creation of instructions/rules could potentially negatively override nuance and individual circumstances. Maybe start by putting these recommendations into an essay? -M.nelson (talk) 10:07, 30 November 2022 (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.

RfC: Showing a gadget menu to logged-out users

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

Implementing was Opposed.
And No Consensus on "some other way" to provide "dark mode" to IPs. - jc37 17:34, 1 December 2022 (UTC)

---

Using the gadget menu to enable dark mode

Should a JavaScript gadget be installed as a default gadget to show a gadget menu to logged-out users? The menu will initially be used to offer the Dark mode gadget, but future proposals can add/remove other gadgets/scripts to the menu. — Alexis Jazz (talk or ping me) 14:14, 26 October 2022 (UTC)

Background (showing a gadget menu to logged-out users)

Visitors without an account have no access to Special:Preferences. They can only load gadgets or scripts by appending &withgadget= or &withJS= to a URL, but this has to be done every time a page is visited which is not practical for everyday use.

Wikipedia relies on gadgets and scripts for all kinds of functionality. Dark mode is a notable one, but the WMF also suggested developing gadgets to alter/customize the behavior of the new Vector-2022 skin. Scripts/gadgets to show signatures in the local timezone of the user, add links to comments, disable access keys or add outline-style numbering to headers are examples of other gadgets/scripts that can be beneficial to visitors without an account. A gadget could also be developed to allow users without an account to manage gadgets/scripts more extensively. Such a gadget could be loaded through the proposed gadget menu.

Users who are logged out currently have no convenient way to load any of those. Before this gadget would be deployed the WMF developer team will be asked to review it and issues that should be resolved before deployment will be resolved.

The gadget menu script is lightweight: it adds ~3K to MediaWikiModuleStore. The script has no effect for users who are logged in. The script can be tested by visiting Betacommons (desktop) or Betacommons (mobile) while logged out.

Update 15:31, 27 October 2022 (UTC): in response to some of the votes it has been made possible to show the gadget without a menu, simply listing all entries instead. This means the script could be used purely for dark mode, adding a "Enable dark mode" link to the sidebar and nothing more. You can preview this menu-less mode of the gadget by visiting [10]. Note that while the testing environment currently lists four gadgets, this proposal is only for the gadget loader+dark mode. This added functionality made the script slightly bigger, but a little over 4K is still tiny. (for comparison: WP:Twinkle is ~550K)

Survey (showing a gadget menu to logged-out users)

• Support as proposer. — Alexis Jazz (talk or ping me) 14:14, 26 October 2022 (UTC)
• Support: Long overdue. There are only a few popular websites that don't allow features like dark mode to visitors in the year 2022. It is time that we follow suit by letting IPs use gadgets. What other gadgets should be added into this in future? An advertised RFC should determine. —CX Zoom[he/him] ^{(let's talk • {C•X})} 19:22, 26 October 2022 (UTC)
• Support - this is poggers. jp×g 19:35, 26 October 2022 (UTC)
• Support. —Yahya (talk • contribs.) 20:14, 26 October 2022 (UTC)
•  Support, a great way to allow casual readers to use dark mode. — Qwerfjkltalk 20:19, 26 October 2022 (UTC)
• Support because it gives the user more freedom. --small jars tc 20:53, 26 October 2022 (UTC)
• Strong support - Making UI customisation easily accessible to readers without accounts is a no-brainer. Daß Wölf 21:07, 26 October 2022 (UTC)
• Oppose. I have concerns about this on a number of levels. As a baseline framework, we're talking here about logged-out users, so it's important to put ourselves in their position. All of us, by virtue of being in this discussion, are power users, and that means the way we interact with Wikipedia is far different than that of typical users. We care about customizability; normal users do not. We care about advanced editing tools; normal users do not. Etc. When we're talking about the left sidebar, we're talking about extremely valuable space that should be reserved only for our most important links. Our audience is >99% people who have never edited Wikipedia before beyond perhaps fixing an odd typo. (The far less than 1% of users who are active IP editors are negligible numerically, and are making a highly idiosyncratic choice in full knowledge of the many downsides for both themselves and others they interact with; we need not cater to them.) The best way to engage them is through links to the high-level overview pages like Help:Contents and Help:Introduction that are currently in the sidebar. The proposed gadget menu in the screenshot has a link to "CD", presumably commons:User:Jack who built the house/Convenient Discussions. (The nominator ought to specify these in the proposal so we know what we've !voting on.) That may be a useful tool for us advanced editors who spend tons of time on talk pages. It's absolutely not the best entry point for someone who's brand new to editing, especially now that most of the important functionality for newcomers is handled by the talk page improvements. Ditto for User:Alexis Jazz/Factotum. Likewise for skin changes, the quintessential example of something no one other than veteran Wikipedians cares about (and which is already easily accessible in your preferences). The dark mode is the most promising option, but if that's all we care about, it should be listed directly, not accompanied by all these other items. And per Writ Keeper below, I'm not convinced it's ready for widescale deployment yet. Our audience can be expected not to know what a gadget is, so grouping things under a gadget menu for them makes no sense. Also, the tools section where the menu currently appears is supposed to be reserved for things that affect the specific page one is on; the correct placement would be above it.
  I get the sense from the !votes above that editors think we're discussing just giving readers a dark mode. But this proposal goes far beyond that, and it's nowhere near ready for widescale deployment, nor is it the right overall approach. If we want a dark mode gadget for readers, that should be done through making it a default-on gadget that would add an appropriately designed/placed icon, not through introducing an entirely new menu. {{u|Sdkb}} ^talk 21:16, 26 October 2022 (UTC)

  @Sdkb: The nomination statement clearly talks only about Dark mode initially, the screenshot is simply for representation purposes. Again, as I mentioned above, adding/removing scripts should be done on a case-by-case basis via RFCs. —CX Zoom[he/him] ^{(let's talk • {C•X})} 22:16, 26 October 2022 (UTC)

  As far as making it^{[dark mode]} a default-on gadget is concerned, I'm afraid it is technologically not possible yet to install it on its own. See Wikipedia:Village pump (proposals)/Archive 191#Proposal: Dark Mode Button. AlexisJazz's AnonLoader tool appears to have achieved this without having to install a extension to individual wikis's configurations. —CX Zoom[he/him] ^{(let's talk • {C•X})} 22:23, 26 October 2022 (UTC)

  I would want to know what sorts of other gadgets we'd envision as eventually part of the menu before supporting this, since a one-item menu looks terrible. And per above, since readers don't know what a gadget is, having this as a menu doesn't make sense in the first place.

  The discussion you link was a non-starter because of the bright flash issue, which (per below) appears to still exist here. My objection is primarily to the menu, and if it were possible to have dark mode as a menu item it would presumably also be possible to have it as a normal button. {{u|Sdkb}} ^talk 00:50, 27 October 2022 (UTC)

  It can be a normal button as long as it is the only item, and increase to a menu if/when more items are added. —CX Zoom[he/him] ^{(let's talk • {C•X})} 07:40, 27 October 2022 (UTC)

• Oppose Neutral. Withdrawing since I don't have the MediaWiki background to evaluate this. The desire to bring dark mode to Wikipedia is well-placed, and I love how minimally this proposal is scoped, but I doubt users will reach for a "Gadgets" link or understand what it means. Generously (talk) 22:40, 26 October 2022 (UTC)

  I can agree somewhat with this sentiment. Maybe the gadget button is too hidden among other links, at the sidebar. Will look forward to improvements proposed at the discussion section below. —CX Zoom[he/him] ^{(let's talk • {C•X})} 06:48, 27 October 2022 (UTC)

  Generously, an earlier version of AnonLoader was actually different and just listed all gadgets. I've added a mode that basically restores that behavior, you can preview what that looks like by visiting [11]. This can be enabled on a project by putting window.AnonLoaderShowAll=1 in common.js/mobile.js alongside the script list. As long as there are <4 gadgets listed it's likely sensible to just show them all like this.
  If we never agree on any other gadget to add, we could just use AnonLoader exclusively for dark mode without anyone ever seeing the word "gadget". As a side note: when a user does create an account, a similar argument could be made for the "gadget" wording: would a user ever reach for that tab in their preferences or know what it means? I guess curiosity and word-of-mouth are the answer to that. — Alexis Jazz (talk or ping me) 15:13, 27 October 2022 (UTC)

• Oppose. We should be encouraging people to make accounts rather than providing additional account-like features to anonymous users. -- RoySmith (talk) 01:03, 27 October 2022 (UTC)

  No one wants to give them access to WP:XFDCloser for example. Dark mode has always been more of a reading-experience-improving tool, than a editing tool. Don't see why casual readers need to create an account to "read" Wikipedia as they feel best, when we allow them to even edit articles. —CX Zoom[he/him] ^{(let's talk • {C•X})} 06:46, 27 October 2022 (UTC)

• Oppose The white flash problem makes dark mode basically useless for non-registered users (and afaik cannot be circumvented), and without a similar killer app, I don't think this is worth deploying to every reader of Wikipedia. A good idea, and one we can and should come back to when we have a viable use case, but this intrinsically flawed dark mode gadget ain't it. Writ Keeper ⚇♔ 07:19, 27 October 2022 (UTC)
  • Writ Keeper, I don't think the white flashes make dark mode "basically useless", but I'd have to agree it's suboptimal.
    I made some changes to the gadget for this. You can experience a white flash for the first page you visit in a session and when performing some specific actions, but while browsing from article to article you should not experience them anymore. — Alexis Jazz (talk or ping me) 15:00, 27 October 2022 (UTC)

    What actions in particular? It definitely looks better, but if someone is using dark mode in a low-light setting, for example, flashing bright white frequently might actually be worse than just white all the time, since one's eyes can't adjust to it. Writ Keeper ⚇♔ 15:35, 27 October 2022 (UTC)

    Writ Keeper, when navigating somewhere using a form, but never mind because that should work now too. Special:Search would probably be the most common example. — Alexis Jazz (talk or ping me) 17:06, 27 October 2022 (UTC)

    It seems you've figured out how to persist the url param across link clicks and form submits. But there are still ways the flash can occur: when search directly takes you to an article rather than the search page; when a page loads after being edited, etc.

    I have a personal script which does something similar to force use of timeless on mobile – I consider it so hacky that I don't even advertiser it as a user script, let alone propose as a gadget. – SD0001 (talk) 19:29, 27 October 2022 (UTC)

• Oppose. If you want to provide the dark mode to logged-out users, then write a gadget (or a patch to the toggle gadget) that allows logged-out users to use the dark mode and make it enabled by default. A gadget that allows toggling all or even a subset of the gadgets doesn't make sense, as that's the point of having an account, i.e. to have a customized site experience. Nardog (talk) 07:59, 27 October 2022 (UTC)
• Oppose mostly against the !voters that are supporting because of "dark mode" only - that should be sovled via phab:T26070, and get away having to push even more layers of locally maintained javascript hacks out. — xaosflux ^Talk 23:27, 27 October 2022 (UTC)
• Oppose per above. A hacky, single item menu for enabling dark mode (accompanied by a white flash on every page load) doesn't sound like good UI/UX. Agree with Xaosflux that this should be done via phab:T26070 -FASTILY 23:55, 27 October 2022 (UTC)
• Oppose Size and branding-wise, the public regards Wikipedia as probably on the same level as Facebook or Google. So if we're implementing a feature for our readers, it just can't be clunky, like at all. The AfC script? Whatever. Dark mode? Absolutely not. —VersaceSpace 🌃 01:35, 28 October 2022 (UTC)
• Support. I think IPs should have more power over their experience. Of course, some technical gadgets (ie. XFDC, which only works for XCONs anyways) should be left to registered users, and the dark mode flash isn't ideal, but some gadgets would be useful for IPs. ^Clyde!_Franklin! 14:20, 28 October 2022 (UTC)
• Oppose: This is a toggle that enables/disables another gadget which implements dark mode through filters (MediaWiki:Gadget-dark-mode.css). Not a good idea to put this out in production. RAN1 (talk) 15:54, 28 October 2022 (UTC)
• Oppose: This is not urgent in anyway. Can wait for proper implementation in MediaWiki. – Ammarpad (talk) 12:32, 29 October 2022 (UTC)
• Oppose: While I generally support the concept of allowing non-logged in users the ability to change their interface, this seems like a very hacky and editor-centric (as opposed to reader-centric) solution. Regards, Sohom Datta (talk) 15:43, 30 October 2022 (UTC)

  In particular, I find the placement of the menu very weird. The sidebar is generally meant to host links that are more focused towards the content side of the project. If implemented, I think a better option might be to use a dropdown/link from p-personal. Regards, Sohom Datta (talk) 15:50, 30 October 2022 (UTC)

• Oppose, anybody who knows enough to want to use gadgets knows enough to make an account to save their settings (and giving IPs access to gadgets but only a limited selection seems like a strange choice). The Correct Way to implement dark mode on a website is the CSS prefers-color-scheme media query, which is exactly what's being done in phab:T26070. XenonNSMB (talk, contribs) 17:15, 31 October 2022 (UTC)
• I understand the idea and I find proposals to improve the experience of any Wikipedia user commendable. I don't agree that having a menu for custom user-written JavaScript "gadgets" is a viable solution, though. If the interface lacks important features or even has bugs that affect every reader, the solution to implement these features or to fix these bugs is to improve MediaWiki, not to throw community-"maintained" JavaScript at the situation. ~ ToBeFree (talk) 23:46, 10 November 2022 (UTC)
• Comment I like some of the ideas here, and dark mode is overdue, but the implementation could use some finessing. Ideally the WMF would've allocated the resources for additional features like dark mode ages ago, and given the glacial pace on their end I can understand the desire to do this on our own. Still this proposed solution is rather hacky. 74.73.224.126 (talk) 00:30, 11 November 2022 (UTC)
• Oppose, they can create an account if they want to, it takes 30 seconds. Stifle (talk) 14:34, 15 November 2022 (UTC)
• Oppose as someone who explored creating a dark mode toggle, with the way gadgets currently work, this should not be done for logged-out users. Seddon ^talk 15:02, 15 November 2022 (UTC)
• Opposed to this, basically per the above: hacky and just generally not a good road to start going down. I also think "logged-out users" is the wrong way to frame this, when what that really means is readers. We get, what, around 9 or 10 billion page views a month? It's a massive surface area given readership, and they are owed a certain standard. ~ Amory (u • t • c) 18:45, 15 November 2022 (UTC)
• Oppose introduction of Dark Mode gadgetry per User:Sdkb. Also, nobody here seems to notice that MediaWiki is an open source project. Everyone is allowed to contribute code to it and so mediawikiwiki:Extension:DarkMode already exists (courtesy of User:MusikAnimal who may wish to comment here). Go work on that and get it to a point where it's of an acceptable quality for the English Wikipedia. Don't code hacky JS stuff specific to enwiki. Chess (talk) (please use {{reply to|Chess}} on reply) 15:45, 16 November 2022 (UTC)
• (Already !voted above) I'd just like to note I stick by my Support !vote above: Extension:DarkMode won't be enabled for logged-out readers per MusikAnimal the native solution (by adding CSS on page load) via mw:Extension:DarkMode won't be offered to logged out users on the WMF cluster because it would mean we have to bypass the Varnish cache on every page load, which is an absolute no-no. This seems to be the only reasonable way to offer Dark Mode to people without an account. — Qwerfjkltalk 15:23, 18 November 2022 (UTC)
• Support. I want Wikipedia to have dark mode for when I am not logged in. Ghost of Kiev (talk) 15:31, 23 November 2022 (UTC)
• Support with wishes that default MediaWiki can support this. 🥒 EpicPickle ^{(he/him | talk)} 22:57, 23 November 2022 (UTC)
• Oppose If what people want actually is a dark mode for logged out users, that should be a specific proposal. Adding a generic menu for gadgets is too vague of a goal. Galobtter (pingó mió) 02:14, 24 November 2022 (UTC)
• Support I had a dream about this last night! But I think that choosing any of these prefs should (once each session) invite the reader to log in / make an account. Dark mode alone is a nice carrot to help avid readers overcome the friction to making an account. And the challenge of learning to optimize how we support the customizations of a larger user pool is both tractable and a great one to have. Improving the reading experience for everyone is literally one of the things we raise funds to enable. – SJ + 14:44, 24 November 2022 (UTC)

Discussion (showing a gadget menu to logged-out users)

This is a cool thing in general, but specifically in the case of dark mode, I'm not sure it works very well, since (at least on my browser) the page will load and display in the regular white screen for a half-second or so while the Javascript executes, then flashes back to dark mode. I don't think that's practical.

(Also, not sure if it matters, but is there a particular reason it's using a global variable for storage, rather than localStorage.getItem("X","Y");, etc.?) Writ Keeper ⚇♔ 20:18, 26 October 2022 (UTC)

Half a second is not bad at all. In my case the first time takes about 30-35 seconds to turn on and 5-7 seconds to turn off, and in the meantime the toggle is unresponsive (TBF I'm not sure how much of that is due to new Vector which is somewhat slower on my PC). This should be rewritten in a less resource intensive way so that it works swiftly on the average computer. I think it can be done with CSS and cookies, which would also be backward compatible with nearly all browsers recent enough to be able to connect to Wikipedia. Daß Wölf 21:07, 26 October 2022 (UTC)

Daß Wölf, on a 10-year old system it takes more or less just as long to reload a page as it does to enable/disable a gadget. (which is expected as enabling/disabling a gadget also reloads the page) On a 9-year old smartphone my experience is the same, enabling dark mode takes roughly 2 seconds which is roughly how long it takes to reload a page.
Edit: while browsing you won't see a white flash anymore, pretty much only when starting a session now as far as I can tell. — Alexis Jazz (talk or ping me) 23:00, 26 October 2022 (UTC)

@Daß Wölf: The reason it's lagging so hard is because it's applying an invert and hue-rotate filter to the page. RAN1 (talk) 15:54, 28 October 2022 (UTC)

I've withdrawn my !vote, but I'll add here that while logged-in users are used to large JS payloads, the logged-out experience has been made pretty slim through some WMF effort. In that context, 3KB is sizeable. Generously (talk) 20:49, 27 October 2022 (UTC)

Generously, that article speaks of bandwidth savings and "after compression". The script has currently grown to 6K after fixing the white flash issue for searches (could possibly be optimized a bit) but this is 2.6K compressed which could be slightly less when delivery is combined with other scripts by ResourceLoader. In practice however, this would be cached in MediaWikiModuleStore (localStorage) and once it's there it won't be downloaded again.
@SD0001, I've worked on the white flash search issue. Some edge cases remain. For editing, it should be noted that the vast majority of anons never edit. There's no issue with VisualEditor or DiscussionTools. Due to the way the 2010 Wikitext editor works I don't think there's any clean way to make that work. I suspect the most viable option would be to figure out how to enable the 2017 wikitext editor in this case. Not sure how hard that'll be. As for your script, I guess my SkinEnforcer does something similar. It's quite a bit more complicated. I see some obvious issues with your script and SkinEnforcer has some different issues which also make it far from perfect, so I wouldn't propose either of those indeed. Not in their current state anyway.
@RoySmith @Nardog, that's generally how things are, but it doesn't have to be. We could offer more customization to visitors without an account. The way I see it, you create an account to get attributed for your contributions, to stop spilling your IP with every edit, to get rid of the CAPTCHA, to engage in talk page discussions more easily and to vote on things. Why should we require an account to enable dark mode, auto-number headings or perhaps some accessibility options?
@Xaosflux @Fastily, well, phab:T26070 is a ticket from 2010. 12 years old. This is kinda how it works: the community wishlist barely works, but if we vote for a gadget suddenly the WMF realizes "this is important!" and develops a native implementation. The white flash issue (which I didn't personally perceive as a big deal when I created the RfC, but I see others care much more strongly about it) has already been much reduced if not eliminated from your average anon browsing session. (apart from the start of the session) And the gadget menu can work without the menu part now, showing only the "Enable dark mode" link.
@VersaceSpace, I essentially agree, but does this mean you'd change your vote if the issues are resolved? — Alexis Jazz (talk or ping me) 14:34, 28 October 2022 (UTC)

@Alexis Jazz: yes —VersaceSpace 🌃 22:35, 1 November 2022 (UTC)

Is there a reason for this to be a toggle in production? The stylesheet can't automatically disable itself when the toggle is. I ended up learning the hard way that these are separate gadgets when I disabled the toggle. RAN1 (talk) 15:11, 28 October 2022 (UTC)

RAN1, dark mode consists of multiple parts. MediaWiki:Gadget-dark-mode-toggle.js ("dark-mode-toggle") provides the toggle which loads the actual dark mode from the hidden gadget "dark-mode" at MediaWiki:Gadget-dark-mode.css. In the way it's currently set up on betacommons the proposed script, AnonLoader, skips dark-mode-toggle and applies dark-mode directly. The dark-mode-toggle normally changes a user preference to enable dark-mode.css. This is not possible for anons. To prevent white flashes, the hidden "dark-mode" gadget must be loaded along with the page request. This is done through a user preference for logged-in users. AnonLoader achieves this by adding &withgadget=dark-mode to the URL with persistence.
Due to the way cache stuff is set up, using cookies is AFAIK not possible for this kind of thing. — Alexis Jazz (talk or ping me) 20:17, 28 October 2022 (UTC)

@Ammarpad, Can wait for proper implementation in MediaWiki. That may not be realistically possible. As explained by TheDJ in phab:T307851 for a similar question about skins: Cookies (I'm assuming for anon users ?) can be used, but we cannot vary the content based on them. This would cause a caching problem.
So cookies are out, localStorage is out due to the white flash issue and the query param method (which AnonLoader can use for 1 gadget, which it uses for dark-mode on betacommons now) seems unlikely to get implemented natively in MediaWiki. So the real choice it seems is this: either don't offer dark mode to anons at all, or put effort towards making the query param method as good as it can be. — Alexis Jazz (talk or ping me) 13:11, 30 October 2022 (UTC)

Correct, the native solution (by adding CSS on page load) via mw:Extension:DarkMode won't be offered to logged out users on the WMF cluster because it would mean we have to bypass the Varnish cache on every page load, which is an absolute no-no. I have heard through the grapevine that leadership is reconsidering this extension for logged in users, however. The extension does have a query param that could be offered to logged out users, but since the CSS has to be applied after page load, they may experience FOUCs. — MusikAnimal ^talk 17:37, 16 November 2022 (UTC)

@MusikAnimal: The extension is a reproduction of the gadget. Can we get proper support out of this line of development? RAN1 (talk) 00:58, 17 November 2022 (UTC)

Other way around actually: the extension came first and for Earth Day 2021 we (myself, SD0001, Nardog, Xaoslfux and others) ported it to a gadget here. We then advertised it in meta:Tech/News in an effort to have the gadget adopted on other wikis. It looks like it's now spread to seven other wikis, while more wikis may have their own fork or variant. This was to influence WMF leadership that communities are accepting of the "invert" solution provided by this implementation of DarkMode. As I hinted at above, there's a chance they're reconsidering it now. Not sure if that answers your question. — MusikAnimal ^talk 01:10, 17 November 2022 (UTC)

My bad, I saw there wasn't a pref toggle and assumed that was a remnant. I noticed the render delays with the filter on, so I don't think this can run sitewide, even if it was limited to just a CSS media query to make it cacheable. RAN1 (talk) 04:33, 17 November 2022 (UTC)

The toggle is not necessary IMO and you would do well to decouple it from dark mode solution. Most operating systems have a toggle these days built in (my operating system for example transitions to dark mode based on time).

We were recently discussing doing this in core here:

https://phabricator.wikimedia.org/T26070#8401179 Jdlrobson (talk) 19:45, 23 November 2022 (UTC)

• Consider consulting with WMF devs about how this would affect caching. There may be big caching implications to making the website more interactive/less static for logged out users. –Novem Linguae (talk) 11:43, 19 November 2022 (UTC)

Quick comment regarding dark mode: the prefers-color-scheme method that was mentioned looks like it would be a (much) more neat solution. I have a few concerns with it though: some users have reported severe performance issues with dark mode. They never mention their browser/OS/anything and I haven't had any issues even on really old systems/phones, but apparently it's a thing. With prefers-color-scheme there wouldn't be any obvious way to disable the dark mode though. Also, we should provide instructions on how to enable/disable dark mode in that case. Mozilla links [12] (Windows) [13] (Android) [14] (Firefox) for that. In Windows and Android, it's an OS setting. In Firefox, the instructions are to open about:config which we probably shouldn't encourage users to do. And none of these allow enabling dark mode on a per-domain basis. But I see the potential. — Alexis Jazz (talk or ping me) 09:55, 25 November 2022 (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.

Tags

I think think here should be an option to hide tags through preferences 2006toyotacorrola (talk) 14:41, 20 November 2022 (UTC)

The entire point of tags is to alert readers and editors about potential problems within an article, and inspire them to fix those problems. If you hide the tags, how will you know whether there are problems, what those problems are, and what needs fixing? Blueboar (talk) 15:21, 20 November 2022 (UTC)

+1 Donald Albury 16:23, 20 November 2022 (UTC)

Thanks, I was looking for a good reason to not do it 2006toyotacorrola (talk) 16:36, 20 November 2022 (UTC)

@2006toyotacorrola: if you want to hide them for yourself, go to Special:MyPage/common.css and insert this code:

.mw-tag-markers{display: none;}

— xaosflux ^Talk 18:32, 20 November 2022 (UTC)

The entire point of tags is to alert editors (some of whom are not logged in, of course) that something needs to be fixed. Except in rare and temporary situations like {{hoax}}, we don't add tags to "warn the reader".

We have no evidence that maintenance tags are effective at inspiring improvements to content that wouldn't happen otherwise, or that readers pay any attention to them. They weren't shown at all on mobile for years, and during that time, AFAICT we received exactly zero comments from IPs or newbies about the "missing" maintenance tags. That suggests that they probably don't work. WhatamIdoing (talk) 03:20, 30 November 2022 (UTC)

Conversely, we don't hear anything about tags may mean that they are working. I appreciate when there are tags that say something like "Changed height/age in infobox", because more often than not they are vandalism edits. – robertsky (talk) 03:35, 30 November 2022 (UTC)

I don't think there are any Wikipedia:Maintenance tags saying things like that (which is the kind of tag I was thinking of). Are you thinking of Special:Tags with the Edit summary? WhatamIdoing (talk) 19:53, 5 December 2022 (UTC)

Way to visually identify inactive editors

See also: Wikipedia:Village_pump_(idea_lab)/Archive_43 § Is_there_a_way_to_visually_identify_inactive_editors?

The previous discussion at Village Pump's Idea Lab received some interest but stalled. Figured I'd start a discussion here and see if anything comes to fruition. In short, Wikipedia already offers a user preference to "Strike out usernames that have been blocked" (which is accessed under the Appearance section of the "Gadgets" tab). I've found this to be very helpful at quickly and easily identifying blocked editors.

I propose a similar "gadget"/preference to similarly identify inactive editors. I'm tired of looking at lists and categories of editors at WikiProjects and other spaces only to discover many of the users are inactive. I'm open to how the community defines "inactive" for this feature -- I'm open to something as simple as "no edits in 5 years" or similar. There's nothing wrong with inactivity, but (optionally) identifying active vs. inactive users seems very helpful.

Hoping for a continued discussion here. Based on the Idea Lab discussion, this seems like an easy option to turn on (since the backend already exists for blocked editors). Now there just needs to be community consensus to implement. Thoughts? Concerns? Help implementing?

Thanks! ---Another Believer _(Talk) 16:30, 29 November 2022 (UTC)

@Another Believer: Just in case it's useful, we worked on something very similar to this during a hackathon — phab:T307948 has some more info — TheresNoTime (talk • they/them) 16:39, 29 November 2022 (UTC)

@Another Believer you can add the experimental gadget indicated in the phab ticket in your Common.js and Commons.css:

Common.js:

mw.loader.load('//www.mediawiki.org/w/index.php?title=MediaWiki:Gadget-whoisactive.js&action=raw&ctype=text/javascript');

Common.css:

@import url("//www.mediawiki.org/w/index.php?action=raw&title=MediaWiki:Gadget-whoisactive.css&ctype=text/css"); – robertsky (talk) 00:39, 30 November 2022 (UTC)

Agree this would be useful. Schierbecker (talk) 18:19, 29 November 2022 (UTC)

I can't see how this needs a formal "proposal". This would be delivered as a gadget, which means it can be birthed as a userscript. Anyone is welcome to write a userscript, and if it is stable and starts getting popular it can be promoted to an opt-in gadget. Only if it became immensely popular would it become an opt-out gadget. — xaosflux ^Talk 18:31, 29 November 2022 (UTC)

Short version: {{justdoit}} or WP:US/R is where this can start today. — xaosflux ^Talk 18:34, 29 November 2022 (UTC)

@Xaosflux I have no idea what next steps should be. I posted here so the Idea Lab discussion didn't get lost forever. I invite other editors to continue this discussion wherever's most appropriate. I just had an idea and my only interest here is possibly seeing this come to fruition as a helpful tool, regardless of form or format. Thanks! ---Another Believer _(Talk) 18:36, 29 November 2022 (UTC)

@Another Believer what you want done doesn't exist, software will need to be written to do it. I'm assuming you don't know how to to that, but there are others that may volunteer to do it for you. You can ask them to do this at Wikipedia:User scripts/Requests. Once a "user script" is made, anyone anyone can try it out. If it is popular, we can make it a community-supported script that people can turn on in their preferences, if it is super super userful, we could force it on for everyone. But none of that can happen until it is created. This page is for concrete, actionable proposals - right now this is not actionable. — xaosflux ^Talk 18:50, 29 November 2022 (UTC)

Wikipedia:WikiProject X created an automated membership/participant list system for WikiProjects. If you are instead interested in finding out who's actively participating (not just on wiki, but in the group), then pages like Wikipedia:WikiProject Directory/Description/WikiProject Video games will be useful to you, but they're out of date right now. @Harej, I don't think that User:Reports bot has run either of those two tasks for a couple of months now. The members task last ran at the end of September, and the directory task at the end of June. WhatamIdoing (talk) 03:30, 30 November 2022 (UTC)

I would be concerned about unconscious biases that would result from implementing this feature. For example, "oh so-and-so editor doesn't contribute much" so their contributions, however infrequent, would either not be taken seriously or unfairly targeted for reversions. A central tenet of Wikiquette is, "Be open and warmly welcoming, not insular" and "Treat your fellow productive, well-meaning members of Wikipedia with respect and good will". I am afraid that this would provide a chilling effect to those members who have busy lives but can still meaningfully contribute to Wikipedia. Moarscience (talk) 20:17, 8 December 2022 (UTC)

FAQ Banner

I was thinking that for the talk pages for articles that have an FAQ section, it would make sense to put it as one of the top banners on the talk page since that would improve visibility. Maybe additionally the format of the FAQ section could be standardized, since every section is done a little differently. RPI2026F1 (talk) 02:38, 9 December 2022 (UTC)

{{FAQ}} is the standard banner used at the top of the talk page to display a FAQ. The documentation for the FAQ template contains links to other templates that can be used to help lay out the FAQ. isaacl (talk) 04:09, 9 December 2022 (UTC)

Oh, I saw someone was using a pinned section in a talk page. RPI2026F1 (talk) 04:35, 9 December 2022 (UTC)

Yes, see for example Talk:Muhammad and Talk:Jesus. This is done in the hope that more smartphone etc editors will see them. I think it's worth the effort. Gråbergs Gråa Sång (talk) 15:31, 9 December 2022 (UTC)

Yeah, one of the problems with the default mobile skin (Minerva) is that it puts {{FAQ}} with other talk page header templates behind a very small "about this page" link. So, mobile readers very often never even see the {{FAQ}}, unless they happened to click that link. To combat this, editors have gotten into the practice of posting the FAQ as a pinned section on the talk page, which mobile editors will see right at the top, which is the intended effect. This is useful at least for high-traffic pages where there are a lot of mobile editors. We haven't yet solved this problem permanently though. Someone should probably do something at some point to make {{FAQ}} more prominent on Minerva, because the template is kinda obsolete for this reason. Levivich (talk) 16:59, 9 December 2022 (UTC)

Would be nice if "important templates" could add an indicator in wikitext or an html class that the skin could use to make certain templates always show. RPI2026F1 (talk) 17:00, 9 December 2022 (UTC)

There is a discussion about the visibility of {{tmbox}} message boxes at Template talk:Mbox#Tmboxes not visible on mobile (all other mboxes are), the possibility of coming enhancements for it to be changed, and a workaround for those using the tmbox template directly. The FAQ template, though, uses the {{mbox}} template which selects a specific message box template based on the current namespace. One way to preserve this behaviour would be to add an option to the mbox template (and the underlying Module:Message box) that would trigger the workaround template to be used. isaacl (talk) 17:43, 9 December 2022 (UTC)

(On an implementation note, I see now that the workaround template uses mbox, so embedding the required workaround within the Message box module might be preferable.) isaacl (talk) 17:54, 9 December 2022 (UTC)

Place policy proposal

While it is true that WP:USPLACE states that U.S. locations "should never be titled 'City, State, Country' (e.g., "Kansas City, Missouri, U.S.") because that is contrary to general American usage" and it is also true that the country ("United States") is clearly listed in the Infobox for reference purposes and referenced indirectly in categories and other ways, it should be mandatory that "United States" be included in the introductory sentence of all pages on U.S. locations, including cities, towns, townships, boroughs, census-designated-places, etc. To date, for instance, to take one example, the Pompano Beach, Florida page opens with the following introduction, which is permissible currently:

Pompano Beach (/ˈpɒmpənoʊ/ POMP-ə-noh) is a city in Broward County, Florida.

Under this proposal, this would no longer be permitted and instead the introduction to all U.S. locations should be required to include the country ("United States"). In the example above, this means that the introduction must reference the "United States" in some capacity so that a compliant intro would read as follows:

Pompano Beach (/ˈpɒmpənoʊ/ POMP-ə-noh) is a city in Broward County, Florida, United States.

Keystone18 (talk) 20:09, 1 December 2022 (UTC)

Seems reasonable. Just because a state is American doesn't mean we don't have to give it proper context. --Golbez (talk) 20:15, 1 December 2022 (UTC)

Is the point of the lead sentence to disambiguate or to inform? The former supports the current status quo, while the latter supports the proposed policy. As an American, I feel these should be used only when necessary to disambiguate, such as locations in Georgia, to avoid confusion. "Florida" is just as obviously in the US as "Queensland" is in Australia or "Uttar Pradesh" is in India. Sungodtemple (talk • contribs) 02:19, 2 December 2022 (UTC)

And, again, I am biased as an American. Sungodtemple (talk • contribs) 02:20, 2 December 2022 (UTC)

but we include Australia in the opening sentence of Brisbane, and India in the opening sentence of Lucknow. So the examples you give appear to support including the name of the country. --Golbez (talk) 03:35, 6 December 2022 (UTC)

I would not make a hard-and-fast rule either way. Quickly scanning my print Britannica, I see St. Louis, Missouri, with a "U.S." designation and San Francisco, California, without, where both names are likely used for other places around the world, although not for places of equal importance. One problem is that "U.S." is cryptic and "United States" is wordy. It is easier to have country designations when your town is located in India or France. Dhtwiki (talk) 09:17, 2 December 2022 (UTC)

I am sympathetic to the argument that articles about cities and the like should include the country in the lede whenever possible, but I do not think a firm rule is needed (WP:CREEP). I suppose there could be many context-dependent factors; for instance, the would need to be exceptions for border disputes (what country should be in Jerusalem’s lead? what about Azad Kashmir or Perejil Island?).

Note that WP:USPLACE is about the article titles only, not the text of the lede. Tigraan^{Click here for my talk page ("private" contact)} 12:53, 2 December 2022 (UTC)

There are other ways to go about it, such as:

• Pompano Beach (/ˈpɒmpənoʊ/ POMP-ə-noh) is an American city in Broward County, Florida.
• Pompano Beach (/ˈpɒmpənoʊ/ POMP-ə-noh) is a U.S. city in Broward County, Florida.
• Pompano Beach (/ˈpɒmpənoʊ/ POMP-ə-noh) is a city in Broward County, which is in the U.S. state of Florida.

We could probably come up with half a dozen variations.

Speaking of variations, I suspect that the most widely known (by foreign audiences) states (e.g., California and New York) don't need disambiguation as much as some of the least well-known states. WhatamIdoing (talk) 19:58, 5 December 2022 (UTC)

Rather than adding a new rule, maybe it's sufficient to remove the offending sentence from WP:USPLACE: Articles on US cities should never be titled "City, Country" (e.g., "Detroit, United States") or "City, State, Country" (e.g., "Kansas City, Missouri, U.S.") because that is contrary to general American usage. This sentence is unhelpful on two counts. Firstly the italicized never denies any opportunity to use human common sense according to context. Editors should be free to add the country in cases where it's genuinely unclear to a non-American that the place is in the United States. Secondly, the justification "because that is contrary... usage" is illogical: in every country, it's general usage to assume that place-names relate to your own country. It's contrary to Mauritian usage to refer to Vacoas as "Vacoas, Mauritius", because everyone in Mauritius expects Vacoas to be in Mauritius. But most of the world has no idea that Mauritius even exists, let alone that Vacoas is a fairly major town within it. Wikipedia is a global thing, and we are writing for readers outside our own countries. We should recognise that our local usages might not be sufficient for a reader from the other side of the world. Elemimele (talk) 08:28, 6 December 2022 (UTC)

That would take an RfC to determine if consensus has changed, but note that the "Frequently asked questions" section at the top of Wikipedia talk:Naming conventions (geographic names) states that the question is now considered a tedious perennial proposal. Donald Albury 14:38, 6 December 2022 (UTC)

Thinking about this, most past RfCs on US place names have centered on whether including the state name in titles is required. Whether to allow "U.S." or "United States" in the title may not have been discussed as often. Nevertheless, an RfC is the way to change that. Donald Albury 15:04, 6 December 2022 (UTC)

I just removed that line from the FAQ. Adding/removing "US" is not on the list of perennial proposals, and anyway, the last time this was looked at was apparently 7 years ago. WP:CCC and all that. FWIW, I agree that we should include country for every country including the US, and saying that American sources don't usually do this is quite circular: since they're American sources writing about American places, of course they won't bother specifying the country. But Wikipedia is a global encyclopedia, and we should not assume readers know what Florida is, or any US state, or any country's subnational regions. There are of course exceptions for very famous places, like Paris and Tokyo, but to assume everyone knows what all the US states are is US-centric (and in the case of Georgia, hella confusing). Levivich (talk) 17:07, 9 December 2022 (UTC)

I think I support only half of the USPLACE sentence. This is good: Articles on US cities should never be titled "City, Country" (e.g., "Detroit, United States"). Kansas City is always going to be paired with Missouri. I think I disagree with all of the second half: "City, State, Country" (e.g., "Kansas City, Missouri, U.S.") because that is contrary to general American usage. Just because Americans are (i.e., should be) familiar with the names of all 50 states doesn't mean that non-Americans will recognize all of them, especially if we're talking about younger readers. I assume that kids in other countries aren't routinely tested on whether they can list off all 50 US states. Just like you'd normally write "Mumbai, Maharashtra in India" rather than leaving people outside of South Asia wondering whether this was a different Mumbai in a country whose name you don't recognize, we should normally indicate that the less well-known US states are part of the US. WhatamIdoing (talk) 16:46, 12 December 2022 (UTC)

Vector 2022 update (more info on VPT)

In the technical section, the Web team has posted an update on the Vector 2022 skin based on the communities' requests and RfC closure. We will also be having an open meeting for anyone that has questions this Thursday at 19:30 UTC on Discord. Thank you! SGrabarczuk (WMF) (talk) 20:38, 12 December 2022 (UTC)

This will be followed several months from now by a long discussion at the VP about how no one knew this was happening, what the Web team got wrong, and why Vector (2022) should be scrapped. (Because of course it will) Blueboar (talk) 20:52, 12 December 2022 (UTC)

Now, now. Just because that has happened some times in the past, including for at least one community-initiated, CENT-listed RFC held on this page and concluding with unanimous support, doesn't prove it will necessarily happen this time. But if someone's setting up a betting pool, put me down for a post at VPT at 21:18 UTC on Tuesday, 17 January 2023. Skin changes are extremely noticeable, and even if you decide that you like it in the end, it can take a few days, or even a couple of weeks, to get used to it. WhatamIdoing (talk) 21:15, 12 December 2022 (UTC)

“If they are going to change something, why don’t they change broccoli!” Harrumph! Blueboar (talk) 21:34, 12 December 2022 (UTC)

Proposal: Edit filter for non-admins changing the status of unblock requests

Various incidents have occurred regarding unreviewed unblock requests later reviewed by vandals, with the most recent occurrence happening here. I propose that there be an edit filter with the description: "Disallow; Non-admin changing the status of an unblock appeal". --Magnatyrannus (talk | contribs) 00:06, 13 December 2022 (UTC)

@Magnatyrannus: See Wikipedia:Edit filter/Requested/Archive_20#Tagging non-admins who accept/decline unblock requests 0xDeadbeef→∞ (talk to me) 00:14, 13 December 2022 (UTC)

Oh, sorry, didn't know that it was already under discussion. --Magnatyrannus (talk | contribs) 00:15, 13 December 2022 (UTC)

Central Notice / Watchlist Notice Banner for Sound Logo

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

---

There is a voting open regarding a new sound logo for Wikimedia. WMF has asked us to gain input via a Central Notice and Watchlist Notice (logged in editors only). Please see Wikipedia:Village pump (miscellaneous)/Archive 73#Sound logo vote + asking for permission for a banner? if you have any opinions on if we should advertise this vote or not. Thank you! — xaosflux ^Talk 11:14, 8 December 2022 (UTC)

• This was added as the CN, will likely do a WLN next week unless objections. (The CN is set to very limited display). — xaosflux ^Talk 16:04, 9 December 2022 (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.

Simple Wikipedia Site

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.

---

Hello! It seems reasonable to me to create a Simple Wikipedia for most natural languages. For example, the article https://simple.wikipedia.org/wiki/Washington,_D.C. is not available to a person in simple German or simple Italian. The most convenient way to create a base for all Simple Wikipedias would be to create the site simple.wikipedia.org. There could be switchable different languages in it. Why not create such a site? In addition, let's configure access to the file libraries of all other portals (commons.wikinedia.org, de.wikipedia.org, en.wikipedia.org, etc). I'd love to join in the editing. Could you please let me know what you think about my suggestions? — Preceding unsigned comment added by 87.116.167.90 (talk) 02:15, 20 December 2022 (UTC)

• The correct place to propose this is meta:Requests for new languages. I'm not optimistic the idea will gain traction, but that's the right place. -- RoySmith (talk) 03:52, 20 December 2022 (UTC)

  They woud almost certainly not accept it. Simple English Wikipedia only exists because it predates the current system and was grandfathered in. Simple German Wikipedia was rejected 4 times, although Simple French Wikipedia was marked eligible (meaning in theory were a critical mass of editors to form the wiki would be created) on the premise that a well-established "Simple French" standard exists, unlike for any other language. See m:Language proposal policy * Pppery * _{it has begun...} 04:20, 20 December 2022 (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.

Proposal: Show Good Article and Featured Article Icons On Mobile Devices

Tracked in Phabricator
Task T303650

I believe this may have been proposed in the past, but I feel it's something that shouldn't be too controversial to bring up again. I've been browsing Wikipedia on mobile devices for years now, even before I knew of the Featured and Good Article rankings on the platform. After becoming an editor and learning of these rankings, I find it bizarre how these icons that denote the quality of an article only appear on the Desktop version.

Checking the official mobile app, I have yet to find the feature that displays the icon indicating whether an article is a Good or Featured Article, or neither. Browsing on Google Chrome or other mobile browsers, the only time I can determine the quality of an article is when I set my browser to Desktop Mode and have to zoom in to the top right just to look at the icon. Either that, or I have to visit the talk page to see the article's class, or check the "page information" section to see its ranking. This action becomes quite repetitive as time goes on, as it ensures readers will continuously have to turn on Desktop Mode on Wikipedia almost every time they browse then exit the site, and partially defeats the purpose of browsing Wikipedia on mobile in the first place. The whole point of a mobile Wikipedia is to ensure that browsing the site will have the same features and experience as browsing the site on a PC or laptop. Eschewing a feature like this does little to benefit the user experience of Wikipedia readers - even casual ones - who may be interested in the quality of an article. I feel that as an editor and mobile browser, it would be just as beneficial for readers to have FA/GA icons show on mobile versions of Wikipedia as having them appear normally on Desktop Mode. This way, people who browse on mobile would not only be able to know the quality of an article, but may learn how they are generally organized so if they ever become future editors, they'll have a standard on what Wikipedia expects for Good/Featured quality articles. Simply put, it could potentially entice more mobile browsers to become editors and create well-written articles on Wikipedia.

TL;DR - Is there a way to place icons of Good and Featured Articles on pages in mobile mode? I don't think it should be that impractical of a concept to implement; all it would take is a small star or green plus icon right near the sidebars. PantheonRadiance (talk) 04:00, 18 December 2022 (UTC)

This is a very uncontroversial idea with the community, I believe. There is a technical problem however, {{#tag:indicator}} which is used to show GA/FA icons on desktop is not supported by the mobile site and app. There must be a phab: ticket somewhere that seeks to resolve the issue but it is not acted upon, yet. —CX Zoom[he/him] ^{(let's talk • {C•X})} 07:53, 18 December 2022 (UTC)

There are probably others of these that are even older, but phab:T303650 is a recent one that is open, it could get merged with an earlier duplicate but could still be used. @PantheonRadiance: as this would require an upstream software change that would likely apply to all projects I don't think we need a local proposal for it. It's worth noting that development effort on the "mobile app" upstream is not a very high priority from the staff and volunteers that do it, when compared with the mobile web view that is seen by more readers. — xaosflux ^Talk 12:42, 18 December 2022 (UTC)

@Xaosflux and CX Zoom: Thank you both for reading my request. I'm glad that there has been a proposal like this in the past, but it's a shame there isn't much of a priority for such features to be implemented for mobile WP. I hope it does pick up eventually so we could finally see FA/GAs easier on mobile mode. PantheonRadiance (talk) 22:00, 22 December 2022 (UTC)

About the Math section of the Appearance part of User Preferences

Tracked in Phabricator
Task T237516

Tracked in Phabricator
Task T325725

I suggest that a new option "MathJax" be added since it is used by arXiv, Elsevier's ScienceDirect, etc. By the way, what does the sentence "MathML can be enabled via browser plugin" mean? Since I'm really eager to enable MathML in Microsoft Edge, but does not know how to find a proper plugin to enable it.--RekishiEJ (talk) 15:53, 20 December 2022 (UTC) altered a word 12:25, 23 December 2022 (UTC)

• @RekishiEJ: adding new software features, such as MathJax, is beyond the capabilities of the English Wikipedia and would need to be requested upstream in MediaWiki. You can follow and comment more as to the MathJax3 development by going to phab:T237516 and its related tasks. Regarding the plugin, a request, phab:T325725, has been opened to provide better guidance about that. — xaosflux ^Talk 11:11, 22 December 2022 (UTC)

Wikipedia:Using neural network language models on Wikipedia

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.

---

This is not really a proposal but more as a proof-of-concept of how AI such as ChatGPT can integrate to Wikipedia. I'm trying to document my opinion and comments about the AI capability at the essay while improving an article with it. What do you think about it? CactiStaccingCrane (talk) 15:20, 23 December 2022 (UTC)

I think that AI-generated text should stay as far from Wikipedia as possible, personally. The fact that the sentence This demonstrates the impressive capabilities of Starship and its potential for future space exploration. was included as a response to the prompt "tone down the paragraph a bit and make it more in line with Wikipedia's encyclopedic voice" tells me that it's not there yet, which is unsurprising.

Speaking more practically, because keeping AI-generated text out of Wikipedia will probably become impossible at some near-future point, it probably makes sense to treat it similarly to how we treat paid edits (minus the ToU angle)--which is to say, mandatory disclosure if you're using AI-generated text, and *strongly* suggesting the use of the talk page (or draft space, for new articles), rather than inserting it directly into mainspace. Maybe that's just me. Writ Keeper ⚇♔ 16:24, 23 December 2022 (UTC)

I agree with this approach. Indeed, a lot of the edits that I've used AI are very heavily edited afterwards and doesn't really reduce the workload that much. It is really good however at giving you advice on how to improve your writing, brainstorming about what to write, even how to comply with Wikipedia policies, etc. I think that most people has approached ChatGPT in the wrong way, thinking of it as a magical fact-spitting box instead of thinking of ChatGPT as a very good writing assistant. CactiStaccingCrane (talk) 16:32, 23 December 2022 (UTC)

See also: AI alignment. CactiStaccingCrane (talk) 16:50, 23 December 2022 (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.