This page contains discussions that have been archived from Village pump (policy). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
Greetings. I noticed today (September 11th) on the anniversary section of the home page, a photo of United Airlines Flight 175 hitting the WTC South Tower, representing the anniversary of 9/11. Is there a policy preventing potentially distressing images (e.g. photos of graphic violence or serious injury, porn, etc.) from appearing on the home page? I understand that some articles, such as those on wars or atrocities, will warrant the use of potentially distressing images for illustration. But a visitor to an article like that will likely understand the risk of seeing those kinds of images if they know anything about the topic of that article. I don't think the same could be said for the home page.
Of course different people have different views on what amounts to a potentially distressing image. Nevertheless, I'd imagine that memories, reminders and depictions of 9/11 have traumatic impact on a wide swathe of people—people who were personally affected by the attacks (directly or indirectly), people who were distressed by watching them play out, people who have been affected by other aviation accidents, or even people who (like me) just have a low tolerance for these things. With all of these factors in mind, I was surprised to see that the photo of Flight 175 was deemed suitable to appear on the home page. Thecolonpagesaretoocomplicated (talk) 16:47, 11 September 2024 (UTC)
It's fairly uncomplicated: Wikipedia is not censored, unfortunately. If you've perused the Main Page for any length of time, you've likely seen dozens of images that were similarly distressful to individuals from different backgrounds than yours. Like with every other content issue, we reflect sources in what visibility we give these features, and there's just no getting around that this is one of the most famous images of the 21st century, ugly as it is. Remsense ‥ 论16:49, 11 September 2024 (UTC)
"Wikipedia is not censored" doesn't mean run whatever on the main page. I read the front page every day, I do not see dozens of images that are similarly distressful, or distasteful (can anyone point to three from the past year?). Of course that image should be in the article(s) about the attack, but there's really no reason to have an image of thousands of people being murdered on the front page every damn year. So, it bothers me, too, OP, you're not alone. I think it's callous of Wikipedia to put "violence porn" on the front page. (I also don't love that it's the lead image of the 9/11 article instead of being further down in the article, but having it in WP:OTD is much more gratuitous.) (Another example like this: the Hiroshima/Nagasaki "mushroom cloud" atomic bomb images.) Levivich (talk) 19:44, 11 September 2024 (UTC)
I'll put it like this: I personally loathe this about as much as you've expressed you do, but I am looking in my pockets for a way to make the argument you're making that's congruent with fundamental site policy and I am coming up with nothing. I am explicitly not making this about our ~~integrity as editors~~ because that would be inane and I respect my interlocutors a lot more than that, but sometimes we write and gleefully present violence porn because our reliable sources are violence porn, and there's no distinction I can honestly make there that makes any sense when taken to its logical conclusion.. Remsense ‥ 论19:55, 11 September 2024 (UTC)
I hear ya. I would say we can choose a different image for 9/11 OTD (even a different 9/11 image, like the famous one of the rubble). That doesn't conflict with any site policies. And we don't have to take it to its logical conclusion (whatever that may be). We can choose an image for the main page for a particular item, and in making that choice, we can be sensitive to various sensitivities. I think what you're saying about us being effectively bound by policy is very true when it comes to article content--no way we can exclude that image from the 9/11 article and be in line with policy--but on the main page, we have discretion what photos to show. Just as we pick POTD based on aesthetics, we can be selective about OTD, DYK, etc. NOTCENSORED doesn't mean we can't make a good choice when we have several options, and there are many iconic 9/11 photos to choose from (firefighters running up the stairs while everyone else is running down, Bush with the megaphone, twisted steel of the tower ruins, just to name a few). Levivich (talk) 22:18, 11 September 2024 (UTC)
There's also nothing in our policies that requires us to include an image of any specific event in the list every single year. We could and perhaps should rotate them: This year it was the twin towers, and next year it can be the 30th anniversary of the space station trip, and the year after, we maybe we would choose an image for the 250th anniversary of the Staten Island Peace Conference. WhatamIdoing (talk) 22:37, 11 September 2024 (UTC)
Totally not trying to undermine peoples' points, I think they're right and we don't disagree about anything really, but I got myself curious: 9/11 was not mentioned by OTD in 2008, 2010, 2014, 2015 (was TFA), 2016, 2019, 2021, and 2022. Remsense ‥ 论22:52, 11 September 2024 (UTC)
I did the same thing and noticed that it ran in 2020, 2023, and now 2024. The OTD images do rotate (and thank you to the volunteers who rotate them). I think this is easily fixed; this image sits in the image bin for that date. Tomorrow I'll swap it for another one. That way when we rotate in a 9/11 image next time, it'll be a different image. Or I'll get reverted and reported at ANI. One of the two. Levivich (talk) 23:02, 11 September 2024 (UTC)
I am looking in my pockets for a way to make the argument you're making that's congruent with fundamental site policy: The WP:OM guideline states that Images containing offensive material that is extraneous, unnecessary, irrelevant, or gratuitous are not preferred over non-offensive ones in the name of opposing censorship and that When multiple options are equally effective at portraying a concept, the most offensive options should not be used merely to "show off" possibly offensive materials. By citing this I don't mean to say that I think the image offends a person's sensibilities on like a propriety/decorum level but rather that, as OP says, the image can cause distress—'offend' in the sense of causing pain or hurt feelings. All that to say, it's entirely consistent with guidelines and policy to deliberately refrain from showing an image on the main page on the grounds that it's gratuitous and distress part of the readership when the relevant idea can be meaningfully conveyed with a different image. Hydrangeans (she/her | talk | edits) 02:47, 12 September 2024 (UTC)
But it's still ultimately the prevalence that guides choices, not whether they're offensive. It just so happens that offensive material is generally less prominent in RS, so we follow. Remsense ‥ 论02:56, 12 September 2024 (UTC)
As a New Yorker who was in downtown NYC and saw 9/11 with my own eyes… I think it is GOOD that the images of that day are distressing. They should be. They remind us that it was a horrific incident. Don’t EVER sugar coat it. Remember it. Blueboar (talk) 19:56, 11 September 2024 (UTC)
Using violence (in imagery or graphic text or whatever) for the sake of remembering violence (as opposed to, in reading an article, the purpose of education) is generally not a good idea. The selection of an image for the front page to be something rather than something else is not necessarily a "sugar coat" unless you're using you're using an image that is pretty much burying the lead -- an opaque coating around the point of the article, say.
The 9/11 article encompassing a long series of events (the aftermath being arguably orders of magnitude more significant for the world than the events of the day itself), one has a choice of many such events from which to take a headline image. A plane crashing into something, while a dramatic image and certainly a trigger moment for the event cascade, does not necessarily have to be the only kind of image that's justified for a headline (although it is certainly necessary for the article). And that day had a number of critical images that replayed on TV for days, not just the airplanes smashing into buildings. (And also remember that certain images were self-censored by media very early on, such as video of people jumping from the towers, which thus while shocking on the day of, has perhaps a less persistent memory because it was not replayed endlessly -- but would that not perhaps be a more powerful representation of the human tragedy?)
I don't have an alternative image to suggestion, from the day of Sept 11 itself, that isn't by some extension comparably morbid: showing both towers before the plane hits, or showing one tower in smoke is showing people about to die, and showing rubble is showing dead bodies. But those are probably have less violence-in-motion, this-is-people-being-killed-in-front-of-you, than the plane in the process of crashing. SamuelRiv (talk) 20:23, 11 September 2024 (UTC)
I don't know whether it's a good or a bad thing, but we have definitely become more squeamish about such things during my lifetime. As a child I watched TV programmes such as All Our Yesterdays which showed footage from World War Two, much of people being killed (usually off-screen, such as films of bombing raids taken from the bombers' point of view), but I don't remember any complaints, even about children watching. Phil Bridger (talk) 21:23, 11 September 2024 (UTC)
I think like most comparisons of this ilk, a large part of it is "people previously had fewer opportunities to voice the nuances of their opinions about media for you to notice". Remsense ‥ 论21:27, 11 September 2024 (UTC)
We have had Wikipedia editors whose parents survived WWI or who lived through WWII themselves.
The television show mentioned above started airing in 1960, so it is reasonable to assume that every adult watching it had lived through the events, and that some fraction of them were watching events that had affected them very personally (e.g., the bombing raid that destroyed the family home). WhatamIdoing (talk) 22:49, 11 September 2024 (UTC)
Phil_Bridger gave an impression of their personal recollection of the show which seems like they were not watching their civilian peers in their country or hometowns getting bombed, which fundamentally contrasts to the TV experience that Blueboar describes. Therefore, the notion that "we have definitely become more squeamish about such things" seems to be unsupported by that anecdote, which is what my point is.
Furthermore, to give a contrasting anecdotal argument: my own experience is that older generations tend to be more reluctant to reflect on pain of their past in detail (whether theirs or of their peers) (which in my anecdotes would correlate at least somewhat to education, as those with more education seem more likely to value history for its own sake, as opposed to "letting the dead rest in peace" as one person told me; and education has improved dramatically across populations across the world.) SamuelRiv (talk) 00:58, 12 September 2024 (UTC)
To be clear… my experience was live rather than on TV. Not only did I witness it all with my own eyes, I personally knew two people who were in the Towers that morning and didn’t make it out.
So yes, even after 23 years, seeing graphic images of 9/11 can bring back some very strong memories (sights, sounds and smells)… but, each time I see them, each time I mentally re-live that day, there is also some catharsis. The pain heals… the sadness-mixed-with-anger fades… That’s a good thing. Blueboar (talk) 12:58, 12 September 2024 (UTC)
IMO, any generalization to the tune of "we used to be more/less sensitive to this" that stretches back to cultural memory of WWII is going to be a major oversimplification. There's been many wars and generations since then, and attitudes toward cultural memory of each have shifted over time and place (not to mention that there is no unified historical "we" that we as Wikipedia editors can point to that covers this time period). signed, Rosguilltalk14:50, 12 September 2024 (UTC)
The entire premise of this discussion starts with the idea that the image in question is on the same level as graphic violence or serious injury or porn, which it... very much isn't. An atomic mushroom cloud, likewise, is not graphic violence even if it is connected to extreme losses of life that lots of people today still have strong feelings about. They aren't gratuitous, they are massively important images that are part of the cultural awareness of these events. You can take complaints about the lead image of September 11 attacks to the talk page of that article, where I imagine one will find much support for changing it. Der Wohltemperierte Fuchstalk14:36, 12 September 2024 (UTC)
I think it's totally fine to cede all territory here, as people are fully expected to have a wide variety of emotional responses mediated by social association and context, even if the media isn't explicit. My first and imo strongest point was merely that—while avoiding being overly reductive or obtuse about it—Wikipedia has plenty to offer in terms of distress for different members of its readership. That's why I'm genuinely wary about going too far out of my way to advocate maximal tastefulness on the front page—one possible outcome are a general censorship if we try really hard to be fair to everyone while being maximally tasteful, or an ebb in the wrong direction towards presentation based on the type of people Wikipedia editors tend to be, rather than who readers are intended to be. Remsense ‥ 论14:50, 12 September 2024 (UTC)
I had an archived CBAN/Indef proposal that got archived without any action, but pretty much all users agreed there was a case for supporting one. What should I do? Allan Nonymous (talk) 14:03, 13 September 2024 (UTC)
Per WP:NSPORTS2022 Proposal 5 and the subsequent update to WP:SPORTSCRIT, there is consensus that sports biographies are not subject to WP:NEXIST and are automatically subject to deletion if they do not contain at least one source demonstrating significant coverage in the article. To this point, cleanup has been slow as a courtesy to AfD. I propose CSD X4 so the articles can be addressed without causing a significant backlog. X4 would only apply if there is unambiguously no source to demonstrate significant coverage in the article, meaning borderline sigcov would still need to go through AfD or PROD. Articles sourced entirely to databases or passing mentions would qualify for X4 deletion. X4 would be an alternative to mass AfD nominations, which will be the likely outcome if no action is taken. Thebiguglyalien (talk) 21:24, 6 September 2024 (UTC)
I don't read the close of NSPORTS2022 as saying that such articles must be deleted, but rather that for an article to be created it must have at least one source with SIGCOV. voorts (talk/contributions) 21:32, 6 September 2024 (UTC)
Thank you! I considered this the most "central" location and went to notify other places, but I got distracted after adding it to COIN. I have no objections if anyone thinks this should be moved to WT:CSD. Thebiguglyalien (talk) 21:51, 6 September 2024 (UTC)
(edit conflict) Firstly new CSD criteria should be proposed at Wikipedia talk:Criteria for speedy deletion (I'll notify them for you) and should demonstrate that they meet all four requirements listed at WP:NEWCSD. My first impression is that this would fail at least point 1 (objective) because what coverage counts as "significant" is subjective and whether coverage meets that standard is frequently a matter of disagreement at AfD. AIUI there is also frequent disagreement about what counts as a database and whether database entries are always non-trivial coverage. Thryduulf (talk) 21:52, 6 September 2024 (UTC)
Speedy deletions are for situations where the deletion criterion is clear and the deletion of articles meeting that criterion is uncontroversial. Past discussions of sports stubs have made it obvious that both of these conditions are not met here. —David Eppstein (talk) 21:57, 6 September 2024 (UTC)
I regularly see athlete articles prodded, in the list at WP:PRODSUM, often in large batches. I haven't been keeping track of how successful the prods are but I think it's a good thing to try first before resorting to an AfD. —David Eppstein (talk) 22:08, 6 September 2024 (UTC)
All right, thank you. I do feel a little silly now that the points above have been raised. I'm just working through the NPP backlog right now and trying to find some sort of way to make it more efficient when sorting the good from the bad. Thebiguglyalien (talk) 22:10, 6 September 2024 (UTC)
If your goal is efficiency or a minimum of drama, I think that you should not try to delete any "borderline" cases. Using WP:PROD on egregious examples, with a good explanation and a link to the requirements, isn't likely to earn you many wiki-enemies. However, trying to remove (by any means: AFD, PROD, Draft:, etc.) any subject for which SIGCOV is perhaps a matter of judgement is not likely to win friends and influence people. In particular, I suggest turning a blind eye towards any subject that someone could claim as SIGCOV under WP:100WORDS. WhatamIdoing (talk) 00:24, 7 September 2024 (UTC)
There are 3 things I want to see in any X series new criterion proposals. Firstly, I want to see a list of the pages subject to the new x criterion. This is typically a page compiled in user or project space somewhere. This both defines the scope (how many pages are we talking about), and lets people take random dip samples. The second thing I'm looking for is a consensus that many or most, but not all or nearly all, of the pages subject to the criterion should be deleted if the appropriate consensus based process was run in full. If all or almost all of the articles should be deleted, make a single mass nomination at the appropriate XFD, or else have a RFC linked from that XfD. The third is a limit date, or some other way to demonstrate that the flow of new articles into the X series eligible pool has stopped. This is to ensure that an x series criterion doesn't grow in scope. No opinion on the merits of these articles, but I do need this info before I can weigh if X4 is an appropriate response. Tazerdadog (talk) 01:42, 10 September 2024 (UTC)
The problem is that, so very often, when these items are taken to AfD sources are found. There are a few folks at the NFL WikiProject who actually end up saving a lot of pages at AfD but will also vote to delete pages that they can't find sigcov on. I don't think it becomes uncontroversial to delete player pages unless we can find something less arbitrary than "does not currently contain sigcov". Hey man im josh (talk) 14:07, 16 September 2024 (UTC)
Starting a compilation of Wikipedia policies
I took long hours to condense core content policies into one document. By my calculations, I can retain at least 95% of the meaning of the policies, including most of their intricacies and details, by using only about a third of space that the policies and guidelines, scattered among multiple pages, now take (I estimated from raw text that the policies and guidelines I summarised have about 530 KB of raw text but under the compilation have just 173 KB - still a lot but much better).
It was a hard task and appears about as hard as working in one person to recompile the Constitution of Alabama - a ridiculously long document running at 373K words - 420K words before 2022 (for comparison, War and Peace is 587K words, and there's a good reason they publish it in volumes), but I think it is more than worth it, as people will have a unified set of policies that will be easier to read for people because there's gonna be much less of that but reflecting the same meaning. The overabundance of policies is one reason we have few new editors - there are too many rules, and then folks just randomly throw WP or MOS shortcuts not immediately obvious to the bystander, and suddenly nobody wants to join a project with United States Code-long rules and obscure jargon.
I will appreciate all feedback from you - positive or negative - and preferably some help into condensing further policies and guidelines, such as those about conduct, legal, editing etc. into one page where everything belongs.
I wish you well in your endeavour, but am worried that it will fail in the end because everyone thinks that "their" sub-sub-clause is vitally important. I admit that I rarely look at policies or guidelines now, but find a few basic ideas, along with common sense, to work. Phil Bridger (talk) 12:14, 22 August 2024 (UTC)
That works for me as well (I normally look into the rules on an ad hoc basis), but then you wouldn't need all those volumes of tiny rules covering, like, 99% of cases, and yet here we are. Also, admins themselves need a clear set of rules for proper enforcement (even if you catch the gist that the persob is just NOTHERE - an essay btw - you still kinda need a more concrete reason that just "that's my hunch")
It's like with RL: pretty common-sense that you shouldn't kill or rob anyone, or what appears common-sense like not using the army or the government to finance/securre your own reelection campaign, and yet these are codified lest anyone have an idea to bend the rules. Szmenderowiecki (talk) 17:29, 22 August 2024 (UTC)
This exists WP:Nutshell and I think your effort is noble but better focused on improving accessible language and navigation of existing guidelines for newcomers. Twinkle has feature to welcome new users for example. WP:Mentor finds ways to automate assisting newbies. ~ 🦝 Shushugah (he/him • talk) 12:47, 22 August 2024 (UTC)
Just to pick one example. There's no policy that an article must have (any) sources, let alone one. Yet we consistently advise new users to create articles with multiple sources. Save the edge cases and careful readings of guidelines/policies for advanced users who want to push the margins or change consensus. ~ 🦝 Shushugah (he/him • talk) 12:49, 22 August 2024 (UTC)
Actually there very much are two policies that prohibit articles without sources:
Verifiability says that you should only add content that you can check against a reliable source, and that you can remove any unsourced content
No original research says you just can't make stuff up. The only way you can have some sort of content is if it can be supported by a reliable source. Technically just have to demonstrate that the source for the passage is somewhere but if you don't provide it in the article, you can totally expect it to be removed and it's gonna be your problem.
No, policy prohibits unverifiable articles, not unsourced articles. Sources are required for BLPs and anything that is likely to be challenged should include a source (but this doesn't have to be inline). An article List of uncontroversial statements of fact consisting of things like "The sky is blue", "Many people are Catholics", "The 1970s happened before the 1980s", etc could be completely fine (it would be deleted, but for reasons completely unrelated to not having sources). Thryduulf (talk) 17:28, 22 August 2024 (UTC)
Look, I'm not making this up:
Any material lacking an inline citation to a reliable source that directly supports[b] the material may be removed and should not be restored without an inline citation to a reliable source
Which de facto means that if you are adding unsourced content, you are wasting your time as any editor may come by and just remove what you wrote, tell you "lacks an inline citation, I don't care why, pics or it didn't happen" and you are gonna still default to having to add a source (and then again giving time to fix it is a courtesy you needn't, though probably should, extend; though if you have the means to fix it yourself, you should do it)
So there's no obligation to source an article only in the most literal reading of policies. Anyone can enforce this policy provision. WP:SKYISBLUE is just an essay, although one with a pretty large following (and which totally makes sense for me, which is why there is a footnote to that effect) Szmenderowiecki (talk) 17:47, 22 August 2024 (UTC)
... any editor may come by and just remove what you wrote ...: the operative word is may. The reality is there's loads of unsourced text on WP, much of which will take years for it to be challenged, if ever. —Bagumba (talk) 18:29, 22 August 2024 (UTC)
And from what I've seen, deleting uncited material without a good-faith attempt to find a source (similar to WP:BEFORE) is considered disruptive (at least at high volumes). jlwoodwa (talk) 03:35, 16 September 2024 (UTC)
This highlights one of the issues with a monolithic policy body, is that the social norms of Wikipedia are not given their own space for each topic. This would encourage further unconstructive legalistic interpretations of pages that are meant to facilitate us getting on with improving the encyclopedia instead of fighting all day or indulging our own personal compulsions with policy as a fig leaf. Monolithic codes of law can work when they are used and interpreted by legal professionals whose job is to use and interpret them, but not ordinary people trying to contribute to a community project.Remsense ‥ 论03:46, 16 September 2024 (UTC)
So if this is the "informal norm", codify it. And Wikilawyering will not disappar overnight, that's for sure. TBH the "social norms" aren't really codified in one place, either - they are dozens of pages and that just makes the learning curve steeper than it already is. Szmenderowiecki (talk) 02:01, 18 September 2024 (UTC)
It has been tried before. Take a look at Wikipedia:Attribution, an attempt 18 years ago to consolidate some policies. Some very active and well regarded Wikipedians put a lot of time and effort into that proposal, but it was rejected by the community. Consensus can change, but I suspect the community remains just as resistant to change as it was then. Donald Albury20:07, 22 August 2024 (UTC)
So I did read the poll, and a lot of stuff that was probably relevant here doesn't apply:
Users were complaining about lack of participation/that proposal being forced down their throats as policy - not an issue here (yet)
Merger of NOR, V, RS didn't appeal to people - not abolishing them, just giving sections to these concepts, not a problem.
Users complained about one massive page, or that they preferred separate policies rather than a massive policy code - well that is an issue to discuss but again it's not something that should extinguish all debate before it even starts.
Disgusted that truth is deprioritised - kinda not applicable here, because I'm not changing the framing of policy, just condensing it.
Change is unnecessary - again, debatable but let's have that debate in the first place
WP-links - well, you will have them all you like. Again, something to be discussed.
Assessment of any changes and their impact on disputes - to be discussed, again. This is how rulemaking process should work.
"If it ain't broke, don't fix it" - my whole point is that it is, in fact, broke, so needs fixing.
And again, you can say "meh, we tried eons ago and it didn't work, why bother anymore" but that's gonna be a catch-22, because nothing will change without discussion, which you don't want to hold anyway.
I believe the attitude should be "OK, let's see what you did there and if it makes any sense". It would be another thing if you told me why what I did was bullshit, which is fine. Szmenderowiecki (talk) 18:45, 23 August 2024 (UTC)
I know, but that's not the point of the compilation. What you are pointing to has a different purpose.
Nutshell, WP:5P etc. is a post hoc summary of policies and guidelines that summarise the main goals in slogans. Just like a company saying "we want to increase the market share; we want good treatment of workers" but not saying how.
WP:SIMPLE is a very high-level summary of policies and guidelines. It's the company analogue of saying: Good treatment of workers means paying more than the minimum wage, giving them extra breaks, paid leave and some other perks, without telling much specifics.
The body of the policies and guidelines is like all internal company directives about pay grades, conditions of getting worker benefits, levels of compensation, powers of HR/executives etc. This page intends to clean up all this body of policies and codify them in a couple of places, grouped by category, so that we remove unnecessary bloat, as in too many redundancies and passages repeated across different policy pages, extraneous comments etc.
@Szmenderowiecki, I don't feel like you're hearing what people are telling you, so l'm going to try a completely different, un-Wikipedian way of explaining this, because the previous efforts haven't worked, and maybe this will get your attention. Here's my new way:
Hi, Szmenderowiecki, and welcome to Wikipedia! I see you've been editing for just four and a half years, and that you've made a few hundred edits at Wikipedia:Reliable sources/Noticeboard, which I really appreciate. I don't know if you knew this, but you're in the top half a percent of contributors for all time. I also notice that you've never edited a single policy, and you have only made one small, uncontroversial edit to a guideline.
Just so you know, most of the people who have responded to you in this discussion have been editing for 15 to 20 years, and have made between 50,000 and 170,000 edits. Also, relevantly, we've been much more active in developing Wikipedia's policy and guideline ecosystem. If you'd like to see an incomplete overview of my own policy-related work, then you can start at User:WhatamIdoing#Policies and guidelines you can ask me about.
Now that you understand who's at the table for this discussion, I want to point out that there is an English saying that fools rush in where angels fear to tread. Every person in this discussion has more experience than you, and every single one of them thinks that, even though your goal is laudable and praiseworthy and at least partially shared by everyone here, your approach is not likely to be successful. It is, of course, possible that you know better than any of us and that rushing ahead is a great idea, but I suggest to you that it is unlikely that all of us are wrong in urging caution and small steps.
If you think you could slow down and get some more experience, and if you're willing to consider doing this over the space of years, then I think we could help set you up for success. For example, if we implemented this idea, that would get about 300 words out of a policy. The next step is to write a good RFC question. If you're interested in this, you could get some practical experience by helping out. WhatamIdoing (talk) 22:26, 23 August 2024 (UTC)
I don't know if you realise it, and I guess you didn't mean it, but the comment has a very strong patronising "you are too young to understand" vibe which I have a hard time shaking off rn.
I asked you for specific input in opinion and help, and I just think the folks who suggested Nutshell etc. misunderstood my intentions. I apologise if I wasn't clear. My intent is to retain the same scope and level of detail but in fewer words.
If what you meant is to do it in increments, fine, that's an option, still I'd love some feedback if I fucked up with the text in the first place. That is valuable. I'm open to discuss it one-by-one. I will hear input from people who actually drafted policies. That was what I intended to do anyway. Szmenderowiecki (talk) 23:30, 24 August 2024 (UTC)
You've dropped things, rearranged things, and changed things, and I suspect you have done this without knowing what effects any of that will have.
For example, you've added the word secondary to the WP:GNG, and swapped in a description for the WP:SIGCOV language:
Original: "A topic is presumed to be suitable for a stand-alone article or list when it has received significant coverage in reliable sources that are independent of the subject."
Yours: A topic generally may have a stand-alone article or list when several reliablesecondary sources that are independent of the subject address the topic directly and in detail, so that editors do not have to resort to original research.
I've been trying to get a definition of SIGCOV for years (and years), and failing repeatedly because nobody wants to admit how long (or, perhaps more precisely, how low) "in detail" actually is, for fear that some "unworthy" subject might deliberately seek a qualifying level of independent media coverage. The NOR line in the GNG is basically worthless, and AFAICT removing it would have no effect whatsoever on AFD outcomes, but the fear of making changes to such a high-visibility sentence will likely prevent us from fixing that. Your [e] footnote requires a huge amount of work (e.g., primary sources aren't always about events, sources don't have to adhere to the neutral point of view, a smaller number of high-quality sources is not automatically less indicative of notability than a large number of worse sources).
At the time we started leaning on secondary sources (about 15 years ago), we had a lot of editors who thought that secondary was a fancy way to spell independent. You have added a requirement for secondary sources that does not actually appear in the GNG statement (though it is in the explanations). The GNG offers a conditional rebuttable presumption, which you have turned into a statement of permission (may/are allowed to have...). The GNG says that multiple sources are only "generally expected", rather than required, and you have changed that. Oh, and "several" is often interpreted, at least in American English, as meaning "four" (a=one, a couple=two, a few=three, several=four), whereas the GNG is usually looking for "two".
Among the things you haven't resolved is whether the sources for an article must be considered in isolation. For example:
If I have ten brief independent secondary sources, is that multiple+independent+secondary+SIGCOV, or just multiple+independent+secondary and no SIGCOV?
If I have SIGCOV in a very lengthy, extremely detailed independent primary source, and I have a non-SIGCOV secondary source, does that add up to multiple+independent+SIGCOV+secondary and therefore notability overall, or do I have to get all three key qualities (independent+secondary+SIGCOV) in each source separately?
@Szmenderowiecki, just so you know, I'm always going to be interested in this. If you want to talk about how to improve our written policies and guidelines, then feel free to drop by User talk:WhatamIdoing and tell me about your ideas. It doesn't matter to me if that's that's next month, or next year, or next decade – I'd be happy to hear your ideas whenever you want to share them. WhatamIdoing (talk) 23:19, 25 August 2024 (UTC)
OK, I'm finally back after fixing my phone with 2FA, I will respond to your suggestions above on the user talk page. It will be there in an hour or two. Szmenderowiecki (talk) 19:31, 7 September 2024 (UTC)
If anything, the project would benefit from more "fresh eyes"—editors with enough experience to speak somewhat intelligently about these issues, but without so much experience that they are heavily invested in the status quo. There is a strong, almost indisputable case that current PAGs are far too convoluted and complex for the project's good. As a practical matter, the core problem is that the self-selected self-governance model, which created the problem, is incapable of addressing it. Resistance is futile; hence my semi-retirement after about ten years of futile resistance. ―Mandruss☎02:54, 25 August 2024 (UTC)
I would add that it's useful to hear from editors who still remember their first few edits, because a sentence that makes sense to the "old hands" isn't necessarily any good for the majority of editors. An actual majority of editors has made five or fewer edits, total, ever. WhatamIdoing (talk) 03:02, 25 August 2024 (UTC)
It might be "useful" in supporting the position that current PAGs are far too convoluted and complex for the project's good (but I think that's self-evident). As for fixing the problem, not so much. Incremental change is never going to be enough; what's needed is massive overhaul, and that's just not going to happen under the current model. Meanwhile, the current model is sacrosanct. ―Mandruss☎04:45, 25 August 2024 (UTC)
I'll confess that I rarely look at the written policies & guidelines, & mostly use them as a citation when I need to emphasize a point to another editor. I consider what they say is basic common sense, but I've been around so long that I've probably internalized all of the important points. (This is not to say that the original poster is wasting their time. The written policies & guidelines have been considered a mess for countless years.) -- llywrch (talk) 01:49, 26 August 2024 (UTC)
This is part of the reason why English Wikipedia's guidance is sprawling: a lot of additions get made because a situation arises, some people say "we should have a rule for that", it gets added with a shortcut used for jargon, and editors brandish it in future discussions. As I've written before, it would be better to address problems without creating new specialized rules. But in English Wikipedia's current decision-making environment, there is little appetite to delegate to a working group to more effectively rewrite any pages. Amongst those who like to discuss these matters, there are enough editors who want to be able to weigh in on each sentence that it's hard to modify existing guidance pages, and instead we accrete more. Writing well is hard; writing well in a group is even more so. The irony of a crowd-sourced web site is that crowd-sourcing works best for making incremental changes, but consumes a lot of editor time in discussion for larger-scale changes. Which is why the path of least resistance for modifying guidance pages (and articles too) is to add a few sentences, rather than rework the pages. isaacl (talk) 23:22, 26 August 2024 (UTC)
As a new editor, adopting this would help me contribute more effectively. I would cautiously suggest that it seems like people know too many abbreviations. Support ForksForks (talk) 22:08, 26 August 2024 (UTC)
And we use different WP:UPPERCASE for the same page/section, sometimes resulting in one editor claiming that "WP:PAGE" supports his view and the next saying that "WP:SAMEPAGE" requires the opposite, and neither of them realize that they're talking about the same page. WhatamIdoing (talk) 00:35, 31 August 2024 (UTC)
I don't see any substantive argument that our current P&G structure / the ability for users to peruse it is actually problematic. It should be telling that those editors generally seeing potential in this are relatively new, and those who don't are relatively experienced. That's not (just) survivorship bias, that's experience indicating that what is perceived by some newer editors as a pedagogical issue is (as stated above) actually just the inherent difficulties in learning how to do something conceptually multifaceted and difficult.
Editing is just hard intellectually and socially, and there's no shortcut to becoming familiar with it to be found in compiling one huge document people will not be able to digest immediately versus having several documents. Remsense ‥ 论22:18, 26 August 2024 (UTC)
I agree with the inherent difficulties in learning how to do something conceptually multifaceted and difficult, but I believe there are more effective and efficient ways to communicate the PAGs than our current structure. I also believe it is pretty much impossible to replace the current structure with a more effective one, having seen what it takes to add a sentence to a policy. Schazjmd(talk)23:32, 26 August 2024 (UTC)
I think there are substantial improvements that can be made throughout each policy, or even refactoring involving multiple policies, but I think on the broadest level the modular P&G structure has no actual downsides—this isn't Justinian's code. Remsense ‥ 论23:36, 26 August 2024 (UTC)
Remsense No, and neither was that my point. The whole structure remains modular, just the modules are larger. As in, when you open a typical English textbook for foreigners, you have six books (A1-C2), each having 8-12 units.
Right now you have a separate page for every unit. I propose a separate page for a whole book, and all units get codified in one book.
So no, it's not gonna be one mammoth document, but maybe 5-8 big ones. Again, not even touching the Manual of Style.
That is more or less the reason why civil law countries have law codes. Instead of the law being scattered around 20-30 acts, you have a big one, but it resolves like 90-95% of cases. Any additional laws just build up on the codes. And even for American folks, the United States Code is sorted into 53 titles, and that organisation is in some sense not unlike that of civil law codes.
The downside is that yes, you get a tl;dr document (if you need the short story, WP:SIMPLE is indeed what you are looking for). The upside though is that you actually don't have to repeat parts of other policies in other places. Note how WP:V repeats a lot of RS because without it, V would kinda fall apart. Or how WP:OR has to remind of "related policies". Look at any subject-specific reliability guideline - depending on the size, up to half of it is copypasta from WP:N, and the only reason, apart from making the PAGs internally structurally sound, is to try to show that the policies are interconnected. In that large document, the one thing that connects all these policies is at the very top: why we need them. Because right now it's scattered all over the place. Other than that, the idea is to avoid redundant repetition. Szmenderowiecki (talk) 19:49, 7 September 2024 (UTC)
No, because a navigation template, either the one at the top or at the bottom - not sure which you refer to - is not intended to answer what the policy says, only shows you the way to actual policies. It's just a signpost, and it should stay that way. Very useful, but are not the thing I propose.
Why do we need to start a complimentary, high-complexity codification of documents which are already all in the exact same place? Again, this isn't Justinian's code, it's simply not the case that policies are "scattered all over the place".Remsense ‥ 论20:45, 7 September 2024 (UTC)
It is not "complimentary", it is intended as a replacement. And I'd say the current system has way more complexity because you need a hundred pages or so, a couple of FAQs, explanatory essays that sometimes define scopes of guidelines (see WP:BIOMED) and a couple of essays that de facto have the force of a guideline.
And what's the "exact same place" anyway? I can think of no one such place other than a navigation template, and it's simply not good enough, because duplicating the same thing has numerous downsides. a) slightly different text will be interpreted slightly differently, and it's not like wikilawyering will disappear anytime soon, b) maintaining two instances of same text is harder than maintaining one, c) after a change on page A there may appear a contradiction either with same copy of policy on page B or with a different rule on page C, which the community may simply not notice at first.
And if you think there are substantial improvements that can be made throughout each policy, or even refactoring involving multiple policies, why haven't you proposed that yet? Like a rewrite of V or N or whatever? Szmenderowiecki (talk) 21:39, 7 September 2024 (UTC)
About WP:OR has to remind of "related policies": I wonder if we should pull that. It makes the pages longer and introduces some confusion (e.g., if someone cites WP:THISPAGE for a rule that actually belongs to WP:THATPAGE, but happens to get mentioned in WP:THISPAGE). WhatamIdoing (talk) 23:29, 8 September 2024 (UTC)
I'm all for condensing our guidance down where possible, but I have to agree with Remsense – I'm not sure the goal should be putting absolutely everything on a single page.
There are quite a few policies and guidelines which the average editor doesn't really need to understand in detail unless they're editing in the particular area where it applies. For example, you've included our guideline on reliable sources for medical topics in your compilation, but I'd say that's not a guideline every editor needs to know in detail. For the average editor, it's probably enough to know "medical topics have stricter standards on sourcing, and if medical topics ever come up in my editing there's a page out there I can consult for more information". I don't see the benefit in trying to squeeze the details of that guidance onto a single page together with every other policy.
Sometimes there's a good reason for guidance to be extremely detailed or unusually attentive to particular wording. Our notability guideline for companies comes to mind – it goes over what sourcing does and doesn't demonstrate notability in pretty exhaustive detail. But the details are there for good reason – there's a lot of bad actors out there who manipulate the system for commercial interests, so we need to be unusually strict and explicit about exactly how to determine notability.
Of course, there's still a lot of cases where these caveats don't apply and we really could condense things down without losing much. My advice would be a more targeted approach: rather than condensing everything at once, work out where the low-hanging fruit is and push for changes there. – Teratix₵13:11, 28 August 2024 (UTC)
Or rather, do you mean, the response to the proposal has reminded you of "On Exactitude in Science"?
The notion that one condenses a vast network policies to a simplified reference document, a map if you will, is well-founded (and as others have pointed out, a similar concept exists already in explanatory essays WP:Nutshell and WP:SIMPLE). Many objections posted here seem to be that currently the simplified essay does not accurately represent every single paragraph of every single policy accurately.
Fwiw, I think a complete from-scratch attempt at simplified reference document every few years, to be measured against whatever already exists, is a good thing. As people choose to direct new editors to one version or another, or as new editors opine on one or another, maybe something appears completely superior. Or not -- we have a bunch of independent ways of presenting the basic P&G. Currently you can choose to link from between 5 or more independent general editing tutorial portals for newbies (WP:NEWBIE, Help:Introduction, Wikipedia:GLAM/Beginner's_guide_to_Wikipedia, WP:MAN, etc.).
An explanatory essay is not new policy, and as long as it is in userspace it does not require consensus. I frankly think some of the behavior so far has been disappointing to the spirit of VP: when someone asks for feedback on a work in progress here, then we should at minimum be constructive. (And to be sure: any feedback with a tldr of "don't do this" or "nobody wants it" or "put your effort somewhere else" is the opposite of constructive.) SamuelRiv (talk) 20:59, 4 September 2024 (UTC)
Just for clarity, what I would mean by "simplified" in this case is not "this is the TLDR version" - you have pointed to enough of that but "this is the new comprehensive version, essentially same content, but we completely reviewed the text and made it clearer, shorter, neater, better organised etc.", with a dollop of advice from WP:POSA and a sprinkle of other advice about concise writing. Other than that, I agree. Szmenderowiecki (talk) 20:13, 7 September 2024 (UTC)
I guess I'd suggest to just keep your presentation delicate for a while. Presenting as an alternative/better tldr version might be received more openly, since you've seen the reaction here when talking about a total conceptual rules overhaul.
In evaluating the quality, since many P&G are separated into pages with separate Talk sections, you might take one section of your draft you think is pretty refined and present it to one of those pages to get feedback on whether it makes sense as a concise version, then make adjustments from there. Everyone here is aware of WP:Bloat, so after doing the refinement, go back to the section Talk page and say at some point, "what if this entire page were replaced with just this, would it break anything?", you might get a better feel for what's possible. SamuelRiv (talk) 21:58, 7 September 2024 (UTC)
The problem is, tl;drs are already there, and xkcd covers creating "this one tl;dr that solves everything" well. So I don't want to go that way.
As for your suggestions, I may be subjective in what I believe is refined, but let's try that. Just choose what you believe is the best summary out there. Just not the one that has cross-references to other policies in the text, because folks will cry wolf and claim that it's absolutely essential to understand the policy. Szmenderowiecki (talk) 22:25, 7 September 2024 (UTC)
Can we discourage indiscriminate automatic addition of Wayback archive links on all external links?
There are a bunch of Wikipedian meat-bots running around with an automated tool which indiscriminately adds Wayback Machine links to every external link in every reference on one Wikipedia article after another, either as an archive-url parameter for CS1 or CS2 citation templates, or using the {{Webarchive}} template for ordinary wiki-markup links.
While the Wayback Machine is a wonderful and invaluable resource that I use multiple times a week, and I am all in favor of adding archives for dead links (such as User:InternetArchiveBot currently does), adding a wayback link for every external link on Wikipedia, including all of the still live and publicly accessible URLs, seems to me extremely spammy and moderately reader-hostile. It wastes a lot of space, is confusing to readers, wastes time/attention and causes confusion for editors trying to verify claims in articles, and seems mostly like a way of turning Wikipedia into a massive advertisement for the Internet Archive. I personally think the Internet Archive is wonderful and well worth supporting with money and use, but this method feels really icky and unjustified to me, not that different in spirit from Wikipedia adding banner ads for third-party charities or individual Wikipedians indiscriminately spamming links to their own published papers. It feels abusive of Wikipedia as a platform and of the Wikipedia community, and as far as I know there was never any consensus for it.
Can we formalize some kind of policy discouraging indiscriminate automatic addition of archive links? If human editors want to deliberately add individual specific wayback backups for still-living pages for some good reason (e.g. a website changed their content, substantially changed their formatting, or put up a paywall, in a way that makes the original content difficult to use for verifying the claims in the article) I have no problem with that. And again, as I said above I am all in favor of adding wayback backups (including automatically) to dead links.
One thing that I suggested above is that rather than discourage the creation of the archive link (which is quite understandable at least when the person originally constructing the reference wants to make it bulletproof), we have the cite templates only display the archive if the link status is "dead" or some similar status that indicates that the original link is no longer appropriate. (I also question whether we need the statement archived at Internet Archive displayed on references even when the original URL is dead; anyone following the archive will see the site it's at, it doesn't really inform the reader about the quality of the source material, and as you say, it does come across as advertising.) -- Nat Gertler (talk) 06:14, 8 September 2024 (UTC)
This doesn't seem like a good solution to me. There are perfectly legitimate reasons for editors to manually and intentionally add archive backups for specific still-living pages, e.g. if the site is flaky and routinely goes offline, is notorious for regularly changing URLs, or has substantially changed the content of a specific linked page. However, for other links, a "just in case" backup in the article source serves no purpose. The action that is useful, for still living pages, is to explicitly ask the IA to crawl and archive the content of the page (e.g. by requesting that it crawl all pages linked from a particular Wikipedia article), so that there will be a backup in case the link ever rots. But that can be done from the IA site or some external script and shouldn't involve changing the source markup of a Wikipedia article. –jacobolus(t)06:30, 8 September 2024 (UTC)
It's NoMore404, which monitors for every link added to every Wiki project including all 300+ wiki languages, and saves it to the Wayback Machine within 24hrs. This is why the coverage for Wikipedia on the Wayback Machine is so good. There are various reasons some URLs might not get saved, thus I wish we had another service filling in the gaps ie. logging new URLs and checking they exist on Wayback a few days later, if not archiving them elsewhere (Ghost, ArchiveToday etc). -- GreenC00:37, 11 September 2024 (UTC)
I am aware that this is done, but can you link an example bot or script that is doing this? (As you note, IAbot does not.) The code people are using may just be hastily written without checks. I am opposed to adding such archive links indiscriminately to every citation:
Archive links added after the fact, when not for rescue/CPR purposes, should be dated as close as possible to the |access-date= parameter of the citation, and not to the date of the crawl (which may or may not be the case for a given userscript.) If the new |archive-date= parameter must be different, the cited text must be checked manually.
If no |access-date= parameter is given, the cited text must be checked manually. (In practice it may not be justified to date it to the day the original edit was made, and I doubt it's computationally feasible to back-trace a section of wikitext to its last edit in a bot.)
Some very few citation links might be explicitly meant to reference the live version of a website, such as a webapp or "current status of..." footnote.
However, if the |access-date= parameter is given in the citation, I don't see an issue with adding an archive link with |url-status=live as applicable. (Although we might consider querying more archiving sites than just IA when doing this.) SamuelRiv (talk) 16:51, 8 September 2024 (UTC)
Here's an example edit, special:diff/1243928783, edit summary "Rescuing 13 sources and tagging 0 as dead.) #IABot (v2.0.9.5 Tag: IABotManagementConsole [1.3]". (This one is a particularly annoying common variant that adds wayback links for stuff like Google Books pages, bibcode links, etc.) I'm not trying to call out specific Wikipedians or publicly shame anyone. There are a bunch of people doing this type of edit using the same automated tool, often to many pages in quick succession. I think these kinds of edits are done in good faith, but I think we should have a policy page discouraging them. –jacobolus(t)17:46, 8 September 2024 (UTC)
IABot is no longer saving links to into the WaybackMachine because NoMore404 mentioned above already does it. -- GreenC00:39, 11 September 2024 (UTC)
@Jacobolus could you clarify if your objection is to the use per-se of IA, or to the fact that people are doing it indiscriminately in a bot-like manner? I routinely run IABot on my own articles and tell it to add links to anything it archives. I hope you're not objecting to that. RoySmith(talk)17:33, 8 September 2024 (UTC)
Yes, I am objecting to adding archive links to "anything it archives". This is, in my opinion, a type of spam. Please use archive links (whether from the internet archive or some other site) for links where the original is dead, changed, or unreliable for some reason, not just for fluffing out the citations section with distracting and unnecessary clutter. –jacobolus(t)17:37, 8 September 2024 (UTC)
This isn't purely rhetorical, but one could plainly search for URLs of IAing Google Books and quite quickly get a sense of how common this indiscriminate archiving is and what it looks like. Remsense ‥ 论20:18, 8 September 2024 (UTC)
OK, I guess I'll have to respectfully disagree. The problem is that by the time a link goes dead, it's too late to archive it, and then it's lost. I wouldn't mind if the citation templates treated this in a less "fluffy" way, but I'd hate to see the archive information omitted completely. RoySmith(talk)17:45, 8 September 2024 (UTC)
Here's an example from RoySmith: special:diff/1232611207 to Big Duck. Most (all?) of the archive links being added here go to still-living pages which are publicly accessible on the open internet, so the archive links are nothing more than clutter. "by the time a link goes dead, it's too late to archive it" – People should directly ask the IA to crawl and backup pages linked from Wikipedia. It is completely unnecessary to change the markup source of Wikipedia articles to accomplish this task. But to be honest, I don't mind that strongly if one of the primary authors of an article wants to go ham on the wayback links. Discussion of that choice could be contained to individual article talk pages and hashed out locally. But there are also folks doing large numbers of these edits to one page after another in a bot-like fashion, and at scale it's impossible for someone who disagrees to meaningfully revert or contest those changes without spending an even greater amount of time. I don't think there's any established consensus that such archive links should be added site-wide, so adding them automatically at scale is a kind of fait accompli. –jacobolus(t)17:52, 8 September 2024 (UTC)
Adding the IA link into the citation template makes it much easier to find later should it be necessary. If it bothers you to see that, it's easy enough to add some custom CSS to hide those sections of the citation. I'd be happy to have the templates add some classes to the markup to make that easier to implement. RoySmith(talk)18:32, 8 September 2024 (UTC)
It bothers me that we are spamming editors and readers in a way that seems abusive of Wikipedia's platform and community. Hiding what I personally see does not at all address my concerns. "much easier to find later should it be necessary" – this seems like nonsense to me. We are talking about the result of a fully automated tool without human inspection or intervention beyond clicking a submit button; the IABot is currently automatically "rescuing" dead links across the site without any human involvement at all, and will presumably continue to do so. Speaking as a human who constantly uses the Wayback Machine to find archived pages, it is trivial to go to web.archive.org, type a URL in the box, and then click through to see the various archived versions of that URL. –jacobolus(t)18:47, 8 September 2024 (UTC)
@Jacobolus: I just want to express the exact opposite position to your proposal.
Clicking on a link vs. going to the Wayback page, copy/pasting the url, possibly comparing alternative archive copies ... yet you say you're concerned for everybody else rather than just yourself? That makes no sense to me. Fabrickator (talk) 19:13, 8 September 2024 (UTC)
@Fabrickator You are not understanding my point. Let me try to be clearer. The claim is that we need to defensively add archive links to every external link because otherwise it is not "easy" enough to find the archive link in the event that the link rots and it becomes "necessary". My responses are: (1) it doesn't get any harder to manually trigger an archive bot/script years down line in the possible case that some links rot, (2) there's a continuously running automated process scanning the web for dead links and "rescuing" Wikipedia citations by adding wayback archive links, requiring no human intervention at all in the general case, and (3) even if this bot somehow doesn't catch a very occasional stray dead link and a human editor tries to verify a claim but ends up at a 404 page or whatever, it is quite trivial for a human editor to use the wayback machine from their browser (it takes no more than a few minutes to manually find the wayback link and add it to an article, and we are talking about a tiny number of links at that point). People running this script certainly aren't comparing various archived versions of every link. I have no problem at all if editors carefully manually inspect and think about how best to present every citation link to readers, sometimes making the specific individual decision to add an archive link. –jacobolus(t)20:34, 8 September 2024 (UTC)
@Jacobolus, if I understand you correctly, you're saying that the current system, which is:
The bot does everything automatically. Bonus: Since it's running soon after you added the source, it will (almost) always link to the correct archived page.
is inferior, because the alternative:
Wait until the link breaks
Trigger the bot manually.
Check the results.
Oops, it linked to an archived copy of the broken page.
Go to archive.org.
Paste the dead URL into the search box.
Manually check through various versions of the page to figure out which one ought to be given to readers.
Copy that URL.
Paste the archive URL into the Wikipedia article.
Figure out what the citation template requires for the date stamp (because it produces a red error message if you don't get it right).
is "very easy" and "quite trivial", right? Speaking just for myself, I don't feel like a 10-step process is "easy" or "trivial", especially compared to the option of "The bot does everything automatically". WhatamIdoing (talk) 05:32, 9 September 2024 (UTC)
No, this is a dramatic mischaracterization both of what I am saying and also of "the current system". I'm not sure what's going wrong with communication here, but I'll try briefly to clear things up before I have to go. The working parts of the "current system" is (1) the Internet Archive (IA) automatically checks nearly all external links added to Wikipedia and crawls them, adding snapshots of the pages they point at to the Wayback machine (henceforth WB), (2) anyone in the world can explicitly request that any arbitrary webpage and all of its outgoing links should be crawled and a new snapshot of each added to WB, (3) the IA runs some kind of automatic process checking the outbound links from Wikipedia and flagging them when they are no longer working, (4) User:InternetArchiveBot ("IABot") "rescues" dead links which appear on Wiki pages by adding WB snapshot links to Wikipedia article citations, without much need for human intervention (though sometimes the bot screws up somehow, or the archive contains the wrong content, or the website changed their URL scheme and there's still a living page at a new URL, etc., in which case a human can fix it). All of the above generally works great. It prevents a lot of link rot across Wikipedia, and I have no problem with it.
Additionally, there's a part of "the current system" that I find to be spammy, confusing, wasteful of space and attention in both output and source markup, unnecessary churn in page histories, without any obvious practical value, and not supported by current community consensus. Namely: (5) human "meatbots" run a semi-automated script, "IABotManagementConsole", which indiscriminately adds a WB snapshot link to every citation with an external link on it on a particular article, nearly all of which are working links to still-living pages accessible to anyone on the open internet. These editors are not checking anything manually or making careful choices, but just clicking one or two buttons, and their behavior is not fundamentally different from bots. Some of them are doing this repeatedly over and over again to dozens or hundreds of different pages which they have no other interaction with.
These edits are unnecessary, because in the event a link rots, the other parts of "the current system" already take care of it. Only a trivially tiny proportion of links rot and get clicked on by human editors trying to verify a claim before they have been "rescued", and in these cases, it takes about 1–2 minutes for the human editor to manually do the rescuing, or a few clicks to get a bot to do it. There's no "10-step process" involved. –jacobolus(t)05:57, 9 September 2024 (UTC)
Okay, the part I dispute is your claim that "in the event a link rots, the other parts of "the current system" already take care of it". I find that the post-rot "rescues" are worse quality (e.g., undetected 404 pages and redirects to the site's main page) than the archived links added pre-rot.
Why do you think that 1–2 minutes manual work per link – and realistically, we have to assume that they will all die some day, so for an article with ~15 sources, that's half an hour of manual time – better than clicking a button once and being done forever with all the (current) refs? WhatamIdoing (talk) 06:09, 9 September 2024 (UTC)
In my experience the "pre-rot archive" links also have a substantial proportion of mistakes, and would also routinely require manual attention. (Except we can skip it by just deleting those snapshot links as reader-hostile spam.) My own expectation is that the amount of manual work required for these is going to be nearly identical either way, except demanding backup links everywhere front-loads that manual effort and forces a human to double-check a wayback link for every link on the site instead of reserving manual checks for cases where it makes a difference. I imagine most of whatever difference you are seeing is selection bias: working links are relatively more likely to come from better managed websites which don't break their URLs as often and therefore tend to have working archived snapshot links as well. But if those pages do break at some point, they will still have working snapshot links. By comparison, broken links are relatively more likely to come from neglected or mismanaged websites. But if you find "post-rot rescue" links to often show the wrong thing, then that seems like a problem for bot authors to work on: for example, the bot could try to check for variants of the page and avoid 404 pages or versions where there is limited visible content, or could try to pick a snapshot date close to the access date described in a citation template, when presumably a human was able to view the content. –jacobolus(t)06:22, 9 September 2024 (UTC)
In the source of pages, this cavalier archiving behavior manifests as either apparent negligence or obsessive compulsion far too often in certain situations. "Indiscriminate" is the key word here. Remsense ‥ 论20:20, 8 September 2024 (UTC)
I HAVE NOT read through (or digested via ChatGPT or similar summary agents) this entire lengthy thread, but I do think it has significant relevance as a point of discussion and policy. In the article OpenStreetMap, Citation#1 which relates to the very first changeset indexed by the OpenStreetMap software, the citation contained an archive link dated to 2018; the original webpage was dated to 2005. However, the earliest InternetArchive stored page is from 2014. I changed the archive link to the earliest version because the 2018 stored page contains comments that were added to the changeset after it was apparently "found" to be the first changeset, while the 2014 archived page contained no such comments. I believe this is a good example (of a specific type) countering indiscriminate archive link additions ... though, I've not nailed down that this was something along the meat-bot lines being discussed above. The change to the page can be found at https://en.wikipedia.org/w/index.php?title=OpenStreetMap&diff=1245279923&oldid=1245279698 . Hope this helps the discussion a bit. Regards --User:Ceyockey (talk to me) 02:29, 12 September 2024 (UTC)
I very much agree with this. I used to be one of those editors that clicked the button and let IAbot run because I thought adding the archive links was an improvement to any article. I no longer think so, especially since I learned that Internet Archive archives all external links on Wikipedia anyway, so having the bot run doesn't actually archive the links, it just adds archive links to the citations, which is usually not helpful, unless the link is dead and IA has the full version (or to get around a paywall, but that's not really a kosher use). The archive links make citations harder to read and work with. It's even worse when the link being archived is useless, e.g. archiving Google Books pages because it's linked in a citation to the book (which doesn't archive the book!). Bottom line: I do not think the automatic addition of web archive links to citations is a good thing. I would support a change to IABot that it only adds archive links if |url-status=dead. I think I'm in the minority on this, though. Levivich (talk) 19:27, 8 September 2024 (UTC)
If what you say in your first bit of bolding is true (I have no reason to doubt it but don't have time to check now) then I am in the same minority, if it really is a minority. Phil Bridger (talk) 19:40, 8 September 2024 (UTC)
This being Wikipedia, I should cite my sources :-) IA in 2018: For more than 5 years, the Internet Archive has been archiving nearly every URL referenced in close to 300 wikipedia sites as soon as those links are added or changed at the rate of about 20 million URLs/week.WP:WAYBACK also says New URLs added to Wikipedia articles (but not other pages) are usually automatically archived by a bot. It also says Editors are encouraged to add an archive link as a part of each citation, which I think it should not say. BTW, another very easy solution to this would be to code the citation templates to not display archive links unless |url-status=dead. This could also probably be done as a CSS hack, so editors who didn't want to see those links for live URLs could turn them off as it were. Levivich (talk) 20:07, 8 September 2024 (UTC)
One of the reasons for linking to wayback is so that we can continue to cite webpages that are no longer available, or have been significantly changed. But this raises red flags for me… I want to know WHY the cited source is no longer available or has changed. This question should always be asked before we link to wayback. The answer may require us to reassess whether the information in our article is out of date, and thus no longer accurate and verifiable. Blueboar (talk) 21:19, 8 September 2024 (UTC)
In my experience, archive links for still-alive links could be useful, as the site may be temporarily down or region-blocked. I don't have a strong opinion on this, though, because for me personally it's not hard to manually open a link through the Web Archive. Levivich's solution seems good to me, but I also agree with jacobolus that there should be an option in IABot to archive all the links but not add them to the article. AstonishingTunesAdmirer連絡21:10, 8 September 2024 (UTC)
I just tested it, it's not that, it still adds archive links to the article. As far as I understand, the bot makes a list of all references in the selected article, then saves each link through the Web Archive, and then adds links to these archived pages to the article. What jacobolus was talking about is skipping that final part, so the bot would save all links through the Web Archive, but would not add them to the article. AstonishingTunesAdmirer連絡21:30, 8 September 2024 (UTC)
@Jacobolus: You wrote: "You are not understanding my point. Let me try to be clearer." I hear your point, but I think it's a bad one. I'm unclear whether you object to the archive link being visible, being present when you edit the article, or being stored in the wikitext. Certainly I don't object to it not showing up when you view an article, and the details of how this is stored is something I should like to see improved (e.g. along the lines of storing the data in Wikidata and accessing it using {{cite q}}).
But even the possibility that the live url is temporarily not working (or permanently not working) is good enough reason to have the archive link handy. It's a bonus that there are other scenarios where it's useful ... e.g. some "multi-page" articles (requiring a different url to get to subsequent pages) may also have a link that displays all pages with a single url. You might suppose this is neither here nor there, but as an editor, I make such a decision as to which is preferred. I am unhappy about the nuisance of all this, but I am happy that we are not stuck with what unintelligent bots choose to do.
I would long for a bot that was smart enough to make good decisions, but I see no evidence that we have the appropriate technology to develop sufficiently intelligent bots, so we have a fallback of manually adding or editing archive links, yet the existing system is useful in that it makes a passable selection at least most of the time, yet somehow you are annoyed about the presence of that selection. I throw up my hands. Fabrickator (talk) 21:51, 8 September 2024 (UTC)
"I'm unclear whether you object to the archive link being visible, being present when you edit the article, or being stored in the wikitext." – I am strongly opposed to the first, which seems like spam and is confusing to readers, and moderately opposed to the other two, which still add a lot of clutter to the markup for no practical benefit. "may also have a link that displays all pages with a single url" if you want to link the article title to one URL and also add a second URL to a consolidated version of the content, there's nothing stopping you. It would be extremely confusing to use the "archive-url" parameter for this, so please don't do that. "as an editor, I make such a decision" – again, I am mostly unhappy with automated tools imposing poor choices not backed by site consensus, not by human editors making specific decisions about individual links on single articles. The latter is entirely possible to discuss and work out in local talk pages. –jacobolus(t)22:03, 8 September 2024 (UTC)
I guess my response to this would be "you never know when a publication/company could go down". Just as a recent example, Game Informer went down this year and there was a mad scramble to archive all of their website links and making sure all that was saved because GameStop couldn't be bothered to keep GI's history up. I'd rather be preventative and avoid stuff like that from occurring rather than being reactionary and having to scramble to archive a source if it goes down. ♠JCW555(talk)♠ 22:22, 8 September 2024 (UTC)
"You never know" simply isn't a compelling enough argument to applied literally 100% of the time in favor of obvious clutter that has clear concrete disadvantages in the meanwhile. What is the aversion editors have against literally any discretion being applied here? Remsense ‥ 论22:52, 8 September 2024 (UTC)
"obvious clutter that has clear concrete disadvantages in the meanwhile" this is your opinion, which is fine to hold of course, but I (and others) don't feel that way so don't try and speak for everyone. "Discretion" in this case would be "editors should have the same opinion as I do". I'd rather be proactive in archiving sources than be reactive. ♠JCW555(talk)♠ 23:05, 8 September 2024 (UTC)
My opinion is putting emphasis on what are demonstrable, objective issues caused by the practice. You can have a different emphasis, but let's not pretend whether the issues even exist (which I've just elaborated upon below) are a matter of opinion themselves. Remsense ‥ 论23:08, 8 September 2024 (UTC)
"what are demonstrable, objective issues caused by the practice" again, according to you. I, and others in this conversation don't agree with you. You can think it's a problem, others can think it's not a problem. That doesn't make either of us right of course, but I don't say my opinion is 100% true and everyone must agree with me. I only speak for me, not every editor on the platform. So again, don't speak for me or everyone on here. ♠JCW555(talk)♠ 23:19, 8 September 2024 (UTC)
My browser crashing when I try to turn on syntax highlighting isn't a figment of my imagination or a mere aesthetic preference I have. In the general case it is a problem for me and for you for all intents and purposes, so you're not going to force me to mince words as such. Remsense ‥ 论23:20, 8 September 2024 (UTC)
I've read this whole discussion a couple of times now and I'm still not understanding what is problematic about including the archive links for active links. They are useful for temporary outages, region locking, verification of pages that have changed content, usurped domains (which are hard to detect automatically, which is why the WP:JUDI domains have to be tracked manually for example) and for other uses too. I also don't understand why some people in the discussion find the presentation of both live and archived links confusing - is this an actual problem that readers have noted or is it just a theoretical somebody might potentially be confused? I'm not attached to changing the display, but I am opposed to removing it without evidence that the current presentation is actually problematic and that the proposed alternative is actually an improvement. If anything, I would prefer to encourage the inclusion of archive links with every citation, because they are significantly valuable to maintaining the integrity of the encyclopaedia and allowing continued verification of our articles. I completely disagree that they are "clutter" and nobody has presented any arguments here that convince me that inclusion has any disadvantages at all, indeed quite the opposite. Thryduulf (talk) 22:57, 8 September 2024 (UTC)
When they are clearly addressing one of your stated issues then of course they are useful. Otherwise, wikitext length itself plus its associated visual and technical complexity simply isn't free or essentially free: the additional bundle of parameters indiscriminately added to every citation adds visual clutter for editors to scroll through, which does make it harder to factor articles and understand their wikitext, and even the rendered article if the archive is not serving any clear function. It is not controversial that it can also lag the editor, especially when syntax highlighting is enabled. I am dead serious when I say there are articles I cannot comfortably edit in their present state, whereas I would be able to if every Google Books url didn't add nearly 1kB to the article size instead of 100B. If we're supposed to have archives on literally every external URL, then that should be added to the backend or something so we don't have to deal with it this way. Let's not treat it technically like a matter of discretion when it's actually not editorially. Remsense ‥ 论23:05, 8 September 2024 (UTC)
When they are clearly addressing one of your stated issues they always address those stated issues, because it is not possible to predict when a site is down (temporarily or otherwise), whether any editors will be geolocked (e.g. many US news sites are blocked to editors in Europe but it is completely invisible to US readers which they are and which they aren't), etc. Thryduulf (talk) 23:15, 8 September 2024 (UTC)
But it is actually possible to weigh some of these factors based on context. Plus, why are we a priori able to assume the IA is perfectly reliable in this way, but any other site isn't? Remsense ‥ 论23:19, 8 September 2024 (UTC)
It is possible for a human to weigh some of those factors in context, which means that as humans don't (and can't) evaluate every link in context in advance of every reader reading the article the links are always addressing the stated issues. We don't assume that IA is perfectly reliable, we know that the IA does not geoblock and is generally reliable, we also know that the combination of a link and an archive (IA isn't the only game in town, despite what this thread implies) is more reliable than a link alone. Thryduulf (talk) 00:03, 9 September 2024 (UTC)
Right—all I am arguing for is that discretion is possible, and that it is still expected in the use of automatic tools like with any other dimension of editing.
As a total tangent, I've always wondered why it isn't possible to collapse CS1 archiving into two parameters—date and liveness. Surely it's pretty feasible to derive |archive_url= from the |url= and |archive_date= (etc.) already given? Remsense ‥ 论00:11, 9 September 2024 (UTC)
Ah, that makes sense. Do you think it would be viable for the "default mode" to assume IA with no redirect, and other configurations could be further specified if needed? As strong as my opinion is here, reducing the wikitext footprint of archiving would make it essentially a nonissue! Remsense ‥ 论00:20, 9 September 2024 (UTC)
It's a good idea, in my opinion. I think combined with an option to disable rendering for archive links on live sites it should solve most of the complaints (wikicode would be less cluttered, there would be fewer archive links on screen). But I think this more of a question to people working on the citation templates, whether it's hard to implement, etc. Pinging @Trappist the monk and Izno: how hard would it be to generate an archive link for a URL, so instead of {{cite web|url=https://en.wikipedia.org|archive-url=https://web.archive.org/web/20240501005015/https://en.wikipedia.org|archive-date=May 1, 2024}} you could do just {{cite web|url=https://en.wikipedia.org|archive-date=May 1, 2024}}, but with an option to provide archive-url if it differs from url (or you need a specific snapshot, I guess)? AstonishingTunesAdmirer連絡00:49, 9 September 2024 (UTC)
You would need the full timestamp of the archive 20240501005015, so you need a separate parameter regardless |archive.org-id=20240501005015 or whatever. You would not be able to do it solely with a |archive-date=. Izno (talk) 01:02, 9 September 2024 (UTC)
Sure—I was envisioning a |archive_vendor= parameter (or something terser) in the de facto exceptional case when we're using something else, which would default to IA.Remsense ‥ 论 01:34, 9 September 2024 (UTC) Scratch that, it should've probably occurred to me sooner that this can remain minimally complicated by just assuming IA by default and specifying |archive-url= otherwise. Remsense ‥ 论05:01, 9 September 2024 (UTC)
I do not think that making changes to cs1|2 in an attempt to curb annoying or bad societal behavior is a good idea. For the narrow question of hiding the archive information in a rendered citation, I can imagine having Module:Citation/CS1 wrap the live form (Archived from the original on <archive date>) in a css class so that individual editors may hide that portion of the rendered citation with something like this:
Another possibility is to get someone at WP:US/R to write a script that hides live archive info but also provides a clickable something so that that individual editors can show a citation's archive info if the want to see it.
@Thryduulf, I talked to the IA folks about this a while ago. The problem we have is that what the bot does violates our guideline at WP:ELCITE. The problem they have is that the bot is too simple-minded to know how to stay out of the ==External links== section. It takes an all-or-nothing approach to adding archive links in an article. (It also has had problems with incorrectly claiming that sites are dead.)
For clarity, in the ==External links== section, either of these is Y good (depending whether the link is live):
WP:ELDEAD agrees with you. We tend to keep archived copies of official links, and occasionally something that an editor thought was particularly valuable, but otherwise, they should usually be removed/replaced with something else. WhatamIdoing (talk) 23:55, 8 September 2024 (UTC)
@WhatamIdoing that's an issue with the implementation of the specific bot, not with the addition of archive links.
@JacobolusSome links should remain archived (e.g. official websites), some can (and should) be fixed by replacing them with an updated link the bot is not aware of, others should be removed. However that determination needs to be made by a human, and marking a link as dead is a very good way of letting humans know that a determination needs to be made. Thryduulf (talk) 00:07, 9 September 2024 (UTC)
Adding {{dead link}} is not usually a good idea for the ==External links== section. However, in the specific case of WP:ELOFFICIAL links for which you believe a working website to be reasonable (e.g., a company that is still in existence), it may occasionally be appropriate as a temporary measure (e.g., until someone can find the new corporate website). WhatamIdoing (talk) 01:05, 9 September 2024 (UTC)
Why is it not a good idea? It signifies that a human needs to make a decision about whether to remove the link, replace it with a working alternative or replace it with an archived version. Thryduulf (talk) 01:14, 9 September 2024 (UTC)
I can understand the impulse to kick the can down the road to a hypothetical future editor. However, WP:ELDEAD says that instead of doing that, you should normally update or remove dead links right now. We don't need one human to ask another human to make a decision. Just make the decision yourself. WhatamIdoing (talk) 01:49, 9 September 2024 (UTC)
We aren't talking about humans adding the template (although it would be appropriate while a discussion is ongoing or while attempting to locate the new location), we're talking about it being added by a bot. Thryduulf (talk) 02:00, 9 September 2024 (UTC)
Are we? I thought this thread was primarily about edits like this one, which affects nothing outside of the ref tags, and that I was talking about my desire to prevent the bot from making edits like this one, which added:
{{Webarchive|url=https://web.archive.org/web/20180101214652/https://www.irishfa.com/ifa-international/squads/senior-men/chris-brunt |date=1 January 2018 }}
in the ==External links== section. It is the location of this edit, rather than the substance of it, that I believe is inappropriate. If this edit were made inside ref tags, I'd never complain.
I understand that edits like this one (adding the dead link template) can't be easily improved upon, because all the bot can do, when it can't figure out how to fix it, is either ignore it or tag it. I might prefer ignoring it in that case (the domain works, and the reader could search from there; also, this specific bot sometimes finds itself blocked when the URL is working correctly for humans), but bots have limited capabilities. WhatamIdoing (talk) 02:41, 9 September 2024 (UTC)
The first is policy compliant, but irritates some editors when they are working in a wikitext editor. That first edit is the problem described at the top of this thread. I don't know how to solve that problem, or even if we should solve that problem.
The second is a violation of the Wikipedia:External links guideline and should stop. However, that will reportedly require more than a trivial bit of coding effort.
The third is perhaps discouraged under WP:EL, but I don't think we can realistically hope for the bot to do any better than that.
"primarily about edits like this one (special:diff/1244763493)" – No, this is not the type of edits we are discussing here. I think this edit – which is adding archived snapshot backups for dead links – is just fine, and my impression is that almost everyone appreciates such edits. –jacobolus(t)06:07, 9 September 2024 (UTC)
This URL does not have a working wayback snapshot, so no the snapshot should not be added as a backup. (And if the wayback snapshot had been added by a human while the page was still alive, we'd still be seeing the same empty content, because this website served a broken page to the wayback crawler, and is still serving broken pages to me when I navigate there now.) If this link does not show the intended content it should just be deleted as a citation, and a human will have to find a working replacement source. Any human adding wayback snapshot links should be double-checking every single snapshot link and making sure to never add anything like this to Wikipedia. (For example, wayback backups of Google Books pages should never be added, because they are similarly broken.) However, that is not currently happening, because wayback links are being added indiscriminately – what I am complaining about here. –jacobolus(t)06:33, 9 September 2024 (UTC)
wayback backups of Google Books pages should never be added, because they are similarly broken – This is not always correct. Pre-2020 it archived just fine, but it's possible the new Google Books UI broke something. A magazine we extensively cited was removed from Google Books in 2022, leaving hundreds of 404 links. And I've personally fixed many of these using the Web Archive. See ref 5 in Respect (Shaquille O'Neal album) for an example. AstonishingTunesAdmirer連絡16:23, 9 September 2024 (UTC)
This is a different view of the same Google scan of the same magazine hosted on the same website (archive.org), just going through their front-end instead of a wayback snapshot of google books. If you think that either of the two links is an unacceptable copyright violation then the other link surely has the same status, and you should just remove the external link and leave readers to find a copy of the magazine on their own. (I don't have any idea why the magazine was removed from Google Books, or what the copyright status is of the IA-hosted scan.) –jacobolus(t)18:42, 9 September 2024 (UTC)
the other link surely has the same status – does it though? A snapshot of a web page is explicitly allowed per the policy. But I haven't seen any mentions of reuploading of the web page's content. I do agree with you, the full scan is infinitely more useful. But I want to link sources that: 1) another editor will not delete at some point in future (right now this area is much grayer than what is allowed explicitly); 2) Internet Archive itself will not delete at some point in future (they absolutely will the moment copyright holders notice it and/or decide that sending a DMCA request is worth the effort, but it's extremely unlikely they will go after the archived copy of Google Books). AstonishingTunesAdmirer連絡19:40, 9 September 2024 (UTC)
If you want to follow "However, if you know or reasonably suspect that an external Web site is carrying a work in violation of copyright, do not link to that copy of the work without the permission of the copyright holder." and don't think the current copyright owner of Vibe gave permission for a scan to be hosted by third parties, then you should probably delete the links. I have no idea whether this media conglomerate that bought and shut down the magazine 10 years ago and now calls it a "leading entertainment and lifestyle brand delivering content across multiple media platforms to a diverse audience around the world" (i.e. a fancy blog/email newsletter) is going to be trying to scrub 15-year-old magazine scans from the internet. Maybe? Perhaps the Internet Archive should be gating access to similar still-copyrighted magazines behind their "borrow" feature. Personally I would just link to the IA copy, assuming that the publisher will sort things out with the IA, and if the book later ends up unavailable or deleted from the IA then Wikipedia could just take out the external link at that point and leave readers to find the magazine on their own if they want to verify the quotation. YMMV. –jacobolus(t)19:54, 9 September 2024 (UTC)
Honestly, I was just as puzzled when they deleted it from Google Books. I tried emailing them to ask whether it's some mistake on their side and if they are planning on fixing it, but it looks like they only accept corporate email addresses. It appears that they also own Billboard magazine, which is still available at Google Books (it will be an even bigger problem if they delete that one), so who knows. But I think you are right, eventually all of these will be unavailable. A shame, really. AstonishingTunesAdmirer連絡20:51, 9 September 2024 (UTC)
I too agree that we should discourage the blanket archiving of live links. It feels we're adding extraneous text to the references (and extraneous wikitext. Like jacobolus', my browser crashes when I turn on syntax highlighting on large pages; I wish it didn't) that are unlikely to be intentionally read or clicked on. Internet Archive is already doing us and our readers the great service of archiving pages linked to from our articles. If those links go dead, a bot is already doing the great service of linking to an IA snapshot of the page. I don't think the other much less common (I dare to assume) use cases merit so much text clutter. I agree with jacobolus that the scale of the linking feels like advertising for the service IA provides. Ajpolino (talk) 00:10, 9 September 2024 (UTC)
From the description, it does not seem that the addition of such links is indiscriminate. As long as it is reasonable to believe that the AI links will persist, which I think we all hope they will, there are numerous good reasons to always have a backup for any external link that can be backed up. BD2412T03:43, 9 September 2024 (UTC)
But you're not actually arguing that "the situation as described isn't indiscriminate"—instead it's "we don't need to discriminate". I put such a fine point on it because that's rhetorically what we're all hinging around, degrees of totality versus discretion. Remsense ‥ 论03:48, 9 September 2024 (UTC)
That's not what "indiscriminate" means. Were someone to create an article titled List of interesting news articles archived in the Internet Archive, and to populate this list with a random selection of a few hundred internet archive links, that would be indiscriminate. If someone were to linkeverywordinanarticle and provide an online dictionary reference for each word with a consequent Internet Archive link, that would be indiscriminate. However, were someone to create an article on a discrete and notable subject, including references to reliable online sources relevant to that subject, and were to then provide Internet Archive links as backup links for that set of sources, that would be the opposite of indiscriminate. That would be providing backup links to exactly parallel the sources relevant and appropriate to the article. BD2412T12:38, 9 September 2024 (UTC)
Doing something without discriminating, such as adding archive links to every link without considering them individually, is precisely what the word "indiscriminate" means: it would make a good example for a dictionary. Doing something indiscriminately doesn't necessarily mean it is bad, inappropriate, irrelevant, or involves ill intent. For example, a parent might indiscriminately and unconditionally tell each of their children they love them. (Though I personally think indiscriminately adding archive links is bad and inappropriate, which is why I raised the issue here.) –jacobolus(t)14:36, 9 September 2024 (UTC)
Well that's like saying "I drive indiscriminately" to mean that "I indiscriminately stop at all of the stop signs". BD2412T20:56, 9 September 2024 (UTC)
I would say that fundamentally, if in a frequently-updating publication like a newspaper or magazine (or something else reasonably expected to possibly have updated content within a month or two), IABot uses an archive-date that does not exactly match the access-date, and the editor does not verify that the content sourced is still verified by that archived copy (or else the archived text still matches), then that is indiscriminate editing subject to concern.
@SamuelRiv: I agree with you, and up above, Blueboar raised the same issue: if the original source goes down, it's important to know why that is, is it because the article was retracted? If so, simply switching to the archive link is not good. If the original was updated, similarly using the outdated archive link is not good. So, indiscriminate is an issue. (And there are other indiscriminate issues, like archiving pages that make no sense to archive, such as YouTube pages [which don't archive the video] and Google Books pages [which don't archive the book].) Levivich (talk) 17:15, 10 September 2024 (UTC)
If the article content cites a source at a specific date, then an archive link should also be at that date, regardless of whether that source was updated or retracted. Ideally, the person adding the archive link would also check whether the source and the content still match (V), and in the process they would also check the status of the source (RS) and consequently update the access-date. But people doing wide-scoped markup maintenance work are almost by definition not stopping every time to do fine-grained content maintenance work. If the article content matches the source at its access-date, then it is correctly cited. If an editor adds an updated version of the article without changing the content, then that's one way citation drift happens, and it may soon enough fail V. SamuelRiv (talk) 17:27, 10 September 2024 (UTC)
Indeed, the whole purpose of references is to ensure our articles are verifiable, not that they are correct. Just because a paper is retracted doesn't mean that what we were citing it for is incorrect (it depends what we are citing it for and why it was retracted) - and in some cases we will still want to cite it because its retraction is notable. Thryduulf (talk) 20:33, 10 September 2024 (UTC)
Raising my hand as agreeing with Remsense in general here. My objection is that unnecessary archive links are a waste of reader time. If the IA was fast, it would be one thing, but it's not fast at all. --jpgordon𝄢𝄆𝄐𝄇04:39, 9 September 2024 (UTC)
That's a distinction we should be clear about.
Some editors object to displaying archive links when the original is working just fine.
Some editors object to huge long strings of wikitext, even if readers never see it.
The first group would be perfectly satisfied if this wikitext: {{cite book |url=https://example.com |title=Example Domain |website=example.com |access-date=2 September 2023 |archive-url=https://web.archive.org/web/20240908173056/http://example.com/ |archive-date=8 September 2024 |url-status=live}} was in the article, so long as all the readers saw was a simple "Example Domain". example.com. Retrieved 2 September 2023.
Thryduulf to their credit has also stressed above that "working for me right now" isn't always sufficient for "working just fine", as an ancillary point. Remsense ‥ 论05:25, 9 September 2024 (UTC)
I support, in general, the archiving of as many reference urls on Wikipedia as possible. I don't think the "clutter" affects readers very much, since the reference section is not meant to be read through as prose. I think readers are getting with ease all of the useful information out of the citations they check out, assuming the citations are properly formatted. The presence of text like "Archived from the original on December 26, 2021", usually presented at or near the end of the citation, is not unduly burdensome on readers who don't care about archive links, and is obviously useful to those who do. I do think local consensus should be able to determine that a given article's citation style is not to use archive links for live urls. It's currently the case at Donald Trump, mainly for size reasons. Article creators with a preference for less archive-related text should be able to establish that style and not have it overridden unless there's a discussion that leads to consensus for inclusion. Firefangledfeathers (talk / contribs) 12:23, 9 September 2024 (UTC)
How do we take them out once they're in? Manually? I'd like this idea except in practice it's fait accompli. Once someone pressed the button, the links are there to stay, unless someone else manually removes each one. Levivich (talk) 14:49, 9 September 2024 (UTC)
I think it's generally true that "established styles" need some vigilance to maintain and that the work needed is minimal if deviations are caught early. I think the only exception might be date style, since a script can semi-automate switches between styles. Firefangledfeathers (talk / contribs) 18:30, 10 September 2024 (UTC)
What's really mind-boggling is that it already works that way! Store a date as 2024-09-10 and it'll display as 12 Sep 2024 or Sep 12, 2024 depending on article and user preferences. Still, people argue about, and change, the underlying code. Levivich (talk) 18:55, 10 September 2024 (UTC)
If only we could agree that non-ambiguous ISO-compliant date formats like 2024-08 could be displayed as "August 2024" instead of throwing a red error message. (Yes, 2001-02 is ambiguous. But most of them aren't, and the ambiguous ones are easy to predict.) WhatamIdoing (talk) 19:06, 10 September 2024 (UTC)
People should add e.g. {{use dmy dates|cs1-dates=sy|date=November 2024}} to the top of an article, and then use dates of the form 2024-11-12 within citation templates; they will be automatically formatted to the correct style, even if someone adds a citation template with date parameters in another format. –jacobolus(t)18:56, 10 September 2024 (UTC)
Heh. I've always assumed that's how it worked, but then started assuming my understanding was wrong when reviewers started insisting I needed to change the dates in my templates in the sake of uniformity. I stopped arguing and just made them happy. Maybe I'll push back harder the next time. RoySmith(talk)19:36, 10 September 2024 (UTC)
I've brought this up a few times over the years. Basically, IABot is already creating archive links for articles added to citations without the need to run IAbot manually. It stores them in an off-wiki database and adds them as needed (I don't know exactly what it's looking for to do this). My perspective is that while there's an obvious downside of increasing the size of an article, there are some good reasons to err on the side of including the archive links in the articles. Namely, because what happens off-wiki is opaque and wiki bots have a tendency to just stop without notice, and also because it provides a link for a savvy reader to circumvent a paywall (not that this reason should be documented anywhere, mind you -- IA is having enough troubles lately). Regardless, however, this system of users drive-by "rescuing" sources that don't need rescuing isn't great. We could use an RfC simply asking "should all links have an archive link by default". If so, a bot should be doing it rather than random users adding them randomly. If not, we'll have to decide if it should be prohibited or left at a case-by-case basis. If case-by-case, what are the considerations? I'll also just add that my pet peeve in all this is less the size of the addition but how that addition messes with the tools we have to quickly determine who the primary contributors of an article are. — Rhododendritestalk \\ 17:47, 9 September 2024 (UTC)
If there's real interest we could run an-house experiment on link clicks on a couple articles to see if there's any significant uptick in people viewing sources when the archive link is available versus not. That'd give the benefit for displaying the links to live urls, at the least.
If there's a client-side performance cost/benefit per page to consider, I don't know if that can be reasonably mitigated by something like passing an iarchive-id parameter instead of the full urls, or else only rendering the live parts of citations on mobile and limited connections, or keeping the citations section unexpanded except on clicks (as several academic publishers do). I don't think stopping a few characters here or there (that time will force upon a page eventually) addresses the legitimate issue of client-side performance that people are raising.
at Rhododendrites (above): since bots are flagged in edits, your tools should discount bot edits, no?
I'm more concerned with the examples given that it seems IABot is adding archive links that do not conform to |access-date=. It seems like this should be the default behavior (as opposed to adding the latest archive link), but I'm not sure whether it is according to IABot's documentation. Not sure I can tell from the API source main whether that's the default already, not using the tool myself. Can someone confirm? SamuelRiv (talk) 19:21, 9 September 2024 (UTC)
My understanding is that IABot uses the archive that is closest in time to the access date in the article, if one is present. The closest archive may be quite different to the access date in some cases. When an access date is not present (e.g. for bare URIs) then I think it uses the most recent archive available. Thryduulf (talk) 19:37, 9 September 2024 (UTC)
According to doi:10.1145/3366423.3380300, 99.7% of readers don't click on any links in the refs. To give a few examples from the traffic report in The Signpost:
Vinesh Phogat might have had ~5,500 people click on a ref link during the last year. There are 90 refs, of which 66 have archive links. If we assume conditions along the lines of the spherical frictionless chicken, that might be an average of 11 opportunities per day for choosing between an archived link and a current link.
Noah Lyles might have had ~8,000 people click on a ref link during the last year. There are 68 refs, of which 9 have archive links. That might be around 3 opportunities a day for people to choose between an archived link and a current link.
Armand Duplantis might have had ~7,000 people click on a ref link during the last year. There are 79 refs, of which 52 have archive links. That means someone had to choose between an archived link and a current link about 12 times a day.
These are super-high traffic pages (mostly during the last month), and recording just 1,000 events would take more than a month. While I think that it would ultimately be feasible to test whether archived links encourage people to open a source, I would not want anyone to think that this would be quick and easy. I think it is more likely to involve words like long-term, perseverance, and (unfortunately) indeterminateresults. WhatamIdoing (talk) 20:27, 9 September 2024 (UTC)
a reference popup screenshot I just took to illustrate this There's a problem I'd love someone to sink their UX teeth into. How can we make users read references period! @Valjean and some of the other editors on the Trump article were experimenting with lead ref targets. I wonder if Wikipedia should invest more in footnote overlay gadgets and the like. I use some kind of gadget or user script that makes a mouseover preview popup show up. It does work for footnote links, but you just get an overlay that shows you the footer. It could be a lot bigger, brighter, and with more information about the reference. Also, theoretically, it could show you other pages that cite that source or general information about its reliability, etc. There's also a great user script by @Novem Linguae that adds color highlighting to the references. Andre🚐20:37, 9 September 2024 (UTC)
I believe that one of the ideas considered in Vector 2022 was having the refs displayed on the right-hand side (in all that "unnecessary" white space, if you have a wider screen and don't expand to full width).
But: Why should "making users read references" be one of our values? Also, would pushing that upset the apple cart in terms of WP:NONENG and WP:PAYWALL?
I looked up a Wikipedia article earlier today. I needed to remind myself that Bratislava really was in Slovakia, and I hadn't misremembered it. Do you think it would have been better for me to read the references for that? I don't. WhatamIdoing (talk) 20:43, 9 September 2024 (UTC)
I'm not a fan of the extra white space, I like the popup approach better. The Vector whitespace was a disaster on my monitor until they fixed it and offered some adjustable option for a wider view. I was using Monobook for a while until they fixed it.
I think making users read references is pretty key to the mission of Wikipedia and verifiability. I think accessibility to open access journal articles and content literacy are key to the mission of education and inspiring critical thinking. As everyone knows, Wikipedia is NOT reliable. As someone seeking information that's a bit less common, anytime you look at an article you don't know whether everything on it is correct, especially controversial statements, unless you check the references. Hoaxes and vandalism exist due to the wiki model, and the chain of corroboration is key to making the whole thing work. Sure, looking up where Bratislava is, is not going to require looking at the references. I've come to see Wikipedia as basically a public source of information, while plenty of valuable stuff is locked behind paywalls or private, difficult to access archives. Wikipedia's goal is unlocking the world's information and making it available. Andre🚐20:51, 9 September 2024 (UTC)
I don't agree that making users read references is a key goal. If it were, then the best way to achieve it would not be to create encyclopedia articles, but an index of references. And while that may be a useful reference work for a segment of Wikipedia's current readership, it would not have the same broad appeal as an encyclopedia. isaacl (talk) 19:07, 10 September 2024 (UTC)
WP:V means people should check the references. It's in the first line. people using the encyclopedia can check that the information comes from a reliable source. If nobody is reading or checking them, what's the point of having them? An index of simple references would be, I guess, Wikisource. Which is also really valuable. There's some great old Ukrainian documents on there. Or we could be Nupedia or World Book and simply have a cadre of expert magicians who we implicitly trust to create truthful articles? But I would argue that you're basically information-illiterate if you read Wikipedia and trust the text implicitly without checking the references. In fact, I'm surprised someone would push back on the importance of references. They're arguably more important than the text itself! Andre🚐19:34, 10 September 2024 (UTC)
You're tripping yourself up on the very basic distinction between can and are expected to. I remember my pre-editor self, and I literally almost never actually checked the references. Remsense ‥ 论20:11, 10 September 2024 (UTC)
Splitting some very semantic hair IMHO. I don't remember reading and not being an editor, but before I was an editor there weren't references and Wikipedia was a trash pile of Pokemon articles and original research by today's standards. Still -- I would consider it a problem worth solving that we don't make it easy for non-editors to verify things. Andre🚐21:53, 10 September 2024 (UTC)
Insisting that readers must read references is an absurd fantasy. The wide variety of readers are going to do what they want, which mostly will not involve carefully reading details of the article, let alone tracking down paywalled scholarly sources to verify references for every claim. The job of articles is to best serve readers' needs and answer their questions, which means making statements which are generally accurate, reflect expert consensus, and weren't just made up by a pseudonymous Wikipedian. "what's the point of having [references]?" The purpose is that readers and other editors can check them if they want or need to for some reason, as is plainly stated in the text you quoted. –jacobolus(t)22:37, 10 September 2024 (UTC)
I think there's something between "must" and "should". Also, I think we agree that someone must check them, just not everyone. No reader is required to check the references, but they really ought to. A paywall is an obstacle but a motivated reader may pay. Luckily, most articles have at least a few non-paywalled references. At any rate, I wasn't insisting that readers must be reading the references, I was advocating to improve the UX to make it more likely that they would. Andre🚐00:07, 11 September 2024 (UTC)
No reader is required to check the references, but they really ought to. that's oversimplified. Every reader should check the references associated with every statement for which "probably correct" is not good enough for their use case. If you need to know for certain that the melting point of a given alloy is greater than 3000 K then you absolutely should check the reference for that, but saying they "ought to check the reference" for it being invented in France in the 1990s is wrong. Conversely, someone compiling a report about the history of European metallurgy absolutely should check the latter reference but "it has a high melting point" is likely as much detail as is relevant to them (if not more so) and they don't need to verify it is 4112.88 K. Thryduulf (talk) 00:22, 11 September 2024 (UTC)
I wasn't going to go here, but I can't resist any longer. Our current UI for presenting references sucks. Let's take John Rolph (today's TFA). I click on the first citation. That takes me to a list of references, highlighting "^ a b c Johnson 1989, p 223". So let's assume I figure out the highlighting mean "click here" and I do that. This gets me to the "Works cited" section, with "Johnson, J. K. (1989). Becoming Prominent: Regional Leadership in Upper Canada, 1791–1841. Kingston: McGill-Queen's University Press. ISBN 0-7735-0641-1." highlighted. So, OK, I click on the first link, which gets me to McGill–Queen's University Press. At this point, I feel like I'm playing a scavenger hunt game and I've made a wrong turn somewhere. Why couldn't clicking on "[1]" just gotten me to the source directly?
Yeah, I know, [1] happens to be a source that's not on-line, but [2] is on line and the same three-click process is required. At least in that case, I get to a NCBI page where (with a fourth click) I can actually get to a PDF of the source. Except that by this time, I've lost track of the fact that one of the intermediate stops on this particular scavenger hunt said "p. 17", so I need to go back and find that again. We sure don't make it easy on our readers. RoySmith(talk)00:30, 11 September 2024 (UTC)
m:WMDE Technical Wishes/Sub-referencing#Sub-referencing in a nutshell is one way to reduce the first step. Instead of going to "a b c Johnson 1989, p 223" and needing to click again to find the name of the book, it'd take you to a unified list that could look something like this:
Johnson, J. K. (1989). Becoming Prominent: Regional Leadership in Upper Canada, 1791–1841. Kingston: McGill-Queen's University Press. ISBN 0-7735-0641-1.
I agree that'd be helpful but I'd go further, what about my mouse over overlay tooltip idea? Also, there's a bug in the visual editor that I just reproduced. If you click on the reflist itself you are offered a chance to "replace reference." This just ends up adding a reference to the bottom of the page instead. [1] The "replace reference" link only works if I click the footnote on the top of the page, not the line in the reflist. Let me know if you'd want a screenshot or if I should tell someone, do you still like receiving my bug reports? Andre🚐01:28, 11 September 2024 (UTC)
Citations have opened on hover/mouseover for years for me, and I don't use any custom settings. When you hover on the bluetext in the popup for [1] on John Rolph, it gives a second popup for the full citation, as implemented in {{harvc}} and related referencing templates.
Not sure how fluid this is for mobile, but hovering should work for anyone on desktop (unless the refs in the article have not been templated, which is still technically allowed in MOS). SamuelRiv (talk) 01:48, 11 September 2024 (UTC)
"Our current UI for presenting references sucks. Let's take John Rolph (today's TFA). I click on the first citation. That takes me to a list of references, highlighting ... So let's assume I figure out the highlighting mean 'click here' and I do that. This gets me to the 'Works cited' section, with ... highlighted." Over here, I hover the footnote superscript, which pops up a little box, and then I hover the author name + year, which pops up another box with the book metadata. There's no external link involved because this is a book, not a website. If I click the ISBN link I can get to a page that helps me find the book in a local library. –jacobolus(t)02:41, 11 September 2024 (UTC)
That's expected. They don't work on {{sfn}}-type citations if you do have NAVPOPS enabled. The WMF's tool does the hover-and-hover-again trick. NAVPOPS doesn't. WhatamIdoing (talk) 03:28, 11 September 2024 (UTC)
Yeah, that's a big difference. Although I'm reenabling NAVPOPS because the WMF tool doesn't use a popup for user pages, and the NAVPOPS have additional buttons for actions and other things. Andre🚐03:41, 11 September 2024 (UTC)
There is a difference between "can check" and "should check". Whether you should check depends what use you're putting the information to. If you're doing something safety critical, or academic research, or something like that then you absolutely should be checking the references relevant to your subject, but even then you don't need to check every reference. For example, if you are interested in the melting point of elements you should be checking the references for the melting points but checking the references for date of discovery would just waste your time.
For many purposes, Wikipedia can be trusted to be good enough. For example the other day I looked up when Alun Michael represented Swansea in parliament, if Wikipedia was wrong then one question on a quiz that at most 5 people will ever take will also be wrong. Thryduulf (talk) 20:26, 10 September 2024 (UTC)
I would say simply for intellectual hygiene and epistemological edification. People really shouldn't blindly trust anything written on Wikipedia without checking the references and even sometimes the page history. I've found errors many times. It's the nature of a wiki. I'm actually a bit aghast to find so many people defending the idea that references are just an inside baseball thing. Andre🚐21:56, 10 September 2024 (UTC)
Nobody is defending the idea that references are just an inside baseball thing and if think they are then you have very seriously misunderstood what people are saying. References are vitally important, but that doesn't mean everybody needs to check every reference every time. There are more facts on Wikipedia that are right than there are facts on Wikipedia that are wrong. That means any given fact on Wikipedia is probably true. For many purposes probably true is good enough. References exist for those situations where it isn't. Thryduulf (talk) 23:17, 10 September 2024 (UTC)
I assume that the "it" in "References exist for those situations where it isn't" is "probably true is good enough". The first time I read it, I briefly thought you meant that refs exist for when the Wikipedia article is wrong, and I thought that couldn't possibly be something you would say. WhatamIdoing (talk) 23:37, 10 September 2024 (UTC)
I guess it's quite likely that most statements on Wikipedia are true, meaning much more than half, but it's unclear if that means that any given statement may be true especially on obscure topics. There are hoaxes, incorrect information, mischaracterized sources, vandalism, and while there's an eventual aspect to this, vandalism and hoaxes aren't always found immediately, and some last for years, and some articles are insufficiently watched and find themselves subtly vandalized. I'd say it's probably closer to 80% than 99% or higher. A WP:BLUESKY statement is basically what I've seen Wiki discourse call an obvious statement. But for any non-obvious statement, as a reader reading the article, the likelihood of a fact definitely being true is more dependent on how recently extensively edited and how highly trafficked the article is. This is also something that users should be able to know about and check, and I'd say it's part of a mission of informational literacy to encourage surfacing this type of critical metadata. So checking out the article history and the references should, in my humble opinion, be a first class user activity or job to be done even for non-logged-in users. Andre🚐00:20, 11 September 2024 (UTC)
Again it all depends on what level of accuracy is "good enough" for the reason you are consulting Wikipedia - and that varies hugely. 51% likely to be correct is enough for some uses, 99% is insufficient for others. Thryduulf (talk) 00:28, 11 September 2024 (UTC)
I'm not arguing against the importance of references (and I'm probably more hardline than many editors about putting references in right away rather than leaving it to someone else to do). I'm just saying that "make users read references" isn't a key goal. The verifiability policy is for editors; it doesn't mean that a key goal of Wikipedia is for all of its readers to check every reference. By all means, of course, they should be convenient to use for everyone who wants to read them. isaacl (talk) 22:05, 10 September 2024 (UTC)
I don't think anyone wants to deliberately make it difficult for others (readers or editors) to check sources. But in terms of what how articles actually get used, I think it's reasonable fair to estimate that it's at least 300x as important to get the article's content right as it is to give someone access to a source.
On my list of things to do, I want to update Multiple chemical sensitivity. Among the choices I have to make are: choose sources with Full text on the Net, or choose a highly rated medical school textbook? I chose the latter, even though basically nobody will be able to check the source (it's US$120, or follow my example and use Interlibrary loan), and even though I may spend the next couple of years getting requests for quotations from "just one more paragraph" from editors who don't like what it says. But it's the best source for most of the information in the article. WhatamIdoing (talk) 22:35, 10 September 2024 (UTC)
Sure, by "convenient to use" I meant Wikipedia's citation system should make it convenient to see the citations and follow any provided links. I wasn't referring to how references should be selected. isaacl (talk) 23:55, 10 September 2024 (UTC)
I think that if we agreed that getting readers to read the cited sources were a "key goal", then it only would be logical to prefer sources that readers can easily/freely read. WhatamIdoing (talk) 01:17, 11 September 2024 (UTC)
Well, I think it's still better to use the WP:BESTSOURCES. People can pay if they really want to. There are also easy ways around paywalls. But the point being that it's cumbersome and cludgy to check the references. Better than nothing but could be better. I'm not advocating against the use of paywalled sources or non-English sources at all. Our responsibility starts and ends within the Wikipedia UX, and once we get you to the pay gate, it ends there. Andre🚐01:22, 11 September 2024 (UTC)
That's not quite true. If the same source is (legally) available in multiple places we should link to the more accessible one. If there are multiple equally good sources that verify the same content we should prefer the more accessible one. Obviously if one source is better we should prefer that one.
If there are three facts to verify and sources A and B are of equal quality; Source A is paywalled and verifies all three facts, source B is freely available to everyone but only verifies facts 1 and 2 (it's silent on fact 3), should we cite only source A, or should we cite source B for facts 1 and 2 and source B for fact 3? My gut feeling is we should do the latter, but I can see arguments in favour of the former. Thryduulf (talk) 02:14, 11 September 2024 (UTC)
I was discussing how references should be convenient to access, even though making readers read the sources is not a key goal. (I already stated that if it were, encyclopedia articles aren't the way to go.) isaacl (talk) 06:28, 12 September 2024 (UTC)
This is a use case for having invisible template text or a special transclusion type. Basically the archive links should live somewhere else, not in the actual article. Andre🚐19:43, 9 September 2024 (UTC)
The concern brought up here, and brought up repeatedly at CS1, is site outage and region blocks. The solution, given time and time again, is to just use the archive link. (Adding explicit parameter options to notify bots is apparently unworkable, so undocumented html comments are recommended instead?) SamuelRiv (talk) 20:14, 9 September 2024 (UTC)
So yeah, the archive link is useful, as a permalink of the article at that time, and solves a legitimate problem as you say, don't get me wrong. But for large articles someone blindly rescuing all the links, even ones that will never probably go down bloats the article with a ton of extra size for no gain, and it also creates a usability issue because in many cases the archive link, while preferable to a 404, is less usable than the real website - either due to lacking some assets or images, special javascripts or what-have-you. We've all experienced a great deal of jank browsing archive links, right? And there's no real reason that the archive links themselves need to be in the article for highly-trafficked sites, where the output of feeding that URL into the archive API will deterministically return something usable. As Rhodo says there's actually a bot that will store a map of the links, which seems like a good direction, versus having humans doing it. Andre🚐20:19, 9 September 2024 (UTC)
Region locks and region throttles. That gets worse for big articles on regional subjects, especially those updated with local news (frequently region-throttled), Trump and other US pols being good examples. I also fail to see how a relatively small percentage increase in the tiny fraction of articles that are both utterly enormous and highly volatile should be what makes or breaks IABot (especially since it's those articles for which the first point of my paragraph here is most relevant). There are surely other ways to address performance issues on oversized over-newsed articles (including, but not limited to, those already enabled by default for mobile). SamuelRiv (talk) 20:54, 9 September 2024 (UTC)
If articles are getting so big that editing them is difficult then they should be split. Unfortunately this will lead to having to defend some spinout articles against deletionists at AfD but that's a separate issue. Thryduulf (talk) 11:14, 10 September 2024 (UTC)
Some articles are also more densely cited than others, which is a dimension that does not justify merely equating wikitext length with the abstract conceptual length withholding particular technical hiccups. Remsense ‥ 论11:23, 10 September 2024 (UTC)
I'm not sure I fully understand that comment, but splitting because it cannot be edited without problems is just as valid a reason for splitting as it being too long to read comfortably. Thryduulf (talk) 12:04, 10 September 2024 (UTC)
Sorry for the confusion—I suppose I would rephrase by saying I disagree with that. Articles should be split for the sake of readers; if there is a distinct temptation to split for the sake of editors, we should critically examine whether there are technical problems we can fix to avoid such a solution first. Remsense ‥ 论12:09, 10 September 2024 (UTC)
I don't think Levivich is in a minority, and I agree with Ajpolino. Here is a good-faith example by Susmuffin which has made the article miserable to work with. After the addition of archive links, 12% of the page content is still archive links; it is not necessary to add archive links on sources like The New York Times, the BBC, The Washington Post and multiple others whose links rarely go dead, and editing around the now excessively lengthy citation templates is made more complex. I don't feel I can revert a good-faith edit like that, but I wish I could, as having all of that template clutter isn't helpful. SandyGeorgia (Talk) 11:04, 10 September 2024 (UTC)
The Washington Post and The New York Times both limit access in various ways. Both at times also change the content on pages without changing the URL. While it might not be strictly necessary to add archives to such pages, they still add value to the page and I would revert removal of them for any reason other than them being broken (and even then it would be much better to replace them with ones that aren't broken). The extra wikitext is unfortunate, but nothing more than that, especially since tools like Visual Editor and syntax highlighting reduce the impact significantly. Thryduulf (talk) 11:12, 10 September 2024 (UTC)
I agree that using IA as a tool to bypass paywalls is unethical, but how exactly does that work? Does IA maintain subscriptions to paywalled sites and then expose the pages they retrieve? RoySmith(talk)15:04, 10 September 2024 (UTC)
Some paywalls only trigger after a certain number of reads. Typically news websites. By using IA you can access a website even when you have used up all your free reads. Jo-Jo Eumerus (talk) 15:53, 10 September 2024 (UTC)
Websites sometimes
offer an openly available article at one time and then (sometimes many years) later retroactively put it behind a paywall, or
offer an openly available article to crawlers such as the Internet Archive's or Google's, but present a paywall to human readers.
I don't personally have a problem with including archived snapshots of paywalled pages in Wikipedia articles: these provide an important service to editors trying to verify claims made in articles, but are unlikely to significantly affect the website's revenue. If the website owner has a problem they can ask the archive site to take down the snapshot. –jacobolus(t)15:53, 10 September 2024 (UTC)
@RoySmith: In addition to the above explanations, there are various technical ways to get around paywalls, and the various archive services sometimes use some of those ways. As an example (apologies to the New York Times), here is a NYT article, it's paywalled for me, I'm not sure if for others this is displayable as one of the "free articles per month," which perhaps I've used up. Here is the archive from Internet Archive, you'll see it's also paywalled. Here is another archive from Archive.today: voila, no paywall, you can read it for free. In my personal opinion, this is almost certainly copyright infringement. (Disclosure: I've used both these archiving services on Wikipedia; I think we all have at one point or another.) Now, try this with Wall Street Journal [2] and it doesn't work. Archive.today can break through NYT's paywall but not WSJ; I don't know why, but there is some technical explanation arising from the two newspapers using different paywall technology. I don't know which paywalls IA respects and which ones Archive.today respects (if any). And while Wikipedia can't do anything about the archiving practices of other websites, what we really should not do is add archive links because some sites are paywalled, as was suggested above. Levivich (talk) 16:59, 10 September 2024 (UTC)
@SandyGeorgia If you find the archive links on living pages there to not be helpful, you should absolutely feel free to revert the change or otherwise remove them. Edits being done in good faith does not mean that no one else gets to disagree. –jacobolus(t)14:50, 10 September 2024 (UTC)
I object again that adding archive links is adding important functionality. On live links it gets around region locks and throttles (especially to foreign news outlets, depending on where one is based; a number of US newspaper sites for example still block EU IPs for GDPR). (in re above: 99.7% source click rate is honestly higher than I expected, btw -- if you consider the sheer amount of traffic WP gets, and for what purposes people use it, that's an awful lot of people checking sources.) An addition of 50k wikisource characters on template expansion becomes 100KB of HTML (UTF-8) for the client, which is rendered as plaintext + hyperlink. I'm sympathetic to slow browsers and computers, but we have mobile wikipedia for that reason, which would keep the citations section collapsed by default. (If this is a persistent problem beyond what I'm calculating here, then more fine-tuned client performance tweaks per page can be looked into here.) I really think there's an assumption being made that this creates a significant performance hit, when I think that instead the performance hit is endemic within the page. The articles being used as examples, like Trump, are gargantuan to begin with, bloated by constant breaking WP:Notnews updates and WP:Citekill. (I and others have tried to trim this bloat, only to be reverted for removing RS; per discussing a split above, a split for bloatedness is usually uncontroversial, which is why it's not in detail in the P&G, until it's not, and these articles are the result).
Taking a fresh page on Chrome with the Venezuelan election diffs cited above (before and after the 50k addition), the memory footprint upon opening is 92708k and 98388k respectively (restarted and cleaned browser each time).
tldr: is there evidence that the adding of archive links significantly affects client performance on a bloated page, as people claim? Or is the page already lagging their machine? SamuelRiv (talk) 16:59, 10 September 2024 (UTC)
It's a 99.7% non-click rate. One in every 300 page views results in someone clicking on a link in a ref. This is most likely to happen in short articles, so the belief is that people click on sources when they need more information than we can give them (e.g., you want to see a picture of the subject, and the Wikipedia article doesn't have one). WhatamIdoing (talk) 17:59, 10 September 2024 (UTC)
It would be interesting to see what fraction of that 0.3% happens while the article is undergoing some sort of review process (DYK, GAN, FAC, AfD, etc). My hunch is most. RoySmith(talk)18:08, 10 September 2024 (UTC)
I don't think so. Those processes affect so few pages/page views. The middle 50% of articles have 2 to 9 refs (not all of which will have links). The median article has 13 sentences, which is long enough to meet most readers' needs, but short enough that someone might be looking for more details.
There will be a certain percentage of misclicks, and I would not be surprised if misclicks outweigh editor clicks. There are just so many more readers than editors. WhatamIdoing (talk) 18:24, 10 September 2024 (UTC)
I agree, great insights. PDF citations more often clicked than a DOI or JSTOR? That's pretty scathing. Why don't we have a bot that harvests a raw PDF link and icons it? Andre🚐02:02, 12 September 2024 (UTC)
I think the solution for articles like Donald Trump is for an editor to sacrifice multiple hours to systematically replace citations that have only been used once in the article with a recent book. For example, there is a paragraph about him not serving in the military, citing four sources. It's likely that all four of those could be replaced by a citation to a single book. WhatamIdoing (talk) 18:07, 10 September 2024 (UTC)
I don't think we should be building policy based on exceptional cases like Donald Trump. There's always going to be articles like that and they're always going to be a pain to maintain no matter what policies and tools we have. We should concentrate on the 99.999%[citation needed] of our articles that don't have 834 references. RoySmith(talk)18:13, 10 September 2024 (UTC)
Donald Trump is the 267th entry on Special:LongPages, and if we assume that wikitext size correlates to the number of refs, it might have approximately the 267th most refs, which would put it at 99.9961% – very close to your off-the-cuff estimate. I'm impressed. WhatamIdoing (talk) 19:12, 10 September 2024 (UTC)
I gave my numbers. Would anyone else like to test page performance with and without mass IA linking on their machines/browsers, per above?
A couple posters have claimed there is reduced performance, but can people post evidence (I gave just one measurement) that the IA links actually affect performance to the significant degree that is being claimed? Because performance can, one way or another, be objectively demonstrated, unlike aesthetics (which is all this discussion reduces to, if it turns out there is no significant performance hit). SamuelRiv (talk) 02:16, 11 September 2024 (UTC)
Is it time to explore WikiCite? I know enwp doesn't like wikidata, but that project to take all the sources we cite and include them in wikidata has been going on for some time now. I imagine an archive link property is already in place. Time to have a bot replace citations with wikidata references and a bot to turn new citations into wikidata items? I don't expect so, but worth bringing up at least. — Rhododendritestalk \\ 12:34, 10 September 2024 (UTC)
Is it possible to have a smaller step, say one where archive links for live sites (ie. those created purely as a backup) can be stored at wikidata? That would keep the wikitext burden of the archive urls small (just a Qcode I suppose), while maintaining the backup functionality. CMD (talk) 12:43, 10 September 2024 (UTC)
I wonder if there have already been discussions about the intersection between IABot and WikiCite. i.e. when creating archive links, add them to Wikidata if there's an identifier available. @Cyberpower678 and Harej: — Rhododendritestalk \\ 14:59, 10 September 2024 (UTC)
Better integration with Wikidata is definitely what we are working towards, but no specifics about timelines and features yet. One step at a time. :-) —CYBERPOWER(Chat)16:29, 18 September 2024 (UTC)
I know this doesn't address all of the issues raised here, but apparently the latest version of the syntax coloring extention includes template folding which should make large citation templates less obtrusive. RoySmith(talk)16:58, 10 September 2024 (UTC)
The problem--or one problem--is that when editing a citation template, the archive-link stuff adds a bunch of extra stuff to the template that one must read (and process, and sometime remove).
Adding archive links to the citation templates for 'live' sources has both advantages and disadvantages. Should this be accepted as a best practice?
Should the inclusion of archive links for 'live' links be considered a form of WP:CITEVAR? If so, then editors running the Wikipedia:IABotManagementConsole script will sometimes have to discuss changing the article's citation style to include them before running the script.
I wasn't thinking of asking any question, but I don't think either of those two should be an RFC question, as they're too narrow, especially the second one, that's too wikilawyer-y. Thinking out loud here, I think a better RFC question would be something more open-ended, like: "when should archive links be added to articles?" Or something like that. Levivich (talk) 17:36, 10 September 2024 (UTC)
That question seems so wide that it might be more effective at collecting information than at producing a consensus. We're already collecting information here (128 comments by 26 editors so far), so I'm not sure what additional value an RFC would provide. WhatamIdoing (talk) 17:50, 10 September 2024 (UTC)
That parent category specifically says that members should be moved to subcategories where applicable so if someone is making a bad edit (i.e. where it is not applicable), revert the edit with the reason. — xaosfluxTalk20:37, 18 September 2024 (UTC)
@Xaosflux: I tried putting Keith Maillard in the top level of the diffusing categories and it took less than 1 day for it to be incorrectly "cleaned up" into the male category. The user who made the incorrect edit (and graciously admitted their mistake) wasn't a newbie, but an extended confirmed user with over 600,000 edits. This isn't just a one-off problem that can be solved by watchlisting a few pages, IMO. We now have approximately 1,000 articles about non-binary people (according to Wikidata) and keeping them correctly categorized has always been difficult. I really hope there is a better solution. Nosferattus (talk) 03:29, 24 September 2024 (UTC)
There is a related issue with nb subcategories being opposed at CfD as "trivial intersections" (even where the numbers clearly warrant a category) in a way that male/women subcategories are not. I think the answer is that if we are going to diffuse by gender, the nb category should be created and kept regardless of size. Having male and women subcategories with nb subjects thrown in the parent category makes it very counterintuitive for readers to find those articles, in addition to the persistent "cleanup" attempts you highlight above.--Trystan (talk) 20:40, 18 September 2024 (UTC)
Probably because some wanted to increase the visibility of female poets by separating them from the male poets. Then whether we create "male" (and now "non-binary") categories too or not depends on whether someone decides that full diffusion is necessary or that having only a "female" category could be interpreted as implying that female poets somehow aren't "real" poets. Anomie⚔12:24, 19 September 2024 (UTC)
Yes. Our current depth-categorization paradigm is guaranteed to create a classic resource problem (regardless of whether you want to call it intersectionality in race and gender, the same concept applies to any intersecting categories -- it's fundamentally formally a problem of sets, sorting, and query/allocation).
In the meantime, indeterminate categorization of gender (not nonbinary) is always going to be necessary regardless, what with all the edit wars over historical and ambiguous figures. Shrugemoji on the topic I guess. SamuelRiv (talk) 19:46, 19 September 2024 (UTC)
@Nosferattus_ Hi there! @Chaotic Enby reverted my recent edit to change from Category:Canadian novelists to Category:Canadian male novelists to the article and directed me here. Since Maillard is non-binary (a statement in the article that I hadn't read at the time I made the edit), it's fine with me to not add the article to any "male" categories.
That is a good question. In many of these cases, people are typically diffused into multiple subcategories under a diffusion category based on different schemes: gender, country of origin, time period, etc. If a person is already diffused into 1 of those schemes, and they don't fit into another scheme's subcategories, should they just be omitted? A literal reading of WP:PARENTCAT would suggest that, but this also seems problematic as it means non-binary people will be put into half as many categories as everyone else and thus be harder to find. Nosferattus (talk) 03:41, 24 September 2024 (UTC)
Is Category:West Virginia University appropriate? The only connection the article mentions is that one of his books was printed by the West Virginia University Press. Seems like there are stronger connections to University of British Columbia and Simon Fraser University in the article. GoingBatty (talk) 04:05, 24 September 2024 (UTC)
You're right, I meant half as many diffusing categories. He went to college at West Virginia University[3] although it isn't mentioned in the article. I actually don't know if he published any poetry in the 21st century or not. However he was a poet and he was alive during the 21st century. Does that make him a 21st century poet? Nosferattus (talk) 04:23, 24 September 2024 (UTC)
@Nosferattus Although he's not in male/female categories, he is included in LGBT(Q) categories. The article indicates his poetry was included in various 21st-century anthologies. I presume that being included in The Best of Canadian Poetry in English, 2008 means he wrote poetry in the 21st century, which makes me think Category:21st-century Canadian poets would be appropriate. GoingBatty (talk) 05:31, 24 September 2024 (UTC)
According to WP:TPG, the purpose of the user talk pages is to provide space for editors to discuss editing that page. Also, this page specifies that archives over 512kB should not be used for accessibility reasons. There is a good reason for that, as for extremely long pages, browsing on mobile is basically impossible because the browser can't handle the RAM overload and simply breaks, forcing to delete all the other open tabs along the way. My phone stopped responding when trying to put a CCI notice to this guy, who had 1.5 MB of text - and I haven't gone into images yet. My phone isn't particularly old, was first produced in 2017 - there are definitely folks out there with much older hardware on their hands.
More examples: my PC stutters on this, this, this and this user talk subpages; and in the case of Bishonen, these are not mostly newsletter subscriptions but actual talk page, even if archived. So if anyone were to browse it for whatever reason, they may get problems actually loading it, let alone using it for any meaningful purpose. And imagine trying to edit the talk page if, like me, you are editing by default in source code but use syntax highlighters, which seem to be loading the browser pretty heavily. My PC is not that old, either.
For active users, the same issue arises from talkpages like those of AwfulReader. For Dr Sroy or Masao - no longer active, installing Lowercase sigmabot 3 didn't work at all, as their pages are still at over 1MB.
In any case, there are very clear accessibility issues involved, so this needs addressing. Something to the tune of a change to WP:TPG saying If an editor experiences accessibility issues with the editor's user talk page because it is too large to navigate comfortably, they may archive it themselves after notifying the editor of the changes and explaining their character. When doing that, they should use reasonable sorting criteria (e.g. sort by year, or by a smaller period if size concerns justify it), and use sorting criteria that would allow comfortable browsing of archives (e.g. 100 kB per page).
I have, on rare occassions, seen excessively long user talk pages forcibly archived. People are generally given wide latitude on how to manage their own user space, but that doesn't extend to breaking the ability of the project to function. RoySmith(talk)19:10, 11 September 2024 (UTC)
Sorry, as the owner of this I didn't make the large page size deliberately. Maybe archive bots should have built-in overrides to not create such large pages? Stuartyeates (talk) 00:30, 12 September 2024 (UTC)
I wholeheartedly endorse some system of page size limitation and forced archiving in egregious cases. I have done this myself in the past. I would also note that in some instances editors have long abandoned the project while their talk pages continue to grow through various automated messages and through notices about their long-ago article creations being proposed or nominated for deletion. BD2412T19:14, 11 September 2024 (UTC)
Yeah, I tried to avoid listing these pages, as inactive editors are of little concern to me or to Wikipedia in most situations where you'd actually want to use the talk, but subscriptions do clutter a lot of user talk pages in at the top of the list by user length. Szmenderowiecki (talk) 23:48, 11 September 2024 (UTC)
I fully endorse a size limit on user talk pages, after which they are forcibly archived. This is a basic accessibility issue, and in my experience the editors with pages that are too long have usually been asked to trim them and haven't done so. Vanamonde93 (talk) 19:23, 11 September 2024 (UTC)
Good idea! But how would it work? Do the old posts get deleted? Will it Block you from puttibg in a New post? I think The smartest things to do would be that A: The old posts get archived OR B: The talk page gets split into two after a certain amount of posts. There would be a button at the top saying: "Older topics" or something like that. 87.95.81.141 (talk) 19:28, 11 September 2024 (UTC)
At the end of the day, if someone can't use a user talk page to talk to the user, it's fundamentally at odds with the principles of Wikipedia. I would support some restriction on page length. ~~ AirshipJungleman29 (talk) 19:30, 11 September 2024 (UTC)
To clarify, per TPG we can edit a User's Talk page already in certain cases, and if the user is inactive and not responding to an email and message request and this is an accessibility issue, then that seems like a perfect reason to just go ahead and fix it. We don't need a new policy that says we can do a policy.
For existing archives, when it's not just newsletter subscriptions that can all be pruned or replaced into a separate archive, I'm not sure what the best solution is (maybe preserving section anchors and then redirecting the content into Archive 16.1, Archive 16.2, etc.?). SamuelRiv (talk) 21:08, 11 September 2024 (UTC)
I support this proposal to enforce talk page size limitations. Maybe the best way would be to have a bot post a talk page notice once it reaches 150k or so, and then a month later, if it is still at or over 150k the bot automatically applies the archive coding and {{archives}} box to the talk page. Iggy pop goes the weasel (talk) 20:31, 11 September 2024 (UTC)
Just for clarity, many of these pages are not user talk pages, they are user talk page archives.
I realize this isn't AN/ANI, but it still would have been classy to tell people you're posting about them, by name, here.
I'm not necessarily against some kind of page size limit, nor necessarily for it. I'd need someone to convince me that it affects more than, say a couple of people. At some point, it is your responsibility to upgrade your equipment. Where that point is, is a reasonable thing to discuss. We can't all be expected to limit our choices so a 15-year-old computer still works, though.
Editing on the mobile site is not fit for purpose. I'd be against anyone insisting that talk pages be accessible to people using old (or new) phones with the sucky mobile interface.
I am against the original proposal that anyone with an ancient computer gets to decide the size of other peoples' talk pages and/or talk page archives. There would need to be some agreed-upon size limit, and if one's computer is so bad that this limit is still too big, it's time for a new computer. --Floquenbeam (talk) 21:30, 11 September 2024 (UTC)
I use the desktop site on a reasonably modern mobile phone for a large portion of my editing, and enormous talk pages can cause issues. It's also a problem with large talk page sections. So it's not just the mobile interface that has issues. We should also keep in mind that a large and growing number of editors use a mobile device as their primary, or only, means of editing. ScottishFinnishRadish (talk) 21:40, 11 September 2024 (UTC)
WP:User talk pages are inaccessible for many reasons. Making the best of the current system, I agree that you should politely ask someone to archive (let them decide how first). Conversely, I find it disruptive when users archive their talk page with each and every single edit, making it difficult to peruse through older conversations without going through their entire page history. Reading and replying to longer convos on talk pages while on mobile is next to impossible even in relatively short conversations. ~ 🦝 Shushugah (he/him • talk) 21:47, 11 September 2024 (UTC)
It's also a problem with large talk page sections: I could definitely get behind a size limit for individual AN/ANI/AE/ArbCom/VP threads! If it isn't solved after X kB of text (X is TBD), then zot, into the archive it goes. Floquenbeam (talk) 21:58, 11 September 2024 (UTC)
Wikipedia:Administrators' noticeboard/Incidents is a chronic offender, despite aggressive archiving, and I've wondered whether we could split it into a rotating list by day of the week (all getting archived to the same place – that part would be easy). This would make it easier for people to find manageable ways to help out ("I'll can keep an eye on WP:ANI/Monday if you'll take care of WP:ANI/Tuesday, but I refuse to watch every single dispute all year long") and keep each individual page relatively short. WhatamIdoing (talk) 22:30, 11 September 2024 (UTC)
It's amusing that a discussion whose basic premise is "Adding all that stuff bloats the page" is responsible for bloating this page. RoySmith(talk)22:33, 11 September 2024 (UTC)
I'm not opposed to a size limit on talk pages, but I agree with Floq here (sorry, Floq, I tried my best not to, but your post just made too much sense). I don't mean any disrespect here, but a 7-year-old phone is a really old phone, and I personally don't care whether people with obsolete hardware have a hard time accessing this website. It's the internet, backwards compatibility can only go so far (like 3 years). Beyond that, backwards compatibility is just not a priority in my view.
I remember having a similar discussion not long ago about "page weight" (the total size of everything that's downloaded on a webpage, images and text). It was in the context of thumbnail images. The average page weight now is 2MB IIRC. A rationale rule would be that no page on Wikipedia should have a page weight that is, say, larger than the average page weight on the internet (or 75% of that figure, or whatever).
But if your phone or PC is having a problem loading a 1MB page, you're using very obsolete hardware and probably have trouble surfing the rest of the web, too.
In general, Wikipedia should keep up with the times. Sure, let's not have greater-than-average page weight. But let's not worry about 2017 phones. Levivich (talk) 22:32, 11 September 2024 (UTC)
I think we actually should worry about 2017 hardware. Most people in the world can't afford to replace their devices every few years.
I am posting this from my MacBook Pro (15-inch, 2017). Up until early this year, it was my daily driver. I still use it extensively when not at my desk. I agree we can't burden ourselves with supporting ancient hardware forever, but three years is way too soon and even seven years is rather aggressive. RoySmith(talk)23:32, 11 September 2024 (UTC)
That's a MacBook Pro! That's one of the most expensive laptops on the market! Of course it'll last longer. Average PC lifespan is 3-4 years. Yes, Macs can last much longer, I've had MacBooks go 10 years before. But that's not typical. 84% of computer users do not use a Mac (16% market share). Levivich (talk) 23:37, 11 September 2024 (UTC)
Sorry, but if you are saying that to edit Wikipedia you need ultra-modern hardware then no, I don't agree with the premise.
Also, tell all the government agencies/school districts etc. to have their PCs go to waste every 3-4 years - I'd like to see taxpayers' reaction on that. It's fine if you want to upgrade it so often but we aren't speaking of playing AAA games or doing Photoshop or video rendering, it's just editing the text with a couple of images in a CSS envelope.
I'm not saying Wikipedia should be able to run on Nokia 3310 but I'm damn sure a lot of folks outside the western world just want a phone and not necessarily iPhone 16, and they will buy the cheapest Chinese stuff sold on the market, which will do the basic work of calling, texting and browsing/scrolling through memes/watching YT/listening to music/make some pictures. And even in my case I don't really see a point in high-end phones when budget options are just fine (my phone is a mid-range tier, and still works perfectly well after so much abuse I've inflicted on it).
Edit: actually, sorry, I was wrong: the phone I have was first produced in 2019, not 2017; my brother's is from 2017. So by no means "ancient hardware". Szmenderowiecki (talk) 00:07, 12 September 2024 (UTC)
Agree with this. I just checked to see my phone's age and it's pretty much seven years. I am looking into getting a new one, but I haven't treated the current one overly well. Seven years seems an aggressive cutoff for no backwards compatibility. CMD (talk) 05:38, 12 September 2024 (UTC)
To add to the anecdata, I am writing this reply from my seven-year-old phone which I sometimes use for simple editing. – Teratix₵05:46, 12 September 2024 (UTC)
Anecdata isn't data.
Globally, the replacement cycle of smartphones was about 21 months in 2016, with apparently longer cycles in developed markets (Counterpoint Research, 2016; Kantar World Panel, 2017). Interestingly, the average replacement cycle is close to the smartphone service contract length typically signed by consumers in Germany (Prakash et al., 2020), as well as in other countries. As a comparison, it is calculated that the median lifespan of a (pre-smartphone era) mobile phone decreased from 4.8 to 4.6 years between 2000 and 2005 (Bakker et al., 2014). — journal article
More:
In 2016, American smartphone owners used their phones for 22.7 months on average before upgrading. By 2018, that number had increased to 24.7 ... The life cycle of a smartphone in China was relatively shorter at 20.2 months in 2016 and 21 months for both 2017 and 2018.CNBC
As a result, the average amount of time that people own a car before replacing it, about eight years, dwarfs the length of time before a phone upgrade, about three and a half years.NYT
Today, the average lifespan of smartphones is around 2.5 years.USAToday
Why the average lifespan of a smartphone is only three yearsEl Pais
I wonder how often changes are necessary (e.g., physically broken) vs voluntary/consumer choices (e.g., "but I want the new iPhone!"). WhatamIdoing (talk) 20:27, 12 September 2024 (UTC)
That first paper goes into some detail about those issues. It also distinguishes between "functional lifetime" (user preference) and "technical lifetime" (how long the phone will physically function). Levivich (talk) 20:33, 12 September 2024 (UTC)
@WhatamIdoing For my last three phones, I replaced two when they physically broke (one after about 4 years, one after about 8 years) the other I replaced after the 2½ year contract partly because it had a few annoying minor issues and partly because there was an excellent upgrade offer available. Thryduulf (talk) 20:47, 12 September 2024 (UTC)
I don't know why we're arguing about this in the first place. People have complained about the problem. Let's fix it—which costs us nothing—instead of arguing that "it doesn't affect me" or deciding whether the opinions of the people who want it fixed are worthwhile. Thebiguglyalien (talk) 20:51, 12 September 2024 (UTC)
Averages aren't very helpful here – we care quite a bit about how large the cohort of older-than-average smartphones is. So, yes, anecdata isn't data, but that doesn't mean the first statistic you pull out of a journal is automatically going to be more useful. – Teratix₵15:20, 15 September 2024 (UTC)
Wikipedia users appear not to be from the same distribution as the average user in developed markets, considering some 32% (or 50% of mobile users) are using Android 10 according to WMF user agent data, which (the Android version I mean, not the data) was released in 2019. Alpha3031 (t • c) 16:39, 24 September 2024 (UTC)
Can we back up here? If page length alone in terms of wikitext is enough to break even a 20-year-old machine, then something is really wrong. The performance should not in principle scale disproportionately -- a Talk page is primarily, at scale, plaintext, with comparatively few templates. If the dynamic UX elements of Talk pages are scaling with, then that's a software problem to report to phabricator. (Also, on Talk page archives, already nicely templated, the dynamic UX should be disabled.)
You might have to manually disable the fancy discussion bells and whistles in your settings in the meantime, but for WMF default interface, 2017 hardware should be able to handle pages of this size, and if it can't that's a bug. SamuelRiv (talk) 05:10, 12 September 2024 (UTC)
First, when the problem is reading, then the "page length alone in terms of wikitext" is not a good predictor of the size of the HTML that's being delivered to you. A mere 51 characters of wikitext can put 1.6MB in your browser, if the 51 characters happen to be {{Wikipedia:Administrators' noticeboard/Incidents}}.
Second, even if the page weight is light (e.g., limited formatting, no photos), if a page has zillions of words on it, it's going to be difficult to find the part that you want to read. WhatamIdoing (talk) 05:43, 12 September 2024 (UTC)
I would support a maximum page length and also a ban on any formatting that breaks skin functionality and/or the reply tool. Garuda3 (talk) 22:58, 11 September 2024 (UTC)
Yes, it shouldn't be controversial to make pages more accessible at practically no cost. Just archive the page. It's super easy. If someone is inactive, then we can set up auto-archiving on their behalf. If someone is active but doesn't know this is an issue, then they can be notified (presumably by one of the people touting their performance above) or it can be done for them. If someone is active, knows this is an issue, and refuses to fix it after being asked, then they need to demonstrate that they can participate in a collaborative environment before anything else, because choosing to die on this hill fails to meet the very low bar of rational behavior we expect from each other. Thebiguglyalien (talk) 06:29, 12 September 2024 (UTC)
Maybe it's a script, but at the top of user talk pages I see "Latest comment:" with the time and date, easy to click on that and get to the bottom or close to it. Or just click the new topic button. Doug Wellertalk14:42, 12 September 2024 (UTC)
It is some sort of script, I just tried to go as a guest on a different browser on your talk page and the latest comment line doesn't appear - but I do have it when logged in. The PC version also has the "Add topic" button, but the issue is more with mobile than PC. On mobile you have the blue "Add topic" button, but because these pages load so slowly it is basically unclickable and can crash your browser in extreme loads (that is, if the browser doesn't crash before that because it thinks you are asking too much of it). Szmenderowiecki (talk) 15:23, 12 September 2024 (UTC)
Floquenbeam, the old phone is a bit of a red herring; I'm currently on a state-of-the-art laptop and an ethernet connection, and there are user talk pages that have a noticeable load time. Vanamonde93 (talk) 15:50, 12 September 2024 (UTC)
It's not just going to be device age. It's also going to be internet connectivity/ bandwidth for a laptop and wifi 3G/4G/5G coverage for a phone? These are likely to be variable. Especially if people edit while moving around. Martinevans123 (talk) 17:02, 12 September 2024 (UTC)
I just don't think "no noticeable load time" is a reasonable criterion. I have my own personal experience too; my 2450 page watchlist (that's not gigantic compared to others) takes about 6 seconds to load, and a certain editor (who is famous for a large talk page) has a talk page that currently takes me about 4 seconds to load. I realize watchlist sizes vary, and this probably depends on a dozen things I don't understand, scripts I have loaded, etc. But I don't think I have a right to insist that an editor ensure that their talk page loads quicker than my watchlist. What we really need - if this is currently an actual problem for a significnat number of editors - is some kind of methodology respectful to both extremes, and some kind of rational criteria, so that (a) the number of editors who have a hard time loading a page (esp. a talk page) using desktop mode is "reasonably" small, and (b) the number of editors forced to change the way they manage their talk page is "reasonably" small as well. If anyone can claim they can't load someone's talk page with no way of proving it, and force a change, then people will immediately weaponize that rule and try to piss off their perceived enemies. Floquenbeam (talk) 17:36, 12 September 2024 (UTC)
some kind of methodology, it's called "page weight". The median today for desktop is 2.7MB, for mobile it's 2.4MB [4]. You can test a page's page weight with tools like this one: [5]. I checked the ones mentioned here:
Bish's archive 19 does take a hot minute for my work PC to load... and it's less than a year old.. but at the same time, how often are people looking back at archives? is a slower load a huge issue? -- Aunva6talk - contribs19:17, 13 September 2024 (UTC)
The original link is for non-user talk pages, not Wikipedia:User pages. " User pages are for communication and collaboration. While considerable leeway is allowed in personalizing and managing your user pages, they are community project pages, not a personal website, blog, social networking medium, or a Wikipedia article. They should be used to better participate in the community, and not used to excess for unrelated purposes nor to bring the project into disrepute."Doug Wellertalk16:02, 12 September 2024 (UTC)
This is a technology problem and the WMF is responsible for providing the core technology. The core issue is that Wiki software is not a good tool for creating and managing a mailbox facility. And the widespread use of scripts and templates makes the problem worse by encouraging people to spam bloated messages with a single click.
My real email inbox is much better. With that, I can file or delete or tag messages easily. I can set up filters to route them automatically. There's a spam filter and sensible defaults which segregate the different types of messages – social media, promotional, newsletters – so that the primary inbox is comparatively uncluttered.
But, checking latest developments at mw:Talk pages project, I'm not seeing a lot of activity there. I'll try a little innovating in my own case....
That team is working on mw:Edit check now. I would not expect any significant new features to be added during the next year. Additionally, one of the community-imposed restraints on it was that it be compatible with wikitext, which means that filtering and tagging are not realistic. WhatamIdoing (talk) 18:44, 13 September 2024 (UTC)
Anybody who wishes can archive my talk page. I tried to do it once and I couldn't figure out how. The instructions were impenetrable for my technology level of pen and paper 1.0. Smallchief (talk) 19:49, 13 September 2024 (UTC)
I think we would do well to have a bot which sets up talk page archiving for all new accounts. Maybe only after they pass some minimal activity bar like autoconfirmed. Pick a reasonable configuration and it'll be fine for 99.99% of users. RoySmith(talk)22:42, 13 September 2024 (UTC)
A one-time pass on User_talk: pages above a certain size+staleness (say, >50kb and only affecting comments >90 days old) would probably also be fine for 99.99% of users.
A one-time pass has the advantage of not generating ongoing support requests ("It archives my page every day! How do I turn this thing off?!" as well as "I don't read the village pumps, participate in RFCs, or watch CENT, and I hate this, which is proof that you don't have consensus for this!"). WhatamIdoing (talk) 00:51, 14 September 2024 (UTC)
Rather than having a bot, can't you build that into the standard Welcome messages? I realize that wouldn't hit 100% of the new accounts, but likely a large percentage. -- Nat Gertler (talk) 14:40, 14 September 2024 (UTC)
I suspect it would be closer to nobody. People don't read instructions, and people certainly don't take the time to implement things that they have no immediate need for. RoySmith(talk)14:49, 14 September 2024 (UTC)
I think that'd be a waste of effort and edits. Even if you wait until after the person actually makes an edit (thereby ignoring 70% of new accounts), almost none of the people who make an edit actually need things archived. 99% of (successful) editors never make 500 edits. The odds of someone making less than 500 edits and needing an archiving system is very low. A few of them might need to be unsubscribed from various newsletters, or to have non-discussion test edits moved to a sandbox, but I wouldn't expect routine archiving to be useful for brand-new or low-volume accounts. I could imagine a bot that says "Congrats on your 1000th edit – I see you have a kind of long talk page, so I've installed a talk-page archiving system for you", but not for new accounts. WhatamIdoing (talk) 00:49, 15 September 2024 (UTC)
I'm not saying instruct them to set up archiving. I'm saying that the Welcome message is generally the first message on the talk page, and if we included the actual archiving code in the template, then it would be set up by default. -- Nat Gertler (talk) 00:53, 15 September 2024 (UTC)
New users are the ones least likely to be making excessively long talk pages, so it seems to me that this aims at the wrong cohort. Zerotalk02:53, 15 September 2024 (UTC)
The last time I remember this being discussed (where was it?) it transpired that people who had the most trouble reading longish user talk pages were using some particular gadget. Sorry, I don't remember the details. My opinion then, as now, is that average users should not be forced to manage their user pages to compensate for the choice of a few users to make trouble for themselves. Of course there has to be some limit, but limits that are smaller than thousands of articles don't make sense to me. If someone can read a 300KB article just fine but they can't read a 300KB talk page, it isn't the talk page's owner who's at fault. Zerotalk02:53, 15 September 2024 (UTC)
You know the answer. But are you saying that a smartphone can read long articles, but not talk pages of the same length? Zerotalk03:56, 15 September 2024 (UTC)
Regardless, it makes sense to have a policy about page weight and load times (from multiple continents), which should be calibrated against the current internet average, and updated every few years, and applied to every page on the website, regardless of namespace. And the benchmark should be logged out users, not logged in (since by far most readers are logged out, and it'll avoid the gadget/script issue). Levivich (talk) 04:23, 15 September 2024 (UTC)
It occurs to me it's not just page loading time, but also edit publishing time, that matters. We ought to have benchmarks for that, too, also logged out for the same reasons as above. Maybe we could run an RFC asking people to log out and edit EEng's talk page and report back how long it took for the edit to publish? After it runs the usual 30 days, we should have a good sample size. Levivich (talk) 05:18, 15 September 2024 (UTC)
That doesn't seem kind to EEng, who would get a lot of notifications from test edits.
I understand that there are professional services that measure website performance in a variety of different contexts. If we really need this to be done, we could do it properly. However, I don't think we need this to be done. I think we need to agree on a rule that allows generously large talk pages and requires action in response to certain types of complaints.
For example, we could adapt the principle in WP:RFD#KEEP that "Hint: If someone says they find a redirect useful, they probably do" to say "If someone says they find your talk page too large, they probably do", so you should archive it, but reject complaints below a certain size (User:MiszaBot/config gives | maxarchivesize = 150K as an example, and I suggest adopting that) and never require archiving content that is less than (e.g.,) six months or a year old. WhatamIdoing (talk) 16:22, 15 September 2024 (UTC)
The gadget referred to by Zero0000 was Wikipedia:Convenient Discussions, which is a javascript tool. Tools like this are a bad idea because they are not supported by the WMF. They tend to get broken by technical change and/or become orphaned and unsupported when the enthusiast that wrote them burns out. Andrew🐉(talk) 14:06, 16 September 2024 (UTC)
Isn't this something that is better addressed on the application side rather than the source side? It's obviously very common for the volume of data returned by some kind of request/query etc. to exceed some preferred limit and this is usually handled by returning the data in chunks/using pagination etc. Sean.hoyland (talk) 04:39, 15 September 2024 (UTC)
I think we want a "both/and" approach instead of an "either/or" approach.
Also, it's not just loading time. It's scrolling time, searching time, and editing time. Long pages are less manageable even after the page is on screen. WhatamIdoing (talk) 16:14, 15 September 2024 (UTC)
But the number of times someone wants to scroll through a long talk page or open the whole thing to edit is negligible. The relevant actions are reading the bottom of the page, opening the last section and starting a new section. The last two at least should not depend on the page length, and if they do there is a technical fault. Zerotalk02:35, 16 September 2024 (UTC)
How do you read and edit the last section (or at least one of the sections at the bottom of the page; this section is the penultimate one at the moment) on a long page, without scrolling down to it? WhatamIdoing (talk) 03:24, 16 September 2024 (UTC)
That depends on how busy the talk page is. Mine is very quiet so sure, most of the time, only the last section is active (if any). Talk pages with more interaction can have several active threads at once. isaacl (talk) 05:55, 16 September 2024 (UTC)
I get to the bottom like I got to this section, by clicking on the index. Anyway a simple solution would be for Talk pages to open by default at the bottom rather than the top. I'm sure the techs could do that and it could be an option. It would save a lot of time even on talk pages of moderate length. There could be a template that stops that behavior on noticeboard pages like this one, RSN, etc. Zerotalk06:16, 16 September 2024 (UTC)
The way HTML works, browsers have to render the whole page before they can scroll to the bottom. Thus for a solution like going to the bottom of the page to actually save rendering time, the page would have dynamically load via Javascript. Some users dislike this, as it causes the content to change its layout as new portions of the page are loaded. isaacl (talk) 06:43, 16 September 2024 (UTC)
I go to any user talk or other talk page on this website, there's a "+" button at the top to add a new section. No scrolling to the bottom is required. I think this is part of the discussion tools that were rolled out a few years ago. Levivich (talk) 16:35, 16 September 2024 (UTC)
That button doesn't exist on the mobile site, and even on the desktop site (=my own personal preference), it doesn't help you read existing comments. WhatamIdoing (talk) 21:38, 16 September 2024 (UTC)
Well... maybe not? If a page is extremely large or awkward, it may impede communication between editors, which can lead to preventable drama.
Also, sometimes little problems really do need to be addressed. Individually, they may just be little "paper cuts", but paper cuts are irritating, and cumulative irritation drives people away. WhatamIdoing (talk) 16:08, 23 September 2024 (UTC)
This could have been solved in 15 minutes, but it wouldn't be a Wikipedia noticeboard without a 5,000 word discussion to decide whether solving problems is a good thing. Thebiguglyalien (talk) 21:27, 23 September 2024 (UTC)
Here's a solution for whoever is complaining about a UTP being too long: teach them how to click on the + tab in the top margin. No scrolling required. Problem resolved. (somebody already mentioned this resolution a earlier.) Atsme💬📧00:31, 24 September 2024 (UTC)
WP:BRD, while an essay, is well established. It would require that a bold edit, once challenged should be discussed. It fairly clearly indicates that the discussion should be opened by the editor making the bold edit. WP:BRD fits well into our policies such as WP:CON and WP:VER (see also WP:ONUS and WP:BURDEN). It is my observation that very few editors making a change actually initiate a discussion when an edit is challenged. While WP:3RR (and variants such as 1RR) are meant to counter disruption, in practice, they act in a contrary way that encourages the bold editor to persevere in forcing their edit through reverts rather than gaining consensus or despite P&G (the broader community consensus). A remedy would be to consider the initial challenged edit as being a revert from the status quo. This would change the dynamic and should encourage good faith editors to initiate discussion rather than engaging in disruptive reverts. For discussion. Cinderella157 (talk) 11:24, 25 September 2024 (UTC)
It's still edit warring even if you don't hit 3RR. That could be made clearer. But making a change from the status quo is not disruptive and should not be considered a revert. voorts (talk/contributions) 13:07, 25 September 2024 (UTC)
@Cinderella157, have you read BRD recently? It says things like:
"The talk page is open to all editors, not just bold ones. The first person to start a discussion is the person who is best following BRD."
"Alternatively, start a discussion yourself [←the reverter] on the article talk page about the issue."
I'd say that it "fairly clearly" indicates that following BRD requires someone to start a discussion, but that someone doesn't have to be the bold editor. WhatamIdoing (talk) 19:31, 25 September 2024 (UTC)
It doesn’t matter who starts a discussion… what matters is that someone start it. So… if “the other guy” doesn’t, then “you” should. Blueboar (talk) 19:51, 25 September 2024 (UTC)
I agree.
The notion of "original" BRD is this:
There would be a known problem that people are having trouble resolving.
Instead of getting bogged down in (further) discussion, you would make a bold compromise edit.
You would wait to see who disliked your compromise enough to revert it.
You would talk to that one (1) person, until the two of you agreed on something, and implement that.
Repeat as many times as necessary if another editor dislikes the change that the first two editors agreed upon enough to revert it.
I'm not sure what you're proposing. Are you suggesting that any new edit be considered a revert, and so someone contesting it should open a discussion, as per the bold, revert, discuss cycle, thus making it a bold, discuss cycle? Are you suggesting that since any new edit would be considered a revert, editors should discuss them first on the talk page to avoid getting into back-and-forth reversions? Are you suggesting that the 3-revert bright line be changed to a 2-revert bright line, so the new edit would remain in place during discussion? As the other commenters have stated, the ultimate goal is to get discussion going, no matter who starts it, rather than just churning the page. Individual situations differ a lot, making it hard to give blanket guidance, and so the guidance allows a degree of discretion. isaacl (talk) 21:27, 25 September 2024 (UTC)
The suggestion seems to be that any new edit be considered a revert for the purposes of 3RR, so the new edit would not remain in place during discussion. CMD (talk) 02:14, 26 September 2024 (UTC)
The scenario raised below is for an article with one-revert rule in place, so I'm not sure if the intent is to only cover that case. You're right; the only effect would be to turn the 3-revert bright line into a 2-revert bright line (using the current definition of revert, which doesn't include the new edit). isaacl (talk) 02:34, 26 September 2024 (UTC)
In the current policy, the system is bold(OP)->R1(P2)->R1(OP)->R2(P2)->R2(OP)->R3(P2)->R3(OP). This means the bold edit is edit warred in, as the next step, R4(P2) gets a brightline block. If you treat the initial bold edit as a revert, then the brightline block occurs at R3(OP), meaning policy does not facilitate the edit warring of changes into articles. This works for any stage of XRR where blocks occur at RX+1. CMD (talk) 02:49, 26 September 2024 (UTC)
This would be applicable to 3RR or 1RR. I used the 1RR example because there are less steps and therefore easier to follow. Also, the shortcomings of the rules are more evident in the 1RR scenario. It is not the same as converting the 3-revert bright line into a 2-revert bright line using the current definition of revert. It would change the current definition of a revert to include the new edit. Cinderella157 (talk)
Scenario 1 with 1RR protection.
Editor A adds a commander to a conflict infobox with a summary that they are important.
Editor B reverts with the edit summary: Per MOS:INFOBOXPURPOSE - not supported by body of article - ie there is no mention of the commander that would tell a reader why they are in the infobox.
Editor A re-adds commander with essentially the same previous edit summary and not addressing the reason the initial edit was reverted
The addition is unsourced (WP:BURDEN). There is no attempt to establish consensus for the addition (WP:ONUS). It is also contrary to MOS:INFOBOXPURPOSE. There are multiple points of P&G for the addition not to stand. Editor A has not reasonably engaged in consensus building. By just reinstating the same material for the same reason, they are effectively edit warring. 1RR is not being as effective as it could and probably should be. To effect, it is rewarding Editor A for edit warring. However, if Editor A's initial edit were considered a revert (from the status quo) the dynamic would be changed. They could not simply revert. At the very least, they would need to discuss and get clarification of the reason given in the edit summary by Editor A. Consequently, 1RR would be more effective in preventing edit warring/disruption, preventing changes contrary to P&G and, in building consensus and a better understanding of the broader community consensus. A similar scenario could be written around 3RR and material being edited in the body of the article but would be more complex because of the many additional steps.
There is nothing wrong with editing boldly. What is wrong is simply re-adding the same material with no attempt to build consensus or acknowledge P&G reasons why the edit might be considered inappropriate. BRD does not mean that the initial editor is the only one who can start a discussion but the initial editor should not just re-add the material without engagement. However, WP:ONUS does place a burden on the initial editor to establish consensus. Revert (in BRD) is not a get-out-of-jail-free card. Without reasonable reason, it is just stonewalling. Preserving the status quo is not of itself a good reason but there may be other factors such as the WP:CONLEVEL for the status quo or prevailing P&G. Cinderella157 (talk) 01:50, 26 September 2024 (UTC)
One of the problems is the 24-hour rule that experienced edit warriors are easily able to avoid.... that's causing a slow edit war that needs to be reported to the administrator notice board causing a great amount of time to file the report. Moxy🍁 02:27, 26 September 2024 (UTC)
Are you proposing that the one-revert rule be enforced more strictly when a one-revert rule has been enacted for an article (or category of articles), thus allowing step 3 to be undone to restore the state after one revert? Or are you proposing that instead of placing articles under a one-revert rule, articles should be placed under a prior agreement required rule for any new edit? There are some cases of prior agreement required rules, but so far it's quite rare. There is considerable overhead in managing all new edits through talk page discussions. isaacl
As above, the proposal is not just for 1RR. The 1RR scenario is just easier to follow because there are less steps. What does the proposal mean in terms of the scenario? Step 1 and step 2 are fine. Step 3 is not fine because it is just re-adding contested material and reasonably falls to edit warring. Under the proposal it would breach 1RR. Incidentally, this is a real scenario. In Step 4, Editor B has opened a discussion, restating the reason in the edit summary (albeit with a small amount of additional detail). Cinderella157 (talk) 02:58, 26 September 2024 (UTC)
OK, so you're proposing that an editor cannot re-insert a change once it has been reverted, until there has been a discussion establishing consensus? That sounds like mandating discussion after a change is reverted (basically similar to the bold, revert, discuss cycle). I prefer looking at the desired state of the article during discussion, rather than counting reverts, which just gets people distracted with arguing about what counts as a revert and whether the editors involved are unfairly resisting a change through joint action, when the focus should be on the content being changed. isaacl (talk) 03:19, 26 September 2024 (UTC)
No, one would expect BRD, but in practice, this might be something like BRRRDB. Regarless, it should not be BRRRRR ... Where the Rs stop before you get a block depends on whether it is 3RR or 1RR. No editor should just be re-inserting an unmodified change because they can. It is ipso facto edit warring as opposed collaborative iterative improvements. Good editors will initiate discussion. Bad editors will just keep pushing their preference even when it is contrary to P&G. The proposal doesn't change things that much except to draw the bar a bit closer for the editor making the change in respect to either 1RR or 3RR. It should discourage the editor making the initial change from edit warring because they have one more revert up their sleeve even though they have not achieved a consensus per WP:ONUS. Cinderella157 (talk) 03:58, 26 September 2024 (UTC)
The problem with counting reverts is that it focuses on a numbers game: who can get more people to revert on each side? We need to have a discussion, and get enough participants to form a consensus. So many content discussions wither because there aren't enough people available to engage. isaacl (talk) 04:13, 26 September 2024 (UTC)
As someone whose biggest point of self-critique is easily that they revert too much and explain not enough in certain moments, and who would like to revert twice or thrice less than they do, I think it's fairly clear to me that my less BRD-adhering, unhappy moments are almost entirely motivated by a thought process like "if I don't fix this, no one else will see it for hours or days, if ever, and what's more I have to be really assertive about it to make the point clear to the other editor"—and ultimately that can result in more bluntness than is required. I don't like when I end up acting less than zen to other editors, and I have admittedly allotted myself a lot of "turf" on my watchlist to patrol.
If reversion is not the end of a given situation, and communication is not immediately fruitful, the natural next resort are WikiProjects, the content noticeboards, or I suppose WP:3O. Something has occurred to me, though it seems a little silly on first blush: what if we had an AIV-style "rapid-response" board for certain disagreements—let's say specifically style disputes for now. That's not quite what 3O is: instead, it could serve as a possible pressure valve so that editors feel they don't have to handle a situation themselves in the here and now. Editors who are comfortable with the Manual of Style could monitor the board, and quickly clarify matters they feel they can help with that get requested. I like talking about the MOS, and I feel others might volunteer for this too. I imagine stale reports would be cleared on a regular basis like AIV, but by that point the posting would also have served its purpose if the posting editor waited for a response like you'd expect: they've now had time to cool down and assess other options for dispute resolution. Remsense ‥ 论07:32, 26 September 2024 (UTC)
It's hard, right? The MOS pit tends to invite general discussion, and I think people would hesitate to post at regular intervals like they would to AIV. Maybe it could be a part of 3O, but I do think there's something there in "people would benefit from a high-visibility, low-friction venue to help nip petty disputes in the bud" Remsense ‥ 论08:30, 26 September 2024 (UTC)
I've had issues with content matters unrelated to style, and the associated WikiProjects didn't respond, either because they were lacking in active participants watching the WikiProject talk page (which is the case for many of them), or apparently the issue wasn't sufficiently interesting for people to weigh in (which happens even with reasonably active WikiProjects, like those associated with popular sports). You can't generate consensus unless enough people engage in discussion. isaacl (talk) 15:45, 26 September 2024 (UTC)
Of course, and at that point the entire mechanism breaks down. Not sure what to systematically do about that other than "my best". Remsense ‥ 论15:52, 26 September 2024 (UTC)
The point was that I think revert wars happen when there aren't enough people to generate consensus, or they aren't interested in having a discussion, and tweaking how reverts are counted won't change this. isaacl (talk) 16:05, 26 September 2024 (UTC)
@Remsense, I don't know what kinds of pages you're watching, so this might not help with your quest for a zen-like detachment, but you can calculate the average time between page views, and use that to estimate how long you have to act before the next reader will appear. 2 page views per day = 12 hours, 6 pages views per day = four hours, and so forth. Most articles get less than one page view per week. 90% get less than one page view per hour. So unless you tend to be on high-traffic articles, for the most part, instant reactions are not necessary to protect the reader from seeing m:The Wrong Version. WhatamIdoing (talk) 00:54, 29 September 2024 (UTC)
About this: What is wrong is simply re-adding the same material with no attempt to build consensus.
As a general principle, this sounds okay, but in specific instances, that's probably not the case. For example, years ago, I was part of this "edit war":
A removes a sentence (originally written by B) from an article (e.g., while copyediting the whole page).
B puts the sentence back.
A removes that sentence again.
I was "B", and I was really happy that it was removed the second time, without any time-wasting trips to the talk page. Why? Because the second edit summary stated more clearly that the specific sentence had been accidentally duplicated. Sometimes mistakes happen. Maybe not at the 3RR level, or even at the 2RR level, but sometimes simply reverting is the right thing to do. WhatamIdoing (talk) 00:49, 29 September 2024 (UTC)
WikiPolicy / Recommended Practice question: "how many examples are enough?"
I have not seen this type of disagreement between two editors anywhere else on wikipedia, so I want to bring it up for a more general discussion. The question is about an appropriate number of examples to illustrate a non-controversial topic:
1) how many examples are sufficient/appropriate?
2) what constitutes a "clutter", when giving a list of examples?
3) is adding an example from a class, which is not present in the list, a clutter?
I would like to get opinion of 3rd parties instead of limiting the food-fight to the two original parties.
More specifically, I am talking about this article: https://en.wikipedia.org/wiki/Inflection .
I made a minor change to this article. More specifically, I added Russian language as an example of as highly inflectional language. I specifically wanted to add Russian there, because this list is missing Slavic languages completely, and because Russian is mostly widely spoken of the Slavic languages:
After my edit the paragraph reads:
Languages that have some degree of inflection are synthetic languages. These can be highly inflected (such as Latin, Greek, *Russian*, Biblical Hebrew, and Sanskrit), or slightly inflected (such as English, Dutch, Persian). https://en.wikipedia.org/w/index.php?title=Inflection&oldid=prev&diff=1248062111&markasread=327526085&markasreadwiki=enwiki
In addition I would like to ask:
4) Is there a wiki-policy about appropriate number of examples to illustrate a non-controversial topic?
5) How do you find if Wikipedia has a policy about something?
There's no policy or guideline specifying number of examples (and, IMO, there should not be). It's a matter of editorial judgement. In this case, it's a simple content dispute. It's unfortunate that you didn't engage in the talk page discussion that Remsense began on the issue and instead posted on three noticeboards (Teahouse, 3O, and here). Schazjmd(talk)14:14, 29 September 2024 (UTC)
In addition I want to mention, that editor "Remsense" has no expertise in Comparative Linguistics ( as can be judged from his profile and non-deletionist edits). — Preceding unsigned comment added by Walter Tau (talk • contribs) 12:56, 29 September 2024 (UTC)
The only reason this wasn't closed on the spot was you said you wanted to discuss the general case. Whining about other editors you're disputing with is not a matter for the village pump, it's a matter for WP:ANI, but you won't like the result if you go there, so I don't recommend it.
Are you satisfied with Schazjmd's answer that there is no standard, and it's a matter for editorial discretion? If so, we should close this. (But Schazjmd is correct, there's no simple rule. Acceding to requests like yours every time will make it impossible to list select examples, and will collapse into "here is the full list" for everything if everyone insists on their favorite example being included.) SnowFire (talk) 18:59, 29 September 2024 (UTC)
Dear @User:SnowFire, thank you for you input. This is the first time in my many years of wiki-editing, that I have engaged into a dispute with another editor. I am not familar with the available dispute resolution means, so this is my learning lesson. Unfortunately, I get different and conflicting suggestions from different editors of what is the most appropriate rout, so I cannot call this lesson a complete success. Nevertheless, I feel that the proposal by 3O for @[[User:Иованъ] on https://en.wikipedia.org/wiki/Talk:Inflection is the most appropriate way to end this discussion.
Notably, his proposal suggests criteria for including specific examples, which was my original Village Pump question. To rephrase @User:Иованъ's suggestion :
when making a list of examples, limit it to the most common (or distinct in another way) examples of each class.
Is there any way to put this suggestion for a discussion to make it into a wiki-policy?
I don't find it necessary to make the very basic principle that communication is equally about "what not to include" part of my wikıïdentity. Remsense ‥ 论22:20, 29 September 2024 (UTC)
This is the kind of thing to suggest on Talk:2017 edition of the Samsung Galaxy A series. Because the respective sections are so small, you should give substantial reasons for separate articles: either that you would have substantial amounts of content to add separately to each, or that they are such substantially different entities covering different topics to have separate discussions. (An example of the latter would be if the A5, and only the A5, had extensive controversy on launch and massive explosions and lawsuits, a significant digression from the flow of the main A Series article -- that would warrant a separate article for the A5.) SamuelRiv (talk) 00:38, 8 October 2024 (UTC)
I'd like to hear from people who don't know much about Korea or Korean history, but are familiar with Wikipedia style as a whole. This is a pretty major topic that would affect thousands of articles.
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.
Its existing functions may be moved elsewhere, at the discretion of editors. Examples: FTN function could be moved to a WikiProject discussion page; it could handled by other policy noticeboards (namely RSN, NPOVN, NORN, BLPN, and AN).
Question 2: Should the Wikipedia guideline WP:Fringe theories (WP:FRINGE) be disbanded? You may give specific options for resolving guideline sections, including:
2A. Downgrade WP:FRINGE from a guideline to an explanatory essay;
2B. Deprecate and archive WP:FRINGE guidelines altogether;
2C. Merge sections of WP:FRINGE into the larger guidelines that refer to them:
Option 2C examples (this is a partial attempt at a comprehensive list): WP:V section REDFLAG cites FRINGE as main article; WP:RS has a "Fringe" section that cites PARITY; WP:N has a "Fringe" section citing NFRINGE; WP:NPOV has a "Fringe theories and pseudoscience" section as well as scattered citations to FRINGE and its various sections; WP:BLP does not cite WP:FRINGEBLP, but FRINGEBLP cites BLP and NPOV.
Affirm or reject either, both, none, with any number of suboptions (nothing must be mutually exclusive).
Reject both, WP:FRINGE has no need for any such changes. The fact is that this all arose because FRINGE POV-pushers of religious topics got angry that their pseudoscience claims were being appropriately described in our articles as pseudoscience. It's ridiculous we're even entertaining this RfC at all when that's the background context and reason for it. SilverserenC00:40, 18 October 2024 (UTC)
The fact is that this all arose because FRINGE POV-pushers of religious topics got angry that their pseudoscience claims were being appropriately described in our articles as pseudoscience.
What!?’ With all due respect this is wholly divorced from the reason this came up. The specific issue was removing a peer-reviewed study demonstrating a fringe topic was not real, because that user rejected that academics at a secular university could be trusted because they were themselves Buddhist. As the person you’re accusing of being a “FRINGE POV-pusher” here I’d appreciate that struck, it’s uncalled for. Warrenᚋᚐᚊᚔ17:57, 18 October 2024 (UTC)
No, and No.WP:FTN fulfils a necessary function on Wikipedia, and has done for many years. A centralised noticeboard is far better placed to tackle issues which very frequently involve multiple factors when considering such disputes. They are very rarely just about sourcing, just about NPOV etc. As for the guideline, it is just that - a summary of policy etc laid out elsewhere, emphasising the relevant parts of such material. There are certainly sometimes issues with the noticeboard, and quite possibly the guideline needs improvement in places to more accurately reflect policy, but the alternatives offered here seem to be based around the premise that the noticeboard is the root cause of 'fringe material' problems, rather than the material itself. AndyTheGrump (talk) 00:49, 18 October 2024 (UTC)
No and No. Just seems like unhelpful process-ology, with no rationale give. NPOVN and FTN and both busy enough, so making a mega-board would just create something unwieldy. WP:FRINGE is a well-established guideline and Wikipedia's handling of fringe content is one of the conspicuous successes of the Project according to academic assessments (though not, of course, according to advocates of fringe idea who are frustrated by Wikipedia's standards). The world of sources 'out there' is not becoming less contaminated by pseudoscience, misinformation and conspiracy theories. If anything, the opposite is true. So weakening Wikipedia's defences in this area would seem most unwise if the Project is to continue a knowledge-based mission. Bon courage (talk) 01:02, 18 October 2024 (UTC)
No and No Those thinking the anti-fringe group sometimes overdo it might be right, but downgrading FRINGE would give much worse results. Woo nonsense attracts a lot of followers and they can swamp a topic. Ensuring that articles reflect reality is necessary for an encyclopedia based on reliable sources. Johnuniq (talk) 01:05, 18 October 2024 (UTC)
Yes 1; Yes 2C else 2A. From our previous discussion, it took me a while before I came to this point. But I feel like WP:FTN see WP:FRINGE as a hammer and everything around them as a nail. The other noticeboards (RSN etc) handle fringe topics and fringe editors fairly regularly without a problem (and usually without bringing up any FRINGE guideline), and per the preamble the FRINGE guideline is already a patchwork of cross-references from existing guidelines. FTN moving to a WikiProject will likely change very little, which is a major part of the point -- the noticeboard does not really function like other P&G noticeboards. And back-merging FRINGE will change no policy too, which is also pretty much the point. SamuelRiv (talk) 01:13, 18 October 2024 (UTC)
Yes/No: There's IMO no serious problems with WP:FRINGE, though I'd like some expansion of WP:FRINGE/QS and WP:FRINGE/ALT, and generally more clarification when something is not fringe. However, I feel like FTN behaves in a way that pushes a very particular hyperskeptic POV over the sources when they contradict, and that it often overfocuses on pseudoscience and woo to the point that it usually misses even obviously supernatural claims outside those domains. For this reason, I'd like it to be merged into WP:NPOVN, which currently is pretty slow and which behaves much more normally in these situations. Loki (talk) 01:59, 18 October 2024 (UTC)
No and No. FTN is and has been a valuable platform for discussing how fringe topics and POVs should, and should not, be presented in Wikipedia articles. If enacted, these proposals would considerably weaken the project by making it easier for fringe-POV pushers to populate WP articles with all sorts of unreliably-sourced, non-encyclopedic nonsense. JoJo Anthrax (talk) 02:22, 18 October 2024 (UTC)
Reject both (Linked from NPOVN) This idea seems pretty out there. With all due respect and good faith, why is this even an RfC? Seems like an obvious waste of time to suggest we remove one of the most important safe-guards Wikipedia offers, one that sets it apart from any other platform. I have also noticed increases in the amount of new users and editors doing what some may consider POV pushing (of Fringe) over the last year. Maybe due to the elections in the US, but it is noticeable. DN (talk) 02:34, 18 October 2024 (UTC)
Total rejection of both: One of the most ridiculous and even outright insulting proposals I've ever seen on this site and that's saying something. A complete and total waste of time for everyone verging on the point of violation of Wikipedia:Disruptive editing. Wikipedia is under constant, relentless attack by fringe proponents and any attempt at weakening our safeguards instead of further strengthening them should be considered extremely suspicious. If you've ever been physically threatened or witnessed attempted outing on this site by fringe groups, you'll know how outrageous this proposal is. These groups range from confused and well-meaning to organized and outright dangerous. They are not something to fetishize or give an inch. We are extremely lucky to have the editors that we do who are willing to deal with fringe topics. I personally think it is time for us to start pushing back on the lack of support or appreciation Wikipedia shows for this small group of specialized editors who do so much for the project. :bloodofox: (talk) 02:36, 18 October 2024 (UTC)
The way I see it, Wikipedia keeps becoming a bigger target for special interests, and if it's going to survive into the next decade it needs to be much less open to bad actors. Ask any admin. The firehose of misinformation and stoking of bad behavior is beyond overwhelming by design, and it's only going to get much worse unless those in charge do something about it. On a lighter note, if the project wasn't working then they wouldn't even bother with us. Cheers to success. DN (talk) 04:52, 18 October 2024 (UTC)
No and No: It seems fringe theories requires folks well-versed in combatting fringe theory proponents and how to deal with them. It's not a huge lift to make a separate space for fringe theory discussion, or to have the fringe theory guidelines. I see no good reason to get rid of either. Bluethricecreamman (talk) 02:47, 18 October 2024 (UTC)
Absolutely not. WP:FRINGE is a subset of WP:NPOV that helps ensure our articles on conspiracy theories, woo science, and religion remain empirical and evidence-based. These folks do great work keeping our encyclopedia free of junk. There's absolutely no way the encyclopedia would be better off without this work. comes across as WP:CANVAS. The correct way to deal with someone notifying a noticeboard that has a POV you disagree with is to do your own notifications, such as to notify a WikiProject talk page. Notifying noticeboards, article talk pages, and WikiProject talk pages is (in my opinion) never canvassing. This kind of looks like a case of an editor trying to change the entire system, instead of learning how the system works and the good reasons why it works that way. –Novem Linguae (talk) 03:06, 18 October 2024 (UTC)
No and No. The guideline and the noticeboard are extremely important in helping maintain neutrality and high quality referencing in topic areas that are susceptible to POV pushing. I oppose any effort to carve out a toehold that legitimizes crank theories. Cullen328 (talk) 03:58, 18 October 2024 (UTC)
Yes/2C - effectively merging FTN with other existing noticeboards like NPOVN and RSN will have the double benefit of putting more eyes on fringe issues and also breaking up the hyperskeptic cabal issues mentioned by other supporters above. Merging the guideline will have the benefit of fewer policies/guidelines. WP:FRINGE and WP:FTN are duplicative of NPOV/NPOVN. (I'd also support merging NORN for the same reasons.) Levivich (talk) 04:02, 18 October 2024 (UTC)
My experience is that when fringe topics end up at WP:NPOV it just leads to confusion from editors with little experience in the topic, sometimes even leading to confused editors siding with the fringe proponents, wasting volunteer time all around. These aren't just NPOV concerns but often intentionally obfuscating, often organized attempts at gaming the site. We need a specialized board for these specialized matters that includes editors who are willing to do the research and the work necessary to keep the site from becoming just another fringe platform. :bloodofox: (talk) 04:47, 18 October 2024 (UTC)
Great, so now we can look at this claim. There's not a lot of fringe stuff on the NPOVN front page, but there are several on the most recent archive (113), from late August to late September. It seems like 'Myers-Briggs' and 'Muslim gangs' were resolved pretty well at NPOVN, while I'm not sure if 'WPATH' ever got resolved in its article. Would you have something to compare from FTN discussion resolutions? SamuelRiv (talk) 05:04, 18 October 2024 (UTC)
Sorry, I'm not playing this game. There is no question that we need specialized support for the unique needs that come with editing fringe topics and your apparent goal of removing what little support we have for this on the site raises a parade of red flags. :bloodofox: (talk) 05:14, 18 October 2024 (UTC)
No to both. I do understand and respect the canvassing/'cabal' concerns, and FTN is very useful to me for finding and rehabilitating articles of fringe topics that need improvement. We definitely want more eyes on the FTN, but just merging the boards would just make things more difficult for everyone. Feoffer (talk) 05:09, 18 October 2024 (UTC)
Yes, No. WP:FRINGE as guideline is fine, FTN should be merged with NPOVN. In practice, FTN is WikiProject Skepticism- it doesn't really function like a notice board. In theory it could be something else, but it is not. This lends itself to a type of editing that while occasionally good constantly causes problems with some topics. In my experience, I often have thoughts on the topics raised at that board, but it's difficult and hostile to contribute to as it is far more insular and WikiProject-esque than any other noticeboard, even when I largely agree with what they're saying. As someone with an interest in "fringe topics", even when it would be extremely helpful to get other eyes on a topic from people who aren't pushing fringe (what a "fringe noticeboard" should hopefully be good for) I don't even bother due to how exhausting it seems to have to deal with the very specific hyperskeptic pov some people there push. PARAKANYAA (talk) 06:01, 18 October 2024 (UTC)
No no. I just wasted two hours on reading a thread that only exists because an article contained something amounting to "he's really not dead, Jim! Although a study said he is." Someone deleted it, which was an improvement, someone reverted that deletion. And now the reverter is butthurt and says the deleter is a bigot, and the idea came up of nuking the place where those two clash sometimes, and someone else started this farce just for the fun of it although everybody including the reverter said it will not fly, but everybody needs to read the thread. And it did not fly. Yeah, let's make a study to find out whether a dead person is dead, and let's start a survey to find out whether a waste of time is a waste of time. --Hob Gadling (talk) 07:29, 18 October 2024 (UTC)
There was a study showing that people alleged to be in a state of Tukdam were in fact dead. The line adding this study got reverted, which I would normally associate with WP:PROFRINGE since it's removing evidence against a supernatural claim, but in fact was from an FTN regular who apparently objected to even the idea that one might be able to study this.
This is what I mean when I say FTN is both overactive and underactive: in its pursuit of a hyperskeptical POV it's actually caused its participants to make WP:PROFRINGE edits in this case. Loki (talk) 20:59, 18 October 2024 (UTC)
No, no. I'm not an involved editor but I have read this and the previous discussions with interest. I conclude that the FTN regulars deserve all the thanks and Wikilove we can send their way. MichaelMaggs (talk) 09:03, 18 October 2024 (UTC)
yes, no: per PARAKANYAA primarily, although i sympathize with those who disagree with the premise of this RfC in the first place. ... sawyer * he/they * talk09:20, 18 October 2024 (UTC)
addendum: i think the comments here and elsewhere characterizing those critical of FTN as fringe POV-pushers kind of proves the point ... sawyer * he/they * talk10:16, 18 October 2024 (UTC)
I’m surprised to learn I’m just butthurt and a POV FRINGE-pusher. It’s amazing how far the game of telephone has gone considering how easy it is to scroll up and see the actual points raised. Warrenᚋᚐᚊᚔ18:01, 18 October 2024 (UTC)
No and No. WP:FTN has functioned as a successful and essential forum for applying WP:CONSENSUS in order to prevent Wikipedia from becoming yet another online source of misinformation and disinformation. Of course, POV-pushers of pseudoscience and conspiracy theories don't like it. NightHeron (talk) 10:09, 18 October 2024 (UTC)
Maybe and No. Largely per PARAKANYAA. There are problems at FTN, and some editors there confuse anti-FRINGE with NPOV when they are not the same (the former is just as much a POV as pro-FRINGE) and with seeing bad-faith and/or pseudoscience when it isn't there (it's not pseudoscience if it doesn't claim to be scientific; there is a difference between "proven wrong", "unproven" and "unstudied"). These problems are largely behavioural rather than structural, but perhaps the structure is enabling the behavioural problems? I think a better first approach would be a detailed, structured, independent review of the behaviour at FTN (perhaps by arbcom). There is far too much wailing and gnashing of teeth that Wikipedia will be overrun by pseudoscience and "woo" if we even consider that something about how we currently deal with the topic area might not be 100% perfect, and that needs to stop - as does the automatic assumption that anyone who isn't actively against saying anything remotely positive about something that is even arguably FRINGE is a pov-pushing and trying to defend or include pseudoscience or conspiracy theories. Remember the N in NPOV means neutral not anti. Thryduulf (talk) 10:18, 18 October 2024 (UTC)
I think FTN is incredibly useful and want to keep it, but it definitely needs more eyeballs and review. There's truth in the basic realization that anti-FRINGE is an important facet of NPOV, but NPOV isn't synonymous with anti-FRINGE. Feoffer (talk) 12:49, 18 October 2024 (UTC)
Yes, yes The Guerrilla Skeptics are explicitly organised as an off-site cabal to push their POV on Wikipedia. They have a point but are so dogmatic in their pursuit of it that they come across as a fringe religion themselves. They seem to have a specific agenda as they constantly go after particular soft targets rather than being skeptical about the large amounts of other BS that's out there. The obsessive labelling of topics as fringe and pseudoscience is itself pseudoscientific and is so preachy and proselytising that it is counter-productive. The fringe noticeboard is clearly used to canvass by this cabal and so should be shut down. Andrew🐉(talk) 10:28, 18 October 2024 (UTC)
1) there was an arbcom case about gorilla skeptics a few years ago, and they were pretty much acquitted of all wrongdoing. 2) it became clear during the arbcom case that gorilla skeptics organizes off-site, and does not really use ftn or a wiki project, 3) I remember not recognizing most of the publicly identified gorilla skeptic members, whereas I recognize most of the ftn regulars –Novem Linguae (talk) 17:07, 18 October 2024 (UTC)
No. I don't believe there is sufficient evidence to establish even a prima facie case that there have been conduct issues involving multiple users, much less that it is systemic, around FTN as a nexus, or that removal of the board would make a meaningful improvement. I would suggest that if this is proposed again for the same reason, a review in line with what Thryduulf proposes be conducted beforehand. Such a review could also submit evidence in the interim to boards such as AN. I doubt Arbcom would chose to take it up at this point, as community resolution methods have not been exhausted, but if they eventually do, they could simply implement as a remedy what resolutions they see fit, making the community proposal redundant. I would not be opposed to revisiting this proposal should a community review find both the requisite evidence and a need for action without ending up involving Arbcom. Alpha3031 (t • c) 11:28, 18 October 2024 (UTC)
Meh; no. I don't have strong feelings either way about FTN, though it looks to me that the issue that prompted this is really the alleged misbehaviour of a relatively small number of individual editors rather than FTN as a whole being irrepairably flawed. Even if there is a systemic issue with FTN, I'm not seeing from reading this proposal or the above discussion any sort of argument for getting rid of or downgrading WP:FRINGE. Indeed, the people arguing for that outcome are specifically saying that it won't change policy, so... why bother? Caeciliusinhorto-public (talk) 11:54, 18 October 2024 (UTC)
No and NoWP:FRINGE is an extension of WP:UNDUE and WP:NPOV and its status as a policy does a lot if heavy lifting to help prevent fringe POV pushers from spreading junk science, misinformation and fraudulent research. And, most importantly, it helps editors in general to understand the purpose of an encyclopedia. WP:FTN does a lot of the hard work to enforce this and the idea of disbanding it is absurd. If there are instances when FTN is used in a questionable way (I don't think there are many, if at all), then people should let those editors know what they are doing wrong, not disband a place where a LOT of important work is done. (Oh, and anyone who brings up GSoW in this discussion has no idea what they're talking about, are getting their information from cranks and frauds, and deserves to be WP:TROUTed.) VdSV9•♫12:05, 18 October 2024 (UTC)
My point, in short, is this: very few of the active editors in FTN are part of GSoW. The Arbcom case has nothing to do with what people do at FTN. VdSV9•♫13:54, 18 October 2024 (UTC)
No/No while the board occasional gets it wrong from because of hyper hatred of anything fringe, resulting in normal dispassionate treatment of some subjects being considered too friendly because they aren't hostile enough, abolishing the noticeboard or downgrading the policies/guidelines/whatever will cause much more frequent problems that are much worse. Headbomb {t · c · p · b}12:08, 18 October 2024 (UTC)
Nonsense and Nonsense: WP:FRINGE needs more support, not less. Its basis is in our fundamental policies and, indeed, should really be added to WP:NOT. ("Wikipedia is not a vehicle for promoting the theories of lunatic charlatans", perhaps...) SerialNumber5412912:14, 18 October 2024 (UTC)
One issue is that some editors at FTN have trouble distinguishing those trying to achieve NPOV from those promoting a pro-FRINGE POV, labelling them all as lunatic charlatans, which doesn't help anybody. Thryduulf (talk) 12:43, 18 October 2024 (UTC)
That comment demonstrates you've completely missed the point. The failure to distinguish between NPOV and pro-FRINGE POV actively harms the encyclopaedia, and hinders the cause of NPOV and those seeking it while doing absolutely nothing to the goal of those pushing conspiracy theories that restricting the aspersions to them would not. Ideally there would be no name-calling or aspersion-casting at all, but one step at a time. Thryduulf (talk) 17:54, 18 October 2024 (UTC)
No and No. As others have said in other ways, WP:FTN has been successful to the point where there is a lot of questioning around if it is needed are not. It continues to act as a bulwark against a significant number of groups trying to get their unproven/random musings in what should be a encyclopedic work. There is enough volume that having its own separate policy and noticeboard continues to be needed. spryde | talk12:30, 18 October 2024 (UTC)
No and No. While I am cognizant of the concern expressed by Andrew Davidson of off-site organization intending to push a POV, getting rid of a particular noticeboard does nothing to prevent things from happening off-site, the activities of which will likely then just move to other Wikipedia noticeboards. The discussion that we are having here is likely sufficient to bring additional attention to WP:FRINGE, so that a broader slice of the community is involved in its discussions. BD2412T12:57, 18 October 2024 (UTC)
No/No In agreement with the above, where it appears there's more a problem that is beyond FRINGE, which is how we label those that are promoting fringe theories, which falls under NPOV and BLP concerns. As long as fringe concepts have been readily disproven by reliable sources, there's zero harm in making sure they are labeled as such, but it is a problem to further that labeling onto those that promote them without significantly strong backing to get around the POV issue. Other issues like offsite canvassing are those that are not a specific issue to FTN but misuse of WP in general, and have other remedies available to handle than to shut down a key noticeboard. --Masem (t) 13:18, 18 October 2024 (UTC)
No and No. Per WP:PROJGUIDE, A WikiProject is a group of editors interested in collaborating on a specific topic within Wikipedia. A WikiProject is a group of people, not a set of pages, a subject area, a list of tasks, or a category. I think the same applies to a noticeboard; functionally noticeboards and WikiProject talk pages often differ only in name. Shutting down an active noticeboard is therefore primarily a question of taking administrative action against those editors, to stop them from collaborating. That sort of action should be reserved for WP:ARBCOM. Deleting the pages and moving the functions elsewhere does not seem like it would achieve anything meaningful. WP:FRINGE is a logical extension of core policies and demoting it would be taken as an invitation to promote theories that do not align with NPOV or V.--Trystan (talk) 13:55, 18 October 2024 (UTC)
No and no. Wikipedia is a bright spot on the Interent at least in part because we really do try to comprehensively get things right, even if we often fail. Part of "getting things right" is keeping out material that is well outside what is mainstream, as represented by reliable sources. I see some comments that FTN, or some participants at FTN, are hyper-skeptical. My impression is that charge is coming in part from the failure of FTN to be sufficiently differential to extraordinary claims made by some groups. - Donald Albury15:40, 18 October 2024 (UTC)
No and No. Disbanding the noticeboard would have no effect other than to move discussion elsewhere, so why bother. Anyone can view or comment on the noticeboard so how would having the same discussions elsewhere make any difference. As to the idea of disbanding or downgrading FRINGE it is patently ridiculous. If editors have issues with other editors they should take it to ANI or ARBCom, rather than tilting at windmills. -- LCU ActivelyDisinterested«@» °∆t°16:32, 18 October 2024 (UTC)
Yes and No. I don't think our policies and guidelines are what's in need of revision right now. The matter of concern is, to borrow Loki's words a pattern of behavior enabled by the structure in which a 'hyperskeptical' POV is pushed over and against sources and often using bigoted reasoning. When academically trained and university-associated scholars get treated by FTN participants as uncitable 'woo' again and again, , with no regard for the training of the authors or even the content of their findings, the attempt to achieve NPOV is inhibited, not helped. Hydrangeans (she/her | talk | edits) 17:37, 18 October 2024 (UTC)
@Headbomb Yes, if the discipline is itself fringe, but scholarship is not made unreliable in and of itself by the scholar being a member of a particular religion, which is something people at FTN often argue. PARAKANYAA (talk) 18:13, 18 October 2024 (UTC)
If Bob believes that magical dwarves live at the center of Jupiter, and goes "Trust me, I'm an astrophysicist, I wrote papers on the topic, I'm the foremost expert on this, magical dwarves do live at the center of Jupiter", Bob is a nutjob and their paper support Jovian magical dwarves is equally vapid and devoid of validity. Headbomb {t · c · p · b}18:19, 18 October 2024 (UTC)
If the claim in question is clearly out of step with other literature, of course. But that is not what the issue is. Someone being a member of a particular religion does not make their scholarship inherently fringe. PARAKANYAA (talk) 18:25, 18 October 2024 (UTC)
(edit conflict) What Bob does or does not believe has absolutely no relevance to whether their paper supporting Jovian magical dwarves is valid. Whether the paper is or not valid depends entirely on how reliable sources rate the content of the paper, particularly the methodology and whether the conclusions match the evidence. Thryduulf (talk) 18:29, 18 October 2024 (UTC)
If Bob is a member of the Church of Jove and manages to publish an article in the Journal of Vaguely Related Engineering about the striking evidence for the existence of magical dwarves, there is at least an itty bitty amount relevance that his membership in the church could serve as a WP:REDFLAG. Agreed that one might come to this conclusion anyway through source evaluation, and I absolutely accept that church membership is in princinple compatible with WP:MAINSTREAM scholarship. But there are enough examples I have seen of poor scholarship following that model that I think a complete taboo of such a heuristic is just as problematic as someone who outright dismisses a source based on the religious affiliation of the author. jps (talk) 18:55, 18 October 2024 (UTC)
...but what if Bob, a member of the Church of Jove, is a respected expert who publishes research suggesting that magical dwarves do not exist? Because that's the actual analogy for the situation you're talking about. Loki (talk) 20:49, 18 October 2024 (UTC)
Not quite. I know that is the argument that was leveled, but this isn't the full story. There was, in fact, only a claim that one means of trying to measure some phenomenon came up with a predictable null result. jps (talk) 23:48, 18 October 2024 (UTC)
Bob's membership of the church would still not be relevant. We judge how extraordinary claims are by how much they differ from the prevailing consensus of opinion in reliable sources, not by who makes them. We judge whether the claims are supported by sufficiently strong evidence based on how reliable sources report on them. If claims are noteworthy but have not been assessed in reliable sources then the article must express no opinion on their veracity in Wikipedia's voice (if the claims are not noteworthy we don't mention them at all). Thryduulf (talk) 20:51, 18 October 2024 (UTC)
We judge how extraordinary claims are by how much they differ from the prevailing consensus of opinion in reliable sources, not by who makes them. This isn't strictly true. I can think of many instances where we do not use sources precisely because of who is making the claim even if the claim being made is in-line with prevailing understanding. And I'm not even arguing for this kind of strict excising. I'm just saying that we can use the identity of an author as a datapoint when evaluating the source. jps (talk) 23:51, 18 October 2024 (UTC)
Yes and No. I didn't expect to end up !voting in this way - I was really surprised to see the headline of the RfC notice, and immediately thought "are you kidding me?!" But having read through these discussions and thought about it for a little while, I do agree that it would be best to merge this together into the npov board. The arguments in favour of ending the noticeboard articulate something I had observed for some time but not really thought through myself. I disagree that this would have no effect except to move the discussion elsewhere. (If the discussion is moved to npov and the fringe regulars immediately overpower the npov regulars such that there really is no effect on the fringe discussions, well, that's not really an outcome that looks good on the fringe regulars trying to argue that they're not part of a hyperskeptic bloc.) -- asilvering (talk) 18:49, 18 October 2024 (UTC)
Neutral and No I have often found the fringe theories noticeboard to be helpful when dealing with fringe topics and ideas, but I agree that the purpose of the board heavily overlaps with NPOVN, and there is a evident lack of interest/activity at NPOVN (I have had several posts on NPOVN that I thought were significant issues not generate any real noticeable reponse), and perhaps merging FTN with NPOVN could sort this issue. The fringe guideline is itself good though and I see no real good reason to remove it. Hemiauchenia (talk) 19:10, 18 October 2024 (UTC)
No and no. I see a lot of vague claims of FTN being abused by individual editors acting as an organized hyperskeptic bloc, biased FTN editors holding a hatred of anything fringe, fringe subjects being unfairly treated with hostility, etc. We would need evidence in the form of diffs to evaluate the need for actions suggested by the survey. - LuckyLouie (talk) 20:12, 18 October 2024 (UTC)
No and Maybe 2A. Thryduulf pretty much covers it. The problem isnt FTN or FRINGE. Most of the editors there do good work and are a net positive for Wikipedia. The problem is that a handful of editors that hang out there also routinely ignore NPOV and CIVIL and, because they otherwise do good work, the system gives them a pass. Bonewah (talk) 20:40, 18 October 2024 (UTC)
Yes and No I clearly think FTN has issues, and I think the sheer volume of WP:PROFRINGE accusations being thrown out here and above, in the absence of any PROFRINGE actions or statements from any user should show that there’s a problem. This has gone way beyond civil in places and an inability to actually have a nuanced discussion around FTN is a symptom of the wider problem.Warrenᚋᚐᚊᚔ21:43, 18 October 2024 (UTC)
'Sorta/no’. I've long thought that the lower traffic content noticeboards, FTN, NPOVN, and NOORN would be more effective merged into a single noticeboard. Fringe is part of NPOV already, and combining the eyes from those noticeboards would address concerns about canvassing to a particular group and draw attention to discussions that generally have too few participants. ScottishFinnishRadish (talk) 23:37, 18 October 2024 (UTC)
No and No. This seems a drastic measure when no fringe policy and noticeboard serve a useful purpose and have been relied upon. Other available options include suggesting specific changes or clarifications to WP:NOFRINGE and editors productively trying to engage content experts in religious topics that have garnered the attention of FTN.MYCETEAE 🍄🟫— talk01:52, 19 October 2024 (UTC)
No and No. Neither the noticeboard nor the guideline are broken. Both are necessary. Scattering the discussions from FTN across other boards would just invite forum-shopping and general confusion. If there's a conduct problem with one or more editors, take them to ANI or ArbCom. XOR'easter (talk) 03:40, 19 October 2024 (UTC)
I just want to note regarding some of the comments about FTN being an important safeguard, some of the last bit of our discussion above was about precisely this point. Does FTN really mitigate against fringe edits and editors? Does having a separate FRINGE guideline page mitigate similarly? Is there evidence of this in our experience? SamuelRiv (talk) 02:40, 18 October 2024 (UTC)
Maybe that's the sort of question to be asking before launching a waste-of-time RfC? There was no traction for your odd ideas and you were advised they were pointless. But here we are. Bon courage (talk) 02:45, 18 October 2024 (UTC)
And nobody at all agreed with your idea to ditch the FRINGE guideline (you were told it would be a waste of time to ask). You also seemed not to understand basic things about how noticeboards work, saying for example they should not be used for content issues. This RfC just looks like a pointless way to preside over process and stoke up drama, rather than build an encyclopedia. Bon courage (talk) 03:44, 18 October 2024 (UTC)
Per my post history for that entire discussion, including the very last posts where I state my reasons for starting the RfC, I strongly ask that you strike this comment. I really should not have to take this. SamuelRiv (talk) 04:17, 18 October 2024 (UTC)
Assessing, dealing with, and reporting on fringe groups require specialized editors with expertise in their topic areas. Fringe-specific boards allow for the cultivation of such editors. Additionally, fringe groups very frequently organize and brigade the site, requiring a counter-response from Wikipedia editors, for which our fringe boards and fringe guidelines allow. Given the repeated attempts at systemic gaming of the site we've seen from extremely well-funded and well-organized fringe groups, especially new religious movements, Wikipedia needs far, far, more fringe-specialized editors and it is quite frustrating to see attempts at reducing what little safeguards we have. To put it frankly, we are very lucky to have the few editors we do willing to put up with the abuse, harassment, and outright death threats that come with editing in what is by far the most stressful and outright dangerous part of Wikipedia. :bloodofox: (talk) 02:47, 18 October 2024 (UTC)
Point: I think this association is double-edged. This stuff isn't usually the most stimulating to think about—never mind to have to fight with bad- and gray-faith strangers about else we allow the wiki to get blatantly worse before our very eyes. Not speaking about anyone or anything in particular, I'm serious, but in the broadest possible terms—I think in certain moments that dynamic can lead to a negative connotation for editors that do put up with it, something like "they like to fight" or "they're always talking about wiki detritus". Sometimes, the exhaustion shows on my conduct, and I'm not a member of this class even. Remsense ‥ 论02:52, 18 October 2024 (UTC)
No. It's time to start showing appreciation for these volunteers—they are by far putting up with the worst that the project offers and if even a single one of them sticks around, they need spines of steel. Editors who deal with the unecessary bullshit that comes with editing fringe topics need better support. It's obviously not coming from the WMF but it needs to come from somewhere. Debating removing what little support we have for them is unacceptable. :bloodofox: (talk) 02:56, 18 October 2024 (UTC)
I am not disagreeing with you, I'm just elaborating on some of the possible reasons I think the dynamic takes the shape that it does. Reflection is worthwhile. Remsense ‥ 论02:58, 18 October 2024 (UTC)
The entire impetus for the discussion above was the problem of FTN having non-specialist editors claiming authority on specialist science topics, in several FTN threads on the current board page. Is there a specialist in fringe theories that would be better equipped than experienced editors at RSN, NPOVN, etc? When it comes to WP, what additional skills would they have? If it's dealing with problematic fringe editors, then my challenge again is to look at the results (which we do in the prior discussion). SamuelRiv (talk) 03:44, 18 October 2024 (UTC)
(ec) : Is there evidence of this in our experience? In my experience, yes. In yours? Well, with all due respect, perhaps you should have reviewed the current FTN topics and, of course, the FTN archives, sufficiently to answer those questions yourself prior to initiating this RfC. JoJo Anthrax (talk) 02:57, 18 October 2024 (UTC)
I'd rather we run the RfC for at least a day so we can see the opinion of the broader Wikipedia community who are not FTN regulars. I agree that if the writing is on the wall then there's no reason to drag it out any longer than few days rather than a week or a month Hemiauchenia (talk) 04:00, 18 October 2024 (UTC)
"Does FTN really mitigate against fringe edits and editors?" Yes. I would also note that from my personal experience in the realm of rhetoric, the phrase “is it really?” is often employed in the dissemination of Fringe as a persuasive device.
Does having a separate FRINGE guideline page mitigate similarly? As a matter of personal opinion, yes.
Is there evidence of this in our experience? Yes, and while examples may be given, it's important to frame the terms of what is considered acceptable evidence. DN (talk) 03:12, 18 October 2024 (UTC)
The question is clearly placed in direct reference to the discussion at the top of VPP, this page, linked at the top and bottom of the RfC. ("some of the last bit of our discussion above...") The question is asked and analyzed in detail in that discussion. I am not trying to persuade anyone by asking a question. But I do expect people who respond to an RfC to at least take a moment to glance at the preceding discussion when the RfC says that it is the culmination of that discussion. SamuelRiv (talk) 04:14, 18 October 2024 (UTC)
I do expect people who respond to an RfC to at least take a moment to glance at the preceding discussion There is absolutely no evidence whatsoever that the people who have responded to this RfC have failed to do that. That comment is a borderline, if not actual, violation of WP:AGF. JoJo Anthrax (talk) 04:18, 18 October 2024 (UTC)
I can understand how someone may see my reply as somewhat pointy, but for the record I don't take offense. I would guess they may be frustrated at the results they are getting and trying to make sense of why some editors are not reacting as positively as they might have hoped. DN (talk) 04:28, 18 October 2024 (UTC)
Strike that. I made clear above before starting the RfC the extent of my expectations. Responses I have gotten here have been borderline, tangential, or directly insulting to my character as a person and an editor. I'm becoming short because nobody, not an IP, not me, deserves that shit. SamuelRiv (talk) 04:40, 18 October 2024 (UTC)
If you didn't want pushback, you might have tried showing the slightest ounce of concern or respect for the handful of editors who actually deal with the threats, attempts at outing, and harassment that come with editing in fringe spaces. It gets so bad in these areas that it's amazing no one has been hurt yet: I know I have personally been repeatedly threatened and you can easily find attempts at outing me and I am just one editor. Without question, the small group of volunteers who gather at the fringe noticeboard and apply Wikipedia's fringe policies are the only thing keeping the website from being overrun from unrelenting, well-funded, and organized attempts at converting it into a fringe platform. :bloodofox: (talk) 04:52, 18 October 2024 (UTC)
I think personal dangers experienced by editors, however important, are not relevant to this particular discussion (and oddly the one credible RL threat I've had on Wikipedia has been as a result of editing a NRM topic). What is concerning is the aspersions and othering in these VPP discussions, with "FTN" being used collective noun and proxy for casting aspersions. Warrenmck's continued use of this tactic is particularly shabby, but they are not alone. Bon courage (talk) 04:59, 18 October 2024 (UTC)
I think it is relevant because it is apparently something we have to put up with as fringe topics editors and nobody seems to be discussing the real world danger. Without going into too much detail, I dealt with a group of editors who attempted to stalk and potentially harm me, hunting down some poor individual (who wasn't even me) at his workplace, among a few other instances. Editing non-fringe topics isn't likely to trigger this kind of thing — this is one of the reasons I think we need unique support systems and forums for editing on fringe topics. After nearly 20 years of this, I have no shortage of horror stories. :bloodofox: (talk) 05:09, 18 October 2024 (UTC)
I sympathise, but surely you can see that if we extend special treatment to editors because of things that heppen (or which they say happen) in RL then ... that way madness lies. I can think of non-fringe topics that are also fraught if one's real life identity is known (abortion, organized crime, espionage ...) Bon courage (talk) 05:14, 18 October 2024 (UTC)
Well, some type of support system needs to exist, or at least a true zero-tolerance policy, but I don't see that happening as long as the site remains little more than a cash cow for the Wikimedia Foundation. In any case, it was foolish of me to edit in these spaces to begin with, I initially followed the breadcrumbs from hijacked folklore-related articles, and these kind of discussions just make it more obvious to me that I should much more narrowly focus what little time I have for Wikipedia these days on non-fringe matters. :bloodofox: (talk) 05:27, 18 October 2024 (UTC)
I’m actually not okay with you continually referring to my real concerns as a “tactic”, you’ve done nothing but assume an underlying agenda or crusade on my part here and your inability to actually even acknowledge that the concerns and criticisms raised may be legitimate and being raised in good faith is pretty much exactly one of the problems I see with FTN. I wasn’t even engaging yo, here. If you can’t assume good faith, then that’s not on me. Warrenᚋᚐᚊᚔ13:21, 18 October 2024 (UTC)
Looking at the discussion/catalyst for the RfC, it did not look like there was a consensus for it, but you seemed to take it upon yourself to do it anyway. Are the reactions all that surprising? DN (talk) 05:29, 18 October 2024 (UTC)
I did not go in depth, but I would say I looked it over. I give you points for courage and assume you are acting in good faith. I had no involvement there so my opinions on the legitimacy of this endeavor are strictly based on face-value. Best of luck. Cheers. DN (talk) 04:23, 18 October 2024 (UTC)
It's certainly true there are problem editors in this space, just not in the way some editors seem to think. If you're unaware of how Wikipedia noticeboards work, or how FRINGE is generally handled on Wikipedia, you might get the idea from these VPP discussions there was some kind of problem with WP:FRINGE, rather than a quixotic campaign from one or two editors with bees in their bonnets. Bon courage (talk) 04:42, 18 October 2024 (UTC)
rather than a quixotic campaign from one or two editors with bees in their bonnets
and yet other editors see a problem, and when they point this out you’ve disagreed that they see the same problem as I do over their objections. You need to knock off the aspersions yesterday. Warrenᚋᚐᚊᚔ13:25, 18 October 2024 (UTC)
I don't believe it's "bad faith". I just think you're very wrong and disagree with the substance and manner of what you are doing. Bon courage (talk) 13:44, 18 October 2024 (UTC)
I don’t see how not editing the article when what I was proposing was a contentious move is an issue. Editing an article isn’t the only way to work on an article. Talk and noticeboard discussions prior to sweeping changes are perfectly reasonable, and the only way to disagree that “Panspermia” is still used widely to refer to what Wikipedia calls Paeudo-panspermia is WP:IDIDNTHEARTHAT, not any kind of reasoned position, because it’s clearly true. Warrenᚋᚐᚊᚔ13:28, 18 October 2024 (UTC)
Your dogmatic position was "It’s absolutely erroneous to say “panspermia is a fringe theory”. It took a lot of discussion to get you to recognize this was wrong. Bon courage (talk) 13:35, 18 October 2024 (UTC)
It’s not wrong, and the “convincing” was people saying “it’s wrong” and providing no comment whatsoever on the evidence provided. For anyone reading a long, my argument was not that the fringe theory panspermia is anything other than a fringe theory, just that the same term is used in the literature for the one that isn’t a fringe theory, which is demonstrably true. Warrenᚋᚐᚊᚔ13:38, 18 October 2024 (UTC)
You were shown a load of journal sources and had to concede it's not "absolutely erroneous" to say panspermia is a fringe theory but that both terms are used, seemingly with panspermia being the most common term for the fringe theory. Bon courage (talk) 14:11, 18 October 2024 (UTC)
both terms are used
this was the claim.If both terms are used in the literature to refer to the non-front theory then “panspermia is a fringe theory” is misleading, rather a specific fringe as hell theory which is also referred to as “panspermia” is distinct from the “panspermia” used by scientists, which is why my proposal was “Panspermia (astrobiology)” and “Panspermia (fringe theory)”, not making some case that the fringe theory isn’t a fringe theory. Warrenᚋᚐᚊᚔ14:33, 18 October 2024 (UTC)
Seems pointless to continue, so you can have the WP:LASTWORD if you want. Editors can see what actually transpired if they wish, and see the consensus crystalized in the relevant articles. Per the sources, panspermia is the fringe theory and pseudo-panspermia the non-fringe one. If this turned your prior understanding on its head, that's not a problem with FTN but with published knowledge itself. Bon courage (talk) 14:46, 18 October 2024 (UTC)
Per the sources, panspermia is the fringe theory and pseudo-panspermia the non-fringe one. If this turned your prior understanding on its head, that's not a problem with FTN
I’m a WP:SME in meteorites. There’s a reason I was easily able to provide a huge pile of sources disagreeing with the characterization on Wikipedia, and it’s not because I’m WP:PROFRINGE trying to pick sources to soften the stance on the absurd panspermia fringe theory.
At no level do I expect anyone here to take my SME perspective on this (hello, Essjay controversy), but I do expect self-described skeptics to re-evaluate a previously held stance in the face of evidence, which didn’t happen and that’s one of the issues I see with FTN. FTN is mistaken in their assessment of this and I was able to provide plenty of sources, but that didn’t matter, which strongly informs my perspective of FTN as engaged in WP:POV editing. Warrenᚋᚐᚊᚔ16:04, 18 October 2024 (UTC)
Because, without me even commenting on this vote going on, it keeps getting presented as an unsubstantiated personal crusade on my part rather than any sort of genuine concern and good faith attempt to address that, and the above example is a pretty good one for FTN rejecting sources that counter a specific anti-fringe POV being used to edit even when nobody, at all, is taking a WP:PROFRINGE perspective.
But broadly you’re right, and it’s clear this proposal is going nowhere. I hope that nobody’s taking some of the above characterizations uncritically at face value. I’m going to make a sincere effort to disengage here. Warrenᚋᚐᚊᚔ16:48, 18 October 2024 (UTC)
I've been loosely following the discussion and have reread it, I'm not ready to enter a comment yet but my initial impression is that there isn't a sufficient case for such a drastic action. I'm not really seeing much evidence that this is definitely a systemic issue vs one of a few users, if any. Alpha3031 (t • c) 05:12, 18 October 2024 (UTC)
There is no coherent case. As the OP admitted, this should have been at WP:ANI because it's really a complaint about users. Just not delivered in an up-front way. This ruse is probably the root of this entire mess because some users have become confused into believing it was ever about genuine issues with FTN/FRINGE themselves. Bon courage (talk) 05:23, 18 October 2024 (UTC)
this ruse
You seem incapable of engaging with this thread, from the start, without accusing me of a secret agenda, engaging in ruses, having an axe to grind with specific editors, and engaging in WP:PROFRINGE behaviour. You’re beyond out of line here, Bon, and if you’re not actually going to read the discussion you’re engaging with without passing it through a conspiratorial lens then you need to take a step back and re-evaluate your own approach. You’ve constantly misrepresented arguments, decided it’s acceptable to cast me as some lying pro-fringe editor trying to sidestep normal pathways of dealing with issues, and engaged in strawman after strawman. The reason this entire thread has been derailed away from any discussion about the topic raised is partially because you showed up accusing me of an agenda from the very first reply you made and wildly misrepresented the entire thing from that first post, and you continue to do so.
It's not an aspersion. I'm criticising you specifically for couching what you have admitted is an ANI/user issue in opaque complaints about an entire noticeboard. Predictably, this has caused a big old mess. Bon courage (talk) 13:42, 18 October 2024 (UTC)
I said specific behavior, which is recurring from a large number of users, was the impulse for a policy discussion about something that was leading to those behaviours. As @Hydrangeans agreed, it’s reasonable to want to seek a resolution outside of sanctions. You then extrapolated the discussion to be “that’s what this is exclusively about” and have refused to budge from a position of accusing me of lying about my motivations for the VPP thread repeatedly, ignoring the entire context of the statement you’re repeating like some kind of spell that shows I’m engaging with this whole process nefariously. Warrenᚋᚐᚊᚔ16:14, 18 October 2024 (UTC)
I don't think you're "lying". I think you're wrong on the facts and damagingly oblique and confusing in your approach. Anyway, we shall see from the RfC how convinced the community is. Bon courage (talk) 16:41, 18 October 2024 (UTC)
BTW the discussion you're referencing is difficult to parse in terms of understanding why this RfC is up. Your last comment there was..."Eh, I think it's worth asking just because it's up here, and it closes it out. A RfC can ask two questions. I'll post it in a few minutes."DN (talk) 05:17, 18 October 2024 (UTC)
The most obvious problem with noticeboards is canvassing, where members feel emboldened to skirt civility because there is a group of like minded supporters to dog whistle for help. The noticeboard should be held to higher standards of civility, and have a lower bar for sanctions. Society works this way, positions of public trust (politicians, police, teachers) can get hit hard when they cross a line. The fringe group have a responsibility to behave well, or else; just because the other person has a fringe view is not a reason to act like a jerk. What we need is a noticeboard guideline and set of rules so members understand the issues with noticeboards and best practices. -- GreenC06:14, 18 October 2024 (UTC)
It's practically impossible to WP:CANVAS at noticeboards, as they are so well watched. Calling for assistance is often the point. BLP questions? Ask at BLPN; original research issues? NORN; questions of FRINGE? FTN. Most fringe topics are WP:CTOPS so realistically editors are already on notice to be on best behaviour. Bon courage (talk) 06:21, 18 October 2024 (UTC)
Calling for assistance is often the point, you can call that canvassing, or "assistance", whatever you like. Noticeboards can and often do become a place to "call for assistance" ie. getting like-minded people to help you in a dispute. Anyone who denies that is not being honest. I've done it, I've seen others do it, it's very common. Since we believe we are doing it for a higher cause, and believe we are right, most people won't even recognize it as a problem, rather see it as doing the right thing. It's human nature to collaborate towards a goal, it should not be avoided. But it can be regulated through guidelines. Noticeboards are different from normal random editor involvement in a page. -- GreenC14:09, 18 October 2024 (UTC)
Agreed. Getting more eyes via an appropriate noticeboard is a way to widen and deepen consensus and helps the Project. Sunlight is the greatest disinfectant and all that. Of course editors hate in when they "lose" because of extra transparency over a particular point of contention. Some of them might even bear grudges: some people hate "FTN"; some people hate admins; some people even hate Wikipedia. Bon courage (talk) 14:15, 18 October 2024 (UTC)
The issue is how neutral the notice is, not the notice itself. Otherwise notification of any project (literally a group of editors all interested in the same subject) would be canvassing. -- LCU ActivelyDisinterested«@» °∆t°16:37, 18 October 2024 (UTC)
Above, people accuse FTN of being Wikiproject Skepticism. But I'm more religious studies and anthropology, and I find articles I can improve and expand via FTN. Just merging it into NPOVN would make it harder for me to spot where I can be of use. Isn't there some technical way we can keep FTN separate, but also transclude it on to NPOVN so people there see it? Feoffer (talk) 12:53, 18 October 2024 (UTC)
The whole "merge noticeboards" idea just sounds like a kind of punishment beating fantasy to teach "FTN" a lesson. It wouldn't achieve anything to change the work being done, just make a bigger more unwieldy noticeboard with editors being bothered with more threads they aren't interested in (already a problem when watching most noticeboards). Hell - why not merge all the noticeboards into one? Bon courage (talk) 13:17, 18 October 2024 (UTC)
@Feoffer Well people and sources that are related to "skepticism" (the community/discipline/whathaveyou, not the general concept of skepticism) have been interested in topics that relate to anthropology and religion, so I don't really think that defeats the charge of being more-or-less WikiProject Skepticism. I understand its usefulness - despite almost never contributing, I find it to be an interesting place to find topics I would want to work on/would be able to improve - once it's been a month and the topic has been archived so I don't have to deal with what comes with posting on the noticeboard. The problem is the board shares a very specific hyperskeptic POV that conflicts badly with many topics and is often unnecessarily hostile, which leads to canvassing. When raising an article there the problem is often solved, and several more are introduced. Or at least how that's how I feel from lurking on the board.
I'm well aware that merging into NPOVN won't actually happen despite voting for it, but I considered saying that less waffling then hey, it probably shouldn't be deleted but something has to be done about how this works in practice but I know nothing will ever be donePARAKANYAA (talk) 18:04, 18 October 2024 (UTC)
@ජපස I mean people who take a hardline stance on many of the issues and interests associated with "skepticism", to the point of being hostile/aggressive and accusing people of pushing fringe when they are not, or labeling things as fringe or debunked more aggressively than they are in the actual literature (someone made a very good post about this before but I cannot find it).
Often, people are actually pushing fringe and it's fine but sometimes an issue is not so clear cut and everyone has blown it up out of proportion and then the article is unbalanced. In fairness that is not exclusive to the fringe board. I was not using the word "hyperskeptic" as a conscious neologism, merely referring to people who are well, hyper-skeptical. PARAKANYAA (talk) 18:30, 18 October 2024 (UTC)
What does "accusing people of pushing fringe when they are not" mean? How does one objectively determine that this has happened? I, for one, have always argued that people can be WP:PROFRINGE without necessarily believing the fringe theory being promoted. Devil's advocates exist, for example, and if the actions of an account are functionally equivalent to promoting a fringe theory, I do not shy away from pointing that out. Does that make me a hyperskeptic? If so, where do you draw the line? jps (talk) 18:40, 18 October 2024 (UTC)
@ජපස "Pushing fringe when they are not" means, to me, accusing someone of pushing fringe when the relevant consensus is not actually deeming that belief fringe; being the minority view, for example, is not strictly fringe. Over correction. As to how one can tell I don't know, I'm not pointing out any individual's behavior (or I would have taken it to ANI), more the pattern I have noticed over time looking at the noticeboard. I don't know you or the way you edit, as I have not watched your edits.
Also why would someone promote a theory they themself do not believe in/get material gain from? I don't get what you mean in that sense. PARAKANYAA (talk) 18:46, 18 October 2024 (UTC)
I think the attempt to decide whether a belief is "strictly fringe" or not is perhaps taking Wikipedianisms too far. Surely there is a spectrum of consensus understanding and there is also a contextual basis for an argument. Trying to decide that an idea is being called fringe when it isn't strikes me as an endeavor that is just not well-posed.
The reason people do it can be for a lot of reasons, but out of a sort of sense of justice or support for the underdog, I have seen people make arguments here that Wikipedia has been overly mean to this-or-that fringe group. What sticks most in my head were some now long-gone admins who policed the biographies of climate change deniers some 15 years ago or so. jps (talk) 19:00, 18 October 2024 (UTC)
Yes, there is a spectrum of consensus, so it doesn't have to be 100% declared that as long as it is generally accepted to be, but the problem I find is that the board sometimes overreacts and declares things much more fringe than they actually are, out of proportion. If it is in proportion it is fine.
The trouble I have with this kind of complaint about "out of proportion" reactions is that it requires judging what exactly that "proportion" should be. That's where WP:CIVIL and WP:NPA come into play, but this seems a more behavioral/cultural matter that is unrelated to the existence of a noticeboard or a content guideline. jps (talk) 19:08, 18 October 2024 (UTC)
Yes, but I think it's fair to judge if posting things on a noticeboard often gives a result that has a specific tilt one way, that posting your concern somewhere else would not have. You could take the same exact issue to NPOVN or FTN - as it is in the scope of both, and have two completely contradictory proposed solutions. PARAKANYAA (talk) 19:11, 18 October 2024 (UTC)
the board sometimes overreacts and declares things much more fringe than they actually are, out of proportion Not to be overly dense, but do you have any specific examples of that behavior from FTN that you can share here? Any diffs? If fringe claims are supported by independent, reliable, secondary sources but are nonetheless dismissed as a matter of course at that noticeboard, then a broad-stroke criticism about "out of proportion reactions" might have merit. But without such evidence... JoJo Anthrax (talk) 19:33, 18 October 2024 (UTC)
In sceptic discourse elsewhere I've seen people accused of "promoting pseudoscience" because they wished to discuss something (reflexology in this instance) with more nuance than ridiculing the whole thing. Thryduulf (talk) 19:00, 18 October 2024 (UTC)
It's amusing that some people are willing to throw around the word 'hyperskeptical' but as yet the concept of 'hypercredulous' hasn't been put on the table in this discussion. Bon courage (talk) 03:28, 19 October 2024 (UTC)
I've seen people accused of "promoting pseudoscience" because they wished to discuss something (reflexology in this instance) with more nuance Because we are still discussing FTN (I think), I do not recall any such discussion there, but my memory is not exactly fabulous. In any case, I am unaware of any discussions - or sceptic discourse if you prefer - at FTN where "nuance," if supported by independent, secondary sources, has resulted in people being accused of "promoting pseudoscience." Perhaps some diffs would be in order, as I might be wrong about that. JoJo Anthrax (talk) 19:21, 18 October 2024 (UTC)
The reflexology discussion was several years ago not on Wikipedia so I cannot give you diffs of it. From memory the nuance sought was something along the lines that the act of massaging the feet can have benefits to the feet and things that help you relax can be good for overall health so even if the claims about massaging a specific part of the foot curing an ailment in some other part of the body are rubbish (my gut feeling is they probably are, but I've not looked), ridiculing the whole thing as useless/harmful (I can't remember which it was) was too blunt. They were accused of trying to promote reflexology, of believing in pseudoscience, etc. for those comments. I've seen similar sorts of attitudes from some editors at FTN in the past (not related to Reflexology, I don't think I've ever read a discussion about that on Wikipedia, it's been a good couple of years at least since I've even read our article about it). I can't point to anything specific without doing research I haven't got time to do right now, but I'm clearly not alone in getting these sorts of feelings about the noticeboard. Thryduulf (talk) 20:44, 18 October 2024 (UTC)
OK. But when it comes to justifications for disbanding a noticeboard and/or a content guideline, vague feelings are really thin soup. JoJo Anthrax (talk) 20:56, 18 October 2024 (UTC)
I will freely admit that people have less than warm feelings about the noticeboard. But I'm not convinced that this is necessarily a bad thing.
What you have reminded me of is a similar slate of complaints about the way certain subjects were described. The argument goes, "Even if proponents sometimes employ pseudoscientific arguments and the system itself lacks evidence for efficacy, if the practice or belief is mostly harmless, then why beat people over the head with the lack of evidence or labeling it with derisive labels?"
I think the problem with this kind of accommodationist approach is that it can easily slip into a kind of dishonesty in presentation. This is the fundamental friction that happens with the question of how one approaches these subjects stylistically.
As someone who occasionally reads and comments on the board I'm not a 'skeptic', let alone a 'hyperskeptic'. This again appears to be about individual behaviour not the board, behavioural issues should be handled at ANI or ARBCom. -- LCU ActivelyDisinterested«@» °∆t°18:33, 18 October 2024 (UTC)
I'm not saying everyone who has ever posted there has that point of view, but relative to other places on the project it is tilted a certain way. PARAKANYAA (talk) 18:34, 18 October 2024 (UTC)
As above, do you have any actual evidence (that is, diffs) to support your broad - and vaguely aspersional - claim that "[FTN and editors who comment therein are] tilted a certain way," a "tilt" that makes it unworthy of retention? Anything at all? JoJo Anthrax (talk) 21:22, 18 October 2024 (UTC)
This sounds like the endless "notifying projects is canvassing" discussions (it's not). A noticeboard isn't a private off-site group, anyone can post there or watchlist it, so closing it wouldn't change the behaviour you're concerned about. There are routes for dealing with behavioural issue. -- LCU ActivelyDisinterested«@» °∆t°22:48, 18 October 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Template protection for DYK queues?
For those not familiar with the DYK workflow, its basically anybody can review a submission, anybody can promote a reviewed submission to a prep area, but then we need an admin to move that into a queue, because the queues are fully (i.e. admin only) protected. Once in a queue, an admin bot moves things to {{Did you know}} which is transcluded onto the main page. DYK is chronically short of admins to perform the last step. That's probably the single biggest roadblock to the smooth operation of DYK, and has been for a long time.
There are a number of DYK regulars who are highly skilled and trustworthy, but for all the usual reasons don't want to subject themselves to RfA hell. I started a conversation at WT:DYK#Giving queues template instead of full protection? about the possibility of changing the full protection of the queues to template protection, and making a limited number of DYK regulars template editors. This was met with positive response, so I'm coming here to find out how the broader community would feel about this.
I know it's policy that the main page is fully protected (but I don't know where that's written down). It's unclear to me how much of the DYK queues being fully protected is baked into policy. The Template Editor capability only goes back to 2013, much newer than DYK, so I suspect it's mostly a case of "we've always done it this way". Assuming DYK could agree on the implementation details, would I be within my remit as an admin to change the protection level on the DYK queues and start handing out template editor bits? Or does that require some community-wide approval process? RoySmith(talk)17:57, 30 September 2024 (UTC)
I support the proposal (and suggest that DYK regular admins just hand out the bit as needed). In case anyone is wondering, the DYK template on the Main Page and the next DYK update would continue to be fully protected via cascading protection, so the proposal would not allow template editors to vandalise the Main Page. —Kusma (talk) 18:37, 30 September 2024 (UTC)
Doesn't template editor usually have a host of pre-requirements? As anyone with template editor can change templates transcluded to millions of articles. -- LCU ActivelyDisinterested«@» °∆t°23:11, 30 September 2024 (UTC)
Personally, I don't favour expanding the role of template editors simply because the permission may be easier to grant. I would prefer creating a new permission tailored for the role, such as DYK-editor or main-page-editor, which can be assigned to a corresponding user group. isaacl (talk) 23:54, 30 September 2024 (UTC)
In theory, I agree that a finer-grained permission system would be a good thing. In practice, I suspect it would be near impossible to make that happen. In the meantime, we've got zero filled queues because no admins want to do the work, and the people who want to do the work aren't admins and don't want to be. RoySmith(talk)00:37, 1 October 2024 (UTC)
I'm not sure that it would be impossible to gain consensus for a protection level for, say, main page maintenance. If I understand the documentation correctly, only configuration changes are needed. I just don't see template editor as a good fit: I think it requires a much higher degree of trust than editing main page components. isaacl (talk) 01:32, 1 October 2024 (UTC)
Thanks for the link. As far as I can tell from that, what we'd need to do is not just create a new user group, but also create a new restriction level. That all seems excessively complicated. RoySmith(talk)11:33, 1 October 2024 (UTC)
Yes, that's what I said. Creating the permission level is one line in the configuration, and is necessary to be able to designate which pages can be edited by the new role. Procedurally, it's the equivalent amount of work as designating a page that can only be edited by those with the template editor role, and then assigning users to the corresponding template editor group. isaacl (talk) 15:57, 1 October 2024 (UTC)
As I understand it, the English Wikipedia configuration was modified to implement the template editor role. The change allowed admins to select the template editor permission level when protecting a page, created a template editor user group, and assigned the permission to the new template editor group and the sysop group. The same would have to be done to create a main page editor permission and a corresponding role. The new permission level is needed so specific pages can be designated as limited to main page editors. A corresponding group is needed so main page editors can be assigned to the group. The permission is also assigned to the sysop group so admins can also edit the pages in question. isaacl (talk) 16:55, 1 October 2024 (UTC)
I'm not opposed to going this route, but I'm not confident enough that I understand the details to tackle it myself. If you're willing to take on getting this created, I'll be happy to use it in lieu of my current plan. RoySmith(talk)17:02, 1 October 2024 (UTC)
If it helps, Wikipedia talk:Requests for comment/Template editor user right/Archive 2 § Next steps is where the work to implement the template editor role was discussed. Roughly speaking, it seems to consist of configuration changes, MediaWiki message changes, English Wikipedia page protection process changes, and English Wikipedia icon changes. I'm only tangentially familiar with most of these, so I think a better bet would be to crowdsource volunteers to help out. Hopefully an RfC would find enough interested helpers (as seems to have been the case with the template editor role, but then again, by the nature of that role it was probably more likely to do so). I was mainly thinking of what it took to implement the role in the configuration, rather than how to update English Wikipedia's procedures, so I appreciate now that it's more upfront work than re-using an existing permission level. However I think it pays off by making it easier to replenish a pool of editors able to edit the main page, since they won't have to meet the higher requirements for the template editor role. isaacl (talk) 17:33, 1 October 2024 (UTC)
I don't think fine grained permissions are a good thing. Everybody who can be trusted to edit templates or to decide what should be on the Main Page should be made an admin. The only reason we need extra permissions at all is that we do not have a working method to make new admins. —Kusma (talk) 05:20, 1 October 2024 (UTC)
So in the interest of getting results, I would suggest to go ahead with changing the queue protection to "template protection" and assigning the template editor bit to a couple of people now. A separate permission could be a later second step that we should take if we need it. —Kusma (talk) 11:11, 1 October 2024 (UTC)
My read on this is that they may say they want to do the work, but they don't think they'd be trusted to. And in that case, why should we trust them to? RFA is still thataway, and we're not doing anybody - not the reluctant candidates, not the current admins, not the DYK process - any favors by bypassing it. —Cryptic13:58, 1 October 2024 (UTC)
By bypassing RfA we do almost everyone a favour. The exception is future admins who will have higher workloads because we aren't promoting enough of them. But as long as RfA is so hurtful that failed RfAs have a high chance of putting off people from editing altogether (or at least from running ever again), we need to care for other processes like DYK by finding solutions for their problems without involving RfA. —Kusma (talk) 15:03, 1 October 2024 (UTC)
We have important work that isn't getting done. We have people with the skills and desire to do that work. The only reason we can't draw a line between point A and point B is because RFA is totally broken. RoySmith(talk)15:22, 1 October 2024 (UTC)
We have the ability to draw a line between point A and point B without making it go through point C (whether that's the admin role or the template editor role). We bundle the lines together to try to avoid overhead in managing the lines. But in this case, where drawing the line would be easy given the existence of a pool of editors with the required skills and interest, I think it's less overhead to draw a direct line, rather than routing it through a different point that requires a larger set of skills. isaacl (talk) 16:09, 1 October 2024 (UTC)
Your read on this is wrong. I don't need everything about me to be vetted by voters who can be very rude for no reason, especially when the only thing I would do if I was an admin would be to update DYK. I don't want to ban editors, delete articles, or do any of that stuff. SL93 (talk) 23:33, 3 October 2024 (UTC)
The bizarre thing about all this is that one of the abilities I have as an admin is being able to edit template-protected pages. Which is stupid because my understanding of non-trivial template syntax is essentially zero. The only thing I know how to #invoke is sheer terror about anything that has more than one pair of curly braces. And of all the stupid things I've seen asked at RfA, never once have I seen anybody quizzed on their understanding of template syntax. RoySmith(talk)00:01, 4 October 2024 (UTC)
Presumably trusted with the mop. We'd now be potentially extending that same level of trust to some DYK editors who probably won't have any template coding experience either. —Bagumba (talk) 13:31, 4 October 2024 (UTC)
Same. I can break any template the first time I use it, and I won't go near editing most except for things like adding an entry in a navigation template. I think what we need to consider is whether an editor can be trusted to know what they don't know. Valereee (talk) 16:21, 5 October 2024 (UTC)
DYK queue editors would likely not have the "real" template coding experience typically expected by WP:TPEGRANT. They basically are just editing text. But if given the right, they would then have access to other highly-sensitive templates and their actual code. —Bagumba (talk) 12:45, 1 October 2024 (UTC)
@ActivelyDisinterested As long as they meet the first 4 criteria of WP:TPEGRANT I don't seen how they'd be more likely to break every page than any other template editor (and in reality, I think the worst a template editor could do is break a little under 20% of pages), and anything they put on the main page would have to sit in the queue first where it could be reverted before hitting the main page. --Ahecht (TALK PAGE)21:44, 7 October 2024 (UTC)
What about the other 3 criteria aren't you meant to meet all four of them? Also doesn't the main page directly transclude templates? If so the TPE right could be abused to push anything to it. As to how many pages could be effect I'm not sure how many pages something like {{cite web}} or {{short description}} is transcluded to, but I'd bet it's more than 20%. -- LCU ActivelyDisinterested«@» °∆t°23:06, 7 October 2024 (UTC)
While these are technically templates, these aren't really templates. Granting template editor rights to editors who have no experience working with templates is completely the wrong way of doing things. Gonnym (talk) 11:46, 15 October 2024 (UTC)
Just to be clear, what I'm seeking here is clarification on why the queues are fully protected. Is there some specific established policy which requires that because they feed into the main page?— Preceding unsigned comment added by RoySmith (talk • contribs) 11:24, 1 October 2024 (UTC)
The DYK queues might be a good use case for pending changes level 2 (disabled for the better part of a decade), or heck, even level 1. The admin bot could be changed to copy over only the most recent approved revision. IznoPublic (talk) 03:14, 6 October 2024 (UTC)
BTW, this change was made a few days ago. So far, the world has not come to an end, so let's see how things go. If there's problems, we can always revisit this to see if a different solution would work better. RoySmith(talk)20:37, 14 October 2024 (UTC)
The question I was asking was "Is there a policy reason which prevents me from doing this". Nobody came up with such a reason. RoySmith(talk)21:00, 14 October 2024 (UTC)
Have we ever considered reducing the responsibilities of the posters i.e. more onus on the prep areas being good to go? —Bagumba (talk) 17:13, 19 October 2024 (UTC)
New Page Reviewers
Hi. I thought I ask the question here regarding policy on New Page Reviewers. The current tutorial states "The purpose of new pages patrol is equally to identify pages which cannot meet this standard, and so should be deleted, and to support the improvement of those that can. Pages that pass new pages patrol don't have to be perfect, just not entirely unsuitable for inclusion." On several occasions I have noted that new page reviewers have marked pages as reviewed, but for other editors to then go in another as not meeting notability rules. If this is the case is there not a mechanism that the new page reviewers can be reported as not meeting the "just not entirely unsuitable for inclusion" criteria? Davidstewartharvey (talk) 12:22, 29 September 2024 (UTC)
I think they are saying that there are 2 editors A and B. A reviews the page, marks it as reviewed, then B marks it as not meeting notability rules. And the question is whether there is a way to report this inconsistency based on the premise that B is correct, and A made an error. Sean.hoyland (talk) 12:55, 29 September 2024 (UTC)
It's common for editors to disagree on notability, as is clear in a number of AfD nominations, so a reviewer passing a new page that is subsequently nominated for deletion isn't necessarily a problem. If, however, you see it happening frequently with the same reviewer, you should discuss your concerns with that editor on their talk page. Schazjmd(talk)14:07, 29 September 2024 (UTC)
Something doesn't have to be unquestionably notable to pass NPP patrol. It just needs to be "not entirely unsuitable". Some NPPers will only mark at patrolled when they're very, very sure a topic is notable; others will mark it as patrolled so long as it doesn't meet some of the WP:CSD criteria, most reviewers are somewhere in between the two. Also, many people use the notability tag not to mean "this isn't notable" (really, if you're sure, you should probably start a deletion discussion), but "I don't know if this is notable, can someone who knows more about this kind of thing come check?" So even if two different reviewers might both agree that a page should be marked as patrolled, that doesn't mean that one reviewer might want to leave a notability tag where the other wouldn't. -- asilvering (talk) 00:38, 30 September 2024 (UTC)
I haven't heard anybody object to them? No doubt you've amassed a considerable knowledge of the spectrum of opinions on new page reviewing since I granted you the right six months ago, though. – Joe (talk) 18:13, 14 October 2024 (UTC)
Is that sarcasm? I also think that essay contains some controversial points. Don't worry about notability seems a little extreme for me. Cremastra (u — c) 16:19, 20 October 2024 (UTC)
As someone who does make significant use of draftification and probably has stronger opinions on notability of the articles I usually review, I review very differently but I don't actually disagree with that essay in that it represents a valid way of review. Just my two cents. Alpha3031 (t • c) 23:42, 16 October 2024 (UTC)
Wikipedia:Indic transliteration and WP:INDICSCRIPT
I know this is biased but I find it to be really unfair that we cannot use the scripts that were written Indian languages all because of one user did something back in 2012. Like, we could have use the scripts for cities for example. SpinnerLaserzthe2nd (talk) 16:18, 12 October 2024 (UTC)
It seems that WP:IndicScript, for the lede and infobox, has been discussed several times from 2012 thru 2017. Since we're past 7 years from the previous discussion (at least as listed on the policy page), it's probably time to have another discussion, to get the beat from editors as to where ethnonationalist edit-warring on this is at nowadays, and consider a new RfC (even if just to reaffirm the old policy). SamuelRiv (talk) 17:11, 12 October 2024 (UTC)
Procedural close or move to some other forum or talk page. No substantive reason to change anything has been expressed. There's no clear proposal either. "Not fair", "one user did something" and "7-year-old RFC" are not actionable items on which it is possible to form a consensus. —Alalch E.13:13, 13 October 2024 (UTC)
I suggest starting a thread at Wikipedia_talk:Manual_of_Style/India-related_articles. It looks like the issue has been brought up before, but there's been no updated information on vandalism posted, which is the key consideration. Maybe you'll want to solicit such information first by announcing your intentions beforehand, and post a notice on WP:Wikiproject India.
Anecdotally, I tried to propose a relatively small exception to the current guideline a year ago or so and was met with pretty significant pushback, so I'd expect a similar response to any suggestion along SpinnerLaserz's lines, despite being sympathetic to it myself. signed, Rosguilltalk16:49, 13 October 2024 (UTC)
What might be practical is a change to permit especially pertient scripts (e.g. of top 2 or 3 official and majority languages in a relevant location, or those most culturally appopriate with regard to some historical person or event). The central issue is that there are dozens of writing systems extant in and around India. This "it's all because of one user" stuff is nonsense; WP:INDICSCRIPT exists to address a practicality issue. But it may need revision, to not take a throw-the-baby-out-with-the-bathwater approach. — SMcCandlish☏¢ 😼 16:23, 20 October 2024 (UTC)
The same problems exist in many parts of the world other than South Asia. It has always struck me as rather odd that we single out Indic scripts in such a way. One by-product of this is that it can be difficult to find sources for subjects that do not have a fixed Roman transcription. Phil Bridger (talk) 18:18, 20 October 2024 (UTC)
RfC: In the news criteria amendments
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Should either of the following proposals to amend the criteria for In the news be adopted?
Proposal 1: Amend the ITN significance criteria (WP:ITNSIGNIF) to state: The significance criteria are met if an event is reported on the print front pages of major national newspapers in multiple countries (examples of websites hosting front pages: [11] and [12]).
Proposal 2: Abolish ITNSIGNIF and amend the ITN update requirement (WP:ITNUPDATE) to state that a sufficient update is one that adds substantial due coverage of an event (at least two paragraphs or five sentences) to an article about a notable subject.
Proposal 3: Mark WP:ITN as historical and remove the "In The News" template from the Main Page, effectively closing the process in lieu of an alternate means of featuring encyclopedic content on Wikipedia.
Adding for the record Proposal 3: Mark WP:ITN as historical and remove the "In The News" template from the Main Page, effectively closing the process in lieu of an alternate means of featuring encyclopedic content on Wikipedia. Duly signed,⛵ WaltClipper-(talk)13:48, 8 October 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I want to suggest default unban appeal terms. Namely to incorporate WP:SO into it. Something along the lines of this:
Unless stated otherwise in the ban, a community ban may be appealed not less than six months from the enactment, or six months after the last declined (or inappropriate) appeal. This includes bans as a result of repeated block evasion, bans as a result of a block review by the community, and bans occurring de facto. This does not apply if there are serious doubts about the validity of the closure of the ban discussion. A ban from the Arbitration Committee may be appealed not less than 12 months from the enactment, or 12 months after the last declined (or inappropriate) appeal. None of these appeal provisions apply to arbitration enforcement blocks, such as blocks enforcing contentious topic restrictions, or community sanction blocks.
I am pretty sure that this is sensible for most bans. While the ArbCom part will require an ArbCom motion, the community part could happen almost immediately. AwesomeAasim02:38, 13 October 2024 (UTC)
Repeating this in VPPL to get further input. I think this should be added to the Banning policy. We can further refine it to get the right wording that can then be added in one swift edit. AwesomeAasim22:47, 13 October 2024 (UTC)
It is more to codify what is already standard practice. Community bans are rare, but ArbCom bans are rarer. Although blocks are much more common, though. AwesomeAasim04:20, 21 October 2024 (UTC)
Problems with 'reliable sources' and 'original research'
Dear Editors, I have not posted here before but have been advised to do so by your volunteer Responder.
I wish to request some flexibility in the No original research' policy.
We were recently working on a 19th century lady who has a Wiki page, but about whom only one book has, I think, been published and that book has her date of birth incorrect along with a few other aspects of her life.
But when we tried to change the birth date as we have her birth and baptism registrations from expert genealogists, WIki told us that constituted 'original research' and as the book was published it must be deemed to be a 'reliable source'.
Sorry but I am astonished.
So many publications contain inaccurate material (not deliberately) and if there is only one published source one apparnetly cannot refute it without another. This doesn't seem workable.
The whole matter reminds me of my school history teacher who asked us for one lesson to bring into school different newspapers all published on a certain day. We then had to read the same item of news in all the different newspapers to show us how very different they were according apparnet sources and statements of 'facts'; political leaning; the experience and background of the journalist authors and their own opinions, etc. Specifically the teacher wanted to emphasise that just because it is published and in print - it does not mean that it is true and accurate !
I see that you have tried to address this under your 'reliable sources' heading, and I am not suggesting that the published book deliberately made errors.
However surely there must be provision in WIki for correcting entries which were made in good faith at the time but can now be shown to be incorrect. And if it is a birth and parentage then usually the 'proof' lies in the birth records of the state or country in which they were born and not in another publication. I hope you see what I mean. Stiperstones (talk) 21:16, 21 October 2024 (UTC)
Have you considered having an expert publish a paper or article on the subject with the correct information? That is generally the most straightforward way to address this sort of thing, especially so far in the past. Horse Eye's Back (talk) 21:44, 21 October 2024 (UTC)
I would also note that there may also be a way to use the birth and baptism registrations directly as primary sources, but that is much more context dependent. The birth and baptism registrations might also not be accurate. Horse Eye's Back (talk) 21:46, 21 October 2024 (UTC)
Another concern, is that the person mentioned in a set of birth and baptism registrations might possibly be a different person with the same name and an explanation is needed as to why they are same person.
Given that you have expert genealogists willing to sign off on the change of birthdates, could the error be noted in a footnote to article saying this problem exists, even if is not suffcient for changing the text of article?
As far as getting it published, an expert might be able to publish the correct information as a short letter or report in an regional journal. They might be able to use the incoorect information in book leading to errors in Wikipedia and other articles using it as source as a justification for publishing the short letter or report as a formal publications.
The advice given at the essay Wikipedia:When sources are wrong is sound, and the specifics of proceeding will probably be best worked out on the talk page.
Sometimes a little IAR can be appropriate in borderline cases, as just one example see the discussion of fumarolic activity in Copiapó (volcano), but that really only holds when there is no opposition to the proposed content.
As an amusing little historical tidbit, in the late 00s there still was still limited sourcing available for Jimmy Wales, and those that mentioned his birthdate simply got it wrong. As a result he spent a good deal of time arguing with other editors over his birthdate no joke.
There have actually been a couple of similar issues involving birthdates over the years, made all the more tedious to work through by periodic WP:CITOGENESIS.
To get a deeper picture of the knots this kind of stuff has twisted normally reasonable people into over the years, and why things are the way they are, you can try to muddle your way through this discussion and this rfc. And if you have an absolute surfeit of time and can tolerate reading lengthy disjointed and circuitous discussions of varying intelligibility you can help yourself to the 81 and counting archives over at WT:V. 184.152.68.190 (talk) 03:14, 22 October 2024 (UTC)
good (depending whether the link is live):
bad:
Moved from Wikipedia talk:Banning policy