Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.


Mass creation of pages on fish species[]

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 ing", 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)Reply[reply]

WikiProject Tree of Life and WikiProject Fishes have been informed of this discussion. BilledMammal (talk) 02:55, 31 August 2022 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
Mass creation doesn't need to be at bot speed to be a problem. Masem (t) 23:11, 30 August 2022 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
using OUTCOMES to support mass creation is absolutely the wrong approach (its circular reasoning) Masem (t) 01:40, 31 August 2022 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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 ors 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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@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)Reply[reply]
@Plantdrew: Wikipedia:Bots/Noticeboard#Dams articles Levivich 01:58, 31 August 2022 (UTC)Reply[reply]
That was the one and only time that was done (at least that I can recall). BeanieFan11 (talk) 02:04, 31 August 2022 (UTC)Reply[reply]
I found some examples in the BRFA archives (1, 2, 3, 4, 5, 6). –xenotalk 02:12, 31 August 2022 (UTC)Reply[reply]
Every one of those ors, like Lumpsucker, deserve our thanks for seeking community input on this. Levivich 02:44, 31 August 2022 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
Why? I'm not convinced an article needs to say why it's important. Ortizesp (talk) 16:09, 5 October 2022 (UTC)Reply[reply]
It does. Andre🚐 16:19, 5 October 2022 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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 ors. Gnangarra 04:06, 31 August 2022 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
"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)Reply[reply]
The ongoing non-automated creation of new species articles by various ors has been the status quo here for twenty years and there is no need to pressure another or 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)Reply[reply]
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)Reply[reply]
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 ors 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 ors to Wikipedia. Gnangarra 14:51, 31 August 2022 (UTC)Reply[reply]

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 or? WhatamIdoing (talk) 23:46, 31 August 2022 (UTC)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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 or has time to write a more comprehensive article. BilledMammal (talk) 03:17, 1 September 2022 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
@AKAF: The question is how would you define bot-like s? 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 ors 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)Reply[reply]
@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)Reply[reply]
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 ed 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)Reply[reply]
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)Reply[reply]
"micro-stubs like these reduce the quality"
This is false and not in alignment with core ing 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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
So, it's basically a matter of opinion. It's the Wikipedia not ExxonMobile, so it one or 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 ors 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)Reply[reply]
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 for more than a few characters without the page hanging. Gnomingstuff (talk) 12:53, 16 September 2022 (UTC)Reply[reply]
WIkidata is looking at negotiating to be the central hub in DE Wakelamp d[@-@]b (talk) 08:18, 24 September 2022 (UTC)Reply[reply]

Add top icons for WP:Vital articles[]

To incentivize improvement to vital articles, a template should be created that display Círculos Concéntricos.svg the vital article icon to the top of the page, just like {{Featured article}} Cscr-featured.svg. If Cscr-featured.svg shows "someone has made this article really good", then Círculos Concéntricos.svg Cscr-featured.svg would show "someone has poured their heart and soul to make this article about an important topic real good" and a lone Círculos Concéntricos.svg would show "this topic is important but the article is currently kinda crap". I personally can already some objection to this idea (the vital article list isn't perfect, adding another top icon would increase maintenance, it won't actually encourage ors as you might imagine, etc.) but after personally working on these broad-topic articles for so long, I recognize the immense importance of signaling the impact of your work. A few pixels can do wonders to morale. CactiStaccingCrane (talk) 10:09, 18 September 2022 (UTC)Reply[reply]

