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.
Withdrawn. Thanks for all the feedback. I'll see about replacing just the WikiMiniAtlas part with Kartographer so there's a link to both Kartographer and GeoHack, which should be a straight upgrade as far as I know. Galobtter (talk) 18:53, 12 May 2023 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Support as proposer, I think displaying a much improved and modern map, especially on mobile (where currently readers don't even get an interactive map) is beneficial for 99% of readers. The people who still want direct access to geohack can enable it quite easily with the CSS. I see the utility in the regional mapping services that GeoHack links to, but Kartographer links to the most common mapping services in its "External Maps" section, and also includes a link to GeoHack for people who want that. Galobtter (talk) 07:21, 11 May 2023 (UTC)
Oppose The discussion at Template talk:Coord#Switching to Kartographer shows little support for ditching geohack and forcing people to use Kartographer. Geohack has a huge number of mapping services that have their own features that Kartographer does not provide. If geohack were to be amended to use Kartographer instead of WikiMiniAtlas, or to provide Kartographer in addition to the existing features, that would be fine. But the proposal above implies that people will need to jump through hoops in order to use the facilities that they can presently use easily. --Redrose64 🌹 (talk) 20:13, 10 May 2023 (UTC)
@Redrose64 Only three other people commented in that discussion. TheDJ very much wants this to happen and hike395 seems happy with the CSS hack to enable the geohack link. So as far as I can see, the only opposition there is from you. Kartographer has a link to Geohack in the external maps section, so it just requires an additional couple of clicks to get there, and people who use it regularly can enable the direct link very simply. Galobtter (talk) 20:19, 10 May 2023 (UTC)
I'm leaning oppose. If the purpose of GeoHack was just to provide an interactive map, then this would make sense. But GeoHack is more like an index of map services, including not just topographic maps like OSM but also satellite imagery, historic maps, historic and contemporary geocoding, nearby photos, place names, archaeological sites, etc. The coordinate formatting tool is also very useful (I use it all the time in my day job, actually). Kartographer seems to only have a very small subset of these features, unhelpfully hidden away behind an "external maps" button. If there are plans to add them to Kartographer I could support, but otherwise it's a huge loss of functionality just for the sake of a more modern UI. – Joe (talk) 10:40, 11 May 2023 (UTC)
Inclined to oppose as Kartographer has too narrow a scope compared to Geohack; not every person using a map on Wikipedia wants to know roads and towns. Jo-Jo Eumerus (talk) 07:44, 12 May 2023 (UTC)
Discussion (Updating Template:Coord)
I just tried the example link twice, and it crashed chrome on my phone both times. It appears to be trying to load a very large map, rather than option for mapping I see at the old link. -- LCU ActivelyDisinterested∆transmissions∆ °co-ords° 11:31, 10 May 2023 (UTC)
@ActivelyDisinterested The old link does not work on mobile. If you try the new link in mobile view it should work fine; I guess it is not optimized for the desktop site on mobile. But 99% of readers are going to be using the mobile site on mobile. Galobtter (talk) 16:39, 10 May 2023 (UTC)
Like many other editors on mobile I use the, improperly named, desktop version. The old link take me to a page with option but no map, as geohack is a separate site I get the mobile page. The new link crashes my phone, and I'm guessing anyone else in the same situation. -- LCU ActivelyDisinterested∆transmissions∆ °co-ords° 16:44, 10 May 2023 (UTC)
@ActivelyDisinterested Looks like Kartographer doesn't work that well when zoomed in on the link in desktop mode on a touchscreen device (mobile/tablet). I made the link fallback to geohack in that case. Does that help? Galobtter (talk) 21:00, 10 May 2023 (UTC)
This sounds like an out of memory of the phone. Opening a big page like this village pump (decoded already a pretty insane 3MB of pure HTML, before getting to JS/CSS and rendering), on a phone/tablet (especially an older/low-end one with 4 to 6GB of RAM or something) and then also opening a map, and then having the phone scale down that gigantic (desktop width sized, but in area actually 6x bigger, because its portrait) rendering surface to the size of the phone screen, while also loading extra javascript code, doesn't seem optimal. —TheDJ (talk • contribs) 08:50, 11 May 2023 (UTC)
While I do not expect this to be a very common problem, I did file a ticket to see if maybe we can better support the use case to avoid crashes of the browser. —TheDJ (talk • contribs) 09:40, 11 May 2023 (UTC)
I hope I am misunderstanding this proposal because at the moment I am feeling rather shocked. Is is really being suggested that a template transcluded over a million times would be replaced by a system obviously currently being debugged? Personally, I am not bothered by the icon leading to an interactive map. However, from desktop and mobile browsers (the latter in desktop and mobile modes) I want to go to a page with a range of mapping sites so I can choose according to my current interest. In particular for Great Britain I prefer to use Streetmap and it is highly convenient when there is a list of regional maps readily available. The testcases are not illuminating to me. Can there be some user-orientated examples, please? Can you suggest a CSS hack so I can temporarily test the proposed system? A CSS hack for users to retain GeoHack would not be acceptable in my opinion but a gadget might be. Thincat (talk) 08:54, 11 May 2023 (UTC)
@Thincat you can change {{coord to {{coord/sandbox on articles to preview the page with the new system, or look at pages on the French Wikipedia - for example see fr:Londres. As this system has already been implemented in frwiki and a few other wikis, it is obviously technically fine. You can also see a few more side-by-side examples at User:Galobtter/sandbox2. If people want a gadget a gadget can certainly be created. Galobtter (talk) 09:10, 11 May 2023 (UTC)
For me it is not technically fine. For the three examples you have added above, London, California and South Africa, all three give various errors, differing between mobile and desktop modes (Android, Chrome). I don't really want to continue beta testing. I suggest this proposal is premature so I won't formally !vote at this stage. Thincat (talk) 09:53, 11 May 2023 (UTC)
Sorry about that; I believe I've fixed the issue and I updated the examples to explain how to test on mobile. Galobtter (talk) 10:45, 11 May 2023 (UTC)
@Joe Roe: I'm going to piggy back off your comment rationale to write some more thoughts on this: all the features you mention definitely seem useful - for a certain subset of users (e.g. someone like you who uses coordinates in their day job). Speaking for myself as someone who is a reader in relation to geography articles, I remember my reaction to first opening up geohack was "this seems confusing, but I guess there's a link to Google Maps so that's useful" - for 95% of people, the limits of their mapping and coordinate knowledge is using google or apple maps, and the current UX is not the most helpful for those people (and I think it took me years to realize the icon next to the coordinates actually opened up a map rather than being just decoration). Geohack feels more like a useful external link than something that should be quite that prominent in articles.
I'll leave this RfC open for more thoughts, but there's not more support for this replacement, I'll withdraw this and mock up some options for just replacing WikiMiniAtlas and having both GeoHack and Kartographer links, which I think would make everyone happy. Galobtter (talk) 22:50, 11 May 2023 (UTC)
For 95% of people, the limits of their mapping and coordinate knowledge is using google or apple maps – I figured that this was the assumption behind the RfC, but has this actually been established anywhere? You could well be right, but it could also be that only geo-nerds like me actually pay attention to the coords in the first place. My preference would be to modernise GeoHack and incorporate Kartographer into it, but it sounds like what we really need is some research into what the majority of readers expect and find useful. – Joe (talk) 07:25, 12 May 2023 (UTC)
Also, getting a bit off topic here, but yes I am in a peculiar subset of users here. I teach cartography, and one of the first things I try to get across to students is that the hegemonic style of Google Maps (copied almost exactly by Apple, OSM, etc.) is not the only or default way to visualise space. In fact, for a lot of encyclopaedic topics the hyper-detailed, transport-focused topographic map Kartographer gives you is possibly the least useful map for a reader. For anything historical, or to do with the natural world, or just on a larger scale than a city neighbourhood, it gives you practically no relevant context and a huge amount of irrelevant details and labelling. One of the nice things about GeoHack was that it foregrounded the variety of different ways you could see the space around the same set of coordinates. Kartographer feels like a missed opportunity to build on that concept, instead just copying the same Google Maps-clone that every website uses nowadays. – Joe (talk) 07:39, 12 May 2023 (UTC)
Thanks for your thoughts. Someone involved in cartography education is an ideal person to hear from! geo-nerds like me actually pay attention to the coords in the first place that's fair, it's possible that the people who actually click on coordinates are the type to be interesting in such things.
On One of the nice things about GeoHack was that it foregrounded the variety of different ways you could see the space around the same set of coordinates. My feeling is that this goal is only accomplished if people actually can use and get to all those various other useful maps. Just out of curiosity, I decided to really take a look at and click on a bunch of links on GeoHack page for Berkeley, California, [1]. On the top left is a link to popular mapping services; obviously useful. On the top right is some various coordinates and identifiers, which is useful to geonerds. Looking at the "Global/Trans-national services" links, there are a few useful ones: sentinel-hub has some cool vegetation layers and OpenHistoricalMap seems interesting, and maybe a couple others. But most of the links are basically your regular google maps/open street map but worse, sometimes much worse and out of date, and two are straight up broken/the website doesn't work (NASA WorldWind and GeaBios). Looking at the United States specific maps, CalTop is pretty cool and works well, Historic Aerials is nice except it seems to require payment to actually see the aerials properly, but the NASA weather and US EPA link is broken, one of the sites requires registration to do anything (WP:ELREG), and USGS National Map Viewer does not take me to Berkeley.
Continuing down the page, the photos section is pretty useful. The nearby articles stuff is actually implemented in Kartographer and works pretty well. The other information section actually seems to have the most cool stuff—Old Maps Online has some genuinely cool old maps of Berkeley, and but again some links don't work (e.g. Flightradar24)—but it is stuck at the bottom. GeoHack also seems to link arbitarily to some commercial sites (why weatherUSA and not any of the other weather services?). A lot of the websites linked don't really feel like they meet 2023 standards for usability—I get the impression that most of the links were added in 2007 or something and not updated since—and I was disappointed at the number of broken links.
Overall my feeling is that GeoHack doesn't really feel up to being a reader-facing tool but more a tool for "geo-nerds" to get to the links they want to get to. But it also does feel like reorganizing the links by their utility (e.g. is their main utility a regular map, topographical map, historical map etc) and instituting some minimum standards a la WP:EL for the links there (e.g. can't be redundant to the big mapping services and no unnecessary commercial links) to trim the links could make it useful.
Anyway I suppose this is more an argument to improve GeoHack than hide it behind the "External maps" section of Kartographer. Galobtter (talk) 09:23, 12 May 2023 (UTC)
Pretty much everything map-related on Wikipedia feels like it's stuck in 2007, GeoHack definitely included. That's why I feel bad about straight up opposing using Kartographer, because it obviously is an improvement, and a sorely needed one. Sadly it doesn't seems to only receive sporadic attention from the WMF. GeoHack, at least, is easier to improve locally. – Joe (talk) 10:51, 12 May 2023 (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 show the status of reliability within articles
After encountering dubious sources through my edits on the project, it has been tiring looking through the backgrounds of each source through their dedicated articles or heading over to the long list of WP:RSP.
What I am proposing is a template placed in articles about sources, for example the article for ABC News with a template discussing the reliability of the source based on WP:RSP (a link to WP:RSP could be provided as well.
This template would be useful because:
It would provide readers information regarding potential reliability on the topic
Users could travel to the article through links in citations to see reliability designation according to WP:RSP
If the template includes a link to WP:RSP, it would encourage more participation by readers and users, broadening interpretation and discussion in WP:RSP decisions
A "note" function could also be provided in the template to provide nuance regarding the topic/source (ex. XXX is a partisan source regarding XXX)
The template may not be suitable for articles where the topic has been defined as "Generally unreliable", "Deprecated" or "Blacklisted" as it may violate WP:NPOV. I have reviewed Wikipedia:Perennial proposals#Define reliable sources and don't think that this template would be strictly defining which sources are reliable; the template could even be worded in a not so authoritative way. The template would just be used to show that the source covered in the article is "generally reliable". Overall, this may be a valuable tool for readers and users alike. WMrapids (talk) 22:17, 24 April 2023 (UTC)
I don't know if you know about User:Headbomb/unreliable – it's a userscript that highlights potentially bad sources based on their RSP designation. You might find that helpful for personal use. As far as your proposal goes, I don't think it's worthwhile to try and explain to readers which sources are reliable because (a) the majority of readers don't care; and (b) reliability is complicated. I was going to write a longer comment but I'm afraid this proposal is simply a non-starter, which I'm sure you'll realise if you think it through a little more. Sojourner in the earth (talk) 05:43, 25 April 2023 (UTC)
I could see links to pertinent RSN discussions being valuable on article talk pages, but those aren't appropriate encyclopaedic content. A little bit worried this would heighten the sense of overreliance on RSP, where unimpeachable sources never turn up due to too reliable. Folly Mox (talk) 05:49, 25 April 2023 (UTC)
I am opposed to this, not just because of issues with implementation, but because it would further worsen the situation with informal "reliability" scores being reified as stone-tablet law (perhaps I could call it "RSPism"). The core deal of it is that WP:RSP is not even a policy -- it's just a convenient page you can browse in a hurry rather than searching the full archives of WP:RSN. It is not some kind of official Bible on which sources are good or bad: Wikipedia is very poorly equipped to provide such a reference work, and using RSP as one contributes to it being low-quality. Essentially, the more important RSP becomes, the stronger our incentive (and indeed requirement) for people to go there and suit up for gladiatorial combat so that their sources win and their enemies' sources lose; for an example of what I mean, look at the regularly scheduled MMA tournaments over Fox News. These are easily among the worst-behaved events on the English Wikipedia, and I think that formally enshrining them as official policy (worse, official externally facing policy to readers) would likely push us over the point of no return to being a 100% political screaming website. jp×g01:29, 6 May 2023 (UTC)
And... then there's the problem of a source that's not "generally" reliable, but which is 100% reliable and appropriate for the particular sentence. PMID9500320 is a horrible source for any medical statement, but it's an authoritative source for the statement that the paper was retracted. So is that "reliable" or "unreliable"? I'd say I think you'll find that it's a bit more complicated than that. WhatamIdoing (talk) 00:58, 13 May 2023 (UTC)
Converting Indian numbering system
Hey all, I was wondering if someone could create a template like {{convert}} to convert the Indian numbering system (lakhs, crores...) to the common one we are used to (thousands, millions...), because I get confused and need to calculate it every time I see a number in this notation. Thanks. --Esperfulmo (talk) 18:16, 10 May 2023 (UTC)
It's a nice idea. I have to convert such numbers into hundreds of thousands, millions, billions etc. too, but let's remember that there are well over a billion (or a hundred crore) people who have to convert the other way. I just look on it as one of the things I have learnt about the world from editing Wikipedia. And also remember that the "we" who you invoke includes those people too. Phil Bridger (talk) 18:36, 10 May 2023 (UTC)
@Redrose64 do you know where that was? I'd like to read the discussion. It seems like a totally useful and logical thing to do, I'm surprised it was rejected. -- RoySmith(talk)17:02, 11 May 2023 (UTC)
Over the years several articles have been deleted for containing content that writers don't want to clean up, despite being encyclopedic topics, such as List of longest novels and List of people with autism spectrum disorders. So I am proposing that we create a requests for rewrite system as an alternative to deletion, where rather than the article being deleted, it would simply be blanked and rewritten in a way that follows policy. This would help save a lot of encyclopedic pages deleted due to a lack of this system. I have planned to userify a bunch of pages myself and create a list of "wrongly deleted pages", pages that I feel were wrongly deleted, but I will have to talk to an admin about that. Blubabluba9990 (talk) (contribs) 22:14, 14 May 2023 (UTC)
I was not aware of that until now. However, that seems to only be for before the article is deleted. Perhaps we could reform WP:RESCUE to include articles that have already been deleted. Blubabluba9990 (talk) (contribs) 23:03, 14 May 2023 (UTC)
We need your valuable input! As part of our ongoing efforts to improve the Wikipedia mobile app, we are seeking volunteers to provide their opinions on new designs for an upcoming feature in the iOS app.
To participate, simply visit this link and share your thoughts on the new designs on this talk page. We appreciate your time and contribution to this important project.
If you would like us to reach out to you for future volunteer projects, please feel free to email me.
Move planet symbols placed at the planets and moons' infobox title
Yes, I'm the proposer of this, but because this is a fairly trivial issue and there's a very strong consensus to NOT delete the symbol and instead move it somewhere else, I'm just gonna boldly perform the change to save everyone's time. Most also agrees to move the planetary symbol to somewhere else in the infobox, similar to what User:WhatamIdoing has proposed. It's time to make an edit request at {{Infobox planet}} then. CactiStaccingCrane (talk) 14:37, 17 May 2023 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Since WP:SOLARSYSTEM is inactive, I make my proposal here to aid visibility. So anyways, at almost all articles about planets on Wikipedia, there is a symbol next to its names at the infobox (example: the Sun, Mars, Ceres (dwarf planet), Triton). However, most if not all astronomers don't use these symbols anymore, as the International Astronomical Union has effective depreciated their use and the only practical use for them nowadays is for legacy abbreviations, such as M☉ for solar mass. Also, for most minor planets, there isn't a symbol for them as there's way too many of them, and many now are made by a random software engineer anyways. I'm all for putting these symbols somewhere else in the articles, but I don't see a purpose of putting them at such a prominent place in the article anymore. CactiStaccingCrane (talk) 06:21, 4 May 2023 (UTC)
I am quite surprised to learn, thanks to your note here, that these symbols were even used by modern astronomers. I thought these things were used by astrologists and the kind of astronomer who'd have drinks in the same bar with Copernicus and Kepler and maybe talk about recent developments in alchemy. Your note suggests these were used by IAU types in the 20th century, which I would not have guessed.
I'm therefore not a reliable commentator on the subject, but I don't see the inclusion in/above the infobox to be a problem. In fact, in my unqualified view, they seem well-placed there, as it might be just the thing a reader is looking to find out (maybe like, "my moon is in Venus, what's that symbol again?"). But they should absolutely be addressed in the text of the article, although I see after only a few cursory checks that our articles do not like uniformly to Planet symbols or Astronomical symbols; some link to one, some to the other, and I thought I flitted past one that didn't link at all, but of course now I can't find it. Interested to see what others think. — JohnFromPinckney (talk / edits)08:07, 4 May 2023 (UTC)
Oppose Wikipedia is a general encyclopedia, not a resource for professional astronomers. It has a historical perspective and so should cover such traditional usage rather than being recentist. Andrew🐉(talk) 08:53, 4 May 2023 (UTC)
I somewhat agree with this actually. But is it really worth it to put at the infobox's lead? Every planets/moons have an etymology section, so I think that these symbols should go there instead. CactiStaccingCrane (talk) 12:50, 4 May 2023 (UTC)
Oppose as a general proposal per historical significance for the major planets. Don't care what happens to minor planets. Discuss individual cases at individual talk pages. —Kusma (talk) 09:01, 4 May 2023 (UTC)
I don't see the harm of having the symbol there, but it would be helpful if the image was a link to Planet symbols rather than to the image file. I can imagine a number of people wondering what they're looking at. Barnards.tar.gz (talk) 09:33, 4 May 2023 (UTC)
How many of the symbol files are licensed as public domain or CC0 (or something else that doesn't require attribution or notice of the license), that we could do that? CC BY-SA 4.0, for example, requires attribution and notice that the work is under the license, both of which we satisfy via the link to the image description page. Anomie⚔12:17, 4 May 2023 (UTC)
CC BY-SA 4.0 seems pretty tolerant when it comes to attribution, which can be provided in "any reasonable manner", and I think having the image description page linked from the target (Planet symbols) of the image link would be reasonable (two clicks to get there rather than one).
The few I clicked through all claimed CC BY-SA 4.0. But you're welcome to go over to Commons and see if you can get a change to stick. Anomie⚔01:31, 5 May 2023 (UTC)
Support moving the symbols to lower in the infobox (under "Designations" would be my first choice, with the field name linking Planet symbol). I'm a person who overrides people's Company field in my contacts app with their sun, moon, and rising signs, which I find purpose to reference more frequently. I've got like tens of natal charts for friends and relatives saved in my profile at astro.com. I have an astrology tab open right now in this browser. But the title of the infobox doesn't seem like the appropriate spot for these symbols even to me. Also, since they're images instead of unicode glyphs, they look conspicuously horrible in dark mode. Folly Mox (talk) 13:12, 4 May 2023 (UTC)
Support removing contemporary minor planet symbols as WP:UNDUE weight to neologistic developments with no evidence of widespread use, Oppose removing traditional symbols as they’ve been around for centuries and are important cultural, rather than purely scientific, touchstones (think of the Mars and Venus symbols for sex/gender, alchemy and mysticism, etc.) Dronebogus (talk) 15:00, 4 May 2023 (UTC)
Oppose removal of reliably-sourced symbols - I did a BSc in astrophysics in 1999-2001 and these symbols were very much things that would be encountered in reading particularly older text-books at that point in my experience. I can't find my old text book but this one is very similar to what I would have had in my first year. These are still things that can be encountered by our readers and which it is helpful to provide to them if the symbols are reliably sourced. For the newer symbols I note the articles on newly-discovered dwarf planets use NASA's JPL as their source which typically would be a good source for astronomical facts generally. If there is something that genuinely is just a guy on the internet making up symbols then I'm OK to remove. FOARP (talk) 16:20, 4 May 2023 (UTC)
Oppose removal of reliably-sourced symbols, basically per what everybody already said (especially FOARP, who correctly noted that they are still in textbooks that might be read today). Even for the contemporary dwarf-planet symbols, Unicode includes most of them, and even NASA has used some of them (which FOARP has also pointed out). Those certainly did start from "a random software engineer", but they have clearly become more than just something he made up one day: Unicode and NASA are surely reliable enough sources to keep them around. As for the other asteroids, those are actually from the 19th century and made by astronomers, before they realised that they were not quite the same kind of thing as the major planets. Most minor planets don't have symbols anyway; keeping them around for the few which do have them does not seem to be too much. Double sharp (talk) 21:33, 4 May 2023 (UTC)
Support The title of the infobox is probably not the most appropriate place for these symbols. If desired, these symbols can be placed lower in the infobox. --Enos733 (talk) 22:44, 4 May 2023 (UTC)
Weak oppose as we should keep the symbol, but it does not need to be in the prominent position at the top, and could move to be internal to the infobox. Graeme Bartlett (talk) 00:08, 5 May 2023 (UTC)
Oppose for the major planets:even if they are not used today, they were used frequently in historical times and are important symbols in a historical context. Less sure about the more-recently created (or "made up") minor planet symbols. Edward-Woodrow (talk) 00:34, 5 May 2023 (UTC)
Support. I concur with Folly Mox that the symbol be put in the infobox, and prefer the Unicode symbol. It being in the title feels... unideal. SWinxy (talk) 23:52, 6 May 2023 (UTC)
Support lowering them. They should definitely stay somewhere in the article (probably lower in the infobox), but the top of the infobox is giving them undue prominence relative to their current use. Thebiguglyalien (talk) 16:13, 7 May 2023 (UTC)
Oppose removing them, but support moving them lower in the infobox if that's what's preferred. ResPM (T🔈🎵C) 12:42, 11 May 2023 (UTC)
Support moving them lower, and inside the infobox only. I see no reason that the symbol should be above the infobox and in the title. — HTGS (talk)23:52, 11 May 2023 (UTC)
CactiStaccingCrane, I agree that it's a weird to put these symbols right at the top of the infobox, as if they were part of the official name. What do you think about moving it lower in the infobox, perhaps like this? WhatamIdoing (talk) 01:27, 13 May 2023 (UTC)
Oppose removal of symbols (most of them are well-sourced and included in Unicode already) and support lowering at a more convenient place in the infobox rather than in the title. Chaotic Enby (talk) 05:32, 14 May 2023 (UTC)
Keep, but lower in infobox - infobox titles are often used for metadata and other purposes, so the title field should be clean and simple text only. -- Netoholic@17:03, 14 May 2023 (UTC)
Keep symbols. They are historically important, and I believe all of them are deep-historic or roughly contemporaneous to the planet/minor planet/asteroid's discovery. It was a major thing back then; that they aren't used much anymore doesn't mean we should edit out the history. I believe they stopped being used because the symbols were getting too complex as more and more asteroids got discovered, to the point that they were no longer useful, but, again, they were still used. Obviously, they need a decent source. Adam Cuerden(talk)Has about 8.3% of all FPs. Currently celebrating his 600th FP!17:35, 14 May 2023 (UTC)
I think that everyone is misunderstanding me. I don't agree that we should get rid of the symbols outright, as I've said in the proposal: I'm all for putting these symbols somewhere else in the articles, but I don't see a purpose of putting them at such a prominent place in the article anymore.CactiStaccingCrane (talk) 17:38, 14 May 2023 (UTC)
I suspect if they aren't in the infobox, they aren't going to appear consistently. That said, I don't think they need appear at the top. Rearrange their position in the infobox all you want. Adam Cuerden(talk)Has about 8.3% of all FPs. Currently celebrating his 600th FP!17:44, 14 May 2023 (UTC)
I do agree with you on this. An entry in the infobox is much better imo. (Also the title of the proposal is "Remove planet symbols placed at the planets and moons' infobox title", not infoboxes in general) CactiStaccingCrane (talk) 17:47, 14 May 2023 (UTC)
Ah, then, makes sense. Agreed. It looks like - with a few exceptions - editing {{Infobox planet}} to move where the symbol parameter displays will be sufficient. Sun might need more work. Adam Cuerden(talk)Has about 8.3% of all FPs. Currently celebrating his 600th FP!18:17, 14 May 2023 (UTC)
I think I see the problem here: You titled this section "remove symbols" but merely meant to move them. I suspect there's little real controversy for what you meant, as long as you do it in some way similar to Redrose64's example, just you misspoke slightly. Adam Cuerden(talk)Has about 8.3% of all FPs. Currently celebrating his 600th FP!01:02, 15 May 2023 (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.
Streamline the sign-up process for new editors from China
Currently, the sign-up process for new users in China is very hard. To access Wikipedia in China, one must use a VPN to bypass the Great Firewall. To edit through a VPN, editors must first apply for WP:IPBE, but that puts them in a catch-22. WP:IPBE states, "Editing via an anonymous proxy, including open proxies and VPN services, can be easily abused. In this case, IP block exemption is granted only to trusted users. Examples of editors who may reasonably request an exemption include users who show they can contribute to the encyclopedia, and existing users with a history of valid non-disruptive contribution." This basically means that new Chinese users can't edit on Wikipedia because they need to have IPBE to do so, and to get IPBE, they need to have previously edited on Wikipedia, which basically means they are stuck this way unless they travel to Hong Kong, Macao, Taiwan (which don't block WP) or a foreign country, get a good history of edits there on an allowed IP address, then request IPBE, or they would have to ask a friend outside mainland China to set up a VPN on their residential Internet connection (if they have a friend outside of mainland China).
Although I currently am staying in Hangzhou and going to Zhejiang University, I am very lucky and blessed to call Canada home, where I can gain access to Wikipedia through normal means, sign up normally, get a good reputation, and request IPBE for use in China.
Mainland Chinese editors have made many very good contributions to Wikipedia. Some of my favourites are User:N509FZ and User:MasaneMiyaPA (the latter mainly uploads Commons photos), who are transit photographers who have photographed many public transit systems around China. Just go see many articles about the Beijing Subway or Hangzhou Metro, and you will see their photos. I think that by making it easier for mainland Chinese editors to join Wikipedia, there can be more coverage on niche topics in China such as Chinese public transit, and it can allow "insiders" who experience living in China first-hand to document things in China.
We could streamline the sign-up process through one of several ways (just one way is necessary):
Set up a special sign-up portal exclusively for users in China that contains only a sign-up form on a hidden IP address to avoid DNS poisoning (the sign-up portal would contain no articles to avoid upsetting the censors, causing the portal to be blocked), with the IP changing frequently to avoid blocking. Have a special button on Wikipedia to "request sign-up from China", and when that button is clicked, the user will receive an email to the sign-up portal's IP address. The user will then disconnect their VPN, go to their mailbox (such as QQ or 163), and click the IP address to access the sign-up portal. The sign-up portal detects the IP address of the user, and if the user is on a residential China Mobile, China Unicom, China Telecom or China Broadnet IP (the four ISPs of China), the sign-up will proceed normally, and the user will be automatically granted IPBE, so they can then edit normally. (If the user is not in China, they are not allowed to use this special portal to gain IPBE.) Then, the user simply reconnects to their VPN, goes back to the main WP website, and starts editing.
Ask Chinese users to verify their phone number through SMS to instantly gain IPBE, to prove that they are in China. At the same time, this also has the positive effect of preventing people in China from creating sockpuppet accounts. (Such a page would accept Chinese phone numbers only, as it is not necessary for people in other countries to verify their phone number.)
Ask Chinese users to pay a token amount such as CNY￥0.01 (worth only a fifth of a Canadian cent) using Alipay or WeChat Pay in an automatic sign-up portal to gain IPBE. This is not to make money or collect donations, but to verify that they are in China. (One cent RMB is nothing and will cause absolutely no financial burden for editors, as Taobao gives out roughly 10-50 cents for free every day in their 一起摇现金 promotion, where the user can shake their phone daily and get this small amount deposited directly to their Alipay account.)
It's not easy, and you need to wait and you can't start editing immediately, which puts Chinese new editors at a disadvantage compared to other new editors around the world. There are also closed proxies just for using Wikipedia, but you need to request them manually. I think that by 100% automating the sign-up process for Chinese editors and letting them start instantly, we can increase the numbers of Chinese editors on Wikipedia. Félix An (talk) 00:39, 19 April 2023 (UTC)
The most common way to request an account in zhwiki is to send an email. An admin will create the account and grant IPBE for you. However due to the large amount of account requests, this process can take 14 days or even more. MilkyDefer06:21, 30 April 2023 (UTC)
Having the prospective Chinese users to sign up and verify using their phone numbers or bank details/mobile wallets may open up a can of worms on the privacy front if these Chinese users want to remain anonymous to the government.
To transact mobile wallets in China, there needs to be an organisation to do the necessary paper work with Alipay and/or WeChat Pay. My last knowledge is that the Wikimedia affiliate in China has been derecognised due to the zhwiki admin corps being infiltrated by CCP members among other issues, while WMHK is more or less not operational after the last riots. – robertsky (talk) 14:25, 21 April 2023 (UTC)
On a side note, I don't think there's anything wrong with people simply joining the CCP or any other political party. Anyone can edit Wikipedia as long they adhere to NPOV. Félix An (talk) 00:26, 25 April 2023 (UTC)
Additionally, Hong Kong people are still allowed to edit Wikipedia, as long as they adhere to the new national security law. This law does not affect the editing of most Wikipedia articles. Félix An (talk) 00:28, 25 April 2023 (UTC)
When editing other topics that are unrelated to China, such as articles in science. Not everyone goes on Wikipedia to edit political articles. Félix An (talk) 02:47, 26 April 2023 (UTC)
Oh, definitely. It is no different from people being in the Democratic Party or Republican Party, except when such people decide to stray into COI or POV area, either by choice or by orders from their superiors. Given the autocratic nature of CCP, we can assume that someone top down will order the censorship of various topics. – robertsky (talk) 06:09, 1 May 2023 (UTC)
As long as they adhere to WP:COI and WP:NPOV, just like all other Wikipedia editors, their edits are welcome. For example, if they joined the party, they may not want to edit the article about it, to avoid adding content that is not NPOV. Félix An (talk) 00:23, 2 May 2023 (UTC)
I would like to point out that the reason for the derecognition is that the affiliate (WUGC) did not submit an annual activity report in 2020. You might refer to another User Group in China named WMCUG, whose main active members were banned or de-sysop-ed due to "community capture" in 2021. The Chinese Wikipedia community does not regard the WMCUG as an infiltrator for the Communist Party, nor did the Foundation say so. --魔琴 (Zauber Violino) (talk) 13:37, 2 May 2023 (UTC)
Failed alternate proposals
There's much better and simpler solution. Wikimedia Foundation has a lot of money and a lot of server capacity. So they can set up free VPN (or proxy) service for users from China and other restrictive countries. Benefits:
No need for any exemptions, 'cause it's our own VPN/proxy
No privacy issues, 'cause VPN can be diskless (no saving of data on provider's side)
Better privacy and safety for editors, 'cause they'll use our pro bono VPN
Better use for the Foundation's riches than paying high salaries to staff.
Downside:
That VPN/proxy can be blocked by the Great Firewall too.
1. Yep, your downside's right. China has blocked pretty much every mainstream free VPN out there.
2. This can open up the same can of worms that lead to open proxies being banned in the first place. How would we stop people from circumventing a block with this VPN? Aaron Liu (talk) 00:27, 24 April 2023 (UTC)
How about another Alternate Proposal then: set up an officially-licensed Chinese mirror of Wikipedia at "wikipedia-cn.org", "wikipedia-china.org", "wikipedia.cn" or something like that. This hypothetical mirror website is officially ICP-licensed and is a mirror of Wikipedia in all languages. Chinese editors can sign up and start reading and editing normally. The only difference is that articles that do not comply with Chinese laws are censored, such as the Taiwan which incorrectly states that it is a country, Uyghur genocide, etc. Note: I am in no way trying to undermine WP:UNCENSORED, and the regular Wikipedia would have no changes made to it, but partial censorship of WP is at least better than complete censorship of WP, and we would have to make a compromise. Félix An (talk) 07:48, 24 April 2023 (UTC)
If this mirror existed, I would use it 99% of the time for faster speeds so I don't need to connect my VPN. In the occasional instance when I need to view or edit something politically sensitive in China, I would simply turn on the VPN. Please understand that China is the second most populous country in the world, and in my opinion, to improve the compliance with the WP:UNCENSORED rule, having an official Chinese mirror would better adhere to that rule, since assuming that 10% of Wikipedia articles are critical of the Chinese government, a 10% censorship of Wikipedia is obviously better than 100% censorship of Wikipedia. And if the users want to edit the 10% of politically sensitive articles, they can get a good reputation editing the 90% uncensored articles, request IPBE, and then connect their VPN to edit the remaining 10%. I would sacrifice everything I had for this mirror! It would not only benefit me, but the 1.4 billion people of China, because they can gain access to a well-written freely-licensed Creative Commons encyclopedia! Félix An (talk) 07:54, 24 April 2023 (UTC)
I imagine the WMF would be against that for philosophical reasons. We also have to consider the logistical issue of determining whether content is visible to China. Snowmanonahoe (talk) 11:24, 24 April 2023 (UTC)
How is that even more damaging? Isn't being able to edit 90% of Wikipedia without a VPN better than being able to edit 0% without a VPN? If you wanted to edit the remaining 10%, you can simply get IPBE after editing the 90%, and simply turn on the VPN, as I am doing right now. Félix An (talk) 08:31, 25 April 2023 (UTC)
Wikipedia doesn't consist of just political articles. Some people forget that Wikipedia has a plethora of articles on science and technology as well. Félix An (talk) 00:42, 27 April 2023 (UTC)
Every field out there is quite interlocked, and there’s no exception that a lot of non-political subjects will involve politics.
My point still stands that editors can still edit non-political articles. Most articles about science and technology are fine. Félix An (talk) 08:04, 28 April 2023 (UTC)
There's already multiple mirrors, including en.jinzhao.wiki . A comprehensive list of mirrors is available at WP:MF (and a better list at its Chinese counterpart zh:WP:MF). Plus these mirors are ALSO open proxies as they all just sign in to WMF servers with the same IP of the server that hosts the mirror. Aaron Liu (talk) 12:37, 24 April 2023 (UTC)
I forgot to mention: edits on my hypothetical Wikipedia China appear on the normal Wikipedia in real time. That's what I'm trying to propose. Félix An (talk) 00:24, 25 April 2023 (UTC)
You can edit through two of them (including the one I mentioned) if you have an IP block exemption. Like I said, due to the nature of mirrors sending requests like open proxies they should be subject to similar restrictions. Though if a mirror sent edits as individual IPs that would be fine. But then the censorship part would be very tricky to implement. Many articles have a bit of content the CCP will find objectionable, how are we gonna redact them all while preserving compatibility with the uncensored version? With so many netizens how do we prevent them all from adding objectionable content while not having patrollers violate uncensored as these changes also get pushed to the uncensored version? Aaron Liu (talk) 00:33, 25 April 2023 (UTC)
We only need to block the main controversial articles. There are bits and pieces elsewhere that might refer to them, but at least the most controversial parts are blocked. We don't need to "rewrite" them for China, just simply blocking them will do. Félix An (talk) 04:44, 25 April 2023 (UTC)
Also, the whole point I was trying to get across was that IPBE would be not needed for editors in China, so Chinese editors could start editing right away. Félix An (talk) 04:47, 25 April 2023 (UTC)
Your last sentence was "how do we prevent them all from adding objectionable content while not having patrollers violate uncensored as these changes also get pushed to the uncensored version?" One solution to this problem could be to have a team of patrollers specifically designated to monitor the Chinese version of Wikipedia and ensure that no objectionable content is added. These patrollers could be based in China and have a thorough understanding of the country's laws and regulations. (Or we could simply use an AI.) Additionally, there could be an AI system in place similar to ClueBot to automatically flag any potentially biased edits made to the Chinese version of Wikipedia for review by these patrollers before they are pushed to the uncensored version. This would help to prevent biased content from being added while still allowing for Chinese editors to contribute to the site. Félix An (talk) 00:36, 27 April 2023 (UTC)
You shall remember that there was a pro-CCP media, heavily criticized that Wikipedia advocates the independence of Hong Kong, simply because the infobox for a person born before 1997 states that he was born in "British Hong Kong", not "Hong Kong SAR".
Insane people are everywhere in China. I personally believe inviting them brings chaos to Wikipedia. MilkyDefer 06:36, 30 April 2023 (UTC) Feel free to ignore this. Personal rambling. MilkyDefer15:06, 30 April 2023 (UTC)
Denying groups because they're insane is against the principles of Wikipedia. Could you give a link of that article? Also, are you sure that wasn't a self-media (for these who don't know you could say it's a selfpub)? What's a MINQI? Aaron Liu (talk) 14:05, 30 April 2023 (UTC)
I apologize for being not able to recover the original article. You can safely ignore my rambling. Yes, I really mean User:MINQI. From my recollections, his view on media outlet's reliability completely blew up my mind. (eg: zh:Special:Diff/63955463, "Global Times should be generally reliable, VOA should be generally unreliable or blacklisted") He is also frequently seen in ANI, VIP and 3RR noticeboards, blocked several times. I am not willing to say further. I will not bring Chinese Wikipedia affairs to English Wikipedia. MilkyDefer15:05, 30 April 2023 (UTC)
But I really believe that many Chinese media heavily criticizes Wikipedia. For example you can try searching "Wen Wei Po" and "Wikipedia" together. There is possibility that we may have systematic bias, and including them will make Wikipedia more neural. This possibility exists but I am not sure. MilkyDefer15:11, 30 April 2023 (UTC)
Jesus Christ that's a very funny thread. Still the user appears to have changed since 2021, and just one user shouldn't account for all of China. Aaron Liu (talk) 15:23, 30 April 2023 (UTC)
Nevertheless, since this is related to China, I have notified the Chinese Wikipedia community of this discussion. If WMF is to provide an official mirror site or VPN, Chinese users' first stop will be Chinese Wikipedia. MilkyDefer15:28, 30 April 2023 (UTC)
These clearly aren't from or about mainland China, which is the only Chinese territory that has Wikipedia blocked. Aaron Liu (talk) 19:26, 30 April 2023 (UTC)
I'd like to point out that censored Wikipedia versions do exist. One called "Wanwei Baike" mirrors and censors articles and does some find-and-replace-ment. And what happened next? It was blocked (probably twice). So if we are to make an official censored Wikipedia site, in which way should we do it and will it be blocked like that one? --魔琴 (Zauber Violino) (talk) 17:42, 30 April 2023 (UTC)
I'm not sure if it was blocked or if they just went down because of low-traffic and it's inferior UI. Either way, I think we may need to contact the Chinese government to do such a thing, which is yet another point against the idea of an official mirror. Aaron Liu (talk) 19:29, 30 April 2023 (UTC)
@MilkyDefer:Please tell them the fact and behave yourself!
You and other ones who from Hongkong or Taiwan want to take all mediaes from Mainland China as unreliable or blacklisted, as well as reject to admit VOA is an International broadcasting. Even one of editor from Taiwan mixed status of ,,Deutsche Welle and ZDF! It's really ridiculous!
You have defamed me many times at many social mediaes (at least in two Telegram groups), just because what I say is right when medias are discussed, but that not satisfying to you and your like-minded people. This is just one of the examples.
By the way, why do you not tell them how to block someone by using Tag team, just as what I have been treated.
PS: I signed up wiki when I study in Germany and just because someone has written something wrong. This is also the reason why my ID is my name, I used to trust wiki is just one place to spread knowladge and facts. But now unfortunately because of the people like you, it, at least zh.wiki is degenerating. MINQI (talk) 23:25, 30 April 2023 (UTC)
Secondly, while MilkyDefer may have some biases against the CCP, wanting to tag almost all major media from US as questionable on all topics is even worse than that. Even Fox News is reliable on nonpolitical topics. Plus, just that a media is international doesn't make that unreliable. If anything, it makes them more reliable. The sources are based on consensus on their content, and VOA, though state-owned, is reliable in almost every case.
Thirdly, there is no tag team here. The This link you linked to has you opposed to because you are confusing said website's opinion section with their articles. Aaron Liu (talk) 23:19, 30 April 2023 (UTC)
1.sorry, I just clicked "Reply";
2.I have never tagged all major media from US as questionable. Or I took The Washington Post，"NYT" and so on as sources, is just to contradict myself. And about "International broadcasting", it's not because of " international" but the reason, why they are setted up, and thier listeners.
3.Thank you for your reminder. It should be "Wikipedia:Tag team". They did it as teamwork at that time. They talked in Telegrm group and one of them reported me as WP:POINT. After I was blocked, they hidded my opinion although what I saied is similar to the final conclusion. MINQI (talk) 00:07, 1 May 2023 (UTC)
To respond to some comments above: people who want to help to build to the encyclopedia who anyone can edit should be welcomed, not shunned. This community should take efforts to help people contribute to building our compendium of free knowledge even if their government denies them their inalienable rights. We should absolutely not deny people from participation in Wikipedia owing to their nationality or national origin, nor should we proactively assist repressive governments in denying their citizens their right to free knowledge. — Red-tailed hawk(nest)00:27, 1 May 2023 (UTC)
@Piotrus: I refer you to the (now-partly-struck) comments above. I understand that there are very real problems on ZhWiki (indeed, the WMF took extraordinary actions not all that long ago), but I don't think the answer to that is to refrain from making it easier for people from China to edit EnWiki. — Red-tailed hawk(nest)00:56, 1 May 2023 (UTC)
On a related note, I just renewed my IPBE! 🙂
But anyways, I think since Wikipedia's mission is to be an encyclopedia that anyone can edit (as long as editors abide by NPOV and other rules), we should try our best to fulfill that by making it easier and quicker for Chinese editors to start editing. It doesn't matter if they live in China, or even if they joined the CPC or the CYL. We don't discriminate towards people who joined certain political parties in other countries. As long as they abide by the NPOV, their edits are welcome and much appreciated, especially photographic contributions. Félix An (talk) 01:36, 1 May 2023 (UTC)
Some final thoughts after calming down: If Chinese users can abide to Wikipedia rules like NPOV, and willing to follow community concensus, I believe that Wikipedia will become better. But if most users treat Wikipedia as an ideology warfare that they must conquer, I'd suggest not inviting them to avoid chaos. From my personal experiences, Wikipedia is labeled "anti-China" as my links shown above, and China has blocked WMF's multiple attempts to join WIPO due to Wikipedia containing anti-China (saying Taiwan is a country, etc) materials. There is a high possibility that the 500 million internet users in China might storm in and cause trouble. MilkyDefer01:52, 1 May 2023 (UTC)
Is it really appropriate to ask this question here? In fact, our community has also discussed similar issues, mainly because of the technical need to hide or face greater blockade; policy (for the Chinese government) is unlikely to be allowed; the proxy server provided by the community has trust question. At this stage, new registered users are allowed to register and grant permissions on their behalf through the administrator mailing list. I or the community is not sure the Foundation is willing to play cat and mouse in technology? --Cwek (talk) 02:11, 1 May 2023 (UTC)
If you want to offer a licensed, censored site in China, you're probably looking for qiuwenbaike（求闻百科）, an alternative run by the folks at WMC. --Cwek (talk) 02:18, 1 May 2023 (UTC)
How about my original idea of simply having an optional instant automatic IPBE gaining portal for Chinese users? This way, editors can start editing on the normal Wikipedia instantly. Many people in China already have VPNs for "scientific browsing", so all they need is a Wikipedia account that has IPBE. Félix An (talk) 06:03, 1 May 2023 (UTC)
I don't think there is an easy way for it to happen. Your suggestions on how to verify that these editors using VPN are from China requires some form of private information collection/processing which the Foundation is resistant against, as enshrined in the Privacy Policy, which enwiki ascribes to as well (see footer for link). Heck, they are not even going to comply to upcoming Western regulations on this front (see [4]).
Again, I re-iterate my point that it may also put these editors at risks of being identified by CCP easily if they do not want to be identified in the first place. In the eyes of authoritarian regimes, there is a difference between consuming unfiltered content for official or 'scientific' (whatever it is) purposes and actively writing content without their oversight. As an example: the persecution of Ai Weiwei over his activities in China (Uninterestingly, his zhwiki article isn't migrated into Qiuwenbaike). – robertsky (talk) 06:38, 1 May 2023 (UTC)
WP:IPBE already collects the IP address, I’m not sure what you’re talking about on “the foundation is against this”, it already happened. Plus, the IP address collected is that of the VPN, not the user themself, so it does not put users at risk just by allowing them to sign up. Aaron Liu (talk) 11:41, 1 May 2023 (UTC)
His proposal includes verification that the registered user on the VPN is from China and involves either verification via SMS or using WeChat Pay. This is not covered by WP:IPBE. Doing such verification opens up the registered user to authorities tracking these users down if they wish to since there are now traces within Chinese telco systems and/or WeChat that these users have requested some form of verification with Wikipedia. Unless mass surveillance in China isn't a thing? – robertsky (talk) 13:58, 1 May 2023 (UTC)
The first option that involves simply verifying their Chinese residential IP address. That may be a better option. Félix An (talk) 00:20, 2 May 2023 (UTC)
The point is, I want some instant way of verifying a user is in China, and if it succeeds, they instantly gain IPBE and can start editing right away, just like the rest of the world. Félix An (talk) 00:25, 2 May 2023 (UTC)
When you do the IP verification, you disconnect the VPN and use a hidden temporary portal designed specifically for this purpose. Félix An (talk) 02:32, 3 May 2023 (UTC)
The other thing is, many people use Google, Telegram, etc. in China by using a VPN. They will use their cell phone to verify their account in these cases. Despite these services being banned in China, they still can send SMS to Chinese phones, and they even follow the Chinese standard of putting the company name in square brackets in the text message. It's very rare that people get caught for it. Most of my university classmates use these services. Félix An (talk) 00:28, 2 May 2023 (UTC)
I agree that It's very rare that people get caught for it, simply edit non-politic related article would not upsetting the authority. But if they edit article about politically sensitive topics, such as human right in China, they can easily become the targets for the authority. In this case, if they had used their cell phone to verify their account, the authority can find them out very easily.
Maybe someone would think avoid editing politic-related article can solve this problem, however, its not that easy. In Chinese Wikipedia, their is a case that a user revert an edit which change "Republic of China" to "Taiwan province, China". According to Wikipedia policy, it's just reverting a vandalism. But the editor was later criticized on Chinese social media platforms, others accused him of "supporting Taiwanese independence", which is a crime in China. (This editor do not use that social media, he did not know that such a threat had arisen) This editor wasn't arrested (he continues to edit), but if the authority can track this user via there phone number, maybe the ending would be different. BlackShadowG (talk) 02:33, 2 May 2023 (UTC)
Firstly, things used to verify aren't public. It's also not easy to search every piece of data you have for someone who received a text message from Wikipedia at a specific time.
Secondly, could you provide a source for that? How is changing Taiwan province to Republic of China vandalism??? That is what they are, I think I need some more context. Plus were there any repercussions other than getting trolled on a platform that does not have control of him? What about violating Chinese laws, this is an American platform! Aaron Liu (talk) 12:31, 2 May 2023 (UTC)
Sorry for my mistake. I means changing "Republic of China" to "Taiwan province, China" is a vandalism (at least on zhwiki), the user revert this vandalism was criticized on social media platforms. I just want to say that using a platform that the authorities can track for verification is not a good idea, because it gives the authorities the ability to track these users, which would make them not completely safe even if they use a VPN. Even if these users try to avoid editing politically sensitive content, they could inadvertently anger the authorities while editing some normal article and thus become a target for law enforcement. BlackShadowG (talk) 13:01, 2 May 2023 (UTC)
There is another possible data point for verification: Chinese ID Cards (for the locals) and Chinese visas (for foreigners in China). Prospective users scan these documents, get uploaded to a server managed by WMF, or a group of entrusted community developers, using OpenCV to do a simple check that the image is Chinese ID Cards/visas (no storing of images) and release a token or create the account for the applicant. The codes on the server obviously have to be open source for auditing purposes. Yes, there may still be private data being processed, but at the very least, we are not leaving traces on the telco or WeChat side, and the data is not held beyond for what it is necessary. – robertsky (talk) 07:39, 2 May 2023 (UTC)
A simple check of "is this a Chinese ID" would be extremely open to forgeries and/or people just using random images online to bypass it. Additional checks that this ID hasn't been used before and that this is a valid ID will also be needed, and the latter will probably still require "conspiring" with the Chinese government. Aaron Liu (talk) 12:27, 2 May 2023 (UTC)
Yes, it is still can be opened to forgeries, which other than gathering/sourcing for benchmark dataset, similar to MIDV-2020 or DLC-2021 for Chinese ID cards and perform some ML-based verification on the captured image against the dataset, it will remain unsolvable, unless we want to rely on other third party SDKs (coughHuaweicough). On validity of the ID, there is already the checksum algorithm to verify the ID number on Resident_Identity_Card#Identity_card_number. – robertsky (talk) 18:29, 2 May 2023 (UTC)
Checksum only verifies that the sequence is a possible ID number, it doesn't check if there's actually someone with that ID. For example, 111111 11119111 111X is obviously an impossible ID number, but the checksum's right. Aaron Liu (talk) 19:21, 2 May 2023 (UTC)
yeah, it doesn't. but if the goal is for a good enough check without handing information to the telcos, this suffice. – robertsky (talk) 20:54, 2 May 2023 (UTC)
Felix originally wants that "editors can start editing on the normal Wikipedia instantly." I doubt an ID verification procedure will be fast enough. (Probably faster than the current RfIPBE system but who knows? Good news is the work will be done by WMF staff instead of volunteer sysops:) --魔琴 (Zauber Violino) (talk) 13:50, 2 May 2023 (UTC)
Good editors in China could be a great plus for Wikipedia and and the hurdle to get it looks pretty high. But this is a complex situation which could backfire. I don't know the best way to do it but Félix An's idea looks like thoughtfulness and knowledge/expertise went into it. How about this? Félix An, finalize a proposal. Include that it will be a 1 year trial with a maximum of 100 accounts under the procedure in that proposal. Then see how it goes. Sincerely, North8000 (talk) 00:38, 2 May 2023 (UTC)
While limiting the accounts registered is a good idea for a trial, what you describe seem to be "the portal locks up even if the trial isn't finished after a measly 100 accounts gets registered".
For such an operation we'd also need to publicize it somehow. I'm not sure if such a CentralNotice banner would get accepted. Aaron Liu (talk) 00:46, 2 May 2023 (UTC)
At a minimum, we could add that to the block notice for open proxies. Still we need to decide on what way and if we need it get/code a verification service provider. Aaron Liu (talk) 00:47, 2 May 2023 (UTC)
My idea is that instead of gridlocking this while trying to achieve perfection, to just try it out on a small scale and see how it goes and modify if needed. I just made up 100 / 1 year. Both could change if that sounds too small. Sincerely, North8000 (talk) 01:22, 2 May 2023 (UTC)
At least for now, applying for accounts or permissions through the administrator mailing list, I think it is a good "Great Filter". I very much doubt how much the foundation is willing to play cat and mouse with the Chinese government on compliance and technology. The proposer's idea is ideal, but as the proverb goes. Those who are capable can always find a way to access Wikipedia. --Cwek (talk) 05:29, 2 May 2023 (UTC)
But that's unfair. People in the West can sign up instantly, and people in China have to go through many hurdles, which might put off new editors. Félix An (talk) 02:36, 3 May 2023 (UTC)
The world just isn't fair. At least I think the current mechanism can basically handle it, and there is no need to open a bigger hole.--Cwek (talk) 08:55, 3 May 2023 (UTC)
We have no limits because the limits are not in my hands. But the issue being discussed now is that there are compliance and technical issues. The use of identity-related identification services in China (including SMS, mobile payment tools) may be learned by the Chinese government and become evidence for tracking users (or may become easier to track); the foundation establishes a mirror server or account creation and The authentication server may eventually become a game of peek-a-boo, and may even make the blockade more serious (if you know the blockage level of the entire wiki project, you can know that the IP addresses of some access points are directly blocked. I made some skills technically, the server of the foundation can know the IP address of my location, not all of my proxy. But I am not sure if the foundation continues to confront the Chinese government, whether it may lead to more Severe blockade of the entire address segment). In our local discussion, an administrator who has contact with the foundation mentioned that it seems that the foundation wants to maintain a neutral position in similar incidents, and the risk of setting up servers in China is too high to do so. I think our discussion of this matter here is meaningless, and the proponents should consult the opinions of the foundation, especially in legal matters. --Cwek (talk) 00:57, 6 May 2023 (UTC)
Welcome to the Real World. But at least now there is a way to workaround this issue (the administrators in zh are willing to provide the convenience of creating a new account and granting LIPE). --Cwek (talk) 01:39, 18 May 2023 (UTC)
I doubt 100 accounts would be enough if we decided to do this. Some people would think Wikipedia is a great place for advertisement before their account is permanently blocked. --魔琴 (Zauber Violino) (talk) 13:40, 2 May 2023 (UTC)
I still like my original residential IP verification idea the best. It's the easiest to do and doesn't expose more information than necessary. (You would need a hidden IP verification portal accessible by directly typing in the IP address. The IP address of this portal would change frequently and would only be obtainable after a CAPTCHA to prevent the firewall from automatically scraping the IP address and blocking it when it changes.) Félix An (talk) 02:35, 3 May 2023 (UTC)
From my point of view, the special sign-up portal is doable. There are still some non-Wikipedia non-Chinese language projects that are still accessable from mainland China through IPv6, as far as I know. A sign-up & gain-IPBE portal website wouldn't do much for circumvening the cencership. But it all depends on how the Chinese government think about this (shrug). --魔琴 (Zauber Violino) (talk) 08:26, 9 May 2023 (UTC)
I think that's the end of it. Similar discussions have been discussed more than once in zhwiki (because of this topic, it was mentioned again). Some users who claim to have been in contact with the Foundation mentioned that the Foundation is unwilling to play cat and mouse in order to provide an uncensored server, nor is it willing to stray from the goal by providing a censored server (the latter actually has It has been tried, for example, WMC operates qiuwenbaike, and there are also some private read-only mirror sites that will also do censoreing). The foundation also wants to be in the middle on this issue (it seem that they don't want to entangle with the Chinese government). Using identity verification services in China will only increase the risk of user identity exposure (because the Chinese government is able to find out). In addition, according to zh's technical observations, not all IP addresses of the foundation's access points are unavailable, and the same for some project domain names, which can register accounts through other projects. And zhwiki's administrators are willing to give LIPE with a lower standard. --Cwek (talk) 01:58, 18 May 2023 (UTC)
Hello. I want to inform you about the request for my bot. This request is specific in that the bot can arbitrarily edit pages that are in the list sk:Redaktor:Dušan Kreheľ/Mapovanie slovenských miest. The bot has already updated the statistics, but the pages are content-poor, so the bot could possibly also expand the content. More/details in request. Dušan Kreheľ (talk) 16:42, 14 May 2023 (UTC)
I think we're supposed to reply here instead of the BRFA?It's clear you're a subject matter expert on statistics in Slovakian administrative divisions, and I don't want to hold against you permanently the rocky start your botop career had with your misunderstandings of policy, but it does still leave me a little leery about insuring your bot edits carefully and safely. I don't think arbitrarily edit pages is a narrow enough task for your bot, and from the function detail possibly others at the BRFA, I'm getting the impression that you are seeking preemptive approval to have your bot make any edits you think are valuable.I like the idea of updating / adding infoboxes and tabular data, and I think you should start off with a task narrowly focused on that so we can all feel safe about your bot's operations before you try to broaden the scope to arbitrary edits without specific subsequent approval. Folly Mox (talk) 03:23, 15 May 2023 (UTC)
@Folly Mox: It was somehow a request, of BAG or who. I don't think it's a bad move. Humans may not notice or follow bot requests.
I think you're on the right track, because being approved for a small number of test edits in any of a bot's tasks is already how bot policy on the English language wikipedia works (specifically, see WP:BOTAPPROVAL). From the diff you've provided, it looks like you may be planning on making manual edits from your bot account, which shouldn't be done. I think your best chance of success is still to narrow your scope: pick a few simple tasks for your bot to start with (like "update population data in tables", "add population tables if none exist", and "update values for all infobox parameters in articles about Slovak administrative divisions"). Once you've shown your bot can handle narrow tasks safely and that you understand the bot policy and are willing to follow it, you should have a stronger position to request an increase in scope. (And if you want your bot to be able to remove external links, you'll have to show it's also capable of removing the entire section if you've removed the last remaining external link.)I'm not a botop or BAG member, so my opinion doesn't carry any special experience or weight, but since you're starting out from the difficult position of having your bot account blocked for editing outside its previous remit, you'll be wanting to start slow to earn back the trust of the people who approve these things. I do support the idea of your bot updating statistics, adding population tables, and removing external links, if it can edit within policy and not create empty sections. Folly Mox (talk) 13:12, 18 May 2023 (UTC)
Hi, how can I properly add a request here at Wikipedia:Village pump about adding a filter by namespace to the Special:GlobalUsage page? Presently, there is no way to exclude Talk pages when searching for a file's usage. ♆ CUSH ♆15:23, 20 May 2023 (UTC)
@Cush this isn't something we can do anything about here on the English Wikipedia directly, a software request for this is already open at phab:T179505, you can follow that or work on improvements there. — xaosfluxTalk16:50, 20 May 2023 (UTC)
Hypothetical star
Hypothetical star is a list and should be treated as such.
From my point of view, on Wikidata [hypothetical star (Q5961276)] and [list of hypothetical stars (Q118591275)] should be merged.
His point is that the enwiki article "hypothetical star" should be renamed "list of hypothetical stars" cause the article is actually mainly a list. Simon Villeneuve (talk) 15:26, 23 May 2023 (UTC)
RfC: Removing "Clear the watchlist" from main watchlist screen
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.
As we know the new default skin Vector-2022 has a "Clear the watchlist" option on the main watchlist screen beside "Edit raw watchlist" option. Personally, I get scared by its existence here, I have a habit of misclicks and I have 3000+ pages in the watchlist. I can't afford to lose it all. This option may also cause some confusion to non-native English users: "Clear the watchlist" might also mean that the current watchlist screen is cleaned, and not all the pages of watchlist. And ofcourse this is not as widely used an option to merit inclusion right on front of the watchlist screen. People don't put pages on their watchlist only to perform a mass removal 2 days later. This option can safely be moved away from the main page and only inside the edit watchlist pages. This RfC is to determine whether there is consensus among the community to seek such a technical change to the new watchlist. —CX Zoom[he/him](let's talk • {C•X})07:42, 15 April 2023 (UTC)
NOTE that I was inactive during the post-deployment discussions, so if this issue was already raised that time and was voted up or shot down, feel free to early close this one. —CX Zoom[he/him](let's talk • {C•X})07:42, 15 April 2023 (UTC)
UPDATE: I have been made aware below that the "Clear the watchlist" option has always existed. Most (including me) didn't see it on our watchlists because the "JS watchlist" was enabled by default which hid the "Clear the watchlist" option in the previous default skin, Vector legacy. This, however, raises the question, that when the need for removal of this option was felt due to obvious reasons, why was it removed using a JS workaround that is incompatible with the current default skin (Vector-2022), rather than from the software side itself. —CX Zoom[he/him](let's talk • {C•X})16:25, 1 May 2023 (UTC)
I hadn't even spotted that it was there. You've got me frightened now, as I too often misclick. I'm sure I didn't so often when I was younger, so it must be an age thing. I daren't click the option to check this for myself, so is there a "do you really mean to do this?" failsafe message when you do? Without at least this I would certainly support the proposal, and would probably do so anyway. Phil Bridger (talk) 09:25, 15 April 2023 (UTC)
There is a confirmation message.
Clear watchlist All of the titles will be removed from your watchlist Clear the watchlist (This is permanent!)
However, my concerns about non-native English users like me confusing this up remain. What exactly is meant by "all titles"? And again, this does not need to be on the front under any logic. It should be shown only to those who attempt to edit their watchlists. —CX Zoom[he/him](let's talk • {C•X})10:03, 15 April 2023 (UTC)
Support I see no reason why it should be where it is. It hardly seems to be the kind of thing you do so often that you need quick access to it. Moving it to the edit menu makes sense. -- Random person no 362478479 (talk) 11:01, 15 April 2023 (UTC)
The "Clear the watchlist" link exists in all skins and has existed long before Vector 2022. The opening statement of the RfC seems misinformed. And it can be hidden by the CSS #ca-special-specialAssociatedNavigationLinks-link-3{display:none;}. Nardog (talk) 13:58, 15 April 2023 (UTC)
Not true. Vector legacy definitely has the link, for me it's the last item in the line "For Redrose64 (View relevant changes | View and edit watchlist | Edit raw watchlist | Clear the watchlist)" just below the title and above the line beginning "You have nnn pages". If you're not seeing it there, you have some customisation that hides the link. --Redrose64 🌹 (talk) 17:35, 15 April 2023 (UTC)
I do not see either of these lines, the only things above "You have nnn pages" and below the title for me are the watchlist notices. Aaron Liu (talk) 19:46, 15 April 2023 (UTC)
What Sojourner in the earth said. So the apparent addition of the link isn't a deliberate decision by the V22 devs but simply a by-product of moving the tool links above the page body. Nardog (talk) 17:42, 16 April 2023 (UTC)
Thanks, this explanation clears it up for me. However, I have two doubts: 1) I don't see them even with ?safemode=yes. Why does the Watchlist JS still get called? 2) Whosoever created the JS Watchlist must've recognised the uselessness of "Clear the watchlist" option on watchlist, that is why they must've hidden it. So, why not hide it from software side rather than a JS workaround? —CX Zoom[he/him](let's talk • {C•X})09:16, 17 April 2023 (UTC)
The links at the top of the watchlist (View and edit watchlist; Edit raw watchlist; Clear the watchlist) are not specific to Vector 2022 - they are also in the watchlist for all other skins, and what is more, have been there for as long as I can remember (almost 14 years). If you really want to hide the link, it can be done in CSS - but the actual CSS selector differs according to your skin. For Vector 2022 (but not legacy Vector) it is
One of the things I mentioned on the recent Vector-2022 zoom call was the need for greater stability of the skin APIs. There really is no reason why every skin that exposes a "Clear the watchlist" functionality couldn't include that inside a HTML element with class="clear-watchlist-control" (maybe id instead of class?). Then people who wanted to make it go away could do so in a skin-independent way. I've got
#pt-logout { display: none; }
in my common.css for exactly the same reason. One time too many, an accidental click (especially on my phone) would log me out. And due to the way logout works, it would log me out from all my devices. And since I use 2FA, if I didn't happen to have my authenticator with me, I'd have just committed a one-click accidental DOS attack on myself. -- RoySmith(talk)15:50, 15 April 2023 (UTC)
Neutral This button has always been present in the same location in Vector 2010's non-Javascript watchlist, and also in Timeless and Minerva. When you click it, you get a big red warning sign asking for confirmation, so I think the danger is minimal. That said, the button doesn't really need to be where it is (or to exist at all, now that the "check all" option is available on the "Edit watchlist" screen). I'd say if it's technically easy to remove it, remove it; if it's technically difficult, let it be. Sojourner in the earth (talk) 20:34, 15 April 2023 (UTC)
If you have more than about 20,000 (±10%) pages in your watchlist, the "View and edit watchlist" screen may not be feasible: it can time out if it takes too long to (a) load; (b) action the "check all" option; (c) action the "Remove titles" button. --Redrose64 🌹 (talk) 23:04, 15 April 2023 (UTC)
Is there anyone who has more than about 20,000 pages in the watchlist and wants to delete them all? I doubt it. If we have a problem with large watchlists then that should be addressed, rather than a useless workaround be offered to users. Phil Bridger (talk) 18:46, 16 April 2023 (UTC)
Support - (Summoned by bot) I don't use Vector 2022 by default and I'm assuming my tweaking my CSS has removed this elsewhere so I never noticed this until I checked for it after reading this discussion, but I do think that this is too prominently placed for something that most editors will absolutely not want to do. If you had asked me how to clear the entire watchlist I would have said that it would be in "Preferences > Watchlist" and I just checked and "Clear your watchlist" is there as a button with red text making it clear that this is an extreme option. If this link is removed from the watchlist page it's still accessible for those wanting to remove their entire watchlist, and those with a tenuous grasp of English or otherwise not understanding what "clearing all titles" mean are far less likely to accidentally click through a red button in the watchlist section of their preferences page than they are a comparatively innocuous-looking link at the top of their watchlist. - Aoidh (talk) 00:18, 24 April 2023 (UTC)
Support removal and from all skins if necessary. Just flat out remove this functionality. Please see this relevant Far Side comic. Back when bulletin boards were a new thing, a common Madrona Park option was a "clear all text" button. But... why would you ever need this? No confirmation on that one, either, it just did it. If you really needed to clear the text window, CTRL-A + delete did the trick regardless. Anyway, there is absolutely no need to implement a "wings fall off" button on watchlists. If someone really, really wants to do this, they can go to Special:EditWatchlist/raw, select all, and delete it themselves. This will happen once in a blue moon, and it has the merit of working better for people who merely want to clear *most* of their watchlist, and it'd be what, 2 seconds slower than the dedicated process? For an action most editors will do never, or at most once? Delete it with fire. SnowFire (talk) 06:27, 1 May 2023 (UTC)
And the confirmation for rollback no longer works for me. I long ago enabled confirmation for rollback to avoid accidentally rolling back edits. That stopped working for me a while back, so that even though I select "cancel" on the confirmation notice, the rollback still proceeds. I can easily revert accidental rollbacks. It would only take one time for the cancel button to fail on clear watchlist to wipe out the over 5,000 items on my watchlist. Donald Albury11:54, 1 May 2023 (UTC)
Eh? I've had rollback since 2010 and it's never had a confirmation step for me. I can't find any option for this in preferences, either. --Redrose64 🌹 (talk) 18:31, 1 May 2023 (UTC)
In Preferences, Gadgets, Browsing, there is an item, "Require confirmation before performing rollback on mobile devices", which I have checked (I don't think my Chromebook counts as a mobile device, however). I also have installed User:Mr. Stradivarius/gadgets/ConfirmRollback.js in my common jss. I used to get two confirmation notices, and could sucessfully cancel an accidental rollback. Now I normally only get one confirmation notice (I sometimes see the second one flash on the screen very briefly), and clicking on "cancel" does not stop the rollback. That has not yet been enough of a problem for me to pursue a solution. My main point, however, is that if the confirmation process for a rollback can break, then it is possible that the confirmation process for clearing a watchlist could break, and fail to stop a watchlist clear action. Donald Albury19:47, 1 May 2023 (UTC)
You didn't mention mobile in your post of 12:00, 1 May 2023 (UTC). I have no mobile, and tend to ignore any prefs that are mobile-specific. That said, I find that the preference concerned is enabled for me (it was apparently added in June 2015 as an opt-out gadget, with a four-person consensus).
If a script provided by Mr. Stradivarius (talk·contribs) isn't working as it should, you should inform Mr. Stradivarius on their user talk page: indeed, this is entirely the wrong venue to be reporting script problems. --Redrose64 🌹 (talk) 08:08, 2 May 2023 (UTC)
If you have too many pages on your watchlist, the "raw edit, select all, and delete" method does not work due to timeouts or excessive page size. The "clear" option uses the job queue to do it for extremely large watchlists without overloading the DBs. Anomie⚔11:53, 1 May 2023 (UTC)
Sure, but dismantling bridges also requires special procedures, but it's rare enough that we don't install a "dismantle bridge" button at the entrance. This is an argument that perhaps the Special:EditWatchlist/clear option should be kept (although I'd say even this is suspicious, just do it manually in smaller batches), but it certainly shouldn't be highlighted. For the one person every two years who has compiled a watchlist of tens of thousands of articles AND wants to clear it efficiently, they can be pointed to the clear option at the Village Pump tech help. There's no need for a button to get you there faster, and potentially harm. SnowFire (talk) 17:05, 1 May 2023 (UTC)
I was replying to where you said Just flat out remove this functionality. I also note your batching idea wouldn't work if people can't even load the page because it's too big. Anomie⚔23:05, 1 May 2023 (UTC)
If people are unable to edit their watchlist because it's too big, then that is a problem that needs to be fixed by the developers not a reason to reject this proposal. Thryduulf (talk) 09:58, 2 May 2023 (UTC)
It seems to me they did fix it, by having a "clear watchlist" feature that uses the job queue. And I think that's excellent reason to oppose the "just flat out remove this functionality" sub-proposal. Anomie⚔11:42, 2 May 2023 (UTC)
I still struggle to see anyone with 5000+ items gathered over months and years to go clear it all instead of selectively weeding out the less important items from the more important ones in their list, to do which "clear watchlist" isn't really a good feature. Devs should try to explore other alternatives that fixes "raw edit" page, if one wants to clear it all: Ctrl+A > DEL is all they'd need to do. At the very least, the behaviour of the "Clear the watchlist" option should resemble the one already seen in "JS watchlist" on vector legacy, that hides this option in the main watchlist, but shows it in the edit pages. —CX Zoom[he/him](let's talk • {C•X})15:06, 2 May 2023 (UTC)
I think you're about 1.7–2 orders of magnitude lower than where people have the problem being discussed here. SnowFire just below is at 2.4, and apparently doesn't believe anyone who accidentally got their watchlist that full would ever decide to start using it. Anomie⚔12:03, 3 May 2023 (UTC)
(de-indent) Re Anomie, to be clear, I still support removing the functionality entirely, just think that hiding it away is a good enough compromise. If we put on project manager hats for a moment - so what that it's technically tricky to mass delete watchlists? Maybe it'd be technically tricky to submit a bulk edit that transforms 1,000 articles into Pig Latin simultaneously, too. But that's a useless task. Again, it really needs to be restated that I find the use case of this functionality incredibly rare: an editor who's built up an exceptionally large watchlist AND wants to unilaterally delete everything (if they want to retire, they can just not login to their account anymore...). There's a certain cost with maintaining functionality and increased complexity, and it doesn't matter how clever or efficient the Pig Latin transformer is, it's for the best long term to just not bother with it and make the codebase a little simpler. Keep it if you want, but slap a big UNMAINTAINED warning on it and be done with it. (If there's REALLY an argument that this is useful, I'd want to see metrics on how often this is actually called by editors with 1,000+ articles on their watchlist, bearing in mind that the raw number of such editors isn't huge to begin with.) SnowFire (talk) 18:30, 2 May 2023 (UTC)
I think you probably overestimate the amount of maintenance the code requires. Even the link showing up in Vector 2022 has nothing to do with the feature itself, it's just that one of the random changes to Vector 2022 happened to break the CSS and JS someone had added to MediaWiki to hide these links on the fancy watchlist UI, just like how Vector 2022 broke gadgets and user scripts too. Anomie⚔12:03, 3 May 2023 (UTC)
Leave is alone this is a useful function and sometimes necessary for people with certain broken watchlists (often if they are ridiculously large). There is already a confirmation prompt - no objections if someone wants to improve the localization of the message there (via MediaWiki:watchlistedit-clear-explain). — xaosfluxTalk13:33, 5 May 2023 (UTC)
Support hiding away. There might be rare cases where it is useful, but I agree with above comments that the button is liable to be misunderstood, and I don't think any wording change would fix that. CMD (talk) 15:57, 17 May 2023 (UTC)
Support: Anything that's basically irreversible probably should be hidden deep in user preferences with two confirmations, not right out in the open. Adam Cuerden(talk)Has about 8.4% of all FPs.05:46, 24 May 2023 (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.
@Maddy from Celeste:how do you want this done? From your close above, it seems you are saying it should also work when scripts are disabled, so that means that another script to hack it away won't be the answer. I suppose you can open a feature request on this asking for it to be removed in core. — xaosfluxTalk15:10, 30 May 2023 (UTC)
Feature request seems reasonable. I'm not super familiar with the tech side of things, and haven't filed a feature request before, so I'm not entirely sure what information to include and which projects to tag. -- Maddy from Celeste (WAVEDASH)11:19, 31 May 2023 (UTC)
promotional phrase for Wiki - "You could look it up", from Yogi berra
Dear Wiki:
It occurred to me that an excellent promotional slogan for Wikipedia might be "You could look it up", one of Larry "Yogi" Berra's most notable quotes, made long before Wiki existed. The only problem I see for this idea might be name recognition - that if you know who Yogi was, you might well be close to my age (71 and counting). On the other hand, Yoogi's fame went beyond baseball.
This seems to be the default phrase already of anyone young enough to have been brought up in the Internet age, who include my children who are in their 30s. The days of interminable discussions in the pub about factual matters seem to be well and truly over. I'm a Brit, and not a follower of baseball, but I certainly know who Yogi Berra was. Phil Bridger (talk) 20:37, 28 May 2023 (UTC)
Hey, we got it in the UK - twice, IIRC: once in the late 1960s, and again in the late 1980s. Sock it to me! --Redrose64 🌹 (talk) 22:51, 28 May 2023 (UTC)
For example, there is a gap between #3 and #6. I think the algorithm should pick a random number between 1 and 276 and display #174 if the ad indicated by the random number doesn't exist. Additionally, ads to defunct things (like certain WikiProjects) should be removed. Aaron Liu (talk) 01:53, 5 June 2023 (UTC)
i was thinking, what if a second mascot vote was done (by the ip address 92.23.92.72, note if i made mistake typing my ip address) — Preceding unsigned comment added by 92.24.92.70 (talk) 14:21, 16 June 2023 (UTC)
RfC on establishing a biography infobox guideline
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.
There's nothing approaching consensus in favor of any of the proposal changes. While there was initial clash on the merits (and some unfortunate personalizing during an occasionally passionate discussion) the two camps seem unmoved after 30+ days. BusterD (talk) 00:05, 3 June 2023 (UTC)
Should MOS:INFOBOX be modified to advise that infoboxes are "recommended" for biographical articles where the infobox would contain textual information not provided by an article's first paragraph? Nythar (💬-🍀) 19:24, 2 May 2023 (UTC)
Current guideline
The use of infoboxes is neither required nor prohibited for any article. Whether to include an infobox, which infobox to include, and which parts of the infobox to use, is determined through discussion and consensus among the editors at each individual article.
Proposed guidelines
Option 1: Information past the first paragraph
The use of infoboxes is neither required nor prohibited for any article. For biography articles, infoboxes are recommended if there is textual information—aside from external links—that could be put in an infobox beyond what is found in the article's first paragraph. The purpose of the infobox in these contexts is not to replace the lede or to re-summarize it, but to augment it. In other cases, there is no presumption for or against an infobox. Whether to include an infobox, which infobox to include, and which parts of the infobox to use, is determined through discussion and consensus among the editors at each individual article.
Option 2: Non-stubs
The use of infoboxes is neither required nor prohibited for any article. For biography articles, infoboxes are recommended if the article is longer than stub length. The purpose of the infobox in these contexts is not to replace the lede or to re-summarize it, but to augment it. In other cases, there is no presumption for or against an infobox. Whether to include an infobox, which infobox to include, and which parts of the infobox to use, is determined through discussion and consensus among the editors at each individual article.
Option 3:All biographies
The use of infoboxes is neither required nor prohibited for any article, although for biography articles, infoboxes are recommended. The purpose of the infobox in is not to replace the lede or to re-summarize it, but to augment it. Whether to include an infobox, which infobox to include, and which parts of the infobox to use, is determined through discussion and consensus among the editors at each individual article.
Option 4: Oppose all changes/Other
Background (establishing a biography infobox guideline)
There is no current MOS guidance on the appropriateness of infoboxes. A 2013 ArbCom decision made clear that infobox inclusion should not be considered a maintenance task, but, rather, based on a determination of the use of a particular infobox on a particular page—in other words, it endorsed an article-by-article analysis. Unfortunately, in the past few years, there have been an unusual number of RFCs concerning infoboxes in biography articles, a subject which continues to be contentious.
[1] Infobox later added to the article after discussion.
[2] Infobox later added to the article without discussion.
There were two discussions on whether to collapse infoboxes, both resulting in a consensus in favor of uncollapsed infoboxes: Frank Sinatra and Peter Sellers
Moreover, editors examining or participating in these debates have noticed a few patterns:
First, the debates are all contentious, feature many repeat players, and, despite the ArbCom's apparent endorsement of tailored considerations, are often dominated by general arguments—that is, arguments concerning whether infoboxes are, on the whole, good or bad.
Third, there's a trend towards infobox inclusion. Eight of the last 10 RFCs that reached a consensus reached a consensus in favor of inclusion. And, as to the two RFCs that reached a consensus in favor of exclusion? Both pages now have an (apparently stable) infobox.
In light of these considerations, I propose the above non-mandatory language. The goal of this guidance is to reflect a preference for infoboxes where an infobox would contain textual information (not including links) beyond what is contained in the first paragraph of an article. Infoboxes serve to highlight information for quick reference; to the extent that they can contain information beyond what is already detailed by an article's opening paragraph, they allow users to find that information without having to scan. The guidance, which does "recommend" infoboxes in such situations, reflects the recent trend towards infobox acceptance in RFCs that have reached a consensus. Finally, a non-mandatory recommendation may serve to set a baseline for future discussions on infobox appropriateness. Nythar (💬-🍀) 18:49, 2 May 2023 (UTC)
Survey (establishing a biography infobox guideline)
Please indicate whether you would support or oppose changing the guideline, and, if support, please indicate which option or options you would support.
Support (establishing a biography infobox guideline)
Support as one of the drafters and as the proposer. I believe this is long overdue and will help us achieve more consistency across biographical articles with generally acceptable criteria. Nythar (💬-🍀) 18:52, 2 May 2023 (UTC)
Support my stance is that it’s a bit too vague (if someone wanted to stonewall a box they could just add suggested content to the lead or say it’s already there in a different format, etc.) and an article-length-based requirement would be better; but as a bare minimum it is preferable to the non-guideline we currently have. Dronebogus (talk) 19:02, 2 May 2023 (UTC)
Support as one of the drafters. Reviewing the RfCs on this topic the past six months the consensus appears to generally support the use of infoboxes on biographies. Updating the guideline for this community position should help reduce the number of RfC's and make this a less contentious topic in the future. In the past, there have been calls to create a policy to help reduce the conflict on this topic. Given the support for infoboxes, this attempt at creating a policy isn't perfect, but it's a step in the right direction. I prefer option 3 but I support the options presented. Nemov (talk) 19:13, 2 May 2023 (UTC)
Narrow support, support all options, but, in order: Options 2, 1, 3 I helped Nythar craft this proposal at WP:VPI—I drafted the background information section, and I made the recommendation that external links and media be excluded. (I figured that this would have no shot at consensus support if it gave the impression that, say, a picture or link to a YouTube channel automatically warranted an infobox.) At the time, I raised concerns that no proposal would be perfect. I said that these RFCs have been dominated by individuals who always vote in favor or always vote against an infobox's inclusion, and that the editors who always vote against would certainly object to this change. Responding to a proposal that prioritized the number of parameters a template had, I mentioned that I'd seen debates in which users have stretched to add parameters to a template in order to make the infobox seem more useful, and that's a risk here—it's a gaming risk. But the tense that I just used is notable. I've seen that issue—meaning it's an issue under the current guidance. And, frankly, a discussion over whether information properly belongs in an infobox would, at least, be more article-specific than many of the comments I've seen in the various RFCs.Here's what's, for me, key: Almost worse than how brutal these RFCs are is how repetitive they are. The same general arguments are employed time and time again. Frankly, it doesn't make sense to have these discussions completely afresh on every individual page on which this issue comes up. This proposed guidance probably won't solve that problem. But at least it gives a suggested baseline. I think the non-stub option would encourage contributing to articles where users think an infobox is important, and I think article length is generally a decent proxy for infobox usefulness. I think the information/parameter focused option addresses a pretty common line for opposing an infobox ("it's in the first paragraph!"), and the more a user has to scan an article, the more an infobox makes sense. I also think infoboxes can generally be recommended for biographies--Jerome Frank Disciple (talk) 19:34, 2 May 2023 (UTC)
I generally support this, as the one who spitballed the first draft. Sure, it's gameable, but so are all policies and guidelines; if someone does that, that's a user conduct issue, and we already have WP:CTOP in place if that occurs. Infobox RfCs have been a vexing issue because they're a rare case where there's long, draining RfCs, but without much personal attacks, POV-pushing, or other conduct that would merit admin action. Having actual guidance in place that establishes even a partial presumption one way or the other would be a step toward having to reinvent the wheel with each successive RfC. Like I said at VPI, basically everyone agrees with the idea that most non-stub biographies should have infoboxes, but some should not. This would formalize that. Individual talkpages would still be able to find local consensus to override the default recommendation, if some good reason exists. -- Tamzin[cetacean needed] (she|they|xe)19:59, 2 May 2023 (UTC)
Support I think this will generally reduce the amount of RfCs debating the same topic. There's no way to word this that isn't going to be gamed by people, but as a broad recommendation I think it works. Galobtter (talk) 21:19, 2 May 2023 (UTC)
Support. I think this would reflect the current status quo, which is that, in general, more editors than not support infoboxes on biographical articles. That can vary depending on the article and the subject; I think in most disciplines/genres/whatever this isn't controversial at all. Note: I've preferred infoboxes for a long time; my views haven't changed since at least 2017 and probably longer ago than that. — Preceding unsigned comment added by Mackensen (talk • contribs) 21:43, 2 May 2023 (UTC)
Support. I have long felt that there should be a presumption in favour of an infobox for non-stub articles about most concrete subjects (including biographies) because, in the majority of cases, they are (by consensus) significantly beneficial to and expected by readers. This proposal may not be perfect, but let's not let perfect get in the way of substantially better than the status quo. Thryduulf (talk) 22:42, 2 May 2023 (UTC)
Update: I support Option 2 as my first preference, and Options 1 and 3 as about equal second preference. While I don't actively oppose option 4, it is a distant preference behind the above. Thryduulf (talk) 21:11, 4 May 2023 (UTC)
Support as a healthy dose of common sense and a final end to these weird little cliques that oppose their usage in articles where a normal reader would expect to find them. Zaathras (talk) 23:41, 2 May 2023 (UTC)
Support – I think including infoboxes in most/all cases for biographies is in line with the principle of least astonishment; since it is common for biographies to have infoboxes, not having them can be confusing. In other words, infoboxes make it clear visually that the article is a biography as opposed to some other type of article. RunningTiger123 (talk) 01:46, 3 May 2023 (UTC)
Following the updates, option 3 is my preferred option and is most in line with my reasoning. Options 1 and 2 are okay as alternatives. RunningTiger123 (talk) 22:22, 4 May 2023 (UTC)
Support – I would rather support a guideline that said "All biographies should have an infobox unless there is a clear consensus to the contrary", but this is a step in the right direction. Infoboxes, when used properly, provide a helpful overview of the article subject, are much more considerate to those who struggle to read a wall of text, and provide valuable assistance to search engines and tools that gather and compile structured data. – bradv02:04, 3 May 2023 (UTC)
I find the structured data argument for infoboxes to be one of the weaker ones. We have Wikidata for that; on Wikipedia, we should write for humans rather than machines. {{u|Sdkb}}talk02:17, 3 May 2023 (UTC)
Support - I would, like Bradv, prefer a slightly stronger guideline, but I think this is vastly better than what we have, and I think this will hopefully bypass some of the highly repetitive comments that I've seen even in my brief time engaging with this discussion. It need not be perfect now, it just needs to be better, which it is. -Nerd1a4i (they/them) (talk) 04:05, 3 May 2023 (UTC)
Support (Bradv's proposal 1st choice; original proposal 2nd) — Infoboxes are useful and readers expect them in biographical articles. Confusing readers because a small contingent of anti-infobox editors fight to keep them off specific pages does not benefit the encyclopedia. —pythoncoder (talk | contribs) 05:20, 3 May 2023 (UTC)
”readers expect them in biographical articles”: do you have any evidence for this? It’s a claim I see thrown around frequently, but to date no-one has given any rationale for the claim. An IB-less article may have hundreds of thousands of users, but rarely to I see a reader ask about a box, only an editor. - SchroCat (talk) 06:11, 3 May 2023 (UTC)
Support. (1) Infobox RFCs are a common and repetitive occurrence on biographical articles; these RFCs tend to feature recurring participants, and recurring arguments – in some cases repeated verbatim from other articles' RFCs. Adding stronger guidance about infobox use cases should help to free up editor time that has previously been given over to these discussions. (2) The direction of the recommendation (in favor of infoboxes) accurately depicts the most common consensus that emerges; however, by being simply a recommendation, the proposal also creates an explicit allowance for infoboxes to be omitted on articles where a consensus forms against infoboxes. ModernDayTrilobite (talk • contribs) 15:14, 3 May 2023 (UTC)
I don't think there'd be a way to combine all three without a lot of redundancy; I just intended to express that I'd support any of the three proposals individually. If I had to rank them, my order of preference would be 3 > 1 > 2, but in my opinion each of the three is an improvement over the status quo. ModernDayTrilobite (talk • contribs) 17:02, 5 May 2023 (UTC)
I generally expect to see infoboxes on biographical articles and think they provide a convenient summary of important facts, so I support this proposal. Hatman31 (talk) 23:37, 3 May 2023 (UTC)
Support alternative:The use of infoboxes is neither required nor prohibited for any article, although for biography articles, infoboxes are recommended. In other cases, there is no presumption for or against an infobox. Whether to include an infobox, which infobox to include, and which parts of the infobox to use, is determined through discussion and consensus among the editors at each individual article. For me, it's simply a matter of style, which is fitting as this is the manual of style we are talking about. I agree with WhatamIdoing's comment from the idea lab: Infoboxes are effectively part of our Trade dress. The content of the infobox should continue to be discussed on an article-by-article basis, although it seems obvious to me that at a minimum a biography should be expected to include dates and places of birth and death.I do not support the original proposed wording, which I think mixes style and content considerations, and is overly prescriptive and arbitrary about what should go in an infobox. Barnards.tar.gz (talk) 08:59, 4 May 2023 (UTC)
Oooh, I very much like this alternative. It's short and succinct, and reading it I have the feeling it describes my philosophy, although I have considered myself to be in the just-leave-it-to-individual-pages camp. I, too, dislike the original proposal, as it gets too finicky with conditions without clarifying them sufficiently. — JohnFromPinckney (talk / edits)10:08, 4 May 2023 (UTC)
@Nythar:: would you be willing to add this alternative as a second option? (If you'd like, I can work it into the above proposal and then ping the current voters to see if they have a preference or want to change their vote; I think this roughly matches Dronebogus's proposal.)--Jerome Frank Disciple (talk) 11:37, 4 May 2023 (UTC)
Support I think the current guidelines are too vague, but I wouldn't want a strict guideline on how appropriate an infobox is. As long as the infobox is able to easily summarize facts that would be more difficult to pick out from the article itself, I support its inclusion. :3 F4U (they/it) 01:09, 6 May 2023 (UTC)
Support recommending infoboxes, whatever that option was. Infoboxes are good things to have for and article, and is a common facet of Wikipedia. As I've said in the Mozart RfC, an infobox provides a different formatting of information that is wholly separate from prose. Infoboxes are useful in that they serve it in a structured format, and the commonplace and the recent RfCs ending in inclusion make it evident that infoboxes are desired generally. When an infobox has a field that would be wrong, excluding it altogether is what should be done (see Mozart's infobox) instead of denying a common standard. SWinxy (talk) 01:57, 8 May 2023 (UTC)
Support option 3, the alternative suggested by Barnards.tar.gz in this section, or any other options that otherwise gently encourages (but does not require) infoboxes in most biographies. I support this idea partly because this seems to be the direction that the community is slowly taking. Ten years ago, 30% of all articles contained infoboxes. Today, almost 50% of them do. This trend is, as User:Jerome Frank Disciple put it recently, "the elephant in the room". We're headed that direction, and we might as well admit it. We may someday reach a point of saying that biographies should have infoboxes except if there are extenuating circumstances, or even that citations should use Wikipedia:Citation templates. We're not there yet, but we can and IMO should take gentle little baby steps towards acknowledging that the community's preferences are drifting inexorably towards this approach. In case it matters, I have added infoboxes to very few of the articles I've created. However, I recognize that my personal approach is increasingly in the minority. WhatamIdoing (talk) 00:45, 13 May 2023 (UTC)
I would support all three options. I recognize that this is a contentious topicnand that major changes are unlikely to receive consensus. Although I would prefer a broader policy in favor of IB, I can still support threes kinds of incremental improvements. — BillHPike (talk, contribs) 07:28, 15 May 2023 (UTC)
Support option 3. Glad I noticed this discussion. Appreciate the consistency that infoboxes across biography articles provide. Guidelines should favor including one. Hameltion (talk | contribs) 15:51, 19 May 2023 (UTC)
Support due to all the stupid reasons given by the opposers. A guideline is required to enable sensibleness, and to stop argument. Graeme Bartlett (talk) 05:08, 25 May 2023 (UTC)
Really? The guideline isn't sensible and won't stop arguments - it will likely increase them and introduce gaming to the process, but is there really any need to be so dismissive of everyone else's opinions? - SchroCat (talk) 14:52, 27 May 2023 (UTC)
And I don’t mean you individually, but the opposition camp in general. The dominant reasons are “it should be determined on a case by case basis” (why?) and “more rules bad”. Dronebogus (talk) 11:34, 31 May 2023 (UTC)
Oppose (establishing a biography infobox guideline)
Oppose. I agree with User:Anarchyte above. I have often said that I agree with infoboxes in bios for politicians and sports figures, as the key information about these backgrounds makes sense in the box form. But the wording of the proposed guideline is nonsense: "...if there is textual information ...that could be put in an infobox beyond what is found in the article's first paragraph". All the key information about a subject, particularly a biography of an actor, writer or other creative person, should be included in concise form in the WP:LEAD, not in a box that often presents such trivia as "creator awards" (these are just plaques that YouTube gives you when you pass subscriber thresholds and adds absolutely no information of importance) and "associated acts" who have been deemed not important enough to mention in the Lead. Indeed, in many biographies of actors, performers and other creative people, I have seen users insist that the "YouTube" section be included, even where it is of scant importance to the subjects' careers. The box is mechanical and lacks context and nuance, requiring trivial information to be included. For example, why is a person's place of death important, in most cases? Plus, a lot of information in these IBs, like "years active" is often unclear and lacks adequate referencing to give a definite year. In these infobox debates, most of the people "voting" and commenting are people who have never edited the article, have no interest in the subject, and who will never contribute anything else to the article. As Anarchyte suggested, the editors who have created, expanded, and maintained the article, or at least who have a good-faith interest in contributing to the article, should be the ones who decide whether an infobox should be included or not -- not folks who are attracted merely because there is an infobox debate or RfC. See Signpost report: "Infoboxes may be particularly unsuited to liberal arts fields when they repeat information already available in the lead section of the article, are misleading or oversimplify the topic for the reader". -- Ssilvers (talk) 19:37, 2 May 2023 (UTC)
So you’re saying that (as is the current unwritten status quo) that you need X number of edits to get WP:OWNership privileges on an article? As if that’s really been working out great so far and isn’t a complete violation of the collaborative spirit of Wikipedia? Dronebogus (talk) 19:42, 2 May 2023 (UTC)
Not at all. You need a good faith interest in the article. It's a complete violation of the spirit of Wikipedia (and all the ArbCom decisions on the topic) to start an RfC knowing that the must-have-an-infobox crowd hangs around RfC for the purpose of forcing inforboxes into articles that are better without them. -- Ssilvers (talk) 19:46, 2 May 2023 (UTC)
(edit conflict) Dronebogus, Can you drop the uncivil language please? It's not ownership: it's WP:stewardship in developing an article. Insulting other editors for having an opposing viewpoint isn't going to help anyone. - SchroCat (talk) 19:48, 2 May 2023 (UTC)
Ssilvers, are getting into conspiracy theorist territory and casting aspersions. That is the complete opposite of good faith and the spirit of Wikipedia. Dronebogus (talk) 19:54, 2 May 2023 (UTC)
I'm not sure I agree there. To be clear: I've participated in one RFC concerning infoboxes. My vote was initially a slight oppose, which I changed to "neutral". But I don't think editors who are inclined to see infoboxes as beneficial are at all violating the spirit of Wikipedia or the ArbCom decision if, when a request for comment is made, they chip in their opinion that an infobox is useful on that particular page. And, due respect @Ssilvers, particularly because I know that you're a valuable and talented content creator/editor, but seeing as you've (by my count) participated in 6 of the last 10 RFCs—some on pages you were heavily involved with, some very much not so—using, as we've discussed, very similar statements on each ... surely your opinion isn't that "editors who always vote against infoboxes in RFCs can drive by in the spirit of Wikipedia, while editors who always vote for infoboxes can't".--Jerome Frank Disciple (talk) 19:56, 2 May 2023 (UTC)
Would you all *please* indent your comments in a way that makes it clear where each new comment begins? As for your Comment, Jerome Frank Disciple, what? I never said anything like that. What I mean to suggest is that, in my version of WP utopia, an editor should have an interest in a subject in order to give a useful opinion about whether or not it should have an IB. But I recognize that is not how WP works. -- Ssilvers (talk) 20:03, 2 May 2023 (UTC)
Oppose. A poor solution looking for a problem that doesn't exist. We have a good current guideline and a good RfC system to discuss the cases where there is a question. Sometimes the consensus is to include; sometimes it is to omit. This WP:CREEP is unnecessary.Using an arbitrary metric to determine whether an IB should exist is the wrong way to consider whether an IB should be used, and this raises more questions than it answers. The question of the "first paragraph" fails to address the importance of the information in the box – and that should be the one of the key drivers. For example, we don't tend to have the town of birth or death anywhere in the lead because they are not really that important (as in, they don't tend to be the reason for the individual's notability or affect anyone's understanding of the individual, so there is an element of trivia about them), but those fairly useless bits of information will now be used to force in an IB despite their lightweight usefulness. In other words, this proposal treats all factoids as equal, regardless of whether they aid the reader (the number of children someone has, their height, political affiliation etc – they may be known, but should that be the sole factor in deciding whether an article has to have an IB). There's a long list of fields that are more or less important in providing relevant information about an individual, but some of them should not be used to determine the presence of an IB.The guideline is open to gaming (from both angles). A long(ish) first paragraph could be argued to negate the need for a box, while someone could split a paragraph into two very short ones to justify an inclusion. Why are we introducing something so open to gaming? – SchroCat (talk) 19:49, 2 May 2023 (UTC)
Clarify: Oppose both proposals. The first as above, the second as it doesn't clarify anything or provide a concrete alternative to the existing wording. - SchroCat (talk) 15:04, 4 May 2023 (UTC)
I actually do agree with the last bit about gaming, but anything less vague would immediately be torpedoed as partisan. Dronebogus (talk) 19:57, 2 May 2023 (UTC)
Well it is partisan already... As it stands, this could be used to force an IB in pretty much every article over a stub, which is not necessarily the best thing for every article. Don't forget, we're not talking every biography here - we're looking at some biographies in limited areas - those that don't have rank or positions to tabulate, or those that have sporting records and histories that fit neatly into a box. I don't think I've ever seen an article on a member of the military, or a politician, or a sports person, where there has been any question - and quite right too: they are the biographies where an IB works brilliantly. The problem comes with some in the liberal arts or an occasional historical person where the benefits of a box are not clear cut. Forcing boxes into articles (which is what this proposal will do) does harm to a small number of articles. - SchroCat (talk) 20:06, 2 May 2023 (UTC)
One where things come up for discussion and come to a consensus. That is what has happened in the RFCs listed above - and the ones that have been missed out from the list too. - SchroCat (talk) 20:06, 2 May 2023 (UTC)
Not always long, nor contentious. Yes, some people can’t let a matter drop and will keep re-litigating until they get an answer they want, but the system works. This bit of instruction creep won’t stop that - it’ll still be argued about, with the extra bonus that there will be accusations of people gaming the rules. - SchroCat (talk) 22:08, 2 May 2023 (UTC)
The change is, in my view, a step towards standardization. It’s not good, but it provides some structure and any radical changes won’t receive support at this point. Dronebogus (talk) 23:22, 2 May 2023 (UTC)
Weak Oppose. This isn’t something we can write one-size-fits-all “rules” about. I have no problem with the idea that most bio articles should have an infobox included, but there will always be exceptions to that generalization. Whether a specific article should omit an infobox can and should be determined by local consensus - asking the simple question: Does it make sense to include/omit it in this case? I have no problem if the results of asking this question are inconsistent… in fact, I would expect inconsistency - because each situation is unique. Blueboar (talk) 19:53, 2 May 2023 (UTC)
Addendum in response to the original RFC question being changed/updated - I’m still on Weak Oppose - I find the proposed guidance to be overly restrictive instruction creep. Under the current language, most bio articles will continue to have an infobox, but I see no reason why consensus at the local level should not determine that a specific article should omit. Reaching consensus is often messy and time consuming … but that is a feature, not a bug. Blueboar (talk) 15:24, 4 May 2023 (UTC)
But is that inconsistency good? Because personal experience witb these RFCs tells me it isn’t. It’s confusing and the “no box” enclaves usually collapse anyway. I urge you to reconsider. Dronebogus (talk) 19:59, 2 May 2023 (UTC)
“One size fits most” is a thing. We can make exceptions in exceptional cases, it’s just that most cases I’ve seen are not. They’re arbitrary at best and weird enclaves policing weird local rules nobody else understands at worst. Dronebogus (talk) 23:27, 2 May 2023 (UTC)
@Blueboar: It is a recommendation. Infoboxes are not required for every article that passes the criteria, but they generally should be there. There may be exceptional circumstances that allow for the exclusion of infoboxes even if they do pass the criteria. Nythar (💬-🍀) 20:05, 2 May 2023 (UTC)
Oppose Thanks for the effort but:
I see no need for this
It has a flaw - why should something that is in the first paragraph be excluded from the info box?
IMHO not an improvement. Sort of longer and confusing
IMO works in the wrong direction. Puts a finger on the scale towards inclusion of infoboxes. Why? IMO when in doubt leave it out.
Fair comment! Just to clarify, in response to your two questions: (1) the proposal isn't suggesting that items in the first paragraph should be left out of the infobox; rather, it's declining to recommend that an infobox be put in if it merely reflects first-paragraph information (e.g., name, birth, death, etc.). (2) The reason it does (I'd argue very slightly) put a finger towards inclusion is because, as stated in the background section, 8 of the last 10 RFCs that reached a consensus did so in favor of infobox inclusion, and all 10 pages now have an infobox on them. A "when in doubt leave it out" policy, I think, wouldn't reflect that there seems to be a growing trend of infobox desire/acceptance (though that's not to say that those who always oppose infoboxes in RFCs have significantly softened or warmed to them).--Jerome Frank Disciple (talk) 20:24, 2 May 2023 (UTC)
Thanks. Regarding the "first paragraph" I agree that it structurally says as you describe. But IMO it implies that an infobox isn't for the the material in the first paragraph. Sincerely, North8000 (talk) 20:47, 2 May 2023 (UTC)
7 of the last 106 out of ten. Mackenzie Ziegler’s discussion ran alongside the formal RfC of her sister. The same people !voted in both and both received a formal close from the same person. It was an RfC in all but name. - SchroCat (talk) 20:35, 2 May 2023 (UTC)
No, sorry, 8 of the last 10. I think you missed my qualifier there—RFCs that reached a consensus. (I'm not sure how Mackenzie's spot in the table got taken out? I supposed because it wasn't an official RFC. Either way, neither Ziegler page reached a consensus.) --Jerome Frank Disciple (talk) 20:38, 2 May 2023 (UTC)
7 of 10Six out of ten (Francis Bacon has been pointed out); the Mackenzie Ziegler was near as dammit an RfC, but if you want to stack the numbers one way, I guess that’s the one way to do it. The fact there was no consensus to add doesn’t mean no consensus. - SchroCat (talk) 20:48, 2 May 2023 (UTC)
Schro, I'm baffled here. The closer at the Mackenzie Ziegler page said, exactly, "Closing this as no consensus, with a similar conclusion to the one seen at Maddie Ziegler's RfC." (that's what they bolded). And the closer at the Maddie Ziegler page said, "[T]here is no clear consensus on whether this article should have an infobox." (again, what they bolded).--Jerome Frank Disciple (talk) 20:52, 2 May 2023 (UTC)
When you’ve been here more than a couple of months, you’ll grasp the language of a closer a little better. - SchroCat (talk) 21:03, 2 May 2023 (UTC)
personal discussion
The following discussion has been closed. Please do not modify it.
Was an IP editor for a long time, thanks :) The closer is, plainly, directly contradicting what you're saying. But seeing as there's so rarely been a consensus in favor of exclusion, and seeing that you've opposed infoboxes in so many of the recent RFCs, I can understand if you're a bit desperate to claim wins where you can.--Jerome Frank Disciple (talk) 21:07, 2 May 2023 (UTC)
I’m not desperate at all, by the way, so it appears your mind reading is as flawed as this proposal. Either way, this charming aside on my history of IB discussions is all rather utterly meaningless, so I’m going to leave you to it. - SchroCat (talk) 21:14, 2 May 2023 (UTC)
@North8000: The purpose of including infoboxes is that they are a tidy, easy-to-access summarization of the biographical contents of an article that pertain to the individual; partial descriptors, you may call them. They provide a basic overview of a person in conjunction with the lede, which provides the rest of the overview. And to answer your second point, this proposal doesn't exclude from the infobox the information found in the first paragraph. It simply excludes an infobox if the only information that could be added to the infobox is found in the first paragraph. That is because readers shouldn't need to spend lots of time having to look through more paragraphs, or even the entire article, just to find some basic information on the subject, like location of birth or spouse. If the info can already be found in the first paragraph, an infobox isn't really important because there isn't much reading that needs to be done to locate the basic information that would otherwise be included in an infobox. Nythar (💬-🍀) 20:26, 2 May 2023 (UTC)
When there is basic straightforward factual infobox type material available on the topic, I think the infobox is a great idea. When not, not. Regarding the "first paragraph" I agree that it structurally says as you describe. But IMO it implies that an infobox isn't for the the material in the first paragraph. Sincerely, North8000 (talk) 20:51, 2 May 2023 (UTC)
Oppose as unnecessary WP:CREEP. For biographical articles where there is something good to put in the infobox then they are great, but for the minority of articles where most of the parameters are subjective or controversial then they are not. The current system would work now if RFCs didn't attract the "have an infobox whether it contains anything useful to the reader or not" crowd. Phil Bridger (talk) 20:40, 2 May 2023 (UTC)
Oppose. This will make things so much worse. Even leaving aside the amount of gaming something like this would prompt on both "sides", it's completely illogical. It proposes to look at details that weren't considered important enough to include in the opening paragraph and use those to justify including an infobox - which is meant to summarize key facts? You could go to almost any article that already has an infobox and identify something that could be added to it, but could does not mean should. All this proposal does is encourage the former over the latter, and prompt arguments over that, rather than reducing conflicts. And all of the arguments put forward in support thus far add up to "We should do something. This is something. Therefore we should do this", rather than engaging with the details of the proposal. Nikkimaria (talk) 00:23, 3 May 2023 (UTC)
I thought the proposal was badly worded from the start. I just wanted it to be “infoboxes are recommended for biographies [because WP:SURPRISE and standardization]” and that’s it. I initially thought a weak guideline that “helps” nobody in particular was necessary but now I just wish I’d pushed for the simple version. Dronebogus (talk) 02:24, 3 May 2023 (UTC)
Oppose per my comments in the previous discussion. Most of the time, infoboxes are indisputable. The remainder of the times, the decision should be left to those with a vested interest in the article (not the same as ownership). Dubiously enforceable policies prone to gaming isn't the best way to go about this, as discussed by Nikkimaria. Anarchyte (talk) 02:07, 3 May 2023 (UTC). Update: I also oppose the new alternatives for the same reason: attempting to encourage editors to blindly consider infoboxes as being required, with little regard for local consensuses. Anarchyte (talk) 03:44, 5 May 2023 (UTC)
No functional distinction exists between having a vested interest in the article that somehow allows a small group of editors to control the content that gets added to an article and WP:OWNERSHIP. Wikipedia:Ownership of content#Multiple-editor ownership states The involvement of multiple editors, each defending the ownership of the other, can be highly complex. The simplest scenario usually consists of a dominant editor who is defended by other editors, reinforcing the former's ownership. This can be frustrating to both new and seasoned editors. And it's true; this is quite frustrating, as I'm not able to get the point across that the things that you are describing are by definition "ownership". Sure, the editors of an article might possess better understanding of its contents than most others, and they're more than welcome to present their points at RfCs. But nowhere on Wikipedia are editors allowed to control content against the community's desires. Nythar (💬-🍀) 02:23, 3 May 2023 (UTC)
Exactly. The whole reason infoboxes are contentious are because a very small group of editors have organized themselves against them on certain articles dogmatically, and get mad and blame “the pro-infobox condpiracy” when people point that out. This is just deletionism vs. inclusionism all over again— the inclusionists actively set up support networks to systematically stonewall deletion and blamed a similar, nonexistent conspiracy when people pointed out their gaming. Now that the network has been broken down in various ways, deletion is far less ugly. Dronebogus (talk) 02:30, 3 May 2023 (UTC)
It's the same way that the primary contributors get to decide the date format used in the article. I'm not saying the authors have the dictatorial say in whether an infobox is included, but whatever the decision is during the construction should be the status quo requiring local consensus to change. Per WP:STEWARDSHIP, in many cases, a core group of editors will have worked to build the article up to its present state and will revert edits that they find detrimental in order, they believe, to preserve the quality of the encyclopedia. Such reversion does not indicate an "ownership" problem[...]. Anarchyte (talk) 05:20, 3 May 2023 (UTC)
There is an actual distinction between stewardship and ownership. The behavior that you described above is ownership. Reverting edits that they find detrimental should not give them total control of articles and immunity from RfCs. We usually refer to such behavior as ownership. Nythar (💬-🍀) 12:12, 3 May 2023 (UTC)
I didn't mention immunity? I'm aware of how ownership and stewardship differ. As I said earlier, I'm not saying the authors have the dictatorial say in whether an infobox is included, but whatever the decision is during the construction should be the status quo requiring local consensus to change.WP:CCC. Anarchyte (talk) 13:00, 3 May 2023 (UTC)
Oppose. This comes across as WP:CREEP, and I fail to see a good argument for why biographies should be a special case different from other categories of articles that also generally have infoboxes. As a practical matter, if most biographies have infoboxes, that trend will continue, but with this addition, I could see the recommended language being wielded to try to push infoboxes on some of the few biographies where they aren't so useful. I also have some qualms about the criterion of information that isn't in the lede. Often, such information may be trivia that gets stuffed in the infobox because a parameter exists for it but that doesn't rise to the level of due weight for rightful inclusion in the lead. In those cases, that's actually an argument against having an infobox in that particular article. {{u|Sdkb}}talk02:37, 3 May 2023 (UTC)
Oppose, I don't see a strong need. Personally, I usually don't notice whether articles have infoboxes (they go into my banner blindness spot, just like navigation sidebars). For many biographies (especially pre-1800) a huge amount of information is uncertain or non-standard, which is difficult to reflect in an infobox, and there should be nothing that forces editors to display such information in boxes. Where potential infobox information is located seems unrelated to whether we should have one (this seems to be an argument that could easily be used to force information into the infobox that isn't very important for the specific person). —Kusma (talk) 12:23, 3 May 2023 (UTC)
Continue to oppose, the new options are worse. Whether an infobox is helpful or not depends on completely different properties of the article than stub-ness. —Kusma (talk) 15:37, 4 May 2023 (UTC)
Oppose as WP:CREEP, largely per Skdb and SchroCat. The current system is not perfect, no. But to create a set of rules to recommend the usage of userboxes specifically for biographic articles based on a few iffy parameters will likely worsen the debates. You cannot guarantee that even if these parameters were met, that an infobox would be ideal for that situation based on the content. And even then, just saying that it is "recommended" doesn't really give it any teeth; people who disagree with the practice will likely pay no heed to it. --⛵ WaltClipper-(talk)12:44, 3 May 2023 (UTC)
Oppose This is something that needs to be worked out at the article level, not having a universal policy. If an article needs one, put it in. If it doesn't, don't. We don't need a rule to decide that. --Jayron3212:45, 3 May 2023 (UTC)
Oppose the main benefit of use a guideline would be "niceness" in terms of consistency—but Wikipedia often realizes that consistency is not the be-all, end-all (hence ENGVAR, etc.) and that more prescriptive guideline proliferations harms as often as helps. The RfC setup we've got has by all appearances worked fine. Der Wohltemperierte Fuchstalk00:05, 4 May 2023 (UTC)
Oppose all changes. We should not recommend infoboxes in any form. They are almost always worthless clutter, oversimplified and with significant omissions. See WP:DISINFOBOX. And having a lead that does not contain the same information is an especially bad reason for recommending them: either the information was appropriately omitted from the lead as non-leadworthy (in which case it should not be forced into the lead anyway by adding it to the infobox) or the lead text needs improvement. —David Eppstein (talk) 01:58, 4 May 2023 (UTC)
And close this RFC as an out-of-process disaster and moving the goalposts now that it has been totally changed from the one so many people have already commented on. —David Eppstein (talk) 16:30, 4 May 2023 (UTC)
Hello! In response to the requests for alternatives and asking the proposer, I updated the RFC, which was started two days ago, to include the various options suggested. I pinged every editor that had voted so far, which I imagine is what prompted you to reply here. I see you've been able to respond to that update in a perfect competent manner, and several other editors have done the same. Is there any reason you think others won't be able to?--Jerome Frank Disciple (talk) 16:33, 4 May 2023 (UTC)
Oppose. 1. The initial justification for the guideline refers (twice) to the infobox would contain textual information but the proposed guideline says information ... that could be put in an infobox (note the change from "would" to "could"). The latter seems less justified – a criterion should not depend on lesser matters in the infobox. 2. Any guideline should also include criteria for when infobox removal is recommended on account of such things as changes made to the inbox template coding or the actual contents of the infobox and first paragraph. 3. My observation on the numerous debates is that people care about whether or not there is an infobox at all. It would be a shame if the arguments changed to being about the detailed contents of the first paragraph as a proxy for the real point of contention. Thincat (talk) 11:18, 4 May 2023 (UTC)
Oppose per WP:CREEP. We don't need rules on everything, and prioritising consistency over editorial judgement is rarely the best option when dealing with complex topics. AndyTheGrump (talk) 12:17, 4 May 2023 (UTC)
Oppose per many editors above. Arts biographies in particular are challenging for infoboxes. See Francis Bacon (artist) for an example. There have been many discussions not only about the infobox but how to put contentious things like his nationality into a format that is accessible in the ibox. It was decided that he be described as 'Irish-born British.' His oeuvre is also hard to shoe-horn in: "His output can be broadly described as sequences or variations on single motifs; including the 1930s Picasso-influenced bio-morphs... the 1950s 'screaming popes' ... and the cooler, more technical 1980s paintings.". Describing the subject as a 'Figurative painter' lacks nuance. Consider as well the shrinking of a picture of the article subject being shrunk to fit an ibox. Some of our free use pictures would become difficult to discern when shrunk to ibox params. Too much CREEP, to little nuance, bad idea. Jip Orlando (talk) 16:22, 4 May 2023 (UTC)
Oppose per Kusma. I generally like infoboxes and am a bit bemused by the strong opinions some people have about them. However, articles, it is simply not possible to fill them out to a useful degree while still satisfying WP:V. The information is simply not available, or not undisputed. At that point, it just creates more busywork for the editor and nothing useful for the reader. Gnomingstuff (talk) 18:23, 5 May 2023 (UTC)
Oppose Rules like this would just give make-work people things to argue about. Those interested in developing a particular topic should choose what is best for the articles concerned. Wikipedia relies on volunteers and follows the bazaar model where one-size-fits-all rules are inappropriate. Johnuniq (talk) 00:21, 6 May 2023 (UTC)
One more thought: with the removal of the centralized TOC in the new vector skin, infoboxes have become an aesthetic monstrosity, squeezing text and displacing images in the first section. If anything, we should be discussing removing or condensing many IBs, rather than this soft de-facto mandate. ~ HAL33301:56, 10 May 2023 (UTC)
Oppose - It would lead to a lot more arguing and edit-warring when inevitably User A tags a page for not having an infobox and User B disputes it. An infobox is not needed for many articles and for some, especially with crime and embarrassing incidents, it would come across as demeaning. It's also okay for various pages to look different.KatoKungLee (talk) 17:16, 7 May 2023 (UTC)
I don’t know how an infobox can be “demeaning”. It seems like people are just making up excuses to oppose at this point. If you think this is a “local consensus” thing or you think it’s an unhelpful proposal that would make things worse, just say that. Don’t grasp for weird secondary arguments. Dronebogus (talk) 19:07, 7 May 2023 (UTC)
Oppose As some others have written above, I don't find the proposed changes to be nuanced enough to incorporated as recommendations in the Manual of Style. Even for longer biographies, some considerations are best discussed in the context of a particular article, to the point that I prefer the status-quo guidance. DanCherek (talk) 19:54, 7 May 2023 (UTC)
Oppose It's possible to discuss it for longer articles on their talk page but an infobox for a shorter article or not doesn't really matter and is going to lead to lots of useless arguing/discussions. Coldbolt (talk) 09:15, 9 May 2023 (UTC)
Oppose - I personally quite like them, but they are contentious, and given that I don't think any guideline beyond what we have now ("deal with it case by case") is appropriate. Andrew Gray (talk) 18:46, 16 May 2023 (UTC)
Oppose/other. Sort of like what Rhododendrites wrote below, I think a more appropriate resolution is to put more weight behind retaining existing styles, in the face of both styles being permitted and both styles having enduring community support. If we apply a stronger compromise in favor of retaining the established choice of an article, then repetitive individual RfCs proposing changes become less likely to succeed and are discouraged in that way. The guideline should clarify that, in disputes at individual articles, adding or removing infoboxes requires particularized reasons for that specific case, beyond merely arguments of a general nature or personal preferences, which are insufficient. Adumbrativus (talk) 07:30, 19 May 2023 (UTC)
Oppose even though I personally like infoboxes, I hate the idea of making anything even resemble mandatory or needless CREEPy restrictions, and the proposal doesn't make much sense per the good logic of users like SchroCat, Skdb, Thincat, and Nikkimaria. Huggums537 (talk) 02:37, 21 May 2023 (UTC)Updated on 02:41, 21 May 2023 (UTC)
Oppose. The less rigid the rules the better. It is fine for this to be determined by consensus only. If there is a change, only support option 3 Jack4576 (talk) 14:42, 22 May 2023 (UTC)
Oppose Infoboxes can be useful but personally I believe Wikipedia is more negatively affected by too much infobox (ie. unimportant information, excessive length overall, filling parameters with misleading and unverifiable information because the parameters are there) than no infobox. (t · c) buidhe04:43, 25 May 2023 (UTC)
Strong Oppose per Ssilvers and others above. We all know that "recommended" = "absolutely compulsory". The great majority of bio infoboxes are not at all controversial, but when there is opposition, there is usually a very good reason for it. All these proposed changes will make sensible discussion impossible. Johnbod (talk) 02:30, 28 May 2023 (UTC)
It’s about two individuals. It wouldn’t benefit at the top. But I see no reason why each individual couldn’t have a separate infobox. Dronebogus (talk) 12:03, 31 May 2023 (UTC)
And what would you place within the infoboxes except their names and date of births? If you're proposing they be placed in #Early lives, this information has already been explained in the lead and the first sentences of their respective sections, so we'd be printing it three times. Anarchyte (talk) 14:34, 31 May 2023 (UTC)
This proposal lacks support to adopt, but the article in question would not be effected by this proposal. I wouldn't recommend an infobox for that article and this proposal wouldn't require one. However, for the articles that were mentioned in the proposal that haven't reached consensus, they'll ultimately come up again. I guess they will have to be village pumped to overcome the localized opposition. I haven't looked, but there's probably not too many articles left where this is happening so I guess this is how this debate ends. Nemov (talk) 14:57, 31 May 2023 (UTC)
The problem is that if you remove the subjectivity (and I understand the proposal says "recommended", but let's be honest), articles like Boulton and Park, which is a collective biography (and therefore falls under "For biography articles"), will end up with infoboxes shoehorned in by people that made no other contributions to the page and have in all likelihood not read the sources. Anarchyte (talk) 15:02, 31 May 2023 (UTC)
I understand your point, but that could happen today if someone creates a RfC about it. One of the common arguments against infoboxes in cases where they've been easily approved is "there's no policy on infoboxes." When I've brought infobox RfCs here a common statement is "you should create a policy for this so these RfCs quit happening." Well, here we are... Nemov (talk) 15:12, 31 May 2023 (UTC)
Oppose. Mostly per Johnbod, but others make good points. Better to leave this to the discretion of individual article editors. The desire for consistency between similar articles is not automatically a bad thing, but it shouldn't lead us to establish rules that are sometimes going to be in conflict with the best outcomes for particular articles. Mike Christie (talk - contribs - library) 14:39, 31 May 2023 (UTC)
Discussion (establishing a biography infobox guideline)
I added a statement on your behalf, Nythar (which I assume is okay since I helped craft the background section and stuck to your proposal). If you endorse it, just sign.--Jerome Frank Disciple (talk) 19:23, 2 May 2023 (UTC)
The idea of using an arbitrary metric such as "textual information—aside from external links—that could be put in an infobox beyond what is found in the article's first paragraph" is vague, too open to misinterpretation (either accidentally or deliberately) and so open to gaming by anyone, that it's a weak and poor proposal. It's been rushed through by a small group of editors (all acting in good faith, no doubt), but it's lead to a poor proposal. Even its supporters are admitting it's a poor proposal. Wouldn't workshopping alternatives be a better step than the adoption of something that is fundamentally flawed?One of the problems with biography IBs discussions (and it's a problem that isn't addressed in the proposal) is that there is no baseline agreement of what is considered "important" or "core" information that should be in any box. If such basic fields could be identified it would be a start of something far more useful. On the basis of that, a discussion could be had on how many of those basic fields need to be present to trigger a box. I'm thinking of actual "core" pointers - dates of birth and death are two obvious places to start, but it should be easy enough to come up with a list of 10 or 12 "core" fields, the presence of 5? 6? 7? 8? of which trigger a box unless there are extremely good reasons why there shouldn't be. It would be a damned sight better than the second rate proposal on offer at present. - SchroCat (talk) 09:54, 3 May 2023 (UTC)
Textual information—aside from external links is not arbitrary at all. We discussed this for a while until we landed on that. Usually the first paragraph is the most dense and has the most amount of description. If you can find all the information that could exist in an infobox in the first paragraph of an article, why have an infobox? But it is rather tiresome if you need to look through the entire lede (some ledes can be extremely long) or even the entire article just to find basic information about a subject. Like I said above, The purpose of including infoboxes is that they are a tidy, easy-to-access summarization of the biographical contents of an article that pertain to the individual; partial descriptors, you may call them. They provide a basic overview of a person in conjunction with the lede, which provides the rest of the overview. The wording of the proposal is purposely left vague in order to allow for exceptional circumstances. Remember, nothing on Wikipedia is required, except maybe the civility and BLP policies. But anyway, this reply isn't intended for you; it's just to inform users who may be passing by. Nythar (💬-🍀) 12:25, 3 May 2023 (UTC)
A couple of things. Firstly, as you have done above, can you stop referring to stewardship as ownership? If you are trying to wind people up, then accusing them of ownership is a great way to go, but when people have spent a lot of time, effort (and normally) money in taking an article from something sub-standard to something the encyclopaedia can be proud of, then dismissing their efforts as "ownership" is a great way to get people's backs up. I'm sure that isn't your intention, but that's the effect it has. Maybe if you spent time trying to create some content, you might get an idea of what it's like to be accused of "owning" it when you remove something that is poor.Secondly, you and your fellow supporters don't have to respond to pretty much every comment that opposes the proposal. It's already crossed the line in WP:Bludgeoning and it hardly makes for a place where you will get the community to join in, unless you are actively trying to stop people opposing?"We discussed this [paragraph] for a while": you haven't actually spent that long discussing it - less than a week on WP isn't a terribly long time to discuss a contentious topic. Maybe a slightly wider call for people to chip at that stage would have come up with something better than the rather poor offering here."Usually the first paragraph is the most dense and has the most amount of description". Did you do much research or analysis to get to that conclusion, because it's a long way off what I have seen. Just looking at a couple of the articles listed about, Debussy has three sentences (34 words after the date of death brackets); Olivier, 3 sentences with 58 words; Kubrick, two sentences of 51 words. Those are short, tight paragraphs about people - and yes, they contain the "basic information about a subject". That's a long way from "most dense". Still, it's good to know that the way to legitimately avoid activism on the point of IBs is to write longer leads to ensure that first paragraph negates the need. Is that really the intention of the guideline? I know you are desperate to have IBs in biographies for some reason, but this proposal is the wrong way to go about it. - SchroCat (talk) 12:52, 3 May 2023 (UTC)
For me, the decision as to whether a bio article should/should not have an infobox comes down to answering two simple questions: 1) is there an appropriate infobox template that relates to the subject? 2) Do we have enough verifiable data to populate the core fields in that template?
If the answer to both of these questions is “yes”, then the article should have an infobox… if the answer to either of these questions is “no”… then the article shouldn’t have an infobox (it just does not make sense). Blueboar (talk) 12:44, 3 May 2023 (UTC)
A valid point, and it's one that shows the weakness of the current proposal. What I've (very roughly) sketched out above should deal with that - as it goes to something no-one has really looked at in a methodical way since IBs were first introduced: what is the "core" information. We have fields for any number of points but those shouldn't be used in general biographies (height is a good example of one - great for "world's tallest man" or basketball player articles, but meaningless for most articles). As I said above, birth and death dates are two obvious ones, but a box looks ridiculous and does zero benefit if they and the name are the only fields present. - SchroCat (talk) 12:57, 3 May 2023 (UTC)
Many of the oppose comments feature hypothetical arguments that are non-existant in these RfC discussion. If you review the articles mentioned in this proposal you'll see that the arguments (include/exclude) pretty much the same every time. The infoboxes are getting included anyway. This proposal is attempting to confirm the consensus which is infoboxes are increasingly common and accepted. This proposal doesn't make them mandatory, so someone could make your argument and if it's compelling then there will be no infobox. Valuable editor resources are wasted in these repetitive debates that are being played out in RfCs over and over. If these debates were deadlocked I could understand, but infoboxes eventually get added anyway. As someone who is a dedicated RfC commenter this is a colossal waste of time for an inevitable outcome. It seems like the community would attempt to find a solution to save editor's valuable time. Nemov (talk) 13:04, 3 May 2023 (UTC)
"Many of the oppose comments feature hypothetical arguments that are non-existant in these RfC discussion": I don't know what you're trying to say here.Yes, the arguments are the same in the various IB discussions - that's because there is no direct research or studies to show whether they are useful or wanted by readers; the 'think of the readers - they need an IB' claim is based on nothing but wishful thinking. That means it comes down to opinion and the newer intakes of editors are less flexible in their approach to IBs than many of the older hands who remember the site before IBs were a feature and can see the downsides to them too.Valuable editor resources? No editor is required to go to an RfC, no editor is required to open an RfC, but you've managed to spend a lot of time on them (more time on talk than editing articles, I see; perhaps you should try writing an article, rather than just commenting from the side-lines?) And an "inevitable outcome"? ThreeFour of the last ten discussions have rejected a box - and 70%60% isn't "inevitable". Either way, that's no reason to have a flawed and easily-gameable guideline. - SchroCat (talk) 13:18, 3 May 2023 (UTC)
No consensus closings preserve the status quo ex ante (except in the cases of BLP issues, copyright vios, or external links—see WP:NOCONSENSUS). I wouldn't classify a no consensus vote that results in a status quo box or status quo no box as approving or rejecting a box. And Wikipedia editors put themselves in the shoes of readers all the time—that's not unusual. Wikipedia editors are, also, readers. And, in terms of non Wikipedia editors, as you've admitted, stray IP editors that comment tend to support infoboxes. Not the strongest datapoint, to be sure, but one nonetheless.
And enough with the personal attacks—"try writing an article[] rather than just commenting from the side[]lines"? I understand you're frustrated that "newer intakes of editors ... can['t] see the downsides" of infoboxes, but perhaps, then, you've been around on Wikipedia long enough to be familiar with WP:CIVIL.--Jerome Frank Disciple (talk) 13:44, 3 May 2023 (UTC)
I think we need more examples. For example, I don't think an infobox should be recommended for B. Traven or other people whose identity is subject to debate. —Kusma (talk) 15:42, 4 May 2023 (UTC)
That is the sort of thing I might oppose, but that’s an exceptional case. Famous composers are not. Famous writers are not. Celebrities are not. We have concrete information on these people. Dronebogus (talk) 15:45, 4 May 2023 (UTC)
This is why I wouldn't support a mandatory rule because there are exceptions. If that were discussed on I'd probably be inclinded to oppose an infobox for that article. Nemov (talk) 15:47, 4 May 2023 (UTC)
I'd be much happier if we had some agreement on what the exceptions could look like. If basic facts like year of birth and death are unknown or uncertain, there should not be an expectation that the article has an infobox. Generally, many pre-1900 lives do not fit into our infoboxes well. —Kusma (talk) 15:57, 4 May 2023 (UTC)
We we discussed this in the idea lab we'd have to craft some super complicated rule to manage exceptions. I just don't think that's going to be a problem. The issues in RfCs have been mostly slam dunk cases that are being relitigated over and over. A general recommendation is a far I'd go and there's significant wiggle room for the case you cited. The idea is that infoboxes help improve the article. In that it's not an improvement. Nemov (talk) 16:01, 4 May 2023 (UTC)
Without adequate protection for reasonable exceptions we should not have a recommendation one way or the other. —Kusma (talk) 16:26, 4 May 2023 (UTC)
@Kusma: The general trend is to include infoboxes in biography articles. Recommended exists in the wording of the proposal to indicate that there generally should be infoboxes; however, exceptional cases allow for actual consensus to be generated on talk pages, consensus that focuses on things other than "I generally support infoboxes in these cases so..." or "I generally oppose infoboxes in these cases so...". We don't need to clarify the exceptions; WP:CONSENSUS is one of the basic concepts all editors at Wikipedia should be aware of, and since the wording purposefully doesn't require anything, you should assume that real consensus can result in either the exclusion or inclusion of infoboxes regardless of the recommendation. And this is not WP:CREEP. In actuality, our current system is totally confusing for new editors who are inexperienced and aren't aware that editors who edit certain articles get to control the inclusion or exclusion of infoboxes. Nythar (💬-🍀) 16:36, 4 May 2023 (UTC)
Then why should we change the guidelines to recommend infoboxes instead of letting the actual main editors of an article decide on the appropriateness? Everything here is governed by consensus and confusing to newbies. The earlier they learn that Wikipedia is not consistent, the better. —Kusma (talk) 17:00, 4 May 2023 (UTC)
@Kusma: Because that's ownership? I see a few editors here are annoyed by my use of the term "ownership", so allow me to elaborate. The "actual main editors" of an article might have the stupidest reasons for including or excluding an infobox, or they might have the most well-thought-out reasons for doing so. Either way, they're the ones who decide on the appropriateness of infoboxes, rendering the opinions of most other editors ineffective. It's not like we have a system in place where the main editors must have good reason to include or exclude infoboxes. Apparently they can do so even on a whim. This proposal aims to eliminate this odd system, so that editors can have meaningful discussions that eventually result in neither actual main editors controlling infoboxes nor the regular "I like it" or "I don't like it" arguments, but instead real consensus that is article-specific. Nythar (💬-🍀) 17:11, 4 May 2023 (UTC)
Currently we need "real consensus" for a change in the status quo. The proposal says we should need "real consensus" only for exclusion of infoboxes, not for their addition, but does not actually give us any useful clues which articles should be exceptions. I agree that infobox discussions should be article-specific, hence I oppose suggestions that whole classes of articles should have infoboxes by default. —Kusma (talk) 17:21, 4 May 2023 (UTC)
@Kusma: To answer this, I'll repeat what I said above: The purpose of including infoboxes is that they are a tidy, easy-to-access summarization of the biographical contents of an article that pertain to the individual; partial descriptors, you may call them. They provide a basic overview of a person in conjunction with the lede, which provides the rest of the overview. That is why this proposal favors infoboxes. There isn't a need for exception-indicative "useful clues" because the proposed wording is simply a recommendation for including infoboxes for the reasons I highlighted; this recommendation does not override article-specific consensus, so long as that consensus is article-specific. That is implied by the fact that it is a recommendation. For example, infoboxes may be removed in exceptional cases granted that consensus to do so arises. This, however, is rare, and the proposal would solve most of our problems if passed. Nythar (💬-🍀) 17:34, 4 May 2023 (UTC)
"infoboxes may be removed in exceptional cases granted that consensus to do so arises": no. IBs may be removed at any time if they do not serve a valid purpose - no consensus is needed - that what WP:BOLD editing is. If someone objects, it can be reverted and a discussion should follow; if there's no agreement it goes to RfC (with the IB still there, as per status quo), but a consensus needed to remove the box. The proposal in either form will have no bearing on that. No-one needs a consensus to make that edit. As to the proposal being one that "would solve most of our problems", there is still no indication that there is a problem. We have had some RFCs recently, of which six have led to the inclusion of a box and four have not. Those RFCs ran OK. No one was censured or blocked. No one was taken to ANI or ArbCom for breaching the contentious topic guidelines. We have a good guideline on IBs already and a good mechanism for coming to (or overturning) a consensus. - SchroCat (talk) 17:47, 4 May 2023 (UTC)
The main problems with infoboxes are the inclusion of disputed or uncertain information, as infoboxes lack the necessary nuance, and the tendency of editors to fill out all fields, whether that is beneficial or not. Very often the place of birth is of limited importance for a person, so it isn't in the lead. There is no need for an infobox if all it does is give prominence to such non-important data. —Kusma (talk) 17:48, 4 May 2023 (UTC)
@Kusma: If you believe there is inaccurate information in an infobox or that one is composed solely of unimportant parameters (Template:Infobox person: religion, relatives, employer, baptized, death_cause, resting_place, resting_place_coordinates, burial_place, burial_coordinates, citizenship), you can totally start an RfC for the purpose of removing the infobox. If however the infobox contains mostly information that makes it appropriate for inclusion (date of birth, date of death, location of birth, location of death, name, nationality, spouses, and the like) then it is likely that you do not need to start an RfC. Seriously, all these hypotheticals are making this seem more complicated than it really is, but of course someone won't agree. Nythar (💬-🍀) 18:10, 4 May 2023 (UTC)
@Kusma:, As I am sure you are aware, you do not have to start an RFC before removing an IB. There is no such policy or guideline that says that and indeed, it goes against many of our policies and guidelines. The only time you need to go to RFC is if someone reverts the removal and no consensus can subsequently be reached - that's the point one should be opened. It is how the site has worked since inception and will continue to do so even if this proposal is passed. - SchroCat (talk) 18:17, 4 May 2023 (UTC)
And if you remove it, someone will very likely revert your removal, just as it is likely that adding an infobox will result in its removal. Don't get too focused on my explanations, I'm not wording them perfectly. Nythar (💬-🍀) 18:20, 4 May 2023 (UTC)
It depends on the subject and whether there is enough valid information. People add and remove IBs all the time without it ending in a brouhaha or without a reversion taking place - it depends entirely on the article's subject and whether there are enough pieces of key information to be of use to a reader. - SchroCat (talk) 18:24, 4 May 2023 (UTC)
If there is only irrelevant information in an infobox (and place of death is arguably mostly irrelevant for many people) it should be removed. Wikipedia works by being WP:BOLD, not by starting RfCs about trivialities. —Kusma (talk) 18:18, 4 May 2023 (UTC)
@Kusma: So you've chosen to focus on the fact that I haven't worded my explanations perfectly instead of responding to my actual points? You're correct, in the instance that you described, you'd remove the infobox. However, the entire point of this proposal is to find a solution for when someone does revert your removal. Then, you'd need to decide if an RfC is appropriate. The recommended indicates that infoboxes aren't a must; you should decide if an infobox made up wholly of useless parameters qualifies as an exceptional circumstance for removal. If you believe it does, start an RfC, and the infobox will very likely end up being removed. Nythar (💬-🍀) 18:25, 4 May 2023 (UTC)
No one needs to start an RFC every time they want to improve Wikipedia WP:BOLD is a bedrock policy, and if a person believes that removing an empty or useless infobox makes an article better, they don't need to start an RFC to do so. They can just remove it. --Jayron3218:29, 4 May 2023 (UTC)
@Jayron32: Please read what you plan on replying to before you do so. I wrote: the entire point of this proposal is to find a solution for when someone does revert your removal. And a solution for when someone reverts your addition. Nythar (💬-🍀) 18:32, 4 May 2023 (UTC)
Well, then an RFC is still jumping the gun a bit then. A personal conversation where you and the other person listen thoughtfully to each other will often result in a quick solution to problems. The issue we have is that everyone jumps to "Lets have a 30 day vote on this!" the second any slight hint of disagreement might exist. 90% of the time RFCs are overkill. It's a small issue, and it needs small solutions. --Jayron3211:39, 5 May 2023 (UTC)
Well, I'd have preferred a simpler solution, but that seems quite difficult to agree upon. Nythar (💬-🍀) 15:25, 5 May 2023 (UTC)
I hope I will never have to participate in RfCs about infoboxes on articles I care about. Mostly, I care little about infoboxes either way. Some of my articles have them, some of them don't. I rarely look at them (banner blindness I guess). When I nominate articles for GA, the fact that there is no recommendation for infoboxes means I do not have to have a long drawn out argument about including an infobox when I think it would not be beneficial. Why should it be my job to start an RfC, and not that of someone else who thinks they know better than the article's only author? —Kusma (talk) 18:38, 4 May 2023 (UTC)
Nobody at Wikipedia is forced to do anything. If you don't want to start an RfC, don't. Nythar (💬-🍀) 18:44, 4 May 2023 (UTC)
The following discussion has been closed. Please do not modify it.
How you personally classify something is up to you, but I will stand by my wording, particularly that there is no "inevitable outcome".What I have said about IP editors commenting is that there is a slim majority who !vote in support - but there is hardly likely to be a majority coming to the talk page to say "huzzah - no IB!", is there? They will only make it to a talk page if they see something wrong, and when there is no IB, there are very, very few comments from anyone except editors. As I have said, there is no reserch or study that backs the claims for or against an IB from a reader's perspective, so it's a staw man to try and keep pressing on that point. All it amounts to is personal opinion, which isn't the best way to try and enforce a formatting choice.There are no personal attacks in what I have written. It has always been the case that newer intakes of editors have different views from older ones, and there is nothing wrong in that - that's just observation and I'm not sure how you think that an attack? It's a bit of a stretch to claim that, so perhaps you ought to drop that particular line.Either way, you can try and pick up on one or two bits of what I have written in response to others, or you can be constructive and look at my comment in this section to discuss what is an actionable point. - SchroCat (talk) 13:54, 3 May 2023 (UTC)
Well, I defer to the closers. But I guess if you choose to decide their bolded words don't mean what they say, that's up to you.
And the snideness in "try writing an article" is absolutely incivility. "Well why are you paying attention to my incivility and not my substantive points" isn't a defense.---Jerome Frank Disciple (talk) 13:57, 3 May 2023 (UTC)
If you're trying to pick an argument, with comments that are not based on what I have said, or any reasonable interpretation of that, then you're barking up the wrong tree. - SchroCat (talk) 14:02, 3 May 2023 (UTC)
Undecided, but mainly want to highlight objections by some in the oppose camp along the lines of WP:CREEP or a suggestion that it be "evaluated on a case by case basis". The assumption in "case by case" is that people who care enough about the article or subject will talk it out, perhaps with the help of a DR mechanism. In reality, it's not people who care about the article; it's people who care about infoboxes. The RfCs are iterative and more or less identical, rather than specific to the case. "Case-by-case" just turns it into a question of numbers based on personal preference (based more on broad ideas of "what an infobox ought to do" or "what helps readers" rather than what makes a particular article special). In general, I'm inclined to support additional clarity about when to include an infobox to avoid RfCs that boil down to headcounts that have almost nothing to do with the article itself. I don't know if this provides enough such clarity though, per Nikkimaria, et al. It may just slightly reorient it. Here's the proposal I would support: "Treat the inclusion or exclusion of an infobox in the same way as WP:CITEVAR, applying this statement by the Arbitration Committee: Where Wikipedia does not mandate a specific style, editors should not attempt to convert Wikipedia to their own preferred style, nor should they edit articles for the sole purpose of converting them to their preferred style, or removing examples of, or references to, styles which they dislike.". At the end of the day, we have no clear criteria for including an infobox, meaning it's just a personal preference issue, like CITEVAR/ENGVAR. — Rhododendritestalk \\ 13:27, 3 May 2023 (UTC)
Now that I think about it, why doesn't that statement by arbcom already apply. Infoboxes are, after all, an example of "where Wikipedia does not mandate a specific style". Shouldn't WP:INFOBOX simply have a note along those lines like WP:CITEVAR does? — Rhododendritestalk \\ 13:29, 3 May 2023 (UTC)
It would mean, much like when deciding the referencing style, the primary contributor(s) would determine whether an infobox should initially be included in the article. Then, if other editors disagree with this psuedo-consensus, a discussion on the talk page commences. It would add additional formalities to the way it works currently. Anarchyte (talk) 13:42, 3 May 2023 (UTC)
You’ve diagnosed the problem correctly, but the solution is status quo. That isn’t working. At least, it isn’t working WELL. Dronebogus (talk) 14:17, 3 May 2023 (UTC)
[Responding to both comments about the status quo] - It is not the status quo. The status quo doesn't regard infoboxes as a matter of stylistic preference, even if the guidance on infoboxes is so vague that anyone could infer that's what it boils down to. If we start treating it as such, we can start respecting ArbCom's directive that editors should not attempt to convert Wikipedia to their own preferred style, nor should they edit articles for the sole purpose of converting them to their preferred style, or removing examples of, or references to, styles which they dislike. Currently, these discussions are filled with mere preference, as well as editors who are only there to implement their personal preference (infoboxes=helpful; infoboxes=not helpful). Perhaps this is less the stuff of an RfC and more an appeal to arbcom to clarify whether that language should apply to infoboxes... — Rhododendritestalk \\ 14:27, 3 May 2023 (UTC)
I don’t want ArbCom getting involved again. Their last solution was an imperfect fix at best, and we don’t need more unilateral decisions from tiny editor groups in this area. Dronebogus (talk) 14:31, 3 May 2023 (UTC)
faux-Arbitrary break
Here is what I don’t get: most biographies have infoboxes. Numerous biographies have been RFC’d because they lack them. Most of these end up adding a box after a lot of ultimately pointless arguing. This will likely happen into the foreseeable future. So why are the anti-box users so utterly determined to oppose a pretty obvious emerging meta-consensus over something utterly trivial? Dronebogus (talk) 14:25, 3 May 2023 (UTC)
@Dronebogus You have said quite enough about this topic. I suggest taking a break. This RfC will be open for 30 days and there will be plenty of comments. Wall of text repeating the same arguments are not helpful for anyone. Nemov (talk) 14:35, 3 May 2023 (UTC)
I take some responsibility here—I engaged in a tiff by allowing myself to be baited by a petty remark that I couldn't understand closing summaries because I haven't been on Wikipedia long enough. I shouldn't have done that, and I hatted that discussion, but it may have set a tone. Dronebugs (update: sorry!) Dronebogus, it's ultimately up to you, but if you see comments that you really feel like you can substantively address—and, importantly, that you haven't already substantively addressed—, I would suggest adding to your rationale in the survey section. I understand it's easy to, in good faith, want to talk to every editor you might disagree with or have a response to, but the various walls of text that can result end up making you look like you're dominating the discussion.--Jerome Frank Disciple (talk) 14:48, 3 May 2023 (UTC)
Agreed... Probably time to give it a rest. Let the rest of the community have their say, and perhaps also don't bunch them into stereotype categories like "anti-box users". I have no disposition one way or another on the so-called infobox debates. ⛵ WaltClipper-(talk)16:34, 3 May 2023 (UTC)
I know the broad categories might seem unfair, but I really think there’s only three camps you can be in here— seeing biographical infobox inclusion as an objective maintenance issue that isn’t up for debate (“pro”), seeing it as something that the “article stewards” get to decide for any reason they agree upon (“anti”) and being neutral. Dronebogus (talk) 18:00, 3 May 2023 (UTC)
Or, you know, people who are still opposing i-boxes on principle, like that’s a plausible stance at this point. Dronebogus (talk) 15:52, 4 May 2023 (UTC)
User:David Eppstein, is this true? My guess is no (and Dronebogus if you are going to make a dubious claim about another editor you should let them know). I support infoboxes for vast swathes of bios (sport, military, politicians, most academics and many others) but not for everybody, and on the relatively rare occasions there is a debate I usually oppose the infobox, because unless there are very good reasons not to have one (see eg Mozart most recently), there isn't a discussion. Johnbod (talk) 02:40, 28 May 2023 (UTC)
I am not opposed to infoboxes period. I have deliberately not objected as many of the articles I created have been expanded with infoboxes. I regularly expand existing infoboxes (recent and typical example). I may have even created an infobox or two here or there myself. However, the cost-benefit of infoboxes (where cost = pulling reader attention from the lead text and benefit = informing readers better than just reading the lead text would) is often not positive and I will often revert the addition of an infobox in cases where I think it is not a net benefit. I am definitely opposed to any WP:CREEP of our standards in the direction of requiring or even recommending infoboxes as a general thing. —David Eppstein (talk) 05:27, 28 May 2023 (UTC)
Your vote called the majority of infoboxes trash and said they should never be recommended, which sounds pretty much like “infoboxes are always bad and should be discouraged”. That’s a far cry from your neutral take here. Dronebogus (talk) 11:38, 31 May 2023 (UTC)
Hello! The RFC has been updated based on comments by User:Thryduulf and User:Barnards.tar.gz. If you can, please update your survey entry to indicate (1) whether you support or oppose changing the guidelines at all and, if support, (2) which option or options you support (or "other").--Jerome Frank Disciple (talk) 14:58, 4 May 2023 (UTC)
It’s only a few days old and opposers will always oppose without qualification because as I said they view this as a “local consensus” thing that should have zero external guidance. It won’t become any more trainwrecky than it already is. Dronebogus (talk) 16:04, 4 May 2023 (UTC)
@WaltCip: I'm just curious at what point do you think this is a problem? 2 RfCs a month? 5? At what level does this become a problem? Over the last six months his is the most common type of RfC for biographies and they're not started by the same editor over and over. Thanks! - Nemov (talk) 16:11, 4 May 2023 (UTC)
I'm a bit perplexed by your question. I didn't say anything about the number of RfCs a month. I commented on adding options while the RfC is already underway with lots of responses already submitted. ⛵ WaltClipper-(talk)16:57, 4 May 2023 (UTC)
I don't see anything identified as a new RFC. I'm sure that if I spend more time than typical respondent would I could figure it out. This is getting too gigantic and confused to have real/sufficient feedback. North8000 (talk) 13:12, 5 May 2023 (UTC)
The additional options (2 and 3) are new. I agree the RFC might be too large now, but enough discussion about preferring other options was made that I figured it was worth asking Nythar--Jerome Frank Disciple14:15, 5 May 2023 (UTC)
My guess at the outcome of this is that it's going to die under it's own weight and complexity preventing any significant new input I think that for proponents of addition of a guideline that the best outcome that could expect here would be "no consensus to add". Might it be better to withdraw? Perhaps a proponent for adding a guideline could draw from all of the input received to craft a fresh new proposal that is also guided by the concerns expressed under "oppose" so that it could garner support from some of the "oppose" people. Sincerely, North8000 (talk) 16:07, 5 May 2023 (UTC)
The concerns expressed under oppose are basically "don't do anything at all." Can't craft a new proposal with no meaningful input. Nythar (💬-🍀) 16:31, 5 May 2023 (UTC)
I won't speculate on the outcome, but I haven't been surprised at the feedback so far. I don't see a reason to withdraw after 3 days and you're right, most of the oppose camp so far seems entrenched. Nemov (talk) 16:33, 5 May 2023 (UTC)
Yeah this is about what I expected, too. From my perspective, it would just be better to reduce these debates, given how dragged out and repetitive they are, even if that means some pages get infoboxes where that infobox isn't particularly helpful (although worth emphasizing again that none of the proposals are mandatory). From the perspective of the oppose voters, based on their votes in various RFCs, that's already happening. But I think, from their perspective, they want to maximize their chances at blocking an infobox, even at the cost of many repetitive losses.--Jerome Frank Disciple16:42, 5 May 2023 (UTC)
"most of the oppose camp so far seems entrenched": as do most of the support camp. The problem with the use of IBs and therefore IB discussions is that it's a binary question with very limited room for compromise: there either is one or there isn't. When compromise was tried previously - by having a collapsed box, for example - there has been enough of a campaign against them that I think there are only a couple still left; apparently compromise wasn't wanted. There have been suggestions from the oppose camp further up, but they have been ignored or rejected unfortunately. - SchroCat (talk) 17:06, 5 May 2023 (UTC)
I think that's a fair assessment! In fact, it's one of the reasons I thought guidance should be included—because the debates so often seem to be a referendum on infoboxes in general (though a few specific points might be made), it seems like the type of thing guidance should address, as it's quite repetitive! In light of the recent trend towards inclusion, I was hoping a non-mandatory policy might at least shorten some of these drag-out fights, but if the opponents of infoboxes aren't willing to slightly lower their chances of prevailing, then even explicitly non-mandatory guidance reflecting that trend is bound to be rejected. I'll also be really curious to see how the Colleen Ballinger discussion ends up once it's closed—a consensus exclude seems unlikely there, but I'm not sure if there'll ultimately be a consensus include or a no consensus.--Jerome Frank Disciple17:47, 5 May 2023 (UTC)
It’s a non-mandatory policy but it’s also, quite intentionally, trying to throw extra weight on the pro-standardization side. This obviously sounds unfair but, as it is, the anti-standardization side actually has a built-in edge with the “infoboxes are unsuited to liberal arts” guideline that is brought up at every single discussion. Dronebogus (talk) 19:19, 5 May 2023 (UTC)
JFD, Unfortunately there are people who argue “all IBs are good, so include one here” (and, lesser seen, the opposite), although ArbCom says it should be focused in the specific article – and despite me focusing on the individual article, there are too many closers of the discussions who only focus on the general, rather than the specific.DB, there is no ‘“infoboxes are unsuited to liberal arts” guideline’ included in the guideline (either existing or proposed), which could be why this is being opposed. IBs for the liberal arts is not seen by some as beneficial, but the infobox wars/pressure/grief over years has lead to most not liking the situation, but feeling bullied off/exhausted by the ongoing push to have them. That doesn’t mean they should get included, but just shows that the pro-IB pushers have been trying to achieve the aim of exhausting any opposition for many years. - SchroCat (talk) 23:44, 5 May 2023 (UTC)
I think, for the closers, the real problem is that "focus on the general, not the specific" provides no guidance on what the threshold is. For example: If the infobox makes just one likely-searched-for datapoint more visible, is that enough? You can't answer that question with "well focus on the specific"—it is a specific! And perhaps you're right that there aren't as many "all IBs are bad" users, but, just as the same users show up time and time again in the pro voting sections; the same users show up time and time again in the anti sections ... and frequently you'll see repeat-pro voters say "of course if the article was just a silly stub then obviously an infobox wouldn't make sense!" ... and frequently you'll see repeat-anti voters say "obviously I support infoboxes on certain articles!" But, at least from what I've seen, these voters never seem to find an RFC that causes them to change their normal position.--Jerome Frank Disciple23:53, 5 May 2023 (UTC)
Pro-ibox users don’t really have a choice here but exhaustion tactics when the opposition is stonewalling. Dronebogus (talk) 00:22, 6 May 2023 (UTC)
D: It’s not stonewalling to hold a contrary opinion on a binary question. There is now an IB on Olivier: I still don’t think it a good idea for all the reasons I said in the discussion; it’s not stonewalling that I still don’t agree with it.JFD, Please note that in the Olivier discussion my comments there were specifically about that article, not IBs in general. As to “these voters never seem to find an RFC that causes them to change their normal position” that’s something a straw man. Biographies that should have an IB tend to already have them already and are not contentious. Again, the area of contention isn’t the whole field of biographies, but those in the liberal arts, where for some there is no flexibility of approach. - SchroCat (talk) 07:43, 6 May 2023 (UTC)
I'd be comfortable withdrawing at this time. There's been enough comments at that stage to see this is deadlocked. There doesn't appear to be enough editors who believe this is a real problem. With that in mind, I'll continue to promote future RfCs on infoboxes here. Thanks for all the feedback and the editors who worked hard on attempting to solve a long term issue. Nemov (talk) 20:40, 7 May 2023 (UTC)
@Jerome Frank Disciple: Sorry I didn't respond sooner, my notifications might have gotten clogged up. Yes, unfortunately I agree this isn't going to succeed. Well, at least we know what the community thinks. Nythar (💬-🍀) 03:36, 10 May 2023 (UTC)
This issue will never be resolved. We should just accept that. Looking forward to more long, pointless RfCs about infoboxes for the rest of the foreseeable future. Dronebogus (talk) 21:11, 7 May 2023 (UTC)
There's clearly no consensus for this proposal. Does this need an official close for posterity sake or do we just let the RfC expire and then archive? Thanks for everyone's input on this proposal and for the editors who generously volunteered their time drafting it. Nemov (talk) 15:21, 31 May 2023 (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.
I believe I was the only one to respond last time (ReplyTool bugged out and wouldn't let me expand the subheading), so I hope you see more participation this time round.To reiterate, I support the following tasks for your bot:
Updating statistical information in infoboxes and tables
Adding tables for statistical data where none exist
Conditionally, provided it can be demonstrated your bot won't be leaving empty ==External links== sections, removing external links.
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.
Strong consensus not to implement; blocks are seen as a necessary evil, not necessarily an action which should be clebrated. Mattdaviesfsic (talk) 09:19, 18 May 2023 (UTC)
Support (as proposer) Thanking an administrator for a block is currently not possible, but would be easily enabled. There has been some disagreement as to whether thanking for a block should be possible on Phabricator (T268701). I couldn't find previous discussion surrounding this on enwiki and the discussion surrounding this has been only with a few people. Enabling on the English Wikipedia could give a indication as to it's benefits and negatives, which could be used to expand it's use to other wikis and to be enabled by default.I see many benefits to enabling this especially surrounding admin retention as making non-controversial and beneficial blocks doesn't usually merit a thanks message. Having the occasional thanks for carrying out actions gives affirmation that they are appreciated. Dreamy Jazztalk to me | my contributions19:00, 6 May 2023 (UTC)
For further thought: It is currently possible to thank an administrator for deleting a page and also protecting a page. If discussion here is concludes against enabling this, I wonder whether these two should be re-visited? Dreamy Jazztalk to me | my contributions19:24, 6 May 2023 (UTC)
The result of this discussion either way will give better direction on the associated Phabricator task (which is to allow thanking blocks by default). If there is support here it could suggest support for enabling by default and if there is opposition it could be the basis for declining the task. Dreamy Jazztalk to me | my contributions19:28, 6 May 2023 (UTC)
Deletions and protections aren't against a specific person, so there aren't the same issues as with blocking. Galobtter (talk) 02:23, 7 May 2023 (UTC)
Very weak oppose. Per WP:FUCK, administrators should be doing things because they are the things that need to be done, not in pursuit of recognition. I don't think that fluffing admins' egos is a very good approach to retention - if prospective admins are led to believe that their experience with the mop is going to be all champagne and roses, they're going to have a rough time. I also think that thanking an administrator for a block is awfully close to WP:GRAVEDANCING. Ivanvector (Talk/Edits) 19:21, 6 May 2023 (UTC)
I think providing feedback can be more than bolstering ego—it can provide connection to the community so admins don't feel like they are operating in a vacuum. There are of course disadvantages. Feedback can be non-representative, and an asymmetric thanks mechanism is particularly prone to that. I wouldn't want to change community culture so that thank-you messages are always taboo, for instance, but I agree editors should be constructive and aware of the effect such messages have on others, including the blocked editor and those who advocated on their behalf. If there was already ample feedback during a discussion, for example, more feedback may not be necessary. isaacl (talk) 21:43, 6 May 2023 (UTC)
I'm not convinced there is a strong need for this. When people want to thank me for a block with the "thanks" button, they usually thank me for some edit accompanying the block like the talk page notice or a note on ANI that says "I have blocked the user". —Kusma (talk) 19:34, 6 May 2023 (UTC)
Weak support. Sometimes a prompt block (usually of IP) makes everyone's lives easier, but I just thank the admin for a related action per Kusma. Certes (talk) 20:27, 6 May 2023 (UTC)
Weak support. There are times when thanking an admin for a related action isn't possible. For example, when dealing with an LTA where a block message wasn't left for WP:DENY reasons and where the responding admin is not taking action based on an ANI post. These don't happen very frequently so I understand if the community thinks the cons of the proposal outweigh the benefita of enabling such a feature for these limited scenarios. However, there have been times where I've wanted to send thanks but couldn't (in those cases I usually leave a message on the admin's talk page when I really think a thank you is in order, but this takes significantly longer). Thanks, Aoi (青い) (talk) 21:09, 6 May 2023 (UTC)
The existing pros and cons for thanking administrators for administrative actions already apply today to the existing methods (talk page message, thanking for related edits). Personally I don't feel adding one more method will change the balance of advantages versus disadvantages. Although I don't feel strongly about it, I think the chance that I'm mistaken and the advantages are amplified is not worth the risk I'm mistaken and the disadvantages are amplified. Thus I don't favour adding the proposed functionality. isaacl (talk) 21:28, 6 May 2023 (UTC)
Weak oppose. There's at least one disadvantage, even if limited: it opens up an additional avenue for trolling, gravedancing, and the likes surrounding blocks. That'd be one thing if the benefits outweigh those disadvantages, but considering the relative scarcity of blocks where the work-around mentioned by Kusma doesn't suffice, the benefits seem to me at best equally limited as the disadvantage. (Especially when considering that many of those blocks without related edits one could click "thank" on are blocks of LTAs and DENIED trolls, which are pretty much the very people who would abuse such avenues for further trolling.) AddWittyNameHere23:06, 6 May 2023 (UTC)
Oppose - However much it might be the opposite in practice, blocks aren't meant to be celebrated. They're intended to stop and prevent ongoing disruption. Adding 'thanks' to it will inevitably politicize the act as people "thank" controversial blocks against their enemies. This isn't a habit we should encourage. --⛵ WaltClipper-(talk)23:22, 6 May 2023 (UTC)
Weak support This could potentially reduce gravedancing, not increase it. A "thanks" is semi-private. No one but the thankee known what you sent the "thanks" for. Maybe it was something else they did around the time of the block, or maybe some edit from a week ago that you just noticed. But without the option to thank, the alternative is a public message, which could much more easily veer into GRAVEDANCING territory. My support is only "weak" because, as Kusma says, there's usually some related action, so it's not a big deal either way. Suffusion of Yellow (talk) 23:57, 6 May 2023 (UTC)
Weak Oppose. I get thanks from time to time for various admin-ish things I do. It sometimes makes me feel uncomfortable because I'm not sure if it means "Thank you for your service" or "Thank you for supporting my position". I suspect being thanked for a block would be more likely to be the latter. -- RoySmith(talk)00:11, 7 May 2023 (UTC)
Oppose Per RoySmith, we should not encourage cheering about a block. Per Kusma, if people really want, they can thank for an associated comment although that should be infrequent. Johnuniq (talk) 00:30, 7 May 2023 (UTC)
Serious question. How often do y'all go through Special:log/thanks and try to work out from the timestamps what people are being thanked for? I've never even seen anyone publicly admit that they do this; e.g. "as you can see, in the first day after [admin I like] deleted [page I don't like], they got 20 thanks, but on most days they get between 3 and 5 (see attached statistical analysis in figures 1 through 6), so obviously the AFD closure was correct". All this talk of "drama" and "gravedancing" and "mob mentality" implies this is commonplace. Suffusion of Yellow (talk) 20:18, 7 May 2023 (UTC)
This exactly. A block might be a successful utilization of policy in that it prevents disruption, but in some ways, it is also a failure since it indicates an incompatibility between the blocked editor and Wikipedia that no one was able to reconcile. It's a bit like sending in the SWAT team to take out an unstable person after a breakdown in negotiations between police and suspect; it might get the job done, but it's also shameful and disagreeable. And cheering on the SWAT team after they finish the job bears the unpleasant undercurrents of mob mentality. ⛵ WaltClipper-(talk)15:09, 7 May 2023 (UTC)
Comment Thanking an admin for making a block is not necessarily celebrating, gloating or grave-dancing, but could simply be expressing thanks for performing a necessary task that may subject that admin to attacks. - Donald Albury12:48, 7 May 2023 (UTC)
Yes, it might not necessarily be one, but that's the problem with a "thanks". It does not distinguish between thanking for a necessary task to reduce ongoing disruption vs thanking for eliminating a controversial editor from Wikipedia. It's an unnecessary addition that adds no value, and it can't be retracted or removed once issued, as opposed to a Barnstar that an admin could simply remove from their Talk Page if they feel that it's inappropriate for the situation. ⛵ WaltClipper-(talk)15:03, 7 May 2023 (UTC)
Support It's simply a way to communicate easily with the admin so they know you saw it which is sometimes useful after being engaged in dealing with a bad actor. It also adds an additional level of civility, which Wikipedia needs. For example, what if the thanker and thankee were engaged in a heated debate elsewhere on a diff topic, this signals to the thankee the thanker can see past their differences overall and no hard feelings, it defuses things. It's not just about ego, it's grease for the sometimes sticky parts of Wikipedia. -- GreenC15:10, 7 May 2023 (UTC)
Any case where thanking a block would be gravedancing or in bad faith or whatever will have an accompanying user talk edit for the block notice. The only blocks that this generally doesn't happen for are for new accounts so blatantly disruptive that someone else wanting to thank the blocker is likely, appropriate, and uncontroversial. Preventing thanking directly for the block doesn't stop bad thanks; it just makes good ones more inconvenient and occasionally impossible. —Cryptic15:29, 7 May 2023 (UTC)
Support. I hear some concerns raised above, don't really buy them, but this would definitely suit the types of blocks that I usually do - LTAs, VOAs, abusive socks, and other very-undesirables. Most of the time I don't leave a talk page message. Very often I don't even make any related edits. The thanks that I've received when I do apply talk page notices, or protection, or reverts, says to me that some editors would appreciate having a quick way to show a little appreciation for a good job. And I appreciate being appreciated for doing a thankless task. Having a thank button will also help prevent talk page spam unnecessary messages on my talk page. You're welcome. -- zzuuzz(talk)17:54, 7 May 2023 (UTC)
Serious question, and I'm not being rhetorical -- am I CLUEless to think that people using the "thank" button for blocks could or would be doing so in bad faith? If I am, I'd like to know so that I can self-correct. You make good points; it is a thankless task controlling vandalism, I agree, and perhaps I've been around WP:ANI too much to assume those extraordinarily explosive blocks like those against Athaenara are the norm. ⛵ WaltClipper-(talk)18:06, 7 May 2023 (UTC)
@WaltCip - If I reported you for something on here and got you blocked tomorrow, how would you feel? I doubt you would feel happy. How would you then further feel if I thanked the admin who did it publicly and told them what a great job they did and how I was right in getting you blocked? I don't think that would make you feel very good either. But, you are blocked. You can't complain or do anything about it. That's why it's a problem.KatoKungLee (talk) 19:43, 7 May 2023 (UTC)
Well as I mentioned I don't really buy it. Are admins going to suddenly think hey I should make even more controversial blocks? I don't think so. Is there any added value on the grave dancing scale? Hmm, no? Would it "create avoidable drama"? Huh? In these ANI situations, admins are going to get most of their feedback at ANI. On the plus side I suppose having a thanks button would help identify shy people with a vested interest. I already see that happen, and from an admin point of view I've never known it to be a bad thing. But Special:Log/block is where most of the real action happens, not ANI. The vast majority of blocks are just some school, or someone writing poop, trashing an article that may be very dear to some regular (or even casual but sincere) editor who has put a lot of work into it. These editors can be very appreciative when we put a stop to it, and that's okay. -- zzuuzz(talk)19:12, 7 May 2023 (UTC)
Oppose I indirectly thank admins for blocking by thanking them for adding block notices. This proposal is both unnecessary busywork and just kind of silly. Dronebogus (talk) 19:10, 7 May 2023 (UTC)
Support Would probably reduce drama/gravedancing per Suffusion of Yellow; I also agree with what Zzuuzz wrote. DanCherek (talk) 19:48, 7 May 2023 (UTC)
Weak support in concept but do not think the result of this should be see as greatly increasing the phab requests priority higher than than showing the community supports the idea. I think it's fairly low priority because I have thanked on he other related edits, as mentioned above, when an admin does a block I think is thank-worthy. Most of the downsides mentioned above, I think, are unlikely given the only "public" aspect of it is the fact that the thanks given and thanks received counts will both go up by one (as far as I know?). Some of the difference may just be editor's experience in when they see blocks: for me, it's primarily admins blocking vandalism only IP/accounts after I have already warned them and/or reported them to a notice board. In which case, me being able to give a direct thank to the blocking admin makes sense to me. An editor giving the block a thank after, say, a long-drawn out AN/I thread is potentially a bit more problematic but I'm not sure the negative outweighs the potential value. (Similar to what others have said above: Suffusion of Yellow, Zzuuzz, and GreenC.) Skynxnex (talk) 20:48, 7 May 2023 (UTC)
Of course if sufficient admins oppose this, as is starting below, I'll probably withdrawn my (weak) support since "forcing" this doesn't make sense either. But some of the issues feel like general issues with thanks. Skynxnex (talk) 13:55, 8 May 2023 (UTC)
Oppose. I always assumed this function was disabled to prevent gravedancing and realistically, everyone just thanks you for placing the block notice anyway. I guess there's the case mentioned above where a LTA/troll is blocked without a notice, but is being unable to receive thanks for these actions really causing a crisis of morale among the admin team? Personally, I find the thanks spam after blocking a few accounts at AIV pretty annoying. There are people who will give you an individual "thanks" for a) placing a block notice on a sock's talk page; b) tagging the sock; c) closing the SPI case; d) reverting the sock; etc. Maybe users should be given a limited number of thanks per day to make them a bit more meaningful. Spicy (talk) 21:01, 7 May 2023 (UTC)
Strongly oppose limiting the “thank” function we don’t need MORE unnecessary rules about trivial things that have literally nothing to do with the encyclopedia. Dronebogus (talk) 21:13, 7 May 2023 (UTC)
It had originally not been included because of the following comment at the task that allowed thanking for log entries (T60485#4047567):
Our current criteria for having a log in the list is that thanking for that doesn't come across as harmful/doesn't encourage negative behavior. This is why "block" related logs are not in the whitelist. Pretty much everything else is allowed.Dreamy Jazztalk to me | my contributions14:10, 8 May 2023 (UTC)
Oppose per Spicy; thanking for blocks wouldn't seem to add anything important besides gravedancing. -sche (talk) 21:16, 7 May 2023 (UTC)
Oppose. I can't think of an administrator who would view this as positive feedback. Personally, I'd be wondering if I had to now look at the contributions of the person who thanked me to see if this was a sign of the edit-warrior mindset. Please don't thank me for any of that stuff. Don't thank me for doing an SPI. Don't thank me for any of that stuff. If so moved, feel free to thank me for edits, or for commentary - but not for logged actions. Risker (talk) 21:58, 7 May 2023 (UTC)
There are at least two supports from administrators right in this section; this is a good example of why "I can't think of..." arguments are so easily disregarded. Orange Suede Sofa (talk) 03:34, 8 May 2023 (UTC)
What they'd value is for some appreciation for the tough work that admins do, especially those who deal with the scummy stuff. You want to thank someone, use their talk page and write them a personalized message instead of performing a little click. It will mean so much more. Risker (talk) 04:41, 8 May 2023 (UTC)
Weak Oppose Per above reasons, but also I feel being an admin is a thankless job. Beyond what any editor does to get thanked, giving thanks for blocking or banning someone is much like clapping when someone is kicked out of an arena for being a pest. It's distasteful to the person being blocked (even if the blockee doesn't know). Conyo14 (talk) 03:49, 8 May 2023 (UTC)
Oppose, very un-classy. Where you do feel the need to thank a sysop, they have these things called talk pages.—S MarshallT/C07:49, 8 May 2023 (UTC)
Oppose as gravedancing. And cowardly gravedancing at that. If you wouldn't feel comfortable publicly thanking someone on their talk page for something, you shouldn't be given the option to hide behind the veil of the thanks button. --User:Khajidha (talk) (contributions) 14:44, 8 May 2023 (UTC)
Oppose, unnecessary. Almost all the time a block leads to a block notice on the user talk page; thank the blocking admin for that. --jpgordon𝄢𝄆𝄐𝄇15:12, 8 May 2023 (UTC)
Oppose I don't think it is very helpful or too necessary for the encyclopedia. Many editors who have been blocked may have made valuable contributions in the past, and perhaps their recent destructive edits (or any other reasons) led to their blocking. Thanking the blocking of that user may not show appreciation for the editor's other good works. Even if their contributions were few in number, they still mattered. Additionally, blocking a user is not an achievement, but rather a failure, that we lose another editor. Prarambh20 (talk) 15:19, 8 May 2023 (UTC)
Oppose; I do like the idea of being able to thank for a variety of log actions, but in this instance, it seems like thanking for blocks specifically would be an act whose vibe ranged somewhere between awkward and moustache-twirling. Not that I am in general support of writing software to prevent people from doing something that could potentially be rude, but mostly what I foresee is people (i.e. myself) doing this accidentally and adding a giant permanent entry to Special:Log/TimesThisPersonWasAGiganticAsshole/JPxG. Or, perhaps, Special:Log/HeyLTAsGoMessWithThisGuy/JPxG. jp×g16:11, 8 May 2023 (UTC)
Weak oppose In addition to what others have said, you can already thank an admin for the block via the edit they should be making to the user's talk page notifying them of the block. ~ ONUnicorn(Talk|Contribs)problem solving16:32, 8 May 2023 (UTC)
Oppose per Ivanvector. If an admin needs moral support from the commonfolk, there are other ways to provide it. ―Mandruss☎22:08, 8 May 2023 (UTC)
Oppose By enforcing the block the admin has done their job if any thanks need to be conveyed it could be sent in a mail to that admin. The person has been blocked that should be the end of the case. Move on. It is time for the banned editor to review their own actions and reflect.Mnair69 (talk) 00:49, 10 May 2023 (UTC)
Comment can we WP:SNOW close this? Oppose consensus is pretty overwhelming after just 3 days, I don’t know why anyone would bother keeping this open. Dronebogus (talk) 00:49, 11 May 2023 (UTC)
No. I mean, nobody has to read it. Nobody has to comment. re "don’t know why anyone would bother keeping this open", I do. People can waste their time (in your opinion) on any harmless thing they want to. Even tho it's not going to win, maybe people still want to make unsaid points. I do, and will. — Preceding unsigned comment added by Herostratus (talk • contribs) 01:18, 11 May 2023 (UTC)
Enh, I mean, OK, the great majority of blocks are justified... I suppose most by far are blocks of people who dropped in to vandalize or troll. There's no real need to thank for those, usually, they're so simple and common. Many, I'm sure, are hands-down justified, even tho it's of a longer-term editor. But some are debatable, some even wrong -- people are human. Thanking for those... it's kind of nyah nyah nyah. Go to the talk page if you really want to.And I mean, if you're blocking a long-term editor, something has gone badly wrong. If the block is justified and the person is unteachable, fine. But is it possible the the person blocking has missed a chance to educate the editor. Happens at least sometimes. It's not a crime -- people are human, people are busy. But the block is more an occasion for sad reflection rather than joy. My 2c. Herostratus (talk) 01:18, 11 May 2023 (UTC)
Weak oppose per thank the block notice. That's what I did before I was an admin for vandal blocks and such, and that's what I've seen done now that I'm an admin. It gets the job done. ScottishFinnishRadish (talk) 16:40, 11 May 2023 (UTC)
Weak oppose This isn't that big of a deal, but speaking as someone who has been blocked under circumstances that I considered ...well a lot of adjectives would work here, it would feel a lot like gloating, just one more thing to pile into Wikipedia's record. If a user really feels the need to thank an administrator publicly, then let them do so on a talk page, where there can be some chance of context and nuance. Darkfrog24 (talk) 01:08, 13 May 2023 (UTC)
Oppose. Unnecessary and feels like WP:GRAVEDANCING. I know that's just an essay, but I agree that that kind of behavior feels like bad form. When a block isn't routine, i.e., when it happens to a long-term editor, or to someone a part of a long content dispute, or when there are strong feelings on both sides, the "thank"s would seem like a way to politicize and inflame the issue rather than lowering the temperature. If the goal of thanking is Wikilove, it feels like this is not the way to go.--MattMauler (talk) 03:25, 14 May 2023 (UTC)
Oppose but only for the technical reason that such a change would require the devs to adjust the code, time that could be better spent fixing bugs elsewhere. As for the general principle, I'm neutral. It can already be done, after a fashion - a block is often accompanied by a post of a block notice to the user talk page of the blocked editor, and that may be thanked without any software change, nor indeed any consensus here. If there was no block notice, and you really want to thank the admin, then you are already permitted to use the admin's talk page to leave a message, as others have already pointed out. --Redrose64 🌹 (talk) 10:05, 14 May 2023 (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.
Bot to add short descriptions to articles in a category
Recently I added a plethora of short descriptions to articles in the Percussion category and subcategories. It took a long time and it was an arduous process. Today I created UrbanBot and I wrote some code on Pywikibot to fix this problem. The idea is that the bot operator (me) would specify a category and a short description and the bot would write short descriptions to all articles in the category that were missing one. Therefore, the bot is semi-automated. The source code is located on GitHub here. I wanted to put this here before I submit a request at Wikipedia:Bots/Requests for approval. Any tips or info on this idea would be greatly appreciated. Thanks, UrbanVersis32KB ⚡ (talk / contribs)19:41, 12 June 2023 (UTC)
Maybe, but the way the bot works is that it adds short descriptions to articles based on the article's categories on the English Wikipedia, so it would probably be better suited for Wikipedia. Unless maybe there's something I'm missing? I'm new to Wikipedia bots, but as far as I can tell, it isn't possible to access the English article's categories on Wikidata. UrbanVersis32KB ⚡ (talk / contribs)17:49, 13 June 2023 (UTC)
Oh okay, my bad. I was thinking that the bot would be based on Wikipedia, but it makes more sense that the bot would be based Wikidata as it only grabs the category information from the English Wikipedia but actually edits Wikidata. Thanks for the info! UrbanVersis32KB ⚡ (talk / contribs)20:21, 13 June 2023 (UTC)
Another option for this sort of thing is to create a text file
Jane Ann Gere|British unicyclist
Juan Wheeler|Spanish unicyclist
as an article list for JWB, replacing ^ by {{short description|$x}}. (JWB replaces $x by the text after the pipe.) Certes (talk) 12:55, 13 June 2023 (UTC)
You are invited to join the discussion at Wikipedia talk:Backlog. Snowmanonahoe (talk) 17:57, 11 May 2023 (UTC)
.svg){kind=small}
