[[Wikipedia:Village_pump_(policy)#Should_editing_on_Wikipedia_be_limited_to_accounts_only?]] - Notice about a discussion asking whether editing on Wikipedia should be limited to accounts only? - <b>[[User:Jc37|jc37]]</b> 15:44, 18 May 2023 (UTC)
[[Wikipedia:Village_pump_(policy)#Should_editing_on_Wikipedia_be_limited_to_accounts_only?]] - Notice about a discussion asking whether editing on Wikipedia should be limited to accounts only? - <b>[[User:Jc37|jc37]]</b> 15:44, 18 May 2023 (UTC)
== RFC: Close LTA as historical for declining involvement, and to deny recognition to vandals ==
One thing leads to another. I saw a bunch of LTA pages that should have been archived and requested that to be done [https://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3ALong-term_abuse&diff=1155307186&oldid=1149736158#Semi-protected_edit_request_on_17_May_2023]. Looking at the discussion, I saw that one admin recommended that the page be marked historical due to a relative lack of recent edits [https://en.wikipedia.org/w/index.php?title=Wikipedia:Help_desk&oldid=1155828003#WP:ER_on_WP:LTA]. I think Wikipedia has gotten better at preventing long-term abuse, so the number of LTAs has declined in the past few years. Many vandals also celebrate the recognition they get from these kinds of pages. What do you think?
[[Special:Contributions/2620:8D:8000:10E6:6CB1:8BD0:12C:3695|2620:8D:8000:10E6:6CB1:8BD0:12C:3695]] ([[User talk:2620:8D:8000:10E6:6CB1:8BD0:12C:3695|talk]]) 23:07, 19 May 2023 (UTC)
RfC on draftifying a subset of mass-created Olympian microstubs
The motion carries, WP:Consensus to move the listed articles to Draft space. Note that the motion allows, and even encourages, editors to edit and improve the articles so they can be returned to main space. Not mass, or batch, or automated moves back to main space. As long as the editor sincerely believes they have improved a given specific article enough to pass Wikipedia:Notability, they may move it back to main space; at worst, that way it will face an individualWP:AfD, not 900+ all at once! Until then, or even instead of that, editors may make similarly individual and considered redirects in main space to replace some articles. Redirects will generally need to pass a lower bar, the main concerns are that the redirect will be a reasonably likely search term, and there is an obvious target article. Again, at worst, that way they will face specific WP:RfDs.--GRuban (talk) 01:40, 11 May 2023 (UTC)[reply]
I'd like to thank all those who participated in this discussion, over 100 people, all of whom remained civil, and many of whom brought up very insightful points. I'd also like to thank User:BilledMammal for making the proposal, User:Bradv for closing it the first time, and User:FOARP for convincing him to reopen. I'm trying to fill some pretty big shoes here; I'm an experienced editor, and have closed maybe 100 RfCs, but Bradv is not only an experienced editor, but also an experienced administrator, so it takes quite a bit of hubris to think I can do a better job, and I won't be surprised if there is another thread on WP:AN after this asking that my close be also reopened. But I am still trying hard so that there is not.
So, the decision. I counted a noticeable majority of voices in support of this proposal than opposing it here; something like 68 to 45, and even more if we consider the ones who agreed that the articles should be removed from main space, but wanted redirects instead of draftification (which, as above, will generally be individually allowed). I might be off by one or two in my count, but I am not off by 10. Now as people say, correctly, RfC is a matter of stating arguments, citing policies and guidelines, not a matter of counting votes. The closer does not just count votes. But when I close and judge arguments, I try to remember that the editors stating them are as much editors as I am, many even more experienced than I am, and if many experienced Wikipedians are all saying something, it's definitely worth considering that they just might be right.
So, those arguments. The "support" side mainly said that these articles are stubs that are essentially database entries, and cited only to one or two specific databases, violating WP:GNG, WP:SPORTCRIT, and WP:NOTDB. I looked at a randomly selected subset and they were all of the exact form: "(Name) (born–died) was a (nationality) (sportsman). He competed in the (sport) event at the (year) (season) Olympics." Exactly those two sentences, no more text, and cited as stated. The support side has a point. There are a number of people on the "oppose" side that said that the articles aren't hurting anything, there is WP:NODEADLINE, so they might be expanded, Wikipedia is WP:NOTPAPER, so we have the space, and that at the time that Lugnuts wrote the articles, WP:NSPORT said that just participation in an Olympics, even without winning a medal, was an indicator of notability. Unfortunately, I have to discount those arguments; we have a long and time-honored precedent of deleting articles that are not actually hurting anything, but just because they don't meet Wikipedia:What Wikipedia is not and Wikipedia:Notability; and those policies don't have a "grandfather clause" that say that articles that were made before the policies were written are forever acceptable. We can work on not-harmful articles that don't quite meet standards in our user spaces, or in draft space, but until they do, we don't allow them in main or article space.
Many others of the "oppose" side, maybe even most of them, said two related things: that mass moving articles to draft space is basically deletion, as very few people will ever find them there; and that deletion is not something that can be decided at the Village Pump, that's what we have WP:AfD for. That is basically the argument that Bradv found in his close that there was no counter-argument against; he cited WP:DRAFTIFY and this previous Village pump discussion that articles shouldn't be moved to draft space as a back door to deleting them via AfD. Now Bradv had a good point as well; he's a very experienced and respected editor. Many on the "support" side, at least implicitly agreed that moving these articles to Draft space would be close to deletion; some said they were only supporting draftification because they really wanted the articles deleted, and while others said they supported draftification to avoid deletion, and that the text would still be there for people who wanted to improve them, they admitted there would be a real possibility that no one ever would. However, the "support" side said that that this many articles would be too much for AfD, which only handles one or at most a few articles in a single discussion, not hundreds as here, and especially not the thousands of Lugnuts's similar stubs, which many on both the "support" and "oppose" sides agreed would likely soon be brought up a similar discussion. In questioning Bradv's close, FOARP said that this Village pump discussion was essentially similar to WP:AFD, so should be allowed to draftify articles if the decision went that way, and this was eventually successful enough to get Bradv to withdraw his close. This similarity to AfD was actually brought up in this discussion earlier, by PerfectSoundWhatever: Wikipedia isn't a burocracy, so I don't think its a problem to do this process here instead of AfD if enough editors come to a disagreement. Different room, same discussion. Now I wouldn't always agree with that in many cases, AfD is where it is for a reason, it's a high visibility forum, many editors specifically go there to decide the fate of articles, if this were a lower visibility discussion I would not consider it a sufficient substitute for AfD. But in this case, there were over 100 editors actively participating, including many very experienced ones. Very few AfDs get that level of participation. I think per WP:IAR, and WP:NOTBURO, we can consider this a sufficient venue, as PerfectSound wrote.
Finally, the redirect option. A noticeable number of people were opposed to draftification, for all the above reasons, but preferred replacing the stub articles with redirects to existing articles on the Olympics of that year or the competitors' countries, because that way at least the redirects could be found by readers; even more would accept redirects equally with draft space, or as a compromise. However, several were explicitly opposed to redirects, because it wouldn't be always clear which article to redirect to, and in any case, over half the participants didn't mention redirects one way or the other. So I can't see a consensus for redirect, even as a compromise. However, I can point out the initial term of the proposal, "5: Editors may return drafts to mainspace for the sole purpose of redirecting/merging them to an appropriate article, if they believe that doing so is in the best interest of the encyclopedia". So if someone believes they know a good redirect target, they can feel free to make a redirect; if others disagree, they can discuss or at worst nominate it for WP:RfD. As long as it is one thoughtful redirect at a time, and not a mindless batch or automated process, I believe the community will accept it. User:Valereee even suggested doing draftification and redirect replacement simultaneously.
Personal note: Personally I'm not much of an editor of articles about Olympic competitors (arguably if I were I wouldn't be a suitable closer here!). However I've run into Lugnuts here and there - with all his edits it's hard to imagine an experienced editor who hasn't. I had always looked at his many short articles, not just on sportspeople, but on the many, many topics that he wrote about, and thought: these are not my cup of tea, but I'm glad we have him. I'm sad that he's gone. I'm even more sad that he went like this, with a statement that he intentionally added copyright violations and incorrect information. That several people in this conversation think he was lying about this, and just saying it "to piss off all of those who did not like him" doesn't really make it much better. What we're doing here by building the Wikipedia is a 90%+, maybe even 99%+, a very good thing. If I'm ever this angry at the <1-10% of what this project does that I don't agree with, I hope I can leave without deliberately acting to damage the project as a whole. A sad thing all around.
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.
Should the following biographical microstubs, which were mass-created by Lugnuts and cover non-medalling Olympians who competed between 1896 and 1912, be moved out of article space? 08:15, 2 March 2023 (UTC)
List of microstubs
Article
Initial size
Current size
Growth
Date created
Page views in 2022
# of extant articles created by Lugnuts on same day
Selection criteria: Generated using a Quarry query, these 960 articles meet the following criteria and are a subset of the articles created by Lugnuts:
Athletes who competed in the 1896, 1900, 1904, 1908, or 1912 Olympics
No significant contributions from editors other than Lugnuts[b]
If this proposal is successful: All articles on the list will be draftified, subject to the provisions below:
Draftified articles will be autodeleted after 5 years (instead of the usual 6 months)
Any editor may userfy any draft (which will prevent autodeletion)
Any WikiProject may move a draft to their WikiProject space (which will also prevent autodeletion)
Any draft (whether in draftspace, userspace, or WikiProject space) can be returned to mainspace when it contains sources that plausibly meet WP:GNG[c]
Editors may return drafts to mainspace for the sole purpose of redirecting/merging them to an appropriate article, if they believe that doing so is in the best interest of the encyclopedia[d]
Background (Olympian draftification)
In the 2022 Deletion ArbCom case, ArbCom found (Finding #6) that User:Lugnuts had created over 93,000 articles, "the most articles of any editor ... Most of these were stubs, and relatively few have been expanded to longer articles", which led to sanctions from the community and to Lugnuts being indefinitely sitebanned by Arbcom.
Arbcom also mandated an RfC on mass deletion. A mass creation RfC took place but the mass deletion RfC did not, and the RFC mandate was rescinded, leaving the question of how to handle mass-created microstubs such as these unresolved. This proposal suggests a method for resolving this question, with a group of articles that can be used to test the proposed resolution.
Survey (Olympian draftification)
Support. The alternative to this proposal is bringing hundreds or thousands of articles through AfD each month[e] and that alternative is not practical. These are articles that took minutes, sometimes seconds, to create; each AfD consumes hours of community time and it would be a waste to spend more collective time assessing each of them individually than was spent on their creation. Further, editors who support keeping these articles object on the grounds that the workload is too high; that it is impossible to search for sources with the diligence required in the time available and as a consequence articles on notable topics are deleted.This proposal resolves both of those issues; editors will have time to search for sources, and considerable amounts of our most limited resource, editor time, will be saved.We also cannot leave the articles as are; we have a responsibility to curate the encyclopedia, to remove articles that do not belong on it due to failing to meet our notability criteria or due to violating our policies on what Wikipedia is not. Failing to do so is also harmful to the project; it reinforces the perception among the public that Wikipedia is mostly empty around the edges and that anything is notable, and it reinforces the perception among editors that creating large numbers of microstubs that do not inform the reader is as good or better than creating smaller numbers of informative articles.These are articles that all violate the fifth basic sports notability criteria, on topics that usually lack notability, that no one edits, that almost no one looks at, and that are so bereft of information that they are of no benefit to the reader. Removing the group will improve the quality of the encyclopedia, and by doing it in this manner we provide the best hope of the articles on notable topics being identified, improved, and returned to mainspace. BilledMammal (talk) 08:15, 2 March 2023 (UTC)[reply]
Disagreed on pretty much all points. These articles improve the scope and quality of the encyclopedia, they are often useful for every day users, and have little to no impact on how others view Wikipedia in my opinion. Ortizesp (talk) 05:30, 4 March 2023 (UTC)[reply]
These articles receive less than one page view per day, so they are not often useful; even the web crawlers don't use them every day. Levivich (talk) 05:52, 4 March 2023 (UTC)[reply]
And? It's useful to that person per day that's looking at it, not sure there's a number for usefulness. Ortizesp (talk) 00:24, 5 March 2023 (UTC)[reply]
Less than one per day means nobody is looking at them except web crawlers. The lowest one on the list has 20 views in a year. Some of these have been like this for over ten years. These articles are dust in the attic. Levivich (talk) 00:32, 5 March 2023 (UTC)[reply]
I don't agree that the views an article gets dictates whether it should be kept or not. Ortizesp (talk) 03:01, 8 March 2023 (UTC)[reply]
I agree with you, what’s the harm in keeping all these? No problems were brought up in nom about verified information, so I don’t see how they hurt anything.
I guess in general, I don’t really get the point of notability in general across wiki if information can be verified, it might still be useful to someone. BhamBoi (talk) 05:49, 2 April 2023 (UTC)[reply]
@BhamBoi, I think you might be interested in WP:WHYN. Basically, the point of notability is to make it possible to write a proper encyclopedia article that complies with the core content policies.
No independent sources? It'll be difficult to comply with Wikipedia:Neutral point of view if you can only source the subject's own view, especially once you get past a simple introductory statement like "Widgets, Inc. is a widget manufacturer".
Only trivial coverage? It'll be difficult to write a proper encyclopedia article (because you can only extract a limited amount of information from a passing mention, like "Alice Expert, a consultant in the widget industry, said that demand for widgets was steady", and having dozens, or even hundreds, of such passing mentions doesn't really solve the fundamental problem).
Support assuming the query issues are fixed. Not worth the time to individually delete. Galobtter (pingó mió) 09:29, 2 March 2023 (UTC)[reply]
Support I'm generally suspicious of mass action, but this feels like a reasonable first step to solving a difficult situation. For one, it's clear that some kind of cleanup is required, and increasing AfD workload by something like half for literal years simply cannot be the only solution. The proposed extremely extended draftification seems like a suitably conservative approach (to the point that I'm not sure five years is truly required), giving editors plenty of time rescue any articles that warrant rescuing while ensuring that (most of) those which do not warrant retaining are eventually (even if after an extensive wait) removed. The set of articles identified here (or rather, the criteria used to identify it) seems like a very "safe" subset with high accuracy to the point of sacrificing recall.I'm sure that this type of mass action will not be sufficient to solve this situation completely: there will inevitably be literally thousands of articles that will need to be checked by hand and discussed individually. But filtering out some of the "worst" ones out for a start should conserve everyone's energy for the less clear-cut cases.I'd also support an alternative where these would be redirected to "Country at year season Olympics" as suggested by Curbon7 in § Discussion, below. -Ljleppan (talk) 12:34, 2 March 2023 (UTC)[reply]
I just rescued Addin Tyldesley now. Just wasn't aware of it previously, but I saved an article in probably even less time than it took to suggest it be deleted.KatoKungLee (talk) 01:16, 4 March 2023 (UTC)[reply]
No independent RS were added demonstrating he meets GNG, so the article wasn't "rescued". JoelleJay (talk) 01:25, 4 March 2023 (UTC)[reply]
Articles can't be judged on new standards, as those can always change. Just as someone had 5 years to edit this, people here had years to mark this as a draft or to delete it.KatoKungLee (talk) 01:59, 4 March 2023 (UTC)[reply]
Your response is farcical. You added literally nothing to that article that would get it to pass this project's notability threshold. That is not debatable. Zaathras (talk) 02:40, 4 March 2023 (UTC)[reply]
I prefer draftification as I believe it makes the articles easier to work on but I would support redirection as a second choice, with the requirements to restore the article being the same in regards to sourcing.
As it appears there is some support for this alternative I've created a list of proposed targets to allow it to be properly discussed. Note that some articles have multiple targets; a way to resolve that issue would be required.
I assume the editors in support of this proposal would support this alternative, at least as a second choice, as this proposal already includes that possibility; Rhododendrites, Black Kite, Pawnkingthree, would you support this alternative as your first choice rather than opposing entirely? BilledMammal (talk) 17:29, 2 March 2023 (UTC)[reply]
That would be my first choice, yes., Pawnkingthree (talk) 00:26, 3 March 2023 (UTC)[reply]
Support These have not been shown to meet the basic notability requirements of NSPORTS including "A person is presumed to be notable if they have been the subject of significant coverage" and "Sports biographies must include at least one reference to a source providing significant coverage of the subject, excluding database sources." Draftification is the best solution to prevent these mass-created stubs from being any more of a time sink, while giving folks the opportunity to work on any that can be proven notable. I think this RfC format will be the best way forward to deal with these mass creations. –dlthewave☎ 13:52, 2 March 2023 (UTC)[reply]
Support For the reasons given. IMO the ideal final result would be to have each of these end up as one line in a table in a broader article. This proposal is a good framework handle that possibility if the 5 year thing is doable. If not, then we have 6 months for somebody to take that on. North8000 (talk) 14:13, 2 March 2023 (UTC)[reply]
Support - Per above as a necessary step in clearing out the issues caused by the mass creation. — Ixtal( T / C ) ⁂ Non nobis solum. 14:19, 2 March 2023 (UTC)[reply]
Oppose - Draftification when the author of the page is blocked is just delayed deletion. Contrary to what BilledMammal says, creating a glut of AfDs is not actually the only alternative. There are three other options: (1) redirect them all to the relevant team/event articles. Articlespace pages for people mentioned in other articles should redirect to those articles anyway, even if the articles are draftified. If redirects are reverted, choose another from this list or send to AfD at that time. Further, for those whose efforts at redirecting have been thwarted, I'd even support a proposal to redirect them all, putting the burden on anyone recreating the article to demonstrate notability. (2) Rather than assume all 960 people are exactly the same, with exactly the same available sourcing, help figure out which are actually notable and improve those. (3) Anything else. There's zero exigency here. I certainly wouldn't say these stubs do anyone any good (and am opposed to the creation of stubs based on databases), but these stubs weren't created illicitly, and they don't harm the project in any way except for the drama that has grown around them. There's no obligation to deal with them. Personally, I prefer #1, but including the others because the threat of "otherwise we'll have to tank AfD" is silliness. — Rhododendritestalk \\ 14:31, 2 March 2023 (UTC)[reply]
Support Non-notable stubs are of no benefit to the reader in their current form, and AfD can't handle this amount. Avilich (talk) 14:58, 2 March 2023 (UTC)[reply]
Oppose, deleting a thousand pages (which is what this amounts to) for drama-based reasons doesn't build the encyclopedia but seeks to tear out a major part of its Olympic collection. Voices of reason needed please, thanks. Randy Kryn (talk) 15:01, 2 March 2023 (UTC)[reply]
Support redirection, Oppose draftification Even as something of a deletionist, I am somewhat perplexed as to why these need to be draftified. If they're not good enough, why not simply redirect them to the relevant event, event group or Games article? At least that might help someone searching for them. Black Kite (talk) 15:18, 2 March 2023 (UTC)[reply]
Support as Lugnuts created so many thousands of Olympian biographies that comprehensively fail WP:SPORTCRIT that it is not realistic to expect that editors can address them all within the next several years using our standard processes (i.e., finding and adding WP:SIGCOV, which if it exists most of it is stored in difficult-to-access, non-English-language archives, identifying appropriate redirects, proposing and nominating for deletion) without completing overwhelming AfD. This moves these biographies out of mainspace for 5 years, so there is sufficient time for interested editors to address them. As the query shows, on a given day, Lugnuts was often creating 50+ of these biographies. I think that Lugnuts' highly unusual article creation justifies the movement of so many of those articles out of mainspace at once. Jogurney (talk) 15:37, 2 March 2023 (UTC)[reply]
Articles should not be judged under rules that didn't exist when they were created. And we know this is happening, because if those rules existed, those articles wouldn't have existed. If someone tomorrow makes a rule that all articles have to mention "jello" or be deleted, we would lose almost all of the site overnight.KatoKungLee (talk) 17:31, 3 March 2023 (UTC)[reply]
Even if that nonsensical approach was used, the rule that all athletes must meet GNG was in place at the time Lugnuts created these articles. JoelleJay (talk) 01:27, 4 March 2023 (UTC)[reply]
No, we considered all Olympic athletes at the time automatically notable. BeanieFan11 (talk) 01:28, 4 March 2023 (UTC)[reply]
That is not true, GNG coverage was always presumed to exist for Olympians but it was never an automatic notability pass. Editors were just more reluctant to challenge Olympians because that presumption was considered strong. JoelleJay (talk) 01:43, 4 March 2023 (UTC)[reply]
Support - When someone copies a database and pastes it into Wikipedia by the thousands, creating tiny stubs on subjects that don't meet WP:GNG or any WP:SNG, and then never touches the articles again, and no one else reads or edits the articles, for years, even over a decade... the articles are not worth keeping in mainspace (WP:NOT). We will never be able to get through these at AFD, there are too many. Some say redirect them all, some say expand them, some say delete... this procedure is flexible and allows editors plenty of time (five more years) to deal with these titles as they see fit (redirect, merge, draft, expand, userfy, WikiProject). It's better than an WP:XCSD, and it's better than leaving them in mainspace, unedited and unviewed, forever. Levivich (talk) 15:44, 2 March 2023 (UTC)[reply]
Oppose (now support redirection) I don't see any reason why every single one of them cannot just be redirected to the relevant Olympic article.-- Pawnkingthree (talk) 15:47, 2 March 2023 (UTC)[reply]
If this proposal passes, they can still all be redirected, by any editor at any time. If this proposal fails, they won't be redirected. So why oppose? Levivich (talk) 15:57, 2 March 2023 (UTC)[reply]
Draftification of a stub is only useful if there's someone immediately available and interested in working on it. Instead of having them sit for five years in draftspace, the title should be in mainspace redirecting to a useful article if a reader searches for it.-- Pawnkingthree (talk) 16:29, 2 March 2023 (UTC)[reply]
I understand your point -- in fact, I agree with it. But right now, we can't turn them into redirects (when editors try, it gets reverted). We can't have 1,000+ discussions about "should this be a redirect". If this proposal passes, then we can redirect these titles. If this proposal doesn't pass, then we're back to the status quo: can't redirect, would need a second RFC just about redirect, which we can't have for a while after this RFC ends (for the usual reasons). So if you believe these should be redirected, I urge you to support this proposal, so that anyone who wants to turn these into redirects can do so for whatever articles on this list they think should be redirected (and of course the articles could still get expanded into real articles by anyone who wants to do so). Proposal Provision #5, about redirects, was written specifically for editors who believe these should be redirects. #5 (redirect) is an option on the menu of this proposal; I don't think it would help improve the encyclopedia to oppose this proposal because #5 isn't the only option on the menu: that would be letting the perfect become the enemy of the good. I'd ask you to consider "support #5 only" rather than opposing. Levivich (talk) 16:46, 2 March 2023 (UTC)[reply]
Yes, you can turn them into redirects. In fact, many redirects have g45one unopposed. BeanieFan11 (talk) 16:43, 2 March 2023 (UTC)[reply]
So if you believe these should be redirected, I urge you to support this proposal - (Here and elsewhere) your argument that redirect is compatible with this proposal is bizarre. By the same logic, it would also be compatible with absolutely any other mass action that's not redirecting, because you can always redirect them afterwards. For anyone who thinks they should be redirected, draftification is just an unnecessary additional step that adds a countdown clock to the redirection process. — Rhododendritestalk \\ 16:51, 2 March 2023 (UTC)[reply]
No because if you go and redirect the articles now, someone will revert you, and then you have to WP:BRD that stuff, meaning 1,000 discussions. If this proposal passes, then someone can redirect these articles, and no one could revert that unless they added a GNG source per #4 and #5 of this proposal. This proposal fundamentally is about getting consensus that these microstubs should not remain as they are, and then allowing a wide variety of options for how to deal with them. IMO no one should be opposing unless they think the stubs are fine to be left alone the way they are (which some people do, reasonable minds can disagree). Levivich (talk) 17:06, 2 March 2023 (UTC)[reply]
Support: When articles ammount to little more than a name, birth date, death date, nationality and a sport they have competed in, they should not be kept as articles. And with 960 of these articles it is unrealistic to keep them in the article space and add more references and information for each in a timley manner, so draftifying these articles is the appropriate action. Terasail[✉️] 15:53, 2 March 2023 (UTC)[reply]
Support: and, I'd argue that this IS the way to address Rhododendrites' second point casualdejekyll 16:33, 2 March 2023 (UTC)[reply]
Oppose, per a few above. Mass draftifiying Olympians is not a good idea for several reasons:
This will result in the mass deletion of boatloads of notable articles: As said above, many of these are notable. That being said, what this is basically is just the delayed removal of the majority of them under the nice-sounding tone "you can just move it back if its notable – and everything works out" – if this is approved here's what will happen: all these articles get moved to draftspace, only a couple get worked on (I doubt that there's going to be a ton of eager editors who want to help out in writing articles on 1900/10s Olympians), and then eventually just about all of them get deleted. Additionally the proposer has made it clear he plans on going after the rest if this passes, which will result in not just the initial 1,000, but then the rest of the 90,000 also being put there. We do not have the time, energy or resources to expand 90,000 articles in a short period of time with deletion the consequence if we do not. And I'll bet that BM and his deletionist buddies will go after other sports if they get rid of the Olympians, and then the rest of stubs until this place becomes a perfect deletionist paradise. But back to the consequences of just this being passed: many many notable articles will get deleted in the end, and a few improved. Does that help the encyclopedia? NO.
There is no harm in keeping these. The only harm that could possibly be done would be if this is passed, which will (as said above) result in many notable articles being deleted, and a few improved. That is not an improvement to Wikipedia at all And it would especially not be an improvement if this passes because then it would possibly lead to absolute loads more being proposed to be removed and likely removed. 1,000 short articles provides much more overall value than a few nicer-looking ones in my opinion.
There are other ways in dealing with them. As Rhododendrites said above, there are several different ways that these could be dealt with than mass draftification. The proposers are stressing that "oh its way too hard to have these at AFD" – AFD is not the only option. Of the numerous different ways these could be dealt with, my personal favorite – expand them.
So in conclusion, mass draftifying nearly a thousand Olympians would have a terrible effect on the encyclopedia, and is completely unnecessary. Signed, BeanieFan11 (talk) 16:38, 2 March 2023 (UTC)[reply]
Oppose So, there are several problems with this discussion. First, and only tangentially related to my vote, but still bears mentioning, is the statement "which led to sanctions from the community and to Lugnuts being indefinitely sitebanned by Arbcom. The initial ban was for "Canvassing, incivility, bludgeoning, spamming" (quote taken from the initial ban proposal); it was not the creation of stubs per se that led to the ban. Furthermore, the Arbcom ban does not explicitly state that it was merely for creating the stub articles in the first place. Indeed, the ban was enacted under a variety of problem, including "making personal attacks, engaging in battleground behavior in deletion discussions, and other disruptive deletion behavior." and notes things like "been blocked for conduct at AfD" (both quotes from the ArbCom page). The OP makes the disingenuous post hoc ergo propter hoc assertion that they were banned because they created the above article stubs. They were banned for things like being disruptive to the AFD process and battleground behavior, making personal attacks. All of that is sanctionable offenses. Creating stub articles is not. I can go create a stub article right now and no one would be proposing to ban me. So the very premise that the ban was enacted merely because some stubs were created is a non-starter for me. That being said, what do we do with all of these stubs? Nothing at all. If the article meets the standards to be an allowable stub article if it hadn't been created by Lugnuts, like if it was just a stub created by someone else, then there's no reason to do anything special to it because it was created by Lugnuts. They're perfectly fine in the mainspace. If you find one of the stubs you want to expand, do so. If you find one of the stubs should be deleted, WP:AFD is thataway. If you don't want to do either of those things, doing nothing is perfectly fine too. Even if the OP's initial statement wasn't fraught with the errors I already noted, I would still oppose treating these stubs any differently than any other random stub someone might happen to trip over. --Jayron32 16:55, 2 March 2023 (UTC)[reply]
Preliminary question. I am open to a proposal to delete many of the early Olympic participants, but this appears a proposal to delete hundreds of articles without even providing a list of the articles to be deleted. Maybe I'm wrong. Is there a list of the proposed deletions? Before casting a vote, I would like to see a list and have an opportunity to peruse it. Cbl62 (talk) 16:57, 2 March 2023 (UTC)[reply]
@Cbl62: The list is in a collapsed green box at the top of the proposal, right below the question and above the "details" section. Levivich (talk) 17:01, 2 March 2023 (UTC)[reply]
Thank you. Cbl62 (talk) 17:11, 2 March 2023 (UTC)[reply]
Support. There are not any perfect options here, but I think this is the best. If someone wants to shepherd some draft stubs back, there's ample time to do so. Der Wohltemperierte Fuchstalk 17:00, 2 March 2023 (UTC)[reply]
Support either this or mass redirecting. Pre-WW1 Olympians are usually not notable, and so most of these can never become full articles. —Kusma (talk) 17:28, 2 March 2023 (UTC)[reply]
Also, I propose removing from the list those who competed in the Olympics after 1912 – this is supposed to be from 1896 to 1912, not after as well. BeanieFan11 (talk) 17:30, 2 March 2023 (UTC)[reply]
We also should not have ones that were kept at AFD (post sports RFC) on this list. BeanieFan11 (talk) 17:37, 2 March 2023 (UTC)[reply]
Support, and I would add that we need to review more than 960 articles at a time; at such a low rate, cleaning up after Lugnuts will take about 8 years.—S MarshallT/C 18:05, 2 March 2023 (UTC)[reply]
Oppose. Per Wikipedia's deletion policy, draftification must not be used as a "backdoor to deletion". Because abandoned drafts are deleted after six months, moving articles to draft space should generally be done only for newly created articles... or as the result of a deletion discussion.[1] Older articles should not be draftified without an AfD consensus, with 90 days a rule of thumb.[2] This proposal is an extremely clear attempt to mass draftify articles as a backdoor to deletion. The nominator writes that the alternative is not practical but there is another alternative not considered in the OP's arguments—using the articles for deletion process to make decisions with respect to a single mass AfD of these sorts of things. Also, WP:DRAFTOBJECT is pretty clear that literally anyone can object to the draftification of a particular article and revert it to the mainspace, so I'm not sure that this would actually achieve the resolution that the proposer of this RfC desires (all it would take is a few editors to restore one article to mainspace per day over the next six months for this mass draftification to end up back where we started, and that seems to just be delaying sending these to AfD). — Red-tailed hawk(nest) 18:10, 2 March 2023 (UTC)[reply]
By extending the autodeletion period to five years the specifics of this proposal are intended to prevent this being a backdoor to deletion, and the various options around article adoption and article redirection are also intended to prevent that. It will also prevent improper restorations; if there is a consensus for this proposal editors will only be permitted to restore these articles to mainspace after adding sources containing significant coverage. BilledMammal (talk) 18:23, 2 March 2023 (UTC)[reply]
Will this apply to all draftified articles, or just to the 960? My understanding is that we have an adminbot delete old drafts if they are more than 6 months untouched. — Red-tailed hawk(nest) 19:53, 2 March 2023 (UTC)[reply]
Only to the 960. The specifics of this need to be determined, but there are plenty of options and the required bot modifications will be minor. BilledMammal (talk) 00:41, 3 March 2023 (UTC)[reply]
Support. The proposal is unprecedented, and I am generally opposed to mass actions of this type. Despite my reservations, I do support this proposal limited to early Olympians. My rationale is as follows:
No reasonable expectation of notability. The past year of dozens and dozens AfD discussions has clearly demonstrated that mere participation in the Olympics in the early years of the games is in no way a basis to presume or expect that the individual is notable under our WP:GNG standard.
Mass creation. The articles at issue were the product of a well-documented mass process in which thousands of articles were created at the rate of approximately a minute per article.
Lack of substance. The articles are microstubs that contain limited narrative text simply reciting that the person was an athlete in a particular sport who competed in the Olympics X year. If the articles are ultimately deleted, nothing of real substance is lost. If SIGCOV is later uncovered and brought forth, and given the fact that only a minute or so was devoted to the original effort, the articles can be re-created without any meaningful loss of prior effort.
Violation of SPORTBASIC. The articles violate prong 5 of WP:SPORTBASIC which provides: "Sports biographies must include at least one reference to a source providing significant coverage of the subject, excluding database sources." The articles here are sourced only to database sources and do not include SIGCOV.
Cleanup of "deliberate errors". A departure from normal processes is also warranted by the unique case involving Lugnuts and his admission in August 2022 (here) that he added "countless deliberate errors on pages that have very few pages views." Draftification of these low-page view articles permits screening for such errors.
In sum, I support draftification in this narrow situation. In normal and less egregious circumstances, I would expect normal AfD or redirect procedures to be followed and would likely oppose such a proposal. Cbl62 (talk) 18:13, 2 March 2023 (UTC)[reply]
Oppose. I originally supported but now BilledMammal is objecting to the removal from the list of articles like Roland Spitzer and Edward Greene (sport shooter) even though they have been expanded, now include SIGCOV, and are not based solely on database entry. IMO the extreme remedy of mass removal of articles should not be considered for articles that fall into a gray area. Such articles, if challenged, should be dealt with under regular order, by normal AfD processes. Cbl62 (talk) 06:53, 7 March 2023 (UTC)[reply]
Restoring support based on representation that Spitzer and Greene will not be draftified. Cbl62 (talk) 18:38, 15 March 2023 (UTC)[reply]
Support - seems the best thing to do. GoodDay (talk) 19:01, 2 March 2023 (UTC)[reply]
Strong Oppose This is a backdoor attempt at deletion of articles via the Village Pump, and as such is an obvious violation of deletion policy. Take them to AFD if you want them deleted or demoted to drafts. Steven Walling • talk 19:59, 2 March 2023 (UTC)[reply]
Lugnuts is Wikipedia's most prolific article starter, ever. He started rather more than 90,000 articles, most of which were biographies, and he's told us he put deliberate inaccuracies in them. If we nominated 10 of them at AfD every day, it would take nearly thirty years to process them all. I'm afraid that it's simply unfeasible and unrealistic to use AfD to clean up after Lugnuts. It would also be profoundly unfair on other editors to swamp our normal deletion processes with the quantities of articles involved.—S MarshallT/C 23:36, 2 March 2023 (UTC)[reply]
Nominating a group of articles like hoaxes is explicitly called out as allowed in our deletion policy, per WP:BUNDLE. In addition to this being the wrong venue, the stated intent of the proposal is to test the waters for establishing a precedent for mass deletion, which is bad faith and not clearly about removing demonstrably bad articles that violate notability or verifiability policy. Steven Walling • talk 04:59, 3 March 2023 (UTC)[reply]
"he's told us he put deliberate inaccuracies in them" - is it proven? Not much room for inaccuracies in a stub. Pelmeen10 (talk) 10:49, 3 March 2023 (UTC)[reply]
Of course it's proven. Lugnuts claims he introduced deliberate inaccuracies into his stubs in this edit. Some don't believe him on that point, because he was ragequitting Wikipedia when he wrote that. Others might suspect that someone who often started upwards of 20 articles a day wasn't checking his facts carefully in the first place. Whichever side you take, it's my view that we have reasonable grounds to doubt the accuracy of this content.—S MarshallT/C 11:02, 3 March 2023 (UTC)[reply]
Deleting 960 articles on the chance that there might be inaccuracies is a bit of a stretch. There might be inaccuracies in basically everything that isn't a GA or FA article, but there is no deadline for fixing work in progress, and perfection isn't required. These aren't BLPs, either. Steven Walling • talk 23:44, 3 March 2023 (UTC)[reply]
When the article author admits they've put deliberate inaccuracies and obfuscated copyvios in biographical articles, I'd normally expect a more active response than this from a sysop. I do hope you'll reconsider your position here.—S MarshallT/C 23:55, 3 March 2023 (UTC)[reply]
Like you said, he was ragequitting. I wouldn't be surprised if he said that in order to make people delete all his articles as a "f*ck you" to the project. Steven Walling • talk 01:04, 4 March 2023 (UTC)[reply]
If that was what he wanted, he could have achieved it for almost all his articles with G7. I don't think that is what he wanted. BilledMammal (talk) 03:13, 4 March 2023 (UTC)[reply]
Either way, the argument that we should mass delete a series of articles via a straw poll at the Village Pump is utter nonsense. These articles met notability requirements when they were created and many, if not most, of them probably still do. There's no way of knowing, when you nominate 960 at once based on a hunch, rather than an actual review of the articles and research into all the possible source material. Steven Walling • talk 05:37, 4 March 2023 (UTC)[reply]
Have we gotten any proof aside from Lugnuts statements, that he has introduced deliberate inaccuracies? It's better to have no articles rather than a faulty article. ✠ SunDawn ✠(contact) 03:42, 4 March 2023 (UTC)[reply]
@SunDawn: Plenty of inaccuracies have been found; whether or not they are deliberate is impossible to say for certain. One example has already been given in this thread by CMD. I just checked another random article myself; literally the first one I clicked on, Fyodor Zabelin, has the wrong birth date in the infobox. Since Lugnuts specifically mentioned birth dates in his claim that he had introduced deliberate errors, one might wonder whether this gives some ground for believing him. Sojourner in the earth (talk) 05:36, 4 March 2023 (UTC)[reply]
Neither of them can be described as deliberate errors. Wrong date on infobox for Fyodor Zabelin must've been an error, as Lugnuts created Yrjö Vuolio (with that birth date) just 4 minutes earlier. Pelmeen10 (talk) 21:10, 4 March 2023 (UTC)[reply]
Pelmeen10, thanks for looking that up. I didn't read as far as your contribution but thought "Lugnuts introducing deliberate errors? No way!" I've worked a lot with Lugnuts on rowing articles and have always found him conscientious. So I did the exact same as you did: looked up what else did Lugnuts create on 16 July 2019 in that batch, found that he created 10 articles during 29 minutes, Zabelin was the second article in that batch and the birth date belonged to the first article. A simple database / copy-paste error. I think we should dismiss the idea of Lugnuts having introduced errors deliberately; that is simply not the editor who I had the pleasure working with. Schwede66 05:01, 6 March 2023 (UTC)[reply]
Schwede66 - Just to be clear on this, this kind of totally careless article-creation (systematically reproducing errors), spread over many thousands of articles, is the kind of thing that would get you a warning first and eventually banned if you persisted in doing it nowadays. Accidental or not, competence is required. FOARP (talk) 09:35, 6 March 2023 (UTC)[reply]
Strong oppose as Village Pump is not the place to mass delete articles, as is effectively beimg proposed here. No need for a mass decision on all of these articles, they should be checked according to relevant AFD policies individually as some will definitely be notable. Speedy redirecting should be used when there is clearly no notability. This range of dates is also completely arbitrary, with no justification for why the specific dates were chosen and why these people's notability should be assessed differently to Olympians of different years. Joseph2302 (talk) 20:12, 2 March 2023 (UTC)[reply]
Strong Oppose unless there is a guarantee that the sources already in each article have been examined and any even marginally close calls removed. For example, I would have concerns about the inclusion of Alf Davies (swimmer) on this link - the sources suggest that there's a decent chance that there's more there in newspapers and so on. This isn't the first time lists like this have been put forward - I think we found a knight of the realm on one list... At that point I would still oppose in favour of redirecting where even remotely possible per WP:ATD (which is a policy not a guidelines) - draftifying like this is an utter waste of resources for everyone concerned, whereas a redirect preserves the page history and attribution and enables an article to be returned to if sources emerge and someone has the time and motivation to do so. Finding those initial sources, especially when some are archived, isn't as simple as some of the views here might suggest. We have alternatives to deletion; these are flat out more efficient and we should use them. Blue Square Thing (talk) 20:16, 2 March 2023 (UTC)[reply]
Somewhat beside the point, but I can't find any evidence that Alf Davies is notable. I checked a few newspaper archives (e.g. 1), and there's stuff about a boxer and a footballer but no swimmer. If that short bio is correct, his winning of the The Serpentine#Peter Pan Cup seems unimportant; it's a small regional festive race. I'll probably redirect him to Swimming at the 1908 Summer Olympics – Men's 200 metre breaststroke, which seems like the appropriate target. Suriname0 (talk) 17:40, 29 April 2023 (UTC)[reply]
I wouldn't expect NewspaperArchive.com to have sigcov of Davies; it would likely be at the British Newspaper Archive or similar. BeanieFan11 (talk) 17:42, 29 April 2023 (UTC)[reply]
Didn't see anything on BNA either. No problem with discussing at AfD; see here. Suriname0 (talk) 18:21, 29 April 2023 (UTC)[reply]
Support. I made a similar proposal at one of the many RfCs this past year, so of course I support this. I don't understand the "backdoor to deletion" hand-wringing or complaints about the possibility of inclusion of maybe notable athletes in this list. If there are people in there who you think might meet GNG, guess what!! You can personally take them out of draft space and work on them in your user space, thereby avoiding the extremely overly-lenient 5-year deadline. Or you could redirect them. Or put them in project space. These are all better for people who want to keep articles than leaving them in mainspace where they will likely be athlete #22 taken to AfD on any given day and you'll only have a week to find all those difficult-to-access sources that surely exist. JoelleJay (talk) 22:25, 2 March 2023 (UTC)[reply]
Support, the proposal is for a very targeted list, and the way these articles have been generated seems problematic. The first one I clicked on was Alexander Martin (Canadian sport shooter). That article, in its entirety: "Alexander Martin (28 December 1864 – 26 October 1951) was a Canadian sports shooter. He competed in the 1000 yard free rifle event at the 1908 Summer Olympics." I checked the Olympedia source and was immediately struck by "Born: Glasgow, Died: Woking". These are clearly not Canadian locations. Olympedia also lists two family member Olympians, both of whom apparently competed for the GBR NOC. So while Alexander Martin may have competed for the Canada NOC, there seems a lot of evidence that describing them as primarily Canadian is a mistake. If somehow the first article I clicked on was the only problematic one, then I suppose I'd have to revise, but that seems unlikely. I would strongly support mass redirection to the relevant Olympic page (if available), and of course would also support people expanding these where possible to be useful and accurate. Both these actions are possible with or without the passing of this proposal though, so I don't understand how they are coming up as oppose rationales. CMD (talk) 00:05, 3 March 2023 (UTC)[reply]
Looking at the article, I noticed that the source used for his Olympic participation refers to a certain Arthur, not Alexander, Martin from Canada born in a completely different year! Tvx1 16:10, 7 March 2023 (UTC)[reply]
@Tvx1: Look at the Olympedia source, which states "Name previously given as Arthur Martin, but this is not supported by contemporary Calgary newspapers." BeanieFan11 (talk) 16:15, 7 March 2023 (UTC)[reply]
But that is a wiki just lile this one and thus unreliable. And what about the twelve years discrepancy in the birth year? Tvx1 16:23, 7 March 2023 (UTC)[reply]
Olympedia isn't an unreliable wiki. As for the birth year, it seems that the people who run SR/Olympedia originally believed the shooter to be Arthur, but then later realized it was actaully a Martin named Alexander, born twelve years prior. BeanieFan11 (talk) 16:26, 7 March 2023 (UTC)[reply]
I do not see anything that makes it reliable. Moreover, the official site says it was Arthur, not Alexander, Martin as well. The Calgary statement doesn’t even make sense. What do local Calgary newspapers matter to an athlete who was allegedly born in Glasgow and died in Woking?? Tvx1 17:33, 7 March 2023 (UTC)[reply]
"Olympedia isn't an unreliable wiki" - I see absolutely no reason at all to believe that Olympedia is particularly reliable. Whilst the sports statistics on Olympedia come from official bodies (though the chain of ownership is unclear) and might be said to be reliable for that reason, there is a strong wiki-like aspect to the prose content, birth/death dates, and also potentially to the names used on the database. For example when an AFD was raised against our article about a non-notable rower called Francis English it turned out that the death-date was wrong and Francis English went under the name "Frank", Olympedia was updated to include the nickname and the corrected death-date soon after the AFD meaning they were relying on Wikipedia to do their fact-checking. Prose content on Olympedia also appears to come from e.g., families of the Olympians concerned and thus is not independently sourced. I get that the head of Olympedia is supposed to be an expert but the database is run by volunteers and there is no clear editorial system or rigorous fact-checking. T's concerns are thus well-founded and cannot be dismissed simply by saying "I haven't seen many errors" or that the IOC has used it. FOARP (talk) 11:32, 8 March 2023 (UTC)[reply]
Agree. That’s the exact same sentiment I have. The Alexander/Arthur Martin case is another example of the issues they have. Tvx1 16:08, 8 March 2023 (UTC)[reply]
Support competing in the Olympics is not an indication of athletic greatness. Participation is often decided by politics, or there may not be any gatekeeping at all. See also the 1904 Summer Olympics, 1904 men's marathon; apparently a free-for-all. Schierbecker (talk) 00:18, 3 March 2023 (UTC)[reply]
Oppose It is against policy to use draftifying as a backdoor for deletion. Red-tailed hawk sums it up perfectly. --Rschen7754 01:17, 3 March 2023 (UTC)[reply]
Oppose I find no reason to delete them. There could be a reader looking for information on the topic; we are an encyclopedia; why do we feel the need to delete information? I this context, I think the stub-quality of the articles is irrelevant. Perhaps the content would be better served as part of a larger article, but I wouldn't know where to begin. Further, it would be a fallacy to assume that an "oppose" vote would necessarily lead to mass AfDs — it is a false assumption that the articles involved need to be deleted at all. JuxtaposedJacob (talk) 01:48, 3 March 2023 (UTC)[reply]
WP:NOTEVERYTHING and WP:N; just because there is verifiable information on a topic doesn't mean it belongs in Wikipedia. These are also why failing to deal with these articles through a process other than AfD will lead to mass AfD's; leaving non-notable topics in mainspace makes Wikipedia worse, and it is against policy to do so. BilledMammal (talk) 02:08, 3 March 2023 (UTC)[reply]
Support If someone spends a few seconds doing something mildly disruptive, we should have no qualms about undoing that thing. If anyone wants to create a well-sourced article on one of these individuals, these stubs will be of no help at all. The community has found Lugnuts' mass creations to be disruptive, why immortalize his inappropriate creations? In fact, I'd support deleting all of them that haven't attracted major content contributions from others. No prejudice towards decent articles on the same topics being re-created in the future. Ajpolino (talk) 04:30, 3 March 2023 (UTC)[reply]
Support Although they should really be deleted after the normal 6-month period. Also rather disappointing to see the same cheerleaders from the non-notable NFL player debate weighting this discussion down. Zaathras (talk) 04:45, 3 March 2023 (UTC)[reply]
Support draftification as first choice. Aside from the problem of notability, many of Lugnuts' articles have been shown to have serious verifiability issues (almost inevitable with articles created at speed). If it's true that Lugnuts has admitted to introducing deliberate inaccuracies (@S Marshall: do you have a diff for that?), that's all the more reason to remove these articles from the mainspace as soon as possible. I came into this expecting to support redirection over draftification, but I've explained below why I don't think this is practical. Sojourner in the earth (talk) 08:50, 3 March 2023 (UTC)[reply]
Strong Support - And yes this should be rolled out to Lugnut's 19th-century cricketer articles, his 19th/early 20th century footballer articles, and to sub-sets of the mass-created articles of other historical mass creators (e.g., Carlossuarez46, Dr. Blofeld). WP:PROVEIT is pretty clear on what happens to content the notability of which isn't supported - either the people who want it kept find support for it, or it gets deleted. Any other position is allowing editors to establish a fait accompli of mass-created articles that will never be improved to meet notability standards, and most of which cannot be improved. WP:FAIT is clear that we should not allow that.This cannot be handled one-by-one by the normal AFD process as it would jam it permanently. Mass deletion through AFD is possible but this discussion is frankly just as valid as any AFD discussion and probably will engage with more editors which, frankly, is needed, as AFD discussions are often dominated by people heavily invested in the deletion/keeping of article-sets such as this one.
Some argue that the fact that some of these articles may be notable is a reason to keep all of them. It simply isn't. What that is is a reason for people who want them kept to go and establish the notability of those articles and bring them back to mainspace. Anything else is accepting a WP:FAIT situation.Finally, this is not personal. I would also support the same measure be used against other articles sets that were created in violation of WP:MASSCREATE, even by editors I generally like.
ETA - my favoured position is actually just straight deletion of these articles. Draftification is something I'm OK with as an alternative to that because in reality everyone knows that only a handful will be saved even with years of time to work on them because so few of them even can be saved. Redirection is basically a non-flyer for the reasons I discussed below in relation to "Harry" Oppenheim - there is no reason, no reason at all, to redirect people to a list in which specific non-notable Olympian is possibly mentioned (many of the redirects will have the wrong name, because of the poor methodology used to create these articles), rather than serving the full search-results to them and allowing them to see all of the other places that person and other people with the same name listed on EN Wikipedia. FOARP (talk) 09:21, 3 March 2023 (UTC)[reply]
Support per nom, 5 years is ample time for any interested editor to expand on any of the articles. Redirect to the relevant pages would also be fine in my opinion. BogLogs (talk) 09:26, 3 March 2023 (UTC)[reply]
I just saved an article now - Addin Tyldesley. Just wasn't aware of it previously, but I saved an article in probably even less time than it took to suggest it be deleted.KatoKungLee (talk) 01:20, 4 March 2023 (UTC)[reply]
Oppose as the solution to the problem is needlessly complicated. Seems to me that the simple(st) solution is to delete all relevant stubs created in this way immediately. WP editors who are interested in writing about any Olympian who is truly notable could presumably get the same starting information from the same sources that the current stubs used, so there's nothing to be gained by draftifying. JMWt (talk) 10:26, 3 March 2023 (UTC)[reply]
@BilledMammal: well I don't know. Firstly I don't know how automated the process would be or whether it would need considerable manual editing time. Second it seems to me that there is quite a high risk of good-faith errors creeping in when trying to do this with so many pages (for example an Olympian being accidentally attached to the wrong team). This in turn could lead to even more circular referencing and the errors being repeated in off-wiki sources. For me the most accurate solution is delete. The databases still exist, there's no presumption that any of the Olympians in these stubs are not notable - so recreation if RS become available for particular people shouldn't be an issue. I accept that it looks like a sledgehammer solution, but for me the main overwhelming issue is the integrity of WP as a usable encyclopedia. If we routinely do anything which adds to the risks of spreading errors, that's bad. I'd rather keep the stubs that simply reflect the content of off-wiki databases than do anything else that introduces errors. JMWt (talk) 13:53, 3 March 2023 (UTC)[reply]
@JMWt: It would be easy to automate, and no new errors would be introduced; it might continue to include existing errors, but in that case we are no worse off than we currently are. BilledMammal (talk) 14:03, 3 March 2023 (UTC)[reply]
Oppose. per BeanieFan, my comments at the previous discussion about olympian stubs and most of the other opposers here. The way to deal with a mass creation of notable topics is not mass deletion or mass draftification - there is no deadline, and it is much better to get the right answer slowly than the wrong answer quickly. Thryduulf (talk) 10:47, 3 March 2023 (UTC)[reply]
This assumes we have a good interim position right now, which given the lack of attention that seems to have been paid to these articles I am not convinced of. There's no deadline by which redlinks have to be turned into tenuous blue links either. CMD (talk) 14:56, 3 March 2023 (UTC)[reply]
The past is prologue... There's not anything we can do about the fact that they have already been created, but as Thryduulf notes, now that they exist, we might as well deal with each thoughtfully. You are correct as the best action was probably not to have created these so rapidly, but we can't go back in time and make that unhappen. --Jayron32 19:20, 3 March 2023 (UTC)[reply]
Yes, we can make that unhappen, that's kind of what's being proposed here. Levivich (talk) 19:22, 3 March 2023 (UTC)[reply]
We can make that unhappen and per WP:MASSCREATE and WP:MEATBOT they shouldn't have been able to be created in the first place. Since 2009 it is policy to request permission for mass creation of articles here. And I'd argue that creating several articles within minutes or a few hours are likely to be considered bot like editing as mentioned at WP:MEATBOT. Per MEATBOT is also required to request permission at the same place. WP:MEATBOT is within a policy, for admins it would technically be possible to enforce it. Paradise Chronicle (talk) 01:10, 18 March 2023 (UTC)[reply]
Comment in addition to my note above and discussion below in the redirect section, there seem to be quite a few of these which have a reasonable claim to notability. We really need to read the sources and not rely on a machine query. Philip Plater, for example, seems well worth looking in to and if we delete this via drafting it'd be a massive mistake. A number of the British ones seem to have details that would be worth looking in to. Blue Square Thing (talk) 14:39, 3 March 2023 (UTC)[reply]
Why would it be a headache? Nothing is being salted and the Olympedia pages will still exist. The sources currently in Philip Plater doesn't suggest GNG, although the story should certainly be added to Shooting at the 1908 Summer Olympics. CMD (talk) 14:53, 3 March 2023 (UTC)[reply]
The Olympedia source, when you look at it, does in a way suggest that GNG coverage exists – I've found that when they give decent bios, the Olympians usually have a much higher GNG rate than when they don't. BeanieFan11 (talk) 15:01, 3 March 2023 (UTC)[reply]
I would agree! Maybe someday someone will be able to look into such cases and write some articles with more than a database pull, that could do basic things like not make slightly misleading nationality claims and include links to the events the athletes participated in. As noted above, there is no deadline for this. CMD (talk) 15:11, 3 March 2023 (UTC)[reply]
But we already have the articles! Why would we need to delete articles on a topic to be able to write something on that topic? BeanieFan11 (talk) 15:16, 3 March 2023 (UTC)[reply]
Perhaps this was missed, but we should have articles "that could do basic things like not make slightly misleading nationality claims and include links to the events the athletes participated in". CMD (talk) 15:51, 3 March 2023 (UTC)[reply]
The articles do link the events that the athletes participated in – and I haven't seen very many with the wrong nationality – just about all of them seem fine to me. BeanieFan11 (talk) 16:03, 3 March 2023 (UTC)[reply]
No they don't, Philip Plater which you linked just before didn't until I made the relevant edit. As for "very many", maybe not very many, but how many? We don't know, because these are procedurally generated sentence pairs. CMD (talk) 16:18, 3 March 2023 (UTC)[reply]
Lets see, I'm going to pick ten random people on this list and see if they have the link or not: Francesco Pietrasanta, no; Arthur Maranda, yes; Arthur Seward, yes; James Cowan (sport shooter), no; John McKenzie (wrestler), yes; Orazio Santelli, no; Yrjö Vuolio, yes; Jules Roffe, yes; Pierre Saintongey, yes; and Ödön Toldi, yes. That's 7/10 have it. And even if they were missing it, that's still no reason to mass get rid of them by the thousands. As for the nationality, to check, you can just click on the Olympedia link and it will tell you – I have only seen a handful with any issue, and in most of those cases it was half-right, i.e. they were born in e.g. Switzerland, and then became U.S. citizens and competed for the U.S., and the article referred to them as American. BeanieFan11 (talk) 16:34, 3 March 2023 (UTC)[reply]
It says he "competed at three events at the 1912 Olympics" and links "Athletics at the 1912 Summer Olympics" in the words "three events." BeanieFan11 (talk) 16:54, 3 March 2023 (UTC)[reply]
Correct, it does not link to the events he was in. CMD (talk) 01:11, 4 March 2023 (UTC)[reply]
I agree, Blue Squared Thing, many of these are likely notable. I've checked a bunch and for some I've seen Olympedia bios describing them as having been the best of the era, among the most famous, etc. For example, when I chose a random one in Lou Scholes and did a quick search, I found articles describing him as "the best oarsman the world has ever produced" (not surprising, though, considering this is the Olympics). And then for Albert Bechestobill, I was able to locate full-page long articles in major newspapers. When I looked for Arthur Burn, he was given headlines for his life and death. And another one I think would probably have good potential: Carlo Bonfanti – Olympedia mentions how the way Italy viewed diving was changed all because of him – there has got to be coverage on figures like that. And many Olympedia references have enough coverage that I'd consider them a SIGCOV source all by itself. BeanieFan11 (talk) 15:14, 3 March 2023 (UTC)[reply]
Checked out another one, Donnell Young, and he had in-depth feature stories published on him and was one of the only Olympic centenarians. This is really, really, really a bad idea to mass get rid of articles without any effort made to see whether they're notable. BeanieFan11 (talk) 17:26, 3 March 2023 (UTC)[reply]
It was a really, really, really bad idea to mass create these articles without any effort made to see whether they are notable. This proposal is what is required to correct that error. BilledMammal (talk) 17:31, 3 March 2023 (UTC)[reply]
When these articles were created, they were considered notable. Later modifications to the notability guidelines removed their automatic notability (but many are still notable). BeanieFan11 (talk) 17:34, 3 March 2023 (UTC)[reply]
They were presumed notable (under some interpretations of WP:NSPORT), and it was a really, really, really bad idea to mass create these articles without any effort to see whether they are are notable and thus ensure that this presumption was correct. BilledMammal (talk) 17:43, 3 March 2023 (UTC)[reply]
"Presumed notable" back then equaled "notable." BeanieFan11 (talk) 17:44, 3 March 2023 (UTC)[reply]
It actually never did, but many AFD closers just mistakingly assumed it did. It doesn’t do so anymore at all and actually most of these are not notable.Tvx1 17:25, 7 March 2023 (UTC)[reply]
The proposal is not get mass rid of them. It’s to move them to an appropriate place to dustinguish the non-notable ones from the one which are and actually make the keepable ones encyclopedic. No one is requesting blind deletion here. Tvx1 17:27, 7 March 2023 (UTC)[reply]
Garnett Wikoff: Another clearly notable article from this list that I was able to substantially expand. BeanieFan11 (talk) 20:22, 3 March 2023 (UTC)[reply]
Another one who has potential for notability: William Valentine (archer) – per Olympedia, he was an owner of a pharmacy for a while and trained Charles Walgreen – the founder of Walgreen's! It was partly because of him the business was founded! BeanieFan11 (talk) 22:25, 3 March 2023 (UTC)[reply]
Another interesting one: George Retzer. He lived to be 96 and was still regularly working out into his mid-90s (50 situps, 50 pushups every day, wow), and received UPI and LA Times feature stories for it, in addition to having more coverage for being the Pacific Coast wrestling champ. Clearly notable. Just like many others here. Mass throwing them out without any attempt to see if they're notable is an absolutely horrendous idea. BeanieFan11 (talk) 23:17, 3 March 2023 (UTC)[reply]
Yet another that seems highly likely to be notable: Iraklis Sakellaropoulos - the Greek wiki has a much more detailed article on him, he competed at three olympics, was a champion runner in Greek in the 1910s and 20s, and there seems to be a bunch of mentions of him online and in books using his name in Greek (unfortunately I do not speak Greek, so can't tell if its sigcov - but even if those aren't, I'm 99.999% sure the newspapers of the day would have covered him). BeanieFan11 (talk) 00:47, 4 March 2023 (UTC)[reply]
@Paradise Chronicle: No they're not, I've improved many of them (for example, Fred Narganes, Herbert Gidney, Garnett Wikoff, Thomas LeBoutillier, J. Nash McCrea, and others) – there's just so many that we're trying to get rid of here, I haven't been able to get to them all. As for NOTDATABASE, that does not apply. It only applies to: Summary-only descriptions of works – nope; Lyrics databases – nope; Exhaustive logs of software updates – nope; Excessive listings of unexplained statistics – nope (the statistics and events are explained; I don't see how it would fall under that). As for WHOSWHO, that one says "Even when an event is notable, individuals involved in it may not be. Unless news coverage of an individual goes beyond the context of a single event..." – for many of these coverage exists that goes beyond their Olympic appearances. BeanieFan11 (talk) 01:34, 18 March 2023 (UTC)[reply]
That's great, you found some. You can expand them from draftspace. No-one will oppose you. The sources used of the unexpanded stubs are still databases, check Antonio Pereira for example. And an OBE gives a phrase more, that's it. And they were still created ignoring the policies on WP:MEATBOT and WP:MASSCREATE as Lugnuts actually did create more than 50 articles on several days and more than 25 often and then any semiautomated or high speed editing can be considered bot like editing.Paradise Chronicle (talk) 02:18, 18 March 2023 (UTC)[reply]
I'd also support that the one who save such articles are able to voluntarily receive the same notifications the article creator does, as the expanders are likely more interested in getting aware of (potential) wls to and from the article. Paradise Chronicle (talk) 05:35, 19 March 2023 (UTC)[reply]
Oppose - This has nothing to do with articles and is just a continued harassment campaign against Lugnuts. How can you possibly judge Article A based on Article B and Article C? These articles and the people who they are written about have nothing to do with each other. Why would they ever be judged together? And this idea of an article not only having to pass current rules but also needing to pass future rules that didn't even exist is horrifying. This is not in good faith and this goes against everything this website should be. I'm absolutely disgusted by this.KatoKungLee (talk) 16:13, 3 March 2023 (UTC)[reply]
Strongest possible oppose tremendous waste of time and resources, and as I've reiterated times, there's nothing wrong with stubs. Many of these could be fleshed out and pass GNG, and many of these are useful to users. If you want to merge them to a list one by one, I wouldn't necessarily be opposed.--Ortizesp (talk) 05:28, 4 March 2023 (UTC)[reply]
The good news on the merge front is they all appear to have been included in relevant lists since 2006 to 2007. CMD (talk) 08:36, 4 March 2023 (UTC)[reply]
Support either draftification or redirection per BilledMammal. These articles can always be recreated if anyone can find sources showing their notability. (t · c) buidhe 05:43, 4 March 2023 (UTC)[reply]
Oppose. The only thing the subjects of these articles have in common are 1) they competed in the Olympics during a certain time frame 2) they were created by a certain editor. If you believe that mere documentation that someone competed in the Olympics is not sufficient to confer notability, then neither of the things these articles have in common have any bearing on the article subject's notability. That means the responsible thing to do would be to go through and determine notability for each article on an individual basis. Dealing with them in bulk is inappropriate, and would make it inevitable that some babies will be disposed of with the bathwater. —Scott5114↗[EXACT CHANGE ONLY] 06:21, 4 March 2023 (UTC)[reply]
@Scott5114: The contents of the bathwater aren't being thrown out here; they will still be available, whether in the form of a draft or a redirect.
In addition, one of the issues with dealing with them individually is that it will overload AfD. Do you, and other editors opposing this proposal on that basis, have no objection to 25, 50, or 100 of Lugnut's articles being taken through AfD each day (a process that will take between 5, 2.5, or 1.25 years, respectively, if we conservatively assume that only half of Lugnuts articles have notability issues)? BilledMammal (talk) 06:38, 4 March 2023 (UTC)[reply]
Putting them in draft space makes it less likely that anyone will ever actually improve them. I haven't the foggiest idea what's in draft space right now. And when I am using the site as a user, if I come across a redlink and think "gee, I expected Wikipedia to have an article on this," my first inclination isn't to check draft space to see if there's something that just needs to spruced up a bit. I would be very surprised if that is actually part of anyone's workflow.
If it is a long and painful process to put them through AFD then so be it; that is the pain that the nominators choose to endure themselves, and inflict on others in the process. Presumably should they choose to do so, it's because they've examined an individual article and found that it is in fact not notable, and can prove that at AFD. Circumventing the process simply because it will take more effort than some people care to do is simply cheaping out. —Scott5114↗[EXACT CHANGE ONLY] 11:31, 4 March 2023 (UTC)[reply]
Most of the proponents of dealing with these articles individually also oppose sending them en masse to AfD, since the seven-day deadline gives too little time to find sources. This is a proposal to extend that deadline by 4 years and 358 days. Those who wish to examine these articles one-by-one will have plenty of time to do so. I'd also note that all the articles covered by the proposal are extremely scanty; even if they were deleted, any one of them could be recreated with better sources in a matter of minutes. Sojourner in the earth (talk) 11:52, 4 March 2023 (UTC)[reply]
Presumably should they choose to do so, it's because they've examined an individual article and found that it is in fact not notable, and can prove that at AFD. They would be able to prove that the individual article doesn't demonstrate notability; there is no consensus that they are required to do more than this when nominating mass created articles. BilledMammal (talk) 12:05, 4 March 2023 (UTC)[reply]
Oppose. Draftspace is an invisible graveyard. It wouldn't matter if the auto-delete period was set to 50 years; approximately nobody beyond the original author ever stumbles upon a draft. Articles get improved by attracting editors, and editors get attracted as a consequence of visibility, which drafts simply do not enjoy. Therefore the practical eventual outcome of draftification would be deletion.
However, I also do not support deletion. Several editors have proposed redirection instead, and I agree that this would be better. Regardless of the possibility of (potentially deliberate) errors within the articles, I don't think anyone is doubting that these people existed and had a verifiable association with a particular event - therefore it should be possible to identify an appropriate redirection target.
Finally, I'll also mention that this whole set of articles feels like it skirts WP:COPYVIO as a potential infringement of Database rights, and for that reason I do not support doing nothing. Barnards.tar.gz (talk) 08:57, 4 March 2023 (UTC)[reply]
Support as deliberate errors had been introduced, per the evidence by Chipmunkdavis. There is no time to check it all, and it is better to have no articles than hundreds of faulty articles. I would agree that draftification would be a better option, but there is no way we should have thousands of articles that have deliberate errors on them. ✠ SunDawn ✠(contact) 12:55, 4 March 2023 (UTC)[reply]
I highly doubt that he made "thousands of articles with deliberate errors in them." I've checked many articles written by Lugnuts and only very rarely have I found errors. BeanieFan11 (talk) 21:09, 4 March 2023 (UTC)[reply]
Support, with a preference for redirection over draftification. Either way, the article histories will be preserved, and can be used if someone can find reliable sources that establish notability. (IMO, notability is a necessary, but not a sufficient, condition for an article, i.e., just because a subject is notable does not mean that Wikipedia has to have an article about the subject.) - Donald Albury 15:10, 4 March 2023 (UTC)[reply]
Support, many of these articles could be improved to pass notability, but they should not be in mainspace until this has been done. However, to increase the chances of editors improving them I suggest adding a note about drafts to the tasks/to-do lists of the relevant wikiprojects (olympics/fencing/swimming…) with a link to the "other" section in their article assessment page. EdwardUK (talk) 15:49, 4 March 2023 (UTC)[reply]
Support There are to many articles that are only notable because of topic specific notability rules. Such rules only serve to formalize the systemic bias of Wikipedia. My general preference is that WP:GNG replace all topic specific notability guidelines. I recognize that is unlikely to reach a consensus, but I fell this is a step on the right direction. — BillHPike (talk, contribs) 20:01, 4 March 2023 (UTC)[reply]
These aren't notable per topic specific notability guidlines. But many are notable through GNG. BeanieFan11 (talk) 20:06, 4 March 2023 (UTC)[reply]
Strong oppose mass deletions without a detailed look are never a good thing, especially when a lot of the articles likely are in fact notable. Draftifying them is a poor choice, because that makes them hard to find (and therefore, interested editors won’t find and work on them), and just results in a shortcut to deletion. There’s nothing wrong with stubs - in fact, for the same reason, I’d argue having a stub encourages people to expand it more than not having an article at all does. Anything that is truly not notable can be deleted via the standard AfD process, which the village pump is not an appropriate substitute for. Deletion of notable material is not an acceptable side effect. Claims of “it can always be recreated later” are not useful: any recreated articles will likely be rapidly sent to AfD and deleted before someone interested happens to see it and dig up some appropriate sources. Frankly, I’m a little bothered at the very high notability standard that seems to be set these days, as it encourages a perception that the encyclopedia is complete and new contributions aren’t welcome. A lot of us treat Wikipedia as the one-stop shop to learn something, an image that’s taken 20 years to cultivate. It’s going to lose that if it keeps going this direction. Obviously there has to be some kind of notability standard, or else everyone and their dog would have their own article, but accurate content should be a far greater priority. Highway 89 (talk) 21:33, 4 March 2023 (UTC)[reply]
If accurate content should be the priority, then mass-creating articles without spending time to ensure accuracy seems a detriment. CMD (talk) 02:15, 5 March 2023 (UTC)[reply]
So where was the "detailed look" when these were mass-created? Don't applying standards in just one direction. Reywas92Talk 23:02, 3 April 2023 (UTC)[reply]
Support That way, they can stop cluttering mainspace while people prepare them in draftspace. QuicoleJR (talk) 23:56, 4 March 2023 (UTC)[reply]
I don't see how they are cluttering mainspace, it's not like people fall on these pages accidentally. Ortizesp (talk) 00:27, 5 March 2023 (UTC)[reply]
Just to clear up a common misperception, there is no way to clutter up Wikipedia mainspace because, given the right computer tech, Wikipedia can fit on the head of a pin. Randy Kryn (talk) 01:46, 12 March 2023 (UTC)[reply]
Oppose - per others who note that draftification as a backdoor deletion is inappropriate, and a better solution (as offered above) is to redirect these to the appropriate Olympic games. Rlendog (talk) 02:02, 5 March 2023 (UTC)[reply]
Support-ish. After reading Lugnut's final goodbye post where he admitted to leaving false statements in article for years, I can't see how we can leave these stubs in article space. I also don't think we need to spend countless hours to check each one. I would prefer deletion, and if not, then a normal 6 months draft. Regardless, redirects from the person to a relevant article is always helpful and I would support mass redirect (but not with the same content deleted, that invites reverting the redirect and leaving the bad content there). --Gonnym (talk) 22:10, 5 March 2023 (UTC)[reply]
I highly doubt that was true (about the false statements). Having known Lugnuts when he was still here and having checked many of his creations, I very highly doubt that his final statement was true; it was likely just made to piss off all of those who did not like him. BeanieFan11 (talk) 23:35, 5 March 2023 (UTC)[reply]
Another reason why this proposal is a terrible idea: John Hession. Hession received TONS of coverage (so much that I was originally going to expand it, but was so overwhelmed by the amount of coverage that I thought it'd be better to save others and then afterwards expand him) and was described by some as the greatest shooter of all time. We should not be blindly getting rid of these, especially since many of them received sigcov and some of them received coverage calling them the greatest in their sport ever! BeanieFan11 (talk) 00:17, 6 March 2023 (UTC)[reply]
You will have 5 years to work on them from Draftspace, they aren't disappearing. If anything, your comment reinforces why draftification is the optimal choice here. As for your claims about Hassion and the "greatest shooter", that is a wee bit of hyperbole. You're basing that on a title of an obituary which itself uses the vague verbiage of "some claim". Zaathras (talk) 00:51, 6 March 2023 (UTC)[reply]
But when a high percentage are notable, it makes no sense to send them to draftspace! I would much prefer not to spend the next five years of my life expanding articles on Olympians or they all get deleted! (and additionally, if this passes, BilledMammal is going to do the same with the other 90,000) As for Hession, he won many world titles, set many world records, won national championships and won records in them, etc., so I think while he might not be the best, he's still one of the best. We should not be blindly getting rid of all these! BeanieFan11 (talk) 01:16, 6 March 2023 (UTC)[reply]
Support -- seems like a well-thought-out solution to a complex problem. Renata•3 02:22, 6 March 2023 (UTC)[reply]
Huge Oppose this is exactly the thing Wikipedia shouldn't be doing. This should be handled case-by-case and we should never just wily-nily dratify them en-masse. They certainly aren't hurting anyone by being there and as we come across them we can re-check gng to see which are worthy and which are not. Fyunck(click) (talk) 05:02, 6 March 2023 (UTC)[reply]
Oppose I agree that something ought to be done about this subset of articles. Draftification is the wrong way to tidy this up. If we agree that these stubs should not retained, then let us redirect them to the appropriate article. There is nothing to be gained from moving the articles to draft space; it would be a disservice to our readers. Why should a reader looking for an early Olympian not find a result? Draftification would create holes. Redirects would lead the reader to an article where they can find out about the person. Draftification leaves behind red links elsewhere. Creating redirects does not have that problem. Draftification is fraught with problems and should not be pursued. Schwede66 05:07, 6 March 2023 (UTC)[reply]
Support If any of these people pass the GNG, editors can expand them and provide proper sourcing. If they can't they will be deleted in 6 months. --In actu (Guerillero)Parlez Moi 07:41, 6 March 2023 (UTC)[reply]
I also don't expect people to discuss every removal with me. I have no objection to people removing articles when they provide sources that plausibly meet WP:GNG or to editors removing articles after providing just one source if that source is extensive. My objection is to you repeatedly reinstating removals that don't meet these criteria. BilledMammal (talk) 16:17, 6 March 2023 (UTC)[reply]
Strong Oppose As someone already said it takes time to write things, while deleting them is easy. Wikipedia is not finished and there is no deadline. Those articles have basically nothing in common except they were written by the same editor (which is irrelevant), so binding them all together without any BEFORE and without any actual demonstration that these articles are not notable is not appropriate and this is also not the place for such discussions. They should be taken to Afd individually, if you have some concerns. Someone commented that deleting them this way would take min. 8 (or even 30) years, but then you expect people to rewrite them in 5????? I believe it is more than obvious to everyone that this proposal of draftifying is actually a backdoor proposal to deletion, which is basically gaming the system. I am strongly against massive deletion of so many sports articles and the eradicating of so much olympic knowledge, that is very useful to us readers (those who are not interested only in most commercialised superstar champions of the present days) and that is not doing any harm whatsoever. Furthermore (and what actually made me write this comment after a long time of just reading) it was clearly stated that if this proposal succeeds, this anti-sports modern book-burning crusade will continue with massive deletions of other athletes (post 1912), which I again find very worrying and utterly un-encyclopedic. I know I will achieve nothing but I simply had to write this. — Preceding unsigned comment added by 176.76.250.241 (talk) 18:44, 6 March 2023 (UTC)[reply]
Nothing in common? Takes time to write? Have you looked at the articles? They're carbon copies with some variables that differ per page. Assuming they weren't automated, they took probably a minute or two each at most. CMD (talk) 04:31, 7 March 2023 (UTC)[reply]
Oppose as articles that meet SIGCOV are being kept in the proposal. If the SIGCOV articles are removed, I would be Neutral on the proposal - clearly we can't have a ton of permanent stub articles with little to no notability, but I'm not sure userficiation is the right idea. Redirects seem far more helpful. ToaNidhiki05 14:10, 7 March 2023 (UTC)[reply]
Agree with Mistral. For this reason, I originally supported but BilledMammal is refusing to allow amendment of the list to remove articles like Roland Spitzer and Edward Greene (sport shooter) even though they have been expanded, now include SIGCOV, and are not based solely on database entry. IMO the extreme remedy of mass removal of articles should not be considered for articles that fall into a gray area. Such articles, if challenged, should be dealt with under regular order, by normal AfD processes. BilledMammal's refusal to allow amendment of the list renders this proposal objectionable IMO. Cbl62 (talk) 14:20, 7 March 2023 (UTC)[reply]
It is standard practice to not edit RfC statement content after RfCs are opened, especially after there have already been comments. It is best practice to not edit content currently under an RfC. Fine to oppose, but it seems unfair to blame BilledMammal for following WP:RFC. CMD (talk) 14:38, 7 March 2023 (UTC)[reply]
Disagree. BilledMammal initially said he would agree to allow amendments to the list, but then threatened me at my talk page saying it was a violation of WP:TPA for me to remove two that had been amended. He said he would only allow amendments if he approved in advance. He has refused to give his OK to removal of articles like Roland Spitzer and Edward Greene (sport shooter) which are now clearly out of scope. I initially supported the proposal but such extraordinary mass removal should be limited to the most extreme cases with zero SIGCOV and only database sources. Cases like Roland Spitzer and Edward Greene (sport shooter) should be challenged, if at all, only under regular order. Cbl62 (talk) 15:05, 7 March 2023 (UTC)[reply]
I'm not following on what exactly you disagree on. The standard practice? Obtaining consensus seems to be a good way to work within the RfC guidance. CMD (talk) 15:50, 7 March 2023 (UTC)[reply]
I disagree with not striking entries from the list that no longer fit the scope of the proposal. The proposal was to remove from Main space Lugnuts' early Olympic articles that lacked SIGCOV and were based solely on databases. That scope seemed reasonable, and I supported it. Consistent with that scope, BilledMammal initially invited users to strike individual entries that no longer met that scope. He then reversed course when BeanieFan (an editor with whom BilledMammal has a history of disputes) improved a couple articles and struck them. By reversing course, BilledMammal has changed the initial nature of the proposal and is now insisting on including articles that are out of scope. That's what I disagree with. Cbl62 (talk) 16:47, 7 March 2023 (UTC)[reply]
Thanks, although I don't think I said the point you are disagreeing with in my comment. At any rate, the risk of contention that you describe is exactly why the WP:RFC page suggests not doing exactly what BeanieFan is doing. CMD (talk) 17:28, 7 March 2023 (UTC)[reply]
Conditional support - The proposal is a good way to separate the wheat from the chaff. No direct deletion and a fair opportunity to turn the stubs that are keepable into encyclopedic articles. However, five years is way too long not to autodelete. That really should be just one year or two years at the very most.Tvx1 21:01, 7 March 2023 (UTC)[reply]
Support, no preference for redirects or draftification. If the article is draftified or deleted and it actually has sources that meet GNG, it can be improved or recreated as a proper article and not a 1 or 2 sentence stub sourced to a database. Sennecaster (Chat) 04:16, 8 March 2023 (UTC)[reply]
Support. If anything, the proposal should be even broader. As the RFC notes, Lugnuts does not deserve "Assume good faith" and even to the extent that the articles are not inaccurate, they are largely woefully undersourced - if someone attempted to get such a shoddily sourced article past AFC, it would never pass. I have no objection to saving articles which is why a 5-year moratorium on deleting drafts is good, but I don't see that as relevant to this RFC - if there are articles in the list that genuine SIGCOV has been found since (note that some of the examples above are still rather shaky), whatever, it just either won't be draftified or can be moved back to the mainspace immediately, and it can go through normal AFD if desired. SnowFire (talk) 06:48, 8 March 2023 (UTC)[reply]
Support. I see this proposal and the "just redirect instead" as equivalent in all but name, so putting my support here. I am in favour of either/both of just draftifying or dradftify-and-redirect, with a mild preference towards the latter. I actually prefer draftifying for a much shorter period of time than 5 years, potentially the standard 6 months (?) of Draftspace simply because I do not think 5 years is a reasonable amount of time, and the articles that ought to be deleted would instead just linger in draftspace for years until they're eventually deleted long after being forgotten. I'd rather have a concerted effort and save whatever articles can be saved, failing which they should ideally be put under the same scrutiny and procedures as the rest of Wikipedia. Being created by a prolific admin should not grant 5 years of "free Draftspace stay" compared to other articles. Soni (talk) 08:02, 8 March 2023 (UTC)[reply]
Oppose the only problem that's been identified with these articles is that the subjects may not pass the sports notability guidelines. I don't think that's nearly a big enough deal to warrant something like this. Mass deletion/draftification is reasonable if there are more serious problems with the content, such as copyright violations, hoaxes and the like, but notability guidelines are not that big a deal. Hut 8.5 08:50, 8 March 2023 (UTC)[reply]
Other problems have been identified, they are mentioned in a couple of places in this discusison. CMD (talk) 10:43, 8 March 2023 (UTC)[reply]
Like what? I shouldn't have to read an entire 13,000 word discussion to see the rationale for this. The proposer only mentions the notability guidelines or logistical problems related to enforcing them, as do the vast majority of the comments in support. Hut 8.5 12:55, 8 March 2023 (UTC)[reply]
Hut 8.5 - Except for lack of notability? Accuracy is the main one. Lugnuts admitted to purposefully putting inaccuracies into his articles, and whilst there's those who think he was lying about that, it's also inarguable that he made a lot of mistakes when filing in those article-templates at one-a-minute - more than a few of his articles have turned out not to even have the correct name. WP:MASSCREATE violation is another additional reason.
However, the lack of notability issue is enough by itself for these articles to be dealt with as that's a DELREASON. FOARP (talk) 13:16, 8 March 2023 (UTC)[reply]
If you don't think that articles by this person can be trusted then we should be considering deleting all of them, not just Olympic athletes from a certain period. (FWIW that comment sounds like trolling from someone who's just been indef blocked and I wouldn't read too much into it.) The only distinguishing feature about these ones is the sports notability guidelines, which seems to be the main rationale for this. While lack of notability is a valid reason to delete something under the deletion policy, you are proposing to ignore the deletion policy with respect to these articles. I don't think mere failure to follow the notability guidelines is enough for such a drastic step. I would expect to see a bigger problem, preferably one which is grounded in a policy rather than a guideline. Hut 8.5 17:47, 8 March 2023 (UTC)[reply]
Of course it didn’t. That searched for copyright violations, not inaccuracies. Tvx1 20:18, 9 March 2023 (UTC)[reply]
Some of the comments in that investigation explicitly referred to looking for inaccuracies, though not all of them. As I said, it's just a data point. isaacl (talk) 16:27, 26 March 2023 (UTC)[reply]
Support in the cases of those that are just regurgitation of database entries. Oppose for the few that have been expanded to be more encyclopedic. WP:NOT a database or an indiscriminate collection of information. — SMcCandlish☏¢ 😼 23:46, 8 March 2023 (UTC)[reply]
Support I've got to say, I've always hated the low bar set for including sports figures here. (Do we still have the article about the ball player with no name? Moving on). That said, I cannot favor mass deletion at this point. The 5 yr limited draftification seems to be the solution to an extraordinary problem. Extraordinary problems require extraordinary solutions. A clear case of the need to Ignore All Rules on a massive scale. I would hope that this process could somehow be automated and perhaps a database/index of these article drafts could be made accessible for those who would want to avail themselves of it. Also, another thought: Is it technically possible to symbolize (mark unobtrusively) red links that have articles in DraftSpace? Regards, GenQuest"scribble" 01:26, 9 March 2023 (UTC)[reply]
Support per Snowfire. Ealdgyth (talk) 13:00, 9 March 2023 (UTC)[reply]
Qualified Support I'd much rather see these articles redirected and even thought of opposing this, but ultimately I feel that something needs to be done. So if the alternative to redirect doesn't happen this has my weak support. The reason this has less support from me is that draft imposes time limits and requires moves. -- LCU ActivelyDisinterested∆transmissions∆ °co-ords° 22:28, 9 March 2023 (UTC)[reply]
Ambivalent, leaning oppose. This proposal really seems like draftifying as a backdoor to deletion, which is against policy, and I think it's fairly harmless to have a bunch of borderline-notable stubs lying around. People can always PROD them as needed. I am concerned about the inaccuracies reported above, but I spot-checked a few articles and they seemed to match the sources. I'm also concerned about the WP:TRAINWRECK concerns mentioned by some participants who say that some of the articles listed pass WP:GNG. It's an unfortunate situation, but dealing with the articles on a case-by-case basis (PROD, redirect, or expand as appropriate) may be best. —Mx. Granger (talk·contribs) 19:05, 10 March 2023 (UTC)[reply]
@Mx. Granger: People can always PROD them as needed ... dealing with the articles on a case-by-case basis (PROD, redirect, or expand as appropriate) may be best. In your view, how many can I PROD or redirect in one day without being disruptive? Levivich (talk) 19:14, 10 March 2023 (UTC)[reply]
That's a good question. It's not realistic to expect people to deal with hundreds of PRODs in the same topic area all at the same time. Given the special circumstances, I think it would be reasonable to PROD 5 or 10 a day or maybe more (though under normal circumstances that would be a lot for one topic area). Redirecting is easier to undo than deletion, so that could probably be done at a higher rate without being disruptive. But I realize the list might take weeks or months to get through at that rate. Hence my ambivalence – I don't really see a good solution, so I'm not sure what the best approach is. —Mx. Granger (talk·contribs) 19:38, 10 March 2023 (UTC)[reply]
Not weeks or months, years. 93,000 Lugnuts stubs, the ones listed here are less than 1% of the total. At 10 a day, we're talking 90 days for 900 articles, plus AFDing the removed PRODs (or some of them), so it'll extend beyond 90 days. Now, I know people will say, well not all 93,000 Lugnuts stubs need to be dealt with at all, some are good. That's true. We don't know how many. But even if a mere 10% are bad -- 9,000 articles -- PRODing 10 a day would take 3 years. And if it's higher than 10%, if it's 50% bad, then we're talking over a decade to PROD them all. To go through them case-by-case is totally impossible, in my view. It must be done by batch processing, because of the number. They were created by batch processing, so I don't feel bad about not going through them one by one, but I feel a lot better about it when I realize that it's functionally impossible to get through 10,000 articles or more, one by one. Levivich (talk) 19:45, 10 March 2023 (UTC)[reply]
Support Depicting my opposition to mass article creation, microstubs are not a value-add to the encyclopedia. Chris Troutman (talk) 15:21, 11 March 2023 (UTC)[reply]
Support: Wikipedia is not a sports database and many of these people will not be notable. The efforts of those who have expanded articles under this scope is appreciated, but it is not clear why this is made easier by having an existing sub-stub article rather than directly using the two website sources to write something from scratch. You could even keep an outline of the wikitext in userspace or start by copying a similar article. If it took minutes for Lugnuts to create then it takes minutes to re-create, not much overhead. I am persuaded against redirection by FOARP and I believe that it would fall afoul of WP:R#DELETE#1 and #2, by indiscriminately redirecting many common names with more notable targets to very brief mentions (if any) of very obscure sportspeople that no-one would be using the search function to discover anyway. — Bilorv (talk) 22:26, 11 March 2023 (UTC)[reply]
Oppose per Rhododendrites. I suggest AfD-ing the worst 5%, and then review. —SmokeyJoe (talk) 23:02, 11 March 2023 (UTC)[reply]
I guess that merging possibilities are poorly considered. SmokeyJoe (talk) 23:04, 11 March 2023 (UTC)[reply]
What would we merge? And plenty of these microstubs have been AfD'd and deleted or redirected...in the past 11 months we've had 214 bios of Olympians and 75% of them have been deleted (71), redirected (88), or merged (2), and that's including a lot that don't meet the criteria for this list (and so would be expected to have a greater chance of being kept). Why should the community have to spend 2.5 more months reviewing 50 AfDs (using the archive average of 19/month, which a lot of people complained was too high) just to arrive at the same conclusion: we have way too many non-notable Olympian stubs? JoelleJay (talk) 00:51, 12 March 2023 (UTC)[reply]
What would we merge? Any proposal to delete, even 5-year slow delete, should require the proponent to explain what merging is not possible. For William Horschke, for example, why not merge all USA participants to USA at the 1904 Summer Olympics? I agree that the article creator should have asked this question.
Plenty have been AfD-ed? I didn’t know that. Was it stated upfront? It would be helpful, it is what I was asking for. This data would change my mind, if the were all deleted. But they mostly weren’t. Looking at Wikipedia:WikiProject Deletion sorting/Olympics/archive, a minority were deleted, and almost none were draftified which makes draftification and odd proposal here. “Redirect” looks to be a prominent outcome. Assuming that a redirect implies that the subject is mentioned at the target for having done something, I consider that similar to a merge of a stub. Redirection, with optional merge, is something that could be done without special authorisation by RfC. SmokeyJoe (talk) 06:49, 12 March 2023 (UTC)[reply]
So far as I can tell, all of these individuals are already mentioned in the relevant Event at the X Olympic lists. If that is the merge needed, then it is already done. CMD (talk) 08:28, 12 March 2023 (UTC)[reply]
A far smaller minority were kept and the merge rate is negligible, which supports the reality that these subjects are not notable. The proposal to draftify for five years is simply to address claims that 7 days at AfD or 6 months in draftspace is "too short" to find refs, and mass redirection poses its own issues as described below. JoelleJay (talk) 13:55, 12 March 2023 (UTC)[reply]
I accept that “keep” or “do nothing” not good solutions. I would prefer mass redirection to deletion or draftification, the first per policy WP:ATD-R, and the second because draftspace should not be used as purgatory, because draftification should only be used for pages that are envisioned to be returned to mainspace, and this clearly will not be the case. Redirection allow easy bold editing should new sourced material be found. Unjustified reversions of redirects should be responded to promptly by AfD, with consideration of sanctions due to disruptive editing if the reverts were done en mass. SmokeyJoe (talk) 10:24, 13 March 2023 (UTC)[reply]
The issues people have brought up with redirection are 1) not all subjects have a suitable redirect (e.g multiple Olympics) and 2) redirecting wholesale brings up issues with names shared with other mentioned-but-pageless people. JoelleJay (talk) 16:22, 13 March 2023 (UTC)[reply]
(1) Any person who has participated in multiple Olympics is quite a step above the typical example, and their article should be Kept, of AfD-ed. If it is in anyway complicated, there is need for discussion, and with deletion or pseudodeletion on the cards, AfD should be used for that discussion.
(2) So, why not WP:Move to an unambiguous title before redirecting? The current excessively minimalist titling practice doesn’t apply to redirects. SmokeyJoe (talk) 00:43, 14 March 2023 (UTC)[reply]
Several articles[1][2] on multi-Olympians have been deleted due to failing the requirement for SIGCOV. JoelleJay (talk) 02:31, 14 March 2023 (UTC)[reply]
Support mass automated deletion or userification, both in this case and as a general solution where anyone mass-creates articles and and any discussions (before or afterwards) that occur fail to produce an affirmative consensus supporting their creation or retention. The ArbCom case showed that Lugnuts' judgement when creating articles is not good; and the listed sources look like raw databases, which likely do not pass WP:RS in all the places where Lugnuts used them, failing the GNG. Redirection, as some people have suggested above, is not reasonable because we can't verify that these articles are actually appropriate for the target they would be redirected to (or that they reflect any sort of reality at all, given the terrible sourcing); nor is it reasonable that people spend several times the amount of time and effort Lugnuts spent spamming out these to "review" them. Anyone who believes there are individual articles worth salvaging has had ample time to do so. If people believe the database entries that were indiscriminately dumped into Wikipedia here can be turned into valid articles, the WP:BURDEN is on them to produce proper sources for them, and the WP:ONUS is on them to demonstrate a consensus supporting it - arguing that article-shaped-objects that were mass-produced in mere weeks or days must consume months or even years of the community's time to clean up is unworkable. A mass-edit that was done with one press of a button, with no discussion or effort to seek consensus, should not be so drastically more difficult to review and reverse. --Aquillion (talk) 04:53, 12 March 2023 (UTC)[reply]
Strong Oppose I prefer the redirect option if there the community determines a problem exists. I am not convinced that a problem actually exists as Rhododendrites says in point 3 above ("There's zero exigency here"). This proposal appears to be a way to avoid a formal community discussion on how to resolve the question about how to handle mass nominations at Articles for Deletion. There are some things to like about the proposal, such as long term draft space, but in my mind, any mass nomination process should involve a group of uninvolved editors to review the nominated articles prior to beginning the AfD process. --Enos733 (talk) 17:51, 12 March 2023 (UTC)[reply]
This proposal appears to be a way to avoid a formal community discussion on how to resolve the question about how to handle mass nominations at Articles for Deletion. Please explain this theory. Levivich (talk) 18:01, 12 March 2023 (UTC)[reply]
This is mentioned in the background section of this proposal. I believe the proposer wants to suggest "a method for resolving this question, with a group of articles that can be used to test the proposed resolution." To me the way forward would be to continue the discussion and evaluate the proposals articulated at WP:Arbitration Committee/Requests for comment/AfD at scale before launching a test. - Enos733 (talk) 19:03, 12 March 2023 (UTC)[reply]
Yeah, I wrote that sentence :-) This RFC is a formal discussion on how to resolve the question (or, at least, a question) about how to handle mass nominations at AFD, and it proposes a method for avoiding mass nominations at AFD for articles that meet a certain criteria. I understand preferring redirects, or believing that these can just be left in mainspace as is, but I don't understand how an RFC avoids an RFC. Levivich (talk) 19:23, 12 March 2023 (UTC)[reply]
To me this is a little bit of forum shopping, as a discussion was happening elsewhere (and yes I understood it stalled). I would rather see a more complete proposal, rather than an ad hoc test. - Enos733 (talk) 20:04, 12 March 2023 (UTC)[reply]
That's a lot easier to say than do. Levivich (talk) 20:09, 12 March 2023 (UTC)[reply]
The discussion wasn’t just stalled, it was cancelled by ArbCom. BilledMammal (talk) 02:26, 13 March 2023 (UTC)[reply]
Support Junk the lot. Virtually useless to man and beast. Complete anathama to everything Wikipedia is trying to achieve. scope_creepTalk 16:09, 13 March 2023 (UTC)[reply]
Comment Seems kind of silly when we change the notability criteria then have to do mass deletions. Now we only consider GNG or SPORTS rather than anyone who's competed in the Olympics. Oaktree b (talk) 20:04, 14 March 2023 (UTC)[reply]
Support Draftifying this many articles is pointless; just delete them. They can be re-created when sources show up. Cleaning the cobwebs out of wikipedia is important. Still seems silly to have changed the notability criteria, but here we are. Oaktree b (talk) 20:04, 14 March 2023 (UTC)[reply]
Support draftification or redirection. Either one works. If the only references given are a database source, then they aren't even giving a presumption of notability, particularly since they aren't even medalists. Any that have been expanded or otherwise had proper sources added can just be moved back to mainspace after draftification by the editors who made the improvements. Considering this could have instead been a proposal to delete them all, which would have been valid due to the requirement for all sports biographies to meet the WP:GNG, I think draftification is getting off light, particularly with the special extended time period consideration given here. SilverserenC 00:35, 15 March 2023 (UTC)[reply]
Oppose per NOTPAPER and, more importantly, NTEMP: if we remove what cannot be easily added to today, we skew the balance inexorably towards recentism. Kevin McE (talk) 08:08, 15 March 2023 (UTC)[reply]
Strongest support ever Let's consider the options.
Doing nothing - It should be clear by the discussion reasons that the articles can't stay the way they are. We have to do something.
Drafts - The extended autodeletion means it's not a deletion backdoor, and draftifying them is our best bet. While some people say no one will improve them, I think the people discussing have the village pump watched, and will most likely go to the draft space to improve the articles if the proposal passes.
Redirect - To what? And also, no one will search them, so it won't help the encyclopedia at all.
AfD - That will increase the workload, and there will only be 7 days to find notability, as oppose to 5 years if the proposal passes. Such AfDs will most likely be delete, so why discuss it instead of discussing something actually meaningful to discuss?
Support based on evidence of low page views dictating that drafting articles will have minimal impact. Cherry-picked examples of articles that have proven their notability with improved references would be returned to mainspace as users search for such athletes, recovering the minimal bycatch BluePenguin18 🐧 ( 💬 ) 03:16, 17 March 2023 (UTC)[reply]
Support There are several existing wikipedia rules that would have prevented their creation if they had been enforced. (detailed reasoning comes later).Paradise Chronicle (talk) 06:26, 17 March 2023 (UTC)[reply]
Reconfirm support and also to discourage future mass creation of stubs. The Lugnuts stubs were created ignoring the policies of WP:MASSCREATION, WP:MEATBOT or WP:BOTUSE. Those are policies and should have been enforced. Most of the articles were not edited considerably by other editors except for Lugnuts and draftifying them would still provide potential expanders with 5 years time to expand the articles. Paradise Chronicle (talk) 03:16, 18 March 2023 (UTC)[reply]
Oppose This has been shown to be a test case in deleting most of the 90,000 stubs created by an editor. I would be open to a separate proposal to redirect some of these to the nation's teams. A delayed deletion is not the only way to handle this issue. A dedicated group of 20 to 100 could fix these articles in a reasonable amount of time. Abzeronow (talk) 19:20, 20 March 2023 (UTC)[reply]
So your proposed “fix” for this is that a substantial percentage of the actually-active editors of EN Wikipedia (a 2017 study showed nearly all articles were written by about ~1,300 editors) dedicate months/years of time to fix the problems entirely created by a single editor?
Yeah, no.
But even if this is the way to fix it this proposal doesn’t prevent this from happening? The articles can still be fixed in draftspace if people wish to do that? FOARP (talk) 08:23, 21 March 2023 (UTC)[reply]
Support for the love of god please. I've come across so many of these stubs of sportspeople created by Lugnuts that have zero claims of notability besides the criteria of being an olympian. Sportspeople is an area where we ought to be more strict practicing the notability guideline. Database entries do not count to notability. SWinxy (talk) 04:14, 26 March 2023 (UTC)[reply]
I would also prefer deleting them outright FWIW. SWinxy (talk) 01:16, 27 March 2023 (UTC)[reply]
Support, per FOARP. This is a reasonably pragmatic compromise that addresses the fact that many of these "articles" are potentially not even accurate, let alone notable. Even if the Lugnuts sabotage admission is untrue, other editors in this RfC have detected errors that – in my mind at least – call into question the reliability of the datasets used to create these stubs. I further agree with FOARP that an approach similar to this should be taken with regards to many other mass-created stubs that have little hope of satisfying the GNG or becoming reasonably-substantial articles, and that leaving said articles alone – or trying to mud-wrestle over a few of them at a time at AfD – legitimises using fait accompli as a work-around for the burden of establishing notability and reliable sourcing. Protestations such as those from BeanieFan11 are not at all compelling: they argue at one moment that [the] majority [of the stubs concerned] I would say could be expanded if the right sources were used, it just takes time to write things, then at the next admit that nobody actually wants to do that work of expanding them (I doubt that there's going to be a ton of eager editors who want to help out in writing articles on 1900/10s Olympians), thus undermining their own suggestion that an Olympic stub cleanup project be created as an alternative to the headline proposal. Similarly from Abzeronow just above me here; [a] dedicated group of 20 to 100 could fix these articles in a reasonable amount of time. I wish them, or any and all other editors, the best if they do genuinely wish to start a Lugnuts Stubs WikiProject and set to the task of making decent articles out of these database entries – but I see zero reason as to why that work cannot be carried out over the next five years in the peace and quiet of draftspace. XAM2175(T) 12:31, 26 March 2023 (UTC)[reply]
I would further add, for the avoidance of doubt, 1) that I support the principle of the proposal and the methodology used to prepare the query, and that my support endures on those terms even if the list of articles produced by said query changes in the course of the RfC; and 2) that I oppose systematic redirection as an alternate proposal on the grounds that there is no clear methodology for selecting appropriate targets for redirection. XAM2175(T) 12:36, 26 March 2023 (UTC)[reply]
Support I find the "articles shouldn't have to satisfy Wikipedia standarads" argument extremely amusing. ~~ AirshipJungleman29 (talk) 14:43, 29 March 2023 (UTC)[reply]
Support Per XAM2175. This gives people an option to sort the wheat from the chaff while also keeping most of the chaff out of article space. -Indy beetle (talk) 23:03, 29 March 2023 (UTC)[reply]
Support redirecting, Neutral on draftifying. Wikipedia isn't a burocracy, so I don't think its a problem to do this process here instead of AfD if enough editors come to a disagreement. Different room, same discussion. — PerfectSoundWhatever (t; c) 20:01, 2 April 2023 (UTC)[reply]
Support It is clear that these articles should never have been created. There is no reasonable expectation of notability: Participation in the early Olympics was often who could attend, not who had already shown they were one of the world's best through international competitions. They violate GNG, as well NATHLETE, even before the Olympics change was made: it has always been the case that significant coverage is expected, and simple database listings are indequate. These "articles" have little to no context, merely stating their participation, which is already included in the relevant event articles. It is entirely appropriate to take bulk action such as this against low-quality mass-creation, which would be impossible to address any other way, and we should do so in many more cases, including cricket and football players and place names. If you're whining that draftifying is back-door deletion, I'm happy to fully delete! One should not be able to exempt one's articles from deletion or similar action because you made tens of thousands of such one-line litter pages. A vote to oppose is simply a middle finger to our basic concepts of notability, which call for substantive independent coverage, without exception for atheticism. No one's stopping anyone from writing actual articles or even creating redirects if they want. Reywas92Talk 23:03, 3 April 2023 (UTC)[reply]
Support Either is fine, the idea of having to patrol thens of thousands of minor articles that I'll have to check for notability sounds painful and doesn't really add anything of value. I've seen sports articles like this go both ways at AfD with people willing to die on these molehills. Dr vulpes(💬 • 📝) 04:48, 5 April 2023 (UTC)[reply]
Support. I don't see why we can't draftify the articles and then create redirects. People can work on any drafts they feel are viable without losing the info already in them, and in the meantime the redirects serve the reader looking for information. Valereee (talk) 11:48, 7 April 2023 (UTC)[reply]
Oppose. As others have noted, draftification (especially mass draftification) is simply a backdoor version of deletion, which is an extreme remedy that should be reserved for content that is demonstrably harmful to the project. This proposal is without any proper basis unless there is some reason to believe that these articles are in any way harmful to the project or its users. -- Visviva (talk) 02:36, 10 April 2023 (UTC)[reply]
Oppose, not so much because I care about these Olympian sub-stubs, but because I do care about WP:CREEP and about not expanding the already-problematic process of using draftification as a way of getting rid of articles for which there is no immediate prospect of active improvement and resubmission. Regardless of whether the gotten-rid-of-articles are deleted from draftspace or just left there to molder forever, they have been eliminated out-of-process as Wikipedia content, debasing both our proper deletion processes and our proper use of draftspace to foster drafts. —David Eppstein (talk) 05:59, 11 April 2023 (UTC)[reply]
Oppose I think I am just repeating others above, but in my own words -
These pass special notability criteria that we have for historical biographies. We are talking about 1000 articles and that number will not grow. For this and other records starting in the Industrial Age like military awards with no other info, we give a pass to scant biographies. Wikipedia has the space, and sometimes we compromise on content qualtiy to keep our inclusion rules uniform and easy to understand. We routinely keep Olympians now; it makes sense to me that we would want completeness in our set.
I do support alternative forms of presentation, like migrating these into related lists. I recognize that readers may not want individual one-line biographies, but it is more likely that they would want sports records from the era. If someone has a clever way to keep and combine biographies, then I favor that over keeping individual articles.
Two things are happening in this discussion- the proposal to remove the articles, and also a propose to handle such content with an alternative to AfD. The AfD process gives Wikipedia a lot of stability and I push back against circumventing it. I like the idea of "draftify for 5 years, then delete if no one touched it" as a potential solution. What I do not like is proposing it ad hoc here in this discussion, rather than pointing to it as an independently documented Wikipedia process with centralized discussion. I might and probably would support the 5-year draft solution if that were a documented, reusable, community discussed process. It seems clever, but not as a one-off with no place to discuss it.
::These pass special notability criteria that we have for historical biographies. We are talking about 1000 articles and that number will not grow. For this and other records starting in the Industrial Age like military awards with no other info, we give a pass to scant biographies. Wikipedia has the space, and sometimes we compromise on content qualtiy to keep our inclusion rules uniform and easy to understand. We routinely keep Olympians now; it makes sense to me that we would want completeness in our set.
Have you been following Olympian AfDs lately? Or NSPORT in general? In the past year alone I've personally participated in/watched 150+ AfDs on Olympians that resulted in deletion/redirection because they didn't meet GNG. We don't have "special notability criteria for historical biographies", and in the case of sportspeople such a consideration was explicitly rejected: all sportsperson biographies must meet GNG and contain at least one SIGCOV SIRS demonstrating this.
I do support alternative forms of presentation, like migrating these into related lists. They already are in other lists/pages. JoelleJay (talk) 22:43, 12 April 2023 (UTC)[reply]
Weak Oppose I think redirection of most of them is, on balance, the better approach, but will support 'whatever approach we can agree to that gets these articles out of the mainspace', i.e. either is better than neither. JeffUK
Support - These articles will never meet GNG and are basically just cruft. We don't need to waste more community time debating them individually. Nosferattus (talk) 06:50, 14 April 2023 (UTC)[reply]
These articles will never meet GNG – Obviously you're wrong, as numerous have already been proven to pass it. BeanieFan11 (talk) 14:19, 14 April 2023 (UTC)[reply]
Qualified oppose First, procedurally, as I do think that while discussion can function here as well as or better than a mass AfD, hosting it here instead of there gives the air of being less "serious" and so may be more likely to produce the desired outcome. Second, also procedurally, because of the stated intent to use the outcome (apparently assuming it will be the desired?) as precedent to take the same approach with other articles. Third, I don't think the proposal has appropriately noted the different limits to sourcing for the historic period, and the recency bias that may be introduced by not encouraging article development (instead of the proposal of hiding then deleting). Fourth, and getting to the issue at hand, because while the proposal says that there are no other viable avenues of tackling the issues in these articles, it does mention that a WikiProject may "adopt" the articles to work on... this avenue has clearly not been explored. As far as I can see, such a suggestion was never made to the Olympics project. Given the work there in a semi-organised manner already to improve other Olympic bio stubs, I think this would be the best option. A qualified/limited oppose, though, because I would like to say that I think draftification with an extended deadline is preferable to redirection without discussion; redirects where appropriate are better but there will be salvagable articles and it's harder to find and work on them as redirects. Kingsif (talk) 23:52, 15 April 2023 (UTC)[reply]
Kingsif - Just on the question of venue, who, that might normally be expected to comment on an AFD related to an Olympian, has not yet already had their say here? What, that might have been said in an AFD discussion, has not already been said here? Conversely, what that has been said here would definitely not have been said in an AFD? I think the main result of having it here is simply that the discussion has been less dominated by the people who normally dominate at AFD and more eyes have been on it, but this is a good thing surely? FOARP (talk) 11:50, 17 April 2023 (UTC)[reply]
As I said, discussion can function here as well as or better than a mass AfD. But also as I said, hosting it here instead of there gives the air of being less "serious" and so may be more likely to produce the desired outcome. I do not think either point needs expansion but let me know. Kingsif (talk) 20:18, 17 April 2023 (UTC)[reply]
Oppose I see little to no benefit and many aspects of harm in this proposal, all of which have already been stated by others above. --Dweller (talk) Old fashioned is the new thing! 07:42, 18 April 2023 (UTC)[reply]
Support As other users have stated, it would be best to change these all into redirects to "[Country] at the [year] [Summer/Winter] Olympics," and make there a list of each athlete and their performance. Occidental Phantasmagoria (talk) 18:00, 20 April 2023 (UTC)[reply]
Oppose The decision should be about long term good for the encyclopedia, not revenge against an editor. For example, the evidence presented includes a list sortable by number of articles Lugnuts created that day. When deciding if article x is notable, what difference does it make if the author created 1 other article that day or 40? The decision should be based on the article subject, not the activity level of an author we no longer like on a given day.Dave (talk) 19:31, 21 April 2023 (UTC)[reply]
This is not, and was never, about revenge; it's about, and has always been about, percieved lack of notability and standards enforcement. * Pppery *it has begun... 20:47, 21 April 2023 (UTC)[reply]
Qualified Support for outright deletion (not draftification) of any remaining articles on the proposed list that remain unsourced and are now non-notable (as per WP:NSPORT). This mass deletion will still demand a manual, individual human review of each individual article prior to deletion. Also, this deletion rationale is completely independent of both the size of the proposed articles and the total number created, neither of which are relevant to their notability or possible retention. If somebody is keen to create new list articles out of these names, I would caution that they too are likely non-notable as well. Loopy30 (talk) 01:38, 22 April 2023 (UTC)[reply]
Support According to BilledMammal's draft, it's unlikely these will ever improve if left in mainspace, so the potential copyvio and inaccuracies (if we believe Lugnuts) are troubling. Ultimately, we're faced with mass-creation of stubs based solely on databases (of questionable reliability), and WP:N treats databases, even reliable ones, as poor evidence of notability. So we're likely faced with WP:DEL-REASON #2 and #6, at least. The concerns about backdoor deletion (WP:ATD-I) are easily addressed with the 5-year period, though I support tougher measures (like bringing it back to 6-months, or straight-up deleting) because there's no point in "rescuing" stubs that likely need to be fully rewritten from reliable sources (given that these databases are unreliable, per FOARP and CMD). Also agree with Cbl62's rationale. DFlhb (talk) 09:56, 29 April 2023 (UTC) edited 11:09, 29 April 2023 (UTC)[reply]
oppose draftification, support deletion. shoving these articles into drafts for them to rot for 5 years and then be ultimately deleted is a pointless endeavor. skip the 5 years, why don't ya? lettherebedarklight晚安 10:42, 29 April 2023 (UTC)[reply]
@Lettherebedarklight: While I would also support deletion, I don't think that there will be a consensus for deletion here. Would you be willing to support draftification over doing nothing, even if it is your last choice behind more final actions such as deletion, redirection, etc? BilledMammal (talk) 17:52, 29 April 2023 (UTC)[reply]
i mean, sure, that seems to be the only choice... lettherebedarklight晚安 03:16, 30 April 2023 (UTC)[reply]
Oppose - I'm of two minds: one, these articles likely fail modern notability guidelines and quite possibly have purposefully introduced errors (see this diff and comments from S Marshall above), but two, I can't help but think that the mass deletion or redirection of 1000 articles (or 93000 should people decide to propose more) is not the best way to go about resolving this. We didn't indiscriminately delete Neelix redirects and that had comparable numbers, so I don't see why this case should be any different. Make 930 pages with 100 articles each and let editors slowly run through them all, nominating any problematic ones via PROD or AFD. We could look to introduce a new CSD like we did with Neelix, too. This proposal has a timeframe of five years; it may take longer than this to manually check each article, but at least they'll actually be checked. Anarchyte (talk) 11:18, 29 April 2023 (UTC)[reply]
This proposal has a timeframe of five years; it may take longer than this to manually check each article, but at least they'll actually be checked. Will they, though? I respect the good faith inherent to proposals like this, and please excuse my cynicism, but there's absolutely nothing to suggest that anybody will take systematic action to improve these stubs without being prompted to, and figuratively telling the stubs to shape up or face get shipped out is the closest thing we have to such a prompt. There's nothing about draftifcation that prevents the making of 930 pages with 100 articles each for editors to work through, and it doesn't make working on them compulsory; it simply incentivises people to act according to their apparently very sincere belief that the stubs have potential to be policy-compliant verifiable articles on notable people. As to five years potentially not being long enough – I'm sure that, if the community see real progress being made on the work, there'll be no difficulties arranging for a suitable extension. XAM2175(T) 13:23, 29 April 2023 (UTC)[reply]
Redirect – i.e., have the articles be only slightly less accessible than drafts, without impending deletion being necessary, all whilst helping readers' navigation. J947 † edits 02:43, 30 April 2023 (UTC)[reply]
Oppose for the reasons listed above. At most, redirects seem the best approach, as then users are able to more easily navigate the encyclopedia. I see no point in deleting/draftifying the pages, as it removes the most positive component of these stubs: allowing them to come up in searches. This is why redirects seem like a reasonable compromise. I understand that the concern is that it will take a long time to go through these articles to decide whether to improve or redirect them - to which I say, so what? Wikipedia is an unending work in progress. We have all the time in the world. Why not do it right? --Nerd1a4i (talk) — Preceding undated comment added 03:02, 30 April 2023 (UTC)[reply]
Support, whether it's this proposal, outright deletion, or redirection. The status-quo is untenable, and our usual processes cannot handle the volume here. The articles were created against policy WP:MEATBOT. There is some harm to leaving non-notable articles in mainspace: it sets examples for new users who will get a frustrating experience at WP:AFC when creating similar articles. There is further harm from the fact that these articles contain (purposefully added?) inaccuracies. —Femke 🐦 (talk) 09:04, 30 April 2023 (UTC)[reply]
Oppose - We should be raising awareness about these stubs, not relegating them to forgotten drafts that'll all likely be deleted in 6 months 5 years. It's my view that Lugnuts was lying about inserting those deliberate inaccuracies, and was simply giving the finger to Wikipedia after his forced resignation from the project became inevitable. Tim O'Doherty (talk) 11:00, 30 April 2023 (UTC)[reply]
relegating them to forgotten drafts that'll all likely be deleted in 6 months ...did you read the proposal? JoelleJay (talk) 16:18, 30 April 2023 (UTC)[reply]
Oppose I fully get why this is being proposed and respect folks for trying to find a way forward. But draft space is a horrible way to deal with pretty much any problem. And to quote from above "mass deletions without a detailed look are never a good thing, especially when a lot of the articles likely are in fact notable. Draftifying them is a poor choice, because that makes them hard to find (and therefore, interested editors won’t find and work on them), and just results in a shortcut to deletion.". Hobit (talk) 23:05, 30 April 2023 (UTC)[reply]
Considering 75% of all Olympic bios (not just the microstubs here on the earliest, most under-sourced participants) at AfD are deleted or redirected, I find it extremely unlikely that "a lot" of these articles are on notable subjects. JoelleJay (talk) 23:37, 30 April 2023 (UTC)[reply]
Even if 75% of Olympians were non-notable (and I think thats not even close to true) that's still 250 notable articles we'd be getting rid of here alone. BeanieFan11 (talk) 23:41, 30 April 2023 (UTC)[reply]
You'd have five years to find them all and try to improve them, though, together with all your colleagues in the Lugnuts Stubs WikiProject! XAM2175(T) 00:17, 1 May 2023 (UTC)[reply]
But why not have them improved in mainspace, where they are several times more likely to be seen and thus improved! BeanieFan11 (talk) 00:21, 1 May 2023 (UTC)[reply]
You said so yourself: I doubt that there's going to be a ton of eager editors who want to help out in writing articles on 1900/10s Olympians. Draftication of these stubs – especially in such a high-visibility process as this – is a wonderful incentive, if you'll forgive my bluntness: improve them or lose them. XAM2175(T) 01:15, 1 May 2023 (UTC)[reply]
And there's going to be even less editors expanding them if they are moved to draftspace... There is absolutely no issue in having them in mainspace; they should stay. BeanieFan11 (talk) 01:20, 1 May 2023 (UTC)[reply]
There is no issue with having 750+ PAG-violating articles in mainspace? What is your proposal to deal with the articles that violate PAG's? BilledMammal (talk) 02:50, 1 May 2023 (UTC)[reply]
Template:No significant coverage, Template:Notability, and other maintenance tags exist for articles created lacking sigcov (which is what I assume you mean by "PAG-violating") – my proposal would be to start a project that goes through them: improving the notable ones, redirecting/PROD-ing/AFDing the non-notable ones, etc. BeanieFan11 (talk) 03:00, 1 May 2023 (UTC)[reply]
which is what I assume you mean by "PAG-violating" I also mean violating WP:NOT and WP:N. While I support you creating that project, I would oppose that as an alternative per FOARP; I don't believe it is a practical alternative, and there is no deadline to have articles on these topics. BilledMammal (talk) 03:49, 1 May 2023 (UTC)[reply]
The articles do not fail NOT (I believe you're referring to NOTDATABASE and so here's why it does not apply: it gives four different examples of what would be violating it - Summary-only descriptions of works - nope - Lyrics databases - nope - Exhaustive logs of software updates - nope - and Excessive listings of unexplained statistics - nope (most of these do not have statistics and those that do have them explained)) and many of the articles have been shown to pass WP:N. BeanieFan11 (talk) 14:14, 1 May 2023 (UTC)[reply]
there is no deadline to have articles on these topics – I could say just the same thing the opposite way – there is no rush to delete these. BeanieFan11 (talk) 14:15, 1 May 2023 (UTC)[reply]
The examples under each section are not intended to be exhaustive.JoelleJay (talk) 22:16, 1 May 2023 (UTC)[reply]
75% of Olympians taken to AfD in the last year were deemed non-notable. The bios in question here are on Olympians who are even more likely to be non-notable since they represent the earliest non-medalling competitors and their pages have not been substantially edited by anyone except Lugnuts. JoelleJay (talk) 00:51, 1 May 2023 (UTC)[reply]
Actually looking at the first ~100 AfDs on Olympians since April 2022, out of 57 athletes competing in 1936 or earlier, only 6 were kept. And of those, two were kept for meeting unrelated criteria (NARTIST and NPROF). That's at best ~11%. None of these were closed as soft delete, either. JoelleJay (talk) 01:43, 1 May 2023 (UTC)[reply]
Ok I looked at the rest of the Olympian AfDs. Out of 91 on competitors at the 1936 Olympics or earlier, 8 were kept, 1 was NC, and 1 was soft delete. That's 9%. JoelleJay (talk) 02:43, 1 May 2023 (UTC)[reply]
What if this does pass (which definitely seems possible, given the previous close), User:BeanieFan11 or some other interested party takes responsibility for the articles, and the articles are noindexed and moved without redirect to subpages in Wikipedia:WikiProject Olympics's projectspace? That way mainspace is cleansed of these potentially error-having stubs, no information or edit history is lost, draftspace retains its stated purpose, the articles can be improved / prodded / MfDed as appropriate, and there's no five-year deadline? Wikiproject Olympics can create a project page overviewing the effort, link all the pages from there, and link the overview page from their talk page banners so interested editors can find out about it?
That is already contained within the proposal; editors are empowered to move any of these articles from draft space to project space or user space. As such, if the closer sees procedural problems with moving the articles to draft space, I think what you propose, moving directly to project space, would be an appropriate way to address them - and in general, even absent procedural issues, I have no objection to it. BilledMammal (talk) 03:49, 1 May 2023 (UTC)[reply]
Oppose per @BeanieFan11. As has been stated, in practicality, the proposal here is whether we should keep or delete these articles—as draftifying would have the same effect as deletion. Unless it can be shown that all of these Olympian articles are non-notable (and that's been shown to not be true), there's no good reason to delete them en masse, instead of actually examining the individual articles. :3 F4U (they/it) 01:37, 6 May 2023 (UTC)[reply]
Support As someone working through the BLP rescue project - I highly support removing them from the namespace. I would, also, highly support mass deletion. We've used mass deletion in the past for un-referenced BLP's, I'd support extending to this use case after a reasonably sized test pool is completed. Mr.weedle (talk) 04:42, 7 May 2023 (UTC)[reply]
Oppose per David Eppstein and Hobit. LEPRICAVARK (talk) 18:59, 7 May 2023 (UTC)[reply]
Support, primarily per Levivich and JoelleJay. Looking at an arbitrary set of 10 of these (and AfDing one of them) has convinced me there is extremely little value in the articles as they exist now. This is the kind of situation that Wikipedia processes are uniquely ill-equipped for: there's probably a consensus that something should be done, but no consensus can reasonably form around a particular action, so instead they will exist in perpetuity. I think maintaining these database entries as stubs does cause sufficient harm to require addressing, and I also think draftification is a relatively conservative move that enables future AfDs, redirects, and expansions as needed. For that reason, I support the proposal. Not my preferred solution, but better than doing nothing. Suriname0 (talk) 19:02, 9 May 2023 (UTC)[reply]
@Suriname0, just a note to say that drafts cannot go to AfD. That avenue of review is closed if these articles are moved to draftspace. – bradv 03:30, 10 May 2023 (UTC)[reply]
@Bradv thanks for clarifying. WP:MFD is functionally equivalent, right? I've only participated in AfD. Suriname0 (talk) 12:13, 10 May 2023 (UTC)[reply]
@Suriname0, MfD does not evaluate drafts on notability grounds (at least not that I've ever seen). Non-notable drafts that do not meet any of the "G" speedy deletion criteria stay in draftspace until moved to mainspace or deleted under G13. – bradv 12:55, 10 May 2023 (UTC)[reply]
Comment I think the better WP:ATD is to simply redirect them to "Country at year season Olympics", as mass-draftification has been routinely rejected as being against the purpose of WP:DRAFTIFY, which clearly states that the process is not intended as a backdoor route to deletion. Curbon7 (talk) 08:32, 2 March 2023 (UTC)[reply]
Such redirects are often reverted. This specifics of this proposal are also intended to ensure that it is not being used as a backdoor route to deletion, by extending the auto-deletion period to five years, and by allowing the articles to be returned to mainspace without improvement for the purpose of redirecting them. BilledMammal (talk) 08:39, 2 March 2023 (UTC)[reply]
That discussion seems to relate to American football players, which is a topic-area with very fervent advocates. As far as I'm aware, no one is disputing the illegitimacy of Lugnuts Olympian sub-stubs. Thank you for the correction of the 5 years, I had missed that point. Curbon7 (talk) 08:45, 2 March 2023 (UTC)[reply]
It should be, there must be a bug with the query. I'll resolve it and remove any articles that don't meet the criteria from the list; thank you for bringing it to my attention. BilledMammal (talk) 09:09, 2 March 2023 (UTC)[reply]
There were two issues; the query was excluding articles with contributions <-200 bytes, and including those with >200 bytes, and the query was not considering edits made immediately before an edit by Lugnuts. I've fixed both; for the first, I've decided to continuing excluding contributions <-200 bytes rather than adding articles to the list after the RfC has been opened.
This has reduced the number of articles listed from 1,027 to 971.BilledMammal (talk) 10:07, 2 March 2023 (UTC)[reply]
Thanks, I think I found that one at the same time, on Adolf Davids. I've fixed it now; the issue there was that it wasn't properly including edits with a change tag other than reverts or undo; that diff was tagged with 616, or wikieditor. This has reduced the number of articles listed to 960. BilledMammal (talk) 11:25, 2 March 2023 (UTC)[reply]
The delete after 5 years seems like it might be annoying to do (since the drafts would have to excluded from any bots and automation that assumes drafts are G13 after 6 months), and I don't know if it's necessary unless some editors argue that there's something to be saved. Galobtter (pingó mió) 09:29, 2 March 2023 (UTC)[reply]
The other issue with the 5 year rule as currently written is what should an admin do if a human updates one of these pages 4 years 9 months after draftification but hasn't moved it in to mainspace yet? We can solve this problem by clarifying that this 5 year timer is a one time extension of WP:G13's 6 month timer and human edits after 4 years 6 months extend the timer in the normal manner. This also lets admins simply delete using WP:G13 (instead of having to cite this RFC) once the 5 year clock runs out. Iffy★Chat -- 14:47, 2 March 2023 (UTC)[reply]
My thought is that doing this subversion of G13 might be trying to square peg the round hole. Would it be worth creating a psuedo-namespace for this, similar to UBXspace? casualdejekyll 16:29, 2 March 2023 (UTC)[reply]
Objections to a separate proposal to go along with it, asking if we should mass redirect these articles? Does anyone actually object to redirecting them all (i.e. would only be satisfied if the articles were deleted)? — Rhododendritestalk \\ 16:53, 2 March 2023 (UTC)[reply]
I object to any proposal that has the concept of "them all". If you find that one of them is best dealt with by redirecting it, do that. Some may be best handled by expanding them (or leaving them for someone else with more interest in doing so to expand). Some of them may be best handled by deleting the article outright. Let PROD or AFD handle that. Some of them may be best handled via a redirect. Wikipedia has millions of stub articles. The handwringing over these is primarily about the personality that created them, not about the quality or potential of each one assessed on its own. Yes, these thousands of stubs are a lot, but far less than 1% of all stubs we have at Wikipedia, and proportionally are not that big of a deal. We don't have to do anything with the full set of them, other than approach each one as though it were any other stub we came across. --Jayron32 17:01, 2 March 2023 (UTC)[reply]
Reframing my meaning: is there anyone who supports draftification who would object to them being mass redirected? There are clearly at least a few who oppose draftification but would support redirecting. I don't doubt there are still some who would oppose either one, but redirecting seems obviously preferable to draftification. All of the arguments about redirection above assume "someone will revert". Well, if the proposal is to redirect, that becomes moot. — Rhododendritestalk \\ 17:17, 2 March 2023 (UTC)[reply]
Well, I for one wouldn't object, but I think it saves a whole lot more time to say, in this RFC, "Support #5 only", and see if that carries the day. Levivich (talk) 17:23, 2 March 2023 (UTC)[reply]
So, while I certainly don't fit in the camp you're targeting, I am going to push back on a couple of things. Each proposed alternative to deletion has its own unique problems, and none of them really satisfy all possible issues. Some people may support draftification because it preserves, in the currently viewable state, the article itself in a way that allows for people to more easily expand it. Redirection makes the initial text harder to recover. I mean, only a little if one is an experienced Wikipedia editor, but undoing a redirect and turning it back into an article does involve some rather arcane moves (available to any editor, but tricky nonetheless) that draftification does not. For many purposes, redirecting is tantamount to deletion and salting. Indeed, even deleting and leaving redlinks behind is a better solution, as a redlink at least says "here's an article that you might want to create if you can get the sources together" whereas a redirect basically says "Don't even bother". --Jayron32 17:26, 2 March 2023 (UTC)[reply]
undoing a redirect and turning it back into an article does involve some rather arcane moves (and BilledMammal's I believe it makes the articles easier to work on) - When was the last time either of you saw a newbie find a draft and improve it? Apart from the drafts that get outside attention (high-profile controversial article, canvassing, etc.), I'm not so sure I've ever seen it happen. Not in browsing on-wiki; not the new users I've worked with off-wiki. It's part of the failure of draftspace (or rather, why it failed as a collaborative space and turned into a trap for bad content): on the chance that someone goes to create a new article at the exact page name of the draft, nobody sees the notice that there's a draft, and the processes to discover drafts apart from seeing that notice are far more arcane. Way back in the early days of draftspace, I loved the idea and created a few thinking it would spark collaboration, but nobody ever edited them; to the contrary, people (experienced users, not newbies) just went ahead and started the article anew. With extremely rare exceptions, people don't discover and improve drafts. I agree it's also unlikely that someone will look in the history of an article to see the material, but it's not less likely. And really, if we're being honest, what is the value of what's there in the first place? There are two reasons I'm opposing the proposal above, and neither is because Lugnuts created a treasure trove of quality material for the ages: one is it's frustrating to see deletion-via-draftification, even with a 5-year countdown. It just doesn't do anything other than delete with a veneer of preservation. The other is the article titles should redirect, so why not keep the piddly bit of content that's there per WP:PRESERVE yada yada. — Rhododendritestalk \\ 17:57, 2 March 2023 (UTC)[reply]
When was the last time either of you saw a newbie find a draft and improve it? MY POINT EXACTLY. We shouldn't do anything with these stubs outside of the normal things we would do with a stub when we come across it during our own random wanderings through Wikipedia. Sometimes, when I find a stub, I don't do anything with it, and leave it for someone else to handle. Sometimes, I'll be like "I know enough about this, and I think this is a worthwhile project to handle" and I'll expand it. Sometimes, I'll be like "I'm not entirely sure there's enough source material to justify an article about this" and I'll search, and find out there isn't, and I'll nominate it for AFD. My entire point here is that every person in this discussion should be handling these stubs in this manner, and not fretting about what to do with them all. They'll get handled. Or maybe they won't. But we don't need to do anything special. Stubs exist. They existed before Lugnuts created this relatively small set of them here. The will continue to exist and new ones created tomorrow as well. There's no need to do anything special. Ignore them. Expand them. Delete them. Whatever you would do if you found a stub that had nothing to do with Lugnuts, you should do with each one of these. --Jayron32 18:28, 2 March 2023 (UTC)[reply]
Do any of these articles have nontrivial incoming links? —Kusma (talk) 17:50, 2 March 2023 (UTC)[reply]
This comment, and the discussion in general, seems to be full of people who believe that draftification = deletion. This proposal is explicitly NOT that and I'm not sure why people are so convinced that it is. casualdejekyll 15:01, 3 March 2023 (UTC)[reply]
Because it will result in having been a backdoor route for deletion for the majority of them. BeanieFan11 (talk) 15:04, 3 March 2023 (UTC)[reply]
why people are so convinced that it is - For the reasons I wrote above (and below, and elsewhere). The usefulness of draftspace, to the extent there ever was any, was eroded through a series of RfCs maybe 5-6 years ago which turned it into a bad content trap. Even before then, it was very rarely used for collaboration or article discovery, at least in part because it was never adequately integrated into our technical systems and editing norms. It had potential, but now it's limited to trapping spam/cruft/attack pages/nonsense. It may be useful for that, but I wouldn't support any proposal based on the idea of people somehow finding drafts and improving them, because that just doesn't really happen outside of token cases. This is unhelpful busywork with a veneer of "preserving content" when the goal is really just to delete them (which I wouldn't support, but have more sympathy for than draftification). It's even stranger because there's not really anything to collaborate on or salvage. What we're talking about here is the preservation of 960 instances of Lugnuts creating a placeholder, yelling "first!", adding it to a running tally, and moving on to the next one, leaving the hard part for someone else. Some people say stub creation inspires passersby to develop articles, but in my experience those who want to write a decent article are more likely to do so if they also get to create it (and/or don't have to work within someone else's structure), for better or worse. Not that I think stub creation should be disallowed; let's just not pretend like there's a lot of value here. I digress... Extending 6 months to 5 years doesn't transform draftspace into a useful collaborative space and doesn't create something valuable out of these stubs. It's a way for those who think the stubs shouldn't exist to functionally delete them where a mass deletion proposal wouldn't succeed. I get that some folks are opposing because they see some value in these drafts, but I'm opposing because (a) moving to draftspace is pointless because of the nature of draftspace and because they're not particularly valuable, (b) I don't support their mass deletion, and (c) redirection is just obviously preferable. With that, I'll take some time away from this thread, as I'm writing a disproportionate amount. — Rhododendritestalk \\ 16:49, 3 March 2023 (UTC)[reply]
Is there a reason that we cannot enact this proposal, but then, instead of R2ing the redirects, retarget them to the associated "Country at the year Olympics" article? We would then be able to slap on a {{R with possibilities}}, which would automatically include a handy note that says "This is a redirect from a title that is in draft namespace at Draft:(name of page), so please do not create an article from this redirect (unless moving a ready draft here). You are welcome to improve the draft article while it is being considered for inclusion in article namespace. If the draft link is also a redirect, then you may boldly turn that redirect into a draft article."HouseBlastertalk 18:20, 2 March 2023 (UTC)[reply]
One hurdle appears to be that Someone™ needs to figure out what to do about the cases where the subject participated in multiple Olympics. See bolded entries in the collapsed list in § Alternative: Redirection targets below. Ljleppan (talk) 18:49, 2 March 2023 (UTC)[reply]
How is #1 ("Draftified articles will be autodeleted after 5 years (instead of the usual 6 months)") going to be enforced? A lot of G13 deletions are done by bots, the ones that aren't done by bots may be done by people unfamiliar with this unending saga, and I don't envy the person who would have to babysit hundreds of drafts every six months for five years. Gnomingstuff (talk) 18:35, 2 March 2023 (UTC)[reply]
With something like a template or a category. In theory a faux-namespace could be used, but that has some disadvantages, although those disadvantages could be overcome with a redirect from draftspace to the faux-namespace, but that also has some disadvantages. I think the details of implementation should be left until after we see if there is consensus for the idea. If there is consensus for the idea, figuring out the implementation would be a next step, and then we would probably try nominating other batches of articles for the same process (with the implementation figured out). Levivich (talk) 18:44, 2 March 2023 (UTC)[reply]
I wish people wouldn't use terms such as "microstub" or "sub-stub", especially in supposedly neutral places such as RFC statements. Our shortest articles are simply stubs, and the use of other terms serves to frame a debate against such articles before it has even begun. Phil Bridger (talk) 21:05, 2 March 2023 (UTC)[reply]
There are different types of stubs, however; we needed to make it clear what sort of stubs we were discussing. BilledMammal (talk) 00:35, 3 March 2023 (UTC)[reply]
Request if the motion passes, could a page be created with the articles listed so that people can try to expand them within the 5 years. I know I might try to expand some of them but will have no time until at least July and without a page/list/something like that, I know I'll forget. Red Fiona (talk) 00:21, 3 March 2023 (UTC)[reply]
I intend to; this list will still exist, but I plan to create another one with all current categories listed. If you have any recommendations for where the list should be placed, please let me know. BilledMammal (talk) 00:35, 3 March 2023 (UTC)[reply]
I went through and added sources for a few so that they no longer met the criteria listed (no sources other than Olympedia/Sports-Reference), and BilledMammal has reverted me SIX times (clear violation of WP:3RR) – yet he's accusing me of being disruptive (I have only reverted three times)! BeanieFan11 (talk) 01:42, 3 March 2023 (UTC)[reply]
I support editors removing items from this list if they meet the criteria defined for the restoration of articles if this proposal passes. This was not done for the articles I restored the list; for most of them only a single source was added, which is not enough to plausibly demonstrate WP:GNG, and for one no sources were added, only text. BilledMammal (talk) 02:03, 3 March 2023 (UTC)[reply]
By making those edits you're making your entire proposal false, as its no longer just a list of articles containing only Olympedia/Sports-Reference with no significant edits. And any explanation for why doubling the revert rule is acceptable? BeanieFan11 (talk) 02:06, 3 March 2023 (UTC)[reply]
The criteria for how these articles could be restored is clear; it doesn't make sense to apply different criteria during the RfC than after it. Regarding the reverts, I believe editors are allowed, with some exceptions, to prevent alterations to proposals they make. I also note that you have done more reverts than I, but we already have a discussion about that on your talk page so I won't comment further on it here. BilledMammal (talk) 02:16, 3 March 2023 (UTC)[reply]
No, I have not made more reverts than you (unless three is greater than six somehow) – I do not see anything allowing what you did at WP:3RR – and again, by reverting, all you're doing is making your proposal a bunch of lies. BeanieFan11 (talk) 02:19, 3 March 2023 (UTC)[reply]
This is troubling. I supported this extraordinary proposal only on specific conditions, including the absence of any SIGCOV. If SIGCOV have even arguably been added to some small portion of the articles, those articles should be stricken from the list. Otherwise, the grounds underlying the "support" votes (including mine) have changed. Cbl62 (talk) 02:54, 3 March 2023 (UTC)[reply]
I note the WP:SIGCOV was added after the RfC was opened; I don't believe it makes sense to have different criteria to remove list items during the proposal (one WP:SIGCOV) than after the proposal (WP:GNG). However, if you or other !support editors disagree, I won't object to their removal. BilledMammal (talk) 02:57, 3 March 2023 (UTC)[reply]
I checked one and it was removed due to the presence of a plaintext reference to the 1911 UK Census and a later death registry, so no sigcov issues there (assuming the references were accurate, they were plain text and even then hard to tell if it's the same person). CMD (talk) 02:58, 3 March 2023 (UTC)[reply]
Would you say, CMD, that this is SIGCOV (from one of them that was re-added)? BeanieFan11 (talk) 03:03, 3 March 2023 (UTC)[reply]
Be nice to have some diffs for context, but that is indeed not a plaintext reference to a census. CMD (talk) 03:07, 3 March 2023 (UTC)[reply]
(edit conflict) BeanieFan11 has removed articles under four different categories:
Articles that included plaintext references like the 1911 UK Census and so were missed when establishing the list; for example, Wilfred Bleaden
Articles where, after the RfC had started, they added no sources but made an edit of greater than 200 bytes; for example, Carlo Bonfanti
Articles where, after the RfC had started, they added one sources that could plausibly be WP:SIGCOV; for example, Arthur Burn
Articles where, after the RfC had started, they added sources that could plausibly demonstrate WP:GNG; for example, Richard Genserowski
I consider removals under the fourth category to be appropriate, as that matches the criteria for restoring the articles defined in this proposal, but I reinstated the articles that were removed under the first three categories as those would be insufficient to restore the article if the proposal passes. If !support editors disagree with any of reinstations, then please remove the articles, or let me know and I will remove them. BilledMammal (talk) 03:11, 3 March 2023 (UTC)[reply]
Adding full-page long articles (such as Bechestobill's case) would not pass your criteria for bringing it back? That is ridiculous. BeanieFan11 (talk) 03:16, 3 March 2023 (UTC)[reply]
WP:GNG requires multiple sources. Most of your additions were also considerably shorter; for example, at Arthur Burn, you added a source containing three sentences. BilledMammal (talk) 03:18, 3 March 2023 (UTC)[reply]
...withthe comment "I could make an enormous expansion of the article with the sources that exist, but don't have the time currently so I'll add a ref so it doesn't get draftified." BeanieFan11 (talk) 03:22, 3 March 2023 (UTC)[reply]
I removed Behestobil. That article now has a full page article from a major newspaper, a clear example of SIGCOV. This extraordinary proposal to bypass normal AfD processe was to be limited to microstubs lacking any SIGCOV and received my Support vote on that basis. Cbl62 (talk) 03:26, 3 March 2023 (UTC)[reply]
Thank you. Do you consider sources like the one added to Arthur Burns to also warrant removal? BilledMammal (talk) 03:30, 3 March 2023 (UTC)[reply]
If you have already found multiple sources then it would be easy to add a second reference. Why don't you just do that, demonstrate that WP:GNG is plausibly met, and uncontroversially remove the article from the list? BilledMammal (talk) 03:30, 3 March 2023 (UTC)[reply]
Ok, no, this proposal is about stubs with zero sigcov references. Not stubs with one reference. Zero. Considering you're the most vocal advocate of the proposal, I was hoping you would already know that, @BilledMammal. casualdejekyll 15:03, 3 March 2023 (UTC)[reply]
@Casualdejekyll: All of these stubs had zero sigcov references when this RfC started. I'm of the opinion that items should only be removed when the criteria for restoration is met (Any draft (whether in draftspace, userspace, or WikiProject space) can be returned to mainspace when it contains sources that plausibly meet WP:GNG) as I don't think we should set lower requirements while the discussion is ongoing than we will set if there is a consensus for this proposal. BilledMammal (talk) 15:35, 3 March 2023 (UTC)[reply]
Your proposal is just going to be a lie then, as its not a list containing only "Sports Reference or Olympedia" with "no significant edits other than Lugnuts." BeanieFan11 (talk) 15:58, 3 March 2023 (UTC)[reply]
Then there is a grey area that needs to be somehow addressed. I think that generally your position on this is plausible, but the other hand of it is that the proposal hasn't actually been enacted yet - i.e. nothing's been moved into draftspace, so requiring the articles to meet requirements to move out of draftspace when they haven't even entered draftspace yet seems a little silly. I'd say that once the move is done, that's when we restrict it to only your "fourth category removals". casualdejekyll 16:42, 3 March 2023 (UTC)[reply]
My concern is that will be gamed, and as the criteria for inclusion is the list is so conservative gaming it will be easy to do.
I don't believe there will be any harm caused by requiring that the restoration criteria is met to remove articles from the list, but I think there will be disruption if we allow the selection criteria to be used to remove articles from the list. BilledMammal (talk) 17:04, 3 March 2023 (UTC)[reply]
BilledMammal is repeatedly reverting when I remove entries with SIGCOV – see here, here and here. Pinging those who have talked about these matters (besides me and BilledMammal) prior for their opinions: @Cbl62, Casualdejekyll, Rlendog, and Chipmunkdavis:. BeanieFan11 (talk) 18:12, 6 March 2023 (UTC)[reply]
I disagree with those reversions. If SIGCOV is found, then the affected article is in a different class from where the main problem under discussion is. It shouldn't matter whether the SIGCOV was added before or after this discussion started. Rlendog (talk) 18:17, 6 March 2023 (UTC)[reply]
I also disagree. Rlendog is correct. The whole point of this proposal is to deal with sub-stubs lacking any substance or SIGCOV and based only on databases. I support the proposal, despite its drastic nature, but only on the basis that it is narrowly limited. If articles are improved to the point that they no longer fall within that scope, they should be removed and that should not be controversial. Will strike my support is this continues. Cbl62 (talk) 18:24, 6 March 2023 (UTC)[reply]
(edit conflict) Either find two GNG-compliant sources, or, in deference to Cbl's position while the discussion is ongoing, one GNG-compliant source that contains extensive coverage. However, I don't understand why you insist on working on this list while the RfC is ongoing; it does cause some disruption and clogs up watchlists, and there are many other articles on Olympians that need to be worked on - if it would help, I can provide you a list containing such Olympians. BilledMammal (talk) 18:25, 6 March 2023 (UTC)[reply]
Why not just leave the list as-is and revisit whatever changes should be made to it after the RfC is over? JoelleJay (talk) 18:45, 6 March 2023 (UTC)[reply]
@JoelleJay: Because the proposal is for drastic mass-removal of 1,000 articles that is an exception to normal processes. Given the concerns I raised in my support vote, I am willing to support the proposal in this unique case. However, it should only apply to articles that plainly fit the scope, i.e., zero SIGCOV and based only on databases. If there is SIGCOV and sourcing beyond such databases, the articles should be dealt with using normal AfD processes. Cbl62 (talk) 19:00, 6 March 2023 (UTC)[reply]
I absolutely do not support mass draftification of articles like Roland Spitzer and Edward Greene (sport shooter). Such close cases should be dealt with at AfD if someone wishes to challenge them. Cbl62 (talk) 19:04, 6 March 2023 (UTC)[reply]
This proposal allows five years for anyone to do what Beanie is doing (BEFORE searches of 1,000 articles). No one claimed to have done BEFORE searches of all 1,000 prior to starting this RFC. The articles on the list met the criteria when the RFC was launched. There is no point in somebody going through the list during the RFC to pull articles out of it. To do that damn near 100 times is disruptive. And even if 100 articles are pulled out, there would still be like 800 or 900 left. It's not even a significant portion of the total. Removing articles one by one is purely disruptive, it accomplishes no constructive goal. At the very least, Beanie could just give BM a list of articles that were expanded during the RFC in the event this proposal passes, and BM can take those off the final list. Levivich (talk) 20:01, 6 March 2023 (UTC)[reply]
Yeah, that's what I had in mind. The list can be amended before implementation, but constantly editing it entry by entry during the RfC is disruptive. It would be clear GAMING if someone was to invalidate inclusion of items on the list by making 200+-byte fluff edits or by adding trivial non-database sources; I don't see how other edits that fail to meet list removal criteria are any different. Even if the list was draftified without amendment, if Beanie shows some individuals do meet GNG they can be moved back to mainspace immediately; if for some of them he can only find one SIGCOV source then he can userfy or work with a wikiproject to incubate the drafts in projectspace. If some NEXIST-notable subjects whose pages no one visits continue to not be visited in draftspace, and no one is interested enough to write a new article on them from scratch in five years, then so be it. JoelleJay (talk) 20:37, 6 March 2023 (UTC)[reply]
Improving articles is the antithesis of "gaming" the system nor is it "disruptive". I support the proposal but articles like Roland Spitzer and Edward Greene (sport shooter) are no longer in scope and should be removed from the list. Mass draftification is an extreme measure and should be limited to those that are clearly' within scope. If 25 of the 1,000 articles get improved while the proposal is pending, that's a good thing! Cbl62 (talk) 20:44, 6 March 2023 (UTC)[reply]
He can improve them all he wants, I'm just saying we can revisit whether they meet list inclusion criteria after the RfC but before implementation. JoelleJay (talk) 21:03, 6 March 2023 (UTC)[reply]
If someone wants to challenge the notability of Spitzer and Greene, they are free to do so but such challenge should folow regular AfD procedures. Articles that include SIGCOV should absolutely not be part of this extraordinary mass removal. 21:00, 6 March 2023 (UTC) — Preceding unsigned comment added by Cbl62 (talk • contribs)
Nobody is opposed to the articles being expanded/improved, and of course nobody thinks articles that include SIGCOV should be part of the mass draftification (or redirection). The point is, we don't need to remove them from the list during the RFC. It's not like just because they're on the list means they're automatically going to be draftified if the proposal passes. We can remove the expanded ones from the list after the RFC (if it passes), and people can still go along expanding them during the RFC, just don't need to be making 25 edits removing them one by one from the list day after day. It has nothing to do with the articles, it's about not spamming this page. Levivich (talk) 21:11, 6 March 2023 (UTC)[reply]
Even if they are drafted, individual articles that have been edited to show sigcov can always be easilymoved back to the mainspace or recreated. This proposal is specifically designed to make that painless. CMD (talk) 04:39, 7 March 2023 (UTC)[reply]
If a second independent/secondary/significant source is provided, yes. BilledMammal (talk) 06:17, 7 March 2023 (UTC)[reply]
Any that plausibly meet GNG would be removed; it would be helpful if editors provide a list of articles they improve, but I will also do my own checks. BilledMammal (talk) 06:52, 7 March 2023 (UTC)[reply]
@Cbl62, BeanieFan11, and Toa Nidhiki05: I had a discussion with JoelleJay and Levivich; articles that meet WP:SPORTSBASIC #5 (one significant/independent/secondary source) will be removed from the list. However, it would be preferable if they are removed as a group at the end, to avoid clogging watchlists. This would include the two you mention. BeanieFan11, rather than removing items immediately after improving them, can you create a list of articles you have improved, perhaps on the drafting talk page? BilledMammal (talk) 01:18, 8 March 2023 (UTC)[reply]
Don’t think these two meet that though. Tvx1 01:35, 8 March 2023 (UTC)[reply]
What's wrong with the assurance they'll be removed after the RfC is over? JoelleJay (talk) 02:08, 8 March 2023 (UTC)[reply]
What's wrong with removing them now? Others have been removed. Why not these two? Cbl62 (talk) 02:09, 8 March 2023 (UTC)[reply]
FWIW, I am not saying that Spitzer and Greene meet GNG. They may or may not survive an AfD, but they clearly do not fit the scope of this extraordinary mass-removal proposal and should be dealt with under regular procedures. Cbl62 (talk) 02:13, 8 March 2023 (UTC)[reply]
I don't want to keep getting notified every time the list is amended, and allowing any user to unanimously remove entries at any time based on their personal interpretation of SIGCOV is obviously untenable. I guess if @BilledMammal wants he could ok the removal of those two specifically now, but future proposed changes would have to be held in a separate list in another subsection/userspace for editors to discuss if the proposal passes. JoelleJay (talk) 02:27, 8 March 2023 (UTC)[reply]
Nor should it be based on your personal interpretation of SIGCOV. It should be based on whether the articles are within scope of the proposal. Also, who appointed you to issue a ruling that "future proposed changes would have to be held in a separate list in another subsection/userspace"? The RfC opened with the premise that it could/would be amended to eliminate articles that are not within scope, and the rules of the RfC should not be changed midstream. Many who supported the RfC may have done so on the premise that this would continue to be respected. Cbl62 (talk) 02:34, 8 March 2023 (UTC)[reply]
I don't read the RfC as opening with that premise. It reads to me as here is the quarry, here is the list of articles that quarry generated. Changes to the question mid-RfC are extremely unusual and generally discouraged, while changes to content under WP:RfC is explicitly discouraged, so I doubt commentators made their comments under the expectation that these usual practices would not be followed. CMD (talk) 03:18, 8 March 2023 (UTC)[reply]
It shouldn't be based on anyone's singular personal interpretation of SIGCOV! I am saying entry removals should be assessed by more than one person, and that won't happen if everyone is editing the list themselves. The proposal criteria were based on the history/status of the articles up to this point, before there was the incentive to make edits to the entries just to invalidate their inclusion. If editors claim they added SIGCOV sources, we should verify entries actually do now meet at least SBASIC #5 before removing them, otherwise the RfC will get bogged down by edit-warring on the list and it will become harder to track which entry removals had some agreement and which ones derived from one person's GAMING or erroneous interpretations of NSPORT. We clearly agree that the object of these criteria is to identify the stubs that are most likely to be on non-notable people; the quarry heuristic BM is using is merely a proxy for this, not definitional. Therefore removals that actually reflect the article now containing ≥#5 sourcing are acceptable, but forcing an entry out by making it fail a technical quarry parameter is GAMING that goes against the spirit of the proposal. The only way we can distinguish good-faith additions of plausible GNG sources from users inserting 200 bytes of contentless text is through multiple people evaluating the edits, and how would we do that when someone changes the list without comment? JoelleJay (talk) 03:39, 8 March 2023 (UTC)[reply]
UTC)
If you want, go ahead and remove those two. However, please add future removals to a list instead. BilledMammal (talk) 23:24, 8 March 2023 (UTC)[reply]
And if I do wait until the end and show you a list, how do I know you won't just be like "screw you, I don't feel like removing them"? I'm not sure I trust you, considering you have absurd interpretations of notability and do not like me. BeanieFan11 (talk) 02:37, 8 March 2023 (UTC)[reply]
How about this: rather than remove them one-by-one, I remove them at three-to-five at a time. I will not wait until the end and show you a list. BeanieFan11 (talk) 14:31, 8 March 2023 (UTC)[reply]
OK how about this: if you agree to stop messing with the list, you can remove 20 articles from the final list for any reason, no questions asked. Levivich (talk) 23:29, 8 March 2023 (UTC)[reply]
If I don't accept that, I feel I could find more than that amount of notable ones with sigcov to be removed. How about this, I only remove entries from the list at most once per day (starting the day after acceptance if accepted), and only if the amount of notable ones that I've found is at 5 or more, and can only revert a re-addition at most one time, with me being allowed to remove 18 articles from the final list, no questions asked. BeanieFan11 (talk) 23:49, 8 March 2023 (UTC)[reply]
How about you just leave the list alone until the end of the RFC and we evaluate then if any need te removed, should the proposal to draftify be successful? Tvx1 07:47, 10 March 2023 (UTC)[reply]
WP:AGF, and I don’t dislike you; I dislike some of your actions, but not you. Even Lugnuts I didn’t dislike and unsuccessfully argued against ArbCom banning him.
However, I think it is reasonable to allow other editors to review the articles you restore, so I would ask that you create a list rather than removing them yourself; for example, the coverage of Walter Bowler is lacking. BilledMammal (talk) 23:21, 8 March 2023 (UTC)[reply]
Alternative: Redirection targets
This list is to allow discussion of the proposed alternative of redirecting articles to the relevant country and year article rather than draftifying them; the requirements to convert the redirect to an article would be the same as the proposed requirements to move an article out of draft space. Note that some of these articles have multiple possible targets; those are marked in bold.
Support redirects. For reasons outlined in my comments above, I support both creation of redirects and draftification. The two proposals are not mutually exclusive. Cbl62 (talk) 18:47, 2 March 2023 (UTC)[reply]
Support redirects on general principle, everyone agrees that in normal circumstances BLAR-ing articles with no discussion is allowed, whereas draftifying or deleting them is not. There's no need for unprecendented procedure breaks when the problem can be dealt with while still following procedure. I also see some errors in the table: you listed the same article twice for Frank Ihrcke and George Stapf, and George Patching and George Pinchard are bolded despite not conflicting. * Pppery *it has begun... 23:48, 2 March 2023 (UTC)[reply]
Thank you, fixed- duplicates were handled manually and I appear to have made a couple of mistakes. BilledMammal (talk) 00:32, 3 March 2023 (UTC)[reply]
Support redirects per Cbl and Pppery. I agree this and the draftification are not mutually exclusive. Levivich (talk) 00:06, 3 March 2023 (UTC)[reply]
Oppose with a similar rationale for opposing the other proposal. These should be discussed on their own merit. BeanieFan11 (talk) 00:08, 3 March 2023 (UTC)[reply]
These really should be discussed individually – some are very clearly notable, some may not be. We should not be getting rid of them all at once when its been shown that many are notable, especially considering that no harm at all is done by leaving them as they are. I think its more harmful to mass get rid of articles, some of which may not be notable, but at the expense of many very clearly notable ones than leaving them as they are and discussing them by their own merits – as they should be. BeanieFan11 (talk) 00:42, 3 March 2023 (UTC)[reply]
Support redirects per my comments in the previous section. I agree something must be done but have reservations about draftifying. Pawnkingthree (talk) 00:24, 3 March 2023 (UTC)[reply]
Since this appears to have turned into a !vote, Support as second choice per my comments in the previous section. BilledMammal (talk) 00:30, 3 March 2023 (UTC)[reply]
Also support, as long as it's clear the same requirements for returning to mainspace are enforced. JoelleJay (talk) 00:37, 3 March 2023 (UTC)[reply]
Support As noted, the two ideas are not mutually exclusive. North8000 (talk) 02:53, 3 March 2023 (UTC)[reply]
Strong support, send the readers somewhere with information that has hopefully been looked at with some due diligence and might have wider context. No objection to drafting still happening, although I don't think it has much purpose at that point. CMD (talk) 03:02, 3 March 2023 (UTC)[reply]
Strong support per my comments in the above section. BLARing is much more reasonable as it maintains page history, while also being semi-useful. Curbon7 (talk) 03:35, 3 March 2023 (UTC)[reply]
Weak support [only choice], per what I wrote in a couple places above. Opposed to draftification; very weakly preferred to just leaving them alone. — Rhododendritestalk \\ 04:13, 3 March 2023 (UTC)[reply]
Support I am not sure exactly what problem the OP is trying to solve. Stubs, per se, are not a problem. I do not think we are dealing with the additional considerations of living people with this list. So, while many of these articles may not meet WP:GNG in their current state, I struggle to see the harm to the project if these articles are left alone and nominated for deletion through normal channels. --Enos733 (talk) 05:52, 3 March 2023 (UTC)[reply]
@Enos733: Are you supporting or opposing this proposal to redirect all the Olympians? You said "support" but your comments (stubs ... are not a problem ... I do not think we are dealing with the additional considerations of living people ... while many of these articles may not meet WP:GNG, I struggle to see the harm to the project if these articles are left alone) seem to say the opposite. BeanieFan11 (talk) 18:29, 3 March 2023 (UTC)[reply]
My thoughts are similar to what Rhododendrites says above. I prefer redirects to draftification/deletion. - Enos733 (talk) 21:18, 3 March 2023 (UTC)[reply]
Support Per my comment in the main survey. -Ljleppan (talk) 06:25, 3 March 2023 (UTC)[reply]
Strong Oppose - Per Harry Oppenheim, which is shining example of where the urge to redirect everything in all cases rather than delete "to preserve the edit history" is misguided. These redirects simply serve to cast in stone the erroneous methodology and bad sourcing used to mass-create these articles in the first place. Harry Oppenheim was someone who literally didn't exist under that name, the real name of the non-notable Austrian footballer was Heinrich Oppenheim, but we already have an article about a different Heinrich Oppenheim who is actually notable. There are also multiple other real Harry Oppenheims which a searcher is just as likely to be looking for (a news paper owner, and art-collector, a South African magnate etc.) because they are equally as (non) notable as the Austrian footballer, but for bizarre reasons we redirect searchers to a list of Austrian footballers who played a tiny number of games for the Austrian national team, with no real explanation as to why they land there, rather than just giving them the search results they would get for all the other Harry Oppenheims mentioned on Wikipedia which would obviously be of more interest to them. FOARP (talk) 09:50, 3 March 2023 (UTC)[reply]
Oppose per FOARP. The solution to disruptive mass creation is to simply delete the whole batch without looking twice (or if that's not possible, draftify it). The redirects can be recreated from scratch when appropriate, and the ones that are not should certainly not be kept around for sake of preserving trivial edit histories full of low-effort useless information and cosmetic edits. Avilich (talk) 22:14, 3 March 2023 (UTC)[reply]
Oppose per my comment in the previous section; these should be dealt with on an individual basis. —Scott5114↗[EXACT CHANGE ONLY] 06:27, 4 March 2023 (UTC)[reply]
Weak support as second choice. I have many reservations about this, as explained elsewhere, but it's still better than doing nothing. Sojourner in the earth (talk) 12:04, 4 March 2023 (UTC)[reply]
It's complicated, but redirection is so obviously a better option than creating a tonne of drafts - and is way more efficient technically. I would want, as per my comments below, to be sure that the sources already in the article have been checked for significant detail by a human being - this takes 20 seconds each article and in a 30 minute sample period threw up around 38% of articles as having prose sources already present and which suggest (strongly in around 20% of cases) other sources exist. We need a balance between throwing out everything and reducing the number of stand alone articles. That can be done. Blue Square Thing (talk) 13:09, 4 March 2023 (UTC)[reply]
Strongly Oppose - I don't support the idea or support lumping them all together.KatoKungLee (talk) 16:22, 4 March 2023 (UTC)[reply]
Comment while my personal preference would be to keep the stubs as they are, I admit it's a personal preference and I can't back it up with Wiki policy. Of the two other options, I think redirecting is the better option, although I would like to make a suggestion that we hold off on redirecting the articles which could go to two possible Olympics, because I suspect those people are likely to be easier to find additional sources for (but I could be wrong). Red Fiona (talk) 17:05, 4 March 2023 (UTC)[reply]
Oppose on principle, since we shouldn't be making bulk editing on so many articles (either to delete, redirect or draftify). If there is a consensus to bulk change these, redirecting is better than the other options, but checking them all properly is the vastly superior option to applying handwaving principles to batches of articles like this. Joseph2302 (talk) 16:09, 6 March 2023 (UTC)[reply]
@Joseph2302: These articles were created through bulk editing. If you oppose bulk editing on principle would it not make sense to make an exception to allow the undoing of problematic examples of bulk editing? BilledMammal (talk) 16:43, 6 March 2023 (UTC)[reply]
Qualified support - I would support redirecting those that do not meet SIGCOV. If SIGCOV is met, those should be excluded from the mass redirect and evaluated on their own merits. Rlendog (talk) 17:15, 6 March 2023 (UTC)[reply]
Support I wish this was a more acceptable answer to both sides of the argument. Redirecting articles can be undone without the lose of any article history as and when SIGCOV sourcing is found, and it doesn't have the time constraints that making drafts does. -- LCU ActivelyDisinterested∆transmissions∆ °co-ords° 22:18, 9 March 2023 (UTC)[reply]
Support redirectsif draftification does not find a majority.Paradise Chronicle (talk) 05:41, 19 March 2023 (UTC)[reply]
Support redirects since draftification is essentially a delayed deletion. We should only redirect those in which other sources cannot be found to improve these stubs. Abzeronow (talk) 19:26, 20 March 2023 (UTC)[reply]
Oppose, per FOARP. I'm not at all confident that systematic determination of the redirect target can be trusted. If redirection is the best outcome for any number of these stubs, it can be determined by manual assessment of the draft. XAM2175(T) 12:49, 26 March 2023 (UTC)[reply]
Support as a way of serving the readers and maintaing the history for any editor who wants to try to recreate an article. Valereee (talk) 11:57, 7 April 2023 (UTC)[reply]
Support over draftification, would also support deletion but as per WP:REDIRECTSARECHEAP (and redirects can be deleted in the future) so I wouldn't let that stop us proceeding wiht redirecting them JeffUK 14:45, 13 April 2023 (UTC)[reply]
Oppose per my oppose in the main proposal. Anarchyte (talk) 11:22, 29 April 2023 (UTC)[reply]
Support per my comment last section. Each should be individually surveyed to a greater degree before redirection however: sometimes a dab, deletion, or a different target would be preferable. J947 † edits 06:13, 30 April 2023 (UTC)[reply]
One solution would be to redirect to the first (or last, or even random) Olympics they participated in, and then let normal editing processes handle it from there. Another would be to say "there is no obvious redirect target, so let's draftify for now" and let normal editing procedures figure it out from here. Both are far from perfect, but perfect is the enemy of good. Ljleppan (talk) 09:45, 3 March 2023 (UTC)[reply]
Draftify first. Unintentionally, I'm sure, this issue of having to redirect has simply acted as a barrier on anything being done at all. FOARP (talk) 11:38, 3 March 2023 (UTC)[reply]
Someone above made the explicit suggestion of COUNTRY at the YEAR SEASON Olympics as the most logical option. I'd be happy with that and it's clear and easy to use - see my point below for which one we use where someone has been to more than one games. Blue Square Thing (talk) 14:33, 3 March 2023 (UTC)[reply]
Agree with Sojourner in the earth above - And yes, this is a problem generally for nearly all these redirects of non-notable sportspeople: there is a multitude of possible redirects, each as bad as the other. Returning to the "Harry" Oppenheim case discussed in my !vote above, Heinrich Oppenheim played two games for the Austrian national team but he also played at club level in Austria so why are we highlighting their very brief career on the Austrian national squad. Indeed, why are we highlighting them with a redirect at all when other Harry/Heinrich Oppenheims existed? FOARP (talk) 11:36, 3 March 2023 (UTC)[reply]
That's a good point about other people with the same name. If we didn't have an article on the Olympian Alfred Keene, then the painter Alfred John Keene would be the primary topic, and should therefore be the target of the redirect. Sojourner in the earth (talk) 18:55, 3 March 2023 (UTC)[reply]
Firstly I'm not even sure I'd be trying to do anything with Alfred Keene before doing a quite intensive search of The Times and the London Gazette - the notes on his Olympedia page suggest strongly to me that there's very likely to be something to allow us to develop a decent article about him.
In terms of where to redirect - in some cases it'll be obvious because someone will have had one relatively successful games, in which case the redirect should probably go there (Sidney Domville for example, although again the notes in Olympedia suggest he's worth a look as a keeper). In other cases it won't be so clear - I'd probably suggest their first games in that situation, but I could live with the last. It's just slightly easier for modern people to use the first (and bear in mind that stuff like shooting means people can have really quite long Olympics careers. Blue Square Thing (talk) 14:30, 3 March 2023 (UTC)[reply]
My plan, if there is a consensus to create redirects, to redirect to the country article for the first Olympics they played in. I'll also provide a list of the articles covering sportspeople who played in multiple years to WikiProject Olympics, so that interested editors may easily alter the target if desired. BilledMammal (talk) 16:22, 3 March 2023 (UTC)[reply]
BilledMammal - but then why redirect at all? With the redirect the user is taken to a single page. Without it, the user sees all mentions of that name on Wikipedia in their search results, including all the events and teams on which that name is listed, but also all the other people of that name who are equally as likely to be of interest - isn’t that better? FOARP (talk) 06:02, 4 March 2023 (UTC)[reply]
I agree, and have argued extensively for that position in the past, but I believe a few inconvenient redirects are an improvement over leaving these articles in mainspace, and if there is a consensus for the proposal only on the basis of redirection I don't believe it would be appropriate to omit a few. However, I would be happy to provide you with a list of articles with multiple appropriate targets, and can probably generate a partial list of clashes with other articles - you can then bring them as a group to RfD? BilledMammal (talk) 06:12, 4 March 2023 (UTC)[reply]
That seems very arbitrary and potentially unhelpful, eg. if someone is reading about the 1912 Olympics, searches an athlete's name and is taken to an article on the 1908 Olympics, with no indication of where they can find the information they're looking for. It might do as a stop-gap measure, but if consensus is to make these articles into redirects, my preferred solution would be to merge them all into List of Olympic athletes (1896–1912). That would be a lot more work, obviously. Sojourner in the earth (talk) 12:00, 4 March 2023 (UTC)[reply]
That would be a lot more work, obviously. Depending on what information you believe should be included in that list, it might not be. What information do you believe should be included in it?
My concern would be that the list would be very long (WP:LSC), and that it wouldn't fully resolve the issue as some athletes who competed between 1896 and 1912 also competed after 1912; I think that can be corrected by creating "List of Olympic athletes: A", "List of Olympic athletes: B", etc. BilledMammal (talk) 12:20, 4 March 2023 (UTC)[reply]
It also doesn't deal very well with people who appeared in 1912 and then in the 1920s, for example. Blue Square Thing (talk) 13:04, 4 March 2023 (UTC)[reply]
What information do you believe should be included in it? For the list to be useful, I think at a minimum it would have to contain birth and death dates, Olympic years and events participated in. This information would have to be checked against the sources, though, to make sure we're not propagating errors. Sojourner in the earth (talk) 14:48, 4 March 2023 (UTC)[reply]
We can check against the sports-reference source automatically; would that be sufficient?
If we are going to do this I think it will need further and separate discussion; both to determine what information to include, and to determine whether such a creation would be appropriate. BilledMammal (talk) 15:30, 4 March 2023 (UTC)[reply]
Perhaps it would be easier than I thought, then. I'm completely ignorant about what kind of things can be accomplished with technology. I agree that more discussion would be needed. Sojourner in the earth (talk) 20:53, 4 March 2023 (UTC)[reply]
That applies to something like 5% of articles. So I would suggest we redirect those that are unambiguous automagically; and the rest can simply be left for people to redirect, AFD or improve as they see fit. (Or we can agree separately what to do with those)
It's a hell of a let better to only have 5% to work through 'manually'.
Discussion (other article-sets which need addressing)
If this motion passes some serious thought should be given to sub-sets of other extreme-low-quality articles mass-created on Wikipedia. Off the top of my head:
The 19th-century and early-20th-century cricketer/footballer articles made by Lugnuts.
Dr. Blofeld's mass-created Bangladesh/Burmese "village" articles created using only GEOnet Names Server (GNS), a deprecated source for this purpose. Dr. Blofeld has indicated that they are OK with these articles being dealt with in some way in the past.
The Antarctic geological feature articles created based only on GNIS, a deprecated source for this purpose.
Carlossuarez46's Iranian/Azeri "village" articles, created based on GNS/the Iranian census (both deprecated for this purpose - the Iranian Census because it includes wells/pumps/farms/houses etc. as "villages").
Of course the process would be the same as here, and the search used to highlight it having similarly very low criteria for escaping draftification. FOARP (talk) 10:00, 3 March 2023 (UTC)[reply]
Yes, the problem for me is permastubs which can't be expanded or ever become a useful start class article. I think you'll find most stubs created by me can be expanded, but the "xx is a village" approach using a database, even with a population figure in many of them was a poor way to approach it. I'd be happy to delete all database type stubs from the site which can't be significantly expanded, or merge them into lists were appropriate. Carlos's Iranian stubs for instance, I think we'd be better off merging a lot of the smaller settlements into lists by district. ♦ Dr. Blofeld 14:32, 3 March 2023 (UTC)[reply]
I think this discussion will need to be split off, but I've created two lists of articles created by Carlossuarez46 on locations in Iran and Azerbaijan. These lists attempt to include every article they have created, so they will include articles that would not be considered for draftification like Hadrut; filtering can be done later, if there is a consensus for this proposal and when we decide how we want to filter the articles. They also may not be complete; I am not certain yet what article or talk page categories are best suited to generating a complete list, and suggestions are welcome.
I am wondering, though, if these creations were fully automated; I'm seeing several articles with identical names disambiguated only by coordinates, and I don't believe that even an inattentive human using a semi-automated process would not realize that those are probably the same location. BilledMammal (talk) 17:17, 3 March 2023 (UTC
Alternative proposal to draftification and redirection: create an Olympic stub cleanup project
I have what I believe would be something much more beneficial, at least a hundred times more helpful to the encyclopedia, than the two above proposals (redirection and draftification): start a project dedicated towards expanding and cleaning up Olympians. I have found many people from this list above that are notable, some very highly notable (examples which I have expanded: Fred Narganes, Thomas LeBoutillier, Herbert Gidney, J. Nash McCrea, and Garnett Wikoff, to name a few – and for some others, which I haven't had the time to, I've just added sources to show notability, some of which had full-page long articles (Albert Bechestobill) and some of which had articles describing them as the greatest ever in their sport (Lou Scholes, John Hession)) – it is insane to suggest blindly removing (redirection=removing;draftification=backdoor route to deletion) nearly one thousand articles when many of which are very notable (unless there is a major issue otherwise with all of them, except that's not the case here). So I propose that we create a project to cleanup, improve and expand Olympian articles, with rewards for those who do so. As for what the rewards are, I've thought of this: improve two Olympian articles to the point that it would pass the WP:DYK criteria – one barnstar; improve three further – one more barnstar; then one additional barnstar for every time someone does five more (I've thought of different types of barnstars and awards that could be designed for this). I feel this would be much more benefifical to the project than just mass throwing out huge amounts of Olympians, when many are notable. BeanieFan11 (talk) 15:55, 9 March 2023 (UTC)[reply]
An Olympic stub cleanup project sounds like a great idea, but I don't see why this is an alternative to draftification. The stubs can easily be worked on in draftspace. Contrary to the claim that keeps cropping up that draftification is being used as a backdoor to deletion, I very much hope that the majority of these articles can be rescued and restored to mainspace. Sojourner in the earth (talk) 17:31, 9 March 2023 (UTC)[reply]
Also, BeanieFan, I'm afraid I have to add my voice to those who feel that your behaviour at this RfC is (unintentionally) disruptive. Removing Otto Feyder from the list in order to nominate it for AfD, where you propose to turn it into a redirect – a proposal already under consideration in this discussion – is only wasting the time of volunteers. You're doing some good work on these articles but it would really be so much easier for everyone if you would wait until the RfC is over. Regardless of the outcome, none of these articles are going anywhere for at least another five years. Sojourner in the earth (talk) 17:40, 9 March 2023 (UTC)[reply]
Apologies about Feyder, I see now that that action didn't make sense. BeanieFan11 (talk) 17:50, 9 March 2023 (UTC)[reply]
Support - I would be interested in contributing to this. No rewards needed for me.KatoKungLee (talk) 16:41, 17 March 2023 (UTC)[reply]
Comment I support this, but this can also be done from draft space. On the rewards I believe some more general award for the article expanders could be thought of. Organize "backlog" drives etc. Then also, the Lugnuts olympic stubs are just a start. There are likely tens of thousands similar ones that could need an expansion if sources exist.Paradise Chronicle (talk) 19:52, 19 March 2023 (UTC)[reply]
Oppose - at least as an alternative. Experience has shown that these articles just won't be dealt with. Wikipedia just doesn't have that many truly-active editors that it can waste the time of ~100 or so of them for months sorting through Lugnuts' articles. There is a clear DELREASON for these articles as they currently stand. No opposition, of course, to anyone doing this ON TOP OF the remedy of draftification. FOARP (talk) 14:04, 23 March 2023 (UTC)[reply]
Oppose as alternative. Concur entirely with FOARP. XAM2175(T) 12:53, 26 March 2023 (UTC)[reply]
As an additional strategy for dealing with this, great idea. You can start that today without an RfC. As an alternative, Oppose. Valereee (talk) 12:03, 7 April 2023 (UTC)[reply]
Support per proposal or as a way of formalising the efforts already-present at the Olympics WikiProject. In this way, I also have to say that FOARP's reasoning doesn't ring true in this case - Experience has shown that these articles just won't be dealt with may be correct in many cases, but there has been a conceited effort to rescue Olympic bio stubs going for over a year as I recall already, so experience regards this shows they will be dealt with. I would also challenge FOARP and Valereee's views that (while a commendable additional method) doing this should not be an alternative: there is no harm in going slower about this, and we are more likely to reach a solution that adds to the encyclopedia if we do. Kingsif (talk) 23:58, 15 April 2023 (UTC)[reply]
Support as per my comment above. This seems the most productive path forward. It may appear immediately easier to draftify, but though this is longer term, it adds more quality to the encyclopedia. --Nerd1a4i (they/them) (talk) 06:34, 2 May 2023 (UTC)[reply]
Discussion (general)
Perfection is the enemy of progress. We're talking about an immense amount of stubs that the creator spent perhaps 1 minute each creating. Any plan which requires a special discussion and decision-making process for each one (perhaps 1 hour of volunteer time for each) will not actually get implemented and would be an insult to volunteer time. Some way of efficiently moving forward on this is needed, even if imperfect. The potential downside of an efficient system potentially having non-optimal handling of some exceptions is easily fixed and not big. North8000 (talk) 16:17, 3 March 2023 (UTC)[reply]
Frankly my preference is for straight-deletion of failing articles that were created en masse, and the recreation of that part of them which may be notable as actual articles. The proposed process does at least eventually achieve that result so I am in favour of it.
Opponents are essentially admitting that even given years of lead-time, they are not going to fix these articles, in large part because many/most of them cannot be fixed. FOARP (talk) 05:54, 4 March 2023 (UTC)[reply]
Well, I"m not sure that that's necessarily true.
I just took a strict 30 minutes - timed - and clicked through the first 163 articles on the list of 960 above (17%) - working in the order they were presented, i.e. alphabetically by forename. For each one I checked the Olympedia article to see if it had anything substantial to say about the person. If there was anything relatively in depth that made me think there might well be further sources available I recorded it as "Definitely worth a look"; if there were a few personal details or details about their career I recorded "Possibly worth looking at"; if there were only passing details, such as the club they represented or their performance just in the Olympics I didn't record anything. On average it took less than 20 seconds per article, including recording.
Of those 163 articles, I recorded "Definitely worth a look" 31 times and "Possibly worth looking at" 32 times - so, 63 of the 163 had something on the Olympedia article which gave me significant pause for thought (38.7% - with 19% clearly, in my view, worth a proper look).
That's a much higher proportion than I was expecting.
This might be because the majority of those with detail on were British or American - more likely British fwiw. The 1908 London and 1904 St Louis games almost certainly mean that there are more of those articles - if the set had been 1912 to 1928 then I imagine the proportions would have been lower.
Obviously this is partially subjective. I tried to be as clear as possible and only record when there was clearly something that caught my eye, but at the same time was working quickly and there may be some blurring. I was focussing on the likelihood, in my experience of using newspaper reports from this sort of era, of other sources existing - after all, that's almost certainly where the Olympedia writers got their information from. In some cases there wasn't much in the way of information but hints that there must surely be more (Daniel McMahon (sport shooter), for example), whilst another cases there is already a significant amount of information (Daniel Flynn (cyclist), for example).
The set I looked at is here along with my notes. I took out most of BilledMammal's columns for simplicity.
Why is this "important"? It's reasonable to make the assertion that stubs can act as seeds for articles. I think it's also reasonable to assert that stubs in mainspace are more likely to be developed than redirects or drafts. I have absolutely no quantifiable evidence to back up that assertion, but I'm sure I've seen other people make it in the past and I don't think it's an unreasonable thing to say.
So what? The query is good at identifying possible articles that might be dealt with. And by my book, 60-odd percent of these could probably be dealt with somehow. But my only request is that we look at the sources actually present first. For the list of 960 that's, what, less than four-person hours (20 seconds per article is easily doable over 30 minute bursts). Think how much time has been wasted on this process of discussing alone over the last couple of years. At least part of that - and a substantial amount of the opposition to the proposals - is people pointing out that some of the articles on lists which have been presented as clearly notable (Bill Huddleston was on one list for example, yet already contains a substantial prose source because the methodology assumes, as with these lists, that the sources included in the article are only databases). The discussions above have already thrown up plenty of other examples beyond the first 163.
Yes, let's do something. But let's not delete everything without even having the courtesy to spend 20 seconds on each article. Blue Square Thing (talk) 11:33, 4 March 2023 (UTC)[reply]
I think it's also reasonable to assert that stubs in mainspace are more likely to be developed than redirects or drafts. I have absolutely no quantifiable evidence to back up that assertion, but I'm sure I've seen other people make it in the past and I don't think it's an unreasonable thing to say. I have quantifiable evidence to say the opposite; see my essay Wikipedia:Abandoned stubs. Articles are much more likely to be expanded by their creator than by anyone else. BilledMammal (talk) 11:38, 4 March 2023 (UTC)[reply]
I don't think that's quite the same thing though, is it? And, interestingly, your 35% figure having been developed is quite close to my 39% figure for items on that list where there's a fairly significant flag that I can raise that says, hang on a minute, we need to look at this properly. Which is my main request here. Blue Square Thing (talk) 13:03, 4 March 2023 (UTC)[reply]
Not quite, but it is the best evidence we have or can get without an experiment that would violate WP:NOTLAB. BilledMammal (talk) 13:47, 4 March 2023 (UTC)[reply]
I don't think there'd be anything disruptive involved would there? Blue Square Thing (talk) 15:26, 4 March 2023 (UTC)[reply]
the methodology assumes, as with these lists, that the sources included in the article are only databases This isn't accurate. The method assumes the source has been used as a database, which is not the same thing. (And apparently used in a way that generates the wrong birth dates in some instances, somehow.) CMD (talk) 13:22, 4 March 2023 (UTC)[reply]
I take the specifics of your point, but my point is that the way that the list that Huddleston was on was created using a query to produce a set of articles that are presumed to be inadequately sourced, which is often taken to mean sourced only to databases (see any number of discussion around the sourcing of articles about sports people).
The assumption behind that is that the sources, in that case CricketArchive, are assumed to be purely a database source. In the case of Huddleston that source contained a decent sized prose article about him as well as the standard data tables and so on. The same is sometimes true of articles sourced only to CricInfo - a point I've made a number of times elsewhere.
In the case of the list of 960 articles presented here, the assumption seems to be that articles sourced to Olympedia will simply have data tables rather than any reasonable prose that could act as a seed for article development. In around 40% of the 163 cases I've looked at so far I don't think that assumption is reasonable to make. Of course, identifying the 60% that don't have that and doing something with them would make the task of figuring out exactly what to do with the 40% much easier, and, with caveats, I support that. Blue Square Thing (talk) 15:26, 4 March 2023 (UTC)[reply]
I don't see where that assumption is being made; I don't even think anyone has suggested Olympedia is a poor source. Whatever it (and Cricinfo) could be used for, it has instead been used to procedurally generate two sentences on each subject. Whatever is done to those sentences, Olympedia and its seed information would remain for those interested in the 40%. CMD (talk) 15:44, 4 March 2023 (UTC)[reply]
Given the history of this subject area and discussions such as those at WP:ACAS and ones like this at the cricket project or those surrounding the changes made over the last 2-3 years related to WP:SPORTCRIT, I don't think it's an unreasonable assumption to make given the point in the selection criteria section which says Referenced only to Olympedia or Sports Reference. As I say, I take your specific point about the way that they have been used in these articles at present, but my point here is that Olympedia clearly contains some detailed prose on some of these articles - as do CricInfo and CricketArchive. Not on all of them, but on enough to make it necessary to manually inspect the sources before we chuck stuff out that we should be eventually improving. Blue Square Thing (talk) 20:53, 4 March 2023 (UTC)[reply]
I don't know whether I was involved in those various discussions you point to, but this proposal is specifically designed to provide time for people to manually inspect the sources and develop the articles. CMD (talk) 02:18, 5 March 2023 (UTC)[reply]
Leaving aside that no one will do that if they're difficult to find drafts, rather than much easier to find main space articles, they can then move it back to mainspace when it contains sources that plausibly meet WP:GNG. Which getting on to 40% of my survey ones already do... Blue Square Thing (talk) 10:55, 5 March 2023 (UTC)[reply]
GNG requires multiple sources. In some cases, Olympedia might count as one (although many of the blurbs are too short to plausibly be WP:SIGCOV), but sports-reference never does. BilledMammal (talk) 11:05, 5 March 2023 (UTC)[reply]
Blue Square Thing - The prose sections on Olympedia are not clearly reliably sourced. If you believe they are reliably sourced, you need to go beyond "I haven't seen any instances of them being wrong". I have, actually - Francis English was listed on Olympedia as having died in 1984 but clearly lived beyond that, Olympedia was corrected after the Wikipedia article was redirected but this just goes to show that they are relying on Wikipedia to do their fact-checking. You have to explain who actually wrote them and whether there is any actual rigorous editorial process, because as far as I can see the answer to that question appears to be that they are Wiki-like content written by the volunteers who maintain those databases, and include material e.g., sent in by the families of those listed. I also agree with BilledMammal that most/all of this prose content does not rise to the level of SIGCOV. FOARP (talk) 09:18, 6 March 2023 (UTC)[reply]
The point isn't to draftify them in the hopes that someone outside of NSPORT editors will find them organically, it's to draftify them specifically so that the editors who insist there must be sources can work on them outside of mainspace and we don't have to go through hundreds of AfDs. Given their lack of attention over the last decade, no one outside of the usual sports editors/blanket inclusionists care about these stubs (and even that's just wanting them to exist for completion's sake), much less would notice they were gone, so I highly doubt draftifying would make any difference to their expansion prospects. JoelleJay (talk) 00:21, 6 March 2023 (UTC)[reply]
Blue Square Thing, your study was responding to / responsive to a particular post but IMHO not to the main reasons for the main question here. IMO the main premise of the proposals is "if someone makes a real article out of it fine. If not, then it goes. In a way commensurate with how they were created....en masse rather than requiring an hour of volunteer time to delete each article that took one minute to create. North8000 (talk) 18:33, 6 March 2023 (UTC)[reply]
How are these not "real articles"? Many articles in paper encyclopedias (that some of us remember, and Wikipedia is supposed to emulate) only consisted of one short sentence. "Joe Bloggs competed in the quadrathlon at the 1971 summer Olympics" tells the reader more than nothing. Phil Bridger (talk) 19:54, 6 March 2023 (UTC)[reply]
When a paper encyclopedia says just one sentence about something, that's called an "entry", not an "article." No one is arguing against "Joe Bloggs competed in the quadrathlon at the 1972 summer Olympics" being an entry in the article about the 1972 Summer Olympics, but we shouldn't have one-sentence articles because those aren't what articles are. Semantics aside, if we have one sentence to say about something, it makes almost no sense to put that one sentence on its own web page, alone. It makes a lot more sense to move that one sentence to some other web page that already has other sentences on it. Levivich (talk) 20:05, 6 March 2023 (UTC)[reply]
In draftspace no one can hear you scream - they could be there for 5 years without anyone improving them, yet many of these articles have been in mainspace for longer and have only drawn any interest once they have been threatened with draftification. The subjects may be notable, there may be sources available, and there is the argument that they should be kept because if left long enough someone else may do something to improve them. These stubs do not establish notability, they have few sources and yet they are still here when better quality drafts would be rejected by AFC. It seems that editors agree that something should be done, but not what? An option could be to run an Olympian WP:De-stub-athon that would cover the listed articles but as part of a larger improvement drive, rather than specifically honouring or condemning any individual creator. There are 133,000 articles classed as stubs by the Olympics wikiproject (including those listed here and many others created by Lugnuts). Afterwards the option will still be there to discuss what to do with anything on the list that editors have not been able to improve, but maybe the situation would be clearer. EdwardUK (talk) 16:06, 8 March 2023 (UTC)[reply]
From a couple of things raised here and what I came across with the Arthur/Alexander Martin case, I've grown seriously concerned that Olympedia is not the reliable source some think it to be. I also don't understand why all those articles seem to rely nearly solely on that for information and don't even cite the Olympics own official site's profiles on the people in question. In any case, a serious vetting of the sourcing is required.Tvx1 20:09, 8 March 2023 (UTC)[reply]
Operating under the assumption that users self-sort into WikiProjects of personal interest, it seems unlikely that these stubs could be handled by a dedicated project. WikiProject Olympics reports 190K articles under their purview and only 5.5K are assessed as C quality or above. Thus, if only 2.9% of its articles have reacted a threshold of substantial content over 20yrs after the project's founding, it seems unlikely that a further fork of their labor will attract the necessary support to resolve the stubs BluePenguin18 🐧 ( 💬 ) 03:11, 17 March 2023 (UTC)[reply]
Comment As of now and as to my count it was 63 support to 27 opposes to the draftification. Off course I can err but the supporters are very likely in the majority.Paradise Chronicle (talk) 16:25, 23 March 2023 (UTC)[reply]
And because consensus is determined by someone uninvolved evaluating the strength of the arguments, not by counting noses, that is irrelevant. Thryduulf (talk) 17:09, 23 March 2023 (UTC)[reply]
I hope this would be always like this. Mostly Often it's just counting votes. Paradise Chronicle (talk) 20:08, 23 March 2023 (UTC)[reply]
Ludicrous talking shops like this are among the main reasons for this site's headlong plunge into a permanent downwards spiral. Why delete only the Olympians? The best solution for such a farcical mess of a site is to delete everything. 2.99.210.156 (talk) 13:46, 24 March 2023 (UTC)[reply]
Comment Some other solution for the micro biostubs would be migrating the stubs to something like a directory of people. This would also be quite a boost for the closure of the gender gap I believe.Paradise Chronicle (talk) 18:05, 24 March 2023 (UTC)[reply]
For what it's worth, virtually all initiatives to improve the gender gap (e.g., Wikipedia:WikiProject Women in Red) focus on increasing Wikipedia's coverage of women, not on decreasing the coverage of men. This would narrow the gender gap on a numbers level but would do nothing for the broader aim of fixing the under-coverage of women, which is the entire point. Gnomingstuff (talk) 23:17, 27 March 2023 (UTC)[reply]
Notes
^This excludes many mass-created microstubs, but it keeps the number of false positives extremely low
^"Significant contributions" is defined as "larger than 200 bytes, excluding edits that are reverts or were reverted"
^This does not mean that the article is guaranteed to be kept at AfD on the basis of the sources contained within it, just that it is possible to make a good faith argument at AfD that WP:GNG is met on the basis of those sources.
^This option is provided to support editors who may determine that some of the articles on this list would be more useful as redirects than drafts.
^Nominating 500 articles a month would increase by a third the number of articles going through AfD, and conservatively assuming that only half of Lugnut's creations have notability issues would take almost eight years
Close appeal
This close of this discussion is being appealed at WP:AN; the discussion can be found here. BilledMammal (talk) 21:17, 24 April 2023 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
RfC: Removing "Clear the watchlist" from main watchlist screen
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Support removal of this button. It is too dangerous on the watchlist. Graeme Bartlett (talk) 12:03, 15 April 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
I see the same as Aaron Liu in the old vector, i.e. nothing. Phil Bridger (talk) 20:08, 15 April 2023 (UTC)[reply]
In Vector 2010, I think these options only appear if you have "Use non-JavaScript interface" enabled in Preferences. Sojourner in the earth (talk) 20:18, 15 April 2023 (UTC)[reply]
Strange. I don't have those links on 'Vector Legacy'. I don't see anything in the preferences. It does appear on Vector 2022 though. SWinxy (talk) 17:32, 16 April 2023 (UTC)[reply]
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)[reply]
I can confirm that these options only appear with non-JS interface. Aaron Liu (talk) 18:34, 16 April 2023 (UTC)[reply]
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)[reply]
For 1), safemode doesn't disable all JavaScript, just your userscripts in common.js/vector.js/etc Aaron Liu (talk) 11:30, 17 April 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Can't they just edit raw? Aaron Liu (talk) 18:52, 16 April 2023 (UTC)[reply]
@Redrose64: My watchlist has 12,375 items and it struggles a bit to load the raw list (I copy it over to the watchlist for User:Aoidh (Away) periodically), but if they need to clear the watchlist entirely then that option already exists in the Watchlist section of Special:Preferences. - Aoidh (talk) 03:27, 24 April 2023 (UTC)[reply]
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)[reply]
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)[reply]
While I agree, the clear watchlist button has a confirmation. Aaron Liu (talk) 11:33, 1 May 2023 (UTC)[reply]
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 Albury 11:54, 1 May 2023 (UTC)[reply]
That'd be a bug and you should report it to phabricator. Aaron Liu (talk) 12:00, 1 May 2023 (UTC)[reply]
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)[reply]
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 Albury 19:47, 1 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
(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)[reply]
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)[reply]
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). — xaosfluxTalk 13:33, 5 May 2023 (UTC)[reply]
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)[reply]
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.)
We do have the request an account process but it isn't perfect. I wonder how (if at all) zhwiki deals with this issue. Snowmanonahoe (talk) 12:36, 18 April 2023 (UTC)[reply]
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)[reply]
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. MilkyDefer 06:21, 30 April 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
How do you adhere to NPOV while being censored? Aaron Liu (talk) 00:35, 25 April 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
From my philosophical POV, I think a 10% censorship of Wikipedia more closely adheres to the principles of WP:UNCENSORED than a 100% censorship of Wikipedia. Félix An (talk) 00:18, 25 April 2023 (UTC)[reply]
Collaborating with government censorship is much worse than simply being victimized by it. MrOllie (talk) 00:29, 25 April 2023 (UTC)[reply]
I think his argument is that when pure is unreachable, grey is better. Aaron Liu (talk) 00:41, 25 April 2023 (UTC)[reply]
From my philosophical point of view giving in to Chinese censorship AT ALL is more damaging to Wikipedia than not being available to Chinese users would be. User:Khajidha (talk) (contributions) 05:40, 25 April 2023 (UTC)[reply]
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)[reply]
How do we know that the 90% editors won’t bring their censorship to the rest of the wiki? Aaron Liu (talk) 12:52, 25 April 2023 (UTC)[reply]
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)[reply]
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)[reply]
How can you really tell an article is safe? Even an article of a certain panda can cause problems. MilkyDefer 06:27, 30 April 2023 (UTC)[reply]
I also believe that the parts that will be censored are more than 10%. Aaron Liu (talk) 12:53, 25 April 2023 (UTC)[reply]
Because it would mean that facts were subordinate to politics. Any encyclopedia that caved in to censorship in that manner would become useless. --User:Khajidha (talk) (contributions) 13:19, 25 April 2023 (UTC)[reply]
Encyclopedias in China aren't useless. In fact, I often consult them in university. Félix An (talk) 02:46, 26 April 2023 (UTC)[reply]
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)[reply]
But can you edit through those mirrors? Félix An (talk) 00:15, 25 April 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
The bits and pieces are enough to get the entire Wikipedia blocked. Aaron Liu (talk) 12:52, 25 April 2023 (UTC)[reply]
Also, my last sentence remains unanswered. Aaron Liu (talk) 13:05, 25 April 2023 (UTC)[reply]
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)[reply]
How would we form this group before the Chinese mirror is publicly available? Aaron Liu (talk) 11:20, 27 April 2023 (UTC)[reply]
You previously mentioned that there was a "Wikimedia affiliate in China". We could use them. Félix An (talk) 08:08, 28 April 2023 (UTC)[reply]
Robertsky mentioned it and what he said was it has been destroyed by the CCP Aaron Liu (talk) 11:49, 28 April 2023 (UTC)[reply]
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. MilkyDefer 15:06, 30 April 2023 (UTC)[reply]
Also, one MINQI is enough, I don't want another one. MilkyDefer 06:40, 30 April 2023 (UTC)[reply]
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)[reply]
And what's wrong with normal companies? Also I just found User:MINQI but they haven't done anything wrong either. Aaron Liu (talk) 14:50, 30 April 2023 (UTC)[reply]
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. MilkyDefer 15:05, 30 April 2023 (UTC)[reply]
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. MilkyDefer 15:11, 30 April 2023 (UTC)[reply]
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)[reply]
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. MilkyDefer 15:28, 30 April 2023 (UTC)[reply]
Also I didn't find criticism when just searching the Chinese for "Wikipedia" under news in Baidu. Aaron Liu (talk) 15:32, 30 April 2023 (UTC)[reply]
[3], [4]. I remain neural to their claim. MilkyDefer 16:06, 30 April 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
@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.
I do not want to say it but you have too strong biases, which already influenced your behaviors. MINQI (talk) 23:03, 30 April 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Kinda, in MilkyDefer's struck Personal rambling by their own admission. Aaron Liu (talk) 00:56, 1 May 2023 (UTC)[reply]
@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)[reply]
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)[reply]
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. MilkyDefer 01:52, 1 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
Do edits on 求闻百科 get reflected on the original Wikipedia in real time or near real time? Félix An (talk) 05:56, 1 May 2023 (UTC)[reply]
No. From the looks of it, it is a complete separate fork. – robertsky (talk) 06:18, 1 May 2023 (UTC)[reply]
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)[reply]
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 [5]).
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
How do you verify someone's IP address if they're behind a VPN? Aaron Liu (talk) 00:43, 2 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
OpenCV is just image recognition, of course it would be fast. Aaron Liu (talk) 14:18, 2 May 2023 (UTC)[reply]
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)[reply]
1 year, and only 100 accounts‽ Aaron Liu (talk) 00:44, 2 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@Cwek I can't agree. I do think that the current process on Chinese Wikipedia is too complicated, at the very least for the newcomer tutorial part. Besides, isn't that "the free encyclopedia that anyone can edit" our motto? ときさきくるみnot because they are easy, but because they are hard 17:23, 5 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
It is. And we provide the same access to anyone. The problem here isn't with Wikipedia and there's not really much we can do about it.--User:Khajidha (talk) (contributions) 01:44, 6 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
How about 10000 accounts in this trial? I think this is a more reasonable trial size. Félix An (talk) 02:37, 3 May 2023 (UTC)[reply]
(Another rule we could have is that each IP address can only be used to verify once, to prevent sockpuppets.) Félix An (talk) 02:39, 3 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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×g 01:29, 6 May 2023 (UTC)[reply]
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)[reply]
When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Update: support option 2. That was my preferred proposal from the start. Dronebogus (talk) 14:51, 4 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. – bradv 02:04, 3 May 2023 (UTC)[reply]
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}}talk 02:17, 3 May 2023 (UTC)[reply]
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)[reply]
Support - I am sure that people will find a way to keep repeating the same arguments over and over anyway, but maybe this will decrease the frequency. -- Random person no 362478479 (talk) 04:17, 3 May 2023 (UTC)[reply]
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)[reply]
”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)[reply]
Sometimes blatantly uncivil people need a taste of their own medicine. We're all good, now. Zaathras (talk) 15:30, 4 May 2023 (UTC)[reply]
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)[reply]
Update for further clarity: I support all of the phrasing variations that have been proposed so far (at the time of my writing this, there are three). ModernDayTrilobite (talk • contribs) 15:02, 4 May 2023 (UTC)[reply]
So should we just combine them into one? Dronebogus (talk) 15:05, 4 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I support either the alternative or the initial proposal as both are better than the status quo. Thryduulf (talk) 10:59, 4 May 2023 (UTC)[reply]
@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)[reply]
@Jerome Frank Disciple: Sure. I'm only concerned that it isn't specific enough to be useful at all and will simply result in more RfCs, but go ahead. Nythar (💬-🍀) 14:37, 4 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
(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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I don’t see that as “harm”. Just less essential. Dronebogus (talk) 16:09, 3 May 2023 (UTC)[reply]
As for the RFC system being good… what alternate universe are you living in? Dronebogus (talk) 20:02, 2 May 2023 (UTC)[reply]
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)[reply]
A very long, contentious discussion that frequently gets re-discussed. Dronebogus (talk) 21:29, 2 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
It is neither good nor bad… it is, however necessary because one size does NOT fit all. Blueboar (talk) 20:49, 2 May 2023 (UTC)[reply]
“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)[reply]
@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)[reply]
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.
Sincerely, North8000 (talk) 20:18, 2 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@Dronebogus: It's not too late; you can post it as an alternate proposal. Go ahead if you want to. Nythar (💬-🍀) 02:28, 3 May 2023 (UTC)[reply]
I don’t want to confuse people with two distinct, but extremely similar, proposals running concurrently. Dronebogus (talk) 02:32, 3 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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}}talk 02:37, 3 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Option 4, for all aforementioned reasons. Still not convinced that a change would be helpful. ⛵ WaltClipper-(talk) 16:06, 4 May 2023 (UTC)[reply]
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. --Jayron32 12:45, 3 May 2023 (UTC)[reply]
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 Fuchstalk 00:05, 4 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
The change here is very minor and this RfC is far from a disaster. Nemov (talk) 16:32, 4 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Okay, the pictures thing is a blatant non-issue. Cropping exists. Dronebogus (talk) 00:01, 5 May 2023 (UTC)[reply]
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)[reply]
Oppose per Nikkimaria and David Fuchs. Ajpolino (talk) 18:25, 5 May 2023 (UTC)[reply]
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)[reply]
Oppose This is an issue of local consensus. ~ HAL333 22:10, 6 May 2023 (UTC)[reply]
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. ~ HAL333 01:56, 10 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Oppose. Better not to create anything mandatory. Decide on a case-by-case basis. --Tryptofish (talk) 21:54, 18 May 2023 (UTC)[reply]
Just for the sake of clarification, there's nothing mandatory in this proposal. Nemov (talk) 22:06, 18 May 2023 (UTC)[reply]
Thanks, that was a bad word choice on my part. Maybe "formulaic" would have been a better word. --Tryptofish (talk) 16:34, 19 May 2023 (UTC)[reply]
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)[reply]
Discussion (establishing a biography infobox guideline)
@Redrose64: I've added a signature. Need anything else? Nythar (💬-🍀) 19:19, 2 May 2023 (UTC)[reply]
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)[reply]
I've signed it. Thanks for all your help! Nythar (💬-🍀) 19:25, 2 May 2023 (UTC)[reply]
We'll see if it worked when Legobot next runs, just after 20:00 (UTC). --Redrose64 🌹 (talk) 19:36, 2 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
How much is "enough" verifiable data? Nythar (💬-🍀) 12:56, 3 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
"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)[reply]
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)[reply]
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)[reply]
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)[reply]
B. Traven is a famous writer, though :) —Kusma (talk) 15:50, 4 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
"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)[reply]
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)[reply]
@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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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. --Jayron32 18:29, 4 May 2023 (UTC)[reply]
@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)[reply]
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. --Jayron32 11:39, 5 May 2023 (UTC)[reply]
Well, I'd have preferred a simpler solution, but that seems quite difficult to agree upon. Nythar (💬-🍀) 15:25, 5 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
Pre-1900 is a little extreme. I was thinking like ancient lives, before the bith of Jesus even. Dronebogus (talk) 16:02, 4 May 2023 (UTC)[reply]
Off topic
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)[reply]
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)[reply]
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)[reply]
If you're taking that route, I'd suggest deleting "try writing an article" from your 13:18 comment before you deny saying it.--Jerome Frank Disciple (talk) 14:14, 3 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
This is an interesting idea. How would it be used in practice? Nemov (talk) 13:33, 3 May 2023 (UTC)[reply]
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)[reply]
That scenario would essentially be the status quo. Nemov (talk) 13:49, 3 May 2023 (UTC)[reply]
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)[reply]
[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)[reply]
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)[reply]
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)[reply]
It’s arbitrary because it’s not part of an existing thread. Why do we even need a rule about this? THAT is WP:CREEP. Dronebogus (talk) 14:29, 3 May 2023 (UTC)[reply]
@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)[reply]
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)[reply]
That’s the second time I’ve been called “Dronebugs” in a week 😆 Dronebogus (talk) 14:49, 3 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
Can you name one person who has stated they are opposed to IBs on principle? - SchroCat (talk) 16:19, 4 May 2023 (UTC)[reply]
David Eppstein didn’t literally say that but he made it clear he’s opposed to infoboxes period. Dronebogus (talk) 20:18, 4 May 2023 (UTC)[reply]
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)[reply]
Oh, gosh, there are options now? In a CENT RFC that was already in progress? This is going to become a trainwreck. ⛵ WaltClipper-(talk) 15:59, 4 May 2023 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
Sorry, reviewing above I pinged the wrong person. You can ignore my question. Nemov (talk) 17:04, 4 May 2023 (UTC)[reply]
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)[reply]
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 Disciple 14:15, 5 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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 Disciple 16:42, 5 May 2023 (UTC)[reply]
Isn’t that kind of… disruptive? System-gamey…? Dronebogus (talk) 19:22, 5 May 2023 (UTC)[reply]
"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)[reply]
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 Disciple 17:47, 5 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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 Disciple 23:53, 5 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
“If a bio needs one, it probably has one and adding one wouldn’t be controversial” is circular reasoning. Dronebogus (talk) 00:58, 7 May 2023 (UTC)[reply]
No it’s not. (And please don’t use quote marks for something I haven’t actually said). - SchroCat (talk) 03:23, 7 May 2023 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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)[reply]
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)[reply]
You can still find them even in papers published this century, e.g. this one from 2017 (p. 10, figure 3). Admittedly, they aren't as common as they used to be. Double sharp (talk) 21:29, 4 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Pretty sure all of the symbols are out of copyright. Planet symbols says they date from the 16th century. --Jayron32 12:55, 4 May 2023 (UTC)[reply]
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).
However, a better solution might be to avoid these images entirely and use the Unicode characters as shown on Astronomical symbols. Barnards.tar.gz (talk) 13:02, 4 May 2023 (UTC)[reply]
That’s a great idea. Why haven’t we already done this? If you can use unicode for symbols, you should. Dronebogus (talk) 15:03, 4 May 2023 (UTC)[reply]
Many browsers cannot display them properly. Some more common symbols such as the Sun or Earth is more well supported. CactiStaccingCrane (talk) 15:32, 4 May 2023 (UTC)[reply]
90% of these are simple geometry. Copyright is moot. Dronebogus (talk) 14:55, 4 May 2023 (UTC)[reply]
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)[reply]
Oppose As a singular use, I don't see any problem with them. --Jayron32 12:54, 4 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Sun apart (which uses a bespoke infobox), the change is really very simple - this is all. For demonstrations, see testcases sections for Earth, The Moon, Mercury and Uranus. --Redrose64 🌹 (talk) 19:22, 14 May 2023 (UTC)[reply]
I've WP:Boldly done the change for the Sun, because the consensus here seems to be moving the symbols to somewhere else in the infobox. CactiStaccingCrane (talk) 06:56, 15 May 2023 (UTC)[reply]
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)[reply]
MOVE - but not Remove. The symbol should be listed in the infobox, but not as part of the box title. Blueboar (talk) 20:07, 14 May 2023 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Thanking administrators for blocks
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)[reply]
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 contributions 19:00, 6 May 2023 (UTC)[reply]
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 contributions 19:24, 6 May 2023 (UTC)[reply]
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 contributions 19:28, 6 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
@Ivanvector: Per what?? The UPPERCASEs are getting cheeky these days! jp×g 16:13, 8 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
Weak oppose per Ivanvector and Kusma. Thryduulf (talk) 20:48, 6 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
Oppose per Ivanvector. Some1 (talk) 21:58, 6 May 2023 (UTC)[reply]
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.) AddWittyNameHere 23:06, 6 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Oppose. Would create avoidable drama. Nardog (talk) 00:47, 7 May 2023 (UTC)[reply]
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)[reply]
Strongly oppose. Blocks are necessary, but they're also a kind of failure. Nothing to celebrate. Isaac Rabinovitch (talk) 01:10, 7 May 2023 (UTC)[reply]
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)[reply]
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 Albury 12:48, 7 May 2023 (UTC)[reply]
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)[reply]
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. -- GreenC 15:10, 7 May 2023 (UTC)[reply]
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. —Cryptic 15:29, 7 May 2023 (UTC)[reply]
Strong Oppose - Comes off as going against WP:AGF. It would provide absolutely nothing of value. KatoKungLee (talk) 17:11, 7 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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 contributions 14:10, 8 May 2023 (UTC)[reply]
Oppose per Spicy; thanking for blocks wouldn't seem to add anything important besides gravedancing. -sche (talk) 21:16, 7 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Oppose, very un-classy. Where you do feel the need to thank a sysop, they have these things called talk pages.—S MarshallT/C 07:49, 8 May 2023 (UTC)[reply]
Oppose Gravedancing. We don't celebrate people having to be blocked. --Jayron32 14:08, 8 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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×g 16:11, 8 May 2023 (UTC)[reply]
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 solving 16:32, 8 May 2023 (UTC)[reply]
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)[reply]
Oppose. Just send the admin an email if you want to express your appreciation. – wbm1058 (talk) 18:19, 9 May 2023 (UTC)[reply]
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)[reply]
Oppose Smacks of grave dancing.--Wehwalt (talk) 01:02, 10 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
If there was support from this RfC, I would have been uploading the change and pushing it into production. However, as there doesn't seem to be consensus that is a moot point. Dreamy Jazztalk to me | my contributions 18:13, 14 May 2023 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
@Redrose64 and ActivelyDisinterested: I reformatted this discussion into an RfC, to resolve the dispute over the utility of the geohack link vs the kartographer link. Galobtter (talk) 07:21, 11 May 2023 (UTC)[reply]
The fallback on "desktop" version when on mobile is working in the examples. So I can't give an opinion as nothing changes for my setup. -- LCU ActivelyDisinterested∆transmissions∆ °co-ords° 21:13, 11 May 2023 (UTC)[reply]
Technical feedback/reporting any issues with the change is also appreciated. Galobtter (talk) 07:21, 11 May 2023 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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, [6]. 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)[reply]
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)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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)[reply]
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)[reply]
I'm pretty sure this has been requested and rejected before. Most recently in 2022, IIRC. --Redrose64 🌹 (talk) 20:15, 10 May 2023 (UTC)[reply]
@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)[reply]
I don't recall. But there is guidance at MOS:CRORE, which has links to {{lakh}} and {{crore}}. --Redrose64 🌹 (talk) 22:45, 11 May 2023 (UTC)[reply]
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)[reply]
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)[reply]
@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)[reply]
Creating "Requests for rewrite"
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)[reply]
This could be an option both for articles that have been deleted via AfD or as an alternative to nominating an article for AfD. Blubabluba9990 (talk) (contribs) 22:20, 14 May 2023 (UTC)[reply]
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)[reply]
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.
Together, let's shape the future of the Wikipedia iOS app! ARamadan-WMF (talk) 07:58, 15 May 2023 (UTC)[reply]
RFC: Close LTA as historical for declining involvement, and to deny recognition to vandals
One thing leads to another. I saw a bunch of LTA pages that should have been archived and requested that to be done [7]. Looking at the discussion, I saw that one admin recommended that the page be marked historical due to a relative lack of recent edits [8]. I think Wikipedia has gotten better at preventing long-term abuse, so the number of LTAs has declined in the past few years. Many vandals also celebrate the recognition they get from these kinds of pages. What do you think?
.svg){kind=small}
You are invited to join the discussion at Wikipedia talk:Backlog. Snowmanonahoe (talk) 17:57, 11 May 2023 (UTC)