P.S.: This is not a new idea as it have been implemented on other languages such as Vietnamese. Also, given that most people aren't aware of the GA/FA icons anyways, the focus of this proposal is more about incentivizing ors than informing readers. CactiStaccingCrane (talk) 10:14, 18 September 2022 (UTC)Reply[reply]
I think that this is an excellent idea but I am wondering what vital levels will it cover? My suggestion would be to start with the top 100 articles then a new level each year rather than doing all 10,000 at once. I think that this will help people get used to it as well as helping the project remain focussed.Gusfriend (talk) 10:44, 18 September 2022 (UTC)Reply[reply]
It will be the default level 3 – 1000 articles. More and the icon would lose its purpose. CactiStaccingCrane (talk) 13:55, 18 September 2022 (UTC)Reply[reply]
This would need some kind of threshold since tagging stubs as vital with a template visible to all would be a bit strange. This 3 section article is a vital topic... does seem a bit of a waste of time and energy for maintainers and doesn't provide much, like the aritcle it would be on. Terasail[✉️] 11:54, 18 September 2022 (UTC)Reply[reply]
The simple way to prevent this from happening is to not tag these articles, since all of the articles in the Vital level 3 lists are at the very list Start-class and above, with a fair amount of sections. Level 4 Vital article list is useful, but if used for publicity would stretch the effort too thin. CactiStaccingCrane (talk) 13:57, 18 September 2022 (UTC)Reply[reply]
I think this is a good idea. If it nudges casual readers to improve the article, great, but if it is just a visual distinction that long-time ors recognise without having to search for VA banner in talk page, it might incentivise improvements. CX Zoom[he/him] (let's talk • {CX}) 14:50, 18 September 2022 (UTC)Reply[reply]
Absolutely against, for multiple reasons. First, proposer admits that this is an ego-stroking effort to "signal the impact of your work." This is upside down and backwards - if you want an ego-massage, give yourself a barnstar. If improving Wikipedia articles gives you a warm and fuzzy feeling, you don't need an icon to "prove" it. As a side note, this is a wider issue than just this, but since it has come up before, it's worth stating again that ors are volunteers, not paid labor. Let them work on whatever they want to. Beggars can't be choosers. Second, proposer admits that this is for ors not readers, but why make an icon that's reader-visible, then? If it's not of interest to readers, then don't show it. Volunteers who want to work on vital articles can find VAs just fine without need for the icon. Third, as proposer already noted, the list of VA3s isn't "perfect", but more to the point, it's not an objective list. It's just a best guess. Which is fine when it's an internal tool to roughly guess at what the vital articles are, but you're proposing surfacing this to readers. If we're going to do that, then what was once a harmless internal tool is now external-facing, and you can expect news articles on "X% of Wikipedia's vital articles are of type Y, isn't that unfair." And those articles may well be right! For what? It would cause the list of VA3s to be much more discordant and argued over, for nothing. It's similar to how tests in school are useful as long as they don't matter, but as soon as you start tying funding or teacher assessments or the like to the test, then they become tainted. I would like to point out that our process for adjusting the VA lists is very dysfunctional currently with very little participation, something I think Cacti can agree with since he attempted to radically revamp the guidelines on how to do it, the talk pages, etc. awhile back. That's not a good sign if the contents of the VA lists are suddenly going to become reader-visible and thus more important.
Having said all of that, I'd just like to point out that I personally have put some major effort into improving articles on the VA list lest I be accused of not caring, but haven't needed an icon or a barnstar or anything to do so. I imagine this experience is not unusual. SnowFire (talk) 23:08, 18 September 2022 (UTC)Reply[reply]
I like this idea a lot. I think it effectively and succinctly signals important info to both readers and ors. The VA icon seems particularly suitable too. (Not to hijack, since I'm probably the minority here, but I'd like advocate for this icon to be displayed for mobile ors too. That said, I don't ever see the GA/FA icons either, but that's a different issue, I guess?) — LumonRedacts 02:31, 19 September 2022 (UTC)Reply[reply]

Wikidata lists[]

Should mainspace lists where the contents are pulled from and maintained at Wikidata be allowed or disallowed? Fram (talk) 07:25, 19 September 2022 (UTC) (ed same day at 13.35, see start of discussion section)Reply[reply]

Summary (Fram)[]

There is a number of lists where the contents are pulled from Wikidata through Template:wdtable row, with specific subtemplates for different types of content. The result can be seen e.g. here. The Wikipedia-only version of the same list can be seen here. Previous RfCs (see Wikipedia:Wikidata#Appropriate usage in articles have already agreed that "Wikidata should not be linked to within the body of the article except in the manner of hidden comment" and that it is "not appropriate to use Wikidata in article text on English Wikipedia ", but allowing Wikidata in infoboxes and de facto also many in external links templates. Previous lists where not only the contents, but even the entries were Wikidata driven have been disallowed in the mainspace as well.

The new type of lists has a number of disadvantages compared to enwiki-based lists, i.e.

Summary (MSGJ)[]

Thank you for starting this discussion and inviting me to present an alternative viewpoint. First, some background for those who may not be familiar with Wikidata. This Wikimedia sister project, launched in 2012, is designed to hold data for use by Wikipedias and other sister projects. Its use on the English Wikipedia is not at all new - it has been used extensively in infobox templates for many years now - so its use in data tables and lists should not be surprising to Wikipedia ors. I really thought and hoped that the "us and them" attitude towards Wikipedia and Wikidata had diminished over the years.

Being designed for this purpose, Wkidata offers many advantages over conventional wikitext for storing reliable data, including:

All data on Wikidata can (and should) be referenced, just as it is on Wikipedia. All changes can be monitored via RecentChanges (if you have the appropriate option selected).

The use of a template to produce the rows of the table has several advantages, including:

Finally, a word on the previous discussions about the use of Wikidata on Wikipedia. A table is not classed as "article text" so the prohibition on using Wikidata for article text is not relevant here. And, regarding the linking to Wikidata, the only link is the pencil icon mentioned earlier which is widely used and accepted in infobox templates. — Martin (MSGJ · talk) 17:04, 19 September 2022 (UTC)Reply[reply]

Discussion (Wikidata lists)[]

That said, I don’t think we have been very clear as to what exactly those limits ARE. We need to spell them out clearly. Do we have a guideline or policy section covering this? Blueboar (talk) 13:55, 19 September 2022 (UTC)Reply[reply]
I don't think its specific use in lists/tables has been put to RfC before. The closer of 2013 discussion wrote "There is a valid point raised that while running text is clearly not suitable for Wikidata use, it might be worth discussing use in tables specifically – but no consensus regarding this has been reached in this discussion." — Martin (MSGJ · talk) 18:09, 19 September 2022 (UTC)Reply[reply]
"Sep" as an abbreviation for September looks very odd in UK English, which would appertain to a list of Welsh people. The problem is the lack of easy-to-understand customisation. If I have five sources for a dob, I can choose to include only say no 3 because it is reliable & accessible, or put in two sources because one is highly reliable but not readily accessible, and another less reliable but accessible, &c&c. I have absolutely no idea how to do that within Wikidata, and no desire to have to learn a new and cumbersome ing interface. Also using things like n/a for the death date of a living person feels disrespectful. No clue how to make the links less prominent; I dislike them in infoboxes, but there's usually plenty of whitespace there to absorb them. Perhaps if they only showed in mode, somehow? And how are logged-out ors supposed to amend things? Espresso Addict (talk) 23:44, 1 October 2022 (UTC)Reply[reply]
@Espresso Addict: absolutely. If you are curating a list/table to such a degree then you will almost certainly want to forgo the convenience of the template and gain the greater flexibility. But 99% of lists are not like this, many of which are a bare list of links without additional information or references. For these, the template can produce a nice looking table with more detail, and is more likely to stay up to date. PS I use "Sep" all the time as an abbreviation for September, and it doesn't look odd to me! — Martin (MSGJ · talk) 15:51, 3 October 2022 (UTC)Reply[reply]
Its more that we do see the potential ... for abuse. And there needs to be either a strong mitigation or exceptional reason in place to ignore that risk. Which when it comes to wikidata, there rarely is. Only in death does duty end (talk) 16:47, 3 October 2022 (UTC)Reply[reply]
Particularly for lists that include BLPs, there is potential for BLP violation going unnoticed; a particularly common form of vandalism is to state a living person is dead, or less malevolently, to believe unreliable sources and assume incorrectly that death has occurred. This happens time and time again, and requires careful oversight. Espresso Addict (talk) 22:13, 3 October 2022 (UTC)Reply[reply]

Standardise the 'Go to bottom' button[]

Wikipedia screens with 'Go to bottom' highlighted

Wikipedia has several pages that are in the nature of forums - Help Desk, Teahouse, Village Pump pages, Reference Desk pages, Reference Desk Talk pages - where new content is frequently added at or near the bottom of the page. For the convenience of readers, they all have a 'Go to bottom' button of some sort. For the inconvenience of readers, each of these buttons is different; either in size, colour, horizontal position, or distance from top of page (see image). This makes it difficult to find and use the button when switching between different pages. It is unintuitive that a standard function does not have a standard control interface.

I propose that the 'Go to bottom' button be standardised on all pages where it occurs. I don't much care where it is or what it looks like (though the Reference Desk version is easiest to see and click) because if it is standard I will get used to it.

I propose also that the button be added to Article Talk and User Talk pages. -- Verbarson  talks 21:38, 28 September 2022 (UTC)Reply[reply]

Perhaps someone should make a gadget version of {{Skip to top and bottom}}, that people who lack an "end" key or otherwise need that sort of thing can enable to add floating buttons to every page. Anomie 11:41, 29 September 2022 (UTC)Reply[reply]
There is also this nice skip to top/bottom gadget that https://zh.wikipedia.org has. zh:MediaWiki:Gadget-scrollUpButton.js I like it quite a bit. —TheDJ (talkcontribs) 13:34, 29 September 2022 (UTC)Reply[reply]

Add the following to your common.js file:

// add link to the "Tools" menu -- ⇑ go to top
$(mw.util.addPortletLink( 'p-tb', '#', String.fromCharCode(8657)+' go to top', 'p-tb-top', 'Go to the top'))
  .click(function(e){ e.preventDefault(); $('html, body').animate({scrollTop: 0}); });

// add link to the "Tools" menu -- ⇓ go to end
$(mw.util.addPortletLink( 'p-tb', '#', String.fromCharCode(8659)+' go to end', 'p-tb-end', 'Go to the end'))
  .click( function(e){ e.preventDefault(); $('html, body').animate({scrollTop: $(document).height()}); });

In my case, the sidebar menus are locked to the top of the screen so I can always see the "go to top" item. For you, maybe just add the "go to end" code — GhostInTheMachine talk to me 13:44, 30 September 2022 (UTC)Reply[reply]

@Verbarson, could you explain more about why you want to skip to the bottom of the page? Whatamidoing (WMF) (talk) 22:45, 30 September 2022 (UTC)Reply[reply]
@Whatamidoing (WMF): I have a habit of browsing these pages to see what's new. What's new is mainly at the bottom of the page, so I go to the bottom and work my way up. I prefer to browse with a mouse (so I don't use the End key).
It has been interesting to see the alternative solutions given above, and I am trying some and may try others. My point is mainly that these pages already have a 'Go to bottom' button, but it is inconsistently placed and sized, and therefore clicking it does not become a habitual action. The Reference Desk has a nice big button - easy to see and click on - but it is tied to a position on specific Reference Desk side menu that doesn't exist on other pages. The Teahouse puts its button in small text at the bottom of all the header information, which takes a bit longer to find (granted that I visit the Teahouse less often).
If I had to pick a standard, I'd go with the Help Desk, which puts the button just under the standard menu bar, at the right hand side. That position seems to be available on almost every page. Having the button in small text doesn't bother me as much as having to search the page for it. It seems as if all these pages were designed independently by different people, each of whom thought a 'Go to bottom' button was a good idea, but didn't bother to check where previous designers had placed it.
As I understand it, this is not a skin-related issue. I use Vector 2022, but I assume the button doesn't move in other skins? -- Verbarson  talks 09:54, 1 October 2022 (UTC)Reply[reply]
@GhostInTheMachine: Thank you; I am trying those out now. -- Verbarson  talks 09:37, 1 October 2022 (UTC)Reply[reply]

Change URLs of IMDb links[]

This is the first time I am using the Village Pump. I hope I am doing this correctly.

All film and TV show pages on Wikipedia have IMDb as one of their "external links" at the bottom of the page. IMDb has been very difficult to use for a long time now, with pages being full of pictures and Amazon ads, and all sorts of things that no-one needs but which make the pages to take forever to load and make it generally cumbersome.

I recently learned that (apart from many other subpages everyone knows) there is also the "reference" subpage for each IMDb entry, which contains most of the relevant information on a boring, practical site and also keeps the right-hand sidebar neatly at hand for any additional info one might need. The "reference" page loads much quicker than the "main" page. Since there are many Wikipedia users in all corners of the globe who may have limited band-width and/or old hardware, it would be much better for them to not be directed to a film's "main" IMDb entry, but to its "reference" entry.

You can check out the difference for yourself in this example:

Main page for Zulu (as currently used on Wikipedia): https://www.imdb.com/title/tt0058777

Reference page for Zulu: https://www.imdb.com/title/tt0058777/reference

My proposal is to change all IMDb links in the "external links" section of each article from the "main" IMDb entry to the "reference" IMDb entry. I assume this can be done through a bot which would simply be adding "reference" or "/reference" to each URL (I admit that I am computer-illiterate, but bots have been used before to mass-change archive.org links, IIRC, so I assume this is possible).

Otto von B. (talk) 18:51, 29 September 2022 (UTC)Reply[reply]

IMDb links are generated using templates (this also means that no bot involvement is needed). See Template:IMDb for the list of templates. For titles, currently, only the /awards subpage (see parameter |section=) is supported: {{IMDb title|id=0111282|title=Stargate|section=awards}}Awards for Stargate at IMDb. See also relevant discussions at the talk page of the template. —⁠andrybak (talk) 10:26, 30 September 2022 (UTC)Reply[reply]

DYK elegibility criteria extension[]

I think DYK elegibility criteria should be expanded to new FAs (which hadn't got DYK) and to new FLs. It makes no sense to have GAs elebigle and not FAs and FLs. Dr Salvus 11:55, 1 October 2022 (UTC)Reply[reply]

GA makes you DYK eligible because that's a route for a new GA to get highlighted on the front page. FA's already get onto the front page, so DYK would be redundant with that. -- RoySmith (talk) 12:03, 1 October 2022 (UTC)Reply[reply]
What about FLs? Dr Salvus 12:07, 1 October 2022 (UTC)Reply[reply]
Featured lists also appear on the main page. Espresso Addict (talk) 23:46, 1 October 2022 (UTC)Reply[reply]

Is Wikipedia a genealogy site, or isn't it, or is it partly, or perhaps a teensy bit?[]

I've been around now for almost 15 years, logged in, and one thing bothers me especially. Info boxes are supposed, I believe, to give our readers quick, accurate facts about article subjects. But an article about a person born into royalty can only cause rather severe info-box confusion for any reader who is not a genealogist or at least aware of Wikipedia's stubborn and absolute policy of acting like Ancestry, MyHeritage, Geni and other genealogy sites where mothers traditionally always are listed by their unmarried names. The amount of our new/uninitiated readers who make corrections such as Queen Silvia, not Silvia Sommerlath, being her name when her children were born, and who then get reversed due to our stringent maiden-name pseudo-genealogy-site policy, are considerable indeed. It is an absolute fact (such as are sought by readers in our info boxes) that a woman named Silvia Sommerlath did not give birth to the royal couple's 3 children. People who see that and know no better have the intelligent right to assume that the king had an affair with a Ms Sommerlath. That's absurd! Genealogy sites are cleverly formatted so that they inform about couples who had offspring but never, or rarely, allege specifically that Princess Daughter is the daughter of Mother Maidenname. Wikipedia always does that, in all our pertinent info boxes.

Proposal In the info-boxes of people whose mothers were royal, Wikipedia policy should allow for actual facts, not genealogically-formatted idiosyncrasies, in info boxes regarding the names of all mothers when their children were born and it should not automatically be reversed when such facts are given in info-boxes, --SergeWoodzing (talk) 18:02, 3 October 2022 (UTC)Reply[reply]

Or uninformed. Facts: Queen Silvia's surname, legally, is * (that's right an asterisk), as used by the Swedish Tax Authority's official census for members of the royal family who do not use surnames. Were one to apply a surname to her anyway, it would be Bernadotte. --SergeWoodzing (talk) 20:23, 5 October 2022 (UTC)Reply[reply]