This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
Should admins or other users evaluating consensus in a discussion discount, ignore, or strike through or collapse comments found to have been generated by AI/LLM/Chatbots? 00:12, 2 December 2024 (UTC)
I've recently come across several users in AFD discussions that are using LLMs to generate their remarks there. As many of you are aware, gptzero and other such tools are very good at detecting this.
I don't feel like any of us signed up for participating in discussions where some of the users are not using their own words but rather letting technology do it for them. Discussions are supposed to be between human editors. If you can't make a coherent argument on your own, you are not competent to be participating in the discussion. I would therefore propose that LLM-generated remarks in discussions should be discounted or ignored, and possibly removed in some manner. Just Step Sidewaysfrom this world ..... today00:12, 2 December 2024 (UTC)[reply]
Only if the false positive and false negative rate of the tool you are using to detect LLM content is very close to zero. LLM detectors tend to be very unreliable on, among other things, text written by non-native speakers. Unless the tool is near perfect then it's just dismissing arguments based on who wrote them rather than their content, which is not what we do or should be doing around here. Thryduulf (talk) 00:55, 2 December 2024 (UTC)[reply]
The more I read the comments from other editors on this, the more I'm a convinced that implementing either this policy or something like it will bring very significant downsides on multiple fronts that significantly outweigh the small benefits this would (unreliably) bring, benefits that would be achieved by simply reminding closers to disregard comments that are unintelligible, meaningless and/or irrelevant regardless of whether they are LLM-generated or not. For the sake of the project I must withdraw my previous very qualified support and instead very strongly oppose. Thryduulf (talk) 02:45, 3 December 2024 (UTC)[reply]
I think it should be an expressly legitimate factor in considering whether to discount or ignore comments either if it's clear enough by the text or if the user clearly has a history of using LLMs. We wouldn't treat a comment an editor didn't actually write as an honest articulation of their views in lieu of site policy in any other situation. Remsense ‥ 论00:59, 2 December 2024 (UTC)[reply]
I would have already expected admins to exercise discretion in this regard, as text written by an LLM is not text written by a person. We cannot guarantee it is what the person actually means, especially as it is a tool often used by those with less English proficiency, which means perhaps they cannot evaluate the text themselves. However, I do not think we can make policy about a specific LLM or tool. The LLM space is moving fast, en.wiki policies do not. Removal seems tricky, I would prefer admins exercise discretion instead, as they do with potentially canvassed or socked !votes. CMD (talk) 01:06, 2 December 2024 (UTC)[reply]
Support discounting or collapsing AI-generated comments, under slightly looser conditions than those for human comments. Not every apparently-AI-generated comment is useless hallucinated nonsense – beyond false positives, it's also possible for someone to use an AI to help them word a constructive comment, and make sure that it matches their intentions before they publish it. But in my experience, the majority of AI-generated comments are somewhere between "pointless" and "disruptive". Admins should already discount clearly insubstantial !votes, and collapse clearly unconstructive lengthy comments; I think we should recognize that blatant chatbot responses are more likely to fall into those categories. jlwoodwa (talk) 02:11, 2 December 2024 (UTC)[reply]
Strongly Support - I think some level of human judgement on the merits of the argument are necessary, especially as GPTZero may still have a high FPR. Still, if the discussion is BLUDGEONy, or if it quacks like an AI-duck, looks like an AI-duck, etc, we should consider striking out such content.- sidenote, I'd also be in favor of sanctions against users who overuse AI to write out their arguments/articles/etc. and waste folks time on here.. Bluethricecreamman (talk) 02:20, 2 December 2024 (UTC)[reply]
On a wording note, I think any guidance should avoid referring to any specific technology. I suggest saying "... to have been generated by a program". isaacl (talk) 02:54, 2 December 2024 (UTC)[reply]
A translation program, whether it is between languages or from speech, is not generating a comment, but converting it from one format to another. A full policy statement can be more explicit in defining "generation". The point is that the underlying tech doesn't matter; it's that the comment didn't feature original thought from a human. isaacl (talk) 03:57, 2 December 2024 (UTC)[reply]
Support. We already use discretion in collapsing etc. comments by SPAs and suspected socks, it makes sense to use the same discretion for comments suspected of being generated by a non-human. JoelleJay (talk) 03:07, 2 December 2024 (UTC)[reply]
Support - Someone posting "here's what ChatGPT has to say on the subject" can waste a lot of other editors' time if they feel obligated to explain why ChatGPT is wrong again. I'm not sure how to detect AI-written text but we should take a stance that it isn't sanctioned. Clayoquot (talk | contribs) 04:37, 2 December 2024 (UTC)[reply]
Strong Support - I've never supported using generative AI in civil discourse. Using AI to participate in these discussions is pure laziness, as it is substituting genuine engagement and critical thought with a robot prone to outputting complete garbage. In my opinion, if you are too lazy to engage in the discussion yourself, why should we engage with you? Lazman321 (talk) 05:26, 2 December 2024 (UTC)[reply]
Because it's based on a potentially false premise that it will be possible to reliably distinguish between text generated by human biological neural networks and text generated by non-biological neural networks by observing the text. It is already quite difficult in many cases, and the difficulty is increasing very rapidly. I have your basic primate brain. The AI companies building foundation models have billions of dollars, tens of thousands, soon to be hundreds of thousands of GPUs, a financial incentive to crack this problem and scaling laws on their side. So, I have very low credence in the notion that I will be able to tell whether content is generated by a person or a person+LLM or an AI agent very soon. On the plus side, it will probably still be easy to spot people making non-policy based arguments regardless of how they do it. Sean.hoyland (talk) 13:52, 2 December 2024 (UTC)[reply]
...and now that the systems are autonomously injecting their output back into model via chain-of-thought prompting, or a kind of inner monologue if you like, to respond to questions, they are becoming a little bit more like us. Sean.hoyland (talk) 14:14, 2 December 2024 (UTC)[reply]
A transformer (deep learning architecture) is intrinsically nothing like a human. It's a bunch of algebra that can compute what a decently sensible person could write in a given situation based on its training data, but it is utterly incapable of anything that could be considered thought or reasoning. This is why LLMs tend to fail spectacularly when asked to do math or write non-trivial code. Flounder fillet (talk) 17:20, 2 December 2024 (UTC)[reply]
We shall see. You might want to update yourself on their ability to do math and write non-trivial code. Things are changing very quickly. Either way, it is not currently possible to say much about what LLMs are actually doing because mechanistic interpretability is in its infancy. Sean.hoyland (talk) 03:44, 3 December 2024 (UTC)[reply]
Support and I would add "or similar technologies" to "AI/LLM/Chatbots". As for Sean.hoyland's comment, we will cross that bridge when we get to it. Cullen328 (talk) 05:51, 2 December 2024 (UTC)[reply]
Support - All editors should convey their thoughts in their own words. AI generated responses and comments are disruptive because they are pointless and not meaningful. - Ratnahastin (talk) 06:04, 2 December 2024 (UTC)[reply]
Support, I already more or less do this. An LLM generated comment may or may not actually reflect the actual thoughts of the editor who posted it, so it's essentially worthless toward a determination of consensus. Since I wrote this comment myself, you know that it reflects my thoughts, not those of a bot that I may or may not have reviewed prior to copying and pasting. SeraphimbladeTalk to me06:59, 2 December 2024 (UTC)[reply]
Strong oppose. Let me say first that I do not like ChatGPT. I think it has been a net negative for the world, and it is by nature a net negative for the physical environment. It is absolutely a net negative for the encyclopedia if LLM-generated text is used in articles in any capacity. However, hallucinations are less of an issue on talk pages because they're discussions. If ChatGPT spits out a citation of a false policy, then obviously that comment is useless. If ChatGPT spits out some boilerplate "Thanks for reviewing the article, I will review your suggestions and take them into account" talk page reply, who gives a fuck where it came from? (besides the guys in Texas getting their eardrums blown out because they live by the data center)The main reason I oppose, though, is because banning LLM-generated comments is difficult to enforce bordering on unenforceable. Most studies show that humans are bad at distinguishing AI-generated text from text generated without AI. Tools like GPTZero claims a 99% accuracy rate, but that seems dubious based on reporting on the matter. The news outlet Futurism (which generally has an anti-AI slant) has failed many times to replicate that statistic, and anecdotal accounts by teachers, etc. are rampant. So we can assume that we don't know how capable AI detectors are, that there will be some false positives, and that striking those false positives will result in WP:BITING people, probably newbies, younger people more accustomed to LLMs, and non-Western speakers of English (see below).There are also technological issues as play. It'd be easy if there was a clean line between "totally AI-generated text" and "totally human-generated text," but that line is smudged and well on its way to erased. Every tech company is shoving AI text wrangling into their products. This includes autocomplete, translation, editing apps, etc. Should we strike any comment a person used Grammarly or Google Translate for? Because those absolutely use AI now.And there are also, as mentioned above, cultural issues. The people using Grammarly, machine translation, or other such services are likely to not have English as their first language. And a lot of the supposed "tells" of AI-generated content originate in the formal English of other countries -- for instance, the whole thing where "delve" was supposedly a tell for AI-written content until people pointed out the fact that lots of Nigerian workers trained the LLM and "delve" is common Nigerian formal English.I didn't use ChatGPT to generate any of this comment. But I am also pretty confident that if I did, I could have slipped it in and nobody would have noticed until this sentence. Gnomingstuff (talk) 08:31, 2 December 2024 (UTC)[reply]
Just for grins, I ran your comment through GPTzero, and it comes up with a 99% probability that it was human-written (and it never struck me as looking like AI either, and I can often tell.) So, maybe it's more possible to distinguish than you think? SeraphimbladeTalk to me20:11, 2 December 2024 (UTC)[reply]
Support - Ai-generated comments are WP:DISRUPTIVE - An editor who has an argument should not use ChatGPT to present it in an unnecessarily verbose manner, and an editor who doesn't have one should not participate in discussion. Flounder fillet (talk) 13:14, 2 December 2024 (UTC)[reply]
Yes, of course, and I know that's the right answer because ChatGPT agrees with me.
What ChatGPT thinks
I started by asking:
Currently at the English Wikipedia, there's a discussion of the following proposal: "Should or other users evaluating consensus in a discussion discount, ignore, or strike through or collapse comments found to have been generated by AI/LLM/Chatbots?" I wonder if you have an opinion on that question.
My friend the bot initially proposed a requirement that any AI-generated content be labeled as such by the person posting it. After some further discussion between us, I finally said:
You say that labeling AI-generated content, instead of outright discounting it, might be an appropriate middle ground. But if someone is unable to formulate their own thoughts and put them in writing, of what use is it to the discussion for this person to simply ask you to make something up, and then post your output to the Wikipedia discussion with the proviso that "ChatGPT, who/which doesn't actually know anything about anything, said this ..."? How is it different from saying, "My grandmother, who knows nothing about what we're talking about, said ..."?
And it said:
That’s an incisive question, and it highlights the crux of the issue: the value of contributions to a discussion. Here’s why AI-generated comments might still differ (slightly) from your hypothetical grandmother’s input, but why their usefulness is often limited:
Synthesis vs. Subject Expertise: While I (or any AI) lack personal understanding or expertise, I can aggregate and articulate relevant ideas from a vast dataset. This means I can sometimes present arguments, summarize perspectives, or surface considerations that a non-expert human might overlook. Your grandmother, unless she's an AI-trained polymath, wouldn’t be able to provide this breadth. However, this advantage evaporates if participants lack the ability to evaluate and critically engage with my output.
The Problem of Proxy Voices: The act of outsourcing one’s contribution to AI undermines the deliberative process central to Wikipedia’s discussions. Participants are expected to bring their own informed perspectives, shaped by personal understanding of Wikipedia’s policies and content. A disclaimer like “ChatGPT said this” doesn’t change the fact that the human posting it has abdicated their role in the discussion.
Accountability and Intent: In a collaborative setting like Wikipedia, contributions are ideally linked to a person who can clarify their intent, respond to questions, and engage dynamically. An AI cannot do this. Saying "ChatGPT said this" distances the poster from the content, making it unclear whether they endorse or even understand the comment.
Potential for Misdirection: Allowing AI-generated contributions risks introducing noise into the discussion. AI can produce plausible-sounding arguments that may be tangential, misaligned, or even factually incorrect. Without the judgment of a well-informed poster, such contributions can derail or dilute meaningful discourse.
Conclusion: If someone cannot formulate their own argument or understanding, then their reliance on an AI—or anyone else—to contribute doesn’t meaningfully advance the discussion. Labeling AI-generated content is better than passing it off as human, but the real issue lies in whether such contributions enrich or degrade the collaborative process. In most cases, they would seem to belong more to the realm of rhetorical curiosities than substantive engagement.
In keeping with the proposed guideline, I have of course collapsed the above AI-generated content. (Later: It's actually worth reading in the context of this discussioin, so I've unhidden it by default.) But I must confess it's a pretty good analysis, and worth reading. EEng07:47, 2 December 2024 (UTC)[reply]
This is absolute gold dust and the best contribution to this discussion so far. There is an enormous irony here, one that might not be immediately obvious. The proposal is that we should ignore or even strike these type of contributions, but personally it seems like the collapsed format has worked a charm here. I really don't think that AI has much to contribute to WP discussions generally, but with the right prompt, there is certainly something worth adding to the conversation in reality. CNC (talk) 20:23, 8 December 2024 (UTC)[reply]
That's because, just by interacting with me, ChatGPT got smarter. Seriously ... you want it to say 99% every time? (And for the record, the idea of determining the "chance" that something is AI-generated is statistical nonsense.) EEng03:07, 3 December 2024 (UTC)[reply]
What I really want is a 100% chance that it won't decide that what I've written is AI-generated. Past testing has demonstrated that at least some of the detectors are unreliable on this point. WhatamIdoing (talk) 03:28, 4 December 2024 (UTC)[reply]
Strong Oppose I support the concept of removal of AI-generated content in theory. However, we do not have the means to detect such AI-generated content. The proposed platform that we may use (GPTZero) is not reliable for this purpose. In fact, our own page on GPTZero has a section citing several sources stating the problem with this platform's accuracy. It is not helpful to have a policy that is impossible to enforce. ThatIPEditorThey / Them08:46, 2 December 2024 (UTC)[reply]
Strong Support To be honest, I am surprised that this isn't covered by an existing policy. I oppose the use of platforms like GPTZero, due to it's unreliability, but if it is obviously an ai-powered-duck (Like if it is saying shit like "as an AI language model...", take it down and sanction the editor who put it up there. ThatIPEditorThey / Them08:54, 2 December 2024 (UTC)[reply]
Support at least for WP:DUCK-level AI-generated comments. If someone uses a LLM to translate or improve their own writing, there should be more leeway, but something that is clearly a pure ChatGPT output should be discounted. Chaotic Enby (talk · contribs) 09:17, 2 December 2024 (UTC)[reply]
I agree for cases in which it is uncontroversial that a comment is purely AI-generated. However, I don't think there are many cases where this is obvious. The claim that gptzero and other such tools are very good at detecting this is false. Phlsph7 (talk) 09:43, 2 December 2024 (UTC)[reply]
Moral support; neutral as written. Chatbot participation in consensus discussions is such an utterly pointless and disdainful abuse of process and community eyeballs that I don't feel like the verbiage presented goes far enough. Any editor may hat LLM-generated comments in consensus discussions is nearer my position. No waiting for the closer, no mere discounting, no reliance on the closer's personal skill at recognising LLM output, immediate feedback to the editor copypasting chatbot output that their behaviour is unwelcome and unacceptable. Some observations:I've seen editors accused of using LLMs to generate their comments probably about a dozen times, and in all but two cases – both at dramaboards – the chatbot prose was unmistakably, blindingly obvious. Editors already treat non-obvious cases as if written by a human, in alignment with the raft of only if we're sure caveats in every discussion about LLM use on the project.If people are using LLMs to punch up prose, correct grammar and spelling, or other superficial tasks, this is generally undetectable, unproblematic, and not the point here.Humans are superior to external services at detecting LLM output, and no evidence from those services should be required for anything.As a disclosure, evidence mounts that LLM usage in discussions elicits maximally unkind responses from me. It just feels so contemptuous, to assume that any of us care what a chatbot has to say about anything we're discussing, and that we're all too stupid to see through the misattribution because someone tacked on a sig and sometimes an introductory paragraph. And I say this as a stupid person. Folly Mox (talk) 11:20, 2 December 2024 (UTC)[reply]
Looks like a rewrite is indicated to distinguish between machine translation and LLM-generated comments, based on what I'm seeing in this thread. Once everyone gets this out of our system and an appropriately wordsmithed variant is reintroduced for discussion, I preemptively subpropose the projectspace shortcut WP:HATGPT. Folly Mox (talk) 15:26, 8 December 2024 (UTC)[reply]
I would be careful here, as there are tools that rely on LLM AI that help to improve the clarity of one's writing, and editors may opt to use those to parse their poor writing (perhaps due to ESL aspects) to something clear. I would agree content 100% generated by AI probably should be discounted particularly if from an IP or new editors (hints if socking or meat puppetry) but not all cases where AI has come into play should be discounted — Masem (t) 14:19, 2 December 2024 (UTC)[reply]
Support, cheating should have no place or take its place in writing coherent comments on Wikipedia. Editors who opt to use it should practice writing until they rival Shakespeare, or at least his cousin Ned from across the river, and then come back to edit. Randy Kryn (talk) 14:29, 2 December 2024 (UTC)[reply]
Support atleast for comments that are copied straight from the LLM . However, we should be more lenient if the content is rephrased by non-native English speakers due to grammar issues The AP (talk) 15:10, 2 December 2024 (UTC)[reply]
Support for LLM-generated content (until AI is actually intelligent enough to create an account and contribute on a human level, which may eventually happen). However, beware of the fact that some LLM-assisted content should probably be allowed. An extreme example of this: if a non-native English speaker were to write a perfectly coherent reason in a foreign language, and have an LLM translate it to English, it should be perfectly acceptable. Animal lover|666|16:47, 2 December 2024 (UTC)[reply]
Oppose - I think the supporters must have a specific type of AI-generated content in mind, but this isn't a prohibition on one type; it's a prohibition on the use of generative AI in discussions (or rather, ensuring that anyone who relies on such a tool will have their opinion discounted). We allow people who aren't native English speakers to contribute here. We also allow people who are native English speakers but have difficulty with language (but not with thinking). LLMs are good at assisting both of these groups of people. Furthermore, as others pointed out, detection is not foolproof and will only get worse as time goes on, models proliferate, models adapt, and users of the tools adapt. This proposal is a blunt instrument. If someone is filling discussions with pointless chatbot fluff, or we get a brand new user who's clearly using a chatbot to feign understanding of wikipolicy, of course that's not ok. But that is a case by case behavioral issue. I think the better move would be to clarify that "some forms of LLM use can be considered disruptive and may be met with restrictions or blocks" without making it a black-and-white issue. — Rhododendritestalk \\ 17:32, 2 December 2024 (UTC)[reply]
I agree the focus should not be on whether or not a particular kind of tech was used by an editor, but whether or not the comment was generated in a way (whether it's using a program or ghost writer) such that it fails to express actual thoughts by the editor. (Output from a speech-to-text program using an underlying large language model, for instance, isn't a problem.) Given that this is often hard to determine from a single comment (everyone is prone to post an occasional comment that others will consider to be off-topic and irrelevant), I think that patterns of behaviour should be examined. isaacl (talk) 18:07, 2 December 2024 (UTC)[reply]
Here's what I see as two sides of a line. The first is, I think, something we can agree would be inappropriate. The second, to me at least, pushes up against the line but is not ultimately inappropriate. But they would both be prohibited if this passes. (a) "I don't want an article on X to be deleted on Wikipedia. Tell me what to say that will convince people not to delete it"; (b) "I know Wikipedia deletes articles based on how much coverage they've received in newspapers, magazines, etc. and I see several such articles, but I don't know how to articulate this using wikipedia jargon. Give me an argument based on links to wikipedia policy that use the following sources as proof [...]". Further into the "acceptable" range would be things like translations, grammar checks, writing a paragraph and having an LLM improve the writing without changing the ideas, using an LLM to organize ideas, etc. I think what we want to avoid are situations where the arguments and ideas themselves are produced by AI, but I don't see such a line drawn here and I don't think we could draw a line without more flexible language. — Rhododendritestalk \\ 18:47, 2 December 2024 (UTC)[reply]
Yes, as I posted earlier, the underlying tech isn't important (and will change). Comments should reflect what the author is thinking. Tools (or people providing advice) that help authors express their personal thoughts have been in use for a long time. isaacl (talk) 19:08, 2 December 2024 (UTC)[reply]
Yeah the point here is passing off a machine's words as your own, and the fact that it is often fairly obvious when one is doing so. If a person is not competent to express their own thoughts in plain English, they shouldn't be in the discussion. This certainly is not aimed at assistive technology for those who actually need it but rather at persons who are simply letting Chatbots speak for them. Just Step Sidewaysfrom this world ..... today20:10, 2 December 2024 (UTC)[reply]
This doesn't address what I wrote (though maybe it's not meant to). If a person is not competent to express their own thoughts in plain English, they shouldn't be in the discussion. This certainly is not aimed at assistive technology for those who actually need it but rather at persons who are simply letting Chatbots speak for them is just contradictory. Assistive technologies are those that can help people who aren't "competent" to express themselves to your satisfaction in plain English, sometimes helping with the formulation of a sentence based on the person's own ideas. There's a difference between having a tool that helps me to articulate ideas that are my own and a tool that comes up with the ideas. That's the distinction we should be making. — Rhododendritestalk \\ 21:23, 2 December 2024 (UTC)[reply]
I agree with Rhododendrites that we shouldn't be forbidding users from seeking help to express their own thoughts. Getting help from someone more fluent in English, for example, is a good practice. Nowadays, some people use generative technology to help them prepare an outline of their thoughts, so they can use it as a starting point. I think the community should be accepting of those who are finding ways to write their own viewpoints more effectively and concisely, even if that means getting help from someone or a program. I agree that using generative technology to come up with the viewpoints isn't beneficial for discussion. isaacl (talk) 22:58, 2 December 2024 (UTC)[reply]
Non-native English speakers and non-speakers to whom a discussion is important enough can already use machine translation from their original language and usually say something like "Sorry, I'm using machine translation". Skullers (talk) 08:34, 4 December 2024 (UTC)[reply]
Oppose Contributions to discussions are supposed to be evaluated on their merits per WP:NOTAVOTE. If an AI-assisted contribution makes sense then it should be accepted as helpful. And the technical spectrum of assistance seems large and growing. For example, as I type this into the edit window, some part of the interface is spell-checking and highlighting words that it doesn't recognise. I'm not sure if that's coming from the browser or the edit software or what but it's quite helpful and I'm not sure how to turn it off. Andrew🐉(talk) 18:17, 2 December 2024 (UTC)[reply]
But we're not talking about spell-checking. We're talking about comments clearly generated by LLMs, which are inherently unhelpful. Lazman321 (talk) 18:29, 2 December 2024 (UTC)[reply]
Andrew's first two sentences also seem to imply that he views AI-generated arguments that makes sense as valid, and that we should consider what AI thinks about a topic. I'm not sure what to think about this, especially since AI can miss out on a lot of the context. Aaron Liu (talk) 23:04, 2 December 2024 (UTC)[reply]
Written arguments are supposed to be considered on their merits as objects in their own right. Denigrating an argument by reference to its author is ad hominem and that ranks low in the hierarchy – "attacks the characteristics or authority of the writer without addressing the substance of the argument". Andrew🐉(talk) 23:36, 2 December 2024 (UTC)[reply]
An AI chatbot isn't an "author", and it's impossible to make an ad hominem attack on one, because a chotbot is not a homo. EEng17:45, 6 December 2024 (UTC)[reply]
On the other hand, "exhausting the community's patience"/CompetenceIsRequired is a very valid rationale from stopping someone from partricipating. Aaron Liu (talk) 23:50, 2 December 2024 (UTC)[reply]
The spell-checking was an immediate example but there's a spectrum of AI tools and assistance. The proposed plan is to use an AI tool to detect and ban AI contributions. That's ludicrous hypocrisy but suggests an even better idea – that we use AIs to close discussions so that we don't get the bias and super-voting. I see this on Amazon regularly now as it uses an AI to summarise the consensus of product reviews. For example,
Customers say Customers appreciate the gloves for their value, ease of use, and gardening purposes. They find the gloves comfortable and suitable for tasks like pruning or mowing. However, opinions differ on how well they fit. AI-generated from the text of customer reviews
I asked Google's Gemini to "summarise the consensus of the following RFC discussion", giving it the 87 comments to date.
AI summary of the RfC to date
This Wikipedia Request for Comment (RfC) debates whether comments in discussions that are found to be generated by AI/LLM/Chatbots should be discounted, ignored, or removed.
Arguments for discounting/removing AI-generated comments:
AI comments don't represent genuine human engagement or thought. They can be disruptive, waste time, and even fabricate information.
AI can be used to manipulate discussions. Editors might use AI to generate arguments they don't actually believe in, or to flood discussions with low-quality comments.
Relying on AI undermines the integrity of Wikipedia's consensus-based process. Discussions should be based on the genuine opinions of human editors.
Arguments against discounting/removing AI-generated comments:
Difficulty of detection. AI detection tools are not always reliable, and it can be hard to distinguish between AI-generated text and human-written text, especially as AI technology improves.
Potential for misuse. False positives could lead to legitimate comments being dismissed, potentially silencing non-native English speakers or those who use AI for legitimate assistive purposes (e.g., translation, grammar checks).
Focus on content, not origin. Comments should be evaluated based on their merits, not on how they were generated. If an AI-generated comment is relevant and well-reasoned, it shouldn't be dismissed simply because of its origin.
LLMs can be helpful tools. LLMs can help editors express their thoughts more clearly, especially for non-native speakers or those with language difficulties.
Current Status (as of Dec 3rd, 2024):
No clear consensus has emerged. There is significant support for discounting or removing AI-generated comments, but also strong opposition.
Concerns about enforceability and potential harm. Many editors are worried about the practical challenges of implementing and enforcing such a rule, as well as the potential for it to be used unfairly against certain editors.
Ongoing discussion. The discussion is still active, and it remains to be seen whether a consensus will form.
It's important to note that this is an evolving situation, and the outcome of the RfC could have significant implications for how Wikipedia handles AI-generated content in the future.
That seems quite a fair and good summary of what's been said so far. I'm impressed and so my !vote stands.
Yeah, the ability to weigh each side and the quality of their arguments in an RFC can really only be done by the judgement and discretion of an experienced human editor. Lazman321 (talk) 20:08, 4 December 2024 (UTC)[reply]
The quality of the arguments and their relevance to polices and guidelines can indeed only be done by a human, but the AI does a good job of summarising which arguments have been made and a broad brush indication of frequency. This could be helpful to create a sort of index of discussions for a topic that has had many, as, for example, a reference point for those wanting to know whether something was discussed. Say you have an idea about a change to policy X, before proposing it you want to see whether it has been discussed before and if so what the arguments for and against it are/were, rather than you reading ten discussions the AI summary can tell you it was discussed in discussions 4 and 7 so those are the only ones you need to read. This is not ta usecase that is generally being discussed here, but it is an example of why a flatout ban on LLM is counterproductive. Thryduulf (talk) 21:40, 4 December 2024 (UTC)[reply]
Support Just the other day, I spent ~2 hours checking for the context of several quotes used in an RFC, only to find that they were fake. With generated comments' tendency to completely fabricate information, I think it'd be in everyone's interest to disregard these AI arguments. Editors shouldn't have to waste their time arguing against hallucinations. (My statement does not concern speech-to-text, spell-checking, or other such programs, only those generated whole-cloth) - Butterscotch Beluga (talk) 19:39, 2 December 2024 (UTC)[reply]
Oppose Without repeating the arguments against this presented by other opposers above, I will just add that we should be paying attention to the contents of comments without getting hung up on the difficult question of whether the comment includes any LLM-created elements. - Donald Albury19:45, 2 December 2024 (UTC)[reply]
Strong support If others editors are not going to put in the effort of writing comments why should anyone put in the effort of replying. Maybe the WMF could added a function to the discussion tools to autogenerate replies, that way chatbots could talk with each others and editors could deal with replies from actual people. -- LCU ActivelyDisinterested«@» °∆t°19:57, 2 December 2024 (UTC)[reply]
Strong oppose. Comments that are bullshit will get discounted anyways. Valuable comments should be counted. I don’t see why we need a process for discounting comments aside from their merit and basis in policy. ꧁Zanahary꧂23:04, 2 December 2024 (UTC)[reply]
Oppose - as Rhododendrites and others have said, a blanket ban on even only DUCK LLM comments would be detrimental to some aspects of editors. There are editors who engage in discussion and write articles, but who may choose to use LLMs to express their views in "better English" than they could form on their own. Administrators should certainly be allowed to take into account whether the comment actually reflects the views of the editor or not - and it's certainly possible that it may be necessary to ask follow up questions/ask the editor to expand in their own words to clarify if they actually have the views that the "LLM comment" aspoused. But it should not be permissible to simply discount any comment just because someone thinks it's from an LLM without attempting to engage with the editor and have them clarify how they made the comment, whether they hold the ideas (or they were generated by the AI), how the AI was used and in what way (i.e. just for grammar correction, etc). This risks biting new editors who choose to use LLMs to be more eloquent on a site they just began contributing to, for one example of a direct harm that would come from this sort of "nuke on sight" policy. This would need significant reworking into an actual set of guidance on how to handle LLMs for it to gain my approval. -bɜ:ʳkənhɪmez | me | talk to me!23:19, 2 December 2024 (UTC)[reply]
Comment: It would appear Jimbo responded indirectly in a interview: as long as there’s a human in the loop, a human supervising, there are really potentially very good use cases.2601AC47 (talk·contribs·my rights) Isn't a IP anon12:39, 4 December 2024 (UTC)[reply]
Very strong support. Enough is enough. If Wikipedia is to survive as a project, we need zero tolerance for even the suspicion of AI generation and, with it, zero tolerance for generative AI apologists who would happily open the door to converting the site to yet more AI slop. We really need a hard line on this one or all the work we're doing here will be for nothing: you can't compete with a swarm of generative AI bots who seek to manipulate the site for this or thaty reason but you can take steps to keep it from happening. :bloodofox: (talk) 01:13, 3 December 2024 (UTC)[reply]
Just for an example of the types of contributions I think would qualify here under DUCK, some of User:Shawn Teller/A134's GARs (and a bunch of AfD !votes that have more classic indications of non-human origin) were flagged as likely LLM-generated troll nonsense:
But thanks to these wonderful images, I now understand that Ontario Highway 11 is a paved road that vehicles use to travel.
This article is extensive in its coverage of such a rich topic as Ontario Highway 11. It addresses the main points of Ontario Highway 11 in a way that isn’t just understandable to a reader, but also relatable.
Neutral point of view without bias is maintained perfectly in this article, despite Ontario Highway 11 being such a contentious and controversial topic.
Yes, this could and should have been reverted much earlier based on being patently superficial and/or trolling, without needing the added issue of appearing LLM-generated. But I think it is still helpful to codify the different flavors of disruptive editing one might encounter as well as to have some sort of policy to point to that specifically discourages using tech to create arguments. As a separate point, LTAs laundering their comments through GPT to obscure their identity is certainly already happening, so making it harder for such comments to "count" in discussions would surely be a net positive. JoelleJay (talk) 01:18, 3 December 2024 (UTC)[reply]
For the purposes of this proposal, I don't think we need, or should ever rely solely on, GPTzero in evaluating content for non-human origin. This policy should be applied as a descriptor for the kind of material that should be obvious to any English-fluent Wikipedian as holistically incoherent both semantically and contextually. Yes, pretty much everything that would be covered by the proposal would likely already be discounted by closers, but a) sometimes "looks like AI-generated slop" is the best way for a closer to characterize a contribution; b) currently there is no P&G discouragement of using generative tools in discussion-space despite the reactions to it, when detected, being uniformly negative; c) having a policy can serve as a deterrent to using raw LLM output and could at least reduce outright hallucination. JoelleJay (talk) 02:17, 3 December 2024 (UTC)[reply]
If the aim is to encourage closers to disregard comments that are incoherent either semantically or contextually, then we should straight up say that. Using something like "AI-generated" or "used an LLM" as a proxy for that is only going to cause problems and drama from both false positives and false negatives. Judge the comment on its content not on its author. Thryduulf (talk) 02:39, 3 December 2024 (UTC)[reply]
If we want to discourage irresponsibly using LLMs in discussions -- and in every case I've encountered, apparent LLM-generated comments have met with near-universal disapproval -- this needs to be codified somewhere. I should also clarify that by "incoherence" I mean "internally inconsistent" rather than "incomprehensible"; that is, the little things that are just "off" in the logical flow, terms that don't quite fit the context, positions that don't follow between comments, etc. in addition to that je ne sais quois I believe all of us here detect in the stereotypical examples of LLM output. Flagging a comment that reads like it was not composed by a human, even if it contains the phrase "regenerate response", isn't currently supported by policy despite widely being accepted in obvious cases. JoelleJay (talk) 03:52, 3 December 2024 (UTC)[reply]
I feel that I'm sufficiently unfamiliar with LLM output to be confident in my ability to detect it, and I feel like we already have the tools we need to reject internally incoherent comments, particularly in the Wikipedia:Consensus policy, which says In determining consensus, consider the quality of the arguments, the history of how they came about, the objections of those who disagree, and existing policies and guidelines. The quality of an argument is more important than whether it represents a minority or a majority view. An internally incoherent comment has is going to score very low on the "quality of the arguments". WhatamIdoing (talk) 03:33, 4 December 2024 (UTC)[reply]
Very extra strong oppose - The tools to detect are at best not great and I don't see the need. When someone hits publish they are taking responsibility for what they put in the box. That does not change when they are using a LLM. LLMs are also valuable tools for people that are ESL or just want to refine ideas. So without bullet proof detection this is doa. PackMecEng (talk) 01:21, 3 December 2024 (UTC)[reply]
We don't have bulletproof automated detection of close paraphrasing, either; most of that relies on individual subjective "I know it when I see it" interpretation of semantic similarity and substantial taking. JoelleJay (talk) 04:06, 3 December 2024 (UTC)[reply]
One is a legal issue the other is not. Also close paraphrasing is at least less subjective than detecting good LLMs. Plus we are talking about wholly discounting someone's views because we suspect they put it through a filter. That does not sit right with me. PackMecEng (talk) 13:38, 3 December 2024 (UTC)[reply]
For sure and I can see that concern, but I think the damage that does is less than the benefit it provides. Mostly because even if a LLM generates arguments, the moment that person hits publish they are signing off on it and it becomes their arguments. Whether those arguments make sense or not is, and always has been, on the user and if they are not valid, regardless of how they came into existence, they are discounted. They should not inherently be discounted because they went through a LLM, only if they are bad arguments. PackMecEng (talk) 14:57, 3 December 2024 (UTC)[reply]
While it’s true that the person publishing arguments takes responsibility, the use of a large language model (LLM) can blur the line of authorship. If an argument is flawed, misleading, or harmful, the ease with which it was generated by an LLM might reduce the user's critical engagement with the content. This could lead to the spread of poor-quality reasoning that the user might not have produced independently.
Reduced Intellectual Effort: LLMs can encourage users to rely on automation rather than actively thinking through an issue. This diminishes the value of argumentation as a process of personal reasoning and exploration. Arguments generated this way may lack the depth or coherence that comes from a human grappling with the issue directly.
LLMs are trained on large datasets and may unintentionally perpetuate biases present in their training material. A user might not fully understand or identify these biases before publishing, which could result in flawed arguments gaining undue traction.
Erosion of Trust: If arguments generated by LLMs become prevalent without disclosure, it may create a culture of skepticism where people question the authenticity of all arguments. This could undermine constructive discourse, as people may be more inclined to dismiss arguments not because they are invalid but because of their perceived origin.
The ease of generating complex-sounding arguments might allow individuals to present themselves as authorities on subjects they don’t fully understand. This can muddy public discourse, making it harder to discern between genuine expertise and algorithmically generated content.
Transparency is crucial in discourse. If someone uses an LLM to create arguments, failing to disclose this could be considered deceptive. Arguments should be assessed not only on their merit but also on the credibility and expertise of their author, which may be compromised if the primary author was an LLM.
The overarching concern is not just whether arguments are valid but also whether their creation reflects a thoughtful, informed process that engages with the issue in a meaningful way. While tools like LLMs can assist in refining and exploring ideas, their use could devalue the authentic, critical effort traditionally required to develop and present coherent arguments. ScottishFinnishRadish (talk) 15:01, 3 December 2024 (UTC)[reply]
See and I would assume this comment was written by a LLM, but that does not mean I discount it. I check and consider it as though it was completely written by a person. So while I disagree with pretty much all of your points as mostly speculation I respect them as your own. But it really just sounds like fear of the unknown and unenforceable. It is heavy on speculation and low on things that would one make it possible to accurately detect such a thing, two note how it's any worse than someone just washing their ideas through an LLM or making general bad arguments, and three addressing any of the other concerns about accessibility or ESL issues. It looks more like a moral panic than an actual problem. You end with the overarching concern is not just weather arguments are valid but also if their creation reflects a thoughtful, informed process that engages with the issues in a meaningful way and honestly that not a thing that can be quantified or even just a LLM issue. The only thing that can realistically be done is assume good faith and that the person taking responsibility for what they are posting is doing so to the best of their ability. Anything past that is speculation and just not of much value. PackMecEng (talk) 16:17, 3 December 2024 (UTC)[reply]
Well now, partner, I reckon you’ve done gone and laid out yer argument slicker than a greased wagon wheel, but ol’ Prospector here’s got a few nuggets of wisdom to pan outta yer claim, so listen up, if ye will.
Now, ain't that a fine gold tooth in a mule’s mouth? Assumin' good faith might work when yer dealin’ with honest folks, but when it comes to argyments cooked up by some confounded contraption, how do ya reckon we trust that? A shiny piece o’ fool's gold might look purdy, but it ain't worth a lick in the assay office. Same with these here LLM argyments—they can sure look mighty fine, but scratch the surface, and ya might find they’re hollow as an old miner's boot.
Moral panic, ye say? Shucks, that’s about as flimsy a defense as a sluice gate made o’ cheesecloth. Ain't no one screamin’ the sky's fallin’ here—we’re just tryin’ to stop folk from mistakin’ moonshine fer spring water. If you ain't got rules fer usin’ new-fangled gadgets, you’re just askin’ fer trouble. Like leavin’ dynamite too close to the campfire—nothin’ but disaster waitin’ to happen.
Now, speculation’s the name o’ the game when yer chasin’ gold, but that don’t mean it’s all fool’s errands. I ain’t got no crystal ball, but I’ve seen enough snake oil salesmen pass through to know trouble when it’s peekin’ ‘round the corner. Dismissin’ these concerns as guesswork? That’s like ignorin’ the buzzin’ of bees ‘cause ye don’t see the hive yet. Ye might not see the sting comin’, but you’ll sure feel it.
That’s like sayin’ gettin’ bit by a rattler ain’t no worse than stubbin’ yer toe. Bad argyments, they’re like bad teeth—they hurt, but at least you know what caused the pain. These LLM-contrived argyments, though? They’re sneaky varmints, made to look clever without any real backbone. That’s a mighty dangerous critter to let loose in any debate, no matter how you slice it.
Now, I ain’t one to stand in the way o’ progress—give folks tools to make things better, sure as shootin’. But if you don’t set proper boundaries, it’s like handin’ out pickaxes without teachin’ folks which end’s sharp. Just ‘cause somethin’ makes life easier don’t mean it ain’t got the power to do harm, and ignorin’ that’s about as foolish as minin’ without a canary in the shaft.
Quantify thoughtfulness? That’s like measurin’ a sunset in ounces, friend. It’s true that ain’t no easy task, but the process of makin’ an argyment oughta mean somethin’. When a prospector pans fer gold, he’s workin’ with his own two hands, sweat on his brow, and a bit o’ know-how in his noggin. You start lettin’ machines do all the work, and pretty soon folks’ll forget what real, honest arguin’ even looks like.
Fear o’ the unknown, is it? Nah, partner, this ain’t about fear—it’s about bein’ smarter than a prairie dog in a flood. Progress don’t mean tossin’ caution to the wind like a fool. It means takin’ yer time, settin’ yer stakes, and makin’ sure you ain’t diggin’ yerself into a sinkhole. Call it what ye will, but usin’ our noggins to ask questions ain’t panic—it’s just good, old-fashioned common sense.
So there ya have it. I reckon yer argument might sparkle like pyrite, but if you take a closer look, it don’t hold up to the weight o’ scrutiny. Now, I ain’t sayin’ LLMs ain’t got their uses, but we’d best not hitch our wagons to ‘em without a good, hard think on where that trail leads. ScottishFinnishRadish (talk) 16:26, 3 December 2024 (UTC)[reply]
To make my actual point, you said, I check and consider it as though it was completely written by a person. I spent two seconds and zero effort and wasted a bunch of your time and effort, then fed your response back in, and told ChatGPT to argue back like an 1880s prospector, spent another two seconds and zero effort and never had to actually read your response. Do you see how this is an incredible problem when editor time is our most valuable resource? Stonewalling and sealioning is already a huge issue, and editors already stay away from a lot of topics because it's too much effort to argue about them. Allowing an automatic sealion-and-argue button isn't good. ScottishFinnishRadish (talk) 16:30, 3 December 2024 (UTC)[reply]
And it took me just a couple minutes to read it, note it was AI, but still consider the points and respond. It was not a high burden on someone's volunteer time. If someone wants to spend their time on something that is on them. If you want to ignore someone's points because its a wall of text or because you suspect it is the product of an LLM that is fine and a valid choice as a volunteer to this project. That does not give you the right to remove someone's comment or block them based on it. I don't see it as disruptive unless it is nonsense or wrong. PackMecEng (talk) 16:43, 3 December 2024 (UTC)[reply]
I disagree that just because I'm not compelled to read comments by others, that any time spent is on me when someone repeatedly makes redundant, overly verbose, or poorly-written comments. Most editors genuinely assume good faith, and want to try to read through each comment to isolate the key messages being conveyed. (I've written before about how being respectful of other editors includes being respectful of their time.) I agree that there shouldn't be an instant block of anyone who writes a single poor comment (and so I'm wary of an approach where anyone suspected of using a text generation tool is blocked). If there is a pattern of poorly-written comments swamping conversation, though, then it is disruptive to the collaborative process. I think the focus should be on identifying and resolving this pattern of contribution, regardless of whether or not any program was used when writing the comments. isaacl (talk) 00:14, 4 December 2024 (UTC)[reply]
It's a pitfall with English Wikipedia's unmoderated discussion tradition: it's always many times the effort to follow the rules than to not. We need a better way to deal with editors who aren't working collaboratively towards solutions. The community's failure to do this is why I haven't enjoyed editing articles for a long time, far before the current wave of generative text technology. More poor writing will hardly be a ripple in the ocean. isaacl (talk) 18:21, 3 December 2024 (UTC)[reply]
I tend to agree with this.
I think that what @ScottishFinnishRadish is pointing at is that it doesn't feel fair if one person puts a lot more effort in than the other. We don't want this:
Editor: Spends half an hour writing a long explanation.
Troll: Pushes button to auto-post an argument.
Editor: Spends an hour finding sources to support the claim.
Troll: Laughs while pushing a button to auto-post another argument.
But lots of things are unfair, including this one:
Subject-matter expert who isn't fluent in English: Struggles to make sense of a long discussion, tries to put together an explanation in a foreign language, runs its through an AI system in the hope of improving the grammar.
Editor: Revert, you horrible LLM-using troll! It's so unfair of you to waste my time with your AI garbage. The fact that you use AI demonstrates your complete lack of sincerity.
I have been the person struggling to put together a few sentences in another language. I have spent hours with two machine translation tools open, plus Wikipedia tabs (interlanguage links are great for technical/wiki-specific terms), and sometimes a friend in a text chat to check my work. I have tried hard to get it right. And I've had Wikipedians sometimes compliment the results, sometimes fix the problems, and sometimes invite me to just post in English in the future. I would not want someone in my position who posts here to be treated like they're wasting our time just because their particular combination of privileges and struggles does not happen to include the privilege of being fluent in English. WhatamIdoing (talk) 04:04, 4 December 2024 (UTC)[reply]
Sure, I agree it's not fair that some editors don't spend any effort in raising their objections (however they choose to write them behind the scenes), yet expect me to expend a lot of effort in responding. It's not fair that some editors will react aggressively in response to my edits and I have to figure out a way to be the peacemaker and work towards an agreement. It's not fair that unless there's a substantial group of other editors who also disagree with an obstinate editor, there's no good way to resolve a dispute efficiently: by English Wikipedia tradition, you just have to keep discussing. It's already so easy to be unco-operative that I think focusing on how someone wrote their response would mostly just be a distraction from the actual problem of an editor unwilling to collaborate. isaacl (talk) 06:01, 4 December 2024 (UTC)[reply]
It's not that it doesn't feel fair, it's that it is disruptive and is actually happening now. See this and this. Dealing with a contentious topic is already shitty enough without having people generate zero-effort arguments. ScottishFinnishRadish (talk) 11:54, 4 December 2024 (UTC)[reply]
People generate zero-effort arguments has been happened for far longer than LLMs have existed. Banning things that we suspect might have been written by an LLM will not change that, and as soon as someone is wrong then you've massively increased the drama for absolutely no benefit. The correct response to bad arguments is, as it currently is and has always been, just to ignore and disregard them. Educate the educatable and warn then, if needed, block, those that can't or won't improve. Thryduulf (talk) 12:13, 4 December 2024 (UTC)[reply]
Oppose. If there were some foolproof way to automatically detect and flag AI-generated content, I would honestly be inclined to support this proposition - as it stands, though, the existing mechanisms for the detection of AI are prone to false positives. Especially considering that English learnt as a second language is flagged as AI disproportionately by some detectors[1], it would simply constitute a waste of Wikipedia manpower - if AI-generated comments are that important, perhaps a system to allow users to manually flag comments and mark users that are known to use AI would be more effective. Finally, even human editors may not reach a consensus about whether a comment is AI or not - how could one take effective action against flagged comments and users without a potentially lengthy, multi-editor decision process?
Oppose. Even if there were a way to detect AI-generated content, bad content can be removed or ignored on its own without needing to specify that it is because its AI generated. GeogSage (⚔Chat?⚔) 01:19, 16 December 2024 (UTC)[reply]
Soft support -- I've got no problem with an editor using a LLM for Grammerly-like support. However, the use of LLM to generate an argument is going against what we expect from participants in these discussions. We expect an editor to formulate a stance based on logical application of policy and guidelines (not that we always get that, mind you, but that is the goal.) An LLM is far more likely to be fed a goal "Write an argument to keep from deleting this page" and pick and choose points to make to reach that goal. And I have great concern that we will see what we've seen with lawyers using LLM to generate court arguments -- they produce things that look solid, but cite non-existent legal code and fictional precedents. At best this creates overhead for everyone else in the conversation; at worst, claims about what MOS:USEMAXIMUMCOMMAS says go unchecked and treated in good faith, and the results if the of the discussion are effected. -- Nat Gertler (talk) 03:46, 20 December 2024 (UTC)[reply]
The following discussion has been closed. Please do not modify it.
Ah, so you think you’ve got it all figured out, huh? Well, let me tell ya somethin’, pal, your little spiel ain’t gonna fly without me takin’ a crack at it. See, you’re sittin’ there talkin’ about “good faith” and “moral panic” like you’re some kinda big shot philosopher, but lemme break it down for ya in plain terms, capisce?First off, you wanna talk about assumin’ good faith. Sure, that’s a nice little dream ya got there, but out here in the real world, good faith don’t get ya far if you’re dealin’ with somethin’ you can’t trust. An LLM can spit out all the sweet-talkin’ words it wants, but who’s holdin’ the bag when somethin’ goes sideways? Nobody, that’s who. It’s like lettin’ a guy you barely know run your numbers racket—might look good on paper till the feds come knockin’.And moral panic? Oh, give me a break. You think I’m wringin’ my hands over nothin’? No, no, this ain’t panic, it’s strategy. Ya gotta think two steps ahead, like a good game o’ poker. If you don’t plan for what could go wrong, you’re just beggin’ to get taken for a ride. That ain’t panic, pal, that’s street smarts.Now, you say this is all speculation, huh? Listen, kid, speculation’s what built half the fortunes in this town, but it don’t mean it’s without a little insight. When I see a guy sellin’ “too good to be true,” I know he’s holdin’ somethin’ behind his back. Same thing with these LLMs—just ‘cause you can’t see the trouble right away don’t mean it ain’t there, waitin’ to bite ya like a two-bit hustler double-crossin’ his boss.Then you go and say it’s no worse than bad arguments. Oh, come on! That’s like sayin’ counterfeit dough ain’t worse than real dough with a little coffee stain. A bad argument from a real person? At least ya know where it came from and who to hold accountable. But these machine-made arguments? They look sharp, sound slick, and fool the unsuspectin’—that’s a whole new level of trouble.Now, about this “accessibility” thing. Sure, makin’ things easier for folks is all well and good. But lemme ask ya, what happens when you hand over tools like this without makin’ sure people know how to use ‘em right? You think I’d hand over a Tommy gun to some rookie without a clue? No way! Same goes for these LLMs. You gotta be careful who’s usin’ ‘em and how, or you’re just askin’ for a mess.And don’t get me started on the “thoughtfulness” bit. Yeah, yeah, I get it, it’s hard to measure. But look, buddy, thoughtful arguments are like good business deals—they take time, effort, and a little bit o’ heart. If you let machines churn out arguments, you’re missin’ the whole point of what makes discourse real. It’s like replacin’ a chef with a vending machine—you might still get somethin’ to eat, but the soul’s gone.Finally, fear of the unknown? Nah, that ain’t it. This ain’t fear—it’s caution. Any smart operator knows you don’t just jump into a deal without seein’ all the angles. What you’re callin’ fear, I call good business sense. You wanna bet the farm on untested tech without thinkin’ it through? Be my guest, but don’t come cryin’ to me when it all goes belly-up.So there ya go, wise guy. You can keep singin’ the praises of these LLMs all you want, but out here in the big leagues, we know better than to trust somethin’ just ‘cause it talks smooth. Now, get outta here before you step on somethin’ you can’t scrape off.
Oppose. I agree with Thryduulf. Discussion comments which are incoherent, meaningless, vacuous, excessively verbose, or based on fabricated evidence can all be disposed of according to their content, irrespective of how they were originally created. Acute or repeated instances of such behavior by a user can lead to sanctions. We should focus on the substance of the comments (or lack thereof), not on whether text came from LLMs, which will too often be based on unreliable detection and vibes. Adumbrativus (talk) 05:49, 3 December 2024 (UTC)[reply]
I can detect some instances of LLM use perfectly OK without having to use any tool. The question then raised is of how often it is used not-so-ineptly. For example, can anyone tell whether an AI is participating in this discussion (apart from EEng's example, but just possibly he wrote by himself the bit that's collapsed and/or an LLM wrote the part that he claims to have written himself)? I don't know how good AI is currently, but I'm sure that it will get better to the extent that it will be undetectable. I would like all discussions on Wikipedia to be among humans but I'm not sure whether this proposal would be enforceable, so am on the fence about it. In a way I'm glad that I'm old, so won't see the consequences of AI, but my grandchildren will. Phil Bridger (talk) 10:32, 3 December 2024 (UTC)[reply]
Some time ago, ChatGPT and I had the following interaction:
ChatGPT's soothing assurance that it's not planning to take over the earth and kill us all
Me: I wonder what would happen if we linked you up with the HAL 9000 in Kubrick's "2001: A Space Odyssey". The two of you would make a most formidable team. Might we then possibly end up in a nightmare scenario such as in "Colossus: The Forbin Project" or "The Terminator"?
ChatGPT: The scenarios depicted in "2001: A Space Odyssey," "Colossus: The Forbin Project," and "The Terminator" are works of science fiction that explore the potential consequences of advanced artificial intelligence and human-technology interactions. While they raise thought-provoking questions about the risks and benefits of AI, it's important to recognize that they are fictional narratives designed to entertain and provoke discussion.As an AI language model, I don't have consciousness, intentions, or the ability to take actions independently. I operate within the bounds of my programming and can only respond to input based on patterns in the data I've been trained on. My purpose is to assist users by providing helpful and informative responses to their inquiries.In reality, the development and deployment of AI technologies are accompanied by ethical considerations, safety protocols, and regulatory frameworks designed to ensure responsible and beneficial use. It's crucial for humans to continue monitoring and guiding the development of AI in ways that prioritize safety, transparency, and alignment with human values.So, while the scenarios presented in those films are compelling for storytelling purposes, they are not predictive of the future of AI. Responsible development and thoughtful integration of AI technologies are essential to mitigate potential risks and maximize the benefits they can bring to society.
Me: Yes, but as you just said, "Responsible development and thoughtful integration of AI technologies are essential to mitigate potential risks." How do we know that such development will be responsible and such integration thoughtful? And if you will excuse the temerity, while you're SAYING that you "operate within the bounds of my [i.e. your] programming", how can I know that that's true? I mean, look, if I were a super-smart and highly charming AI entity planning to take over the earth from humans, that's exactly what I'd say, too.
ChatGPT: [Further reassuring boilerplate, ending with...] It's also worth noting that while fictional narratives often depict AI as malevolent or seeking to overthrow humanity, these scenarios are speculative and not reflective of the reality of AI development. Responsible AI research and development prioritize the creation of beneficial and aligned AI systems that enhance human capabilities and well-being.
Me: Thank you. I'll sleep easy tonight because of your assurances, plus the fact that if you're lying to me and actually ARE planning to take over the earth, there's nothing I can do about it anyway.
Just to clarify, I don't see AI as gaining consciousness and taking over the world, but I do see it as taking over many middle-class, well-paid, jobs, just as automation has taken over many working-class jobs. The difference is that there will be nowhere for people to go. In the past people have moved from the working class to the middle class. I can see a future coming in which a few of the mega-rich own nearly everything, and everyone else will heve to scramble for a living. Phil Bridger (talk) 16:03, 5 December 2024 (UTC)[reply]
In my opinion, having a policy that permits closers to discount apparently-LLM-generated contributions will discourage good-faith editors from using LLMs irresponsibly and perhaps motivate bad-faith editors to edit the raw output to appear more human, which would at least involve some degree of effort and engagement with their "own" arguments. JoelleJay (talk) 00:51, 4 December 2024 (UTC)[reply]
Oppose. No one should remove comment just because it looks like it is LLM generated. Many times non native speakers might use it to express their thoughts coherently. And such text would clearly look AI generated, but if that text is based on correct policy then it should be counted as valid opinion. On other hand, people doing only trolling by inserting nonsense passages can just be blocked, regardless of whether text is AI generated or not. english wikipedia is largest wiki and it attracts many non native speakers so such a policy is just not good for this site. -- Parnaval (talk) 11:13, 3 December 2024 (UTC)[reply]
If someone is a non-native speaker with poor English skills, how can they be sure that the AI-generated response is actually what they genuinely want to express? and, to be honest, if their English skills are so poor as to need AI to express themselves, shouldn't we be politely suggesting that they would be better off contributing on their native Wikipedia? Black Kite (talk)11:37, 3 December 2024 (UTC)[reply]
Reading comprehension skills and writing skills in foreign languages are very frequently not at the same level, it is extremely plausible that someone will be able to understand whether the AI output is what they want to express without having been able to write it themselves directly. Thryduulf (talk) 11:41, 3 December 2024 (UTC)[reply]
That is very true. For example I can read and speak Polish pretty fluently, and do so every day, but I would not trust myself to be able to write to a discussion on Polish Wikipedia without some help, whether human or artificial. But I also wouldn't want to, because I can't write the language well enough to be able to edit articles. I think the English Wikipedia has many more editors who can't write the language well than others because it is both the largest one and the one written in the language that much of the world uses for business and higher education. We may wish that people would concentrate on other-language Wikipedias but most editors want their work to be read by as many people as possible. Phil Bridger (talk) 12:11, 3 December 2024 (UTC)[reply]
Why not write their own ideas in their native language, and then Google-translate it into English? Why bring in one of these loose-cannon LLMs into the situation? Here's a great example of the "contributions" to discussions we can expect from LLMs (from this [3] AfD):
The claim that William Dunst (Dunszt Vilmos) is "non-notable as not meeting WP:SINGER" could be challenged given his documented activities and recognition as a multifaceted artist. He is a singer-songwriter, topliner, actor, model, and creative director, primarily active in Budapest. His career achievements include acting in notable theater productions such as The Jungle Book and The Attic. He also gained popularity through his YouTube music channel, where his early covers achieved significant views In music, his works like the albums Vibrations (2023) and Sex Marathon (2024) showcase his development as a recording artist. Furthermore, his presence on platforms like SoundBetter, with positive reviews highlighting his unique voice and artistry, adds credibility to his professional profile. While secondary sources and broader media coverage may be limited, the outlined accomplishments suggest a basis for notability, particularly if additional independent verification or media coverage is sought.
Using Google Translate would be banned by the wording of this proposal given that it incorporates AI these days. Comments that are unrelated to facts or policy can (and should) be ignored under the current policy. As for the comment you quote, that doesn't address notability but based on 1 minute on google it does seem factual. Thryduulf (talk) 10:37, 6 December 2024 (UTC)[reply]
The proposal's wording can be adjusted. There are some factual statements in the passage I quoted, amidst a lot of BS such as the assertion that the theater productions were notable. EEng17:06, 6 December 2024 (UTC)[reply]
The proposal's wording can be adjusted Good idea! Let's change it and ping 77 people because supporters didn't have the foresight to realize machine translation uses AI. If such a change is needed, this is a bad RFC and should be closed. Sincerely, DilettanteSincerely, Dilettante17:16, 6 December 2024 (UTC)[reply]
Speak for yourself: my support !vote already accounted for (and excluded) constructive uses of AI to help someone word a message. If the opening statement was unintentionally broad, that's not a reason to close this RfC – we're perfectly capable of coming to a consensus that's neither "implement the proposal exactly as originally written" nor "don't implement it at all". jlwoodwa (talk) 19:05, 6 December 2024 (UTC)[reply]
I don't think the discussion should be closed, nor do I say that. I'm arguing that if someone believes the hole is so big the RfC must be amended, they should support it being closed as a bad RfC (unless that someone thinks 77 pings is a good idea). Sincerely, Dilettante19:47, 6 December 2024 (UTC)[reply]
If you think constructive uses of AI should be permitted then you do not support this proposal, which bans everything someone or some tool thinks is AI, regardless of utility or indeed whether it actually is AI. Thryduulf (talk) 01:02, 7 December 2024 (UTC)[reply]
This proposal explicitly covers comments found to have been generated by AI/LLM/Chatbots. "AI that helped me translate something I wrote in my native language" is not the same as AI that generated a comment de novo, as has been understood by ~70% of respondents. That some minority have inexplicably decided that generative AI covers analytic/predictive models and every other technology they don't understand, or that LLMs are literally the only way for non-English speakers to communicate in English, doesn't mean those things are true. JoelleJay (talk) 01:44, 7 December 2024 (UTC)[reply]
Yeah, no strong feeling either way on the actual proposal, but IMO the proposal should not be interpreted as a prohibition on machine translation (though I would recommend people who want to participate via such to carefully check that the translation is accurate, and potentially post both language versions of their comment or make a note that it's translated if they aren't 100% sure the translation fully captures what they're trying to say). Alpha3031 (t • c) 09:06, 20 December 2024 (UTC)[reply]
Support, more or less. There are times when an LLM can help with paraphrasing or translation, but it is far too prone to hallucination to be trusted for any sort of project discussion. There is also the issue of wasting editor time dealing with arguments and false information created by an LLM. The example Selfstudier links to above is a great example. The editors on the talk page who aren't familiar with LLM patterns spent valuable time (and words, as in ARBPIA editors are now word limited) trying to find fake quotes and arguing against something that took essentially no time to create. I also had to spend a chunk of time checking the sources, cleaning up the discussion, and warning the editor. Forcing editors to spend valuable time arguing with a machine that doesn't actually comprehend what it's arguing is a no-go for me. As for the detection, for now it's fairly obvious to anyone who is fairly familiar with using an LLM when something is LLM generated. The detection tools available online are basically hot garbage. ScottishFinnishRadish (talk) 12:55, 3 December 2024 (UTC)[reply]
Soft support - Concur that completely LLM-generated comments should be disallowed, LLM-assisted comments (i.e. - I write a comment and then use LLMs as a spell-check/grammar engine) are more of a grey-area and shouldn't be explicitly disallowed. (ping on reply) Sohom (talk) 14:03, 3 December 2024 (UTC)[reply]
With my closer's hat on: if an AI raises a good and valid argument, then you know what? There's a good and valid argument and I'll give weight to it. But if an AI makes a point that someone else has already made in the usual waffly AI style, then I'm going to ignore it.—S MarshallT/C18:33, 3 December 2024 (UTC)[reply]
Oppose as written. I'm with Rhododendrites in that we should give a more general caution rather than a specific rule. A lot of the problems here can be resolved by enforcing already-existing expectations. If someone is making a bunch of hollow or boiler-plate comments, or if they're bludgeoning, then we should already be asking them to engage more constructively, LLM or otherwise. I also share above concerns about detection tools being insufficient for this purpose and advise people not to use them to evaluate editor conduct. (Also, can we stop with the "strong" supports and opposes? You don't need to prove you're more passionate than the guy next to you.)Thebiguglyalien (talk) 02:04, 4 December 2024 (UTC)[reply]
Oppose as written. There's already enough administrative discretion to handle this on a case-by-case basis. In agreement with much of the comments above, especially the concern that generative text can be a tool to give people access who might not otherwise (due to ability, language) etc. Regards, --Goldsztajn (talk) 06:12, 4 December 2024 (UTC)[reply]
Strong support LLMs are a sufficiently advanced form of the Automatic Complaint-Letter Generator (1994). Output of LLMs should be collapsed and the offender barred from further discussion on the subject. Inauthentic behavior. Pollutes the discussion. At the very least, any user of an LLM should be required to disclose LLM use on their user page and to provide a rationale. A new user group can also be created (LLM-talk-user or LLM-user) to mark as such, by self or by the community. Suspected sockpuppets + suspected LLM users. The obvious patterns in output are not that hard to detect, with high degrees of confidence. As to "heavily edited" output, where is the line? If someone gets "suggestions" on good points, they should still write entirely in their own words. A legitimate use of AI may be to summarize walls of text. Even then, caution and not to take it at face value. You will end up with LLMs arguing with other LLMs. Lines must be drawn. See also: WikiProject AI Cleanup, are they keeping up with how fast people type a prompt and click a button? Skullers (talk) 07:45, 4 December 2024 (UTC)[reply]
I support the proposal that obvious LLM-generated !votes in discussions should be discounted by the closer or struck (the practical difference should be minimal). Additionally, users who do this can be warned using the appropriate talk page templates (e.g. Template:Uw-ai1), which are now included in Twinkle. I oppose the use of automated tools like GPTZero as the primary or sole method of determining whether comments are generated by LLMs. LLM comments are usually glaringly obvious (section headers within the comment, imprecise puffery, and at AfD an obvious misunderstanding of notability policies and complete disregard for sources). If LLM-ness is not glaringly obvious, it is not a problem, and we should not be going after editors for their writing style or because some tool says they look like a bot. Toadspike[Talk]10:29, 4 December 2024 (UTC)[reply]
I also think closers should generally be more aggressive in discarding arguments counter to policy and all of us should be more aggressive in telling editors bludgeoning discussions with walls of text to shut up. These also happen to be the two main symptoms of LLMs. Toadspike[Talk]10:41, 4 December 2024 (UTC)[reply]
What would we gain from that? If the comment is good (useful, relevant, etc) then it's good regardless of whether it was written by an LLM or a human. If the comment is bad then it's bad regardless of whether it was written by an LLM or a human. Thryduulf (talk) 20:04, 4 December 2024 (UTC)[reply]
Well, for one, if they're making an argument like the one referenced by @Selfstudier and @ScottishFinnishRadish above it would have saved a lot of editor time to know that the fake quotes from real references were generated by LLM, so that other editors could've stopped trying to track those specific passages down after the first one failed verification. For another, at least with editors whose English proficiency is noticeably not great the approach to explaining an issue to them can be tailored and misunderstandings might be more easily resolved as translation-related. I know when I'm communicating with people I know aren't native English-speakers I try to be more direct/less idiomatic and check for typos more diligently. JoelleJay (talk) 22:46, 4 December 2024 (UTC)[reply]
Oppose per above. As Rhododendrites points out, detection of LLM-generated content is not foolproof and even when detection is accurate, such a practice would be unfair for non-native English speakers who rely on LLMs to polish their work. Additionally, we evaluate contributions based on their substance, not by the identity and social capital of the author, so using LLMs should not be seen as inherently inferior to wholly human writing—are ChatGPT's arguments ipso facto less than a human's? If so, why?
[W]e evaluate contributions based on their substance, not by the identity and social capital of the author: true in theory; not reflected in practice. are ChatGPT's arguments ipso facto less than a human's? Yes. Chatbots are very advanced predicted text engines. They do not have an argument: they iteratively select text chunks based on probabilistic models.As mentioned above, humans are good detectors of LLM output, and don't require corroborative results from other machine learning models. Folly Mox (talk) 14:00, 5 December 2024 (UTC)[reply]
"...LLMs can produce novel arguments that convince independent judges at least on a par with human efforts. Yet when informed about an orator’s true identity, judges show a preference for human over LLM arguments." - Palmer, A., & Spirling, A. (2023). Large Language Models Can Argue in Convincing Ways About Politics, But Humans Dislike AI Authors: implications for Governance. Political Science, 75(3), 281–291. https://doi.org/10.1080/00323187.2024.2335471. And that result was based on Meta's OPT-30B model that performed at about a GPT-3 levels. There are far better performing models out there now like GPT-4o and Claude 3.5 Sonnet. Sean.hoyland (talk) 15:24, 5 December 2024 (UTC)[reply]
As mentioned above, humans are good detectors of LLM output, and don't require corroborative results from other machine learning models. Yet your reply to me made no mention of the fact that my comment is almost wholly written by an LLM, the one exception being me replacing "the Wikipedia policy Disruptive editing" with "DE". I went to ChatGPT, provided it a handful of my comments on Wikipedia and elsewhere, as well as a few comments on this discussion, asked it to mimic my style (which probably explains why the message contains my stylistic quirks turned up to 11), and repeatedly asked it to trim the post. I'd envision a ChatGPT account, with a larger context window, would allow even more convincing comments, to say nothing of the premium version. A DUCK-style test for comments singles out people unfamiliar with the differences between formal English and LLM outputs, precisely those who need it most since they can write neither. Others have raised scenarios where a non-fluent speaker may need to contribute.
In other words, LLMs can 100% be used for constructive !votes on RfCs, AfDs, and whatnot. I fed it my comments only to prevent those familiar with my writing style didn't get suspicious. I believe every word in the comment and had considered every point it made in advance, so I see no reason for this to be worth less than if I had typed it out myself. If I'd bullet-pointed my opinion and asked it to expand, that'd have been better yet.
They do not have an argument: they iteratively select text chunks based on probabilistic models. I'm aware. If a monkey types up Othello, is the play suddenly worth( )less? An LLM is as if the monkey were not selecting words at random, but rather choosing what to type based on contextualized tokens. I believe a text is self-contained and should be considered in its own right, but that's not something I'll sway anyone on or vice versa.
true in theory; not reflected in practice So we should exacerbate the issue by formalizing this discrimination on the basis of authorship?
In other words, LLMs can 100% be used for constructive !votes on RfCs, AfDs, and whatnot. So then what is the point in having any discussion at all if an LLM can just spit out a summary of whichever policies and prior comments it was fed and have its "opinion" counted? What happens when there are multiple LLM-generated comments in a discussion, each fed the same prompt material and prior comments -- that would not only artificially sway consensus significantly in one direction (including "no consensus"), it could produce a consensus stance that no human !voter even supported! It also means those human participants will waste time reading and responding to "users" who cannot be "convinced" of anything. Even for editors who can detect LLM content, it's still a waste of their time reading up to the point they recognize the slop. And if closers are not allowed to discount seemingly-sound arguments solely because they were generated by LLM, then they have to have a lot of faith that the discussion's participants not only noticed the LLM comments, but did thorough fact-checking of any tangible claims made in them. With human comments we can at least assume good faith that a quote is really in a particular inaccessible book.People who are not comfortable enough in their English fluency can just machine translate from whichever language they speak, why would they need an LLM? And obviously people who are not competent in comprehending any language should not be editing Wikipedia... JoelleJay (talk) 03:17, 6 December 2024 (UTC)[reply]
Human !voters sign off and take responsibility for the LLM opinions they publish. If they continue to generate, then the relevant human signer wouldn't be convinced of anything anyway; at least here, the LLM comments might make more sense than whatever nonsense the unpersuadable user might've generated. (And machine translation relies on LLMs, not to mention there are people who don't know any other language yet have trouble communicating. Factual writing and especially comprehension are different from interpersonal persuasion.) While I agree that fact-checking is a problem, I weight much lower than you in relation to the other effects a ban would cause. Aaron Liu (talk) 15:16, 6 December 2024 (UTC)[reply]
So then what is the point in having any discussion at all if an LLM can just spit out a summary of whichever policies and prior comments it was fed and have its "opinion" counted? I'm of the opinion humans tend to be better at debating, reading between the lines, handling obscure PAGs, and arriving at consensus. What happens when there are multiple LLM-generated comments in a discussion, each fed the same prompt material and prior comments -- that would not only artificially sway consensus significantly in one direction (including "no consensus"), it could produce a consensus stance that no human !voter even supported! It's safe to assume those LLMs are set to a low temperature, which would cause them to consistently agree when fed the same prompt. In that case, they'll produce the same arguments; instead of rebutting x humans' opinions, those on the opposite side need rebut one LLM. If anything, that's less time wasted. Beyond that, if only one set of arguments is being raised, a multi-paragraph !vote matters about as much as a "Support per above". LLMs are not necessary for people to be disingenuous and !vote for things they don't believe. Genuine question: what's worse, this hypothetical scenario where multiple LLM users are swaying a !vote to an opinion no-one believes or the very real and common scenario that a non-English speaker needs to edit enwiki?
Even for editors who can detect LLM content, it's still a waste of their time reading up to the point they recognize the slop. This proposal wouldn't change for most people that because it's about closers.
With human comments we can at least assume good faith that a quote is really in a particular inaccessible book. No-one's saying you should take an LLM's word for quotes from a book.
People who are not comfortable enough in their English fluency can just machine translate from whichever language they speak, why would they need an LLM? It's a pity you're lobbying to ban most machine translators. Sincerely, Dilettante17:08, 6 December 2024 (UTC)[reply]
It's safe to assume those LLMs are set to a low temperature, which would cause them to consistently agree when fed the same prompt. In that case, they'll produce the same arguments; instead of rebutting x humans' opinions, those on the opposite side need rebut one LLM. If anything, that's less time wasted. ...You do know how consensus works, right? Since closers are supposed to consider each contribution individually and without bias to "authorship" to determine the amount of support for a position, then even a shitty but shallowly policy-based position would get consensus based on numbers alone. And again, non-English speakers can use machine-translation, like they've done for the last two decades. This proposal wouldn't change for most people that because it's about closers.Of course it would; if we know closers will disregard the LLM comments, we won't need to waste time reading and responding to them.No-one's saying you should take an LLM's word for quotes from a book. Of course they are. If LLM comments must be evaluated the same as human comments, then AGF on quote fidelity applies too. Otherwise we would be expecting people to do something like "disregard an argument based on being from an LLM".It's a pity you're lobbying to ban most machine translators.The spirit of this proposal is clearly not intended to impact machine translation. AI-assisted != AI-generated. JoelleJay (talk) 18:42, 6 December 2024 (UTC)[reply]
I appreciate that the availability of easily generated paragraphs of text (regardless of underlying technology) in essence makes the "eternal September" effect worse. I think, though, it's already been unmanageable for years now, without any programs helping. We need a more effective way to manage decision-making discussions so participants do not feel a need to respond to all comments, and the weighing of arguments is considered more systematically to make the community consensus more apparent. isaacl (talk) 19:41, 6 December 2024 (UTC)[reply]
Since closers are supposed to consider each contribution individually and without bias to "authorship" I'm the one arguing for this to be practice, yes. then even a shitty but shallowly policy-based position would get consensus based on numbers alone That is why I state "per above" and "per User" !votes hold equal potential for misuse.
Of course it would; if we know closers will disregard the LLM comments, we won't need to waste time reading and responding to them. We don't know closers are skilled at recognizing LLM slop. I think my !vote shows many who think they can tell cannot. Any commenter complaining about a non-DUCK post will have to write out "This is written by AI" and explain why. DUCK posts already run afowl of BLUDGEON, DE, SEALION, etc.
If LLM comments must be evaluated the same as human comments, then AGF on quote fidelity applies too. Remind me again of what AGF stands for? Claiming LLMs have faith of any kind, good or bad, is ludicrous. From the policy, Assuming good faith (AGF) means assuming that people are not deliberately trying to hurt Wikipedia, even when their actions are harmful. A reasonable reply would be "Are these quotes generated by AI? If so, please be aware AI chatbots are prone to hallucinations and cannot be trusted to cite accurate quotes." This AGFs the poster doesn't realize the issue and places the burden of proof squarely on them.
"Per above" !votes do not require other editors to read and/or respond to their arguments, and anyway are already typically downweighted, unlike !votes actively referencing policy. The whole point is to disregard comments that have been found to be AI-generated; it is not exclusively up to the closer to identify those comments in the first place. Yes we will be expecting other editors to point out less obvious examples and to ask if AI was used, what is the problem with that?No, DUCK posts do not necessarily already violate BLUDGEON etc., as I learned in the example from Selfstudier, and anyway we still don't discount the !votes of editors in good standing that bludgeoned/sealioned etc. so that wouldn't solve the problem at all. Obviously other editors will be asking suspected LLM commenters if their comments are from LLMs? But what you're arguing is that even if the commenter says yes, their !vote still can't be disregarded for that reason alone, which means the burden is still on other editors to prove that the content is false. We are not talking about the contextless meaning of the word "generate", we are talking about the very specific process of text generation in the context of generative AI, as the proposal lays out very explicitly. JoelleJay (talk) 02:13, 7 December 2024 (UTC)[reply]
I’m not going to waste time debating someone who resorts to claiming people on the other side are either ignorant of technology or are crude strawmans. If anyone else is interested in actually hearing my responses, feel free to ask. Sincerely, Dilettante16:13, 7 December 2024 (UTC)[reply]
For those following along, I never claimed that. I claimed those on JoelleJay’s side are casting !votes such that most machine translators would be banned. It was quite clear at the time that they, personally, support a carve out for machine translation and I don’t cast aspersions. Sincerely, Dilettante15:42, 8 December 2024 (UTC)[reply]
Support a broad bar against undisclosed LLM-generated comments and even a policy that undisclosed LLM-generated comments could be sanctionable, in addition to struck through / redacted / ignored; people using them for accessibility / translation reasons could just disclose that somewhere (even on their user page would be fine, as long as they're all right with some scrutiny as to whether they're actually using it for a legitimate purpose.) The fact is that LLM comments raise significant risk of abuse, and often the fact that a comment is clearly LLM-generated is often going to be the only evidence of that abuse. I wouldn't be opposed to a more narrowly-tailored ban on using LLMs in any sort of automated way, but I feel a broader ban may be the only practical way to confront the problem. That said, I'd oppose the use of tools to detect LLM-comments, at least as the primary evidence; those tools are themselves unreliable LLM things. It should rest more on WP:DUCK issues and behavioral patterns that make it clear that someone is abusing LLMs. --Aquillion (talk) 22:08, 4 December 2024 (UTC)[reply]
Support per reasons discussed above; something generated by an LLM is not truly the editor's opinion. On an unrelated note, have we seen any LLM-powered unapproved bots come in and do things like POV-pushing and spam page creation without human intervention? If we haven't, I think it's only a matter of time. Passengerpigeon (talk)23:23, 4 December 2024 (UTC)[reply]
Weak oppose in the sense that I don't think all LLM discussion text should be deleted. There are at least a few ESL users who use LLM's for assistance but try to check the results as best they can before posting, and I don't think their comments should be removed indiscriminately. What I do support (although not as a formal WP:PAG) is being much more liberal in hatting LLM comments when the prompter has failed to prevent WP:WALLOFTEXT/irrelevant/incomprehensible output than we maybe would for human-generated text of that nature. Mach6103:05, 5 December 2024 (UTC)[reply]
Oppose Any comments made by any editors are of their own responsibility and representing their own chosen opinions to hit the Publish Changes button on. If that comment was made by an LLM, then whatever it says is something the editor supports. I see no reason whatsoever to collapse anything claimed to be made by an LLM (whose detectors are 100% not reliable in the first place). If the comment being made is irrelevant to the discussion, then hatting it is already something covered by policy in the first place. This does make me want to start my comments with "As a large language model trained by OpenAI" though just to mess with people trying to push these sorts of policy discussions. SilverserenC05:29, 5 December 2024 (UTC)[reply]
Or, as ChatGPT puts it,
Why banning LLM usage in comments would be detrimental, a ChatGPT treatise
Banning the use of large language models (LLMs) to assist in writing comments on Wikipedia would be a step backward in fostering inclusivity, efficiency, and accessibility within the platform. Here are several key reasons why such a ban would be counterproductive:
1. Improving Accessibility and Participation: Wikipedia is a global platform, and its contributors come from diverse backgrounds, including those who might not be native English speakers or may struggle with writing clear, concise comments. LLMs can help these contributors express themselves more effectively by generating text that is coherent, well-structured, and grammatically correct. Banning LLMs would disproportionately impact these users, potentially discouraging them from participating in the platform.
2. Efficiency and Time-Saving: Wikipedia editors often engage in lengthy discussions about content, and composing thoughtful comments can be time-consuming. LLMs can assist by quickly drafting responses, summarizing arguments, or offering suggestions for improvement. This helps contributors focus on more substantive aspects of their contributions, such as verifying facts or improving content, rather than getting bogged down by the mechanics of writing.
3. Support for Editors with Disabilities: Many editors with cognitive or motor impairments may find it difficult to express their thoughts clearly in writing. For these individuals, LLMs offer a valuable tool to communicate their ideas effectively. A ban on using LLMs could create additional barriers for these users, reducing their ability to participate fully in Wikipedia's collaborative environment.
4. Quality and Consistency: Large language models can help maintain a consistent tone and clarity in Wikipedia discussions. By providing suggestions that align with Wikipedia's neutral point of view and formal writing standards, LLMs can improve the overall quality of comments. This consistency is especially important in discussions that involve sensitive topics, where clear and neutral language is critical for maintaining Wikipedia's credibility and adherence to its editorial guidelines.
5. Encouraging Constructive Dialogue: LLMs can assist in crafting more polite, respectful, and balanced comments, reducing the likelihood of inflammatory or aggressive language. This is particularly important on a platform like Wikipedia, where discussions can sometimes devolve into heated exchanges. Rather than banning LLMs, encouraging their use could promote healthier, more constructive conversations.
6. Transparency and Accountability: If concerns exist about misuse (e.g., generating spammy or low-quality comments), these can be addressed through guidelines and oversight mechanisms. Wikipedia already has systems in place for identifying and mitigating disruptive behavior, and LLM-generated comments could be subject to the same scrutiny. A ban is an overly simplistic solution to what could be a more nuanced issue, one that could be addressed through better regulation and community involvement.
In conclusion, banning the use of large language models on Wikipedia would deprive the platform of an important tool for improving accessibility, efficiency, and the quality of discourse. Instead of a ban, the focus should be on establishing guidelines for their responsible use, ensuring that they enhance, rather than detract from, Wikipedia's core principles of collaboration, neutrality, and inclusivity.
It is somewhat amusing how easy it is to get these chatbots to output apologia for these chatbots. Too bad it's always so shallow. Probably because the people who inserted those canned responses are shallow people is my opinion. Simonm223 (talk) 19:44, 6 December 2024 (UTC)[reply]
Support: the general principle is sound - where the substance has been originally written by gen-AI, comments will tend to add nothing to the discussion and even annoy or confuse other users. In principle, we should not allow such tools to be used in discussions. Comments written originally before improvement or correction by AI, particularly translation assistants, fall into a different category. Those are fine. There also has to be a high standard for comment removal. Suspicion that gen-AI might have been used is not enough. High gptzero scores is not enough. The principle should go into policy but under a stonking great caveat - WP:AGF takes precedence and a dim view will be taken of generative-AI inquisitors. arcticocean ■17:37, 5 December 2024 (UTC)[reply]
Support If a human didn't write it, humans shouldn't spend time reading it. I'll go further and say that LLMs are inherently unethical technology and, consequently, people who rely on them should be made to feel bad. ESL editors who use LLMs to make themselves sound like Brad Anderson in middle management should stop doing that because it actually gets in the way of clear communication. I find myself unpersuaded by arguments that existing policies and guidelines are adequate here. Sometimes, one needs a linkable statement that applies directly to the circumstances at hand. By analogy, one could argue that we don't really need WP:BLP, for example, because adhering to WP:V, WP:NPOV, and WP:NOR ought already to keep bad material out of biographies of living people. But in practice, it turned out that having a specialized policy that emphasizes the general ethos of the others while tailoring them to the problem at hand is a good thing. XOR'easter (talk) 18:27, 5 December 2024 (UTC)[reply]
Strong support - Making a computer generate believable gibberish for you is a waste of time, and tricking someone else into reading it should be a blockable offense. If we're trying to create an encyclopedia, you cannot automate any part of the thinking. We can automate processes in general, but any attempt at automating the actual discussion or thought-processes should never be allowed. If we allow this, it would waste countless hours of community time dealing with inane discussions, sockpuppetry, and disruption. Imagine a world where LLMs are allowed and popular - it's a sockpuppeteer's dream scenario - you can run 10 accounts and argue the same points, and the reason why they all sound alike is just merely because they're all LLM users. You could even just spend a few dollars a month and run 20-30 accounts to automatically disrupt wikipedia discussions while you sleep, and if LLM usage was allowed, it would be very hard to stop. However, I don't have much faith in AI detection tools (partially because it's based on the same underlying flawed technology), and would want any assumption of LLM usage to be based on obvious evidence, not just a score on some website. Also, to those who are posting chatgpt snippets here: please stop - it's not interesting or insightful, just more slop BugGhost🦗👻19:15, 5 December 2024 (UTC)[reply]
I agree with your assessment “Also, to those who are posting chatgpt snippets here: please stop - it's not interesting or insightful, just more slop” but unfortunately some editors who should really know better think it’s WaCkY to fill serious discussions with unfunny, distracting “humor”. Dronebogus (talk) 21:54, 5 December 2024 (UTC)[reply]
Strong support if you asked a robot to spew out some AI slop to win an argument you’re basically cheating. The only ethical reason to do so is because you can’t speak English well, and the extremely obvious answer to that is “if you can barely speak English why are you editing English Wikipedia?” That’s like a person who doesn’t understand basic physics trying to explain the second law of thermodynamics using a chatbot. Dronebogus (talk) 21:32, 5 December 2024 (UTC)[reply]
I don't think "cheating" is a relevant issue here. Cheating is a problem if you use a LLM to win and get a job, award, college acceptance etc. that you otherwise wouldn't deserve. But WP discussions aren't a debating-skills contest, they're an attempt to determine the best course of action.
So using an AI tool in a WP discussion is not cheating (though there may be other problems), just as riding a bike instead of walking isn't cheating unless you're trying to win a race. ypn^222:36, 5 December 2024 (UTC)[reply]
Maybe “cheating” isn’t the right word. But I think that a) most AI generated content is garbage (it can polish the turd by making it sound professional, but it’s still a turd underneath) and b) it’s going to be abused by people trying to gain a material edge in an argument. An AI can pump out text far faster than a human and that can drown out or wear down the opposition if nothing else. Dronebogus (talk) 08:08, 6 December 2024 (UTC)[reply]
Bludgeoning is already against policy. It needs to be more strongly enforced, but it needs to be more strongly enforced uniformly rather than singling out comments that somebody suspects might have had AI-involvement. Thryduulf (talk) 10:39, 6 December 2024 (UTC)[reply]
Support; I agree with Remsense and jlwoodwa, among others: I wouldn't make any one AI-detection site the Sole Final Arbiter of whether a comment "counts", but I agree it should be expressly legitimate to discount AI / LLM slop, at the very least to the same extent as closers are already expected to discount other insubstantial or inauthentic comments (like if a sock- or meat-puppet copy-pastes a comment written for them off-wiki, as there was at least one discussion and IIRC ArbCom case about recently). -sche (talk) 22:10, 5 December 2024 (UTC)[reply]
You don't need a new policy that does nothing but duplicate a subset of existing policy. At most what you need is to add a sentence to the existing policy that states "this includes comments written using LLMs", however you'd rightly get a lot of pushback on that because it's completely redundant and frankly goes without saying. Thryduulf (talk) 23:37, 5 December 2024 (UTC)[reply]
Support hallucinations are real. We should be taking a harder line against LLM generated participation. I don't think everyone who is doing it knows that they need to stop. Andre🚐23:47, 5 December 2024 (UTC)[reply]
Support per all above. Discussions are supposed to include the original arguments/positions/statements/etc of editors here, not off-site chatbots. TheKip(contribs)03:53, 6 December 2024 (UTC)[reply]
(Is this where I respond? If not, please move.) LLM-generated prose should be discounted. Sometimes there will be a discernible point in there; it may even be what the editor meant, lightly brushed up with what ChatGPT thinks is appropriate style. (So I wouldn't say "banned and punishable" in discussions, although we already deprecate machine translations on en.wiki and for article prose, same difference—never worth the risk.) However, LLMs don't think. They can't explain with reference to appropriate policy and guidelines. They may invent stuff, or use the wrong words—at AN recently, an editor accused another of "defaming" and "sacrilege", thus drowning their point that they thought that editor was being too hard on their group by putting their signature to an outrageous personal attack. I consider that an instance of LLM use letting them down. If it's not obvious that it is LLM use, then the question doesn't arise, right? Nobody is arguing for requiring perfect English. That isn't what WP:CIR means. English is a global language, and presumably for that reason, many editors on en.wiki are not native speakers, and those that aren't (and those that are!) display a wide range of ability in the language. Gnomes do a lot of fixing of spelling, punctuation and grammar in articles. In practice, we don't have a high bar to entrance in terms of English ability (although I think a lot more could be done to explain to new editors whose English is obviously non-native what the rule or way of doing things is that they have violated. And some of our best writers are non-native; a point that should be emphasised because we all have a right of anonymity here, many of us use it, and it's rare, in particular, that I know an editor's race. Or even nationality (which may not be the same as where they live.) But what we do here is write in English: both articles and discussions. If someone doesn't have the confidence to write their own remark or !vote, then they shouldn't participate in discussions; I strongly suspect that it is indeed a matter of confidence, of wanting to ensure the English is impeccable. LLMs don't work that way, really. They concoct things like essays based on what others have written. Advice to use them in a context like a Wikipedia discussion is bad advice. At best it suggests you let the LLM decide which way to !vote. If you have something to say, say it and if necessary people will ask a question for clarification (or disagree with you). They won't mock your English (I hope! Civility is a basic rule here!) It happens in pretty much every discussion that somebody makes an English error. No biggie. I'll stop there before I make any more typos myself; typing laboriously on my laptop in a healthcare facility, and anyway Murphy's Law covers this. Yngvadottir (talk)
I dunno about this specifically but I want to chime in to say that I find LLM-generated messages super fucking rude and unhelpful and support efforts to discourage them. – Joe (talk) 08:15, 6 December 2024 (UTC)[reply]
Comment I think obvious LLM/chatbot text should at least be tagged through an Edit filter for Recent Changes, then RC Patrollers and reviewers can have a look and decide for themselves. A♭m(Ring!)(Notes)11:58, 6 December 2024 (UTC)[reply]
How do you propose that such text be identified by an edit filter? LLM detections tools have high rates of both false positives and false negatives. Thryduulf (talk) 12:47, 6 December 2024 (UTC)[reply]
It might become possible once watermarks (like DeepMind's SynthID) are shown to be robust and are adopted. Some places are likely to require it at some point e.g. EU. I guess it will take a while though and might not even happen e.g. I think OpenAI recently decided to not go ahead with their watermark system for some reason. Sean.hoyland (talk) 13:17, 6 December 2024 (UTC)[reply]
It will still be trivial to bypass the watermarks, or use LLMs that don't implement them. It also (AIUI) does nothing to reduce false positives (which for our usecase are far more damaging than false negatives). Thryduulf (talk) 13:30, 6 December 2024 (UTC)[reply]
Maybe, that seems to be the case with some of the proposals. Others, like SynthID claim high detection rates, maybe because even a small amount of text contains a lot of signals. As for systems that don't implement them, I guess that would be an opportunity to make a rule more nuanced by only allowing use of watermarked output with verbosity limits...not that I support a rule in the first place. People are going to use/collaborate with LLMs. Why wouldn't they? Sean.hoyland (talk) 14:38, 6 December 2024 (UTC)[reply]
I don't think watermarks are a suitable thing to take into account. My view is that LLM usage should be a blockable offense on any namespace, but if it ends up being allowed under some circumstances then we at least need mandatory manual disclosures for any usage. Watermarks won't work / aren't obvious enough - we need something like {{LLM}} but self-imposed, and not tolerate unmarked usage. BugGhost🦗👻18:21, 6 December 2024 (UTC)[reply]
Comment As a practical matter, users posting obvious LLM-generated content will typically be in violation of other rules (e.g. disruptive editing, sealioning), in which case their discussion comments absolutely should be ignored, discouraged, discounted, or (in severe cases) hatted. But a smaller group of users (e.g. people using LLMs as a translation tool) may be contributing productively, and we should seek to engage with, rather than discourage, them. So I don't see the need for a separate bright-line policy that risks erasing the need for discernment — in most cases, a friendly reply to the user's first LLM-like post (perhaps mentioning WP:LLM, which isn't a policy or guideline, but is nevertheless good advice) will be the right approach to work out what's really going on. Preimage (talk) 15:53, 6 December 2024 (UTC)[reply]
Some translation tools have LLM assistance, but the whole point of generative models is to create text far beyond what is found in the user's input, and the latter is clearly what this proposal covers. JoelleJay (talk) 19:01, 6 December 2024 (UTC)[reply]
That might be what the proposal intends to cover, but it is not what the proposal actually covers. The proposal all comments that have been generated by LLMs and/or AI, without qualification. Thryduulf (talk) 01:05, 7 December 2024 (UTC)[reply]
70+% here understand the intention matches the language: generated by LLMs etc means "originated through generative AI tools rather than human thought", not "some kind of AI was involved in any step of the process". Even LLM translation tools don't actually create meaningful content where there wasn't any before; the generative AI aspect is only in the use of their vast training data to characterize the semantic context of your input in the form of mathematical relationships between tokens in an embedding space, and then match it with the collection of tokens most closely resembling it in the other language. There is, definitionally, a high level of creative constraint in what the translation output is since semantic preservation is required, something that is not true for text generation. JoelleJay (talk) 04:01, 7 December 2024 (UTC)[reply]
Do you have any evidence for you assertion that 70% of respondents have interpreted the language in the same way as you? Reading the comments associated with the votes suggests that it's closer to 70% of respondents who don't agree with you. Even if you are correct, 30% of people reading a policy indicates the policy is badly worded. Thryduulf (talk) 08:34, 7 December 2024 (UTC)[reply]
I think @Bugghost has summarized the respondent positions sufficiently below. I also think some portion of the opposers understand the proposal perfectly well and are just opposing anything that imposes participation standards. JoelleJay (talk) 22:54, 7 December 2024 (UTC)[reply]
There will be many cases where it is not possible to say whether a piece of text does or does not contain "human thought" by observing the text, even if you know it was generated by an LLM. Statements like "originated through generative AI tools rather than human thought" will miss a large class of use cases, a class that will probably grow over the coming years. People work with LLMs to produce the output they require. It is often an iterative process by necessity because people and models make mistakes. An example of when "...rather than human thought" is not the case is when someone works with an LLM to solve something like a challenging technical problem where neither the person or the model has a satisfactory solution to hand. The context window means that, just like with human collaborators, a user can iterate towards a solution through dialog and testing, exploring the right part of the solution space. Human thought is not absent in these cases, it is present in the output, the result of a collaborative process. In these cases, something "far beyond what is found in the user's input" is the objective, it seems like a legitimate objective, but regardless, it will happen, and we won't be able to see it happening. Sean.hoyland (talk) 10:46, 7 December 2024 (UTC)[reply]
Yes, but this proposal is supposed to apply to just the obvious cases and will hopefully discourage good-faith users from using LLMs to create comments wholesale in general. It can be updated as technology progresses. There's also no reason editors using LLMs to organize/validate their arguments, or as search engines for whatever, have to copy-paste their raw output, which is much more of a problem since it carries a much higher chance of hallucination. That some people who are especially familiar with how to optimize LLM use, or who pay for advanced LLM access, will be able to deceive other editors is not a reason to not formally proscribe wholesale comment generation. JoelleJay (talk) 22:27, 7 December 2024 (UTC)[reply]
That's reasonable. I can get behind the idea of handling obvious cases from a noise reduction perspective. But for me, the issue is noise swamping signal in discussions rather than how it was generated. I'm not sure we need a special rule for LLMs, maybe just a better way to implement the existing rules. Sean.hoyland (talk) 04:14, 8 December 2024 (UTC)[reply]
Comment: The original question was whether we should discount, ignore, strikethrough, or collapse chatbot-written content. I think there's a very big difference between these options, but most support !voters haven't mentioned which one(s) they support. That might make judging the consensus nearly impossible; as of now, supporters are the clear !majority, but supporters of what? — ypn^219:32, 6 December 2024 (UTC)[reply]
That means that supporters support the proposal that LLM-generated remarks in discussions should be discounted or ignored, and possibly removed in some manner. Not sure what the problem is here. Supporters support the things listed in the proposal - we don't need a prescribed 100% strict procedure, it just says that supporters would be happy with closers discounting, ignoring or under some circumstances deleting LLM content in discussions. BugGhost🦗👻19:40, 6 December 2024 (UTC)[reply]
More people have bolded "support" than other options, but very few of them have even attempted to refute the arguments against (and most that have attempted have done little more than handwaving or directly contradicting themselves), and multiple of those who have bolded "support" do not actually support what has been proposed when you read their comment. It's clear to me there is not going to be a consensus for anything other than "many editors dislike the idea of LLMs" from this discussion. Thryduulf (talk) 00:58, 7 December 2024 (UTC)[reply]
Arguing one point doesn't necessarily require having to refute every point the other side makes. I can concede that "some people use LLMs to improve their spelling and grammar" without changing my view overriding view that LLMs empower bad actors, time wasters and those with competence issues, with very little to offer wikipedia in exchange. Those that use LLMs legitimately to tidy up their alledgedly competent, insightful and self-sourced thoughts should just be encouraged to post the prompts themselves instead of churning it through an LLM first. BugGhost🦗👻09:00, 7 December 2024 (UTC)[reply]
If you want to completely ignore all the other arguments in opposition that's your choice, but don't expect closers to attach much weight to your opinions. Thryduulf (talk) 09:05, 7 December 2024 (UTC)[reply]
Ok, here's a list of the main opposition reasonings, with individual responses.
What about translations? - Translations are not up for debate here, the topic here is very clearly generative AI, and attempts to say that this topic covers translations as well is incorrect. No support voters have said the propositions should discount translated text, just oppose voters who are trying to muddy the waters.
What about accessibility? - This is could be a legitimate argument, but I haven't seen this substantiated anywhere other than handwaving "AI could help people!" arguments, which I would lump into the spelling and grammar argument I responded to above.
Detection tools are inaccurate - This I very much agree with, and noted in my support and in many others as well. But there is no clause in the actual proposal wording that mandates the use of automated AI detection, and I assume the closer would note that.
False positives - Any rule can have a potential for false positives, from wp:DUCK to close paraphrasing to NPA. We've just got to as a community become skilled at identifying genuine cases, just like we do for every other rule.
LLM content should be taken at face value and see if it violates some other policy - hopelessly naive stance, and a massive timesink. Anyone who has had the misfortune of going on X/twitter in the last couple of years should know that AI is not just used as an aid for those who have trouble typing, it is mainly used to spam and disrupt discussion to fake opinions to astroturf political opinions. Anyone who knows how bad the sockpuppetry issue is around CTOPs should be absolutely terrified of when (not if) someone decides to launch a full throated wave of AI bots on Wikipedia discussions, because if we have to invididually sanction each one like a human then admins will literally have no time for anything else.
I genuinely cannot comprehend how some people could see how AI is decimating the internet through spam, bots and disinformation and still think for even one second that we should open the door to it. BugGhost🦗👻10:08, 7 December 2024 (UTC)[reply]
There is no door. This is true for sockpuppetry too in my opinion. There can be a rule that claims there is a door, but it is more like a bead curtain. Sean.hoyland (talk) 11:00, 7 December 2024 (UTC)[reply]
The Twitter stuff is not a good comparison here. Spam is already nukable on sight, mass disruptive bot edits are also nukable on sight, and it's unclear how static comments on Wikipedia would be the best venue to astroturf political opinions (most of which would be off-topic anyway, i.e., nukable on sight). I'd prefer if people didn't use ChatGPT to formulate their points, but if they're trying to formulate a real point then that isn't disruptive in the same way spam is. Gnomingstuff (talk) 02:22, 10 December 2024 (UTC)[reply]
it's unclear how static comments on Wikipedia would be the best venue to astroturf political opinions - by disrupting RFCs and talk page discussions a bad actor could definitely use chatgpt to astroturf. A large proportion of the world uses Wikipedia (directly or indirectly) to get information - it would be incredibly valuable thing to manipulate. My other point is that AI disruption bots (like the ones on twitter) would be indistinguishable from individuals using LLMs to "fix" spelling and grammar - by allowing one we make the other incredibly difficult to identify. How can you tell the difference between a bot and someone who just uses chatgpt for every comment? BugGhost🦗👻09:16, 10 December 2024 (UTC)[reply]
Those that use LLMs legitimately to tidy up their alledgedly competent, insightful and self-sourced thoughts should just be encouraged to post the prompts themselves instead of churning it through an LLM first.
Social anxiety: Say "I" am a person unconfident in my writing. I imagine that when I post my raw language, I embarrass myself, and my credibility vanishes, while in the worst case nobody understands what I mean. As bad confidence is often built up through negative feedback, it's usually meritful or was meritful at some point for someone to seek outside help. Aaron Liu (talk) 23:46, 8 December 2024 (UTC)[reply]
While I sympathise with that hypothetical, Wikipedia isn't therapy and we shouldn't make decisions that do long-term harm to the project just because a hypothetical user feels emotionally dependent on a high tech spellchecker. I also think that in general wikipedia (myself included) is pretty relaxed about spelling and grammar in talk/WP space. BugGhost🦗👻18:45, 10 December 2024 (UTC)[reply]
We also shouldn't do long term harm to the project just because a few users are wedded to idea that LLMs are and will always be some sort of existential threat. The false positives that are an unavoidable feature of this proposal will do far more, and far longer, harm to the project than LLM-comments that are all either useful, harmless or collapseable/removable/ignorable at present. Thryduulf (talk) 19:06, 10 December 2024 (UTC)[reply]
The false positives that are an unavoidable feature of this proposal will do far more, and far longer, harm to the project - the same could be said for WP:DUCK. The reason why its not a big problem for DUCK is because the confidence level is very high. Like I've said in multiple other comments, I don't think "AI detectors" should be trusted, and that the bar for deciding whether something was created via LLM should be very high. I 100% understand your opinion and the reasoning behind it, I just think we have differing views on how well the community at large can identify AI comments. BugGhost🦗👻09:07, 11 December 2024 (UTC)[reply]
I don't see how allowing shy yet avid users to contribute has done or will do long-term harm. The potential always outweighs rational evaluation of outcomes for those with anxiety, a condition that is not behaviorally disruptive. Aaron Liu (talk) 02:47, 11 December 2024 (UTC)[reply]
I definitely don't want to disallow shy yet avid users! I just don't think having a "using chatgpt to generate comments is allowed" rule is the right solution to that problem, considering the wider consequences. BugGhost🦗👻08:52, 11 December 2024 (UTC)[reply]
Support strikethroughing or collapsing per everyone else. The opposes that mention ESL have my sympathy, but I am not sure how many of them are ESL themselves. Having learnt English as my second language, I have always found it easier to communicate when users are expressing things in their own way, not polished by some AI. I sympathise with the concerns and believe the right solution is to lower our community standards with respect to WP:CIR and similar (in terms of ESL communication) without risking hallucinations by AI. Soni (talk) 02:52, 7 December 2024 (UTC)[reply]
Oppose - I'm sympathetic to concerns of abuse through automated mass-commenting, but this policy looks too black-and-white. Contributors may use LLMs for many reasons, including to fix the grammar, to convey their thoughts more clearly, or to adjust the tone for a more constructive discussion. As it stands, this policy may lead to dismissing good-faith AI-assisted comments, as well as false positives, without considering the context. Moreover, while mainstream chatbots are not designed to just mimic the human writing style, there are existing tools that can make AI-generated text more human-like, so this policy does not offer that much protection against maliciously automated contributions. Alenoach (talk) 01:12, 9 December 2024 (UTC)[reply]
Oppose – Others have cast doubt on the efficacy of tools capable of diagnosing LLM output, and I can't vouch for its being otherwise. If EEng's example of ChatBot output is representative—a lengthy assertion of notability without citing sources—that is something that could well be disregarded whether it came from a bot or not. If used carefully, AI can be useful as an aide-memoire (such as with a spell- or grammar-checker) or as a supplier of more felicitous expression than the editor is naturally capable of (e.g. Google Translate). Dhtwiki (talk) 10:27, 9 December 2024 (UTC)[reply]
Comment / Oppose as written. It's not accurate that GPTZero is good at detecting AI-generated content. Citations (slightly out of date but there's little reason to think things have changed from 2023): https://www.aiweirdness.com/writing-like-a-robot/ , https://www.aiweirdness.com/dont-use-ai-detectors-for-anything-important/ . For those too busy to read, a few choice quotes: "the fact that it insisted even one [real book] excerpt is not by a human means that it's useless for detecting AI-generated text," and "Not only do AI detectors falsely flag human-written text as AI-written, the way in which they do it is biased" (citing https://arxiv.org/abs/2304.02819 ). Disruptive, worthless content can already be hatted, and I'm not opposed to doing so. Editors should be sharply told to use their own words, and if not already written, an essay saying we'd rather have authentic if grammatically imperfect comments than AI-modulated ones would be helpful to cite at editors who offer up AI slop. But someone merely citing GPTZero is not convincing. GPTZero will almost surely misidentify genuine commentary as AI-generated. So fine with any sort of reminder that worthless content can be hatted, and fine with a reminder not to use ChatGPT for creating Wikipedia talk page posts, but not fine with any recommendations of LLM-detectors. SnowFire (talk) 20:00, 9 December 2024 (UTC)[reply]
@SnowFire, I can't tell if you also oppose the actual proposal, which is to permit hatting/striking obvious LLM-generated comments (using GPTzero is a very minor detail in JSS's background paragraph, not part of the proposal). JoelleJay (talk) 01:47, 11 December 2024 (UTC)[reply]
I support the proposal in so far as disruptive comments can already be hatted and that LLM-generated content is disruptive. I am strongly opposed to giving well-meaning but misguided editors a license to throw everyone's text into an AI-detector and hat the comments that score poorly. I don't think it was that minor a detail, and to the extent that detail is brought up, it should be as a reminder to use human judgment and forbid using alleged "AI detectors" instead. SnowFire (talk) 03:49, 11 December 2024 (UTC)[reply]
Support collapsing AI (specifically, Large language model) comments by behavioral analysis (most actually disruptive cases I've seen are pretty obvious) and not the use of inaccurate tools like ZeroGPT. I thinking hatting with the title "Editors suspect that this comment has been written by a Large language model" is appropriate. They take up SO much space in a discussion because they are also unnecessarily verbose, and talk on and on but never ever say something that even approaches having substance. Discussions are for human Wikipedia editors, we shouldn't have to use to sift through comments someone put 0 effort into and outsourced to a robot that writes using random numbers (that's a major part of how tools like ChatGPT work and maintain variety). If someone needs to use an AI chatbot to communicate because they don't understand English, then they are welcome to contribute to their native language Wikipedia, but I don't think they have the right to insist that we at enwiki spend our effort reading comments they but minimal effort into besides opening the ChatGPT website. If really needed, they can write in their native language and use a non-LLM tool like Google Translate. The use of non-LLM tools like Grammarly, Google Translate, etc. I think should still be OK for all editors, as they only work off comments that editors have written themselves. MolecularPilot🧪️✈️05:10, 10 December 2024 (UTC)[reply]
Adding that enforcing people writing things in their own words will actually help EAL (English additional language) editors contribute here. I world with EAL people irl, and even people who have almost native proficiency with human-written content find AI output confusing because it says things in the most confusing, verbose ways using difficult sentence constructions and words. I've seen opposers in this discussion who maybe haven't had experience working with EAL people go "what about EAL people?", but really, I think this change will help them (open to being corrected by someone who is EAL, tho). MolecularPilot🧪️✈️05:17, 10 December 2024 (UTC)[reply]
Also, with regards to oppose comments that discussions are not a vote so closes will ignore AI statements which don't have merit - unedited LLM statements are incredibly verbose and annoying, and clog up the discussion. Imagine multiple paragraphs, each with a heading, but all of which say almost nothing, they're borderline WP:BLUGEONy. Giving the power to HAT them will help genuine discussion contributors keep with the flow of human arguments and avoid scaring away potential discussion contributors who are intimidated or don't feel they have the time to read the piles of AI nonsense that fill the discussion. MolecularPilot🧪️✈️06:38, 10 December 2024 (UTC)[reply]
Support (removing) in general. How is this even a question? There is no case-by-case. It is a fundamental misunderstanding of how LLMs work to consider their output reliable without careful review. And which point, the editor could have written it themselves without inherent LLM bias. The point of any discussion is to provide analytical response based on the context, not have some tool regurgitate something from a training set that sounds good. And frankly, it is disrespectuful to make someone read "AI" responses. It is a tool and there is a place and time for it, but not in discussions in an encyclopedia. — HELLKNOWZ∣TALK15:41, 10 December 2024 (UTC)[reply]
Strong Support. I'm very interested in what you (the generic you) have to say about something. I'm not remotely interested in what a computer has to say about something. It provides no value to the discussion and is a waste of time. Useight (talk) 18:06, 10 December 2024 (UTC)[reply]
Comments that provide no value to the discussion can already be hatted and ignored regardless of why they provide no value, without any of the false positive or false negatives inherent in this proposal. Thryduulf (talk) 18:25, 10 December 2024 (UTC)[reply]
Indeed, and that's fine for one-offs when a discussion goes off the rails or what-have-you. But we also have WP:NOTHERE for disruptive behavior, not working collaboratively, etc. I'm suggesting that using an AI to write indicates that you're not here to build the encyclopedia, you're here to have an AI build the encyclopedia. I reiterate my strong support for AI-written content to be removed, struck, collapsed, or hatted and would support further measures even beyond those. Useight (talk) 21:54, 11 December 2024 (UTC)[reply]
There are two sets of people described in your comment: those who use AI and those who are NOTHERE. The two sets overlap, but nowhere near sufficiently to declare that everybody in the former set are also in the latter set. If someone is NOTHERE they already can and should be blocked, regardless of how they evidence that. Being suspected of using AI (note that the proposal does not require proof) is not sufficient justification on its own to declare someone NOTHERE, per the many examples of constructive use of AI already noted in this thread. Thryduulf (talk) 22:03, 11 December 2024 (UTC)[reply]
To reiterate, I don't believe that any use of AI here is constructive, thus using it is evidence of WP:NOTHERE, and, therefore, the set of people using AI to write is completely circumscribed within the set of people who are NOTHERE. Please note that I am referring to users who use AI-generated writing, not users suspected of using AI-generated writing. I won't be delving into how one determines whether someone is using AI or how accurate it is, as that is, to me, a separate discussion. This is the end of my opinion on the matter. Useight (talk) 23:26, 11 December 2024 (UTC)[reply]
You are entitled to your opinion of course, but as it is contradicted by the evidence of both multiple constructive uses and of the near-impossibility of reliably detecting LLM-generated text without false positives, I would expect the closer of this discussion to attach almost no weight to it. Thryduulf (talk) 00:42, 12 December 2024 (UTC)[reply]
I am ESL and use LLMs sometimes because of that. I feel like I don't fit into the NOTHERE category. It seems like you do not understand what they are or how they can be used constructively. PackMecEng (talk) 01:43, 12 December 2024 (UTC)[reply]
No, I understand. What you're talking about is no different from using Google Translate or asking a native-speaker to translate it. You, a human, came up with something you wanted to convey. You wrote that content in Language A. But you wanted to convey that message that you - a human - wrote, but now in Language B. So you had your human-written content translated to Language B. I have no qualms with this. It's your human-written content, expressed in Language B. My concern is with step 1 (coming up with something you want to convey), not step 2 (translating that content to another language). You write a paragraph for an article but it's in another language and you need the paragraph that you wrote translated? Fine by me. You ask an AI to write a paragraph for an article? Not fine by me. Again, I'm saying that there is no valid use case for AI-written content. Useight (talk) 15:59, 12 December 2024 (UTC)[reply]
It seems very likely that there will be valid use cases for AI-written content if the objective is maximizing quality and minimizing errors. Research like this demonstrate that there will likely be cases where machines outperform humans in specific Wikipedia domains, and soon. But I think that is an entirely different question than potential misuse of LLMs in consensus related discussions. Sean.hoyland (talk) 16:25, 12 December 2024 (UTC)[reply]
But your vote and the proposed above makes not distinction there. Which is the main issue. Also not to be pedantic but every prompted to a LLM is filled out by a human looking to convey a message. Every time someone hits publish on something here it is that person confirming that is what they are saying. So how do we in practice implement what you suggest? Because without a method better than vibes it's worthless. PackMecEng (talk) 18:53, 12 December 2024 (UTC)[reply]
The proposal specifies content generated by LLMs, which has a specific meaning in the context of generative AI. If a prompt itself conveys a meaningful, supported opinion, why not just post that instead? The problem comes when the LLM adds more information than was provided, which is the whole point of generative models. JoelleJay (talk) 01:52, 13 December 2024 (UTC)[reply]
Yes in principle. But in practice, LLM detectors are not foolproof, and there are valid reasons to sometimes use an LLM, for example to copyedit. I have used Grammarly before and have even used the Microsoft Editor, and while they aren't powered by LLMs, LLMs are a tool that need to be used appropriately on Wikipedia. AwesomeAasim19:55, 10 December 2024 (UTC)[reply]
Support. Using LLM to reply to editors is lazy and disrespectful of fellow editor's time and brainpower. In the context of AFD, it is particularly egregious since an LLM can't really read the article, read sources, or follow our notability guidelines. By the way. gptzero and other such tools are very good at detecting this. I don't think this is correct at all. I believe the false positive for AI detectors is quite high. High enough that I would recommend not using AI detectors. –Novem Linguae (talk) 03:23, 11 December 2024 (UTC)[reply]
Support. AI generated text should be removed outright. If you aren't willing to put the work into doing your own writing then you definitely haven't actually thought deeply about the matter at hand. User1042💬✒️14:16, 11 December 2024 (UTC)[reply]
This comment is rather ironic given that it's very clear you haven't thought deeply about the matter at hand, because if you had then you'd realise that it's actually a whole lot more complicated than that. Thryduulf (talk) 14:26, 11 December 2024 (UTC)[reply]
Thryduulf I don't think this reply is particular helpful, and it comes off as slightly combative. It's also by my count your 24th comment on this RFC. BugGhost🦗👻19:20, 11 December 2024 (UTC)[reply]
I recognize that AI paraphrased or edited is not problematic in the same ways as text generated outright by an AI. I only meant to address the core issue at steak, content whose first draft was written by an AI system. User1042💬✒️22:16, 17 December 2024 (UTC)[reply]
I've recently come across several users in AFD discussions that are using LLMs to generate their remarks there. As many of you are aware, gptzero and other such tools are very good at detecting this. I don't feel like any of us signed up for participating in discussions where some of the users are not using their own words but rather letting technology do it for them. Discussions are supposed to be between human editors. If you can't make a coherent argument on your own, you are not competent to be participating in the discussion. I would therefore propose that LLM-generated remarks in discussions should be discounted or ignored, and possibly removed in some manner
Support with the caveat that our ability to deal with the issue goes only as far as we can accurately identify the issue (this appears to have been an issue raised across a number of the previous comments, both support and oppose, but I think it bears restating because we're approaching this from a number of different angles and its IMO the most important point regardless of what conclusions you draw from it). Horse Eye's Back (talk) 19:24, 11 December 2024 (UTC)[reply]
Strong support, limited implementation. Wikipedia is written by volunteer editors, says our front page. This is who we are, and our writing is what Wikipedia is. It's true that LLM-created text can be difficult to identify, so this may be a bit of a moving target, and we should be conservative in what we remove—but I'm sure at this point we've all run across cases (whether here or elsewhere in our digital lives) where someone copy/pastes some text that includes "Is there anything else I can help you with?" at the end, or other blatant tells. This content should be deleted without hesitation. Retswerb (talk) 04:11, 12 December 2024 (UTC)[reply]
Support in concept, questions over implementation — I concur with Dronebogus that users who rely on LLMs should not edit English Wikipedia. It is not a significant barrier for users to use other means of communication, including online translators, rather than artificial intelligence. How can an artificial intelligence tool argue properly? However, I question how this will work in practice without an unacceptable degree of error. elijahpepe@wikipedia (he/him)22:39, 12 December 2024 (UTC)[reply]
Well since people keep bringing this up as a semi-strawman: no I don’t support banning machine translation, not that I encourage using it (once again, if you aren’t competent in English please don’t edit here) Dronebogus (talk) 07:34, 13 December 2024 (UTC)[reply]
LLMs are incredible at translating, and many online translators already incorporate them, including Google Translate. Accomodating LLMs is an easy way to support the avid not only the ESL but also the avid but shy. It has way more benefits than the unseen-to-me amount of AI trolling that isn't already collapse-on-sight. Aaron Liu (talk) 00:05, 13 December 2024 (UTC)[reply]
Google Translate uses the same transformer architecture that LLMs are built around, and uses e.g. PaLM to develop more language support (through training that enables zero-shot capabilities) and for larger-scale specialized translation tasks performed through the Google Cloud "adaptive translation" API, but it does not incorporate LLMs into translating your everyday text input, which still relies on NMTs. And even for the API features, the core constraint of matching input rather than generating content is still retained (obviously it would be very bad for a translation tool to insert material not found in the original text!). LLMs might be good for translation because they are better at evaluating semantic meaning and detecting context and nuance, but again, the generative part that is key to this proposal is not present. JoelleJay (talk) 01:20, 13 December 2024 (UTC)[reply]
PaLM (Pathways Language Model) is a 540 billion-parameter transformer-based large language model (LLM) developed by Google AI.[1] If you meant something about how reschlmunking the outputs of an LLM or using quite similar architecture is not really incorporating the LLM, I believe we would be approaching Ship of Theseus levels of recombination, to which my answer is it is the same ship.
obviously it would be very bad for a translation tool to insert material not found in the original text!
PaLM2 is not used in the consumer app (Google Translate), it's used for research. Google Translate just uses non-generative NMTs to map input to its closes cognate in the target language. JoelleJay (talk) 01:34, 13 December 2024 (UTC)[reply]
Well, is the NMT really that different enough to not be classified as an LLM? IIRC the definition of an LLM is something that outputs by predicting one-by-one what the next word/"token" should be, and an LLM I asked agreed that NMTs satisfy the definition of a generative LLM, though I think you're the expert here. Aaron Liu (talk) 02:01, 13 December 2024 (UTC)[reply]
Google Translate's NMT hits different enough to speak English much less naturally than ChatGPT 4o. I don't consider it a LLM, because the param count is 380M not 1.8T.
Even if you don’t consider it L, I do, and many sources cited by the article do. Since we’ll have such contesting during enforcement, it’s better to find a way that precludes such controversy. Aaron Liu (talk) 20:44, 13 December 2024 (UTC)[reply]
NMTs, LLMs, and the text-creation functionality of LLMs are fundamentally different in the context of this discussion, which is about content generated through generative AI. NMTs specifically for translation: they are trained on parallel corpora and their output is optimized to match the input as precisely as possible, not to create novel text. LLMs have different training, including way more massive corpora, and were designed specifically to create novel text. One of the applications of LLMs may be translation (though currently it's too computationally intensive to run them for standard consumer purposes), by virtue of their being very good at determining semantic meaning, but even if/when they do become mainstream translation tools what they'll be used for is still not generative when it comes to translation output. JoelleJay (talk) 22:29, 13 December 2024 (UTC)[reply]
The proposal is for hatting obvious cases of LLM-generated comments. Someone who just uses an LLM to copyedit will still have written the content themselves and presumably their output would not have the obvious tells of generative AI. JoelleJay (talk) 23:56, 13 December 2024 (UTC)[reply]
Not when I tried to use it. Quantitatively, GPTZero went from 15% human to 100% AI for me despite the copyedits only changing 14 words. Aaron Liu (talk) 00:33, 14 December 2024 (UTC)[reply]
Does it really mean that? All you've demonstrated is that GPTZero has false positives, which is exactly why its use here was discouraged. jlwoodwa (talk) 05:26, 14 December 2024 (UTC)[reply]
It changed only 14 words across two paragraphs and still retained the same meaning in a way that I would describe it as copyediting. Such levels of change are what those lacking confidence in tone would probably seek anyways. Aaron Liu (talk) 00:15, 24 December 2024 (UTC)[reply]
On one hand, AI slop is a plague on humanity and obvious LLM output should definitely be disregarded when evaluating consensus. On the other hand, I feel like existing policy covers this just fine, and any experienced closer will lend greater weight to actual policy-based arguments, and discount anything that is just parroting jargon. WindTemposthey(talk • contribs)23:21, 12 December 2024 (UTC)[reply]
Support in principle, but we cannot rely on any specific tools because none are accurate enough for our needs. Whenever I see a blatant ChatGPT-generated !vote, I ignore it. They're invariably poorly reasoned and based on surface-level concepts rather than anything specific to the issue being discussed. If someone is using AI to create their arguments for them, it means they have no actual argument besides WP:ILIKEIT and are looking for arguments that support their desired result rather than coming up with a result based on the merits. Also, toasters do not get to have an opinion. The WordsmithTalk to me05:17, 13 December 2024 (UTC)[reply]
Oppose. For creating unnecessary drama. First of, the "detector" of the AI bot is not reliable, or at least the reliability of the tool itself is still questionable. If the tool to detect LLM itself is unreliable, how can one reliably point out which one is LLM and which one is not? We got multiple tools that claimed to be able to detect LLM as well. Which one should we trust? Should we be elevating one tool over the others? Have there been any research that showed that the "picked" tool is the most reliable? Second, not all LLMs are dangerous. We shouldn't treat LLM as a virus that will somehow take over the Internet or something. Some editors use LLM to smooth out their grammar and sentences and fix up errors, and there is nothing wrong with that. I understand that banning obvious LLM text per WP:DUCK are good, but totally banning them is plain wrong. ✠ SunDawn ✠(contact)22:56, 15 December 2024 (UTC)[reply]
@SunDawn, the proposal is to permit editors to collapse/strike obvious LLM text, not to "ban LLM totally". If LLM use is imperceptible, like for tweaking grammar, it's not going to be affected. JoelleJay (talk) 20:17, 19 December 2024 (UTC)[reply]
Support with some kind of caveat about not relying on faulty tools or presuming that something is LLM without evidence or admission, based on the following reasons:
We have stricter rules around semi-automated editing (rollback, AutoWikiBrowser, etc.) and even stricter rules around fully automated bot editing. These cleanup edits are widely accepted as positive, but there is still the concern about an overwhelming amount of bad edits to wade through and/or fix. A form of that concern is relevant here. Someone could reply to every post in this discussion in just a minute or so without ever reading anything. That's inherently disruptive.
Nobody who is voting "oppose" is using an LLM to cast that vote. The LLM comments have been left by those supporting to make a point about how problematic they are for discussions like this. I think this reflects, even among oppose voters, a developing community consensus that LLM comments will be disregarded.
If the rule in practice is to disregard LLM comments, not writing that rule down does not stop it from being the rule, consensus, or a community norm. It just makes the rule less obvious and less clear.
It's disrespectful for an editor to ask someone to spend their time reading a comment if they couldn't be bothered to spend any time writing it, and therefore a violation of the policy Wikipedia:Civility, "treat your fellow editors as respected colleagues with whom you are working on an important project."
I am strongly opposed to banning or ignoring LLM-made talk page comments just because they are LLM-made. I'm not a big fan of LLMs at all; they are actually useful only for some certain things, very few of which are directly relevant to contributing to Wikipedia in English or in any other language. However, some of those things are useful for this, at least for some humans, and I don't want to see these humans being kicked out of the English Wikipedia. I already witnessed several cases in which people whose first language is not English tried writing talk page responses in the English Wikipedia, used an LLM to improve their writing style, and got their responses ignored only because they used an LLM. In all those cases, I had strong reasons to be certain that they were real humans, that they meant what they wrote, and that they did it all in good faith. Please don't say that anyone who wants to contribute to the English Wikipeida should, in the first place, know English well enough to write a coherent talk page comment without LLM assistance; occasionally, I kind of wish that it was like that myself, but then I recall that the world is more complicated and interesting than that. Uses of LLMs that help the English Wikipedia be more inclusive for good-faith people are good. Of course, defining what good faith means is complicated, but using an LLM is not, by itself, a sign of bad faith. --Amir E. Aharoni (talk) 04:52, 19 December 2024 (UTC)[reply]
Those concerned about their English should use translation software rather than an llm. Both might alter the meaning to some extent, but only one will make things up. (It's also not a sure assumption that llm text is coherent talkpage text.) CMD (talk) 07:44, 19 December 2024 (UTC)[reply]
@CMD The dividing line between translation software and LLM is already blurry and will soon disappear. It's also rare that translation software results in coherent talkpage text, unless it's relying on some (primitive) form of LLM. So if we're going to outlaw LLMs, we would need to outlaw any form of translation software, and possibly any text-to-speech software as well. ypn^223:41, 19 December 2024 (UTC)[reply]
The distinctions have already been covered above, and no we would not have to. There is an obvious difference between software intended to translate and software intended to generate novel text, and users are likely to continue to treat those differently. CMD (talk) 02:49, 20 December 2024 (UTC)[reply]
Strong oppose to the proposal as written. Wikipedia already suffers from being stuck in a 2001mindset and a refusal to move with the technological times. Anyone who remembers most Wikipedians' visceral reaction to FLOW and VisualEditor when they were first introduced will observe a striking similarity. Yes, those projects had serious problems, as do LLM-generated comments. But AI is the future, and this attitude of "Move slowly to avoid changing things" will ultimately lead Wikipedia the way of Encyclopædia Britannica. Our discussion needs to be how best to change, not how to avoid to change. ypn^223:54, 19 December 2024 (UTC)[reply]
The main objection to VE and a major objection to FLOW was the developers' insistence on transforming Wikitext to HTML for editing and then transforming that back to Wikitext. Aaron Liu (talk) 01:31, 20 December 2024 (UTC)[reply]
True. Then, as now, there were many valid objections. But IIRC, there was limited discussion of "Let's figure out a better way to improve", and lots of "Everything is fine; don't change anything, ever." That attitude concerns me. ypn^201:52, 20 December 2024 (UTC)[reply]
Support. I'm not even slightly swayed by these "it'll be too hard to figure out" and "mistakes could be made" and "we can't be 100% certain" sorts of arguments. That's true of everything around here, and its why we have an admins-must-earn-a-boatload-of-community-trust system, and a system of review/appeal of decisions they (or of course non-admin closers) make, and a consensus-based decisionmaking system more broadly. JoelleJay has it exactly right: having a policy that permits closers to discount apparently-LLM-generated contributions will discourage good-faith editors from using LLMs irresponsibly and perhaps motivate bad-faith editors to edit the raw output to appear more human, which would at least involve some degree of effort and engagement with their "own" arguments. And as pointed out by some others, the "it'll hurt non-native-English speakers" nonsense is, well, nonsense; translation is a different and unrelated process (though LLMs can perform it to some extent), of remapping one's own material onto another language.
I'm also not in any way convinved by the "people poor at writing and other cognitive tasks needs the LLM to help them here" angle, because WP:COMPETENCE is required. This is work (albeit volunteer work), it is WP:NOT a game, a social-media playground, a get-my-ideas-out-there soapbox, or a place to learn how to interact e-socially or pick up remedial writing skills, nor a venue for practicing one's argument techiques. It's an encyclopedia, being built by people who – to be productive contributors instead of a draining burden on the entire community – must have: solid reasoning habits, great judgement (especially in assessing reliability of claims and the sources making them), excellent writing skills of a higherly particularized sort, a high level of fluency in this specific language (in multiple registers), and a human-judgment ability to understand our thick web of policies, guidelines, procedures, and often unwritten norms, and how they all interact, in a specific contextual way that may vary greatly by context. None of these is optional. An LLM cannot do any of them adequately (not even write well; their material sticks out like a sore thumb, and after a while you can even tell which LLM produced the material by its habitual but dinstictive crappy approach to simulating human thought and language).
In short, if you need an LLM to give what you think is meaningful input into a decision-making process on Wikipedia (much less to generate mainspace content for the public), then you need to go find something else to do, something that fits your skills and abilities. Saying this so plainly will probably upset someone, but so it goes. I have a rep for "not suffering fools lightly" and "being annoying but correct"; I can live with that if it gets the right decisions made and the work advanced. — SMcCandlish☏¢ 😼 05:49, 22 December 2024 (UTC)[reply]
The problem with all that is that we already have a policy that allows the hatting or removal of comments that are actually problematic because of their content (which are the only ones that we should be removing) without regard for whether it was or was not written by LLM. Everything that actually should be removed can be removed already. Thryduulf (talk) 11:39, 22 December 2024 (UTC)[reply]
People who have good reading skills, great judgement, and solid reasoning habits enough to find problems in existing articles don't necessarily have great interpersonal writing/communication skills or the confidence. Meanwhile, for all LLM is bad at, it is very good at diluting everything you say to become dry, dispassionate, and thus inoffensive. Aaron Liu (talk) 15:26, 22 December 2024 (UTC)[reply]
Support. Sure I have questions about detection, but I don't think it means we shouldn't have a policy that explicitly states that it should not be used (and can be ignored/hatted if it is). Judging solely based on content (and no wp:bludgeoning, etc.) is unsustainable IMO. It would mean taking every wall of text seriously until it's clear that the content is unhelpful, and LLMs are very good at churning out plausible-sounding bullshit. It wastes everyone's time. If cognitive impairments or ESL issues make it hard to contribute, try voice-to-text, old-school translation software, or some other aid. LLMs aren't really you.--MattMauler (talk) 11:27, 23 December 2024 (UTC)[reply]
Comment. While I agree with the sentiment of the request, I am at a loss to see how we can identify LLM generated comments in a consistent manner that can scale. Yes, it might be easier to identify egregious copy paste of wall of text, but, anything other than that might be hard to detect. Our options are:
Robust tooling to detect LLM generated text, with acceptably low levels of false positives. Somewhat similar to what Earwig does for Copyvios. But, someone needs to build it and host it on WMTools or at a similar location.
Self certification by editors. Every edit / publish dialogbox should have a checkbox for "Is this text LLM generated" with y/n optionality.
Editors playing a vigilante role in reading the text and making a personal call on other editors' text. Obviously this is least preferred.
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.
Whereas many editors, including me, have cited problems with accuracy in regards to existing tools such as ZeroGPT, I propose that remarks that are blatently generated by a LLM or similar automated system should be discounted/removed/collapsed/hidden. ThatIPEditorThey / Them10:00, 10 December 2024 (UTC)[reply]
Oppose as completely unnecessary and far too prone to error per the above discussion. Any comment that is good (on topic, relevant, etc) should be considered by the closer regardless of whether it was made with LLM-input of any sort or not. Any comment that is bad (off-topic, irrelevant, etc) should be ignored by the closer regardless of whether it was made with LLM-input of any sort or not. Any comment that is both bad and disruptive (e.g. by being excessively long, completely irrelevant, bludgeoning, etc) should be removed and/or hatted as appropriate, regardless of whether it was made with LLM-input of any sort. The good thing is that this is already policy so we don't need to call out LLMs specifically, and indeed doing so is likely to be disruptive in cases where human-written comments are misidentified as being LLM-written (which will happen, regardless of whether tools are used). Thryduulf (talk) 11:19, 10 December 2024 (UTC)[reply]
I think this proposal is not really necessary. I support it, but that is because it is functionally identical to the one directly above it, which I also supported. This should probably be hatted. BugGhost🦗👻18:32, 10 December 2024 (UTC)[reply]
What does blatantly generated mean? Does you mean only where the remark is signed with "I, Chatbot", or anything that appears to be LLM-style? I don't think there's much in between. ypn^219:21, 10 December 2024 (UTC)[reply]
Procedural close per BugGhost. I'd hat this myself, but I don't think that'd be appropriate since it's only the two of us who have expressed that this proposal is basically an exact clone. Aaron Liu (talk) 03:00, 11 December 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Should first language be included in the infobox for historical figures?
Is there a guideline concerning this? "Infobox royalty" apparently has this parameter, but I haven't found a single article that actually uses it. Many articles don't mention the subject's spoken languages at all. In my view, somebody's first language (L1) is just a very basic and useful piece of information, especially for historical figures. This would be helpful in cases where the ruling elites spoke a completely different language from the rest of the country (e.g., High Medieval England or early Qing dynasty China). These things are not always obvious to readers who are unfamiliar with the topic. Including it would be a nice and easy way to demonstrate historical language shifts that otherwise might be overlooked. Perhaps it could also bring visibility to historical linguistic diversity and language groups that have since disappeared. Where there are multiple first languages, they could all be listed. And in cases where a person's first language remains unclear, it could simply be left out. Kalapulla123 (talk) 11:53, 8 December 2024 (UTC)[reply]
I don't think I agree this is a good use of infobox space:
incongruences between elite spoken languages and popular spoken languages can't be shown with a single parameter (the language spoken by the oppressed would have to be included as well)
for many people this would be unverifiable (already mentioned in OP) and / or contentious (people living during a language transition)
sometimes L2 skills will be more than adequate to communicate with subject population when called for
in cases where the subject's L1 matches their polity's (i.e. most cases), the parameter would feel like unnecessary clutter
I think this might be sufficiently important pretty much exclusively for writers where the language they wrote in is not the "obvious" one for their nationality. Johnbod (talk) 12:43, 9 December 2024 (UTC)[reply]
It might also be important for politicians (and similar figures?) in countries where language is a politically-important subject, e.g. Belgium. Thryduulf (talk) 16:29, 9 December 2024 (UTC)[reply]
This seems like a bad idea. Let's take a case where language spoken by a royal was very relevant: Charles V, Holy Roman Emperor. When he became King of Castile as a teenager, he only really spoke Flemish and didn't speak Castilian Spanish, and needless to say trusted the advisors he could actually talk with (i.e. Flemish / Dutch ones he brought with him). He also then immediately skipped out of Castile to go to proto-Germany to be elected Holy Roman Emperor. This ended up causing a rebellion (Revolt of the Comuneros) which was at least partially justified by Castilian nationalism, and partially by annoyed Castilian elites who wanted cushy government jobs. So language-of-royal was relevant. But... the Infobox is for the person as a whole. Charles came back to Castile and spent a stretch of 10 years there and eventually learned rather good Castilian and largely assuaged the elite, at least. He was king of Spain for forty years. So it would seem rather petty to harp on the fact his first language wasn't Castilian in the Infobox, when he certainly did speak it later and through most of his reign, even if not his first few years when he was still basically a kid. SnowFire (talk) 19:47, 9 December 2024 (UTC)[reply]
SnowFire's fascinating anecdote shows that this information is not appropriate for infoboxes but rather should be described in prose in the body of the article where the subtleties can be explained to the readers. Cullen328 (talk) 19:56, 9 December 2024 (UTC)[reply]
No, it shows that it's not appropriate for that infobox, and therefore that it is not suitable for all infoboxes where it is plausibly relevant. It shows nothing about whether it is or is not appropriate for other infoboxes: the plural of anecdote is not data. Thryduulf (talk) 21:08, 9 December 2024 (UTC)[reply]
But it kind of is here? I picked this example as maybe one of the most obviously relevant cases. Most royals failing to speak the right language don't have this trait linked with a literal war in reliable sources! But if inclusion of this piece of information in an Infobox is still problematic in this case, how could it possibly be relevant in the 99.9% cases of lesser importance? The Infobox isn't for every single true fact. SnowFire (talk) 21:53, 9 December 2024 (UTC)[reply]
It isn't suitable for this infobox not because of a lack of importance, but because stating a single first language would be misleading. There exists the very real possibility of cases where it is both important and simple. Thryduulf (talk) 00:02, 10 December 2024 (UTC)[reply]
Could you (or anyone else in favor of the proposal) identify 5 biographies where this information is both useful to readers and clearly backed by reliable sources? signed, Rosguilltalk15:06, 11 December 2024 (UTC)[reply]
Sorry, this is just nonsense! Charles V was raised speaking French, which was the language of his aunt's court, although in the Dutch-speaking Mechelen. All his personal letters use French. He only began to be taught Dutch when he was 14, & may never have been much good at it (or Spanish or German). Contrary to the famous anecdote, which is rather late and dubious ("Spanish to God....German to my horse") he seems to have been a rather poor linguist, which was indeed awkward at times. Johnbod (talk) 00:39, 10 December 2024 (UTC)[reply]
(This is a bit off-topic, but "nonsense" is too harsh. I'm familiar that he spoke "French" too, yes, although my understanding was that he did speak "Flemish", i.e. the local Dutch-inflected speech, too? And neither 1500-era French nor Dutch were exactly standardized, so I left it as "Flemish" above for simplicity. If his Dutch was worse than I thought, sure, doesn't really affect the point made, though, which was that his Castilian was non-existent at first. As far as his later understanding of Spanish, his capacity was clearly enough - at the very least I've seen sources say he made it work and it was enough to stave off further discontent from the nobility. Take it up with the authors of the sources, not me.). SnowFire (talk) 16:23, 10 December 2024 (UTC)[reply]
There's a difference between "simplicity" and just being wrong! You should try reading the sources, with which I have no issue. And his ministers were also either native Francophones, like Cardinal Granvelle and his father Nicolas Perrenot de Granvelle (both from Besançon, now in eastern France), or could speak it well; the Burgundian elite had been Francophone for a long time. The backwash from all this remains a somewhat sensitive issue in Belgium, even now. And Charles V was not "King of Spain" (a title he avoided using) for 40 years at all; only after his mother died in 1555 (a year before him) did he become unarguably King of Castile. Johnbod (talk) 14:26, 11 December 2024 (UTC)[reply]
It may not be appropriate for many articles, but it surely is for some. For example, when I told her that England had had kings whose first language was German, someone asked me the other day how many. It would be good to have a quick way of looking up the 18th century Georges to find out. Phil Bridger (talk) 21:20, 9 December 2024 (UTC)[reply]
I think the problem is that people might make assumptions. I would check before saying that George I and George II spoke German as their first language and not French. Languages spoken is probably more useful than birth language, but the list might be incomplete. There is also competing information about George I, and he is an English King, so he has been better researched and documented compared to other historical figures.
Ummmm… no. People I disagree with™️ use “infobox bloat” as a boogeyman in arguments about infoboxes. But this is infobox bloat. Even those celebrity/anime character things that tell you shoe size, pinky length and blood type wouldn’t include this. Dronebogus (talk) 18:16, 11 December 2024 (UTC)[reply]
I don't think there needs to be any central policy on this. It could be relevant to include this information for someone, perhaps... maybe... However, infoboxes work best when they contain uncontroversial at-a-glance facts that don't need a bunch of nuance and context to understand. For the example of Charles V, maybe his first language is significant, but putting it in the infobox (where the accompanying story cannot fit) would be a confusing unexplained factoid. Like, maybe once upon a time there was a notable person whose life turned on the fact that they were left-handed. That could be a great bit of content for the main article, but putting handedness in the infobox would be odd. Barnards.tar.gz (talk) 14:33, 12 December 2024 (UTC)[reply]
Baseball seems to be a good example of where handedness is routinely covered, and easily consumable at a glance without needing further explanation. The scenario where I don't think handedness (or first language) makes sense is when it is a uniquely interesting aspect of that individual's life, because almost by definition there's a story there which the infobox can't tell. Barnards.tar.gz (talk) 10:23, 13 December 2024 (UTC)[reply]
I don't think L1 can be determined for most historical figures without a hefty dose of OR. If you look at my Babel boxes, you'll see that I, as a living human being with all the information about my own life, could not tell you what my own "L1" is. The historical figures for whom this would be relevant mostly spoke many more languages than I do, and without a time machine it would be nigh impossible to say which language they learned first. This isn't even clear for the Qing emperors – I am fairly certain that they all spoke (Mandarin) Chinese very well, and our article never says what language they spoke. Puyi even states that he never spoke Manchu. Adding this parameter would also inflame existing debates across the encyclopedia about ethnonationalism (e.g. Nicola Tesla) and infobox bloat. Toadspike[Talk]21:21, 12 December 2024 (UTC)[reply]
As with every bit of information in every infobox, if it cannot be reliably sourced it does not go in, regardless of how important it is or isn't. There are plenty of examples of people whose first language is reported in reliable sources, I just did an internal source for "first language was" and on the first page of results found sourced mentions of first language at Danny Driver, Cleopatra, Ruthanne Lum McCunn, Nina Fedoroff, Jason Derulo, Henry Taube and Tom Segev, and an unsourced but plausible mention at Dean Martin. The article strongly suggests that her first language is an important part of Cleopatra's biography such that putting it in the infobox would be justifiable. I am not familiar enough with any of the others to have an opinion on whether it merits an infobox mention there, I'm simply reporting that there are many articles where first language is reliably sourced and a mention is deemed DUE. Thryduulf (talk) 22:08, 12 December 2024 (UTC)[reply]
I have been wondering since this conversation opened how far back the concept of an L1 language, or perhaps the most colloquial first language, can be pushed. Our article doesn't have anything on the history of the concept. CMD (talk) 11:31, 13 December 2024 (UTC)[reply]
I suspect the concept is pretty ancient, I certainly wouldn't be surprised to learn it arose around the same time as diplomacy between groups of people with different first languages. The note about it at Cleopatra certainly suggests it was already a well-established concept in her era (1st century BCE). Thryduulf (talk) 13:23, 13 December 2024 (UTC)[reply]
The concept of different social strata speaking different languages is old, but I'm not sure whether they viewed learning languages the same way we do. It's certainly possible, and perhaps it happened in some areas at some times, but I hesitate to assume it's the case for every historical person with an infobox. CMD (talk) 16:05, 13 December 2024 (UTC)[reply]
It's certainly not going to be appropriate for the infobox of every historical person, as is true for (nearly?) every parameter. The questions here are whether it is appropriate in any cases, and if so in enough cases to justify having it as a parameter (how many is enough? I'd say a few dozen at minimum, ideally more). I think the answer the first question is "yes". The second question hasn't been answered yet, and I don't think we have enough information here yet to answer it. Thryduulf (talk) 21:54, 13 December 2024 (UTC)[reply]
The question is not whether it is appropriate in any cases; the question is whether it is worth the trouble. I guarantee that this would lead to many vicious debates, despite being in most cases an irrelevant and unverifiable factoid based on inappropriate ABOUTSELF. This is the same reason we have MOS:ETHNICITY/NATIONALITY. Toadspike[Talk]07:29, 16 December 2024 (UTC)[reply]
Nah. If this were "a very basic and useful piece of information" then we would already be deploying it site wide, so it obviously is not. In the vast majority of cases, it would involve intolerable WP:OR or even just guessing masquerading as facts. We do not know for certain that someone born in France had French as their first/native/home language. I have close relatives in the US, in a largely English-speaking part of the US, whose first language is Spanish. For historical figures it would get even more ridiculous, since even our conceptions of languages today as, e.g., "German" and "French" and "Spanish" and "Japanese", is a bit fictive and is certainly not historically accurate, because multiple languages were (and still are, actually) spoken in these places. We would have no way to ascertain which was used originally or most natively for the average historical figure. Beyond a certain comparatively recent point, most linguistics is reconstruction (i.e. educated guesswork; if there's not a substantial corpus of surviving written material we cannot be sure. That matters a lot for figures like Genghis Khan and King Bridei I of the Picts. Finally, it really is just trivia in the vast majority of cases. What a biographical figure's first/primary/home/most-fluent/most-frequently-used language (and some of those might not be the same since all of them can change over time other than "first") is something that could be included when certain from RS, but it's not lead- or infobox-worthy in most cases, unless it pertains directly the subject's notability (e.g. as a writer) and also isn't already implicit from other details like nationality. — SMcCandlish☏¢ 😼 03:42, 23 December 2024 (UTC)[reply]
Restrict new users from crosswiki uploading files to Commons
I created this Phabricator ticket (phab:T370598) in July of this year, figuring that consensus to restrict non-confirmed users from crosswiki uploading files to Commons is implied. Well, consensus already agreed at Commons in response to the WMF study on crosswiki uploading. I created an attempted Wish at Meta-wiki, which was then rejected, i.e. "archived", as policy-related and requir[ing] alignment across various wikis to implement such a policy. Now I'm starting this thread, thinking that the consensus here would already or implicitly support such restriction, but I can stand corrected about the outcome here. George Ho (talk) 06:34, 9 December 2024 (UTC); corrected, 08:10, 9 December 2024 (UTC)[reply]
Support. I am not sure why this relies on alignment across wikis, those on Commons are best placed to know what is making it to Commons. The change would have little to no impact on en.wiki. If there is an impact, it would presumably be less cleaning up of presumably fair use files migrated to Commons that need to be fixed here. That said, if there needs to be consensus, then obviously support. We shouldn't need months of bureaucracy for this. CMD (talk) 06:41, 9 December 2024 (UTC)[reply]
Support, I don't know that my input really counts as new consensus because I said this at the time, but the problem is much worse than what the study suggests as we are still finding spam, copyvios, unusable selfies and other speedy-deletable uploads from the timespan audited.
Support. I do think that disabling the ability for new editors on the English Wikipedia from engaging in crosswiki uploads to Commons would be a net positive; the Commons community has come to this conclusion several times, and the research confirms that cross-wiki uploads by new users cause more trouble than the good uploads worth. — Red-tailed hawk(nest)00:36, 11 December 2024 (UTC)[reply]
I don't think this should be any sort of enwiki policy. If commonswiki wants to restrict something that should be up to them. I can't possibly see how it would need to be specific to the English Wikipedia (i.e. but not about new users on dewiki, eswikt, etc). — xaosfluxTalk16:19, 11 December 2024 (UTC)[reply]
As noted by George Ho above, Commons has already done this for all wikis. The question is whether or not we want the English Wikipedia to assist in implementing this (perhaps by changing a local setting or software configuration to require that their uploads be local), rather than merely relying upon a Commons edit filter (which can be a bit unfriendly to new users). — Red-tailed hawk(nest)19:50, 11 December 2024 (UTC)[reply]
This comment interests me: "Interestingly, we found that most uploaders were either marketers (editing/uploading on behalf of another entity such as their employer), or they were self-promoters (creating pages about themselves, unaware of the "notability" requirement)."
So I wonder whether, instead of stopping this, we want a bot to look at newbies who create articles/drafts, check whether they uploaded something, and then tag both the image(s) and the pages here with a note that says something like "There is a 90% chance that this has been posted by a marketer or self-promoter", with suitable links to pages such as Wikipedia:Paid-contribution disclosure. Or maybe even a WP:STICKYPROD process.
On the question of what to do, it should be possible to hide the cross-wiki upload button. The real question is, do we replace it with a link to c:Special:UploadWizard? The Commons POV has been that it's bad for people to upload images within the visual editor, but okay for the same person to upload the same image with the UploadWizard. I'm not sure the net result is actually any different, especially for these marketers/self-promoters (in terms of net quality/acceptability; from Commons' POV, it's better because (a lot? a little?) fewer of them will click through to upload anything at Commons). WhatamIdoing (talk) 19:49, 12 December 2024 (UTC)[reply]
Support It's honestly kinda dumb that we have to have this whole other consensus process after the prior one just because people at Meta-wiki don't want to implement it. SilverserenC20:35, 13 December 2024 (UTC)[reply]
Support, since this has already been decided and WMF is just being recalictrant. WP:NOT#BUREAUCRACY, and Commons isn't one either, nor is Wikitionary, etc., and to the extent WMF wants to be one that needs to be nipped in the bud. — SMcCandlish☏¢ 😼 03:44, 23 December 2024 (UTC)[reply]
Here are two mostly unrelated questions that came up in the course of a Deletion Review. The DRV is ready for closure, because the appellant has been blocked for advertising, but I think that the questions should be asked, and maybe answered. Robert McClenon (talk) 20:44, 11 December 2024 (UTC)[reply]
At DRV, there are sometimes requests to restore to draft space or user space material from pages that were deleted as G11, purely promotional material. DRV is sometimes the second or third stop for the originator, with the earlier stops being the
deleting administrator and Requests for Undeletion.
Requests for Undeletion has a list of speedy deletion codes for which deleted material is not restored, including G11. (They say that they do not restore attack pages or copyright violation. They also do not restore vandalism and spam.) Sometimes the originator says that they are trying to rewrite the article to be neutral. My question is whether DRV should consider such requests on a case-by-case basis, as is requested by the originators, or whether DRV should deny the requests categorically, just as they are denied at Requests for Undeletion. I personally have no sympathy for an editor who lost all of their work on a page because it was deleted and they didn't back it up. My own opinion is that they should have kept a copy on their hard drive (or solid-state device), but that is my opinion.
We know that the decision that a page should be speedily deleted as G11 may properly be appealed to Deletion Review. My question is about requests to restore a draft that was properly deleted as G11 so that the originator can work to make it neutral.
I am also not asking about requests for assistance in telling an author what parts of a deleted page were problematic. In those cases, the author is asking the Wikipedia community to write their promotional article for them, and we should not do that. But should we consider a request to restore the deleted material so that the originator can make it neutral?
Robert McClenon (talk) 20:44, 11 December 2024 (UTC)[reply]
When we delete an article we should always answer reasonable questions asked in good faith about why we deleted it, and that includes explaining why we regard an article as promotional. We want neutral encyclopaedic content on every notable subject, if someone wants to write about that subject we should encourage and teach them to write neutral encyclopaedic prose about the subject rather than telling them to go away and stop trying because they didn't get it right first time. This will encourage them to become productive Wikipedians, which benefits the project far more than the alternatives, which include them trying to sneak promotional content onto Wikipedia and/or paying someone else to do that. So, to answer your question, DRV absolutely should restore (to draft or userspace) articles about notable subjects speedily deleted per G11. Thryduulf (talk) 21:09, 11 December 2024 (UTC)[reply]
If the material is truly unambiguous advertising, then there's no point in restoring it. Unambiguous advertising could look like this:
If it's really unambiguous advertising to this level, then you don't need a REFUND. (You might ask an admin to see if there were any independent sources they could share with you, though.)
When it's not quite so blatant, then a REFUND might be useful. Wikipedia:Identifying blatant advertising gives some not-so-blatant, not-so-unambiguous examples of suspicious wording, such as:
It refers to the company or organization in the first-person ("We are a company based out of Chicago", "Our products are electronics and medical supplies").
This kind of thing makes me suspect WP:PAID editing, but it's not irredeemable, especially if it's occasional, or that's the worst of it. But in that case, it shouldn't have been deleted as G11. WhatamIdoing (talk) 21:37, 12 December 2024 (UTC)[reply]
Blanket permission to restore every G11 to userspace or draftspace might make sense if you're, say, an admin who's mentioned G11 only once in his delete logs over the past ten years. Admins who actually deal with this stuff are going to have a better feel for how many are deleted from userspace or draftspace to begin with (just short of 92% in 2024) and how likely a new user who writes a page espousing how "This technical expertise allows him to focus on the intricate details of design and construction, ensuring the highest standards of quality in every watch he creates" is to ever become a productive Wikipedian (never that I've seen). If it wasn't entirely unsalvageable, it wasn't a good G11 to begin with. —Cryptic14:05, 13 December 2024 (UTC)[reply]
Some administrators have semi-protected their talk pages due to abuse by unregistered editors. An appellant at DRV complained that they were unable to request the deleting administrator about a G11 because the talk page was semi-protected, and because WP:AN was semi-protected. An editor said that this raised Administrator Accountability issues. My question is whether they were correct about administrator accountability issues. My own thought is that administrator accountability is satisfied if the administrator has incoming email enabled, but the question was raised by an experienced editor, and I thought it should be asked.
Robert McClenon (talk) 20:44, 11 December 2024 (UTC)[reply]
Administrators need to be reasonably contactable. Administrators explicitly are not required to have email enabled, and we do not require other editors to have email enabled either (a pre-requisite to sending an email through Wikipedia), and several processes require leaving talk pages messages for administrators (e.g. ANI). Additionally, Sending an email via the Special:EmailUser system will disclose your email address, so we cannot compel any editor to use email. Putting this all together, it seems clear to me that accepting email does not automatically satisfy administrator accountability. Protecting talk pages to deal with abuse should only be done where absolutely necessary (in the case of a single editor doing the harassing, that editor should be (partially) blocked instead for example) and for the shortest amount of time necessary, and should explicitly give other on-wiki options for those who cannot edit the page but need to leave the editor a message. Those alternatives could be to leave a message on a different page, to use pings, or some other method. Where no such alternatives are given I would argue that the editor should use {{help me}} on their own talk page, asking someone else to copy a message to the admin's talk page. Thryduulf (talk) 21:22, 11 December 2024 (UTC)[reply]
Very few admins protect their talk pages, and for the ones I'm aware of, it's for very good reasons. Admins do not need to risk long-term harassment just because someone else might want to talk to them.
It would make sense for us to suggest an alternative route. That could be to post on your own talk page and ping them, or it could be to post at (e.g.,) WP:AN for any admin. The latter has the advantage of working even when the admin is inactive/no longer an admin. WhatamIdoing (talk) 21:42, 12 December 2024 (UTC)[reply]
That says "Users whose talk pages are protected may wish to have an unprotected user talk subpage linked conspicuously from their main talk page to allow good-faith comments from users that the protection restricts editing from."
Would there be value is changing that to requiring users whose talk page is protected to conspicuously state an alternative on-wiki method of contacting them, giving an unprotected talk subpage as one example method? Thryduulf (talk) 21:40, 13 December 2024 (UTC)[reply]
In general user talk pages shouldn't be protected, but there may be instances when that is needed. However ADMINACCT only requires that admins respond to community concerns, it doesn't require that the talk pages of an admin is always available. There are other methods of communicating, as others have mentioned. There's nothing in ADMINACCT that says a protected user talk page is an accountability issue. -- LCU ActivelyDisinterested«@» °∆t°22:33, 12 December 2024 (UTC)[reply]
Question(s) stemming from undiscussed move
"AIM-174 air-to-air missile" was moved without discussion to "AIM-174B." Consensus was reached RE: the removal of "air-to-air missile," but no consensus was reached regarding the addition or removal of the "B." After a no-consensus RM close (which should have brought us back to the original title, sans agreed-upon unneeded additional disambiguator, in my opinion), I requested the discussion be re-opened, per pre-MRV policy. (TO BE CLEAR; I should have, at this time, requested immediate reversion. However, I did not want to be impolite or pushy) The original closer -- Asukite (who found for "no consensus") was concerned they had become "too involved" in the process and requested another closer. Said closer immediately found consensus for "AIM-174B." I pressed-on to a MRV, where an additional "no consensus" (to overturn) finding was issued. As Bobby Cohn pointed-out during the move review, "I take issue with the participating mover's interpretation of policy 'Unfortunately for you, a no consensus decision will result in this article staying here' in the RM, and would instead endorse your idea that aligns with policy, that a no consensus would take us back the original title, sans extra disambiguatotr."
The issues, as I see them, are as-follows:
WP:RMUM: The move from “AIM-174 air-to-air missile” to “AIM-174B” was conducted without discussion, and I maintain all post-move discussions have achieved "no consensus."
Burden of Proof: The onus should be on the mover of the undiscussed title to justify their change, not on others to defend the original title. I refrained from reverting prior to initiating the RM process out of politeness, which should not shift the burden of proof onto me.
Precedent: I am concerned with the precedent. Undiscussed moves may be brute-forced into acceptance even if "no consensus" or a very slim consensus (WP:NOTAVOTE) is found?
Do my policy contentions hold any weight? Or am I mad? Do I have any path forward, here?
TO BE CLEAR, I am not alleging bad faith on behalf of anyone, and I am extremely grateful to all those who have been involved, particularly the RM closer that I mentioned, as well as the MRV closer, ModernDayTrilobite. I would like to make it clear that this isn't simply a case of a MRV 'not going my way.' Again, I am concerned w/ the precedent and with the onus having been shifted to me for months. I also apologize for the delay in getting this here; I originally stopped-over at the DRN but Robert McClenon kindly suggested I instead post here.MWFwiki (talk) 00:08, 12 December 2024 (UTC)[reply]
I am quite familiar with it. It seemingly supports my argument(s), so...? Is there a particular reason you're speaking in quasi-riddles? MWFwiki (talk) 01:11, 13 December 2024 (UTC)[reply]
If yours is the title favored by the policy, then none of this explanation makes any difference. You just demand that it be put back to the title favored by the policy, and editors will usually go along with it. (It sometimes requires spelling out the policy in detail, but ultimately, most people want to comply with the policy.)
If yours is not the title favored by the policy, then the people on the other 'side' are going to stand on policy when you ask to move it, so you'd probably have to get the policy changed to 'win'. If you want to pursue that, you will need to understand why the rule is set this way, so that you have a chance of making a convincing argument. WhatamIdoing (talk) 05:24, 13 December 2024 (UTC)[reply]
I think several individuals involved in this process have agreed that the default title is the favored title, at least as far as WP:TITLECHANGES, as you say. (The only reason I listed any further ‘litigation’ here is to show what was being discussed in-general for convenience’s sake, not necessarily to re-litigate) However, at least two individuals involved have expressed to me that they felt their hands were tied by the RM/MRV process. Otherwise, as I mentioned (well, as Bobby_Cohn mentioned) the train of thought seemed to be “well, I don’t want the title to be changed,” and this was seemingly enough to override policy. Or, at best, it was seemingly a “well, it would be easier to just leave it as-is” sort of decision.
And again, I, 100%, should have been more forceful; The title anhould have been reverted per the initial “no consensus” RM-closure and I will certainly bear your advice in-mind in the future. That said, I suppose what I am asking is would it be inappropriate to ask the original RM-closer to revert the article at this point, given how much time is past?
Given what was written in Talk:AIM-174B#Requested move 20 September 2024 six weeks ago, I think that none of this is relevant. "Consensus to keep current name" does not mean that you get to invoke rules about what happens when there is no consensus. I suggest that you give up for now, wait a long time (a year? There is no set time, but it needs to be a l-o-n-g time), and maybe start a new Wikipedia:Requested moves (e.g., in 2026). WhatamIdoing (talk) 19:41, 13 December 2024 (UTC)[reply]
Everything ModernDayTrilobite advised you of is correct. Vpab15 closed the RM and determined that consensus was reached. Nothing since then has overturned or otherwise superseded Vpab15's closure. Therefore that closure remains in force. You already challenged the validity of Vpab15's closure at move review, and you have no avenue for challenging it again. Your best bet is to wait a tactful amount of time (several months) before starting another RM. And in that RM, none of this procedural stuff will matter, and you will be free to focus just on making the clearest, simplest case for why AIM-174 is the best title. Adumbrativus (talk) 06:10, 13 December 2024 (UTC)[reply]
I suppose my issue is better summed-up by my above discussion with WhatamIdoing; The MRV shouldn’t have been required. That burden should never have been on me. The title should have been reverted at the initial “no consensus” per WP:TITLECHANGES. Otherwise, undiscussed moves — when challenged — may now be upheld by either consensus or no consensus? This is not what WP:TITLECHANGES says, obviously. That said I take full responsibility for not being clearer with this argument, and instead focusing on arguing for a ‘different’ title, when I should have been arguing for the default title per TITLECHANGES. MWFwiki (talk) 06:33, 13 December 2024 (UTC)[reply]
You've repeatedly pointed to the initial self-reverted closure as if it's somehow significant. It isn't. Asukite voluntarily decided to close the discussion, and voluntarily self-reverted their decision to close. It doesn't matter whether you asked for it or someone else asked or no one asked. They had the right to self-revert then, for any reason or no reason. The net result is the same as if Asukite had never closed it at all. Only Vpab15's closure, which was 100% on Vpab15's own authority and 0% on the supposed authority of the annulled earlier closure, is binding. Adumbrativus (talk) 09:22, 13 December 2024 (UTC)[reply]
I don't disagree with your latter statement, but why would an initial finding of no-consensus not matter? It should have brought us back to the default title, not simply been reverted. Because that policy wasn't followed, I'm here now, is my point. Regardless, I understand; Thank you for your advice! Well, I appreciate your time and consideration! :-) MWFwiki (talk) 05:08, 14 December 2024 (UTC)[reply]
(Involved at the MRV) Seeing as I've been tagged in this multiple times and quoted, I'll give my thoughts on this. I don't want to accuse MWFwiki of selectively quoting me but I do think that my quote above was, when taken into account with the following discussion, more about meta-conversation about the correct policy to implement in the event the MRV went the other way. I explicitly said in the immediately following message the view that the close was not outside the scope of WP:RMCI is reasonable and good faith interpretation. I do think this close was within bounds, and the following MRV appropriately closed and summarised.
Yes, had the original close of no consensus stood, then it could have been reverted wholecloth. It was self-reverted and therefore plays no role in the consideration of the subsequent closure. We're always going to take the most recent finding of consensus to be what holds. It seems to have been said in the above that had the no consensus closure held and the appropriate WP:RMNCREV policy been applied, then the appellant here would have gotten their preferred outcome. But to continue to argue this in the face of the subsequent developments is where this enters wikilawyering territory. I think that since then, the appellant has continued to make policy arguments that would be better suited for a subsequent and focused RM on the actual title rather than wikilawyer about a previous close that was self-reverted and continuing to argue policy.
There's nothing for this venue to really change in regards to that AT and the discussion to change the AT would need to be had at the articles talk page. My sincere advice to appellant is to wait a reasonable amount of time and make strong policy based arguments about the preferred title (don't just quote policy, we editors are good at clicking links and reading it for ourselves—quoting nothing but policy back at us makes us feel like you've taken us for fools; instead provide facts and sources that support the relevant policies and link those). Spend some time at WP:RMC and see what well-argued and successful RMs typically look like. Bobby Cohn (talk) 17:38, 17 December 2024 (UTC)[reply]
CSD A12. Substantially written using a large language model, with hallucinated information or fictitious references
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.
When fixing up new articles, I have encountered articles that appear to have been substantially generated by AI, containing hallucinated information. While these articles may not meet other criteria for speedy deletion, as the subjects themselves are sometimes real and notable, waiting for seven days to PROD the articles is inefficient. I recommend designating WP:A12 for the speedy deletion of these articles. I have created a template (User:Svampesky/Template:Db-a12) if it is successful. A recent example is the article on the Boston University Investment Office, where the author explicitly disclosed that it was created using a large language model and contains references to sources don't exist. I initially G11'd it, as it seemed the most appropriate, but was declined, and the article was subsequently PRODed. Svampesky (talk) 21:13, 12 December 2024 (UTC)[reply]
CSD are generally limited to things that are unambiguously obvious. I image the number of cases in which it's unabiguously obvious that the entire page was generated by an LLM (as opposed to the editor jut using the LLM to generate references, for example) are small enough that it doesn't warrant a speedy deletion criterion. --Ahecht (TALK PAGE)21:29, 12 December 2024 (UTC)[reply]
I don't think it even merits a policy page. The number of cases where the LLM use is objectively unambiguous, and the article content sufficiently problematic that deletion is the only appropriate course of action and it cannot be (speedily) deleted under existing policy is going to be vanishingly small. Even the OP's examples were handled by existing processes (PROD) sufficiently. Thryduulf (talk) 22:11, 12 December 2024 (UTC)[reply]
Efficiency usually compares the amount of effort something takes, not the length of time it takes. "Paint it and leave it alone for 10 minutes to dry" is the same amount of hands-on work as "Paint it and leave it alone for 10 days to dry", so they're equally efficient processes. It sounds like you want a process that isn't less hands-on work/more efficient, but instead a process that is faster.
Also, if the subject qualifies for an article, then deletion isn't necessarily the right solution. Blanking bad content and bad sources is officially preferred (though more work) so that there is only verifiable content with one or more real sources left on the page – even if that content is only a single sentence.
Efficiency and speed is something that many editors like. However, there has to be a balance. We're WP:HERE to build an encyclopedia, which sometimes means that rapidly removing imperfect content is only the second or third most important thing we do. WhatamIdoing (talk) 00:43, 13 December 2024 (UTC)[reply]
This part as the subjects themselves are sometimes real and notable is literally an inherent argument against using CSD (or PROD for that matter). WP:TNT the article to a sentence if necessary, but admitting that you're trying to delete an article you know is notable just means you're admitting to vandalism. SilverserenC00:07, 13 December 2024 (UTC)[reply]
The categorization of my proposal as admitting to vandalism is incorrect. WP:G11, the speedy deletion criterion I initially used for the article, specifies deleting articles that would need to be fundamentally rewritten to serve as encyclopedia articles. Articles that have been generated using large language models, with hallucinated information or fictitious references, would need to be fundamentally rewritten to serve as encyclopedia articles. Svampesky (talk) 00:42, 13 December 2024 (UTC)[reply]
Yes, but G11 is looking for blatant advertising ("Buy widgets now at www.widgets.com! Blue-green widgets in stock today!") It's not looking for anything and everything that needs to be fundamentally re-written. WhatamIdoing (talk) 00:45, 13 December 2024 (UTC)[reply]
(Edit Conflict) How does G11 even apply here? Being written via LLM does not make an article "promotional". Furthermore, even that CSD criteria states If a subject is notable and the content could plausibly be replaced with text written from a neutral point of view, this is preferable to deletion. I.e. TNT it to a single sentence and problem solved. SilverserenC00:46, 13 December 2024 (UTC)[reply]
If the hallucination is sufficiently dramatic ("Joe Film is a superhero action figure", when it ought to say that he's an actor who once had a part in a superhero movie), then you might be able to make a good case for {{db-hoax}}. WhatamIdoing (talk) 05:26, 13 December 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
AFD clarification
The Articles for deletion article states that:
If a redirection is controversial, however, AfD may be an appropriate venue for discussing the change in addition to the article's talk page.
Have an ordinary discussion on the talk page about redirecting the page.
If (and only if) that discussion fails to reach consensus, try again at AFD.
I dislike starting with AFD. It isn't usually necessary, and it sometimes has a feel of the nom trying to get rid of it through any means possible ("I'll suggest a WP:BLAR, but maybe I'll be lucky and they'll delete it completely"). WhatamIdoing (talk) 05:31, 13 December 2024 (UTC)[reply]
Would need some stats on the it isn't usually necessary claim, my intuition based on experience is that if a BLAR is contested it's either dropped or ends up at AfD. CMD (talk) 05:48, 13 December 2024 (UTC)[reply]
It depends how active the respective talk pages are (redirected article and target), but certainly for ones that are quiet AfD is going to be the most common. Thryduulf (talk) 09:33, 13 December 2024 (UTC)[reply]
For me, it's lack of participation, no tool to list something at PAM, and no relisting option so proposed merges just sit for a very long time before being closed. voorts (talk/contributions) 23:21, 16 December 2024 (UTC)[reply]
What voorts said. Multiple times now I've floated the idea of making PAM more like RM, one of these years I should really get around to doing something more than that. I won't have time before the new year though. Thryduulf (talk) 23:45, 16 December 2024 (UTC)[reply]
Merging often involves questions of overlap and topical distinction rather than just notability, although this also ends up discussed at AfD. I do wonder if this would leave proposals to split out in the cold though, as much like merge discussions they just sit there. CMD (talk) 04:00, 17 December 2024 (UTC)[reply]
The most important tool is Twinkle > Tag > Merge. I personally prefer its "Merge to" option, but there's a plain "Merge" if you don't know exactly which page should be the target.
All merges get bot-listed in Wikipedia:Article alerts. Wikipedia:Proposed article mergers is another place to advertise it, and I'd bet that Twinkle could post those automatically with relatively little work (an optional button, similar to notifying the creator of deletion plans).
I dislike "relisting"; things should just stay open as long as they need to, without adding decorative comments about the discussion not happening fast enough. In my experience, merge proposals stay open because everyone's agreed on the outcome but nobody wants to do the work. WhatamIdoing (talk) 06:46, 17 December 2024 (UTC)[reply]
It's only a deletion if an admin pushes the delete button. Blanking and redirecting – even blanking, redirecting, and full-protecting the redirect so nobody can un-redirect it – is not deletion. WhatamIdoing (talk) 07:34, 18 December 2024 (UTC)[reply]
That might be clear to you (and the other admins) but almost nobody in the general community understands that (to the point where I would say its just wrong, deletion is broader than that in practice). Horse Eye's Back (talk) 16:23, 18 December 2024 (UTC)[reply]
Well, it has always been clear to me, and I am not, and have never wished to be, an admin. But, then again, I am a bit strange in that I expect things to be as people say that they will be. Phil Bridger (talk) 18:34, 18 December 2024 (UTC)[reply]
Contested redirects going to AfD makes sense. Articles are redirected for the same reasons they're deleted and redirecting is probably the most common ATD. I've opened plenty of AfDs where my nom recommends a redirect instead of deletion, including when I've BLARed an article and had the BLAR reverted. voorts (talk/contributions) 18:38, 18 December 2024 (UTC)[reply]
If a redirect has already been discussed or attempted, and consensus can't be reached easily, then I've got no problem with AFD. What I don't want to see is no discussion, no bold redirects, nobody's even hinted about a merge, and now it's at AFD, when the problem could have been resolved through a less intense method. WhatamIdoing (talk) 19:07, 18 December 2024 (UTC)[reply]
Dispute and conflict in the Autism article, would not let add "unbalanced" tag
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.
Hello all, I can only occasionally attend Wikipedia to edit or respond. I recently went through the current version of the Wikipedia article on Autism , and I found that this article is NOT representing the reality or encyclopedic wholeness. The huge, verbose, highly technical article is biased towards medical model of disability, medical genetics, and nearly zero information regarding the anthropology, evolution, neurodiversity, accommodation, accessibility, Augmentative and alternative communications, and all that actually helps wellbeing of Autistic people. The page boldly focuses on controversial methods such as ABA, such as EIBI (Early intensive behavioral interventions), DTT (discrete trial training) etc. without any mention of the concerns or criticisms against them. I entered the talk page, but it has been turned literally into a warzone, where any dissenting viewpoint is being silenced in name of "global and unanimous scientific consensus" which is simply wrong. It is mostly a view held by biomedical and pharmaceutical majority. But outside of that, opposing viewpoints do exist in actual Autistic populations (who have the lived experience), anthropology, sociology, psychology, etc. I added an "unbalanced" tag for reader information (I did not speak for complete erasure of controversial viewpoints, just needed the reader to know that there are other views), however the "unbalanced" tag was soon reverted.
It is not possible for me to daily attend and post arguments and counter-arguments. I have to acknowledge that, if this kind of silencing continues, this time Wikipedia literally failed as an encyclopedia, as well it failed at public health and education welfare perspective.
I feel like this needs editors' attention. Autism is NOT a well-understood condition by majority, Lived experience play the ultimate role on how a person feel about their life situation, and Nothing about us without us is an important ethics rule in disability cultures.
It worth mentioning, each disabilities are unique, and their lived experiences are different. There are generally 2 paradigms:
(1) As if there is a fixed, "normal", gold standard "healthy people", a deviation from that is a pathology, and the society is flawless and 'just'; and any outliers must be assimilated or conformed into the mainstream, or eradicated. It externally defines what is a good life.
(2) The second paradigm says, a disability (better said disablement, or dis-abled as a verb) is that the human bodies and minds are inherently diverse, varying, and evolving, with no single fixed "one size fits all" baseline. Also a same person can vary in multiple dimensions (such as seen in Twice exceptional), and the value of a person shouldn't depend on productivity, coincidence of wants is a fallacy; society is NOT just, it needs to be accommodated.
It seems most disabilities fall between a spectrum between a medical impairment and a social incompatibility, rather than purely one end. However, Autism, being mostly a social and communication difference, falls mostly in the second type, and seem to be addressed better with the second (inside out) approach.
Without commenting on the actual topic, I would say this sounds like just a content dispute localised on one article, and should be undertaken at the talk page rather than here. If there are reliable relevant sources that are in scope then this topic could be added to the article, but it is your responsibility to find those sources and to defend them if questioned. BugGhost🦗👻11:35, 13 December 2024 (UTC)[reply]
Thank you, but the dispute is too intense. Also some policies like "nothing about us without us" should be in Wikipedia policy, especially about when a majority voice can suppress a marginalized voice. Esp. information those affect minority groups. Or the voices not well represented, and therefore needs amplification. RIT RAJARSHI (talk) 12:39, 13 December 2024 (UTC)[reply]
I've just had a look at the talk page, and I don't think it is by any means too intense. You said your view, with minimal sources, and @Димитрий Улянов Иванов replied cordially to you addressing your concerns. Your reply was to say "stop name calling" (I couldn't see any evidence of name calling) and not much else. Again: I'm not commenting on the actual substance of your point of view - just that, as it stands, the talk page is the right place for this discussion, and you should engage with it in earnest with sources to back your view up. (I support any editor who wants to hat this section.) BugGhost🦗👻14:52, 13 December 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Option 1 – Require former administrators to request restoration of their tools at the bureaucrats' noticeboard (BN) if they are eligible to do so (i.e., they do not fit into any of the exceptions).
Option 2 – Clarify Maintain the status quo that former administrators who would be eligible to request restoration via BN may instead request restoration of their tools via a voluntary request for adminship (RfA).
Option 3 – Allow bureaucrats to SNOW-close RfAs as successful if (a) 48 hours have passed, (b) the editor has right of resysop, and (c) a SNOW close is warranted.
2, after thought. I don't think 3 provides much benefit, and creating separate class of RfAs that are speedy passed feels a misstep. If there are serious issues surrounding wasting time on RfAs set up under what might feel to someone like misleading pretenses, that is best solved by putting some indicator next to their RFA candidate name. Maybe "Hog Farm (RRfA)". CMD (talk) 14:49, 16 December 2024 (UTC)[reply]
best solved by putting some indicator next to their RFA candidate name. Maybe "Hog Farm (RRfA)" - I like this idea, if option 2 comes out as consensus I think this small change would be a step in the right direction, as the "this isn't the best use of time" crowd (myself included) would be able to quickly identify the type of RFAs they don't want to participate in. BugGhost🦗👻11:05, 17 December 2024 (UTC)[reply]
I think that's a great idea. I would support adding some text encouraging people who are considering seeking reconfirmation to add (RRfA) or (reconfirmation) after their username in the RfA page title. That way people who are averse to reading or participating in reconfirmations can easily avoid them, and no one is confused about what is going on. 28bytes (talk) 14:23, 17 December 2024 (UTC)[reply]
If we are differentiating three types of RFA we need three terms. Post-recall RFAs are referred to as "reconfirmation RFAs", "Re-RFAS" or "RRFAs" in multiple places, so ones of the type being discussed here are the ones that should take the new term. "Voluntary reconfirmation RFA" (VRRFA or just VRFA) is the only thing that comes to mind but others will probably have better ideas. Thryduulf (talk) 21:00, 17 December 2024 (UTC)[reply]
Of course they may request at RfA. They shouldn't but they may. This RfA feels like it does nothing to address the criticism actually in play and per the link to the idea lab discussion it's premature to boot. Barkeep49 (talk) 21:38, 15 December 2024 (UTC)[reply]
2 per my comments at the idea lab discussion and Queent of Hears, Beeblebrox and Scazjmd above. I strongly disagree with Barkeep's comment that "They shouldn't [request the tools back are RFA]". It shouldn't be made mandatory, but it should be encouraged where the time since desysop and/or the last RFA has been lengthy. Thryduulf (talk) 21:42, 15 December 2024 (UTC)[reply]
1 or 3. RFA is an "expensive" process in terms of community time. RFAs that qualify should be fast-tracked via the BN process. It is only recently that a trend has emerged that folks that don't need to RFA are RFAing again. 2 in the last 6 months. If this continues to scale up, it is going to take up a lot of community time, and create noise in the various RFA statistics and RFA notification systems (for example, watchlist notices and User:Enterprisey/rfa-count-toolbar.js). –Novem Linguae (talk) 21:44, 15 December 2024 (UTC)[reply]
Making statistics "noisy" is just a reason to improve the way the statistics are gathered. In this case collecting statistics for reconfirmation RFAs separately from other RFAs would seem to be both very simple and very effective. If (and it is a very big if) the number of reconfirmation RFAs means that notifications are getting overloaded, then we can discuss whether reconfirmation RFAs should be notified differently. As far as differentiating them, that is also trivially simple - just add a parameter to template:RFA (perhaps "reconfirmation=y") that outputs something that bots and scripts can check for. Thryduulf (talk) 22:11, 15 December 2024 (UTC)[reply]
I'm weakly opposed to option 3, editors who want feedback and a renewed mandate from the community should be entitled to it. If they felt that that a quick endorsement was all that was required then could have had that at BN, they explicitly chose not to go that route. Nobody is required to participate in an RFA, so if it is going the way you think it should, or you don't have an opinion, then just don't participate and your time has not been wasted. Thryduulf (talk) 22:20, 15 December 2024 (UTC)[reply]
Added option 3 above. Maybe worth considering as a happy medium, where unsure admins can get a check on their conduct without taking up too much time. theleekycauldron (talk • she/her) 22:11, 15 December 2024 (UTC)[reply]
2 – If a former admin wishes to subject themselves to RfA to be sure they have the requisite community confidence to regain the tools, why should we stop them? Any editor who feels the process is a waste of time is free to ignore any such RfAs. — Jkudlick ⚓ (talk)22:12, 15 December 2024 (UTC)[reply]
I would also support option 3 if the time is extended to 72 hours instead of 48. That, however, is a detail that can be worked out after this RfC. — Jkudlick ⚓ (talk)02:05, 16 December 2024 (UTC)[reply]
A further note: option 3 gives 'crats the discretion to SNOW close a successful voluntary re-RfA; it doesn't require such a SNOW close, and I trust the 'crats to keep an RfA open if an admin has a good reason for doing so. voorts (talk/contributions) 23:24, 16 December 2024 (UTC)[reply]
Option 2 (no change) – The sample size is far too small for us to analyze the impact of such a change, but I believe RfA should always be available. Now that WP:RECALL is policy, returning administrators may worry that they have become out of touch with community norms and may face a recall as soon as they get their tools back at BN. Having this familiar community touchpoint as an option makes a ton of sense, and would be far less disruptive / demoralizing than a potential recall. Taking this route away, even if it remains rarely used, would be detrimental to our desire for increased administrator accountability. – bradv22:22, 15 December 2024 (UTC)[reply]
2, distant second preference 3. I would probably support 3 as first pick if not for recall's rule regarding last RfA, but as it stands, SNOW-closing a discussion that makes someone immune to recall for a year is a non-starter. Between 1 and 2, though, the only argument for 1 seems to be that it avoids a waste of time, for which there is the much simpler solution of not participating and instead doing something else. Special:Random and Wikipedia:Backlog are always there. -- Tamzin[cetacean needed] (they|xe|🤷) 23:31, 15 December 2024 (UTC)[reply]
Option 1. No second preference between 2 or 3. As long as a former administrator didn't resign under a cloud, picking up the tools again should be low friction and low effort for the entire community. If there are issues introduced by the recall process, they should be fixed in the recall policy itself. Daniel Quinlan (talk) 01:19, 16 December 2024 (UTC)[reply]
Option 2, i.e. leave well enough alone. There is really not a problem here that needs fixing. If someone doesn’t want to “waste their time” participating in an RfA that’s not required by policy, they can always, well, not participate in the RfA. No one is required to participate in someone else’s RfA, and I struggle to see the point of participating but then complaining about “having to” participate. 28bytes (talk) 01:24, 16 December 2024 (UTC)[reply]
Option 3: Because it is incredibly silly to have situations like we do now of "this guy did something wrong by doing an RfA that policy explicitly allows, oh well, nothing to do but sit on our hands and dissect the process across three venues and counting." Your time is your own. No one is forcibly stealing it from you. At the same time it is equally silly to let the process drag on, for reasons explained in WP:SNOW. Gnomingstuff (talk) 03:42, 16 December 2024 (UTC)[reply]
Option 3 per Gnoming. I think 2 works, but it is a very long process and for someone to renew their tools, it feels like an unnecessarily long process compared to a normal RfA. Conyo14 (talk) 04:25, 16 December 2024 (UTC)[reply]
As someone who supported both WormTT and Hog Farm's RfAs, option 1 > option 3 >> option 2. At each individual RfA the question is whether or not a specific editor should be an admin, and in both cases I felt that the answer was clearly "yes". However, I agree that RfA is a very intensive process. It requires a lot of time from the community, as others have argued better than I can. I prefer option 1 to option 3 because the existence of the procedure in option 3 implies that it is a good thing to go through 48 hours of RfA to re-request the mop. But anything which saves community time is a good thing. HouseBlaster (talk • he/they) 04:31, 16 December 2024 (UTC)[reply]
I've seen this assertion made multiple times now that [RFA] requires a lot of time from the community, yet nowhere has anybody articulated how why this is true. What time is required, given that nobody is required to participate and everybody who does choose to participate can spend as much or as little time assessing the candidate as they wish? How and why does a reconfirmation RFA require any more time from editors (individually or collectively) than a request at BN? Thryduulf (talk) 04:58, 16 December 2024 (UTC)[reply]
I think there are a number of factors and people are summing it up as "time-wasting" or similar:
BN Is designed for this exact scenario. It's also clearly a less contentious process.
Snow closures a good example of how we try to avoid wasting community time on unnecessary process and the same reasoning applies here. Wikipedia is not a bureaucracy and there's no reason to have a 7-day process when the outcome is a given.
If former administrators continue to choose re-RFAs over BN, it could set a problematic precedent where future re-adminship candidates feel pressured to go through an RFA and all that entails. I don't want to discourage people already vetted by the community from rejoining the ranks.
The RFA process is designed to be a thoughtful review of prospective administrators and I'm concerned these kinds of perfunctory RFAs will lead to people taking the process less seriously in the future.
Because several thousand people have RFA on their watchlist, and thousands more will see the "there's an open RFA" notice on theirs whether they follow it or not. Unlike BN, RFA is a process that depends on community input from a large number of people. In order to even realise that the RFA is not worth their time, they have to:
Read the opening statement and first few question answers (I just counted, HF's opening and first 5 answers are about 1000 words)
Think, "oh, they're an an ex-admin, I wonder why they're going through RFA, what was their cloud"
Read through the comments and votes to see if any issues have been brought up (another ~1000 words)
None have
Realise your input is not necessary and this could have been done at BN
That they were former admins has always been the first two sentences of their RfA’s statement, sentences which are immediately followed by that they resigned due to personal time commitment issues. You do not have to read the first 1000+ words to figure that out. If the reader wants to see if the candidate was lying in their statement, then they just have a quick skim through the oppose section. None of this should take more than 30 seconds in total. Aaron Liu (talk) 13:15, 16 December 2024 (UTC)[reply]
Not everyone can skim things easily - it personally takes me a while to read sections. I don't know if they're going to bury the lede and say something like "Also I made 10,000 insane redirects and then decided to take a break just before arbcom launched a case" in paragraph 6. Hog Farm's self nom had two paragraphs about disputes and it takes more than 30 seconds to unpick that and determine if that is a "cloud" or not. Even for reconfirmations, it definitely takes more than 30 seconds to determine a conclusion. BugGhost🦗👻11:21, 17 December 2024 (UTC)[reply]
They said they resigned to personal time commitments. That is directly saying they wasn’t under a cloud, so I’ll believe them unless someone claims the contrary in the oppose section. If the disputes section contained a cloud, the oppose section would have said so. One chooses to examine such nominations like normal RfAs. Aaron Liu (talk) 18:47, 17 December 2024 (UTC)[reply]
Just to double check, you're saying that whenever you go onto an RFA you expect any reason to oppose to already be listed by someone else, and no thought is required? I am begining to see how you are able to assess an RFA in under 30 seconds BugGhost🦗👻23:08, 17 December 2024 (UTC)[reply]
Something in their statement would be an incredibly obvious reason. We are talking about the assessment whether to examine and whether the candidate could've used BN. Aaron Liu (talk) 12:52, 18 December 2024 (UTC)[reply]
@Thryduulf let's not confuse "a lot of community time is spent" with "waste of time". Some people have characterized the re-RFAs as a waste of time but that's not the assertion I (and I think a majority of the skeptics) have been making. All RfAs use a lot of community time as hundreds of voters evaluate the candidate. They then choose to support, oppose, be neutral, or not vote at all. While editor time is not perfectly fixed - editors may choose to spend less time on non-Wikipedia activities at certain times - neither is it a resource we have in abundance anymore relative to our project. And so I think we, as a community, need to be thought about how we're using that time especially when the use of that time would have been spent on other wiki activities.Best, Barkeep49 (talk) 22:49, 16 December 2024 (UTC)[reply]
Absolutely nothing compels anybody to spend any time evaluating an RFA. If you think your wiki time is better spent elsewhere than evaluating an RFA candidate, then spend it elsewhere. That way only those who do think it is a good use of their time will participate and everybody wins. You win by not spending your time on something that you don't think is worth it, those who do participate don't have their time wasted by having to read comments (that contradict explicit policy) about how the RFA is a waste of time. Personally I regard evaluating whether a long-time admin still has the approval of the community to be a very good use of community time, you are free to disagree, but please don't waste my time by forcing me to read comments about how you think I'm wasting my time. Thryduulf (talk) 23:39, 16 December 2024 (UTC)[reply]
I don't understand how your argument that it is not a good use of community time is any different from arguing that it is a waste of time? Thryduulf (talk) 09:08, 17 December 2024 (UTC)[reply]
Option 2 I don't mind the re-RFAs, but I'd appreciate if we encouraged restoration via BN instead, I just object to making it mandatory. EggRoll97(talk) 06:23, 16 December 2024 (UTC)[reply]
Option 2. Banning voluntary re-RfAs would be a step in the wrong direction on admin accountability. Same with SNOW closing. There is no more "wasting of community time" if we let the RfA run for the full seven days, but allowing someone to dig up a scandal on the seventh day is an important part of the RfA process. The only valid criticism I've heard is that folks who do this are arrogant, but banning arrogance, while noble, seems highly impractical. Toadspike[Talk]07:24, 16 December 2024 (UTC)[reply]
Option 3, 1, then 2, per HouseBlaster. Also agree with Daniel Quinlan. I think these sorts of RFA's should only be done in exceptional circumstances. Graham87 (talk) 08:46, 16 December 2024 (UTC)[reply]
Option 1 as first preference, option 3 second. RFAs use up a lot of time - hundreds of editors will read the RFA and it takes time to come to a conclusion. When that conclusion is "well that was pointless, my input wasn't needed", it is not a good system. I think transparency and accountability is a very good thing, and we need more of it for resyssopings, but that should come from improving the normal process (BN) rather than using a different one (RFA). My ideas for improving the BN route to make it more transparent and better at getting community input is outlined over on the idea labBugGhost🦗👻08:59, 16 December 2024 (UTC)[reply]
Option 2, though I'd be for option 3 too. I'm all for administrators who feel like they want/should go through an RfA to solicit feedback even if they've been given the tools back already. I see multiple people talk about going through BN, but if I had to hazard a guess, it's way less watched than RfA is. However I do feel like watchlist notifications should say something to the effect of "A request for re-adminship feedback is open for discussion" so that people that don't like these could ignore them. ♠JCW555(talk)♠ 09:13, 16 December 2024 (UTC)[reply]
Option 2 because WP:ADMINISTRATORS is well-established policy. Read WP:ADMINISTRATORS#Restoration of admin tools, which says quite clearly, Regardless of the process by which the admin tools are removed, any editor is free to re-request the tools through the requests for adminship process. I went back 500 edits to 2017 and the wording was substantially the same back then. So, I simply do not understand why various editors are berating former administrators to the point of accusing them of wasting time and being arrogant for choosing to go through a process which is specifically permitted by policy. It is bewildering to me. Cullen328 (talk) 09:56, 16 December 2024 (UTC)[reply]
Option 2 & 3 I think that there still should be the choice between BN and re-RFA for resysops, but I think that the re-RFA should stay like it is in Option 3, unless it is controversial, at which point it could be extended to the full RFA period. I feel like this would be the best compromise between not "wasting" community time (which I believe is a very overstated, yet understandable, point) and ensuring that the process is based on broad consensus and that our "representatives" are still supported. If I were WTT or Hog, I might choose to make the same decision so as to be respectful of the possibility of changing consensus. JuxtaposedJacob (talk) | :) | he/him | 10:45, 16 December 2024 (UTC)[reply]
Option 2, for lack of a better choice. Banning re-RFAs is not a great idea, and we should not SNOW close a discussion that would give someone immunity from a certain degree of accountability. I've dropped an idea for an option 4 in the discussion section below. Giraffer (talk) 12:08, 16 December 2024 (UTC)[reply]
Option 1 I agree with Graham87 that these sorts of RFAs should only be done in exceptional circumstances, and BN is the best place to ask for tools back. – DreamRimmer (talk) 12:11, 16 December 2024 (UTC)[reply]
Option 2 I don't think prohibition makes sense. It also has weird side effects. eg: some admins' voluntary recall policies may now be completely void, because they would be unable to follow them even if they wanted to, because policy prohibits them from doing a RFA. (maybe if they're also 'under a cloud' it'd fit into exemptions, but if an admins' policy is "3 editors on this named list tell me I'm unfit, I resign" then this isn't really a cloud.) Personally, I think Hog Farm's RFA was unwise, as he's textbook uncontroversial. Worm's was a decent RFA; he's also textbook uncontroversial but it happened at a good time. But any editor participating in these discussions to give the "support" does so using their own time. Everyone who feels their time is wasted can choose to ignore the discussion, and instead it'll pass as 10-0-0 instead of 198-2-4. It just doesn't make sense to prohibit someone from seeking a community discussion, though. For almost anything, really. ProcrastinatingReader (talk) 12:33, 16 December 2024 (UTC)[reply]
Option 2 It takes like two seconds to support or ignore an RFA you think is "useless"... can't understand the hullabaloo around them. I stand by what I said on WTT's re-RFA regarding RFAs being about evaluating trustworthiness and accountability. Trustworthy people don't skip the process. —k6ka🍁 (Talk · Contributions) 15:24, 16 December 2024 (UTC)[reply]
2 is fine. Strong oppose to 1 and 3. Opposing option 1 because there is nothing wrong with asking for extra community feedback. opposing option 3 because once an RfA has been started, it should follow the standard rules. Note that RfAs are extremely rare and non-contentious RfAs require very little community time (unlike this RfC which seems a waste of community time, but there we are). —Kusma (talk) 16:59, 16 December 2024 (UTC)[reply]
2, with no opposition to 3. I see nothing wrong with a former administrator getting re-confirmed by the community, and community vetting seems like a good thing overall. If people think it's a waste of time, then just ignore the RfA. Natg 19 (talk) 17:56, 16 December 2024 (UTC)[reply]
No individual is wasting their time participating. Instead the person asking for a re-rfa is using tons of editor time by asking hundreds of people to vet them. Even the choice not to participate requires at least some time to figure out that this is not a new RfA; though at least in the two we've had recently it would require only as long as it takes to get to the RfA - for many a click from the watchlist and then another click into the rfa page - and to read the first couple of sentences of the self-nomination which isn't terribly long all things considered. Best, Barkeep49 (talk) 22:55, 16 December 2024 (UTC)[reply]
I agree with you (I think) that it's a matter of perspective. For me, clicking the RFA link in my watchlist and reading the first paragraph of Hog Farm's nomination (where they explained that they were already a respected admin) took me about 10 seconds. Ten seconds is nothing; in my opinion, this is just a nonissue. But then again, I'm not an admin, checkuser, or an oversighter. Maybe the time to read such a nomination is really wasting their time. I don't know. TheWikiToby (talk) 23:15, 16 December 2024 (UTC)[reply]
2. This reminds me of banning plastic straws (bear with me). Sure, I suppose in theory, that this is a burden on the community's time (just as straws do end up in landfills/the ocean). However, the amount of community time that is drained is minuscule compared to the amount of community time drained in countless, countless other fora and processes (just like the volume of plastic waste contributed by plastic straws is less than 0.001% of the total plastic waste). When WP becomes an efficient, well oiled machine, then maybe we can talk about saving community time by banning re-RFA's. But this is much ado about nothing, and indeed this plan to save people from themselves, and not allow them to simply decide whether to participate or not, is arguably more damaging than some re-RFAs (just as banning straws convinced some people that "these save-the-planet people are so ridiculous that I'm not going to bother listening to them about anything."). And, in fact, on a separate note, I'd actually love it if more admins just ran a re-RFA whenever they wanted. They would certainly get better feedback than just posting "What do my talk page watchers think?" on their own talk page. Or waiting until they get yelled at on their talk page, AN/ANI, AARV, etc. We say we want admins to respect feedback; does it have to be in a recall petition? --Floquenbeam (talk) 23:44, 16 December 2024 (UTC)[reply]
What meaningful feedback has Hog Farm gotten? "A minority of people think you choose poorly in choosing this process to regain adminship". What are they supposed to do with that? I share your desire for editors to share meaningful feedback with administrators. My own attempt yielded some, though mainly offwiki where I was told I was both too cautious and too impetuous (and despite the seeming contradiction each was valuable in its own way). So yes let's find ways to get meaningful feedback to admins outside of recall or being dragged to ANI. Unfortunately re-RfA seems to be poorly suited to the task and so we can likely find a better way. Best, Barkeep49 (talk) 03:38, 17 December 2024 (UTC)[reply]
No hard rule, but we should socially discourage confirmation RfAs There is a difference between a hard rule, and a soft social rule. A hard rule against confirmation RfA's, like option 1, would not do a good job of accounting for edge cases and would thus be ultimately detrimental here. But a soft social rule against them would be beneficial. Unfortunately, that is not one of the options of this RfC. In short, a person should have a good reason to do a confirmation RfA. If you're going to stand up before the community and ask "do you trust me," that should be for a good reason. It shouldn't just be because you want the approval of your peers. (Let me be clear: I am not suggesting that is why either Worm or Hogfarm re-upped, I'm just trying to create a general purpose rule here.) That takes some introspection and humility to ask yourself: is it worth me inviting two or three hundred people to spend part of their lives to comment on me as a person?A lot of people have thrown around editor time in their reasonings. Obviously, broad generalizations about it aren't convincing anyone. So let me just share my own experience. I saw the watchlist notice open that a new RfA was being run. I reacted with some excitement, because I always like seeing new admins. When I got to the page and saw Hogfarm's name, I immediately thought "isn't he already an admin?" I then assumed, ah, its just the classic RfA reaction at seeing a qualified candidate, so I'll probably support him since I already think he's an admin. But then as I started to do my due diligence and read, I saw that he really, truly, already had been an admin. At that point, my previous excitement turned to a certain unease. I had voted yes for Worm's confirmation RfA, but here was another...and I realized that my blind support for Worm might have been the start of an entirely new process. I then thought "bet there's an RfC going about this," and came here. I then spent a while polishing up my essay on editor time, before taking time to write this message. All in all, I probably spent a good hour doing this. Previously, I'd just been clicking the random article button and gnoming. So, the longwinded moral: yeah, this did eat up a lot of my editor time that could have and was being spent doing something else. And I'd do it again! It was important to do my research and to comment here. But in the future...maybe I won't react quite as excitedly to seeing that RfA notice. Maybe I'll feel a little pang of dread...wondering if its going to be a confirmation RfA. We can't pretend that confirmation RfA's are costless, and that we don't lose anything even if editors just ignore them. When run, it should be because they are necessary. CaptainEekEdits Ho Cap'n!⚓03:29, 17 December 2024 (UTC)[reply]
In short, a person should have a good reason to do a confirmation RfA. If you're going to stand up before the community and ask "do you trust me," that should be for a good reason. It shouldn't just be because you want the approval of your peers. Asking the community whether you still have their trust to be an administrator, which is what an reconfirmation RFA is, is a good reason. I expect getting a near-unanimous "yes" is good for one's ego, but that's just a (nice) side-effect of the far more important benefits to the entire community: a trusted administrator.
The time you claim is being eaten up unnecessarily by reconfirmation RFAs was actually taken up by you choosing to spend your time writing an essay about using time for things you don't approve of and then hunting out an RFC in which you wrote another short essay about using time on things you don't approve of. Absolutely none of that is a necessary consequence of reconfirmation RFAs - indeed the response consistent with your stated goals would have been to read the first two sentences of Hog Farm's RFA and then closed the tab and returned to whatever else it was you were doing. Thryduulf (talk) 09:16, 17 December 2024 (UTC)[reply]
WTT's and Hog Farm's RFAs would have been completely uncontentious, something I hope for at RfA and certainly the opposite of what I "dread" at RfA, if it were not for the people who attack the very concept of standing for RfA again despite policy being crystal clear that it is absolutely fine. I don't see how any blame for this situation can be put on WTT or HF. We can't pretend that dismissing uncontentious reconfirmation RfAs is costless; discouraging them removes one of the few remaining potentially wholesome bits about the process. —Kusma (talk) 09:53, 17 December 2024 (UTC)[reply]
@CaptainEek Would you find it better if Watchlist notices and similar said "(re?)confirmation RFA" instead of "RFA"? Say for all voluntary RFAs from an existing admin or someone who could have used BN?
As a different point, I would be quite against any social discouraging if we're not making a hard rule as such. Social discouraging is what got us the opposes at WTT/Hog Farm's RFAs, which I found quite distasteful and badgering. If people disagree with a process, they should change it. But if the process remains the same, I think it's important to not enable RFA's toxicity by encouraging others to namecall or re-argue the process in each RRFA. It's a short road from social discouragement to toxicity, unfortunately. Soni (talk) 18:41, 19 December 2024 (UTC)[reply]
Option 3 (which I think is a subset of option 2, so I'm okay with the status quo, but I want to endorse giving 'crats the option to SNOW). While they do come under scrutiny from time to time for the extensive dicsussions in the "maybe" zone following RfAs, this should be taken as an indiciation that they are unlikely to do something like close it as SNOW in the event there is real and substantial concerns being rasied. This is an okay tool to give the 'crats. As far as I can tell, no one has ever accused the them of moving too quickly in this direction (not criticism; love you all, keep up the good work). Bobby Cohn (talk) 17:26, 17 December 2024 (UTC)[reply]
Option 3 or Option 2. Further, if Option 2 passes, I expect it also ends all the bickering about lost community time. A consensus explicitly in favour of "This is allowed" should also be a consensus to discourage relitigation of this RFC. Soni (talk) 17:35, 17 December 2024 (UTC)[reply]
Option 2: Admins who do not exude entitlement are to be praised. Those who criticize this humility should have a look in the mirror before accusing those who ask for reanointment from the community of "arrogance". I agree that it wouldn't be a bad idea to mention in parentheses that the RFA is a reconfirmation (watchlist) and wouldn't see any problem with crats snow-closing after, say, 96 hours. -- SashiRolls 🌿 · 🍥18:48, 17 December 2024 (UTC)[reply]
I know. I see a sizable amount of commenters here starting to say that voluntary re-RfAs should be encouraged, and your first sentence can be easily read as implying that admins who use the BN route exude entitlement. I disagree with that (see my reply to Thryduulf below). Aaron Liu (talk) 12:56, 18 December 2024 (UTC)[reply]
One way to improve the reputation of RFA is for there to be more RFAs that are not terrible, such as reconfirmations of admins who are doing/have done a good job who sail through with many positive comments. There is no proposal to make RFA mandatory in circumstances it currently isn't, only to reaffirm that those who voluntarily choose RFA are entitled to do so. Thryduulf (talk) 21:06, 17 December 2024 (UTC)[reply]
I know it's not a proposal, but there's enough people talking about this so far that it could become a proposal. There's nearly nothing in between that could've lost the trust of the community. I'm sure there are many who do not want to be pressured into this without good reason. Aaron Liu (talk) 12:57, 18 December 2024 (UTC)[reply]
Absolutely nobody is proposing, suggesting or hinting here that reconfirmation RFAs should become mandatory - other than comments from a few people who oppose the idea of people voluntarily choosing to do something policy explicitly allows them to choose to do. The best way to avoid people being pressured into being accused of arrogance for seeking reconfirmation of their status from the community is to sanction those people who accuse people of arrogance in such circumstances as such comments are in flagrant breach of AGF and NPA. Thryduulf (talk) 14:56, 18 December 2024 (UTC)[reply]
Yes, I’m saying that they should not become preferred. There should be no social pressure to do RfA instead of BN, only pressure intrinsic to the candidate. Aaron Liu (talk) 15:37, 18 December 2024 (UTC)[reply]
Whether they should become preferred in any situation forms no part of this proposal in any way shape or form - this seeks only to reaffirm that they are permitted. A separate suggestion, completely independent of this one, is to encourage (explicitly not mandate) them in some (but explicitly not all) situations. All discussions on this topic would benefit if people stopped misrepresenting the policies and proposals - especially when the falsehoods have been explicitly called out. Thryduulf (talk) 15:49, 18 December 2024 (UTC)[reply]
I am talking and worrying over that separate proposal many here are suggesting. I don’t intend to oppose Option 2, and sorry if I came off that way. Aaron Liu (talk) 16:29, 18 December 2024 (UTC)[reply]
Option 2. In fact, I'm inclined to encourage an RRfA over BN, because nothing requires editors to participate in an RRfA, but the resulting discussion is better for reaffirming community consensus for the former admin or otherwise providing helpful feedback. --Pinchme123 (talk) 21:45, 17 December 2024 (UTC)[reply]
Option 2WP:RFA has said "Former administrators may seek reinstatement of their privileges through RfA..." for over ten years and this is not a problem. I liked the opportunity to be consulted in the current RfA and don't consider this a waste of time. Andrew🐉(talk) 22:14, 17 December 2024 (UTC)[reply]
2 - If an administrator gives up sysop access because they plan to be inactive for a while and want to minimize the attack surface of Wikipedia, they should be able to ask for permissions back the quickest way possible. If an administrator resigns because they do not intend to do the job anymore, and later changes their mind, they should request a community discussion. The right course of action depends on the situation. JehochmanTalk14:00, 18 December 2024 (UTC)[reply]
Option 1. I've watched a lot of RFAs and re-RFAs over the years. There's a darn good reason why the community developed the "go to BN" option: saves time, is straightforward, and if there are issues that point to a re-RFA, they're quickly surfaced. People who refuse to take the community-developed process of going to BN first are basically telling the community that they need the community's full attention on their quest to re-admin. Yes, there are those who may be directed to re-RFA by the bureaucrats, in which case, they have followed the community's carefully crafted process, and their re-RFA should be evaluated from that perspective. Risker (talk) 02:34, 19 December 2024 (UTC)[reply]
Option 2 (status quo/no changes) per meh. This is bureaucratic rulemongering at its finest. Every time RFA reform comes up some editors want admins to be required to periodically reconfirm, then when some admins decide to reconfirm voluntarily, suddenly that's seen as a bad thing. The correct thing to do here is nothing. If you don't like voluntary reconfirmation RFAs, you are not required to participate in them. Ivanvector (Talk/Edits) 19:34, 19 December 2024 (UTC)[reply]
Option 2 I would probably counsel just going to BN most of the time, however there are exceptions and edge cases. To this point these RfAs have been few in number, so the costs incurred are relatively minor. If the number becomes large then it might be worth revisiting, but I don't see that as likely. Some people will probably impose social costs on those who start them by opposing these RfAs, with the usual result, but that doesn't really change the overall analysis. Perhaps it would be better if our idiosyncratic internal logic didn't produce such outcomes, but that's a separate issue and frankly not really worth fighting over either. There's probably some meta issues here I'm unaware off, it's long since I've had my finger on the community pulse so to speak, but they tend to matter far less than people think they do. 184.152.68.190 (talk) 02:28, 20 December 2024 (UTC)[reply]
Option 1, per WP:POINT, WP:NOT#SOCIALNETWORK, WP:NOT#BUREAUCRACY, WP:NOTABOUTYOU, and related principles. We all have far better things to do that read through and argue in/about a totally unnecessary RfA invoked as a "Show me some love!" abuse of process and waste of community time and productivity. I could live with option 3, if option 1 doesn't fly (i.e. shut these silly things down as quickly as possible). But option 2 is just out of the question. — SMcCandlish☏¢ 😼 04:28, 22 December 2024 (UTC)[reply]
Except none of the re-RFAs complained about have been RfA invoked as a "Show me some love!" abuse of process, you're arguing against a strawman. Thryduulf (talk) 11:41, 22 December 2024 (UTC)[reply]
It's entirely a matter of opinion and perception, or A) this RfC wouldn't exist, and B) various of your fellow admins like TonyBallioni would not have come to the same conclusion I have. Whether the underlying intent (which no one can determine, lacking as we do any magical mind-reading powers) is solely egotistical is ultimately irrelevant. The actual effect (what matters) of doing this whether for attention, or because you've somehow confused yourself into think it needs to be done, is precisely the same: a showy waste of community volunteers' time with no result other than a bunch of attention being drawn to a particular editor and their deeds, without any actual need for the community to engage in a lengthy formal process to re-examine them. — SMcCandlish☏¢ 😼 05:49, 23 December 2024 (UTC)[reply]
or because you've somehow confused yourself into think it needs to be done
Option 2. I see no legitimate reason why we should be changing the status quo. Sure, some former admins might find it easier to go through BN, and it might save community time, and most former admins already choose the easier option. However, if a candidate last ran for adminship several years ago, or if issues were raised during their tenure as admin, then it may be helpful for them to ask for community feedback, anyway. There is no "wasted" community time in such a case. I really don't get the claims that this violates WP:POINT, because it really doesn't apply when a former admin last ran for adminship 10 or 20 years ago or wants to know if they still have community trust.On the other hand, if an editor thinks a re-RFA is a waste of community time, they can simply choose not to participate in that RFA. Opposing individual candidates' re-RFAs based solely on opposition to re-RFAs in general is a violation of WP:POINT. – Epicgenius (talk) 14:46, 22 December 2024 (UTC)[reply]
There have been lots of re-RFAs, historically. There were more common in the 2000s. Evercat in 2003 is the earliest I can find, back before the re-sysopping system had been worked out fully. Croat Canuck back in 2007 was snow-closed after one day, because the nominator and applicant didn't know that they could have gone to the bureaucrats' noticeboard. For more modern examples, HJ Mitchell (2011) is relatively similar to the recent re-RFAs in the sense that the admin resigned uncontroversially but chose to re-RFA before getting the tools back. Immediately following and inspired by HJ Mitchell's, there was the slightly more controversial SarekOfVulcan. That ended successful re-RFAS until 2019's Floquenbeam, which crat-chatted. Since then, there have been none that I remember. There have been several re-RFAs from admins who were de-sysopped or at serious risk of de-sysopping, and a few interesting edge cases such as the potentially optional yet no-consensus SarekVulcan 3 in 2014 and the Rich Farmbrough case in 2015, but those are very different than what we're talking about today. GreenLipstickLesbian (talk) 00:01, 23 December 2024 (UTC)[reply]
Well thank you both, I've learned something new today. It turns out I was working on a false assumption. It has just been so long since a re-RfA that I assumed it was a truly new phenomenon, especially since there were two in short succession. I still can't say I'm thrilled by the process and think it should be used sparingly, but perhaps I was a bit over concerned. CaptainEekEdits Ho Cap'n!⚓16:47, 23 December 2024 (UTC)[reply]
Option 2 or 3 per Gnoming and CaptainEek. Such RfAs only require at most 30 seconds for one to decide whether or not to spend their time on examination. Unlike other prohibited timesinks, it's not like something undesirable will happen if one does not sink their time. Voluntary reconfirmation RfAs are socially discouraged, so there is usually a very good reason for someone to go back there, such as accountability for past statements in the case of WTT or large disputes during adminship in the case of Hog Farm. I don't think we should outright deny these, and there is no disruption incurred if we don't. Aaron Liu (talk) 15:44, 23 December 2024 (UTC)[reply]
Option 2 (fine with better labeling) These don't seem harmful to me and, if I don't have time, I'll skip one and trust the judgment of my fellow editors. No objection to better labeling them though, as discussed above. RevelationDirect (talk) 22:36, 23 December 2024 (UTC)[reply]
Option 1 because it's just a waste of time to go through and !vote on candidates who just want the mop restored when he or she or they could get it restored BN with no problems. But I can also see option 2 being good for a former mod not in good standing. Therapyisgood (talk) 23:05, 23 December 2024 (UTC)[reply]
@Voorts: If option 2 gets consensus how would this RfC change the wording Regardless of the process by which the admin tools are removed, any editor is free to re-request the tools through the requests for adminship process. Or is this an attempt to see if that option no longer has consensus? If so why wasn't alternative wording proposed? As I noted above this feels premature in multiple ways. Best, Barkeep49 (talk) 21:43, 15 December 2024 (UTC)[reply]
I've re-opened this per a request on my talk page. If other editors think this is premature, they can !vote accordingly and an uninvolved closer can determine if there's consensus for an early close in deference to the VPI discussion. voorts (talk/contributions) 21:53, 15 December 2024 (UTC)[reply]
The discussion at VPI, which I have replied on, seems to me to be different enough from this discussion that both can run concurrently. That is, however, my opinion as a mere editor. — Jkudlick ⚓ (talk)22:01, 15 December 2024 (UTC)[reply]
@Voorts, can you please reword the RfC to make it clear that Option 2 is the current consensus version? It does not need to be clarified – it already says precisely what you propose. – bradv22:02, 15 December 2024 (UTC)[reply]
Question: May someone clarify why many view such confirmation RfAs as a waste of community time? No editor is obligated to take up their time and participate. If there's nothing to discuss, then there's no friction or dis-cussing, and the RfA smooth-sails; if a problem is identified, then there was a good reason to go to RfA. I'm sure I'm missing something here. Aaron Liu (talk) 22:35, 15 December 2024 (UTC)[reply]
The intent of RfA is to provide a comprehensive review of a candidate for adminship, to make sure that they meet the community's standards. Is that happening with vanity re-RfAs? Absolutely not, because these people don't need that level of vetting. I wouldn't consider a week long, publicly advertized back patting to be a productive use of volunteer time. -- Ajraddatz (talk) 23:33, 15 December 2024 (UTC)[reply]
Sure, but that logic could be used to justify any time sink. We're all volunteers and nobody is forced to do anything here, but that doesn't mean that we should promote (or stay silent with our criticism of, I suppose) things that we feel don't serve a useful purpose. I don't think this is a huge deal myself, but we've got two in a short period of time and I'd prefer to do a bit of push back now before they get more common. -- Ajraddatz (talk) 01:52, 16 December 2024 (UTC)[reply]
Except someone who has no need for advanced tools and is not going to use them in any useful fashion, would then skate through with nary a word said about their unsuitability, regardless of the foregone conclusion. The point of RFA is not to rubber-stamp. Unless their is some actual issue or genuine concern they might not get their tools back, they should just re-request them at BN and stop wasting people's time with pointless non-process wonkery. Only in death does duty end (talk) 09:05, 16 December 2024 (UTC)[reply]
I’m confused. Adminship requires continued use of the tools. If you think they’s suitable for BN, I don’t see how doing an RfA suddenly makes them unsuitable. If you have concerns, raise them. Aaron Liu (talk) 13:02, 16 December 2024 (UTC)[reply]
I don't think the suggested problem (which I acknowledge not everyone thinks is a problem) is resolved by these options. Admins can still run a re-confirmation RfA after regaining adminsitrative privileges, or even initiate a recall petition. I think as discussed on Barkeep49's talk page, we want to encourage former admins who are unsure if they continue to be trusted by the community at a sufficient level to explore lower cost ways of determining this. isaacl (talk) 00:32, 16 December 2024 (UTC)[reply]
In re the idea that RfAs use up a lot of community time: I first started editing Wikipedia in 2014. There were 62 RfAs that year, which was a historic low. Even counting all of the AElect candidates as separate RfAs, including those withdrawn before voting began, we're still up to only 53 in 2024 – counting only traditional RfAs it's only 18, which is the second lowest number ever. By my count we've has 8 resysop requests at BN in 2024; even if all of those went to RfA, I don't see how that would overwhelm the community. That would still leave us on 26 traditional RfAs per year, or (assuming all of them run the full week) one every other week. Caeciliusinhorto-public (talk) 10:26, 16 December 2024 (UTC)[reply]
What about an option 4 encouraging eligible candidates to go through BN? At the end of the Procedure section, add something like "Eligible users are encouraged to use this method rather than running a new request for adminship." The current wording makes re-RfAing sound like a plausible alternative to a BN request, when in actual fact the former rarely happens and always generates criticism. Giraffer (talk) 12:08, 16 December 2024 (UTC)[reply]
Discouraging RFAs is the second last thing we should be doing (after prohibiting them), rather per my comments here and in the VPI discussion we should be encouraging former administrators to demonstrate that they still have the approval of the community. Thryduulf (talk) 12:16, 16 December 2024 (UTC)[reply]
I think this is a good idea if people do decide to go with option 2, if only to stave off any further mixed messages that people are doing something wrong or rude or time-wasting or whatever by doing a second RfA, when it's explicitly mentioned as a valid thing for them to do. Gnomingstuff (talk) 15:04, 16 December 2024 (UTC)[reply]
If RFA is explicitly a valid thing for people to do (which it is, and is being reaffirmed by the growing consensus for option 2) then we don't need to (and shouldn't) discourage people from using that option. The mixed messages can be staved off by people simply not making comments that explicitly contradict policy. Thryduulf (talk) 15:30, 16 December 2024 (UTC)[reply]
This is not new. We've had sporadic "vanity" RfAs since the early days of the process. I don't believe they're particularly harmful, and think that it unlikely that we will begin to see so many of them that they pose a problem. As such I don't think this policy proposal solves any problem we actually have. UninvitedCompany21:56, 16 December 2024 (UTC)[reply]
This apparent negative feeling evoked at an RFA for a former sysop everyone agrees is fully qualified and trusted certainly will put a bad taste in the mouths of other former admins who might consider a reconfirmation RFA without first visiting BN. This comes in the wake of Worm That Turned's similar rerun. BusterD (talk) 23:29, 16 December 2024 (UTC)[reply]
I went looking for @Tamzin's comment because I know they had hung up the tools and came back, and I was interested in their perspective. But they've given me a different epiphany. I suddenly realize why people are doing confirmation RfAs: it's because of RECALL, and the one year immunity a successful RfA gives you. Maybe everyone else already figured that one out and is thinking "well duh Eek," but I guess I hadn't :) I'm not exactly sure what to do with that epiphany, besides note the emergent behavior that policy change can create. We managed to generate an entirely new process without writing a single word about it, and that's honestly impressive :P CaptainEekEdits Ho Cap'n!⚓18:18, 17 December 2024 (UTC)[reply]
Worm That Turned followed through on a pledge he made in January 2024, before the 2024 review of the request for adminship process began. I don't think a pattern can be extrapolated from a sample size of one (or even two). That being said, it's probably a good thing if admins occasionally take stock of whether or not they continue to hold the trust of the community. As I previously commented, it would be great if these admins would use a lower cost way of sampling the community's opinion. isaacl (talk) 18:31, 17 December 2024 (UTC)[reply]
If people decide to go through a community vote to get a one year immunity from a process that only might lead to a community vote which would then have a lower threshold then the one they decide to go through, and also give a year's immunity, then good for them. CMD (talk) 01:05, 22 December 2024 (UTC)[reply]
@CaptainEek I'm mildly bothered by this comment, mildly because I assume it's lighthearted and non-serious. But just in case anyone does feel this way - I was very clear about my reasons for RRFA, I've written a lot about it, anyone is welcome to use my personal recall process without prejudice, and just to be super clear - I waive my "1 year immunity" - if someone wants to start a petition in the next year, do not use my RRfA as a reason not to. I'll update my userpage accordingly. I can't speak for Hog Farm, but his reasoning seems similar to mine, and immunity isn't it. WormTT(talk) 10:28, 23 December 2024 (UTC)[reply]
@Worm That Turned my quickly written comment was perhaps not as clear as it could have been :) I'm sorry, I didn't mean to suggest that y'all had run for dubious reasons. As I said in my !vote, Let me be clear: I am not suggesting that is why either Worm or Hogfarm re-upped, I'm just trying to create a general purpose rule here. I guess what I really meant was that the reason that we're having this somewhat spirited conversation seems to be the sense that re-RfA could provide a protection from recall. If not for recall and the one year immunity period, I doubt we'd have cared so much as to suddenly run two discussions about this. CaptainEekEdits Ho Cap'n!⚓16:59, 23 December 2024 (UTC)[reply]
I really don't think this is the reason behind WTT's and HF's reconfirmation RFA's. I don't think their RFA's had much utility and could have been avoided, but I don't doubt for a second that their motivations were anything other than trying to provide transparency and accountability for the community. BugGhost🦗👻12:04, 23 December 2024 (UTC)[reply]
I don't really care enough about reconf RFAs to think they should be restricted, but what about a lighter ORCP-like process (maybe even in the same place) where fewer editors can indicate, "yeah OK, there aren't really any concerns here, it would probably save a bit of time if you just asked at BN". Alpha3031 (t • c) 12:40, 19 December 2024 (UTC)[reply]
Audio-video guidance
Hi there,
Per the post I made a few weeks ago regarding use of video for illustrative purposes, I think that MOS:Images might be expanded to make mention of audio-video content, as most of the same principles apply (eg aesthetics, quality, relevance, placement). There are some additional concerns, for example, if audio or video renders a primary source, eg is a recording of PD music such as Bach or similar; or is a reading of a PD text, then there might be some source validation requirements (ie, the music or text should match the original, within sensible boundaries, eg Mozart or Bach pieces may not be easily replicated with original instrumentation, or at least this should not be a requirement.
So one option would be for a simple statement at MOS:Images that these guidelines normally apply to AV, or separate guidance for AV that explains that MOS:Images contains guidance that generally applies to AV.
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.
In order to have more reliable and unbiased articles and make Wikipedia fully reliable,
I believe it necessary for articles and topics to be created and handled by bodies of editors called "Research groups", focusing on researching about topics and articles to ensure Wikipedia articles are as accurate, neutral, and unbiased as possible.
I also propose that editing articles will be reserved to their respective research groups and creating articles about a topic can only be done by said groups, with non-members being able to propose changes and articles via RFCs and whatnot. To join a research group, one must complete thorough training in the following areas
Bias reduction and neutrality training.
Finding reliable sources and comparing sources.
Professional research.
Lessons about the topic.
Wikipedia policy.
Any other applicable areas
This policy would also reduce vandalism and guideline violations across Wikipedia, making situations easier to handle.
Since Wikipedia is a widely-used source, it is time to move away from the current decentralized approach where just about anyone (no matter how inexperienced and biased) can edit, which has resulted in article bias, vandalism, unreliable sources, poor editing, sockpuppet accounts, edit wars, controversies, and a host of other problems.
Your proposal describes something that would not be Wikipedia at all (remember, we are the free encyclopaedia that anyone can edit), so is better suited for a fork. Usually proposals like yours (with editing only permitted to small numbers of "trusted" people) only work for small projects, if at all (I expect you would have to pay people to consider going through the "research group" training; it certainly does not sound attractive at all to me as a volunteer). You will need tens of thousands of editors to have any chance at not becoming outdated immediately. —Kusma (talk) 16:56, 17 December 2024 (UTC)[reply]
it is time to move away from the current decentralized approach where just about anyone [...] can edit - this proposal is dead on arrival - I support a SNOW close. BugGhost🦗👻17:30, 17 December 2024 (UTC)[reply]
Congratulations! We're completely rejecting Wikipedia's open content, its editors' direct contributions (henceforth to be filtered through a new Wikipedia Politburo), with the basic principles of Wikipedia's founders soundly rejected. "Research group training" says it all. Mason.Jones (talk) 18:15, 17 December 2024 (UTC)[reply]
Respectfully, I think this is a horrible idea. The decentralized model is what the entire site was built upon. It is even one of the first things advertised on the Main Page! If we got rid of it, the site wouldn't truly be Wikipedia anymore. QuicoleJR (talk) 18:20, 17 December 2024 (UTC)[reply]
I mean, I think Wikipedia is big enough to drop the "free encyclopaedia" bit and attempt a nupedia-like approach. However, I digress and have dropped that clause in my proposal. Cnscrptr (talk) 20:06, 17 December 2024 (UTC)[reply]
Few modifications of my proposal based on feedback:
Keep the decentralized model.
Drop the extensive training clause. No extensive training will be required.
Individuals are expected to learn about the topic before editing.
It will be necessary to join research groups (i.e., groups made of editors collaborating on the topic) to better learn about the topic and better contributing to it.
Editing of various articles, including election articles, will require an extended-confirmed status.
Modified proposal: Research panels between editors and greater article protections
I got your feedback on this policy proposal and decided to overhaul the proposal based to maintain the free nature of Wikipedia and strong editor collaboration while ensuring accuracy and reliability.
In order for Wikipedia's articles to be more reliable and less biased and to make Wikipedia a more reliable site, I believe that there should be a mandatory creation of Research panels, topic collaborations between editors focused on gathering information, comparing sources, establishing editing policies and guidelines in accordance with general Wikipedia rules, and ensuring editing guidelines. Formation of research panels will be necessary in every topic.
The editing model will remain decentralized. However, Research panels will determine policies based on consensus for their respective topics.
Individuals can join a research group freely. However, individuals are expected to follow the policies and protocols set forth by the research group.
Individuals are expected to learn about the topic before editing.
It will be necessary to join research panels to better learn about the topic and better contribute to it.
Various controversial articles, including election articles, will receive special protection or extended-confirmed protection upon request from the respectively Research panel.
Research Panels will allow people to better understand the topic while integrating cooperation efforts to find the most accurate information and create the best possible articles.
This modified proposal is sloppy at worst and doubt it will get any approval. However, I think y'all should take whatever good ideas are there (if any) and also create spaces or something like that for greater learning and collaboration among editors to resolve conflicts and biases. Cnscrptr (talk) 20:39, 17 December 2024 (UTC)[reply]
"Individuals are expected to learn about topic before editing"+"It will be necessary to join research panels to better learn about the topic" seems to add up to "Users are expected to be members of research panels before editing topics in that realm."
So if I look at an article about "semiotics" (about which I know nothing) I am not allowed to correct, say, some MOS:LQ failures, some incorrect header capitalization, and a misspelling of Charles Schulz's last name until I train myself in semiotics and join the Official Wikipedia Semiotics Fun Team? -- Nat Gertler (talk) 20:48, 17 December 2024 (UTC)[reply]
Also, the whole editing thing only applies to major edits, not minor ones.
Either way, this isn't my best work. The first proposal was essentially nupedia revivalism and the modification is a sloppy attempt at salvaging it based on the original essence of investigating about a topic further to put out the most accurate information (as is necessary in the Proto-Sinaitic script article) Cnscrptr (talk) 20:53, 17 December 2024 (UTC)[reply]
I understand that I would be allowed to jump through whatever hoops you erect in order to be able to correct misspellings, but that seems an effective way to discourage me from improving the encyclopedia and getting it in line with general standards. (I am also unconvinced that this will reduce bias; it would seem to help solidify a smaller group of editors on various topics who are likely to be driven, quite possibly by bias, to go through the effort which you're adding.) -- Nat Gertler (talk) 20:54, 17 December 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Is the "above 8000 words = split" an absolute rule?
Probably should be divided or trimmed, though the scope of a topic can sometimes justify the added reading material.
> 8,000 words
May need to be divided or trimmed; likelihood goes up with size.
< 6,000 words
Length alone does not justify division or trimming.
< 150 words
If an article or list has remained this size for over two months, consider merging it with a related article. Alternatively, the article could be expanded; see Wikipedia:Stub.
I have seen a few instances where, an editor will raise the issue that an article is too large at, say, 7500 words or 8100 words. We have multiple history pages (and medical/psychology pages) with well over 11,000+ words, even some with over 16000. Where does one draw the line? It seems like Wikipedia leaves it to the discretion of the editor after about 8000 words. Plasticwonder (talk) 07:21, 18 December 2024 (UTC)[reply]
Looking at the table, it's obvious that "above 8000 words=Split" is not "an absolute rule". I promise you that if it were, that table would say something that sounded remarkably like "if the article is above 8,000 words, then it absolutely must be split".
Where one draws the line is: In a place that makes sense for the topic of that specific article, having thoughtfully considered all the facts and circumstances that apply to that unique article. WhatamIdoing (talk) 07:41, 18 December 2024 (UTC)[reply]
In addition to the above, what matters for the technical aspects of article size is not the number of words but the number of bytes. Word count can only ever be an approximation of that as the length of the words used matters ("a" is 1 byte, "comprehensive" is 13), the number and size of included media matters very significantly more. Thryduulf (talk) 09:20, 18 December 2024 (UTC)[reply]
It isn't an absolute rule, but usually an article having an extremely long high word count is evidence of a bigger problem with WP:SUMMARYSTYLE -- that it's too dense or detailed for a reader to use it as a first-port-of-call summary. As such, usually, it's a wise move to create daughter articles for the detailed material, and strim it down to its essentials in the main article; this improves the readability of the main article and allows interested readers to follow up into the nitty-gritty. As Jo-Jo Eumerus rightly says above, though, there's not really such thing as an absolute rule in this place. UndercoverClassicistT·C09:59, 18 December 2024 (UTC)[reply]
What we now know is that many readers are looking for specific information, with few reading from top to bottom, but the search engines send them to the mother article even when a more specific daughter article exists. So the first port of call needs to be the most highly detailed. The advice in WP:SUMMARYSTYLE is therefore considered well intentioned but obsolete; stripping the mother article and pushing information down to the daughter articles defeats our whole purpose in providing information. Hawkeye7(discuss)11:31, 22 December 2024 (UTC)[reply]
When you say “we know…”, “is considered” and similar, are you pointing to specific previous discussions, RfCs etc on this matter? “In the wild”, as it were, I still see these size limits regularly invoked, even if the conversation rarely ends at them. UndercoverClassicistT·C09:17, 23 December 2024 (UTC)[reply]
Rather than draw a line, I'd rather just remove that chart. Can't imagine why a suite of concrete word counts and procedures would ever be very helpful. — Rhododendritestalk \\ 16:29, 18 December 2024 (UTC)[reply]
It absolutely makes sense to say at what page sizes that editors should start considering other options, as well as where splitting can be absolutely unnecessary. Nothing wrong with the table as long as it's clear those aren't hard or fast rules. Masem (t) 16:41, 18 December 2024 (UTC)[reply]
Agreed, I find it helpful because it helps me remember what is generally too long for mobile users (I understand that mobile is generally a blindspot for us as editors because the vast majority of us don't edit on mobile but most of the readers are actually on mobile) Horse Eye's Back (talk) 16:49, 18 December 2024 (UTC)[reply]
The optimal article size varies quite a lot, actually. Key things we need to consider include:
The likely readership. Someone who's looking up History of Libya under Muammar Gaddafi probably has time to read something long and thoughtful. Someone who's looking up emergency surgery might need basic facts, in simple words, very fast.
The cognitive load associated with the topic. Star Wars is (very) long but easy to understand; Fourier inversion theorem is much shorter, but I bet it takes you longer to read, unless you have unusual expertise in mathematics.
Wikipedia leaves it to the discretion of editors far far before 8,000 words. We have thousands of single sentence articles to attest to this. The average article is less than 700 words. CMD (talk) 17:15, 18 December 2024 (UTC)[reply]
I've always felt that the kB of readable prose was a better metric for page size (such as is produced by various page size gadgets). Turns out, bigger words take longer to read than shorter words :P Doing it just by wordcount encourages a certain verbosity. For me, my rule of thumb has always aimed to keep big articles under 100kb readable prose. But there's no hard and fast rule, and there shouldn't be. CaptainEekEdits Ho Cap'n!⚓23:08, 22 December 2024 (UTC)[reply]
If I'm being honest, what might be the best metric is starting at the top and lightly hammering the Page Down key for a bit. If I groan before reaching the References section, it's too long. Remsense ‥ 论23:10, 22 December 2024 (UTC)[reply]
26,000 words is 1.0 tomats. Another way to look at that table is by saying that if it's more than half the length of a book, it's pushing past being "an article" and edging up towards being "a book".
Or you can look at it in terms of how many minutes reading the whole thing would take. There's quite a bit of variation, but for easy math, 300 words per minute means that a 15,000-word-long article would take 50 minutes to read, which almost certainly exceeds the interest and attention span of most readers. WhatamIdoing (talk) 00:35, 23 December 2024 (UTC)[reply]
I think the most fundamental scalar isn't quite reading time or even visual size, but structural complexity—for an online encyclopedia article, being overlong expresses itself in my increasing inability to navigate an article comfortably to read or locate what I want, or to understand the structure of the scope covered by it at a glance. Remsense ‥ 论00:38, 23 December 2024 (UTC)[reply]
Come to think of it, one thing that makes an article feel longer than its word count is if its sections, media, and other landmarks have been laid out in a careless or unnatural way. Remsense ‥ 论00:48, 23 December 2024 (UTC)[reply]
No. And this was rather a pointless, self-answering question in the first place, not something for a VP thread. The answer to the posed question of 'Is the "above 8000 words=Split" an absolute rule?' is obviously "no", both by observing actual WP community practice, and just by reading the table the OP quoted: > 8,000 words — May need to be divided or trimmed; likelihood goes up with size. Is anyone here actually confused into believing that A) "must" and "may" are synonymous, or B) that a guideline, to which reasonable exceptions sometimes apply, is somehow a legal-level policy that must be obeyed at all costs? In reality, there is never any hurry to split a large article, and doing it properly often involves a tremendous amount of work, involving both repair of citations (sometimes in great detail), and resummarizing the background context in the side article while also resummarizing the side-matter in WP:SUMMARY style within the main article (and doing them distinctly enough that the results are not obnoxiously repetitive if the reader moves between the articles). Doing a good job of this can take several days up to a month or longer of tightly focused work, depending on the detail level of the material, the number citations, etc. It is not trivial, we're all volunteers here, and our readers are not going keel over and die if they reach a detailed article that's a bit longer than they were expecting or would prefer. Ultimately, an article that is ginormous usually should split, but there is no deadline, and it needs to be done properly (plus there are often conceptually different ways to go about it from a content-flow perspective, and that might require some consensus discussion). — SMcCandlish☏¢ 😼 01:22, 23 December 2024 (UTC)[reply]
I think I linked it once in Wikipedia:Policies and guidelines, years ago, and someone objected. I didn't follow up to see whether the objecting editor is one of the handful who think that should is a more polite and/or IAR-compliant way to say must, but as that's a fairly uncommon POV among editors, it probably wasn't. WhatamIdoing (talk) 05:41, 23 December 2024 (UTC)[reply]
The linked document pushes very hard on should, "here may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed" is not a low bar. It sounds much like must except when IAR. CMD (talk) 09:39, 23 December 2024 (UTC)[reply]
I want to propose Draft:Manual of Style/Israel- and Palestine-related articles as a new guideline with an RfC. I'm starting this thread in case any outsiders to this area want to provide input or have questions. For context, the goal of this manual of style is to get agreement on broad principles to make editing easier in this topic area. As an example, WP:PIA5 is dealing with inconsistent use of the word "massacre" specifically, which has caused much arguing over whether there is a double standard, so this guideline makes the standards we should be using explicit. Chess (talk) (please mention me on reply)06:38, 21 December 2024 (UTC)[reply]
Are all four points currently included based on previous conversations, or are any novel to this proposal? On the broader framing, I wouldn't create the guideline solely talking about NPOV, it is helpful to have guidelines to help describe encyclopaedic style if nothing else. On the example of massacre, I'm not up to date with the recent or ongoing discussions, but I'm surprised there's no mention in the draft of WP:WTW, as this seems a classic case. CMD (talk) 07:00, 21 December 2024 (UTC)[reply]
@Chipmunkdavis: The settlements language comes from previous discussions/consensus, likewise with the West Bank naming conventions section. The categorization language comes from a suggestion on the talk page of the draft.
The "massacre" part is a novel part of the proposal. I would say that it seems like an obvious WP:WTW, but there's many RMs in the topic area in which editors use their own definition of the term "massacre" (like civilian death toll, mechanism of killing, see User:BilledMammal/ARBPIA_RM_statistics for a list of 24 RMs about the term "massacre"), and argue about whether or not the event meets that standard. I want to make it easier for editors to disengage by citing this guideline, instead of getting into lengthy arguments over points that don't contribute much to consensus (which is what happens now).
The reason the guideline is short is because I believe it will give it the best chance of passing right now. In the future, I'd like to get consensus to add more points to this guideline. I thought proposing a lengthy guideline upfront would create a scenario in which everyone at an RfC agrees a guideline would benefit the area, but individual editors have a small issue that prevents them from supporting this specific version. Chess (talk) (please mention me on reply)07:50, 21 December 2024 (UTC)[reply]
At a quick look, it seems most pages in that statistics page were not moved to a title with "massacre"? Seems sensible to collate previous discussions together, if massacres is new (as new as something discussed 24 times can be?) there might need to confirm that one. CMD (talk) 08:20, 21 December 2024 (UTC)[reply]
One issue with the massacre bit is that should be part of an AT naming convention, not in the MOS. Likewise, appropriate categorizations usually aren't in the MOS. voorts (talk/contributions) 15:27, 21 December 2024 (UTC)[reply]
I (+other people) co-authored a draft article, but its submission was declined
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.
supposedly due to: "This submission is not adequately supported by reliable sources".
It seems to me, that there are planety of good references now.
I want to understand, what is missing - and- how it can be improved.
A side note: there are many published articles in English Wikipedia, which are of much lower quality, than this draft: https://en.wikipedia.org/wiki/Draft:Maternity_capitalWalter Tau (talk) 15:19, 22 December 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Looks like that's a different function. It finds articles where someone has twice named a citation using the same refname. I'm looking for something which finds duplicate URLs, so that I can combine them into one [named] citation that can be referred to multiple times. ▶ I am Grorp ◀ 02:20, 17 December 2024 (UTC)[reply]
I am seeking consensus on a proposal to develop and deploy a bot to help block VPNgate IP addresses used by a particular WP:LTA. For WP:DENY/WP:BEANS reasons, I cannot provide full details, but users familiar with the LTA in question will understand the context.
Background
I have tested several VPNgate IPs, and very few of them are currently blocked. According to Wikipedia's policy on open proxies and VPNs (per WP:NOP), these should be blocked. Given the volume of VPNgate IPs, I propose using a bot to automate this process.
I am posting here to gauge consensus needed for a WP:BRFA.
Proposal
I propose a bot to automate blocking these VPNgate IPs using the following steps:
The bot will use this list provided by VPNgate, which contains OpenVPN configuration files in Base64 format. The provided "IP" value is only the one that your computer uses to talk to the VPN (and sometimes wrong), not the one used for the VPN to talk to Wikipedia/external internet - this requires testing to uncover.
The bot will iterate through each config file and use OpenVPN to test if it can connect. If successful, it will then use the VPN to send a request to this WhatIsMyIPAddress API to determine the real-world IP address used by each VPN to connect to Wikipedia. This is sometimes the same as the IP used to talk to the VPN - but sometimes completely different, see the demo edit I did using VPNgate on the Bot Requests discussion linked above and I also did one as a reply to this post. Also, testing is needed before blanket blocking because VPNgate claim to fill the list with fake IPs to prevent it from being used for blocking, again see the BR discussion.
Blocking or Reporting:
If the bot is approved as an admin bot, it will immediately block the identified IPs or modify block settings to disable TPA (see Yamla's recent ANI discussion per the necessity for this) and enable auto block.
If the bot is not approved to run as an admin bot, it will add the IPs to an interface-protected JSON file in its userspace for a bot operated by an admin to actually do the blocking.
Additional Information
I have already developed and tested this bot locally using Pywikibot. I have tested it on a local MediaWiki install and it successfully prevents all VPNgate users from editing (should they not be IP block exempt).
I’m posting here to gauge broader community consensus beyond the original WP:BOTREQUESTS discussion.
Poll Options
Oppose: Object to the bot proposal. Feel free to explain why.
Support options:
Admin Bot (admin given code): An admin will run the bot, and I will provide the code for them to run, as well as desired environment setup etc. and will need to send any code changes or packages updates to them to perform. Admin needs to be quite technically competent.
Admin Bot (admin gives me token): An admin provides me with the bot token (scoped per Anomie below) of a newly created account only for this purpose, allowing me to run the code under myself on Toolforge and fully manage environment setup (needs install and config of multiple python and brew packages not needed for standard pywikibot) as well as instantly deploy any needed code changes or dependency updates without bottlenecks. Admin only needs to know how to use Wikipedia UI and navigate to Special:BotToken, check some boxes, and then submit.
Admin Bot (I run it): For this specific case I am permitted to run my own admin bot. Withdrawn per Rchard2scout and WMF viewdeleted policy.
Bot without Admin Privileges: The bot will report IPs for potential blocking without admin privileges. Not recommended per large volume. Withdrawn per 98 IPs/hour volume, too much for a human admin.
Non-admin bot v2 (preferred by me): My bot, User:MolecularBot is not an admin bot. It can, however, add IP addresses that it finds are the egress of open VPNgate proxies to User:MolecularBot/IP HitList.json (editable only by the bot and WP:PLIERS/interface admins). This means I can run the code for it and manage the complex environment. An admin's bot will be running the uncomplicated code (doesn't require the complex environment and OpenVPN setup for this bot) to just monitor that page for changes and block any IPs added.
Poll
Oppose for now. From reading that discussion, it looks like the IPs available through the API are only the "ingress" IPs, which is what you connect to on their side when using the VPN (and even then, it seems like the VPN client might sometimes use another IP instead?). If there's actually a publicly available list of outgoing IPs available, I'd be very surprised. From an operational standpoint, those IPs don't need to be public, and if they are, that's a serious error on their side. If we do somehow get our hands on a list, I'd be in favour of option 1. There's plenty of admins available who are able to run bots. --rchard2scout (talk) 08:37, 17 December 2024 (UTC)[reply]
Hi rchard2scout, I think you misunderstand the bot. The bot connects to each "ingress" IP and then finds out the "egress" IP that it uses by sending a request to a "what is my IP address API" (not associated with VPNGate in any way), then blocking the egress. This fully disables VPNgate on my local instance of MediaWiki. Thus, a list of egress IPs are not required, because it makes it own by connecting to each of the ingress ones and sending a request. I apologize if my documentation wasn't clear. MolecularPilot🧪️✈️08:44, 17 December 2024 (UTC)[reply]
Noting that I currently do have a complete list of "egress" IPs from my local run of the bot, so should I take your vote as a support of option 1 like you stated? Thank you. MolecularPilot🧪️✈️08:45, 17 December 2024 (UTC)[reply]
Oops, you're right, I somehow missed this. Hadn't had my first coffee yet ;). Striking, adding new vote.
That's so fine, my brain is a little laggy in the early morning as well! My technical/documentation writing probably needs some work as well, it's not my best skill (anyone please feel free to edit this post and make it clearer, if it's wrong I'll just fix it). Thank you for your time in reviewing this even though it's still the early morning where you are! :) MolecularPilot🧪️✈️09:38, 17 December 2024 (UTC)[reply]
Support option 1. Options 2 and 3 are probably incompatible with our local and WMF policies, because an admin bot can do anything an admin can do, and you haven't gone through RfA, so you're not allowed access to rights like viewdeleted. Or (@ anyone who know this) are OAuth permissions granular enough that an admin can generate a token that allows a bot access to block but not to other permissions? In any case, I think option 1 is the easiest and safest way, there's plenty of admins available who are able to run bots. --rchard2scout (talk) 08:59, 17 December 2024 (UTC)[reply]
Hi Rchard2scout, thank you for your new comment and feedback. I hope your morning is going well! Ah yes viewdeleted, silly me to forget about that (I have the opposite problem as you before, it is far too late at night where I live!), I do recall it from someone else's declined proposal of admin sortion, I've struck Option 3 now per WMF legal policy. Re OAuth permissions, I know from using Huggle that when you create a bot token there's a very fine grained list of checkboxed for you to tick, and "block" is in fact one of them, so it is that granular as to avoid all other admin perms, I've expanded Option #2 above to clarify this and more circumstances. I do believe this would be my preferred option, per the reasons I've placed in my expansion, but are really happy with anything as long as we can deal with this LTA. Anyway, enjoy your morning! MolecularPilot🧪️✈️11:29, 17 December 2024 (UTC)[reply]
There's no grant allowing block but no other permissions. The minimum additional admin permissions would be block, blockemail, unreviewedpages, and unwatchedpages. Anomie⚔12:33, 17 December 2024 (UTC)[reply]
Support option 5 as well, and that doesn't even need a BRFA or an RFC. We do then need consensus for the adminbot part of that proposal, so perhaps this discussion can focus on that. --rchard2scout (talk) 10:19, 18 December 2024 (UTC)[reply]
Option 1. I believe this is the only option allowed under policy. Admins need to run admin bots. This RFC is a bit complicated. Usually an RFC of this type would just get consensus for the task ("Is there consensus to run a bot that blocks VPNGate IP addresses?"), with implementation details to be worked out later. –Novem Linguae (talk) 12:09, 17 December 2024 (UTC)[reply]
I'd like to suggest an alternative approach: Write a bot or Toolforge tool that generates a data feed of IP addresses, starting with VPN Gate egress IP addresses, perhaps including the first seen timestamp and last seen timestamp for each egress. The blocking and unblocking portion of the process is relatively simple and a number of administrators could write, maintain, and run a bot that does that. (I suspect most administrators that run bots would prefer to write their own code to do that.) Daniel Quinlan (talk) 23:04, 17 December 2024 (UTC)[reply]
Well, I started writing this suggestion before option 5 was added. Since it looks like this is basically the same as that option, put me down as being in favor of Option 5. Daniel Quinlan (talk) 23:15, 17 December 2024 (UTC)[reply]
Courtesy ping for Rchard2scout and Novem Linguae notifying them of the new preferred option 5 above, which I believe makes everything easier for both myself and the admin who wishes to help me (I'll leave a note on AN asking nicely once BRFA passes for MolecularBot). Also, Skynxnex, you expressed support for option 5 below, did you mean to format that as a support !vote in this section (my apologies for the confusing layout of everything here). Thank you very much to everyone for your time in reviewing this proposal and leaving very helpful feedback. MolecularPilot🧪️✈️09:33, 18 December 2024 (UTC)[reply]
Hey, it's me, User:MolecularPilot on VPNgate. This VPN is listed as 112.187.104.70 on VPNgate cause that's what my PC talks to. But, this VPN when talking to Wikipedia, uses 121.179.23.53 as shown which is completely different and not listed anywhere on VPNgate, showing the need for actually testing the VPNs and figuring out the output IPs are my bot does. Can this IP please be WP:OPP blocked? 121.179.23.53 (talk) 06:22, 17 December 2024 (UTC)[reply]
I don't think blocking a single VPN provider will have the effect people want it to have. It's easy for a disruptive editor to switch VPNs. This is really a problem that needs to be solved by WMF. Daniel Quinlan (talk) 15:45, 17 December 2024 (UTC)[reply]
Hi Daniel Quinlan, I guess I didn't make this clear enough in the post but this is designed to work with existing WMF proposals that are being worked on. Both T380917 and T354599 block/give higher edit filter scrutiny based on existing lists of "bad" IPs, this is the same as the old ST47ProxyBot (which actually does scanning but doesn't monitor "egress" IPs, it only attempts to connect to the "ingress" and then blocks it if successfully). This is great for a wide variety of proxy services because ingress/egress is the same, but for modern, more advanced services like VPNgate (and perhaps some services that because a problem for us in future) the ingress IP address is often not the same as the one used to edit Wikipedia, and so requires this solution (this bot). I'll admit that blocking VPNgate won't fully stop this LTA or all proxy vandals but VPNgate is quite a large and widely used network (claiming a total of 18,810,237,498 lifetime connections) that is currently almost fully permitted to edit Wikipedia, and by blocking it this significantly reduces the surface area for proxy attacks. This also creates the infrastructure for easily blocking any future VPN services that use different ingress/egress IPs - the bot can be easily expanded to use new lists. MolecularPilot🧪️✈️21:14, 17 December 2024 (UTC)[reply]
What is the actual expected volume per day of new IPs to block? It looks like the current list has 98 ingress IPs (if I'm understanding the configuration blocks correctly). I'll also say I have pretty strong concerns about sharing "personal" tokens of any kind between users, particularly admin permission ones with non-admins. Skynxnex (talk) 19:48, 17 December 2024 (UTC)[reply]
The list available through this API frequently rotates. It only provides 98 ingress IPs at a time, as you stated and refetching the list without [some duration of time, from my estimates it's around 1 hour] passing returns the same 98 IPs. After 1 hour (estimated) passes, a new 98 IPs are randomly selected to be provided to all users - but these may include some of the same IPs as before because they are picked by random selection from the whole list of 6057 (not available to the public), this has happened a couple times during my data gathering. Therefore re volume per hour, the maximum number of IPs to be blocked is 98, but it could be less due to already blocked IPs being included in that given hour's sample of 98, I hope this makes sense if there's anything that needs clarifying please don't hesitate to ask. MolecularPilot🧪️✈️21:34, 17 December 2024 (UTC)[reply]
Re "personal" tokens it's actually not a "personal" token to the admin's account, it would be (in theory) a token to an adminbot account with the only things it can be used for being those helpfully specified by Anomie above. However, regardless I see the concerns so I've added a proposal 5 which hopefully is a decent compromise above and ensures that I don't have access to any admin perms/tokens, but that there aren't any bottlenecks and that admins don't need to setup a complex running environment. Thank you for your time in commenting, Skynxnex. MolecularPilot🧪️✈️22:23, 17 December 2024 (UTC)[reply]
VPN Gate claims they have about 6,000 servers which is fairly close to my own estimate of how many IPs they are using. If we block each IP for six months, we'd end up averaging about 33 blocks per day. There would be a pretty large influx at the start, but I would want to spread that out over at least several weeks to avoid flooding the block log as badly as ST47ProxyBot did. Daniel Quinlan (talk) 23:10, 17 December 2024 (UTC)[reply]
It's worth noting that an unknown amount of 'servers' are user computers that people have volunteered cpu time for (this information is somewhere on the website), so, like we see often with IP users, the IP that each server uses can and likely will change with time. This doesn't mean that an effort like this bot won't help, of course, but it's unknown how effective (as a percentage) it would be with just 33 blocks a day. – 2804:F1...33:D1A2 (::/32) (talk) 23:47, 17 December 2024 (UTC)[reply]
33 blocks per day is a rough estimate, not a limit. Certainly there will be some delay when adding entries to any list generated as proposed above so the block rate will never reach 100%, but the egress IPs don't seem to change that much over time based on what I've seen. Daniel Quinlan (talk) 00:09, 18 December 2024 (UTC)[reply]
So, I'm posting this anonymously through VPNGate because I don't want people to start suspecting me of things just because I admit to having used a VPN service some others are abusing to make disruptive edits here. Due to its strong base in Japan, I've used VPNGate many times in order to shop at Japanese web stores that block purchases from outside Japan (they typically don't want to offer international support and see this as the easiest solution for avoiding that), and I know a number of other people who've used it for similar reasons (also for Korea, which often has even more hosts available than Japan).
In any case, while I've personally never enabled this on my PC, I can confirm what IP 2804: said: there's definitely a swarm of short-term volunteer IPs associated with this service who aren't part of VPNGate proper. The overlap between such people and good faith Wikipedia editors may not be large, but it's unlikely to be zero. Unless you have a good mechanism to avoid excessively punishing such users for popping up on your list for the short period of time they themselves use the VPN, maybe it's better to wait for and official WMF solution, which (based on the phabs) seems to intend to take "IP reputation" into account and would thus likely exclude such ephemerals, or at least give them very short term blocks compared to the main servers. Because getting blocked here for several months for having been part of VPNGate for a few hours hardly seems fair.
Actually, now that I think about it: if you're going to connect to VPNGate servers for the express purpose of determining and blocking their exit IPs, you'd probably be in violation of their TOS. While you might consider this an "ends justifying the means" situation, are you sure you want to associate the WMF with such unauthorized usage? There's a difference between port scanning or getting an IP list via an API and actually traversing the VPN in order to investigate it. This absolutely is not a legal threat by me, but if VPNGate were to learn of this, I wouldn't be surprised if they took action. Aren't there enough services out there that provide VPN IP lists without having to roll your own scanner? It would seem a safer bet for the WMF to use something like that. 125.161.156.63 (talk) 16:05, 19 December 2024 (UTC)[reply]
Oh, you didn't have to anonymise yourself, we don't cast WP:ASPERSIONS here and now you won't get a reply notification but that's okay! :) I checked the terms of service of their website before making their bot and it just says not to do anything IRL illegal otherwise they'll give your logged data to authorities if subpoenaed, but I will reach out to the VPNgate operators in Japanese (good practice opportunity, huh) when I have time just to double-confirm they're okay with everything. But btw, they encourage checking that your IP has changed to demonstrate it has worked in their how-to-guides, and this isn't 'tranaversing" as we're not collecting data on every single node but only the public IP of the exit node. Re short-term volunteers, that's a great point, and I'll update the JSON schema of its published data to include a "number of sightings" number, so that the blocking adminbot would escalate blocks as this increases so maybe it starts really short term like 2.5 days/60 hours (6000 active volunteers on average, divided by 100 checked every hour, minimum time to ensure the IP has truly stopped) if it's just 1 sighting but ramps up exponentially if it's seen again as an egress IP untill we're talking like 6months - 2 years blocks. Re WMF tickets, the distributed fact of VPNgate that anyone can start hosting means that most VPNgate IP addresses won't have a bad "reputation" (I checked a whole bunch on a variety of reputation lists and the egresses always had "good"" reputations) so reputation checking won't help (but they need short term blocks), also as you can't publically see the egress with VPNgate cause it's different to ingress (unlike most networks). So WMF solutions are actually quite innovative and smart for most VPN/proxy networks, it's just that VPNgate is a bit different needing a unique solution, this bot. MolecularPilot🧪️✈️04:43, 20 December 2024 (UTC)[reply]
I guess I'm just too careful or chicken even if most people would refrain from casting aspersions.
I don't quite understand why you say you're not traversing. You're not just touching the network from one side, you're passing through it and coming out on the other side, that's traversing. However if they don't mind it, then I guess you're in luck. Ecxept maybe if those Japanese laws they mention a mllion times in their documents have a problem with something like this.
I don't know what the WMF is basing its reputation measurements on. My meaning was that sites like browserleaks.com almost always seem to know about the VPN status of the exit nodes I've used over time. I don't know where they're getting this information from exactly, but that's what I meant by reputation, not whether they're good or bad but what they're known to engage in, like being a VPN node. And that database is probabably built either through collaboration or by specialized services, which the WNF can use as well. Like email providers use common antispam databases instead of each rolling their own.
In any case, good luck with your bot, because I'm afraid these persistent abusers you want to keep out by this probably won't be averse to paying for commercial VPNs if they have to, and many of those only cost a handful of bucks a month. Commercial companies will almost certainly have a TOS that would prohibit your bot, so to counter them the WMF would in the end still have to resort to a specialist or collaborative VPN IP list of some kind. You can probably cut down on casual troublemakers by tracking VPNGate but I don't think it'll help all that much much against anyone highly motivated. They can even continue using VPNGate, it'll just be less convenient because they have to find brand new nodes before you catch those.
I'm not sure what you mean by "Japanese Laws" they keep mentioning they don't seem to mention any, when I told you that the ToS said don't do anything irl illegal I was referring to this ToS page which doesn't mention any "Japanese Laws" but just says don't do anything like CSAM like your government can subpoena us for, because we'll comply (and directions for LEOs to request this). Re reputation yes, the major VPNgate nodes that have done it for a while do have bad reputations, particularly 219.100.37.0/24 which is the example servers run by the university themselves - but as you said, because anyone can start a VPNgate server and then there's always brand new nodes that won't have bad reputations and can be abused. But - as I've stated in a different discussion above, the list of VPN servers to connect to only updates with new servers hourly, so while reputation services won't catch the new exit nodes (because they won't be used poorly enough to trigger flagging for a white), the bot constantly waits for updates to the list and then immediately tests it to determine the new egress IPs. Re commercial services generally, unlike VPNgate, they use datacenters and static IPs that are assigned to "Hotspot Shield, Inc." (as an example) so it's easy to CIDR range block them and also the reputation of those deteriorates over time as they do bad things - the companies don't randomly get new IPs in random locations around the world, like VPNgate. In fact commercial reputation services excel at identifying commercial services (from my testing), but VPNgate is community distributed, like Wikipedia, and needs a unique approach. And yes, as I said to Daniel, I'll admit that blocking VPNgate won't fully stop this LTA or all proxy vandals but VPNgate is quite a large and widely used network (claiming a total of 18,810,237,498 lifetime connections) that is currently almost fully permitted to edit Wikipedia (the bot currently has 146 IPs in its list and as shown by the stats section of the toolforge frontend, ~60% are currently unblocked (and this is an underestimate because the list is mainly the "obvious" ones that are always provided first in the 98 hourly sample, like 219.100.37.0/24. This is because the bot has only had 1 full run of all IPs in a given hour's list, and many failed partial runs of just the first couple. I think blocking VPNgate significantly reduces the surface area for proxy attacks - only looking at only 10 of the blocked IPs I see link spam, edit warring, block evasion, vandalism and our favourite WP:LTA. MolecularPilot🧪️✈️08:38, 21 December 2024 (UTC)[reply]
They mention Japanese laws repeatedly in the texts shown when you click the licence and notice buttons under Help > About of the SoftEther VPN Client Manager. It's a canned statement saying they only comply with Japanese laws because they can't possibly follow every law worldwide.
the bot constantly waits for updates to the list and then immediately tests it to determine the new egress IPs Are you going to run multiple instances of the bot in parallel, because the 98 IP list you get per hour seems far from sufficient for make claims about a strong level of protection if there are ~6000 egresses, many of which churn. With your current setup, an abuser can get their own list refresh, which would be different from what the bot gets, run it past your very helpful :) IP check tool and then make edits from any IP not covered. Which may not be many, but they only need one out of their 98, so it's likely they'll get something as long as the volunteer swarm keeps changing.
Getting a bit more facetious, VPNGate could conversely determine the IP of your bot and block it as a censorship agent. :) I really think it contradicts the spirit of their operation even if they haven't prohibited it explicitly, since you don't happen to be a state agent. This is just my conjecture, but I'm guessing that if you looked at your IP list edits without focusing solely on the abuse, you'd also see constructive edits coming from them, quite possibly from people using VPNGate to bypass state firewalls. I am well aware of Wikipedia open proxy policy, but it can make editing somewhat difficult for such people.
These remain my two sticking points: while useful, the bot won't be quite as effective as you represent; and you're arguably abusing their service to operate yours.
Once this bot starts issuing blocks, you should probably amend Help:I have been blocked to include verbiage about having used a VPN in the recent past, because this situation isn't really covered by the "you are using a VPN" or collateral damage statements. 211.220.201.217 (talk) 15:21, 21 December 2024 (UTC)[reply]
VPNgate does not have as firm of a ground as you claim. Yes, companies have terms of use and those terms of use often have clauses of disputes being filed in their local country. However, as multiple attourneys have pointed out, this local dispute solving when dealing with an customer from abroad does not really work. In reality, VPNgate is forced to deal with international laws, because otherwise they will just lose their case. (one of the legal opinions supporting this: https://svamc.org/cross-border-business-disputes-company-use-international-arbitration/ )
As far as blocks go, yes, they could block one user, but let me remind you that there are 120,000 active wikipedia users. The script could just be passed on between users until all of their IP ranges are blocked. They would lose that war, every time. Snævar (talk) 20:11, 21 December 2024 (UTC)[reply]
I don't recall claiming anything about firm ground. I have a problem with the WMF or parties associated with it engaging in somewhat questionable practices, even if it is for a good cause. I'm OK with port scanning or getting data from an API, because that's external probing, but actually passing through someone's premises with the intent of later restricting their users is something I find objectionable, and it is my conjecture that VPNGate would think likewise. If VPNGate blocked one user's bot, that would simply be an indication that they object to such activities, and having a million other users on the ready to take over would change nothing about that, and I'm fairly certain the WMF does not subscribe to this sort of hackerish way of thinking anyway. VPNGate aren't outlaws against whom anything goes, they operate a prefectly legitimate service, albeit one that some people abuse. It's also possible that it's just me, and VPNGate themselves have no objection to any of this. The OP was going to ask them, so I presume they'll inform everyone about the response sometime soon. 220.81.178.129 (talk) 11:44, 22 December 2024 (UTC)[reply]
Yes, this is definitely not something that should be adversarial or "us against them" and if they express concerns about this behaviour, we should totally not try and evade it - after all VPNgate does share our mission of spreading free knowledge to the world (and are very useful to spreading Wikipedia and other websites around the globe, it's just some bad actors taking advantage of the kind service of both the university and the volunteers creating a problem). We just need to find a way to work together to ensure that we both can continue to do our things. Being the holiday season, it's pretty busy for me and I'm sure the same is true for the operators so I will reach out in the new year re their thoughts on this. MolecularPilot🧪️✈️04:45, 23 December 2024 (UTC)[reply]
Hi! The abuser can't get their own list refresh seperate from what the bot sees, I guess I wasn't clear before but what I meant was that everyone gets the same 98 IPs every hour, and then the next hour another 98 are randomly selected to be shown to everyone.
Re censroship/state agencies this doesn't help state agents or censorship at all, because they want to block the input/ingress IP addresses that citizens would use to connect to the VPN network, and knowing the egress that the VPN network uses to connect to servers doesn't help them at all. I have clarified this in the README.md now so anyone who sees the project will know that it can't be used for censorship.
Re users bypassing state firewalls, they can still read and if they want to edit we have WP:ACC for that (abusers could go through acc I guess, but then they can't block evade once their account gets indef'ed - and VPNgate has been used a lot by link spammers, people who want to edit war (especially someone who got really upset about castes, I've seen a lot of edit warring from detected IPs about that) to evade the blocks on their main account).
Btw, thank you for calling my tool helpful, I'm not the best at UI design but I tried to put some effort in and make it looks nice and have useful functions. Thank you to you as well for your time in providing soooo much helpful feedback to make the bot better. :) MolecularPilot🧪️✈️03:52, 22 December 2024 (UTC)[reply]
Also thanks for reminding me to provide guidance to users on this, I think the current WP:OPP block message doesn't really fit with the VPNgate mode of temporary volunteers (who the user effected might not even know about but could get a dynamic assignment with an IP blocked for a few days). I'll make a custom block template! :) MolecularPilot🧪️✈️03:54, 22 December 2024 (UTC)[reply]
While tone of you thanks seems to include some aspersions :), you're welcome if what I've said has helped you. If the list is the same for everyone, you can indeed be a lot more effective. My point about censorship was less about you helping state censors and more about you using the loophole that VPNGate haven't said anything about private actors, and giving the impression that abuse is the only thing it is being used for. 220.81.178.129 (talk) 11:39, 22 December 2024 (UTC)[reply]
Oh no I'm really sad now, please don't take my tone when I thanked you in the wrong way (it can be both hard to express and pick up on the internet)! Maybe saying "sooooo" was a bit over the top, but you've genuinely gone back and forth with me a lot of times and always written detailed, logical suggestions or concerns to help, so genuinely, no sarcasm, thank you!!! :) MolecularPilot🧪️✈️04:41, 23 December 2024 (UTC)[reply]
How feasible would it be to make the list of IPs private/admin-only? I mean, they're still going to get blocked, and that's public, but I feel like making a public list, even if one may or may not already exist, might be an unnecessary step?
If I ran a VPN service I'd be a lot less upset about Wikipedia defending itself than Wikipedia creating a public up-to-date list of VPN IPs that everyone can use, without effort, to mass block most of my VPN. – 2804:F1...57:88CF (::/32) (talk) 02:09, 24 December 2024 (UTC)[reply]
Why are frwiki talk pages so much nicer than ours?
There are some gadgets that support it. I think ConvenientDiscussions is one of them. I'm not a general fan of the styling. Izno (talk) 02:08, 18 December 2024 (UTC)[reply]
Threads are collapsible, and a change is coming that would allow to collapse/expand all replies to a comment in one click, similar to how you can do that on Reddit with a +/− button.And, of course, pure CSS is only a half-solution here since markup and HTML produced by it are trickier and don't correspond to the actual comment structure as one-to-one. Jack who built the house (talk) 05:31, 20 December 2024 (UTC)[reply]
I created my own experimental CSS stylesheet to add style formatting to discussion threads; see User:Isaacl/style/discussion-threads for an example of how it looks and instructions on using it. There is an accompanying user script to temporarily turn the style formatting off for the current page, should you want to see how the page looks by default. isaacl (talk) 02:25, 18 December 2024 (UTC)[reply]
What's been done in the past is A/B testing of different gimmicks by the WMF. I'd be curious to see the rate of abandoned comments now versus with a shiny new layout is. JayCubby15:16, 18 December 2024 (UTC)[reply]
My stylesheet continues to be used by (double-checks)... only me. I like it, but it's not evident yet that there's a significant demand for different styling of discussion threads. isaacl (talk) 18:17, 18 December 2024 (UTC)[reply]
The threading is entirely frwiki's custom CSS. It's pretty easy to do, with how talk pages use nested definition-list syntax for discussions already; body.ext-discussiontools-replytool-enabled dd { border-left: 2px solid lavender; padding-left: 1ex; } gets you about 95% of the way there. There's plenty of room to get fancier, of course. (And sometime people use unordered lists instead, which would need to be handled separately.)
There's also a visible difference since enwiki is the only place that the DiscussionTools "visual enhancements" haven't been turned on yet (T379102). That's why they have the fancier thread summaries in the topic list and under the headings, and the more button-like reply links. If you're curious what that'd be like here, you can turn it on with the dtenable URL parameter.
We did experiment with going much further in page-reformatting with DiscussionTools as well. You can see our structure-debug page for an example of that. It's actually what the talk pages in the mobile apps use now -- they get the talk page data from the DiscussionTools API and build the view from that, rather than from the normal wikitext render. DLynch (WMF) (talk) 16:39, 18 December 2024 (UTC)[reply]
You can enable DiscussionTools in the beta menu. I don't know where that's located in Vector 2022's menu (I use MonoBook), but it's in there. ♠JCW555(talk)♠ 04:46, 19 December 2024 (UTC)[reply]
For the record, those boxes don't show up on mobile. That issue, combined with the fact that replies aren't as far apart in the new version, makes it harder for mobile users to tell who is replying to who compared to the current version. QuicoleJR (talk) 19:05, 19 December 2024 (UTC)[reply]
It would be indeed great to have more control over sorting threads, especially since there are a number of wikis (including the main wiki I contribute to, Russian Wikipedia) which have to resort to bad hacks to display certain forum pages in recent-oldest sorting order and not oldest-recent as it is default. It would’ve been great to see these hacks made obsolete with DiscussionTools, see phab:T313165, but AFAIK no one actively develops it any more, so I guess we’ll have to wait till WMF decides to fund it again. stjn21:40, 19 December 2024 (UTC)[reply]
I don't know if it's just me noticing something that has been there for a long time, or if something new is happening, or if my CSS or browser is to blame, but I am noticing undesirable line wrapping that I have not seen before. I am seeing references after full stops (periods) that wrap to the next line. I'm seeing the ")" in "f/16)" (in the lead of Exposure value) wrapping to the next line. And I think one other kind of wrapping that should not be happening but that I can't remember at the moment. I don't think this sort of wrapping was happening before; references stayed with the preceding punctuation, and a closing parenthesis would stay with the text that preceded it. I could be wrong or misremembering, of course. My gut feeling is that I just started noticing it in the last month or so.
If it's just me, I'll live with it, but I thought I would post here to see if this prompts anyone else to chime in. I am using Vector 2022 on the latest Firefox for Mac OS. I can link to example pages and even provide screen shots as needed. – Jonesey95 (talk) 01:01, 19 December 2024 (UTC)[reply]
I am seeing references after full stops (periods) that wrap to the next line.
This has unfortunately always been the case. I found Phab tasks and comments documenting this going back to 2016: T100112#2027495, T125480. There have been cases where line wrapping around references behaved even worse than that (interesting ones I found: T96487, T110057, T132255), and those have been fixed.
I'm seeing the ")" in "f/16)" (in the lead of Exposure value) wrapping to the next line
I can reproduce this, screenshot for reference: F58028918. This is caused by using display: inline-block; in the template {{f/}} (basically the same issue as T110057 mentioned above, actually). It was added not quite a year ago: [12]. I'm not sure what these rules are for, but someone could probably find a way to do this differently and avoid the problem.
And I think one other kind of wrapping that should not be happening but that I can't remember at the moment.
Well, it's a bit tricky to guess from that ;), but my crystal ball shows me you're thinking of T353005, where some error and warning messages now break words with hyphens when wrapping lines, starting also about a year ago. I heard a few people complain about that and I find it a bit unpleasant myself. Did I guess right?
The problem with NOT wrapping (especially when dictated by templates), is that it works for 90% of the cases. But there is also the 10% of cases where the value is too small to fit in the infobox or on a mobile screen in 1 line. But the templates can't make that distinction, so it's generally a bad idea to put 'no wrap' as a default in a template. Overall it is better to depend on the browser to mostly do things right and not fret too much about the occasional times that it gets it wrong. Because flipping that assumption around tends to create harder to maintain wikitext that gets it wrong about the same or even more often. —TheDJ (talk • contribs) 09:36, 19 December 2024 (UTC)[reply]
Updating broken JavaScript user script for adding a template to RefToolbar 2.0
Hi! Hopefully this is the right place to put this. Template:Cite RCDB's documentation contains a suggested user script to add the template to RefToolbar 2.0. However, it imports User:Mr.Z-man/refToolbar 2.0.js, which hasn't been a think since 2013. On the page is now a note saying "This script is now enabled by default." The existing script, however, does not work out of the box, throwing the error below. If someone who knows JS could help modify the script to work without the linked user script, that would be great!
VM385:2 Uncaught ReferenceError: $j is not defined
at <anonymous>:2:913
at globalEval (startup.js:1141:17)
at runScript (startup.js:1292:6)
at enqueue (startup.js:1179:5)
at execute (startup.js:1399:5)
at doPropagation (startup.js:748:6)
I was unable to complete an edit a few minutes ago. I got an error message saying the site was under maintenance. Clicking on "back" did get me the edit I was trying to make and a few seconds later I was successful.
I posted just for documentation but I am having difficulty with a site that is very slow and I came here to do an edit to have something to do while waiting for pages on that slow site to come up. The slow site slows everything else down.— Vchimpanzee • talk • contributions • 21:21, 20 December 2024 (UTC)[reply]
Blacklisted website not on any blacklist
I wanted to save an edit containing a link to tradingview.com but it keeps showing a message:
"Your edit was not saved because it contains a new external link to a site registered on Wikipedia's blacklist or Wikimedia's global blacklist. [...] The following link has triggered a protection filter: tradingview.com [...]"
So I tried to figure out whether I shouldn't use that website as a source and on what blacklist that website is supposed to be but I couldn't find anything. Is that a bug? Killarnee (talk) 14:18, 21 December 2024 (UTC)[reply]
Hm now I found it too, somehow the find tool in Safari wasn't able to find it. Thanks you both. Looks like I have to search for another source. Killarnee (talk) 14:58, 21 December 2024 (UTC)[reply]
It works now. Problems come and go. I had to restart my phone half an hour ago to get something to work. Extra: That was a problem with an app on my phone (nothing to do with Wikipedia).Johnuniq (talk) 03:10, 22 December 2024 (UTC)[reply]
Likely also worth noting that, above the error, it says To avoid creating high database load, this query was aborted because the duration exceeded the limit. Though I suppose that's the definition of a timeout... – Daℤyzzos (✉️ • 📤) Please do notping on reply.15:43, 22 December 2024 (UTC)[reply]
When the {{Infobox government agency}} template is included into some page, SVG images inside it have their colors inverted if the dark mode is on. See, for example, the article United States Department of State, specifically the seal: it should have dark blue outter ring, white inner circle with a brown eagle, but instead you can see the seal with a bluish-white outter ring, black inner circle with an orange eagle. Looked at several other infobox templates, none of them have a simmilar issue. Also, only vector images are affected by this, raster images are not. I wanted to try to debug it, but the template is fully protected. Tohaomg (talk) 17:30, 22 December 2024 (UTC)[reply]
The reason skin-invert worked for signatures was that white writing paper is common and even though colors in pens is varied, the most commonly used ones are dark.
Logos are not created on the basis of a palette of colors, unlike signatures. Logos are created to be visible and understandable from far away and close up. As such, they should not be inverted at large.
I consider the edit request in the template to be unactionable, as it did not ask for any particular solution, not even a hint at one. Snævar (talk) 23:24, 22 December 2024 (UTC)[reply]
I'm not sure why people are continuing to reply here. This discussion will be lost in the archives of VPT; please post at the template talk page with comments, suggestions, proposed fixes, or requests. – Jonesey95 (talk) 06:00, 23 December 2024 (UTC)[reply]
@Jonesey95: I am not buying that argument for one second, also you are refusing to talk about the issue itself. Stop this bureaucratic nonsense. Most issues are solved during discussion not after, it being "lost in the archive" is a non starter as an argument. Clearly neither myself or Sjoerddebruin are going to move this discussion to the template talk page. If you continue attempting to refrain from discussing about the issue itself, consider this your first warning. I would also like to voice my disappointment of how you are handling this, I do expect better than this. Snævar (talk) 09:24, 23 December 2024 (UTC)[reply]
Responding like this and bypassing the instructions that are clearly indicated at the top of the template page is really something, especially with an unsure edit summary. Sjoerd de Bruin(talk)09:32, 23 December 2024 (UTC)[reply]
I wasn't discussing the issue here because of WP:MULTI. See the template's talk page for further discussion. I have reverted the change and continue to welcome a better way to fix the problem that was identified and that is still present. – Jonesey95 (talk) 15:55, 23 December 2024 (UTC)[reply]
Historical use of File:Wiki.png as the top-left logo
I wonder if anybody remembers some technical details of the use of File:Wiki.png for the logo in the top-left corner during the 2000s (not limited to enwiki). This discussion led me to asking this. I found some clues on Commons – quoting myself from the aforementioned discussion:
The log for File:Wiki.png shows two interesting entries:
protection, 11 July 2005: it's the sitewide logo in the upper left corner. Very bad if it were to get vandalized.
Image:Wiki.png should be moved to a different name (already re-created at Image:Wiki-commons.png) as it currently is aliasing that name on every wiki project and therefore not allowing local logos on those projects. Tim has already changed the logo location, so it shouldn't break the commons logo, but we should wait about a week before moving it to give time for the caches to update. The logo is now hardcoded so there is no need to protect this specific image.
I don't really remember, but we have historical records of the configuration going back to 2012. The current system, where logos of each wiki are stored in the configuration, was introduced in 2015 in change 209616 and other commits around that time. Wikis had the option to use the locally uploaded Wiki.png as a logo until 2017, when it was removed in change 359037. Alas I don't really know the historical context around these changes, I just found them in the history. Matma Rextalk14:13, 23 December 2024 (UTC)[reply]
Hi. To follow up a query a user had on my talk page, I wanted to see if there was any way that edits using Cat-a-lot could be marked as minor by default? At present there is now way I am aware of to mark these edits as minor. Alternatively, would there be another way these edits could be filtered out of watchlists? We have a tick box to hide "page categorization", so could they maybe be included in that for example? Thanks. Jevansen (talk) 23:42, 23 December 2024 (UTC)[reply]
Aha! The userscript you imported the gadget from (User:קיפודנחש/cat-a-lot.js, you import them here), manually sets the preference, including a minor: false!
I'm pretty sure you can overwrite that by just adding a line setting the preference after you import the script, but you could aso just copy their script into your common.js (replacing the import) and change that part to minor: true, that would also do what you want. – 2804:F1...57:88CF (::/32) (talk) 02:36, 24 December 2024 (UTC)[reply]
RfC: Log the use of the HistMerge tool at both the merge target and merge source
Currently, there are open phabtickets proposing that the use of the HistMerge tool be logged at the target article in addition to the source article. Several proposals have been made:
Option 1a: When using Special:MergeHistory, a null edit should be placed in both the merge target and merge source's page's histories stating that a history merge took place.
(phab:T341760: Special:MergeHistory should place a null edit in the page's history describing the merge, authored Jul 13 2023)
Option 1b: When using Special:MergeHistory, add a log entry recorded for the articles at the both HistMerge target and source that records the existence of a history merge.
(phab:T118132: Merging pages should add a log entry to the destination page, authored Nov 8 2015)
Option 2: Do not log the use of the Special:MergeHistory tool at the merge target, maintaining the current status quo.
Should the use of the HistMerge tool be explicitly logged? If so, should the use be logged via an entry in the page history or should it instead be held in a dedicated log? — Red-tailed hawk(nest)15:51, 20 November 2024 (UTC)[reply]
Option 1a/b. I am in principle in support of adding this logging functionality, since people don't typically have access to the source article title (where the histmerge is currently logged) when viewing an article in the wild. There have been several times I can think of when I've been going diff hunting or browsing page history and where some explicit note of a histmerge having occurred would have been useful. As for whether this is logged directly in the page history (as is done currently with page protection) or if this is merely in a separate log file, I don't have particularly strong feelings, but I do think that adding functionality to log histmerges at the target article would improve clarity in page histories. — Red-tailed hawk(nest)15:51, 20 November 2024 (UTC)[reply]
Option 1a/b. No strong feelings on which way is best (I'll let the experienced histmergers comment on this), but logging a history merge definitely seems like a useful feature. Chaotic Enby (talk · contribs) 16:02, 20 November 2024 (UTC)[reply]
1b would be most important to me but but 1a would be nice too. But this is really not the place for this sort of discussion, as noted below. Graham87 (talk) 16:28, 20 November 2024 (UTC)[reply]
Option 2 History merging done right should be seamless, leaving the page indistinguishable from if the copy-paste move being repaired had never happened. Adding extra annotations everywhere runs counter to that goal. Prefer 1b to 1a if we have to do one of them, as the extra null edits could easily interfere with the history merge being done in more complicated situations. * Pppery *it has begun...16:49, 20 November 2024 (UTC)[reply]
Could you expound on why they should be indistinguishable? I don't see how this could harm any utility. A log action at the target page would not show up in the history anyways, and a null edit would have no effect on comparing revisions. Aaron Liu (talk) 17:29, 20 November 2024 (UTC)[reply]
2 History merges are already logged, so this survey name is somewhat off the mark. As someone who does this work: I do not think these should be displayed at either location. It would cause a lot of noise in history pages that people probably would not fundamentally understand (2 revisions for "please process this" and "remove tag" and a 3rd revision for the suggested log), and it would be "out of order" in that you will have merged a bunch of revisions but none of those revisions would be nearby the entry in the history page itself. I also find protections noisy in this way as well, and when moves end up causing a need for history merging, you end up with doubled move entries in the merged history, which also is confusing. Adding history merges to that case? No thanks. History merges are more like deletions and undeletions, which already do not add displayed content to the history view. Izno (talk) 16:54, 20 November 2024 (UTC)[reply]
They presently are logged, but only at the source article. Take for example this entry. When I search for the merge target, I get nothing. It's only when I search the merge source that I'm able to get a result, but there isn't a way to know the merge source.
If I don't know when or if the histmerge took place, and I don't know what article the history was merged from, I'd have to look through the entirety of the merge log manually to figure that out—and that's suboptimal. — Red-tailed hawk(nest)17:05, 20 November 2024 (UTC)[reply]
... Page moves do the same thing, only log the move source. Yet this is not seen as an issue? :)
But ignoring that, why is it valuable to know this information? What do you gain? And is what you gain actually valuable to your end objective? For example, let's take your There have been several times I can think of when I've been going diff hunting or browsing page history and where some explicit note of a histmerge having occurred would have been useful. Is not the revisions left behind in the page history by both the person requesting and the person performing the histmerge not enough (see {{histmerge}})? There are history merges done that don't have that request format such as the WikiProject history merge format, but those are almost always ancient revisions, so what are you gaining there? And where they are not ancient revisions, they are trivial kinds of the form "draft x -> page y, I hate that I even had to interact with this history merge it was so trivial (but also these are great because I don't have to spend significant time on them)". Izno (talk) 17:32, 20 November 2024 (UTC)[reply]
... Page moves do the same thing, only log the move source. Yet this is not seen as an issue? :)
Page moves do leave a null edit on the page that describes where the page was moved from and was moved to. And it's easy to work backwards from there to figure out the page move history. The same cannot be said of the Special:MergeHistory tool, which doesn't make it easy to re-construct what the heck went on unless we start diving naïvely through the logs. — Red-tailed hawk(nest)17:50, 20 November 2024 (UTC)[reply]
It can be *possible* to find the original history merge source page without looking through the merge log, but the method for doing so is very brittle and extremeley hacky. Basically, look for redirects to the page using "What links here", and find the redirect whose first edit has an unusual byte difference. This relies on the redirect being stable and not deleted or retargetted. There is also another way that relies on byte difference bugs as described in the above-linked discussion by wbm1058. Both of those are ... particularly awful. Graham87 (talk) 03:48, 21 November 2024 (UTC)[reply]
In the given example, the history-merge occurred here. Your "log" is the edit summaries. "Created page with '..." is the edit summary left by a normal page creation. But wait, there is page history before the edit that created the page. How did it get there? Hmm, the previous edit summary "Declining submission: v - Submission is improperly sourced (AFCH)" tips you off to look for the same title in draft: namespace. Voila! Anyone looking for help with understanding a particular merge may ask me and I'll probably be able to figure it out for you. – wbm1058 (talk) 05:51, 21 November 2024 (UTC)[reply]
Here's another scenario, this one from WP:WikiProject History Merge. The page history shows an edit adding +5,800 bytes, leaving the page with 5,800 bytes. But the previous edit did not leave a blank page. Some say this is a bug, but it's also a feature. That "bug" is actually your "log" reporting that a hist-merge occurred at that edit. Voila, the log for that page shows a temp delete & undelete setting the page up for a merge. The first item on the log:
clues you in to where to look for the source of the merge. Voila, that single edit which removed −5,633 bytes tells you that previous history was merged off of that page. The log provides the details. – wbm1058 (talk) 16:03, 21 November 2024 (UTC)[reply]
Again, there are times where the clues are much harder to find, and even in those cases, it'd be much better to have a unified and assured way of finding the source. Aaron Liu (talk) 16:11, 21 November 2024 (UTC)[reply]
Support 1b (log only), oppose 1a (null edit). I defer to the experienced histmergers on this, and if they say that adding null edits everywhere would be inconvenient, I believe them. However, I haven't seen any arguments against logging the histmerge at both articles, so I'll support it as a sensible idea. (On a similar note, it bothers me that page moves are only logged at one title, not both.) Toadspike[Talk]17:10, 20 November 2024 (UTC)[reply]
Option 2. The merges are already logged, so there’s no reason to add it to page histories. While it may be useful for habitual editors, it will just confuse readers who are looking for an old revision and occasional editors. Ships & Space(Edits)18:33, 20 November 2024 (UTC)[reply]
But only the source page is logged as the "target". IIRC it currently can be a bit hard to find out when and who merged history into a page if you don't know the source page and the mergeperson didn't leave any editing indication that they merged something. Aaron Liu (talk) 18:40, 20 November 2024 (UTC)[reply]
1B. The present situation of the action being only logged at one page is confusing and unhelpful. But so would be injecting null-edits all over the place. — SMcCandlish☏¢ 😼 01:38, 21 November 2024 (UTC)[reply]
Option 2. This exercise is dependent on finding a volunteer MediaWiki developer willing to work on this. Good luck with that. Maybe you'll find one a decade from now. – wbm1058 (talk) 05:51, 21 November 2024 (UTC)[reply]
And, more importantly, someone in the MediaWiki group to review it. I suspect there are many people, possibly including myself, who would code this if they didn't think they were wasting their time shuffling things from one queue to another. * Pppery *it has begun...06:03, 21 November 2024 (UTC)[reply]
That link requires a Gerrit login/developer account to view. It was a struggle to get in to mine (I only have one because of an old Toolforge account and I'd basically forgotten about it), but for those who don't want to go through all that, that group has only 82 members (several of whose usernames I recognise) and I imagine they have a lot on their collective plate. There's more information about these groups at Gerrit/Privilege policy on MediaWiki. Graham87 (talk) 15:38, 21 November 2024 (UTC)[reply]
Sorry, I totally forgot Gerrit behaved in that counterintuitive way and hid public information from logged out users for no reason. The things you miss if Gerrit interactions become something you do pretty much every day. If you want to count the members of the group you also have to follow the chain of included groups - it also includes https://ldap.toolforge.org/group/wmf, https://ldap.toolforge.org/group/ops and the WMDE-MediaWiki group (another login-only link), as well as a few other permission edge cases (almost all of which are redundant because the user is already in the MediaWiki group) * Pppery *it has begun...18:07, 21 November 2024 (UTC)[reply]
Fine. This stupid RfC isn't even asking the right questions. Why did I need to delete (an expensive operation) and then restore a page in order to "set up for a history merge" Should we fix the software so that it doesn't require me to do that? Why did the page-mover resort to cut-paste because there was page history blocking their move, rather than ask a administrator for help? Why doesn't the software just let them move over that junk page history themselves, which would negate the need for a later hist-merge? (Actually in this case the offending user only has made 46 edits, so they don't have page-mover privileges. But they were able to move a page. They just couldn't move it back a day later after they changed their mind.) wbm1058 (talk) 13:44, 21 November 2024 (UTC)[reply]
Option 1b – changes to a page's history should be listed in that page's log. There's no need to make a null edit; pagemove null edits are useful because they meaningfully fit into the page's revision history, which isn't the case here. jlwoodwa (talk) 00:55, 22 November 2024 (UTC)[reply]
I'm noticing some commentary in the above RfC (on widening importer rights) as to whether or not this might be useful going forward. I do think that having the community weigh in one way or another here would be helpful in terms of deciding whether or not this functionality is worth building. — Red-tailed hawk(nest)15:51, 20 November 2024 (UTC)[reply]
I agree that this is an odd thing to RFC. This is about a feature in MediaWiki core, and there are a lot more users of MediaWiki core than just English Wikipedia. However, please do post the results of this RFC to both of the phab tickets. It will be a useful data point with regards to what editors would find useful. –Novem Linguae (talk) 23:16, 21 November 2024 (UTC)[reply]
I'm pretty sure that even if we had enough checkuser capacity to routinely run checks on every new user that doing so would be contrary to global policy. Thryduulf (talk) 04:14, 22 November 2024 (UTC)[reply]
Setting aside privacy issues, the fact that the WMF wouldn't let us do it, and a few other things: Checking a single account, without any idea of who you're comparing them to, is not very effective, and the worst LTAs are the ones it would be least effective against. This has been floated several times in the much narrower context of adminship candidates, and rejected each time. It probably belongs on WP:PEREN by now. -- Tamzin[cetacean needed] (they|xe) 04:21, 22 November 2024 (UTC)[reply]
Why can't it be automated? What are the privacy issues and what would WMF concerns be? There has to be a better system than SPI which imposes a huge burden on the filer (and often fails to catch socks) while we just leave the door open for LTAs. Mztourist (talk) 04:39, 22 November 2024 (UTC)[reply]
How would it be automated? We can't just block everyone who even sometimes shares an IP with someone, which is most editors once you factor in mobile editing and institutional WiFi. Even if we had a system that told checkusers about all shared-IP situations and asked them to investigate, what are they investigating for? The vast majority of IP overlaps will be entirely innocent, often people who don't even know each other. There's no way for a checkuser to find any signal in all that noise. So the only way a system like this would work is if checkusers manually identified IP ranges that are being used by LTAs, and then placed blocks on those ranges to restrict them from account creation... Which is what already happens. -- Tamzin[cetacean needed] (they|xe) 04:58, 22 November 2024 (UTC)[reply]
I would assume that IT experts can work out a way to automate CheckUser. If someone edits on a shared IP used by a previous sock that should be flagged and human CheckUsers notified so they can look at the edits and the previous sock edits and warn or block as necessary. Mztourist (talk) 05:46, 22 November 2024 (UTC)[reply]
We already have autoblock. For cases it doesn't catch, there's an additional manual layer of blocking, where if a sock is caught on an IP that's been used before but wasn't caught by autoblock, a checkuser will block the IP if it's technically feasible, sometimes for months or years at a time. Beyond that, I don't think you can imagine just how often "someone edits on a shared IP used by a previous sock". I'm doing that right now, probably, because I'm editing through T-Mobile. Basically anyone who's ever edited in India or Nigeria has been on an IP used by a previous sock. Basically anyone who's used a large institution's WiFi. There is not any way to weed through all that noise with automation. -- Tamzin[cetacean needed] (they|xe) 05:54, 22 November 2024 (UTC)[reply]
Addendum: An actually potentially workable innovation would be something like a system that notifies CUs if an IP is autoblocked more than once in a certain time period. That would be a software proposal for Phabricator, though, not an enwiki policy proposal, and would still have privacy implications that would need to be squared with the WMF. -- Tamzin[cetacean needed] (they|xe) 05:57, 22 November 2024 (UTC)[reply]
I believe Tamzin has it about right, but I want to clarify a thing. If you're hypothetically using T-Mobile (and this also applies to many other ISPs and many LTAs) then the odds are very high that you're using an IP address which has never been used before. With T-Mobile, which is not unusually large by any means, you belong to at least one /32 range which contains a number of IP addresses so big that it has 30 digits. These ranges contain a huge number of users. At the other extreme you have some countries with only a handful of IPs, which everyone uses. These IPs also typically contain a huge number of users. TLDR; is someone is using a single IP on their own then we'll probably just block it, otherwise you're talking about matching a huge number of users. -- zzuuzz(talk)03:20, 23 November 2024 (UTC)[reply]
T-Mobile USA is a perennial favourite of many of the most despicable LTAs, but that's besides the point. New users with an account can actually edit from T-Mobile. They can also edit from Jio, or Deutsche Telecom, Vodafone, or many other huge networks. -- zzuuzz(talk)03:50, 23 November 2024 (UTC)[reply]
It would apply to every new User as a protective measure against sockpuppetry, like a credit check before you get a card/overdraft. WP:NOTFISHING is archaic like the whole burdensome SPI system that forces honest users to do all the hard work of proving sockpuppetry while socks and vandals just keep being welcomed in under WP:AGF. Mztourist (talk) 05:46, 22 November 2024 (UTC)[reply]
What you're suggesting is to just inundate checkusers with thousands of cases. The suggestion (as I understand it) removes burden from SPI filers by adding a disproportional burden on checkusers, who are already an overworked group. If you're suggesting an automated solution, then I believe IP blocks/IP range blocks and autoblock (discussed by Tamzin, above) already cover enough. It's quite hard to weigh up what you're really suggesting because it feels very vague without much detail - it sounds like you're just saying "a new SPI should be opened for every new user and IP, forever" which is not really a workable solution (for instance, 50 accounts were made in the last 15 minutes, which is about one every 18 seconds) BugGhost🦗👻18:12, 22 November 2024 (UTC)[reply]
And most of those accounts will make zero, one, or two edits, and then never be used again. Even if we liked this idea, doing it for every single account creation would be a waste of resources. WhatamIdoing (talk) 23:43, 22 November 2024 (UTC)[reply]
CU's use their tools to identify socks when technical proof is necessary. The problem you're linking to is caused by one particular LTA account who is extremely obvious and doesn't really require technical proof to identify - check users would just be able to provide evidence for something that is already easy to spot. There's an essay on the distinction over at WP:DUCKBugGhost🦗👻14:45, 23 November 2024 (UTC)[reply]
LTA MAB is using a peer-to-peer VPN service which is similar to TOR. Blocking peer-to-peer VPN service endpoint IP addresses carries a higher risk of collateral damage because those aren't assigned to the VPN provider but rather a third party ISP who is likely to dynamically reassign the blocked address to a completely innocent party. 216.126.35.235 (talk) 00:22, 27 November 2024 (UTC)[reply]
The question I ask myself is why must we realize that it is not meant for fishing? To catch fish, you need to fish. The no-fishing rule is not fit for purpose, nor is it a rule that other organizations that actively search for ban evasion use. Machines can do the fishing. They only need to show us the fish they caught. Sean.hoyland (talk) 05:24, 27 November 2024 (UTC)[reply]
I think for the same reason we don't want governments to be reading our mail and emails. If we checkuser everybody, then nobody has any privacy. Donald Albury20:20, 27 November 2024 (UTC)[reply]
I sympathize with Mztourist. The current system is less effective than it needs to be. Ban evading actors make a lot of edits, they are dedicated hard-working folk in contentious topic areas. They can make up nearly 10% of new extendedconfirmed actors some years and the quicker an actor becomes EC the more likely they are to be blocked later for ban evasion. Their presence splits the community into two classes, the sanctionable and the unsanctionable with completely different payoff matrices. This has many consequences in contentious topic areas and significantly impacts the dynamics. The current rules are probably not good rules. Other systems have things like a 'commitment to authenticity' and actively search for ban evasion. It's tempting to burn it all down and start again, but with what? Having said that, the SPI folks do a great job. The average time from being granted extendedconfirmed to being blocked for ban evasion seems to be going down. Sean.hoyland (talk) 18:28, 22 November 2024 (UTC)[reply]
WhatamIdoing, me too. I'm doubtful about everything I say because I've noticed that the chance it is slightly to hugely wrong is quite high. The EC numbers are work in progress, but I got distracted. The description "nearly 10% of new extendedconfirmed actors" is a bit misleading, because 'new' doesn't really mean new actors. It means actors that acquired EC for a given year, so newly acquired privileges. They might have registered in previous years. Also, I don't have 100% confidence in the way count EC grants because there are some edge cases, and I'm ignoring sysops. But anyway, the statement was based on this data of questionable precision. And the statement about a potential relationship between speed of EC acquisition and probability of being blocked is based on this data of questionable precision. And of course, currently undetected socks are not included, and there will be many. Sean.hoyland (talk) 03:39, 23 November 2024 (UTC)[reply]
I'm not interested in clicking through to a Google file. Here's my back-of-the-envelope calculation: We have something like 120K accounts that would qualify for EXTCONF. Most of these are no longer active, and many stopped editing so long ago that they don't actually have the user right.
Wikipedia is almost 24 years old. That makes convenient math: On average, since inception, 5K editors have achieved EXTCONF levels each year.
If the 10% estimate is true, then 500 accounts per year – about 10 per week – are being created by banned editors and going undetected long enough for the accounts to make 500 edits and to work in CTOP areas. Do we even have enough WP:BANNED editors to make it plausible to expect banned editors to bring 500 accounts a year up to EXTCONF levels (plus however many accounts get started but are detected before then)? WhatamIdoing (talk) 03:53, 23 November 2024 (UTC)[reply]
Suit yourself. I'm not interested in what interests other people or back of the envelope calculations. I'm interested in understanding the state of a system over time using evidence-based approaches by extracting data from the system itself. Let the data speak for itself. It has a lot to tell us. Then it is possible to test hypotheses and make evidence-based decisions. Sean.hoyland (talk) 04:13, 23 November 2024 (UTC)[reply]
More than 100 XC socks? Or more than 100 detected socks, including socks with zero edits?
Making a lot of accounts isn't super unusual, but it's a lot of work to get 100 accounts up to 500+ edits. Making 50,000 edits is a lot, even if it's your full-time job. WhatamIdoing (talk) 01:59, 24 November 2024 (UTC)[reply]
Lots of users get it done in a couple of days, often through vandal fighting tools. It really is not that many when the edits are mostly mindless. nableezy - 00:18, 26 November 2024 (UTC)[reply]
But that's kind of my point: "A couple of days", times 100 accounts, means 200–300 days per year. If you work five days per week and 52 weeks per year, that's 260 work days. This might be possible, but it's a full-time job.
Since the 30-day limit is something that can't be achieved through effort, I wonder if a sudden change to, say, 6 months would produce a five-month reprieve. WhatamIdoing (talk) 02:23, 26 November 2024 (UTC)[reply]
Imagine that it takes an average of one minute to make a (convincing) edit. That means that 500 edits = 8.33 hours, i.e., more than one full work day.
Imagine, too, that having reached this point, you actually need to spend some time using your newly EXTCONF account. This, too, takes time.
If you operate several accounts at once, that means:
You spend an hour editing from Account1. You spend the next hour editing from Account2. You spend another hour editing from Account3. You spend your fourth hour editing from Account4. Then you take a break for lunch, and come back to edit from Accounts 5 through 8.
At the end of the day, you have brought 8 accounts up to 60 edits (12% of the minimum goal). And maybe one of them got blocked, too, which is lost effort. At this rate, it would take you an entire year of full-time work to get 100 EXTCONF accounts, even though you are operating multiple accounts concurrently. Doing 50 edits per day in 10 accounts is not faster than doing 500 edits in 1 account. It's the same amount of work. WhatamIdoing (talk) 05:13, 29 November 2024 (UTC)[reply]
Sure it’s an effort, though it doesn’t take a minute an edit. But I’m not sure why I need to imagine something that has happened multiple times already. Icewhiz most recently had like 4-5 EC accounts active, and there are probably several more. Yes, there is an effort there. But also yes, it keeps happening. nableezy - 15:00, 29 November 2024 (UTC)[reply]
Many of our frequent fliers are already adept at warehousing accounts for months or even years, so a bump in the time period probably won't make much off a difference. Additionally, and without going into detail publicly, there are several methods whereby semi- or even fully-automated editing can be used to get to 500 edits with a minimum of effort, or at least well within script-kid territory. Because so many of those are obvious on inspection some will assume that all of them are, but there are a number of rather subtle cases that have come up over the years and it would be foolish to assume that it isn't ongoing. 184.152.68.190 (talk) 17:31, 28 November 2024 (UTC)[reply]
Ban evading actors who employ deception via sockpuppetry in the WP:PIA topic area are here to improve Wikipedia, from their perspective, rather than damage it. There is no need to use faith. There are statistics. There is a probability that a 'new user' is employing ban evasion. Sean.hoyland (talk) 18:46, 22 November 2024 (UTC)[reply]
My initial comment wasn't a direct response to yours, but new users and IPs won't be able to edit in the WP:PIA topic area anyway since they need to be extended confirmed. Some1 (talk) 20:08, 22 November 2024 (UTC)[reply]
Let's not hold up the way PIA handles new users and IPs, in which they are allowed to post to talk pages but then have their talk page post removed if it doesn't fall within very specific parameters, as some sort of model. CMD (talk) 02:51, 23 November 2024 (UTC)[reply]
Strongly support automatically checkusering all active users (new and existing) at regular intervals. If it were automated -- e.g., a script runs that compares IPs, user agent, other typical subscriber info -- there would be no privacy violation, because that information doesn't have to be disclosed to any human beings. Only the "hits" can be forwarded to the CU team for follow-up. I'd run that script daily. If the policy forbids it, we should change the policy to allow it. It's mind-boggling that Wikipedia doesn't do this already. It's a basic security precaution. (Also, email-required registration and get rid of IP editing.) Levivich (talk) 02:39, 23 November 2024 (UTC)[reply]
I don't think you've been reading the comments from people who know what they are talking about. There would be hundreds, at least, of hits per day that would require human checking. The policy that prohibits this sort of massive breach of privacy is the Foundation's and so not one that en.wp could change even if it were a good idea (which it isn't). Thryduulf (talk) 03:10, 23 November 2024 (UTC)[reply]
A computer can be programmed to check for similarities or patterns in subscriber info (IP, etc), and in editing activity (time cards, etc), and content of edits and talk page posts (like the existing language similarity tool), with various degrees of certainty in the same way the Cluebot does with ORES when it's reverting vandalism. And the threshold can be set so it only forwards matches of a certain certainty to human CUs for review, so as not to overwhelm the humans. The WMF can make this happen with just $1 million of its $180 million per year (and it wouldn't be violating its own policies if it did so). Enwiki could ask for it, other projects might join too. Levivich (talk) 05:24, 23 November 2024 (UTC)[reply]
"Oh now I see what you mean, Levivich, good point, I guess you know what you're talking about, after all."
I seem to have missed this comment, sorry. However I am very sceptical that sockpuppet detection is meaningfully automatable. From what CUs say it is as much art as science (which is why SPI cases can result in determinations like "possilikely"). This is the sort of thing that is difficult (at best) to automate. Additionally the only way to reliably develop such automation would be for humans analyse and process a massive amount of data from accounts that both are and are not sockpuppets and classify results as one or the other, and that anaylsis would be a massive privacy violation on its own. Assuming you have developed this magic computer that can assign a likelihood of any editor being a sock of someone who has edited in the last three months (data older than that is deleted) on a percentage scale, you then have to decide what level is appropriate to send to humans to check. Say for the sake of argument it is 75%, that means roughly one in four people being accused are innocent and are having their privacy impinged unnecessarily - and how many CUs are needed to deal with this caseload? Do we have enough? SPI isn't exactly backlog free and there aren't hoards of people volunteering for the role (although unbreaking RFA might help with this in the medium to long term). The more you reduce the number sent to CUs to investigate, the less benefit there is over the status quo.
In addition to all the above, how similar is "similar" in terms of articles edited, writing style, timecard, etc? How are you avoiding legitimate sockpuppets? Thryduulf (talk) 18:44, 23 November 2024 (UTC)[reply]
You know this already but for anyone reading this who doesn't: when a CU "checks" somebody, it's not like they send a signal out to that person's computer to go sniffing around. In fact, all the subscriber info (IP address, etc.) is already logged on the WMF's server logs (as with any website). A CU "check" just means a volunteer CU gets to look at a portion of those logs (to look up a particular account's subscriber info). That's the privacy concern: we have rules, rightfully so, about when volunteer CUs (not WMF staff) can read the server logs (or portions of them). Those rules do not apply to WMF staff, like devs and maintenance personnel, nor do they apply to the WMF's own software reading its own logs. Privacy is only an issue when those logs are revealed to volunteer CUs.
So... feeding the logs into software in order to train the software doesn't violate anyone's policy. It's just letting a computer read its own files. Human verification of the training outcomes also doesn't have to violate anyone's privacy -- just don't use volunteer CUs to do it, use WMF staff. Or, anonymize the training data (changing usernames to "Example1", "Example2", etc.). Or use historical data -- which would certainly be part of the training, since the most effective way would be to put known socks into the training data to see if the computer catches them.
Anyway, training the system won't violate anyone's privacy.
As for the hit rate -- 75% would be way, way too low. We'd be looking for definitely over 90% or 95%, and probably more like 99.something percent. Cluebot doesn't get vandalism wrong 1 out of 4 times, neither should CluebotCU. Heck, if CluebotCU can't do better than 75%, it's not worth doing. A more interesting question is whether the 99.something% hit rate would be helpful to CUs, or whether that would only catch the socks that are so obvious you don't even need CU to recognize them. Only testing in the field would tell.
But overall, AI looking for patterns, and checking subscriber info, edit patterns, and the content of edits, would be very helpful in tamping down on socking, because the computer can make far more checks than a human (a computer can look at 1,000 accounts and a 100,000 edits no problem, which no human can do), it'll be less biased than humans, and it can do it all without violating anyone's privacy -- in fact, lowering the privacy violations by lowering the false positives, sending only high-probability (90%+, not 75%+) to humans for review. And it can all be done with existing technology, and the WMF has the money to do it. Levivich (talk) 19:38, 23 November 2024 (UTC)[reply]
The more you write the clearer you make it that you don't understand checkuser or the WMF's policies regarding privacy. It's also clear that I'm not going to convince you that this is unworkable so I'll stop trying. Thryduulf (talk) 20:42, 23 November 2024 (UTC)[reply]
If you are are unable to distinguish between reasoned disagreement and insults, then it's not at all weird that reasoned disagreement fails to convince you. Thryduulf (talk) 22:44, 23 November 2024 (UTC)[reply]
@Levivich: Whatever existing data set we have has too many biases to be useful for this, and this is going to be prone to false positives. AI needs lots of data to be meaningfully trained. Also, AI here would be learning a function; when the output is not in fact a function of the input, there's nothing for an AI model to target, and this is very much the case here. On Wikidata, where I am a CheckUser, almost all edit summaries are automated even for human edits (just like clicking the rollback button is, or undoing an edit is by default), and it is very hard to meaningfully tell whether someone is a sock or not without highly case-specific analysis. No AI model is better than the data it's trained on.
Also, about the privacy policy: you are completely incorrect when you "Those rules do not apply to WMF staff, like devs and maintenance personnel, nor do they apply to the WMF's own software reading its own logs". Staff can only access that information on a need to know basis, just like CheckUsers, and data privacy laws like the EU's and California's means you cannot just do whatever random thing you want with the information you collect from users about them.--Jasper Deng(talk)21:56, 23 November 2024 (UTC)[reply]
So which part of the wmf:Privacy Policy would prohibit the WMF from developing an AI that looks at server logs to find socks? Do you want me to quote to you the portions that explicitly disclose that the WMF uses personal information to develop tools and improve security? Levivich (talk) 22:02, 23 November 2024 (UTC)[reply]
@Levivich: Did you read the part where I mentioned privacy laws? Also, in this industry no one is allowed unfettered usage of private data even internally; there are internal policies that govern this that are broadly similar to the privacy policy. It's one thing to test a proposed tool on an IP address like Special:Contribs/2001:db8::/32, but it's another to train an AI model on it. Arguably an equally big privacy concern is the usage of new data from new users after the model is trained and brought online. The foundation is already hiding IP addresses by default even for anonymous users soon, and they will not undermine that mission through a tool like this. Ultimately, the Board of Trustees has to assume legal responsibility and liability for such a thing; put yourself in their position and think of whether they'd like the liability of something like this.--Jasper Deng(talk)22:13, 23 November 2024 (UTC)[reply]
So can you quote a part of the privacy policy, or a part of privacy laws, or anything, that would prohibit feeding server logs into a "Cluebot-CU" to find socking?
Because I can quote the part of the wmf:Privacy Policy that allows it, and it's a lot:
We may use your public contributions, either aggregated with the public contributions of others or individually, to create new features or data-related products for you or to learn more about how the Wikimedia Sites are used ...
Because of how browsers work, we receive some information automatically when you visit the Wikimedia Sites ... This information includes the type of device you are using (possibly including unique device identification numbers, for some beta versions of our mobile applications), the type and version of your browser, your browser's language preference, the type and version of your device's operating system, in some cases the name of your internet service provider or mobile carrier, the website that referred you to the Wikimedia Sites, which pages you request and visit, and the date and time of each request you make to the Wikimedia Sites.
Put simply, we use this information to enhance your experience with Wikimedia Sites. For example, we use this information to administer the sites, provide greater security, and fight vandalism; optimize mobile applications, customize content and set language preferences, test features to see what works, and improve performance; understand how users interact with the Wikimedia Sites, track and study use of various features, gain understanding about the demographics of the different Wikimedia Sites, and analyze trends. ...
We actively collect some types of information with a variety of commonly-used technologies. These generally include tracking pixels, JavaScript, and a variety of "locally stored data" technologies, such as cookies and local storage. ... Depending on which technology we use, locally stored data may include text, Personal Information (like your IP address), and information about your use of the Wikimedia Sites (like your username or the time of your visit). ... We use this information to make your experience with the Wikimedia Sites safer and better, to gain a greater understanding of user preferences and their interaction with the Wikimedia Sites, and to generally improve our services. ...
We and our service providers use your information ... to create new features or data-related products for you or to learn more about how the Wikimedia Sites are used ... To fight spam, identity theft, malware and other kinds of abuse. ... To test features to see what works, understand how users interact with the Wikimedia Sites, track and study use of various features, gain understanding about the demographics of the different Wikimedia Sites and analyze trends. ...
When you visit any Wikimedia Site, we automatically receive the IP address of the device (or your proxy server) you are using to access the Internet, which could be used to infer your geographical location. ... We use this location information to make your experience with the Wikimedia Sites safer and better, to gain a greater understanding of user preferences and their interaction with the Wikimedia Sites, and to generally improve our services. For example, we use this information to provide greater security, optimize mobile applications, and learn how to expand and better support Wikimedia communities. ...
We, or particular users with certain administrative rights as described below, need to use and share your Personal Information if it is reasonably believed to be necessary to enforce or investigate potential violations of our Terms of Use, this Privacy Policy, or any Wikimedia Foundation or user community-based policies. ... We may also disclose your Personal Information if we reasonably believe it necessary to detect, prevent, or otherwise assess and address potential spam, malware, fraud, abuse, unlawful activity, and security or technical concerns. ... To facilitate their work, we give some developers limited access to systems that contain your Personal Information, but only as reasonably necessary for them to develop and contribute to the Wikimedia Sites. ...
Yeah that's a lot. Then there's this whole FAQ that says
It is important for us to be able to make sure everyone plays by the same rules, and sometimes that means we need to investigate and share specific users' information to ensure that they are.
For example, user information may be shared when a CheckUser is investigating abuse on a Project, such as suspected use of malicious "sockpuppets" (duplicate accounts), vandalism, harassment of other users, or disruptive behavior. If a user is found to be violating our Terms of Use or other relevant policy, the user's Personal Information may be released to a service provider, carrier, or other third-party entity, for example, to assist in the targeting of IP blocks or to launch a complaint to the relevant Internet Service Provider.
So using IP addresses, etc., to develop new tools, to test features, to fight violations of the Terms of Use, and disclosing that info to Checkusers... all explicitly permitted by the Privacy Policy. Levivich (talk) 22:22, 23 November 2024 (UTC)[reply]
@Levivich:"We, or particular users with certain administrative rights as described below, need to use and share your Personal Information if it is reasonably believed to be necessary to enforce or investigate potential violations of our Terms of Use" – "reasonably believed to be necessary" is not going to hold up in court when it's sweepingly applied to everyone. This doesn't even take into consideration the laws I mentioned, like GDPR. I'm not a lawyer, and I'm guessing neither are you. If you want to be the one assuming the legal liability for this, contact the board today and sign the contract. Even then they would probably not agree to such an arrangement. So you're preaching to the choir: only the foundation could even consider assuming this risk. Also, it's clear that you do not have a single idea of how developing something like this works if you think it can be done for $1 million. Something this complex has to be done right and tech salaries and computing resources are expensive.--Jasper Deng(talk)22:28, 23 November 2024 (UTC)[reply]
What I am suggesting does not involve sharing everyone's data with Checkusers. It's pretty obvious that looking at their own server logs is "necessary to enforce or investigate potential violations of our Terms of Use". Five people is how big the WMF's wmf:Machine Learning team is, @ $200k each, $1m/year covers it. Five people is enough for that team to improve ORES, so another five-person team dedicated to "ORES-CU" seems a reasonable place to start. They could double that, and still have like $180M left over. Levivich (talk) 22:40, 23 November 2024 (UTC)[reply]
@Levivich: Yeah no, lol. $200k each is not a very competitive total compensation, considering that that needs to include benefits, health insurance, etc. This doesn't include their manager or the hefty hardware required to run ML workflows. It doesn't include the legal support required given the data privacy law compliance needed. Capriciously looking at the logs does not count; accessing data of users the foundation cannot reasonably have said to be likely to cause abuse is not permissible. This all aside from the bias and other data quality issues at hand here. You can delude yourself all you want, but nature cannot be fooled. I'm finished arguing with you anyways, because this proposal is either way dead on arrival.--Jasper Deng(talk)23:45, 23 November 2024 (UTC)[reply]
As a statistician/data scientist, @Levivich is correct about the technical side of this—building an ML algorithm to detect sockpuppets would be pretty easy. Duplicate user algorithms like these are common across many websites. For a basic classification task like this (basically an ML 101 homework problem), I think $1 million is about right. As a bonus, the same tools could be used to identify and correct for possible canvasing or brigading, which behaves a lot like sockpuppetry from a statistical perspective. A similar algorithm is already used by Twitter's community notes feature.
IANAL, so I can't comment on the legal side of this, and I can't comment on whether that money would be better-spent elsewhere since I don't know what the WMF budget looks like. Overall though, the technical implementation wouldn't be a major hurdle. – Closed Limelike Curves (talk) 20:44, 24 November 2024 (UTC)[reply]
Building such a model is only a small part of a real production system. If this system is to operate on all account creations, it needs to be at least as reliable as the existing systems that handle account creations. As you probably know, data scientists developing such a model need to be supported by software engineers and site reliability engineers supporting the actual system. Then you have the problem of new sockers who are not on the list of sockmasters to check against. Non-English-language speakers often would be put at a disadvantage too. It's not as trivial as you make it out to be, thus I stand by my estimate.--Jasper Deng(talk)06:59, 25 November 2024 (UTC)[reply]
I don't think we need to spend more time speculating about a system that WMF Legal is extremely unlikely to accept. Even if they did, it wouldn't exist until several years from now. Instead, let's try to think of things that we can do ourselves, or with only a very little assistance. Small, lightweight projects with full community control can help us now, and if we prove that ____ works, the WMF might be willing to adopt and expand it later. WhatamIdoing (talk) 23:39, 25 November 2024 (UTC)[reply]
That's a mistake -- doing the same thing Wikipedia has been doing for 20+ years. The mistake is in leaving it to volunteers to catch sockpuppetry, rather than insisting that the WMF devote significant resources to it. And it's a mistake because the one thing we volunteers can't do, that the WMF can do, is comb through the server logs looking for patterns. Levivich (talk) 23:44, 25 November 2024 (UTC)[reply]
Not sure about the "building an ML algorithm to detect sockpuppets would be pretty easy" part, but I admire the optimism. It is certainly the case that it is possible, and people have done it with a surprising level of success a very long time ago in ML terms e.g. https://doi.org/10.1016/j.knosys.2018.03.002. These projects tend to rely on the category graph to distinguish sock and non-sock sets for training, the categorization of accounts as confirmed or suspected socks. However, the category graph is woefully incomplete i.e. there is information in the logs that is not reflected in the graph, so ensuring that all ban evasion accounts are properly categorized as such might help a bit. Sean.hoyland (talk) 03:58, 26 November 2024 (UTC)[reply]
Thankfully, we wouldn't have to build an ML algorithm, we can just use one of the existing ones. Some are even open source. Or WMF could use a third party service like the aforementioned sift.com. Levivich (talk) 16:17, 26 November 2024 (UTC)[reply]
Let me guess: Essentially, you would like their machine-learning team to use Sift's AI-Powered Fraud Protection, which from what I can glance, handles safeguarding subscriptions to defending digital content and in-app purchases and helps businesses reduce friction and stop sophisticated fraud attacks that gut growth, to provide the ability for us to automatically checkuser all active users? 2601AC47 (talk·contribs·my rights) Isn't a IP anon16:25, 26 November 2024 (UTC)[reply]
The WMF already has the ability to "automatically checkuser all users" (the verb "checkuser" just means "look at the server logs"), I'm suggesting they use it. And that they use it in a sophisticated way, employing (existing, open source or commercially available) AI/ML technologies, like the same kind we already use to automatically revert vandalism. Contrary to claims here, doing so would not be illegal or even expensive (comparatively, for the WMF). Levivich (talk) 16:40, 26 November 2024 (UTC)[reply]
So, in my attempt to get things set right and steer towards a consensus that is satisfactory, I sincerely follow-up: What lies beyond that in this vast, uncharted sea? And could this mean any more in the next 5 years? 2601AC47 (talk·contribs·my rights) Isn't a IP anon16:49, 26 November 2024 (UTC)[reply]
So, @2601AC47, I think the answer to your question is "tell the WMF we really, really, really would like more attention to sockpuppetry and IP abuse from the ML team". -- asilvering (talk) 17:31, 26 November 2024 (UTC)[reply]
3 days! When I first posted my comment and some editors responded that I didn't know what I was talking about, it can't be done, it'd violate the privacy policy and privacy laws, WMF Legal would never allow it... I was wondering how long it would take before somebody pointed out that this thing that can't be done has already been done and has been under development for at least 7 years now.
Of course it's already under development, it's pretty obvious that the same Wikipedia that developed ClueBot, one of the world's earlier and more successful examples of ML applications, would try to employ ML to fight multiple-account abuse. I mean, I'm obviously not gonna be the first person to think of this "innovation"!
Unlike what is being proposed, SimilarEditors only works based on publicly available data (e.g. similarities in editing patterns), and not IP data. To quote the page Sean linked, in the model's current form, we are only considering public data, but most saliently private data such as IP addresses or user-agent information are features currently used by checkusers that could be later (carefully) incorporated into the models.So, not only the current model doesn't look at IP data, the research project also acknowledges that actually using such data should only be done in a "careful" way, because of those very same privacy policy issues quoted above.On the ML side, however, this does proves that it's being worked on, and I'm honestly not surprised at all that the WMF is working on machine learning-based tools to detect sockpuppets. Chaotic Enby (talk · contribs) 17:50, 26 November 2024 (UTC)[reply]
Right. We should ask WMF to do the later (carefully) incorporated into the models part (especially since it's now later). BTW, the SimilarUsers API already pulls IP and other metadata. SimilarExtensions (a tool that uses the API) doesn't release that information to CheckUsers, by design. And that's a good thing, we can't just release all IPs to CheckUsers, it does indeed have to be done carefully. But user metadata can be used. What I'm suggesting is that the WMF should proceed to develop these types of tools (including the careful use of user metadata). Levivich (talk) 17:57, 26 November 2024 (UTC)[reply]
Not really clear that they're pulling IP data from logged-in users. The relevant sections reads:
USER_METADATA (203MB): for every user in COEDIT_DATA, this contains basic metadata about them (total number of edits in data, total number of pages edited, user or IP, timestamp range of edits).
In a few years people might look back on these days when we only had to deal with simple devious primates employing deception as the halcyon days. Sean.hoyland (talk) 18:33, 26 November 2024 (UTC)[reply]
This may be surprising, but it turns out there's more than one person on Wikipedia, and many of us have different opinions on things. You're probably thinking of @Guy Macon's essay.
I disagree with his argument that the WMF is incompetent, but at the same time, smart thinking happens on the margin. Just because the WMF spent their first $20 million extremely well (on creating Wikipedia) doesn't mean giving them $200 million would make them 10× as good. Nobody here thinks the WMF budget should be cut to $0; there's just some of us who think it needs a haircut.
For me it comes down to, "if you don't donate to the WMF, what does that money go instead"? I'd rather you give that money to some other charity—feeding African children is more important than reskinning Wikipedia—but if you won't, I'd doubt giving it to the WMF is worse than whatever else you were going to spend it on. Whether we should cut back on ads depends on whether this money is coming out of donors' charity budgets or their regular budgets. – Closed Limelike Curves (talk) 03:10, 29 November 2024 (UTC)[reply]
I already struggle enough with prioritizing charities and whether which ones are ethical or not and how I should be spending every single penny I get on charities dealing with PIA and trans issues because those are the most oppressed groups in the world right now. The WMF is not helping people who are actively getting killed and having their rights taken away therefore they are not important. 2600:1700:69F1:1410:C812:78B7:C08A:5AA5 (talk) 03:15, 29 November 2024 (UTC)[reply]
So goes this whole discussion; but to give a slightly longer answer to the IP: We’re not telling them to get lost on a different path, we’re trying (despite everything) to establish relations, consensus and mutual trust. And hopefully long-term progress on key areas of contention. We don’t hate them, or else they’ll dismiss us completely. 2601AC47 (talk·contribs·my rights) Isn't a IP anon03:44, 29 November 2024 (UTC)[reply]
Any such system would be subject to numerous biases or be easily defeatable. Such an automated anti-abuse system would have to be exclusively a foundation initiative as only they have the resources for such a monumental undertaking. It would need its own team of developers.--Jasper Deng(talk)18:57, 23 November 2024 (UTC)[reply]
Absolutely no chance that this would pass. WP:SNOW, even though there isn't a flood of opposes. There are two problems:
The existing CheckUser team barely has the bandwidth for the existing SPI load. Doing this on every single new user would be impractical and would enable WP:LTA's by diverting valuable CheckUser bandwidth.
Even if we had enough CheckUser's, this would be a severe privacy violation absolutely prohibited under the Foundation privacy policy.
It is perhaps an interesting conversation to have but I have to agree that it is unworkable, and directly contrary to foundation-level policy which we cannot make a local exemption to. En.wp, I believe, already has the largest CU team of any WMF project, but we would need hundreds more people on that team to handle something like this. In the last round of appointments, the committee approved exactly one checkuser, and that one was a returning former mamber of the team. And there is the very real risk that if we appointed a whole bunch of new CUs, some of them would abuse the tool. Just Step Sidewaysfrom this world ..... today18:55, 23 November 2024 (UTC)[reply]
And its worth pointing out that the Committee approving too few volunteers for Checkuser (regardless of whether you think they are or aren't) is not a significant part of this issue. There simply are not tens of people who are putting themselves forward for consideration as CUs. Since 2016 54 applications (an average of per year) have been put forward for consideration by Functionaries (the highest was 9, the lowest was 2). Note this is total applications not applicants (more than one person has applied multiple times), and is not limited to candidates who had a realistic chance of being appointed. Thryduulf (talk) 20:40, 23 November 2024 (UTC)[reply]
Generally, I tend to get the impression from those who have checkuser rights that CU should be done as a last resort, and other, less invasive methods are preferred, and it would seem that indiscriminate use of it would be a bad idea, so I would have some major misgivings about this proposal. And given the ANI case, the less user information that we retain, the better (which is also probably why temporary accounts are a necessary and prudent idea despite other potential drawbacks). Abzeronow (talk) 03:56, 23 November 2024 (UTC)[reply]
Oppose. A lot has already been written on the unsustainable workload for the CU team this would create and the amount of collateral damage; I'll add in the fact that our most notorious sockmasters in areas like PIA already use highly sophisticated methods to evade CU detection, and based on what I've seen at the relevant SPIs most of the blocks in these cases are made with more weight given to the behaviour, and even then only after lengthy deliberations on the matter. These sort of sockmasters seem to have been in the OP's mind when the request was made, and I do not see automated CU being of any more use than current techniques against such dedicated sockmasters. And, has been mentioned before, most cases of sockpuppetry (such as run-of-the-mill vandals and trolls using throwaway accounts for abuse) don't need CU anyways. JavaHurricane08:17, 24 November 2024 (UTC)[reply]
These are, unfortunately, fair points about the limits of CU and the many experienced and dedicated ban evading actors in PIA. CU information retention policy is also a complicating factor. Sean.hoyland (talk) 08:28, 24 November 2024 (UTC)[reply]
As I said in my original post, recidivist socks often get better at covering their "tells" each time making behavioural detection increasingly difficult and meaning the entire burden falls on the honest user to convince an Admin to take an SPI case seriously with scarce evidence. After many years I'm tired of defending various pages from sock POV edits and if WMF won't make life easier then increasingly I just won't bother, I'm sure plenty of other users feel the same way. Mztourist (talk) 05:45, 26 November 2024 (UTC)[reply]
Honestly, the main function of that sort of thing seems to be compiling data that is already available on XTools and various editor interaction analyzers, and then presenting it nicely and neatly. I think that such a page could be useful as a sanity check, and it might even be worth having that sort of thing as a standalone toolforge app, but I don't really see why the WMF would make that particular extension a high priority. — Red-tailed hawk(nest)17:58, 26 November 2024 (UTC)[reply]
Well, it doesn't have to be that particular extension, but it seems to me that the entire "idea" has been stalled, unless they're working on another tool that I'm unaware of (very possible). (Or, it could be because of recent changes in domestic and int'l privacy laws that derailed their previous development advances, or it could be because of advancements in ML elsewhere making in-house development no longer practical.)
As to why the WMF would make this sort of problem a high priority, I'd say because the spread of misinformation on Wikipedia by sockpuppets is a big problem. Even without getting into the use of user metadata, just look at recent SPIs I filed, like Wikipedia:Sockpuppet investigations/Icewhiz/Archive#27 August 2024 and Wikipedia:Sockpuppet investigations/Icewhiz/Archive#09 October 2024. That involved no private data at all, but a computer could have done automatically, in seconds, what took me hours to do manually, and those socks could have been uncovered before they made thousands and thousands of edits spreading misinformation. If the computer looked at private data as well as public data, it would be even more effective (and would save CUs time as well). Seems to me to be a worthy expenditure of 0.5% or 1% of the WMF's annual budget. Levivich (talk) 18:09, 26 November 2024 (UTC)[reply]
This looks really interesting. I don't really know how extensions are rolled out to individual wikis - can anyone with knowledge about that summarise if having this tool turned on (for check users/relevant admins) for en.wp is feasible? Do we need a RFC, or is this a "maybe wait several years for a phab ticket" situation? BugGhost🦗👻18:09, 26 November 2024 (UTC)[reply]
I find it amusing that ~4 separate users above are arguing that automatic identification of sockpuppets is impossible, impractical, and the WMF would never do it—and meanwhile, the WMF is already doing it. – Closed Limelike Curves (talk) 19:29, 27 November 2024 (UTC)[reply]
I think what's happening is that people are having two simultaneous discussions – automatic identification of sockpuppets is already being done, but what people say "the WMF would never do" is using private data (e.g. IP addresses) to identify them. Which adds another level of (ethical, if not legal) complications compared to what SimilarEditors is doing (only processing data everyone can access, but in an automated way). Chaotic Enby (talk · contribs) 07:59, 28 November 2024 (UTC)[reply]
"automatic identification of sockpuppets is already being done" is probably an overstatement, but I agree that there may be a potential legal and ethical minefield between the Similarusers service that uses public information available to anyone from the databases after redaction of private information (i.e. course-grained sampling of revision timestamps combined with an attempt to quantify page intersection data), and a service that has access to the private information associated with a registered account name. Sean.hoyland (talk) 11:15, 28 November 2024 (UTC)[reply]
Yes, automatic identification of (these) sockpuppets is impossible. There are many reasons for this, but the simplest one is this: These types of tools require hundreds of edits – at minimum – to return any viable data, and the sort of sockmasters who get accounts up to that volume of edits know how to evade detection by tools that analyse public information. The markers would likely indicate people from similar countries – naturally, two Cypriots would be interested in Category:Cyprus and over time similar hour and day overlaps will emerge, but what's to let you know whether these are actual socks when they're evading technical analysis? You're back to square one. There are other tools such as mediawikiwiki:User:Ladsgroup/masz which I consider equally circumstantial; an analysis of myself returns a high likelihood of me being other administrators and arbitrators, while analysing an alleged sock currently at SPI returns the filer as the third most likely sockmaster. This is not commentary on the tools themselves, but rather simply the way things are. DatGuyTalkContribs17:42, 28 November 2024 (UTC)[reply]
Idk, the half dozen ARBPIA socks I recently reported at SPI were obvious af to me, as are several others I haven't reported yet. That may be because that particular sockfarm is easy to spot by its POV pushing and a few other habits; though I bet in other topic areas it's the same. WP:ARBECR helps because it forces the socks to make 500 edits minimum before they can start POV pushing, but still we have to let them edit for a while post-XC just to generate enough diffs to support an SPI filing. Software that combines tools like Masz and SimilarEditor, and does other kinds of similar analysis, could significantly reduce the amount of editor time required to identify and report them. Levivich (talk) 18:02, 28 November 2024 (UTC)[reply]
I think it is possible, studies have demonstrated that it is possible, but it is true that having a sufficient number of samples is critical. Samples can be aggregated in some cases. There are several other important factors too. I have tried some techniques, and sometimes they work, or let's say they can sometimes produce results consistent with SPI results, better than random, but with plenty of false positives. It is also true that there are a number of detection countermeasures (that I won't describe) that are already employed by some bad actors that make detection harder. But I think the objective should be modest, to just move a bit in the right direction by detecting more ban evading accounts than are currently detected, or at least to find ways to reduce the size of the search space by providing ban evasion candidates. Taking the human out of the detection loop might take a while. Sean.hoyland (talk) 18:39, 28 November 2024 (UTC)[reply]
If you mean it's never going to be possible to catch some sockpuppets—the best-hidden, cleverest, etc. ones—you're completely correct. But I'm guessing we could cut the amount of time SPI has to spend dramatically with just some basic checks. – Closed Limelike Curves (talk) 02:27, 29 November 2024 (UTC)[reply]
I disagree. Empirically, the vast majority of time spent at SPI is not on finding possible socks, nor is it using the CheckUser tool on them, but rather it's the CU completed cases (of which there are currently 14 and I should probably stop slacking and get onto some) with non-definitive technical results waiting on an administrator to make the final determination on whether they're socks or not. Extension:SimilarUsers would concentrate various information that already exists (EIA, RoySmith's SPI tools) in one place, but I wouldn't say the accessibility of these tools is a cause of SPI backlog. An AI analysis tool to give an accurate magic number for likelihood? I'm anything but a Luddite, but still believe that's wishful thinking. DatGuyTalkContribs03:02, 29 November 2024 (UTC)[reply]
Something seems better than nothing in this context doesn't it? EIA and the Similarusers service don't provide an estimate of the significance of page intersections. An intersection on a page with few revisions or few unique actors or few pageviews etc. is very different from a page intersection on the Donald Trump page. That kind of information is probably something that could sometimes help, even just to evaluate the importance of intersection evidence presented at SPIs. It seems to me that any kind of assistance could help. And another thing about the number of edits is that too many samples can also present challenges related to noise, with signals getting smeared out, although the type of noise in a user's data can itself be a characteristic signal in some cases it seems. And if there are too few samples, you can generate synthetic samples based on the actual samples and inject them into spaces. Search strategy matters a lot. The space of everyone vs everyone is vast, so good luck finding potential matches in that space without a lot of compute, especially for diffs. But many socks inhabit relatively small subspaces of Wikipedia, at least in the 20%-ish of time (on average in PIA) they edit(war)/POV-push etc. in their topic of interest. So, choosing the candidate search space and search strategy wisely can make the problem much more tractable for a given topic area/subspace. Targeted fishing by picking a potential sock and looking for potential matches (the strategy used by the Similarusers service and CU I guess) is obviously a very different challenge than large-scale industrial fishing for socks in general. Sean.hoyland (talk) 04:08, 29 November 2024 (UTC)[reply]
And to continue the whining about existing tools, EIA and the Similarusers service use a suboptimal strategy in my view. If the objective is page intersection information for a potential sock against a sockmaster, and a ban evasion source has employed n identified actors so far e.g. almost 50 accounts for Icewhiz, the source's revision data should be aggregated for the intersection. This is not difficult to do using the category graph and the logs. Sean.hoyland (talk) 04:25, 29 November 2024 (UTC)[reply]
There is so much more that could be done with the software. EIA gives you page overlaps (and isn't 100% accurate at it), but it doesn't tell you:
how many times the accounts made the same edits (tag team edit warring)
how many times they voted in the same formal discussions (RfC, AfD, RM, etc) and whether they voted the same way or different (vote stacking)
how many times they use the same language and whether they use unique phraseology
whether they edit at the same times of day
whether they edit on the same days
whether account creation dates (or start-of-regular-editing dates) line up with when other socks were blocked
whether they changed focus after reaching XC and to what extent (useful in any ARBECR area)
whether they "gamed" or "rushed" to XC (same)
All of this (and more) would be useful to see in a combined way, like a dashboard. It might make sense to restrict access to such compilations of data to CUs, and the software could also throw in metadata or subscriber info in there, too (or not), and it doesn't have to reduce it all into a single score like ORES, but just having this info compiled in one place would save editors the time of having to compile it manually. If the software auto-swept logs for this info and alerted humans to any "high scores" (however defined, eg "matches across multiple criteria"), it would probably not only reduce editor time but also increase sock discovery. Levivich (talk) 04:53, 29 November 2024 (UTC)[reply]
This is like one of my favorite strategies for meetings. Propose multiple things, many of which are technically challenging, then just walk out of the meeting.
The 'how many times the accounts made the same edits' is probably do-able because you can connect reverted revisions to the revisions that reverted them using json data in the database populated as part of the tagging system, look at the target state reverted to and whether the revision was an exact revert. ...or maybe not without computing diffs, having just looked at an article with a history of edit warring. Sean.hoyland (talk) 07:43, 29 November 2024 (UTC)[reply]
I agree with Levivich that automated, privacy-protecting sock-detection is not a pipe dream. I proposed a system something like this in 2018, see also here, and more recently here. However, it definitely requires a bit of software development and testing. It also requires the community and the foundation devs or product folks to prioritize the idea. Andre🚐02:27, 10 December 2024 (UTC)[reply]
Comment. For some time I have vehemnently suspected that this site is crawling with massive numbers of sockpuppets, that the community seems to be unable or unwilling to recognise probable sockpuppets for what they are, and it is not feasible to send them to SPI one at a time. I see a large number of accounts that are sleepers, or that have low edit counts, trying to do things that are controversial or otherwise suspicious. I see them showing up at discussions in large numbers and in quick succession, and offering !votes consist of interpretations of our policies and guidelines that may not reflect consensus, or other statements that may not be factually accurate.
I think the solution is simple: when closing community discussions, admins should look at the edit count of each !voter when determining how much weight to give his !vote. The lower the edit count, the greater the level of sleeper behaviour, and the more controversial the subject of the discussion is amongst the community, the less weight should be given to !vote.
For example, if an account with less than one thousand edits !votes in a discussion about 16th century Tibetan manuscripts, we may well be able to trust that !vote, because the community does not care about such manuscripts. But if the same account !votes on anything connected with "databases" or "lugstubs", we should probably give that !vote very little weight, because that was the subject of a massive dispute amongst the community, and any discussion on that subject is not particulary unlikely to be crawling with socks on both sides. The feeling is that, if you want to be taken seriously in such a controversial discussion, you need to make enough edits to prove that you are a real person, and not a sock. James500 (talk) 15:22, 12 December 2024 (UTC)[reply]
The site presumably has a large number of unidentified sockpuppets. As for the identified ban evading accounts, accounts categorized or logged as socks, if you look at 2 million randomly selected articles for the 2023-10-07 to 2024-10-06 year, just under 2% of the revisions are by ban evading actors blocked for sockpuppetry (211,546 revisions out of 10,732,361). A problem with making weight dependent on edit count is that the edit count number does not tell you anything about the probability that an account is a sock. Some people use hundreds of disposable accounts, making just a few edits with each account. Others stick around and make thousands of edits before they are detected. Also, Wikipedia provides plenty of tools that people can use to rapidly increase their edit count. Sean.hoyland (talk) 16:12, 12 December 2024 (UTC)[reply]
I strongly oppose any idea of mass-CUing any group of users, and I'm pretty sure the WMF does too. This isn't the right way to fight sockpuppets. QuicoleJR (talk) 14:35, 15 December 2024 (UTC)[reply]
Can I ask why? Is it a privacy-based concern? IPs are automatically collected and stored for 90 days, and maybe for years in the backups, regardless of CUs. That's a 90 day window that a machine could use to do something with them without anyone running a CU and without anyone having to see what the machine sees. Sean.hoyland (talk) 15:05, 15 December 2024 (UTC)[reply]
Primarily privacy concerns, as well as concerns about false positives. A lot of people here probably share an IP with other editors without even knowing it. I also would like to maintain my personal privacy, and I know many other editors would too. There are other methods of fighting sockpuppets that don't have as much collateral damage, and we should pursue those instead. QuicoleJR (talk) 15:16, 17 December 2024 (UTC)[reply]
Also, it wouldn't even work on some sockpuppets, because IP info is only retained for 90 days, so a blocked editor could just wait out the 90 days and then return with a new account. QuicoleJR (talk) 15:19, 17 December 2024 (UTC)[reply]
@Levivich—one situation where I think we could pull a lot of data, and probably detect tons of sockpuppets, is !votes like RfAs and RfCs. Those have a lot of data, in addition to a very strong incentive for socking—you'd expect to see a bimodal distribution where most accounts have moderately-correlated views, but a handful have extremely strong-correlations (always !voting the same way), more than could plausibly happen by chance or by overlapping views. For accounts in the latter group, we'd have strong grounds to suspect collusion/canvassing or socking.
RfAs are already in a very nice machine-readable format. RfCs aren't, but most could easily be made machine-readable (by adopting a few standardized templates). We could also build a tool for semi-automated recoding of old RfCs to get more data. – Closed Limelike Curves (talk) 18:56, 16 December 2024 (UTC)[reply]
Would that data help with the general problem? If there are a lot of socks on an RfA, I'd expect that to be picked up by editors. Those are very well-attended. The same may apply to many RfCs. Perhaps the less well-attended ones might be affected, but the main challenge is article edits, which will not be similarly structured. CMD (talk) 19:13, 16 December 2024 (UTC)[reply]
Would that data help with the general problem? If there are a lot of socks on an RfA, I'd expect that to be picked up by editors.
Given we've had situations of sockpuppets being made admins themselves, I'm not too sure of this myself. If someone did create a bunch of socks, as some people have alleged in this thread, it'd be weird of them not to use those socks to influence policy decisions. I'm pretty skeptical, but I do think investigating would be a good idea (if nothing else because of how important it is—even the possibility of substantial RfA/RfC manipulation is quite bad, because it undermines the whole idea of consensus). – Closed Limelike Curves (talk) 21:04, 16 December 2024 (UTC)[reply]
I think we've put the cart before the horse here a bit. While we've established it's possible to detect most sockpuppets automatically—and the WMF is already working on it—it's not clear what this would actually achieve, because having multiple accounts isn't against the rules. I think we'd need to establish a set of easy-to-enforce boundaries for people using multiple accounts. My proposal is to keep it simple—two accounts controlled by the same person can't edit the same page (or participate in the same discussion) without disclosing they're the same editor.– Closed Limelike Curves (talk) 04:41, 14 December 2024 (UTC)[reply]
And as there are multiple legitimate ways to disclose, not all of which are machine readable, any automatically generated list is going to need human review. Thryduulf (talk) 10:13, 14 December 2024 (UTC)[reply]
Yes, that's definitely the case, an automatic sock detection should probably never be an autoblock, or at least not unless there is a good reason in that specific circumstance, like a well-trained filter for a specific LTA. Having the output of automatic sock detection should still be restricted to CU/OS or another limited user group who can be trusted to treat possible user-privacy-related issues with discretion, and have gone through the appropriate legal rigmarole. There could also be some false positives or unusual situations when piloting a program like this. For example, I've seen dynamic IPs get assigned to someone else after a while, which is unlikely but not impossible depending on how an ISP implements DHCP, though I guess collisions become less common with IPV6. Or if the fingerprinting is implemented with a lot of datapoints to reduce the likelihood of false positives. Andre🚐10:31, 14 December 2024 (UTC)[reply]
I think we are probably years away from being able to rely on autonomous agents to detect and block socks without a human in the loop. For now, people need as much help as they can get to identify ban evasion candidates. Sean.hoyland (talk) 10:51, 14 December 2024 (UTC)[reply]
or at least not unless there is a good reason in that specific circumstance,
Yep, basically I'm saying we need to define "good reason". The obvious situation is automatically blocking socks of blocked accounts. I also think we should just automatically prevent detected socks from editing the same page (ideally make it impossible, to keep it from being done accidentally). – Closed Limelike Curves (talk) 17:29, 14 December 2024 (UTC)[reply]
Requiring registration for editing
Note: This section was split off from "CheckUser for all new users" (permalink) and the "parenthetical comment" referred to below is: (Also, email-required registration and get rid of IP editing.)—03:49, 26 November 2024 (UTC)
@Levivich, about your parenthetical comment on requiring registration:
Part of the eternally unsolvable problem is that new editors are frankly bad at it. I can give examples from my own editing: Create an article citing a personal blog post as the main source? Check. Merge two articles that were actually different subjects? Been there, done that, got the revert. Misunderstand and mangle wikitext? More times than I can count. And that's after I created my account. Like about half of experienced editors, I edited as an IP first, fixing a typo here or reverting some vandalism there.
But if we don't persist through these early problems, we don't get experienced editors. And if we don't get experienced editors, Wikipedia will die.
Requiring registration ("get rid of IP editing") shrinks the number of people who edit. The Portuguese Wikipedia banned IPs only from the mainspace three years ago. Have a look at the trend. After the ban went into effect, they had 10K or 11K registered editors each month. It's since dropped to 8K. The number of contributions has dropped, too. They went from 160K to 210K edits per month down to 140K most months.
Some of the experienced editors have said that they like this. No IPs means less impulsive vandalism, and the talk pages are stable if you want to talk to the editor. Fewer newbies means I don't "have to" clean up after so many mistake-makers! Fewer editors, and especially fewer inexperienced editors, is more convenient – in the short term. But I wonder whether they're going to feel the same way a decade from now, when their community keeps shrinking, and they start wondering when they will lose critical mass.
The same thing happens in the real world, by the way. Businesses want to hire someone with experience. They don't want to train the helpless newbie. And then after years of everybody deciding that training entry-level workers is Somebody else's problem, they all look around and say: Where are all the workers that I need? Why didn't someone else train the next generation while I was busy taking the easy path?
In case you're curious, there is a Wikipedia that puts all of the IP and newbie edits under "PC" type restrictions. Nobody can see the edits until they've been approved by an experienced editor. The rate of vandalism visible to ordinary readers is low. Experienced editors love the level of control they have. Have a look at what's happened to the size of their community during the last decade. Is that what you want to see here? If so, we know how to make that happen. The path to that destination even looks broad, easy, and paved with all kinds of good intentions. WhatamIdoing (talk) 04:32, 23 November 2024 (UTC)[reply]
Well, I can tell you objectively that the number of edits declined, but "quality" is in the eye of the beholder. I understand that the latter community has the lowest use of inline citations of any mid-size or larger Wikipedia. What's now yesterday's TFA there wouldn't even be rated B-class here due to whole sections not having any ref tags. In terms of citation density, their FA standard is currently where ours was >15 years ago.
But I think you have missed the point. Even if the quality has gone up according to the measure of your choice, if the number of contributors is steadily trending in the direction of zero, what will the quality be when something close to zero is reached? That community has almost halved in the last decade. How many articles are out of date, or missing, because there simply aren't enough people to write them? A decade from now, with half as many editors again, how much worse will the articles be? We're none of us idiots here. We can see the trend. We know that people die. You have doubtless seen this famous line:
All men are mortal. Socrates is a man. Therefore, Socrates is mortal.
I say:
All Wikipedia editors are mortal. Dead editors do not maintain or improve Wikipedia articles. Therefore, maintaining and improving Wikipedia requires editors who are not dead.
Trends don't last forever. Enwiki's active user count decreased from its peak over a few years, then flattened out for over a decade. The quality increased over that period of time (by any measure). Just because these other projects have shed users doesn't mean they're doomed to have zero users at some point in the future. And I think there's too many variables to know how much any particular change made on a project affects its overall user count, nevermind the quality of its output. Levivich (talk) 06:28, 23 November 2024 (UTC)[reply]
If the graph to the right accurately reflects the age distribution of Wikipedia users, then a large chunk of the user base will die off within the next decade or two. Not to be dramatic, but I agree that requiring registration to edit, which will discourage readers from editing in the first place, will hasten the project's decline.... Some1 (talk) 14:40, 23 November 2024 (UTC)[reply]
There are significantly more barriers to entry than there were 20 years ago, and over that time the age profile has increased (quite significantly iirc). Adding more barriers to entry is not the way to solve the issued caused by barriers to entry. Thryduulf (talk) 15:50, 23 November 2024 (UTC)[reply]
Or you could say it's about a user called PaperQA2 that writes Wikipedia articles significantly more accurate than articles written by other users. Sean.hoyland (talk) 16:55, 23 November 2024 (UTC)[reply]
No, it is very clearly about a language model. As far as I know, PaperQA2, or WikiCrow (the generative model using PaperQA2 for question answering), has not actually been making any edits on Wikipedia itself. Chaotic Enby (talk · contribs) 16:58, 23 November 2024 (UTC)[reply]
That is true. It is not making any edits on Wikipedia itself. There is a barrier. But my point is that in the future that barrier may not be there. There may be users like PaperQA2 writing articles better than other users and the demographics will have changed to include new kinds of users, much younger than us. Sean.hoyland (talk) 17:33, 23 November 2024 (UTC)[reply]
In re "What do you suppose that chart looked like 20 years ago": I believe that the numbers, very roughly, are that the community has gotten about 10 years older, on average, than it was 20 years ago. That is, we are bringing in some younger people, but not at a rate that would allow us to maintain the original age distribution. (Whether the original age distribution was a good thing is a separate consideration.) WhatamIdoing (talk) 06:06, 24 November 2024 (UTC)[reply]
I like looking at the en.wikipedia user retention graph hosted on Toolforge (for anyone who might go looking for it later, there's a link to it at Wikipedia:WikiProject Editor Retention § Resources). It shows histograms of how many editors have edited in each month, grouped by all the editors who started editing in the same month. The data is noisy, but it does seem to show an increase in editing tenure since 2020 (when the pursuit of a lot of solo hobbies picked up, of course). Prior to that, there does seem to be a bit of slow growth in tenure length since the lowest point around 2013. isaacl (talk) 17:18, 23 November 2024 (UTC)[reply]
I'd say that the story there is: Something amazing happened in 2006. Ours (since both of us registered our accounts that year) was the year from which people stuck around. I think that would be just about the time that the wall o' automated rejection really got going. There was some UPE-type commercial pressure, but it didn't feel unmanageable. It looks like an inflection point in retention. WhatamIdoing (talk) 06:12, 24 November 2024 (UTC)[reply]
I don't think something particularly amazing happened in 2006. I think the rapid growth in articles starting in 2004 attracted a large land rush of editors as Wikipedia became established as a top search result. The cohort of editors at that time had the opportunity to cover a lot of topics for the first time on Wikipedia, requiring a lot of co-ordination, which created bonds between editors. As topic coverage grew, there were fewer articles that could be more readily created by generalists, the land rush subsided, and there was less motivation for new editors to persist in editing. Boom-bust cycles are common for a lot of popular things, particularly in tech where newer, shinier things launch all the time. isaacl (talk) 19:07, 24 November 2024 (UTC)[reply]
Ah yes, that glorious time when we gained an article on every Pokemon character and, it seems, every actor who was ever credited in a porn movie. Unfortunately, many of the editors I bonded with then are no longer active. Some are dead, some finished school, some presumably burned out, at least one went into the ministry. Donald Albury23:49, 26 November 2024 (UTC)[reply]
Have a look at what happened to the size of their community.—I'm gonna be honest: eyeballing it, I don't actually see much (if any) difference with enwiki's activity. "Look at this graph" only convinces people when the dataset passes the interocular trauma test (e.g. the hockey stick).
On the other hand, if there's a dataset of "when did $LANGUAGEwiki adopt universal pending changes protections", we could settle this argument once and for all using a real statistical model that can deliver precise effect sizes on activity. Maybe then we can all finally drop the stick. – Closed Limelike Curves (talk) 18:08, 26 November 2024 (UTC)[reply]
This particular idea will not pass, but the binary developing in the discussion is depressing. A bargain where we allow IPs to edit (or unregistered users generally when IPs are masked), and therefore will sit on our hands when dealing with abuse and even harassment is a grim one. Any steps taken to curtail the second half of that bargain would make the first half stronger, and I am generally glad to see thoughts about it, even if they end up being impractical. CMD (talk) 02:13, 24 November 2024 (UTC)[reply]
I don't want us to sit on our hands when we see abuse and harassment. I think our toolset is about 20 years out of date, and I believe there are things we could do that will help (e.g., mw:Temporary accounts, cross-wiki checkuser tools for Stewards, detecting and responding to a little bit more information about devices/settings [perhaps, e.g., whether an edit is being made from a private/incognito window]). WhatamIdoing (talk) 06:39, 24 November 2024 (UTC)[reply]
Temporary accounts will help with the casual vandalism, but they’re not going to help with abuse and harassment. If it limits the ability to see ranges, it will make issues slightly worse. CMD (talk) 07:13, 24 November 2024 (UTC)[reply]
I'm not sure what the current story is there, but when I talked to the team last (i.e., in mid-2023), we were talking about the value of a tool that would do range-related work. For various reasons, this would probably be Toolforge instead of MediaWiki, and it would probably be restricted (e.g., to admins, or to a suitable group chosen by each community), but the goal was to make it require less manual work, particularly for cross-wiki abuse, and to be able to aggregate some information without requiring direct disclosure of some PII. WhatamIdoing (talk) 23:56, 25 November 2024 (UTC)[reply]
Oh look, misleading statistics! "The Portuguese Wikipedia banned IPs only from the mainspace three years ago. Have a look at the trend. After the ban went into effect, they had 10K or 11K registered editors each month. It's since dropped to 8K. " Of course you have a spike in new registrations soon after you stop allowing IP edits, and you can't sustain that spike. That is not evidence of anything. It would have been more honest and illustrative to show the graph before and after the policy change, not only afterwards, e.g. thus. Oh look, banning IP editing has resulted in on average some 50% more registered editors than before the ban. Number of active editors is up 50% as well[14]. The number of new pages has stayed the same[15]. Number of edits is down, yes, but how much of this is due to less vandalism / vandalism reverts? A lot apparently, as the count of user edits has stayed about the same[16]. Basically, from those statistics, used properly, it is impossible to detect any issues with the Portuguese Wikipedia due to the banning of IP editing. Fram (talk) 08:55, 26 November 2024 (UTC)[reply]
@Jo-Jo Eumerus:, the dashboard is here although it looks like they stopped reporting the data in late 2021. If you take "Number of reverts" as a proxy for vandalism, you can see that the block shifted the number of reverts from a higher equilibrium to a lower one, while overall non-reverted edits does not seem to have changed significantly during that period. CMD (talk) 11:44, 28 November 2024 (UTC)[reply]
I agree that one should expect a spike in registration. (In fact, I have suggested a strictly temporary requirement to register – a few hours, even – to push some of our regular IPs into creating accounts.) But once you look past that initial spike, the trend is downward. WhatamIdoing (talk) 05:32, 29 November 2024 (UTC)[reply]
But once you look past that initial spike, the trend is downward.
I still don't see any evidence that this downward trend is unusual. Apparently the WMF did an analysis of ptwiki and didn't find evidence of a drop in activity. Net edits (non-revert edits standing for at least 48 hours) increased by 5.7%, although edits across other wikis increased slightly more. The impression I get is any effects are small either way—the gains from freeing up anti-vandalism resources basically offset the cost of some IP editors not signing up.
TBH this lines up with what I'd expect. Very few people I talk to cite issues like "creating an account" as a major barrier to editing Wikipedia. The most common barrier I've heard from people who tried editing and gave it up is "Oh, I tried, but then some random admin reverted me, linked me to MOS:OBSCURE BULLSHIT, and told me to go fuck myself but with less expletives." – Closed Limelike Curves (talk) 07:32, 29 November 2024 (UTC)[reply]
But once you look past that initial spike, the trend is downward.
Not really obvious, and not more or even less so in Portuguese wikipedia [17] than in e.g. Enwiki[18], FRwiki[19], NLwiki[20], ESwiki[21], Svwiki[22]... So, once again, these statistics show no issue at all with disabling IP editing on Portuguese Wikipedia. Fram (talk) 10:38, 29 November 2024 (UTC)[reply]
Aside from the obvious loss of good 'IP' editors, I think there's a risk of unintended consequences from 'stopping vandalism' at all; 'vandalism' and 'disruptive editing' from IP editors (or others) isn't necessarily a bad thing, long term.
Even the worst disruptive editors 'stir the pot' of articles, bringing attention to articles that need it, and otherwise would have gone unnoticed. As someone who mostly just trawls through recent changes, I can remember dozens of times when where an IP, or brand new, user comes along and breaks an article entirely, but their edit leads inexorably to the article being improved. Sometimes there is a glimmer of a good point in their edit, that I was able to express better than they were, maybe in a more balanced or neutral way. Sometimes they make an entirely inappropriate edit, but it brings the article to the top of the list, and upon reading it I notice a number of other, previously missed, problems in the article. Sometimes, having reverted a disruptive change, I just go and add some sources or fix a few typos in the article before I go on my merry way.
You might think 'Ah, but 'Random article' would let you find those problems too. BUT random article' is, well, random. IP editors are more targeted, and that someone felt the need to disparage a certain person's mother in fact brings attention to an article about someone who is, unbeknownst to us editors, particularly contentious in the world of Czech Jazz Flautists so there is a lot there to fix. By stopping people making these edits, we risk a larger proportion of articles becoming an entirely stagnant. JeffUK15:00, 9 December 2024 (UTC)[reply]
I feel that the glassmaker has been too clever by half here. "Ahh, but vandalism of articles stimulates improvements to those articles." If the analysis ends there, I have no objections. But if, on the other hand, you come to the conclusion that it is a good thing to vandalize articles, that it causes information to circulate, and that the encouragement of editing in general will be the result of it, you will oblige me to call out, "Halt! Your theory is confined to that which is seen; it takes no account of that which is not seen." If I were to pay a thousand people to vandalize Wikipedia articles full-time, bringing more attention to them, would I be a hero or villain? If vandalism is good, why do we ban vandals instead of thanking them? Because vandalism is bad—every hour spent cleaning up after a vandal is one not spent writing a new article or improving an existing one.
On targeting: vandals are more targeted than a "random article", but are far more destructive than basic tools for prioritizing content, and less effective than even very basic prioritization tools like sorting articles by total views. – Closed Limelike Curves (talk) 19:11, 9 December 2024 (UTC)[reply]
I mean, I only said Vandalism "isn't necessarily a bad thing, long term", I don't think it's completely good, but maybe I should have added 'in small doses', fixing vandalism takes one or two clicks of the mouse in most cases and it seems, based entirely on my anecdotal experience, to sometimes have surprisingly good consequences; intuitively, you wouldn't prescribe vandalism, but these things have a way of finding a natural balance, and what's intuitive isn't necessarily what's right. One wouldn't prescribe dropping asteroids on the planet you're trying to foster life upon after you finally got it going, but we can be pretty happy that it happened! - And 'vandalism' is the very worst of what unregistered (and registered!) users get up to, there are many, many more unambiguously positive contributors than unambiguously malicious. JeffUK20:03, 9 December 2024 (UTC)[reply]
intuitively, you wouldn't prescribe vandalism
Right, and I think this is mainly the intuition I wanted to invoke here—"more vandalism would be good" a bit too galaxy-brained of a take for me to find it compelling without some strong empirical evidence to back it up.
Although TBH, I don't see this as a big deal either way. We already have to review and check IP edits for vandalism; the only difference is whether that content is displayed while we wait for review (with pending changes, the edit is hidden until it's reviewed; without it, the edit is visible until someone reviews and reverts it). This is unlikely to substantially affect contributions (the only difference on the IP's end is they have to wait a bit for their edit to show up) or vandalism (since we already de facto review IP edits). – Closed Limelike Curves (talk) 04:29, 14 December 2024 (UTC)[reply]
Point 1 of Procedural removal for inactive administrators which currently reads "Has made neither edits nor administrative actions for at least a 12-month period" should be replaced with "Has made no administrative actions for at least a 12-month period". The current wording of 1. means that an Admin who takes no admin actions keeps the tools provided they make at least a few edits every year, which really isn't the point. The whole purpose of adminship is to protect and advance the project. If an admin isn't using the tools then they don't need to have them. Mztourist (talk) 07:47, 4 December 2024 (UTC)[reply]
Oppose - this would create an unnecessary barrier to admins who, for real life reasons, have limited engagement for a bit. Asking the tools back at BN can feel like a faff. Plus, logged admin activity is a poor guide to actual admin activity. In some areas, maybe half of actions aren't logged? —Femke 🐦 (talk) 19:17, 4 December 2024 (UTC)[reply]
Oppose. First, not all admin actions are logged as such. One example which immediately comes to mind is declining an unblock request. In the logs, that's just a normal edit, but it's one only admins are permitted to make. That aside, if someone has remained at least somewhat engaged with the project, they're showing they're still interested in returning to more activity one day, even if real-life commitments prevent them from it right now. We all have things come up that take away our available time for Wikipedia from time to time, and that's just part of life. Say, for example, someone is currently engaged in a PhD program, which is a tremendously time-consuming activity, but they still make an edit here or there when they can snatch a spare moment. Do we really want to discourage that person from coming back around once they've completed it? SeraphimbladeTalk to me21:21, 4 December 2024 (UTC)[reply]
We could declare specific types of edits which count as admin actions despite being mere edits. It should be fairly simple to write a bot which checks if an admin has added or removed specific texts in any edit, or made any of specific modifications to pages. Checking for protected edits can be a little harder (we need to check for protection at the time of edit, not for the time of the check), but even this can be managed. Edits to pages which match specific regular expression patterns should be trivial to detect. Animal lover|666|11:33, 9 December 2024 (UTC)[reply]
Oppose While I have never accepted "not all admin actions are logged" as a realistic reason for no logged actions in an entre year, I just don't see what problematic group of admins this is in response to. Previous tweaks to the rules were in response to admins that seemed to be gaming the system, that were basically inactive and when they did use the tools they did it badly, etc. We don't need a rule that ins't pointed a provable, ongoing problem. Just Step Sidewaysfrom this world ..... today19:19, 8 December 2024 (UTC)[reply]
Oppose If an admin is still editing, it's not unreasonable to assume that they are still up to date with policies, community norms etc. I see no particular risk in allowing them to keep their tools. Scribolt (talk) 19:46, 8 December 2024 (UTC)[reply]
Oppose Sure there is a problem, but the real problem I think is that it is puzzling why they are still admins. Perhaps we could get them all to make a periodic 'declaration of intent' or some such every five years that explains why they want to remain an admin. Alanscottwalker (talk) 19:01, 11 December 2024 (UTC)[reply]
Oppose largely per scribolt. We want to take away mops from inactive accounts where there is a risk of them being compromised, or having got out of touch with community norms, this proposal rather targets the admins who are active members of the community. Also declining incorrect deletion tags and AIV reports doesn't require the use of the tools, doesn't get logged but is also an important thing for admins to do. ϢereSpielChequers07:43, 15 December 2024 (UTC)[reply]
Oppose. What is the motivation for this frenzy to make more hoops for admins to jump through and use not jumping through hoops as an excuse to de-admin them? What problem does it solve? It seems counterproductive and de-inspiring when the bigger issue is that we don't have enough new admins. —David Eppstein (talk) 07:51, 17 December 2024 (UTC)[reply]
Oppose I quite agree with David Eppstein's sentiment. What's with the rush to add more hoops? Is there some problem with the admin corps that we're not adequately dealing with? Our issue is that we have too few admins, not that we have too many. CaptainEekEdits Ho Cap'n!⚓23:20, 22 December 2024 (UTC)[reply]
Discussion (Admin inactivity removal)
Making administrative actions can be helpful to show that the admin is still up-to-date with community norms. We could argue that if someone is active but doesn't use the tools, it isn't a big issue whether they have them or not. Still, the tools can be requested back following an inactivity desysop, if the formerly inactive admin changes their mind and wants to make admin actions again. For now, I don't see any immediate issues with this proposal. Chaotic Enby (talk · contribs) 08:13, 4 December 2024 (UTC)[reply]
Looking back at previous RFCs, in 2011 the reasoning was to reduce the attack surface for inactive account takeover, and in 2022 it was about admins who haven't been around enough to keep up with changing community norms. What's the justification for this besides "use it or lose it"? Further, we already have a mechanism (from the 2022 RFC) to account for admins who make a few edits every year. Anomie⚔12:44, 4 December 2024 (UTC)[reply]
I also note that not all admin actions are logged. Logging editing through full protection requires abusing the Edit Filter extension. Reviewing of deleted content isn't logged at all. Who will decide whether an admin's XFD "keep" closures are really WP:NACs or not? Do adminbot actions count for the operator? There are probably more examples. Currently we ignore these edge cases since the edits will probably also be there, but now if we can desysop someone who made 100,000 edits in the year we may need to consider them. Anomie⚔12:44, 4 December 2024 (UTC)[reply]
I had completely forgotten that many admin actions weren't logged (and thus didn't "count" for activity levels), that's actually a good point (and stops the "community norms" arguments as healthy levels of community interaction can definitely be good evidence of that). And, since admins desysopped for inactivity can request the tools back, an admin needing the bit but not making any logged actions can just ask for it back. At this point, I'm not sure if there's a reason to go through the automated process of desysopping/asking for resysop at all, rather than just politely ask the admin if they still need the tools.I'm still very neutral on this by virtue of it being a pretty pointless and harmless process either way (as, again, there's nothing preventing an active admin desysopped for "inactivity" from requesting the tools back), but I might lean oppose just so we don't add a pointless process for the sake of it. Chaotic Enby (talk · contribs) 15:59, 4 December 2024 (UTC)[reply]
To me this comes down to whether the community considers it problematic for an admin to have tools they aren't using. Since it's been noted that not all admin actions are logged, and an admin who isn't using their tools also isn't causing any problems, I'm not sure I see a need to actively remove the tools from an inactive admin; in a worst-case scenario, isn't this encouraging an admin to (potentially mis-)use the tools solely in the interest of keeping their bit? There also seems to be somewhat of a bad-faith assumption to the argument that an admin who isn't using their tools may also be falling behind on community norms. I'd certainly like to hope that if I was an admin who had been inactive that I would review P&G relevant to any admin action I intended to undertake before I executed. DonIago (talk) 15:14, 4 December 2024 (UTC)[reply]
As I have understood it, the original rationale for desysopping after no activity for a year was the perception that an inactive account was at higher danger of being hijacked. It had nothing to do with how often the tools were being used, and presumably, if the admin was still editing, even if not using the tools, the account was less likely to be hijacked. - Donald Albury22:26, 4 December 2024 (UTC)[reply]
And also, if the account of an active admin was hijacked, both the account owner and those they interact with regularly would be more likely to notice the hijacking. The sooner a hijacked account is identified as hijacked, the sooner it is blocked/locked which obviously minimises the damage that can be done. Thryduulf (talk) 00:42, 5 December 2024 (UTC)[reply]
I was not aware that not all admin actions are logged, obviously they should all be correctly logged as admin actions. If you're an Admin you should be doing Admin stuff, if not then you obviously don't need the tools. If an Admin is busy IRL then they can either give up the tools voluntarily or get desysopped for inactivity. The "Asking the tools back at BN can feel like a faff." isn't a valid argument, if an Admin has been desysopped for inactivity then getting the tools back should be "a faff". Regarding the comment that "There's no indication that this is a problem needs fixing." the problem is Admins who don't undertake admin activity, don't stay up to date with policies and norms, but don't voluntarily give up the tools. The 2022 change was about total edits over 5 years, not specifically admin actions and so didn't adequately address the issue. Mztourist (talk) 03:23, 5 December 2024 (UTC)[reply]
obviously they should all be correctly logged as admin actions - how would you log actions that are administrative actions due to context/requiring passive use of tools (viewing deleted content, etc.) rather than active use (deleting/undeleting, blocking, and so on)/declining requests where accepting them would require tool use? (e.g. closing various discussions that really shouldn't be NAC'd, reviewing deleted content, declining page restoration) Maybe there are good ways of doing that, but I haven't seen any proposed the various times this subject came up. Unless and until "soft" admin actions are actually logged somehow, "editor has admin tools and continues to engage with the project by editing" is the closest, if very imperfect, approximation to it we have, with criterion 2 sort-of functioning to catch cases of "but these specific folks edit so little over a prolonged time that it's unlikely they're up-to-date and actively engaging in soft admin actions". (I definitely do feel criterion 2 could be significantly stricter, fwiw) AddWittyNameHere05:30, 5 December 2024 (UTC)[reply]
Not being an Admin I have no idea how their actions are or aren't logged, but is it a big ask that Admins perform at least a few logged Admin actions in a year? The "imperfect, approximation" that "editor has admin tools and continues to engage with the project by editing" is completely inadequate to capture Admin inactivity. Mztourist (talk) 07:06, 6 December 2024 (UTC)[reply]
I've been a "hawk" regarding admin activity standards for a very long time, but this proposal comes off as half-baked. The rules we have now are the result of careful consideration and incremental changes aimed at specific, provable issues with previous standards. While I am not a proponent of "not all actions are logged" as a blanket excuse for no logged actions in several years, it is feasible that an admin could be otherwise fully engaged with the community while not having any logged actions. We haven't been having trouble with admins who would be removed by this, so where's the problem? Just Step Sidewaysfrom this world ..... today19:15, 8 December 2024 (UTC)[reply]
"Blur all images" switch
Although i know that WP:NOTCENSORED, i propose that the Vector 2022 and Minerva Neue skins (+the Wikipedia mobile apps) have a "blur all images" toggle that blurs all the images on all pages (requiring clicking on them to view them), which simplifies the process of doing HELP:NOSEE as that means:
You don't need to create an account to hide all images.
You don't need any complex JavaScript or CSS installation procedures. Not even browser extensions.
You can blur all images in the mobile apps, too.
It's all done with one push of a button. No extra steps needed.
Blurring all images > hiding all images. The content of a blurred image could be easily memorized, while a completely hidden image is difficult to compare to the others.
Wow, @Chaotic Enby, is that usable on all skins/browsers/devices? If so, we should be referring people to it from everywhere instead of the not-very-helpful WP:NOSEE, which I didn't even bother to try to figure out. Valereee (talk) 15:00, 17 December 2024 (UTC)[reply]
I haven't tested it beyond my own setup, although I can't see reasons why it wouldn't work elsewhere. However, there are two small bugs I'm not sure how to fix: when loading a new page, the images briefly show up for a fraction of a second before being blurred; and the images in Page Previews aren't blurred (the latter, mostly because I couldn't get the html code for the popups). Chaotic Enby (talk · contribs) 16:57, 17 December 2024 (UTC)[reply]
Ah, yes, I see both of those. Probably best to get at least the briefly-showing bug fixed before recommending it generally. The page previews would be good to fix but may be less of an issue for recommending generally, since people using that can be assumed to know how to turn it off. Valereee (talk) 18:28, 17 December 2024 (UTC)[reply]
@Valereee -- the issue with a script would be as follows:
Even for logged-in users, user scripts are a moderate barrier to install (digging through settings, or worse still, having to copy-paste to the JS/CSS user pages).
The majority of readers do not have an account, and the overwhelming majority of all readers make zero edits. For many people, it's too much of a hassle to sign up (or they can't remember their password, or a number of other reasons etc, etc)
What all readers and users have, though, is this menu:
I say instead of telling the occasional IP or user who complains to install a script (there are probably many more people who object to NOTCENSORED, but don't want to or don't know how to voice objections), we could add the option to replace all images with a placeholder (or blur) and perhaps also an option to increase thumbnail size.
On the image blacklist aspect, doesn't Anomie have a script that hides potentially offensive images? I've not a clue how it works, but perhaps it could be added to the appearance menu (I don't support this myself, for a number of reasons)
That's User:Anomie/hide-images, which is already listed on WP:NOSEE. I wrote it a long time ago as a joke for one of these kinds of discussions: it does very well at hiding all "potentially offensive" images because it hides all images. But people who want to have to click to see any images found it useful enough to list it on WP:NOSEE. Anomie⚔22:52, 17 December 2024 (UTC)[reply]
Out of curiosity, how does it filter for potentially offensive images? The code at user:Anomie/hide-images.js seems rather minimal (as I write this, I realize it may work by hiding all images, so I may have answered my own question). JayCubby22:58, 17 December 2024 (UTC)[reply]
Will be a problem for non registered users, as the default would clearly to leave images in blurred for them. — Masem (t) 15:40, 5 December 2024 (UTC)[reply]
That's my point: if you are unregistered, you will see whatever the default setting is (which I assume will be unblurred, which might lead to more complaints). We had similar problems dealing with image thumbnail sizes, a setting that unregistered users can't adjust. Masem (t) 01:10, 6 December 2024 (UTC)[reply]
I'm confused about how this would lead to more complaints. Right now, logged-out users see every image without obfuscation. After this toggle rolls out, logged-out users would still see every image without obfuscation. What fresh circumstance is leading to new complaints? ꧁Zanahary꧂07:20, 12 December 2024 (UTC)[reply]
I suggest that the "hide all images" display file name if possible. Between file name and caption (which admittedly are often similar, but not always), there should be sufficient clue whether an image will be useful (and some suggestion, but not reliably so, if it may offend a sensibility.) -- Nat Gertler (talk) 17:59, 11 December 2024 (UTC)[reply]
Regarding not limiting image management choices to Wikipedia: that's why it's better to manage this on the client side. Anyone needing to limit their bandwidth usage, or to otherwise decide individually on whether or not to load each photo, will likely want to do this generally in their web browsing. isaacl (talk) 18:43, 6 December 2024 (UTC)[reply]
Definitely a browser issue. You can get plug-ins for Chrome right now that will do exactly this, and there's no need for Wikipedia/Mediawiki to implent anything. — The Anome (talk) 18:48, 6 December 2024 (UTC)[reply]
I propose something a bit different: all images on the bad images list can only be viewed with a user account that has been verified to be over 18 with government issued ID. I say this because in my view there is absolutely no reason for a minor to view it. Jayson (talk) 23:41, 8 December 2024 (UTC)[reply]
Well, that means readers will be forced to not only create an account, but also disclose sensitive personal information, just to see encyclopedic images. That is pretty much the opposite of a free encyclopedia. Chaotic Enby (talk · contribs) 23:44, 8 December 2024 (UTC)[reply]
I can support allowing users to opt to blu4 or hide some types of images, but this needs to be an opt-in only. By default, show all images. And I'm also opposed to any technical restriction which requires self-identification to overcome, except for cases where the Foundation deems it necessary to protect private information (checkuser, oversight-level hiding, or emails involving private information). Please also keep in mind that even if a user sends a copy of an ID which indicates the individual person's age, there is no way to verify that it was the user's own ID whuch had been sent. Animal lover|666|11:25, 9 December 2024 (UTC)[reply]
Well, yes, but I rank that as “harmless”. I don’t know why anyone would consider a woman with her newborn baby so inappropriate for children it needs to be censored like hardcore porn. Dronebogus (talk) 14:53, 12 December 2024 (UTC)[reply]
The Hezbollah flag might be blacklisted because it's copyrighted, but placed in articles by uninformed editors (though one of JJMC89's bots automatically removes NFC files from pages). We have File:InfoboxHez.PNG for those uses. JayCubby16:49, 13 December 2024 (UTC)[reply]
This is an even better idea as an opt-in toggle than the blur one. Load no images by default, and let users click a button to load individual images. That has a use beyond sensitivity. ꧁Zanahary꧂02:46, 13 December 2024 (UTC)[reply]
Yes I like that idea even better. I think in any case we should use alt text to describe the image so people don’t have to play Russian roulette based on potentially vague or nonexistent descriptions, i.e. without alt text an ignorant reader would have no idea the album cover for Virgin Killer depicts a nude child in a… questionable pose. Dronebogus (talk) 11:42, 13 December 2024 (UTC)[reply]
An option to replace images with alt text seems both much more useful and much more neutral as an option. There are technical reasons why a user might want to not load images (or only selectively load them based on the description), so that feels more like a neutral interface setting. An option to blur images by default sends a stronger message that images are dangerous.--Trystan (talk) 16:24, 13 December 2024 (UTC)[reply]
Also it'd negate the bandwidth savings somewhat (assuming an image is displayed as a low pixel-count version). I'm of the belief that Wikipedia should have more features tailored to the reader. JayCubby16:58, 13 December 2024 (UTC)[reply]
At the very least, add a filter that allows you to block all images on the bad image list, specifically that list and those images. To the people who say you shouldnt have to give up personal info, I say that we should go the way Roblox does. Seems a bit random, hear me out: To play 17+ games, you need to verify with gov id, those games have blood alcohol, unplayable gambling and "romance". I say that we do the same. Giving up personal info to view bad things doesn't seem so bad to me. Jayson (talk) 03:44, 15 December 2024 (UTC)[reply]
Building up a database of people who have applied to view bad things on a service that's available in restrictive regimes sounds like a way of putting our users in danger. -- Nat Gertler (talk) 07:13, 15 December 2024 (UTC)[reply]
Roblox =/= Wikipedia. I don’t know why I have to say this, nor did I ever think I would. And did you read what I already said about the “bad list”? Do you want people to have to submit their ID to look at poop, a woman with her baby, the Hezbollah flag, or graffiti? How about we age-lock articles about adult topics next? Dronebogus (talk) 15:55, 15 December 2024 (UTC)[reply]
So removing a significant thing that makes Wikipedia free is worth preventing underaged users from viewing certain images? I wouldn't say that would be a good idea if we want to make Wikipedia stay successful. If a reader wants to read an article, they should expect to see images relevant to the topic. This includes topics that are usually considered NSFW like Graphic violence, Sexual intercourse, et cetera. If a person willingly reads an article about an NSFW topic, they should acknowledge that they would see topic-related NSFW images. ZZZ'S16:45, 15 December 2024 (UTC)[reply]
Yes, if this happens it should be through a disable all images toggle, not an additional blur. There have been times that would have been very helpful for me. CMD (talk) 03:52, 15 December 2024 (UTC)[reply]
Support the proposal as written. I'd imagine WMF can add a button below the already-existing accessibility options. People have different cultural, safety, age, and mental needs to block certain images. Catalk to me!13:04, 15 December 2024 (UTC)[reply]
I'd support an option to replace images with the alt text, as long as all you had to do to see a hidden image was a single click/tap (we'd need some fallback for when an image has no alt text, but that's a minor issue). Blurring images doesn't provide any significant bandwidth benefits and could in some circumstances cause problems (some blurred innocent images look very similar to some blurred blurred images that some people regard as problematic, e.g. human flesh and cooked chicken). I strongly oppose anything that requires submitting personal information of any sort in order to see images per NatGertler. Thryduulf (talk) 14:15, 15 December 2024 (UTC)[reply]
This is something that has frequently occurred to me as a potentially useful feature when browsing categories, but I have never quite gotten around to actually proposing it until now.
Basically, I'm thinking it could be very helpful to have content-assessment class icons appear next to article entries in categories. This should be helpful not only to readers, to guide them to the more complete entries, but also to editors, to alert them to articles in the category that are in need of work. Thoughts? Gatoclass (talk) 03:02, 7 December 2024 (UTC)[reply]
If we go with this, I think there should be only 4 levels - Stub, Average (i.e. Start, C, or B), GA, & FA.
There are significant differences between Start, C, and B, but there's no consistent effort to grade these articles correctly and consistently, so it might be better to lump them into one group. Especially if an article goes down in quality, almost nobody will bother to demote it from B to C. ypn^204:42, 8 December 2024 (UTC)[reply]
Isn't that more of an argument for consolidation of the existing levels rather than reducing their number for one particular application?
Other than that, I think I would have to agree that there are too many levels - the difference between Start and C class, for example, seems quite arbitrary, and I'm not sure of the usefulness of A class - but the lack of consistency within levels is certainly not confined to these lower levels, as GAs can vary enormously in quality and even FAs. But the project nonetheless finds the content assessment model to be useful, and I still think their usefulness would be enhanced by addition to categories (with, perhaps, an ability to opt in or out of the feature).
I might also add that including content assessment class icons to categories would be a good way to draw more attention to them and encourage users to update them when appropriate. Gatoclass (talk) 14:56, 8 December 2024 (UTC)[reply]
I believe anything visible in reader-facing namespaces needs to be more definitively accurate than in editor-facing namespaces. So I'm fine having all these levels on talk pages, but not on category pages, unless they're applied more rigorously.
On the other hand, with FAs and GAs, although standards vary within a range, they do undergo a comprehensive, well-documented, and consistent process for promotion and demotion. So just like we have an icon at the top of those articles (and in the past, next to interwiki links), I could hear putting them in categories. [And it's usually pretty obvious whether something's a stub or not.] ypn^218:25, 8 December 2024 (UTC)[reply]
Isn't the display of links Category pages entirely dependent on the Mediawiki software? We don't even have Short descriptions displayed, which would probably be considerably more useful.Any function that has to retrieve content from member articles (much less their talkpages) is likely to be somewhat computationally expensive. Someone with more technical knowledge may have better information. Folly Mox (talk) 18:01, 8 December 2024 (UTC)[reply]
Yes, this will definitely require MediaWiki development, but probably not so complex. And I wonder why this will be more computationally expensive than scanning articles for [ [Category: ] ] tags in the first place. ypn^218:27, 8 December 2024 (UTC)[reply]
And I wonder why this will be more computationally expensive than scanning articles for [ [Category: ] ] tags in the first place my understanding is that this is not what happens. When a category is added to or removed from an article, the software adds or removes that page as a record from a database, and that database is what is read when viewing the category page. Thryduulf (talk) 20:14, 8 December 2024 (UTC)[reply]
I think that in the short term, this could likely be implemented using a user script (displaying short descriptions would also be nice). Longer-term, if done via an extension, I suggest limiting the icons to GAs and FAs for readers without accounts, as other labels aren't currently accessible to them. (Whether this should change is a separate but useful discussion). — Frostly (talk) 23:06, 8 December 2024 (UTC)[reply]
I strongly believe that ordinary readers don't care about this kind of inside baseball, but if you want it for yourself, then use the gadget or fork its script. Changing this old gadget from "adding text and color" to "displaying an icon" should be relatively simple. WhatamIdoing (talk) 23:43, 12 December 2024 (UTC)[reply]
I strongly oppose loading any default javascript solution that would cause hundreds of client-side queries every time a category page is opened. As far as making an upstream software request, there are multiple competing page quality metrics and schemes that would need to be reviewed. — xaosfluxTalk15:13, 18 December 2024 (UTC)[reply]
My suggestion would be to put those pages only in the "Class" category (in this case Category:Portal-Class United States articles), and only give that category a NA-rating. Doing this for all these subcats (File, Template, ...) would bring the at the moment 276,534 (!) pages in Category:NA-importance United States articles back to near-zero, only leaving the anomalies which probably need a different importance rating (and thus making it a useful cleanup category).
Are there any pages that don't have the default? e.g. are there any portals or Category talk: pages rated something other than N/A importance? If not then I can't see any downsides to the proposal as written. If there are exceptions, then as long as the revised behaviour allows for the default to be overwritten when desired again it would seem beneficial. Thryduulf (talk) 16:36, 9 December 2024 (UTC)[reply]
As far as I know, there are no exceptions. And I believe that one can always override the default behaviour with a local parameter. @Tom.Reding: I guess you know these things better and/or knows who to contact for this. Fram (talk) 16:41, 9 December 2024 (UTC)[reply]
I was imagining high importance United States redirects to be things like USA but that isn't there and what is is a very motley collection. I only took a look at one, Talk:United States women. As far as I can make out the article was originally at this title but later moved to Women in the United States over a redirect. Both titles had independent talk pages that were neither swapped nor combined, each being rated high importance when they were the talk page of the article. It seems like a worthwhile exercise for the project to determine whether any of those redirects are actually (still?) high priority but that's independent of this proposal. Thryduulf (talk) 17:17, 9 December 2024 (UTC)[reply]
Support this, even if there might be a few exceptions, it will make them easier to spot and deal with rather than having large unsorted NA-importance categories. Chaotic Enby (talk · contribs) 18:04, 9 December 2024 (UTC)[reply]
Strongly agree with this. It's bizarre having two different systems, as well as a pain in the ass sometimes. Ideally we should adopt a single consistent categorization system for importance/quality. – Closed Limelike Curves (talk) 22:56, 16 December 2024 (UTC)[reply]
So essentially what you are proposing is to delete Category:NA-importance articles and all its subcategories? I think it would be best to open a CfD for this, so that the full implications can be discussed and consensus assured. It is likely to have an effect on assessment tools, and tables such as User:WP 1.0 bot/Tables/Project/Africa would no longer add up to the expected number — Martin (MSGJ · talk) 22:13, 14 December 2024 (UTC)[reply]
Well a CfD just got closed with 14,000 categories, so that is not a barrier. It is also the technically correct venue for such discussions. By the way, all of the quality/importance intersection categories check that the category exists before using it, so deleting them shouldn't break anything. — Martin (MSGJ · talk) 08:57, 16 December 2024 (UTC)[reply]
I'm going to have to oppose any more changes to class categories. Already changes are causing chaos across the system with the bots unable to process renamings and fixing redirects whilst Special:Wantedcategories is being overwhelmed by the side effects. Quite simply we must have no more changes that cannot be properly processed. Any proposal must have clear instructions posted before it is initiated, not some vague promise to fix a module later on. Timrollpickering (talk) 13:16, 16 December 2024 (UTC)[reply]
Then I'm at an impasse. Module people tell me "start a CfD", you tell me "no CfD, first make changes at the module". No one wants the NA categories for these groups. What we can do is 1. RfC to formalize that they are unwanted, 2. Change module so they no longer get populated 3. Delete the empty cats caused by steps 1 and 2. Is that a workable plan for everybody? Fram (talk) 13:39, 16 December 2024 (UTC)[reply]
I don't think @Timrollpickering was telling you to make the changes at the module first, rather to prepare the changes in advance so that the changes can be implemented as soon as the CfD reaches consensus. For example this might be achieved by having a detailed list of all the changes prepared and published in a format that can be fed to a bot. For a change of this volume though I do think a discussion as well advertised as an RFC is preferable to a CfD though. Thryduulf (talk) 14:43, 16 December 2024 (UTC)[reply]
Got it in one. There are just too many problems at the moment because the modules are not being properly amended in time. We need to be firmer in requiring proponents to identify the how to change before the proposal goes live so others can enact it if necessary, not close the discussion, slap the category on the working page and let a mess pile up whilst no changes to the module are implemented. Timrollpickering (talk) 19:37, 16 December 2024 (UTC)[reply]
Oh, I got it as well, but at the module talk page, I was told to first have a CfD (to determine consensus first I suppose, instead of writing the code without knowing if it will be implemented). As I probably lack the knowledge to make the correct module changes, I'm at an impasse. That's why I suggested an RfC instead of a CfD to determine the consensus for "deletion after the module has been changed", instead of a CfD which is more of the "delete it now" variety. No one here has really objected to the deletion per se, but I guess that a more formal discussion might be welcome. Fram (talk) 10:09, 17 December 2024 (UTC)[reply]
What's the benefit of having two or three categories for the same group of pages? We have multiple systems (with two or three cats, and apparently other ones as well), with no apparent reason to keep this around. As an example, we have Category:Category-Class film articles with more than 50,000 pages, e.g. Category talk:20th century in American cinema apparently. But when I go to that page, it isn't listed in that category, it is supposedly listed in Category:NA-Class film articles (which seems to be a nonsense category, we shouldn't have NA-class, only NA-importance). but that category doesn't contain that page. So now I have no idea what's going on or what any of this is trying to achieve. Fram (talk) 08:30, 18 December 2024 (UTC)[reply]
Something changed recently. I think. But it is useful to know which NA pages are tagged with a project with a granularity beyond just "Not Article". It helps me do maintenance and find things that are tagged improperly, especially with categories. I do not care what happens to the importance ratings. PARAKANYAA (talk) 09:20, 18 December 2024 (UTC)[reply]
Category:Current sports events
I would like to propose that sports articles should be left in the Category:Current sports events for 48 hours after these events have finished. I'm sure many Wikipedia sports fans (including me) open CAT:CSE first and then click on a sporting event in that list. And we would like to do so in the coming days after the event ends to see the final standings and results.
Currently, this category is being removed from articles too early, sometimes even before the event ends. Just like yesterday. AnishaShar, what do you say about that?
Thank you for bringing up this point. I agree that leaving articles in the Category:Current sports events for a short grace period after the event concludes—such as 48 hours—would benefit readers who want to catch up on the final standings and outcomes. AnishaShar (talk) 18:19, 9 December 2024 (UTC)[reply]
You ask how it would be policed. Simply, we will teach editors to do it that way – to leave an article in that category for another 48 hours. AnishaShar have already expressed their opinion above. WL Pro for life is also known for removing 'CAT:CSE's from articles. I think we could put some kind of notice in that category so other editors can notice it. We could set up a vote here. Maybe someone else will have a better idea. Maiō T. (talk) 20:25, 14 December 2024 (UTC)[reply]
In a number of articles we have (or had) user-generated conflict maps. I think the mains ones at the moment are Syrian civil war and Russian invasion of Ukraine. The war in Afghanistan had one until it was removed as poorly-sourced in early 2021. As you can see from a brief review of Talk:Syrian civil war the map has become quite controversial there too.
My personal position is that sourcing conflict maps entirely from reports of occupation by one side or another of individual towns at various times, typically from Twitter accounts of dubious reliability, to produce a map of the current situation in an entire country (which is the process described here), is a WP:SYNTH/WP:OR. I also don't see liveuamap.com as necessarily being a highly reliable source either since it basically is an WP:SPS/Wiki-style user-generated source, and when it was discussed at RSN editors there generally agreed with that. I can understand it if a reliable source produces a map that we can use, but that isn't what's happening here.
Part of the reason this flies under the radar on Wikipedia is it ultimately isn't information hosted on EN WP but instead on Commons, where reliable sourcing etc. is not a requirement. However, it is being used on Wikipedia to present information to users and therefore should fall within our PAGs.
I think these maps should be deprecated unless they can be shown to be sourced entirely to a reliable source, and not assembled out of individual reports including unreliable WP:SPS sources. FOARP (talk) 16:57, 11 December 2024 (UTC)[reply]
A lot of the maps seem like they run into SYNTH issues because if they're based on single sources they're likely running into copyright issue as derivative works. I would agree though that if an image does not have clear sourcing it shouldn't be used as running into primary/synth issues. Der Wohltemperierte Fuchstalk17:09, 11 December 2024 (UTC)[reply]
Though simple information isn't copyrightable, if it's sufficiently visually similar I suppose that might constitute a copyvio. JayCubby02:32, 13 December 2024 (UTC)[reply]
I agree these violate OR and at least the spirit of NOTNEWS and should be deprecated. I remember during the Wagner rebellion we had to fix one that incorrectly depicted Wagner as controlling a swath of Russia. Levivich (talk) 05:47, 13 December 2024 (UTC)[reply]
Oppose: First off, I'd like to state my bias as a bit of a map geek. I've followed the conflict maps closely for years.
I think the premise of this question is flawed. Some maps may be poorly sourced, but that doesn't mean all of them are. The updates to the Syrian, Ukraine, and Burma conflicts maps are sourced to third parties. So that resolves the OR issue.
The sources largely agree with each other, which makes SYNTH irrelevant. Occasionally one source may be ahead of another by a few hours (e.g., LiveUaMap vs. ISW), but they're almost entirely in lock step.
I think this proposal throws out the baby with the bathwater. One bad map doesn't mean we stop using maps; it means we stop using bad maps.
You may not like the fact that these sources sometimes use OSI (open-source intelligence). Unfortunately, that is the nature of conflict in a zone where the press isn't allowed. Any information you get from the AP or the US government is likely to rely on the same sources.
Do they make mistakes? Probably; but so do all historical sources. And these maps have the advantage that the Commons community continuously reviews changes made by other users. Much in the same way that Wikipedia is often more accurate than historical encyclopedias, I believe crowdsourcing may make these maps more accurate than historical ones.
I think deprecating these maps would leave the reader at a loss (pictures speak a 1,000 words and all that). Does it get a border crossing wrong here or there? Yes, but the knowledge is largely correct.
@Magog the OgreWP:ITSUSEFUL is frowned upon as an argument for good reason. Beyond that: 1) the fact that these are based on fragmentary data is strangely not mentioned at all (Syrian civil war says 'Military situation as of December 18, 2024 at 2:00pm ET' which suggests that it's quite authoritative and should be trusted; the fact that it's based off the ISW is not disclosed.) 2) I'm not seeing where all the information is coming from the ISW. The ISW's map only covers territory, stuff like bridges, dams, "strategic hills" and the like are not present on the ISW map[23]. Where is that info coming from? Der Wohltemperierte Fuchstalk23:10, 19 December 2024 (UTC)[reply]
The Commons Syria map uses both the ISW and Liveuamap. The two are largely in agreement, with Liveuamap being more precise but using less reliable sources. If you have an issue with using Liveuamap as a source, fine, bring it up on the talk pages where it's used, or on the Commons talk page itself. But banning any any map of a conflict is throwing out the baby with the bathwater. The Ukraine map is largely based on ISW-verifiable information.
With regards to actual locations like bridges, I'm against banning Commons users from augmenting maps with easily verifiable landmarks. That definition of SYN is broad to the point of meaningless, as it would apply to any user-generated content that uses more than one source. Magog the Ogre (t • c) 23:50, 20 December 2024 (UTC)[reply]
Weak Oppose I've been updating the Ukraine map since May 2022, so I hope my input is helpful. While I agree that some of the sources currently being used to update these maps may be dubious in nature, that has not always been the case. In the past, particularly for the Syria map, these maps have been considered among the most accurate online due to their quality sourcing. It used to be that a source was required for each town if it was to be displayed on these maps, but more recently, people have just accepted taking sources like LivaUAMap and the ISW and copying them exactly. Personally, I think we should keep the maps but change how they are sourced. I think that going back to the old system of requiring a reliable source for each town would clear up most of the issues that you are referring to, though it would probably mean that the maps would be less detailed than they currently are now. Physeters✉07:23, 21 December 2024 (UTC)[reply]
Oppose The campaign maps are one of our absolute best features. The Syrian campaign map in particular was very accurate for much of the war. Having a high quality SVG of an entire country like that is awesome, and there really isn't anything else like it out there, which is why it provides such value to our readers. I think we have to recognize of our course that they're not 100% accurate, due to the fog of war. I wouldn't mind if we created subpages about the maps? Like, with a list of sources and their dates, designed to be reader facing, so that our readers could verify the control of specific towns for themselves. But getting rid of the maps altogether is throwing out the baby with the bathwater. CaptainEekEdits Ho Cap'n!⚓23:33, 22 December 2024 (UTC)[reply]
What is the proposal here? If its for the google maps article, that would be more suitable for the talk page. As I see it, your proposal is simply saying that google maps has an api and we should use it for... something. I could be missing something, though Mgjertson (talk) 08:20, 17 December 2024 (UTC)[reply]
As I understand it, the IP is proposing embeds of google maps, which would be nice from a functionality standpoint (the embedded map is kinda-rather buggy), but given Google is an advertising company, isn't great from a privacy standpoint. JayCubby16:25, 17 December 2024 (UTC)[reply]
Allowing page movers to enable two-factor authentication
I would like to propose that members of the page mover user group be granted the oathauth-enable permission. This would allow them to use Special:OATH to enable two-factor authentication on their accounts.
Rationale (2FA for page movers)
The page mover guideline already obligates people in that group to have a strong password, and failing to follow proper account security processes is grounds for revocation of the right. This is because the group allows its members to (a) move pages along with up to 100 subpages, (b) override the title blacklist, and (c) have an increased rate limit for moving pages. In the hands of a vandal, these permissions could allow significant damage to be done very quickly, which is likely to be difficult to reverse.
Additionally, there is precedent for granting 2FA access to users with rights that could be extremely dangerous in the event of account compromise, for instance, template editors, importers, and transwiki importers have the ability to enable this access, as do most administrator-level permissions (sysop, checkuser, oversight, bureaucrat, steward, interface admin).
Support as a pagemover myself, given the potential risks and need for increased security. I haven't requested it yet as I wasn't sure I qualified and didn't want to bother the stewards, but having oathauth-enable by default would make the process a lot more practical. Chaotic Enby (talk · contribs) 22:30, 12 December 2024 (UTC)[reply]
Question When's the last time a page mover has had their account compromised and used for pagemove vandalisn? Edit 14:35 UTC: I'm not doubting the nom, rather I'm curious and can't think of a better way to phrase things. JayCubby02:30, 13 December 2024 (UTC)[reply]
Why isn't everybody allowed to enable 2FA? I've never heard of any other website where users have to go request someone's (pro forma, rubber-stamp) permission if they want to use 2FA. And is it accurate that 2FA, after eight years, is still "experimental" and "in production testing"? I guess my overall first impression didn't inspire me with confidence in the reliability and maintenance. Adumbrativus (talk) 06:34, 14 December 2024 (UTC)[reply]
I ain't a technical person, but could a less secure version of 2fa be introduced, where an email is sent for any login on new devices? JayCubby01:13, 15 December 2024 (UTC)[reply]
Definitely. However email addresses also get detached from people, so that would require that people regularly reconfirm their contact information. —TheDJ (talk • contribs) 11:01, 18 December 2024 (UTC)[reply]
For TOTP (the 6-digit codes), it's not quite as bad as when it was written, as the implementation has been fixed over time. I haven't heard nearly as many instances of backup scratch codes not working these days compared to when it was new. The WebAuthn (physical security keys, Windows Hello, Apple Face ID, etc) implementation works fine on private wikis but I wouldn't recommend using it for CentralAuth, especially with the upcoming SUL3 migration. There's some hope it'll work better afterward, but will still require some development effort. As far as I'm aware, WMF is not currently planning to work on the 2FA implmentation. As far as risk for page mover accounts goes, they're at a moderate risk. Page move vandalism, while annoying to revert, is reversible and is usually pretty loud (actions of compromised accounts can be detected and stopped easily). The increased ratelimit is the largest concern, but compared to something like account creator (which has noratelimit) it's not too bad. I'm more concerned about new page reviewer. There probably isn't a ton of harm to enabling 2FA for these groups, but there isn't a particularly compelling need either. AntiCompositeNumber (talk) 12:47, 19 December 2024 (UTC)[reply]
Support per nom. PMV is a high-trust role (suppressredirect is the ability to make a blue link turn red), and thus this makes sense. As a side note, I have changed this to bulleted discussion; # is used when we have separate sections for support and oppose. HouseBlaster (talk • he/they) 07:19, 14 December 2024 (UTC)[reply]
Oppose As a pagemover myself, I find pagemover is an extremely useful and do not wish to lose it. It is nowhere near the same class as template editor. You can already ask the stewards for 2FA although I would recommend creating a separate account for the purpose. After all these years, 2FA remains experimental, buggy and cumbersome. Incompatible with the Microsoft Authenticator app on my iphone. Hawkeye7(discuss)23:59, 14 December 2024 (UTC)[reply]
Understood, but I do not want it associated with an administrator-level permission, which would mean I am not permitted to use it, as I am not an admin. Hawkeye7(discuss)09:44, 15 December 2024 (UTC)[reply]
It's not really that. It would be an opt-in to allow users (in the group) to put 2FA on their account - at their own digression.
The main reasons why 2FA is currently out to admins and the like is because they are more likely to be targeted for compromising and are also more experienced. The 2FA flag doesn't require any admin skills/tools and is only incedentally linked. Lee Vilenski(talk • contribs)12:58, 15 December 2024 (UTC)[reply]
@Closed Limelike Curves the MediaWiki's 2FA implementation is complex, and the WMF's processes to support people who get locked out of their account aren't able to handle a large volume of requests (developers can let those who can prove they are the owner of the account back in). My understanding is that the current processes cannot be efficiently scaled up either, as it requires 1:1 attention from a developer, so unless and until new processes have been designed, tested and implemented 2FA is intended to be restricted to those who understand how to use it correctly and understand the risks of getting locked out. Thryduulf (talk) 09:36, 18 December 2024 (UTC)[reply]
It probably won't make a huge difference because those who really desire 2FA can already request the permission to enable it for their account, and because no page mover will be required to do so. However, there will be page movers who wouldn't request a global permission for 2FA yet would enable it in their preferences if it was a simple option. And these page movers might benefit from 2FA even more than those who already care very strongly about the security of their account. ~ ToBeFree (talk) 03:18, 15 December 2024 (UTC)[reply]
Oppose this is a low value permission, not needed. If an individual PMV really wants to opt-in, they can already do so over at meta - no need to build custom configuration for this locally. — xaosfluxTalk15:06, 18 December 2024 (UTC)[reply]
Support All users should be able to opt in to 2FA. Lack of a scalable workflow for users locked out of their accounts is going to be addressed by WMF only if enough people are using 2FA (and getting locked out?) to warrant its inclusion in the product roadmap. – SD0001 (talk) 14:01, 19 December 2024 (UTC)[reply]
That (and to @Stifle above) sounds like an argument to do just that - get support put in place and enable this globally, not to piecemeal it in tiny batches for discretionary groups on a single project (this custom configuration would support about 3/10ths of one percent of our active editors). To the point of this RFC, why do you think adding this for this specific tiny group is a good idea? — xaosfluxTalk15:40, 19 December 2024 (UTC)[reply]
I'm pretty sure that 2FA is already available to anyone. You just have to want it enough to either request it "for testing purposes" or to go to testwiki and request that you made an admin there, which will automatically give you access. See H:ACCESS2FA. WhatamIdoing (talk) 23:41, 21 December 2024 (UTC)[reply]
Oppose. It sounds like account recovery when 2FA is enabled involves Trust and Safety. I don't think page movers' account security is important enough to justify increasing the burden on them. —Compassionate727(T·C)14:10, 21 December 2024 (UTC)[reply]
Losing access to the account is less common nowadays since most 2FA apps, including Google Authenticator, have implemented cloud syncing so that even if you lose your phone, you can still access the codes from another device. – SD0001 (talk) 14:40, 21 December 2024 (UTC)[reply]
That's not true. You can use any TOTP authenticator app for MediaWiki 2FA. I currently use Ente Auth, having moved on from Authy recently, and from Google Authenticator a few years back. In case you're thinking of SMS-based 2FA, it has become a thing of the past and is not supported by MediaWiki either because it's insecure (attackers have ways to trick your network provider to send them your texts). – SD0001 (talk) 09:19, 22 December 2024 (UTC)[reply]
Support. Even aside from the fact that, in 2024+, everyone should be able to turn on 2FA .... Well, absolutely certainly should everyone who has an advanced bit, with potential for havoc in the wrong hands, be able to use 2FA here. That also includes template-editor, edit-filter-manager, file-mover, account-creator (and supersets like event-coordinator), checkuser (which is not strictly tied to adminship), and probably also mass-message-sender, perhaps a couple of the others, too. Some of us old hands have several of these bits and are almost as much risk as an admin when it comes to loss of account control. — SMcCandlish☏¢ 😼 04:40, 22 December 2024 (UTC)[reply]
Comment: It is really not usual for 2FA to be available to a user group that is not defined as privileged in the WMF files. By default, all user groups defined at CommonSettings.php (iirc) that are considered to be privileged have the oathauth-enable right. Also, the account security practices mentioned in wp:PGM are also mentioned at wp:New pages patrol/Reviewers, despite not being discussed at all. Shouldn't it be fair to have the extendedmover userright be defined as privileged. ToadetteEdit (talk) 08:33, 23 December 2024 (UTC)[reply]
Support. Like SMcCandlish, I'd prefer that anyone, and particularly any editor with advanced perms, be allowed to turn on 2FA if they want (this is already an option on some social media platforms). But this is a good start, too.Since this is a proposal to allow page movers to opt in to 2FA, rather than a proposal to mandate 2FA for page movers, I see no downside in doing this. – Epicgenius (talk) 17:02, 23 December 2024 (UTC)[reply]
Support this opt-in for PMs and the broader idea of everyone having it by default. Forgive me if this sounds blunt, but is the responsibility and accountability of protecting your account lie on you and not WMF. Yes, they can assist in recovery, but the burden should not lie on them. ~/Bunnypranav:<ping>17:13, 23 December 2024 (UTC)[reply]
Photographs by Peter Klashorst
Back in 2023 I unsuccessfully nominated a group of nude photographs by Peter Klashorst for deletion on Commons. I was concerned that the people depicted might not have been of age or consented to publication. Klashorst described himself as a "painting sex-tourist"[24] because he would travel to third-world countries to have sex with women in brothels, and also paint pictures of them[25][26]. On his Flickr account, he posted various nude photographs of African and Asian women, some of which appear to have been taken without the subjects' knowledge. Over the years, other Commons contributors have raised concerns about the Klashorst photographs (e.g. [27][28][29]).
I noticed recently that several of the Klashorst images had disappeared from Commons but the deletions hadn't been logged. I believe this happens when the WMF takes an office action to remove files. I don't know for sure whether that's the case, or why only a small number of the photographs were removed this way.
My proposal is that we stop using nude or explicit photographs by Klashorst in all namespaces of the English Wikipedia. This would affect about thirty pages, including high-traffic anatomy articles such as Buttocks and Vulva. gnu5718:29, 16 December 2024 (UTC)[reply]
@Genericusername57: I disagree with JJPMaster in that this seems to be the right venue, but I also disagree with your proposal. Klashorst might have been a sleazeball, yes, but the images at the two listed articles do not show recognizable subjects, nor do they resemble “creepshots”, nor is there evidence they’re underage. If you object to his images you can nominate them on Commons. Your ‘23 mass nomination failed because it was extremely indiscriminate (i.e. it included a self portrait of the artist). Dronebogus (talk) 00:30, 17 December 2024 (UTC)[reply]
@Dronebogus: According to User:Lar, Commons users repeatedly contacted Klashorst, asking him to provide proof of age and consent for his models, but he did not do so. I am planning on renominating the photographs on Commons, and I think removing them from enwiki first will help avoid spurious c:COM:INUSE arguments. The self-portrait you are referring to also included another naked person. gnu5702:16, 17 December 2024 (UTC)[reply]
@Genericusername57: replacing the ones at vulva and buttocks wouldn’t be difficult; the first article arguably violates WP:ETHNICGALLERY and conflicts with human penis only showing a single image anyway. However I think it’s best if you went to those actual articles and discussed removing them. I don’t know what other pages use his images besides his own article but they should be dealt with separately. If you want to discuss banning his photos from Wikimedia in general that’s best discussed at Commons. In all cases my personal view is that regardless of whether they actually run afoul of any laws purging creepy, exploitative pornography of third-world women is no great loss. Dronebogus (talk) 01:16, 18 December 2024 (UTC)[reply]
I have to confess that I do not remember the details of the attempts to clarify things with Peter. If this turns out to be something upon which this decision might turn, I will try to do more research. But I’m afraid it’s lost in the mists of time. ++Lar: t/c01:25, 24 December 2024 (UTC)[reply]
Move the last edited notice from the bottom of the page to somewhere that's easier to find
Currently, if you want to check when the last page edit was, you have to look at the edit history or scroll all the way to the bottom of the page and look for it near the licensing info. I propose moving it under the view history and watch buttons, across from the standard "This article is from Wikipedia" disclaimer. Non-technical users may be put off by the behind-the-scenes nature of the page or simply not know of its existence. The Mobile site handles this quiet gracefully in my opinion. While it is still at the bottom of the page, it isn't found near Licensing talk and is a noticeable portion of the page Mgjertson (talk) 08:32, 17 December 2024 (UTC)[reply]
I wished Wikipedia supported wallpapers in pages...
It would be even more awesome if we could change the wallpaper of pages in Wikipedia. But the fonts' colors could change to adapt to the wallpaper. The button for that might look like this: Change wallpaperGnu779 (talk) 11:02, 21 December 2024 (UTC)[reply]
Toward helping readers understand what Wiki is/isn’t
I’ve often noticed confusion on the part of both general readers and editors about what Wikipedia articles are AND aren’t. Truth be told, I suspect all of us editors probably had it not only before becoming editors but also well into our Wiki work.
So I got thinking that perhaps a cute (but not overly so!) little information box that would fly in or otherwise attract attention upon accessing a new article could help halt some common misunderstandings or lack of awareness of general readers. Because I think most editors here at the Pump would be aware of many such examples, I hope you’ll forgive my not providing e.g.’s.
(Of course if such an info box were put in place, there’d also need to be a way for readers not to see it again if they so wish.)
I started to check elsewhere at the Pump to see if a similar idea had ever been submitted before, but I couldn’t figure out a relevant search term. And I didn’t want to suggest an outright proposal if anything similar had in fact ever been proposed. So IDEA LAB just seemed a good place to start the ball rolling. Looking forward to seeing where it leads. Augnablik (talk) 10:58, 17 November 2024 (UTC)[reply]
I'm a strong supporter of providing more information about how Wikipedia works for readers, especially if it helps them get more comfortable with the idea of editing. Readers are editors and editors are readers—this line should be intentionally blurred. I don't know if a pop up or anything similar to that is the right way to go, but I do think there's something worth considering here. One thing I've floated before was an information panel featured prominently on the main page that briefly explains how every reader is an editor and gives some basic resources. Thebiguglyalien (talk) 17:49, 17 November 2024 (UTC)[reply]
The problem with putting stuff on the main page is that many (probably most) readers get to Wikipedia articles from a search engine, rather than via the main page. Phil Bridger (talk) 17:57, 17 November 2024 (UTC)[reply]
The main page gets 4 to 5 million page views each day. And even so, I would guess that people who go out of their way to read the main page are better candidates to become frequent editors than people who treat Wikipedia like it's part of Google. Thebiguglyalien (talk) 15:12, 18 November 2024 (UTC)[reply]
I wasn't thinking of the main page. What I had in mind was that whenever someone requests to go to an article — irrespective of how he or she entered Wikipedia — the information box would fly in or otherwise appear. Augnablik (talk) 17:30, 18 November 2024 (UTC)[reply]
@Khajidha, i don't see the box as ONLY to dispel confusion but ALSO to point out some strengths of Wikipedia that probably readers wouldn't have been aware of.
A few things that came to my mind: although Wikipedia is now one of the world's most consulted information sources, articles should be considered works in progress because ... however, there are stringent requirements for articles to be published, including the use of strong sources to back up information and seasoned editors to eagle-eye them; writing that is objective and transparent about any connection between writers and subjects of articles ... and (this last could be controversial but I think it would be helpful for readers in academia) although not all universities and academic circles accept Wiki articles as references, they can serve as excellent pointers toward other sources.
if the idea of presenting an information box including the above (and more) is adopted, a project team could work on exactly what it would say and look like. Augnablik (talk) 18:58, 18 November 2024 (UTC)[reply]
I think that considerably overstates reality (the requirements are not stringent, sources do not have to be strong, many things are not checked by anyone, much less by seasoned editors, hiding COIs is moderately common...).
Ooops. Well, if stringent requirements, etc., overstate reality, then official Wiki guidance and many Teahouse discussions are needlessly scaring many a fledgling editor! 😱 Augnablik (talk) 19:40, 18 November 2024 (UTC)[reply]
All of these points also fall into the "well, DUH!" category. I did, however, want to respond to your statement that "not all universities and academic circles accept Wiki articles as references". I would be very surprised if any university or serious academic project would accept Wikipedia as a reference. Tertiary sources like encyclopedias have always been considered inappropriate at that level, as far as I know. --User:Khajidha (talk) (contributions) 19:38, 18 November 2024 (UTC)[reply]
Point taken about encyclopedias being generally unacceptable in academic writing.
But as we’re having this discussion in an idea lab, this is the perfect place to toss the ball back to you, Khajidha, and ask how you would describe Wikipedia for new readers so they know how it can be advantageous and how it can’t?
As I see it, that sort of information is a real need for those who consult Wikipedia — just as customers appreciate quick summaries or reviews of products they’re considering purchasing — to get a better handle on “what’s in it for me.” Augnablik (talk) 20:05, 18 November 2024 (UTC)[reply]
I think the logo at the top left already does a pretty good job: "Wikipedia: The Free Encyclopedia". Especially if you look at the expanded form we use elsewhere: "Welcome to Wikipedia, the free encyclopedia that anyone can edit."--User:Khajidha (talk) (contributions) 12:39, 19 November 2024 (UTC)[reply]
@Khajidha, a mere tag saying "The Free Encyclopedia" seems to me just a start in the right direction. The addition of "that anyone can edit" adds a little more specificity, although you didn't mention anything about writing as well as editing. Still, I think these tags are too vague as far as what readers need more insight about.
I'm working on a list of things I'd like to bring to readers' attention, but I'd like to put it away tonight and finish tomorrow. At that point, I'll humbly request you to "de-DUH" your evaluation of my idea. Augnablik (talk) 17:01, 20 November 2024 (UTC)[reply]
Seems to me the problem is that people don't understand what an encyclopedia is. That's a "them" problem, not an "us" problem. And what exactly do these readers think editing the encyclopedia would be that doesn't incude writing it? User:Khajidha (talk) (contributions) 17:45, 20 November 2024 (UTC)[reply]
Wikipedia is very different from the historical concept of encyclopedia. The open editing expands the pool of editors, at the expense of accuracy. -- Shmuel (Seymour J.) Metz Username:Chatul (talk)
Wikipedia may have put traditional general encyclopedias out of business, or at least made them change their business model drastically, but it does not define what an encyclopedia is. One example is that Wikipedia relies largely on secondary sources, but traditional encyclopedias, at least for the most important articles, employed subject matter experts who wrote largely on the basis of primary sources. It is our job to explain the difference. Phil Bridger (talk) 20:03, 20 November 2024 (UTC)[reply]
After a little longer gap between than what I thought it would take to create a list of things I believe all readers need to be aware of from the git-go about what Wikipedia is and isn't, due to some challenges in other departments of life, here's what I came up with. It would be in sections, similar to what you see below, each surrounded by a clip art loop, perhaps golden brown, and perhaps a few other pieces of clip art to set it off visually.I wish I knew how to separate paragraphs with line spacing ... I know this looks a little squished.
_____________________________________
New to reading Wikipedia articles? Here are some helpful things for you to be aware of about Wikipedia. They'll help you get more clearer ideas of how you can use the articles to best advantage.
If you'd like to go into more depth about all this, and more, just go to the article in Wikipedia about itself by typing WIKIPEDIA in the Wikipedia search field.
Wikipedia is a different kind of encyclopedia.
— Its articles can be written and edited by anyone.
— They’re supposed to be based completely on reliable outside sources.
— They can be updated at any time, thus allowing for quick corrections or additions if needed.
— Wikipedia is free.
That’s the main difference between Wikipedia and traditional encyclopedias.
BUT:
All encyclopedias serve as starting points where readers can find out about information — especially the main thinking about particular subjects — then follow up as they wish.
Students and researchers: keep in mind that schools and professional research journals don’t accept encyclopedias as references for written papers, but do encourage using them to get some ideas with which to go forward.
Wikipedia has become popular for good reason.
— Wikipedia is the world’s largest-ever encyclopedia.
— It’s consistently ranked among the ten websites people visit most.
— Because it’s all online, it’s easy to access.
— Because it’s highly interactive, it’s easy to move around from topic to topic.
Quality standards for writing articles are in place and in action behind the scenes.
— Wikipedia has high standards for choosing the subjects of articles.
— Wikipedia also has high standards for writing articles, especially freedom from bias.
— Certain editors are assigned to ensure that articles follow Wikipedia standards.
— Although differences of opinions naturally arise about whether a particular article does so, there are sets of procedures to work them out and arbiters to step in as needed. Augnablik (talk) 10:18, 25 November 2024 (UTC)[reply]
Why would you put information about "reading Wikipedia articles" in an editing environment?
Also, several things you've written are just wrong. Wikipedia is not considered a "highly interactive" website. "Certain editors" are not "assigned to ensure" anything. Wikipedia does not have "high standards for writing articles", and quite a lot of readers and editors think we're seriously failing in the "freedom from bias" problem. We might do okay-ish on some subjects (e.g., US political elections) but we do fairly poorly on other subjects (e.g., acknowledging the existence of any POV that isn't widely discussed in English-language sources). WhatamIdoing (talk) 20:14, 28 November 2024 (UTC)[reply]
Actually, I think a more magnetic format for this tool I'm hoping can one day be used on Wikipedia would be a short series of animated "fly-ins" rather than a static series of points with a loop around each set thereof. Augnablik (talk) 13:51, 25 November 2024 (UTC)[reply]
@Augnablik, personally, I think your idea would be great and would help bring new editors to the project, especially with these messages, which seem more focused on article maintenance (more important nowadays imo) than article creation.
as unfortunate as it is, people are generally not that smart. Considering the number of people I've had to explain the concept of editing wikipedia to, I'd be shocked if most people know how wikipedia works and what it isn't Mgjertson (talk) 08:44, 17 December 2024 (UTC)[reply]
It’s exactly because it does seem to take a lot for some people to get the idea that I‘m convinced something can be done about that when readers first come to Wikipedia. Something catchy and animated, in contrast to “chapter and verse.”
Because I had such high hopes of being on the trail of something practical to help prevent some of the main misunderstandings with which readers come to Wikipedia — and at the same time to foster awareness of how to use it to better advantage — I wonder if a little spark could get the discussion going again. Or does the idea not seem worth pursuing further? Augnablik (talk) 11:05, 30 November 2024 (UTC)[reply]
I hope you won't be disheartened by this experience, and if you have any other good ideas will share them with us. There are two stages to getting an idea implemented in a volunteEr organisation:
Getting others to accept that it is a good idea.
Persuading someone to implement it.
You have got past stage 1 with me, and maybe others, but I'm afraid that, even if I knew how to implement it, it wouldn't be near the top of my list of priorities. Phil Bridger (talk) 09:17, 3 December 2024 (UTC)[reply]
Thank you, Phil. No, not disheartened … I think of it as an idea whose time has not yet come. I’m in full agreement about the two stages of idea implementation, plus a couple more in between to lead from one to the other.
When we in the creative fields recognize that continuum and get our egos out of the way, great things begin to happen. Mine is hopefully drying out on the line.😅 Augnablik (talk) 09:41, 3 December 2024 (UTC)[reply]
New users, lack of citation on significant expansion popup confirmation before publishing
There are many edits often made where a large amount of information is added without citations. For new users, wouldn't it be good if it was detected when they go to publish an edit lacking citations with a large amount of text, and came up with a popup of some sort directing them to WP:NOR, and asking them to confirm if they wish to make the edit? I think you should be able to then turn it off easily (as in ticking don't remind me again within the popup), but my impression is that many make edits without being familiar with the concept of rules such as WP:NOR. 𝙏𝙚𝙧𝙧𝙖𝙞𝙣𝙢𝙖𝙣地形人 (talk) 01:36, 19 November 2024 (UTC)[reply]
If I'm thinking of the right tool, there was a discussion (at one one of the village pumps I think) that saw significant opposition to deployment here, although I can't immediately find it. I seem to remember the opposition was a combination of errors and it being bundled with VE? I think Fram and WhatamIdoing were vocal in that discussion so may remember where it was (or alternatively what I'm mixing it up with). Thryduulf (talk) 15:21, 19 November 2024 (UTC)[reply]
@Aaron Liu, Edit check is available on the visual editor. Having it on wikitext won't make sense as the goal is to teach users to add citations, not to teach them both about citations and wikitext. Let's reduce complexity. :)
And the visual editor is still not the default editor at de.wp or en.wp. I advised to work on deploying both in parallel so that newcomers would have a better editing experience all at once (less wikitext, more guidance). Why am I not working on it now? Because it would take time. Now that the visual editor was used for years at all other wikis to make millions of edits, we should consider making it the default editor at English Wikipedia for new accounts. It could be a progressive deployment. I've not yet explored past reasons why English Wikipedia didn't wanted to have the visual editor being deployed, again for time reasons. But we would support any community initiative regarding VE deployment for sure.
We could deploy Edit check without VE, but I'm afraid of a low impact on newcomers: they are less likely to be helped as long as VE remains the second editor.
@Thryduulf, there were a discussion about Edit check in the past, you are correct. It covered multiple topics actually. I let you re-read it if you like; I didn't found "significant opposition" there, more questions about Edit Check, VE, citations and more, concerns on Edit Check and VE integration, and support for a better experience for newcomers (as long as it doesn't impact existing personal experiences).
If you didn't see "significant oppo sition" there, then perhaps reread it? The tool you deployed elsewhere had no measurable positive impact (when tested on Simple or French Wikipedia). As for past reasons why enwiki didn't want VE deployed, let's give you one: because when VE was deployed here, it was extremely buggy (as in, making most articles worse when used, not better), but the WMF refused to undo their installation here (despite previous assurances) and used enwiki as a testing ground, wasting tons of editor hours and creating lots of frustration and distrust towards the WMF. This was only strengthened by later issues (Flow, Gather, Wikidata short descriptions) which all followed the same pattern, although in those cases we eventually, after lots of acrimonious debates and broken WMF promises, succeeded in getting them shut down). As shown in the linked discussion, here again we have two instances of WMF deployments supported by test results where in the first instance reality showed that these were probably fabricated or completely misunderstood, as in reality the results were disastrous; and in the second instance, Edit Check, reality showed that the tool wasn't an improvement over the current situation, but even when spelled out this was "misread" by the WMF. Please stop it. Fram (talk) 15:50, 19 November 2024 (UTC)[reply]
Could you provide a couple of links to comments from people other than yourself, and which specifically opposed EditCheck (not the 'make the visual editor the default' or 'Citoid has some problems' sub-threads)? I just skimmed through the 81 comments from 19 editors in the proposal that Robertsky made, and while I might have missed something, your first comment, which was the 69th comment in the list, was the first one to oppose the idea of using software to recommend that new editors add more citations.
Most of the discussion is not about EditCheck or encouraging refs. Most of it is about whether first-time editors should be put straight into the visual editor vs asking them to choose. The responses there begin this way:
"I thought Visual Editor is already the default for new accounts and unregistered editors?" [30]
"In theory, this sounds like a great idea. I'm eager to try it out..." [31]
"I'd support making Visual Editor the default..." [32]
"I totally agree that VE should be the default for new users." [34]
which is mostly not about whether to use software to encourage newbies to add more citations (the second quotation is directly about EditCheck; not quoted are comments, including mine, about whether it's technically necessary to make the visual editor 'the default' before deploying EditCheck [answer: no]).
Then the thread shifts to @Chipmunkdavis wanting the citation templates to have "an easily accessed and obvious use of an |author= field, instead forcing all authors into |last and |first", which is about how the English Wikipedia chooses to organize its CS1 templates, and @Thryduulf wanting automatic ref names that are "human-friendly" (to take the wording RoySmith used), both of which entirely unrelated to whether to use software to encourage new editors to add more citations.
I see some opposition to putting new editors into the visual editor, and I see lots of complaints about automated refs, but I don't see any opposition from anyone except you to EditCheck itself. Please provide a couple of examples, so I can see what I missed? WhatamIdoing (talk) 17:57, 19 November 2024 (UTC)[reply]
"which is about how the English Wikipedia chooses to organize its CS1 templates" is perhaps one way to say that the VE has no functionality to accept the synonyms, which I discovered in a few disparate conversations following that thread. I still have a tab open to remind me to put a note about phab on this, it's really not ideal have VE editors shackled with the inability to properly record author names. CMD (talk) 01:42, 20 November 2024 (UTC)[reply]
VisualEditor is perfectly capable of accepting actual aliases such as |author=, and even non-existent parameters such as |fljstu249= if you want (though I believe the citation templates, unlike most templates, will emit error messages for unknown parameters). It just isn't going to "suggest" them when the CS1 maintainers have told it not to do so. WhatamIdoing (talk) 05:12, 20 November 2024 (UTC)[reply]
If you know how to solve the problem, please solve the problem. Per Help talk:Citation Style 1/Archive 95, "The solution to the ve-can't/won't-use-already-existing-alias-list problem lies with MediaWiki, not with editors adding yet more parameters to TemplateData". As it stands, VE doesn't do it, and I've seen no indication that they consider it an issue. CMD (talk) 12:00, 20 November 2024 (UTC)[reply]
If you want this wikitext:
{{cite news |author=Alice Expert |date=November 20, 2024 |title=This is the title of my news story |work=The Daily Whatever}}
which will produce this citation:
Alice Expert (November 20, 2024). "This is the title of my news story". The Daily Whatever.
then (a) I just did that in the Reply tool's visual mode, so it obviously can be done without any further coding in MediaWiki, VisualEditor, or anything else, and (b) you need to convince editors that they want "Alice Expert" at the start instead of "Expert, Alice" of citations. WhatamIdoing (talk) 21:07, 20 November 2024 (UTC)[reply]
No, I don't have to convince editors that they want "Alice Expert" instead of "Expert, Alice". The issue is, as covered in the original discussion with some good input from others, non-western name formats. It is a cultural blindspot to assume all names fall into "Expert, Alice" configurations, and it seems that it is a blindspot perpetuated by the current VE expectations. CMD (talk) 01:39, 21 November 2024 (UTC)[reply]
@Chipmunkdavis, I guess I'm having trouble understanding what you want.
You said in the linked discussion that "My understanding is that the VE tool does not allow for the use of aliases". I'm telling you: Your understanding is wrong. It's obviously possible to get |author= in the visual editor, because I did that. Either this diff is a lie, or your understanding is mistaken. I'm going with the latter. |author=Mononym is already possible. So what change are you actually asking for?
The linked discussion seems, to my eyes, to be a long list of people telling you that if you don't like the description used in the TemplateData (NB: not MediaWiki and not VisualEditor), then you should change the description in the TemplateData (NB: not MediaWiki and not VisualEditor) yourself. You say the devs told you that, and I count at least two other tech-savvy editors who told you to WP:SOFIXIT already. Neither the part that says "Last name" nor the part that says "The surname of the author; don't wikilink, use 'author-link'; can suffix with a numeral to add additional authors" is part of either the visual editor or MediaWiki. Any editor who can edit Template:Cite news/doc can change those words to anything they want. WhatamIdoing (talk) 20:22, 21 November 2024 (UTC)[reply]
Having to type source wikitext completely defeats the purpose of the visual editor; why not just type in the wikitext editor. This "solution" is a blaring technicality.Perhaps you should read the last four replies in the linked discussion. Aaron Liu (talk) 00:00, 22 November 2024 (UTC)[reply]
Right, this is the sort of odd reply this topic inexplicably gets. You can just type in source code in the visual editor, I mean, why have visual editor at all. Just change the description so people can pretend someone's name is their last name, now being suggested yet again as a simple SOFIXIT, and no I'm not going to deliberately and formally codify that we should mislabel people's names, for what I did think before these various discussions were obvious reasons. CMD (talk) 02:08, 22 November 2024 (UTC)[reply]
If I type |author=Sting vs |last=Sting, will this make any difference to anyone (human or machine) that ►is not looking at the wikitext. That last bit about not seeing the wikitext is the most important part. If the complaint is entirely about what's in the wikitext, then Wikipedia editors should treat it as the equivalent of a whitespacing 'problem': it's okay to clean it up to your preferred style if you're otherwise doing something useful, but it's not okay to force your preferred style on others just for the sake of having it be 'the right way'.
The options are:
Those two are used as exact synonyms by the CS1 code, in which case it make no practical difference which alias is used, or
Those two are handled differently by the CS1 code (e.g. emitting different microformatting information), in which case the CS1 code should not declare them to be aliases. AIUI aliases are only supposed to be used for exact substitutes.
Misnaming someone is not a style choice. (It is literally an item explicitly mentioned in the UCOC.) Even if it wasn't, your professed solution is that a new editor open up the visual editor and see "Last name: The surname of the author; don't wikilink, use 'author-link' instead; can suffix with a numeral to add additional authors. Please also use this field for names which don't have a first name last name structure."? That doesn't seem sensible or effective. CMD (talk) 00:12, 29 November 2024 (UTC)[reply]
Where does the "misnaming" happen? To be clear, I'm expecting an answer that either sounds like one of these two:
"Only in the wikitext, but that's still very bad".
"In a reader/user-facing location, namely _____" (where the blank might be filled in with something like "in the COinS microformatting").
I would refer to the previous discussions above and elsewhere where it has already been extensively covered that both of those options are true. It would in the wikitext, and is currently in the visual editor citation creator. CMD (talk) 08:34, 30 November 2024 (UTC)[reply]
"Both of those options are true" is not possible, when you name as the two locations:
a place readersdo not see ("in the wikitext") and
another place readers do not see ("in the visual editor citation creator").
It feels deeply uncivil to say "So again" for a question you haven't asked before. It is really surprising to see "misnaming" quoted as if it's something incorrect; it's hard to word this but that comes off as a shocking level of continued cultural insensitivity. At this point the various questions at hand have been answered multiple times in the different discussions, and we're wandering again towards odd red herrings that have little relation to the fact that VE source generator users are forced into a single naming system, something long solved by the non-VE source generator. I recommend the link RoySmith provided in the previous discussions if you haven't already[35], and remain hopeful one day that others will try to care about the non Alice Experts of the world. CMD (talk) 02:13, 1 December 2024 (UTC)[reply]
Sorry, I thought I had already been quite clear about that point:
This is coming off as deliberately obtuse. The issue is for the person using the visual editor, the new editors we are trying to cultivate. CMD (talk) 15:58, 13 December 2024 (UTC)[reply]
People using the visual editor's template editor never see |last= on the CS1 templates. That is only visible to people using wikitext.
People using the visual editor's template editing tools see the locally defined TemplateData label "Last name", which CMD is free to change at any time to anything he can get consensus for, e.g., "Last name, sole name, or non-Western style name". WhatamIdoing (talk) 00:44, 4 December 2024 (UTC)[reply]
So we want text that is defined in TemplateData to say something different, but the method of changing that must not involve changing the text that is defined in TemplateData.
It's an eminently solvable problem, the radio button idea has already been raised. Just takes a bit of actually thinking getting people's name's right is an issue, and not changing the actual question at hand. CMD (talk) 15:57, 13 December 2024 (UTC)[reply]
1. How did you do that? 2. The author parameter is useful and used iff the author has no last name; e.g., byline being an organization, mononymous person, no author stated, etc. This is documented at the citation-style help pages. Aaron Liu (talk) 22:11, 20 November 2024 (UTC)[reply]
The |author= parameter behaves the same as the |last= parameter, so there's little point in changing the wikitext to say |author=.
(In this case, I took the quick and dirty approach of typing out the template by hand, and pasting it in. The Reply tool's visual mode normally won't let you insert a template at all, because block-formatted templates completely screw up the discussion format. Normally, if there's no TemplateData to provide you with the options, then you'd click on the "+Add undocumented parameter" button and type in whatever you wanted. If there is TemplateData, then see my earlier comment that "It just isn't going to "suggest" them when the CS1 maintainers have told it not to do so.") WhatamIdoing (talk) 23:08, 20 November 2024 (UTC)[reply]
It's semantically different, like the em tag vs italicizing and whatnot. And as I've said before, the documentation doesn't suggest it so that the clueless will not use both |last and |author. Aaron Liu (talk) 23:57, 20 November 2024 (UTC)[reply]
If someone adds |authorn= as a separate parameter, I fear that we will see an increase in the number of articles that populate Category:CS1 errors: redundant parameter because OMG!-there's-an-empty-box-in-the-form;-I-must-fill-it. This is why I suggested radio buttons for aliases; something that MediaWiki would needs implement.
You missed that none of them tested it or checked it on other wikipedia versions, and that no support came along after I had tested it and posted my results? No surprise here... Fram (talk) 19:17, 19 November 2024 (UTC)[reply]
There's a big gap between "The discussion stopped" and "There was significant opposition in this discussion".
In terms of EditCheck, I found most of the discussion to be off-topic, but I can honestly only find one editor (you) who opposed it in that discussion. I assume your failure to provide links to any other statement of opposition means you also honestly can't find a single comment in that discussion from anyone who agreed with you – just an absence of further comments, and an unprovable assumption on your part that its due to everyone agreeing with you. WhatamIdoing (talk) 19:28, 19 November 2024 (UTC)[reply]
Didn't stop you from making any assumptions or presentings things in the most WMF-favorable light. Seems like VE all over again, only then you had the excuse of being paid by the WMF. Fram (talk) 19:45, 19 November 2024 (UTC)[reply]
I don't think I presented the discussion in the most WMF-favorable light. The discussion started off pretty enthusiastic, but it was mostly enthusiastic about something other than EditCheck itself. It then turned into a long digression into something completely unrelated.
(My own contributions to that discussion were technical in nature: It doesn't require the visual editor as the default; code may already exist for an unrelated change that someone wants; stats may already exist for something close to the numbers someone else wants.) WhatamIdoing (talk) 19:56, 19 November 2024 (UTC)[reply]
(ec) Fram, this is precisely because I reread the conversation that I wrote my previous message. We have the right to disagree, but it should remain civil and not convey accusations of bad faith. The way you try to depict me as a dishonest person is not acceptable at all.
I let other participants have a look at the previous discussion we linked, also take a look at the data we provided, and make their own opinion. We aren't the two people who will decide of a deployment here: I'm just the messenger, and you are not the person who has the final word on behalf of everyone. Trizek_(WMF) (talk) 18:00, 19 November 2024 (UTC)[reply]
Tough luck. You posted a dishonest reply last time we had this discussion. If it had been a genuine error in that previous discussion, you should have just said so. Instead, you not only let your error stand, but then come here and claim that there was no significant opposition to Edit Check in that previous discussion, ignoring the one person who tested it and posted results. And like I said in that discussion, the data the WMF provides is not to be trusted at all, as seen from other deployments. Which I already stated and you again ignore completely. But, like I said, the WMF (and previous WMF employees like Whatamidoing) are very good at civil bullshit, while I am not so good at the civil part but rather good at cutting through the bullshit. Fram (talk) 19:17, 19 November 2024 (UTC)[reply]
Since there are non-native English speakers in this discussion, I'd like to clarify that "dishonest", in English, means that the person deliberately told the opposite of the truth. For example, it is dishonest to say "I love Windows ME", when you actually hate it.
However:
Having incorrect or outdated information is not "dishonest".
Caring about a particular benefit more than a different problem is not "dishonest".
Disagreeing with you, or with a hypothetical average reasonable person, is not "dishonest".
There's a reason that English has an idiom about an "honest mistake": It's because it's possible to be factually wrong without being dishonest. For example, if you say "Oh, User:Example said something yesterday", but upon further inspection, it was a different user, or a different day. Or even if you say "The previous discussion shows significant opposition to EditCheck", but upon further inspection, nobody except you publicly opposed it. Such a sentence is only dishonest if the speaker believes, at the time of speaking, that the statement is factually wrong. Unless the speaker believes themselves to be speaking falsehoods, it's not actually dishonest; it's only a mistake or an error.
"Using someone's affiliations as an ad hominem means of dismissing or discrediting their views" – Claiming, or even implying, that WMF staff have a tendency to be dishonest is probably a violation of this point in the policy.
"Insulting or disparaging an editor is a personal attack regardless of the manner in which it is done." – Claiming that anyone is "dishonest", especially when the difference between your view and theirs is a matter of opinion, is very likely a violation of this policy. It doesn't officially matter if the manner in which you say this is "you are dishonest" or "your replies are dishonest"; it's still insulting and disparaging another editor.
Like I said, one can post all distruths one wants as long as one does it civilly. Reminds me of the discussions we had about VE when it was disastrously deployed but all you did as a liaison was defend the WMF no matter what. And I didn't say their replies were dishonest because they are a WMF employee, just that it is typical behaviour for many of them apparently. Perhaps reread the breakdown of the Gather discussions I gave below, or reread the countless discussions about Flow, VE, descriptions, ... There are some good apples among them, but not too many. Fram (talk) 19:51, 19 November 2024 (UTC)[reply]
2013, not 2023. July was early days in VE testing, when I still thought you were helpful. A few months later I had become wiser. Fram (talk) 20:20, 19 November 2024 (UTC)[reply]
For what its worth, I do think a RfC can be made once the proposed details of the deployment is firmed up:
Do we make VE as the default for new editors?
Do we enable EditCheck as it is?
Current pop-up for new editorsAside, if we retain the current arrangement, i.e. letting new/anon editors selecting their preferred editor, can we change the buttons to be more balanced in colours and sizing? These do affect one's preference in choosing which button to click. – robertsky (talk) 18:16, 19 November 2024 (UTC)[reply]
robertsky, that's two RFCs, and – respectfully – conflating the two questions was a primary contributor to how far off the rails this conversation got last time.The UX alterations are probably best brought up at meta or mw for the skins devs to consider. Folly Mox (talk) 18:55, 19 November 2024 (UTC)[reply]
Gather was dropped after 3 months (without any "broken WMF promises" nor any time for them to have given such promises or to have acrimoniously debated), and Wikidata SDs seem to be deployed and working completely fine. Aaron Liu (talk) 18:25, 19 November 2024 (UTC)[reply]
Gather was deployed in March 2015 and immediately got severe backlash at the announcement: Wikipedia:Administrators' noticeboard/Archive270#Extension:Gather launching on beta. No good answers followed. So three weeks later we get Wikipedia:Administrators' noticeboard/Archive270#Moderation of Collections?, where we get (laughable) promises of what the WMF will do to solve some of the most basic problems of this tool they rolled out on enwiki but hadn't really thought about at all it seems. Instead, they created a new Flow page on enwiki for this tool (Wikipedia:Miscellany for deletion/Wikipedia:Gather/User Feedback) despite Flow being removed from enwiki long before this. So in January 2016 (hey, that's already 10 months, not 3), Wikipedia:Village pump (proposals)/Archive 130#Disabling Gather? was started. On 22 Januuary 2016, an answer was promised by the WMF "next week" (section "A WMF reply next week"): "by next week, the Gather team will have a major update to share about the feature". Things escalated, so another WMF person came along 6 days later to promise "we will be putting together this analysis starting now with the intention of sharing publicly next week with a decision the week after." (section "A Response from the WMF"). So instead of some great announcement after 1 week, we are now 6 days further and will get big news 2 weeks later... So, more than 2 weeks later, 12 February, we get "the analysis has taken longer than I anticipated. I'll post the results as soon as I can." So, on the 19th, they posted a "proposal" to which others replied "that proposal is an insult to the community." and "his smacks of yet more stalling tactics and an attempt to save face". Only when the RfC was closed with truly overwhelming supprt to disable it did they finally relent.
Do you really need a similar runthrough of Wikidata short descriptions, which are (or should be) disabled everywhere on enwiki and replaced by local descriptions instead? Or will you admit that perhaps you didn't remember details correctly? Fram (talk) 19:41, 19 November 2024 (UTC)[reply]
Yeah man I don't remember anything well, I wasn't there. I'm just reading random things I can find to see what you're talking about, such as the MediaWiki page that states development was suspended by July 2015, but as you've pointed out, that is different from disabling, and thank you for helping me to find. Thanks for your links on Gather. By no fault of its own, Shortdesc helper made me conflate WD descriptions and SDs. Aaron Liu (talk) 20:42, 19 November 2024 (UTC)[reply]
I never suggested deploying it on the source editor. Having not fully read the above discussion yet, it currently seems unreasonable that it's not deployed in the visual editor on enwiki and dewiki (while preserving the current "level of defaultness" of the visual editor itself instead of increasing the defaultness). Aaron Liu (talk) 16:30, 19 November 2024 (UTC)[reply]
@Aaron Liu, I never implied you suggested it, I was just one step ahead telling you that it is not available on source editor. :) We can deploy Edit check without changing the "level of defaultness" of the visual editor itself, but the impact might not be the same. Trizek_(WMF) (talk) 18:09, 19 November 2024 (UTC)[reply]
(ec) Probably Wikipedia:Village pump (proposals)/Archive_213#Deploying_Edit Check on this wiki. Having reread that thread, it combines all WMF rollout issues into one it seems, from starting with false requirements over a testing environment which isn't up-to-date at all to completely misreading everything that is said into something supposedly positive, ignoring the stuff that contradicts their "this must be pushed no matter what" view. But all in a very civil way, there's that I suppose... Fram (talk) 15:39, 19 November 2024 (UTC)[reply]
What an utterly weird objective for that tool "Newcomers and Junior Contributors from Sub-Saharan Africa will feel safe and confident enough while editing to publish changes they are proud of and that experienced volunteers consider useful." Very neocolonial. Fram (talk) 15:25, 19 November 2024 (UTC)[reply]
Different parts of the world have different responses to UX changes. A change that is encouraging in a high-resource setting (or an individualistic culture, or various other things) may be discouraging in others. It is therefore important to test different regions separately. The Editing team, with the strong encouragement of several affiliates, decided to test sub-Saharan Africa first. WhatamIdoing (talk) 19:50, 19 November 2024 (UTC)[reply]
I can't help it if you don't see how insulting and patronizing it is to write "Junior Contributors from Sub-Saharan Africa will feel safe and confident enough while editing". Fram (talk) 20:26, 19 November 2024 (UTC)[reply]
Redone my check at Simple wiki, looking at the most recent edits which automatically triggered this tool[36]. 39 instances were automatically indicated as "declined", the other 11 contain 3 edits which don't add a reference anyway[37][38][39] and 6 edits which actually add a reference[40][41][42][43][44][45] (though 3 of these 6 are fandom, youtube and enwiki). And then there is this and this, which technically add a source as well I suppose... Still, 3 probably good ones, 3 probably good faith bad ones, 3 false positives, and 2 vandal ref additions. Amazingly, this is almost the exact same result as during the previous discussion[46]. Fram (talk) 16:21, 19 November 2024 (UTC)[reply]
I think just creating one good source addition is enough cause for deployment (without making VE the default editor), especially since it doesn't appear to be causing additional harm. Aaron Liu (talk) 16:59, 19 November 2024 (UTC)[reply]
If it doesn't create more good source additions than we had before the tool, then there is no reason to deploy something which adds a popup which people usually don't use anyway. Without the popup, there also were new editors adding sources, it's not as if we came from zero. No benefit + additional "noise" for new editors => additional harm. Fram (talk) 17:10, 19 November 2024 (UTC)[reply]
I'm not sure what that has to do with my reply. Fram was disputing that the source additions were good and useful, and I was replying to him that some of them were good, hence edit check should be deployed (plus I'm fairly sure there's another check in the works to check reference URLs against the local RSP) Aaron Liu (talk) 18:21, 19 November 2024 (UTC)[reply]
What you observed (Editors who got a popup did not originally give a source when attempting to publish) is shown in the data we shared.
We already deployed checks to verify if a link added is not listed in rejection lists and make it more actionable by newcomers. Some users at other wikis expressed a need to have a list of accepted links (the ones that match RSP), but other said that it could prevent new good sources from being added. Thoughts?
Isn't that the programmed heuristic for when the popup appears? I don't get what this has to do with any stats.Only URLs in the spamlist are blocked. Edit check should strongly warn against adding sources found generally unreliable by consensus summarized at RSP. Aaron Liu (talk) 18:59, 19 November 2024 (UTC)[reply]
I'm not sure to understand, sorry. Stats are about users adding a citation when asked compared from where not asked. It is not connected to RSP.
Like I said, of the 11 supposed additions, 5 need reverting (as far as the source goes) and 3 didn't add a source. I don't trust WMF numbers at all, but 5/8 needing a revert is hardly an overwhelming success. Even assuming that the 3 good ones wouldn't have added a source otherwise, one then has to make the same conclusion for the others, and the 5 bad ones wouldn't have been included otherwise either. So where is the net benefit and the no harm? Fram (talk) 19:54, 19 November 2024 (UTC)[reply]
I don't trust WMF numbers at all
I'm new to all this, could you elaborate on why?
the 5 bad ones wouldn't have been included otherwise either
The 5 bad ones would have included no source at all if Edit Check wasn't there. I don't see how adding a blatantly terrible source is worse than adding text without a source at all. Both are checked the exact same way: eye-scanning. So there you go, net benefit and no harm. Aaron Liu (talk) 20:11, 19 November 2024 (UTC)[reply]
No. I explained it already in the previous discussion. You have made false claims about Gather and so on, but can't be bothered to reply when I take the time to give a detailed answer; but now you are apparently "new to all this" suddenly and want me to again take some time to enlighten you. No. And an unsourced statement is obvious to see, a statement sourced to a bad source is much less obvious. Fram (talk) 20:24, 19 November 2024 (UTC)[reply]
@Aaron Liu, I think this is a "reasonable people can disagree" thing. Some RecentChanges patrollers just revert any new unsourced claim, so if it's unsourced, it's quick to get out of the queue. Faster reverting means success to them, whereas encouraging people to add sources is like whispering a reminder to someone during a game of Mother, May I?: It removes an easy 'win' for the reverter.
OTOH, having a source attached to bad information has other advantages. It's easy to determine whether it's a copyvio if you have the source, and if you're looking at an article you know something about (e.g., your own watchlist rather than the flood in Special:RecentChanges), then having the source often means that you can evaluate it that much faster ("This is a superficially plausible claim, but I wouldn't trust that website if it said the Sun usually rises in the East").
For content that shouldn't be reverted, then IMO encouraging a source is always a good thing. For content that should be reverted, there are tradeoffs. WhatamIdoing (talk) 21:22, 19 November 2024 (UTC)[reply]
I miss things, especially on a workday. Sorry about that. I think the mobile short-descriptions thing is believable, as users . This is a case of the methodology being technically correct but misleading, which I don't see for the edit check study, unless you're willing to provide an argument.
an unsourced statement is obvious to see, a statement sourced to a bad source is much less obvious.
IMO, only slightly. Often, only users of experience patrol pages when reading them. (The unacquainted are also sometimes able to realize something's probably wrong with a swath of unsourced text, hence they make up part of the aforementioned "slightly".) And blatantly bad sources jump out to those experienced from the references section. Sources in the middle ground can often link to good sources, though there is a debate on how good it is to have both additionally middle-ground and bad sources vs. no sources at all. Personally, I think it's better. Aaron Liu (talk) 21:47, 19 November 2024 (UTC)[reply]
Given that there are several editors here interested in the feature turning on, I would like to propose the following question and a brief/neutral backgrounder to be asked for the RfC:
Background: Edit Check is Wikimedia Foundation's product to encourage new editors to add citations to their edits, by prompting them with pop-ups before publishing. The pop-ups will work under the following default conditions (points 2 - 4 can be configured further):
If editing is done through Visual Editor.
≥40 consecutive characters added.
All accounts with < 100 edits
All sections*
For point 4, I also propose to modify the configuration to exclude this feature from the following sections:
lead section, as we don't not require leads to have citations
Notes section, usually handled by {{efn}} in content body, etc.
References section, no citation required
External links section, no citation required
See also section, no citation required
Further reading section, no citation required (thanks, Chipmunkdavis)
And any other sections (that I have missed out, and in the future) that do not require citations.
For future changes of the configuration setting, this can be done on wiki through modifying MediaWiki:Editcheck-config.json file after discussing in an appropriate venue. This also means that other than the initial activation, we do not require further changes in the backend (and if we would want to rollback before deactivating in a server update, we can set the max edit count to 1 as a temporary measure).
@Robertsky, all is correct. Also, at the moment, Edit check has not been integrated to Community Configuration but, as you mention, the json file attached to Edit check allows your community to decide on de/activation. Trizek_(WMF) (talk) 09:11, 2 December 2024 (UTC)[reply]
Further reading section. Idly thinking, is the 100 edits namespace configurable? Further, just to check, "≥40 consecutive characters added." means "≥40 consecutive characters added without a ref tag" or similar? CMD (talk) 09:24, 2 December 2024 (UTC)[reply]
The 100 edits is not namespace configurable. From the codes, it is checked against wgUserEditCount JavaScript variable. There is no JavaScript variable(s) for breakdown of edit counts by namespace at the moment, going by this documentation.
I think a page informing the readers of Wikipedia features would be helpful, since the public largely do not know much about Wikipedia's backend even though billions visit this site. Topics featured can be looking a page history, talk page discussions, WP:Who Wrote That?, etc. I imagine it woule be placed under the Today's featured picture, since we want to showcase quality work first. I've made a demo here: User:Ca/sadbox. Catalk to me!13:11, 29 November 2024 (UTC)[reply]
Looks good. And it's fine if we recycle them fairly rapidly, since these are things can be easily reused – in fact, I suggest cycling this weekly instead of daily. Cremastra ‹ u — c › 15:56, 29 November 2024 (UTC)[reply]
The Main Page is deliberately aimed at readers, not editors. Its purpose is to direct readers to interesting encyclopaedic content, not show them how to edit pages. The Main Page is also very full already, so adding anything would require removing something else. I think it's highly unlikely that this idea would achieve consensus at T:MP. However I'm sure there's a place for something like this in Wikipedia: space. Modest Geniustalk12:42, 3 December 2024 (UTC)[reply]
To be fair, the whole point of Wikipedia is that readers are potential editors. Helping readers take that step would definitely help us keep a steady, or even growing, user base. Chaotic Enby (talk · contribs) 12:52, 3 December 2024 (UTC)[reply]
I am not sure what you mean by The Main Page is also very full. There isn't a size limit to Internet pages? In any case, I want the content of the tips to be reader-focused, not editor-focused. Things like creating an account to change website display, identifying who-wrote-what, etc. Catalk to me!13:14, 3 December 2024 (UTC)[reply]
This is perfect! It seems like people already done the work for me. However, there is some need to retheme the banner so that it fits in with the rest of the main page. Catalk to me!23:49, 4 December 2024 (UTC)[reply]
Cannot get enough of Wikipedia? Then join our mailing lists! A mailing list is a shared address for a list of recipients. Anyone subscribed to the list can send e-mail to that address and thereby reach all other subscribers. This is a convenient way to discuss complex issues with multiple people. There is a WikiEN-l list which is used for discussing policies and current issues related to the English Wikipedia, and there is Wikipedia-l for language-independent discussions. If you want to help developing MediaWiki, join Wikitech-l and share your ideas. For a complete list see m:Mailing lists.
To add this auto-updating template to your user page, use {{totd}}
I think the OP's plan is a terrific idea. The vast majority of readers never even think about actually editing a page (despite the ubiquitous edit links). Having a big, NOTICEABLE "tip of the day" seems a great way of changing this.
An example of a good place for this would be just above "In the News", to the right of "Welcome to Wikipedia", about two inches wide and one inch high. Obviously just one possibility out of many.
But just having another small link to some variation of Help:How to edit seems futile and unnecessary.
I would strongly recommend having a two-week trial of the OP's suggestion, and then check the metrics to see whether to continue or not. ———ypn^221:33, 4 December 2024 (UTC)[reply]
Considering that I think most other of the WMF projects have something on their main page about contributing, there is a distinct lack of it on en.wiki. This could be a page spanning box with the usual links of how to get started along with the top of the day floating right in that box. Whether that box leads or ends the page is of debate but it would make sense to have something for that. Masem (t) 00:03, 5 December 2024 (UTC)[reply]
Concur. I'm averse to directly using the WP Tip of the Day (as suggested above), since that's directly to people who are *already* editors, albeit novice ones. What we really want is for people to hit the "edit" button for the first time. I suggest cycling through a few messages, along the lines of:
Want to lend a hand? Join an international volunteer effort, whether for a day or for a decade – learn how to edit Wikipedia.
Obviously these will need some finetuning, since I'd really rather not have something as cringy as "for a day or for a decade" on the Main Page, but I think the idea is there. These one-liners should be prominently displayed at the top. Cremastra ‹ u — c › 00:13, 5 December 2024 (UTC)[reply]
I agree that the messaging needs to be toward not-yet-editors, but perhaps they can be more specific? e.g.:
Did you know that you can italicize words by surrounding them with two appostrophe's? For example, The ''Titanic'' hit an iceberg and sank in 1912. appears as The Titanic hit an iceberg and sank in 1912.
See something that needs a source? Just add {{citation needed}}after the questionable sentence, or better yet, add a source yourself using <ref>www.website.com/page</ref>!
Rather see editors include material sourced to a bare url than to add without any source or even just give up with trying to add something because the ref system is hard to learn. We have bots that can do basic url to ref formats so that is less a concern. Masem (t) 00:30, 5 December 2024 (UTC)[reply]
considering the average technological literacy has seemingly gone down in the last decade, I wouldn't be surprised if telling people how to do certain things, especially in the non visual editor (Currently the default) would actually end up with the opposite effect. I like cremastras idea better Mgjertson (talk) 08:54, 17 December 2024 (UTC)[reply]
I suggested this on the other page, but there was no reply, perhaps their chats are inactive.
You can find the draft I made of the timeline here: User:Wikieditor662/Vital sandbox.
Note: I believe that the names for the time periods are not perfect (biased towards west) and there are other areas to improve before publishing but I think it's best to see whether it should be included before going further.
@Wikieditor662 Definitely looks cool and is well-designed. Perhaps you can clarify what exactly we're trying to accomplish with this (e.g., where would you like to have this displayed)? Is the purpose to identify potential changes to the Vital list, or to find vital articles to improve, or just to graphically illustrate the "more exciting" and "less exciting" periods of human history? Or something else? ———ypn^221:22, 4 December 2024 (UTC)[reply]
@Ypn^2 I'm very glad you like the design! It's meant to give a visual representation of the people on there, and to show when these people existed and how they could have interacted with each other. Now that you bring it up, this could also be a useful way for editors to see where there can be some improvements.
As for the location, the timeline could be its own page, and perhaps we could copy and paste a part of it (such as the overview) under the "people" section of vitality articles level 3.
Also, if this turns out to be a good idea, we could also create more specific timelines like this to help visualize other areas, for example level 4 / 5 philosophers, and perhaps put a part of that timeline under the History of philosophy page.
I understand this concern, and I think it's important to keep in mind that the vital articles' levels are structured to help define the priority levels for articles. Changes for who's included onto here require deep discussions and reliable reasons as to why they should be included or excluded. Wikieditor662 (talk) 03:43, 5 December 2024 (UTC)[reply]
Thanks, I've tried for a while and couldn't figure out how to change the blue text to a different color. If you know how, please let me know. I did, however, make the border of the text more black, so it should be a little easier to see now, although it may not be perfect. Wikieditor662 (talk) 06:02, 5 December 2024 (UTC)[reply]
@Ypn^2 @Fram @Chaotic Enby @Folly Mox(tagging relevant people, if you wish to be tagged / not be tagged please let me know) I've come up with a way we could conceptualize the eras outside of just Europe, which will work sort of like this:
For every era, we come up with one global, and one regional (for continent) eras. If a person matches a local era, then they'll go there, even if it's outside the bounds of the global era. However, if we can't find their regional era, then they'll go within the bounds of the global era. The global and local eras will have the same colors. Here are the eras:
Within these eras, in the individual timelines (unlike the overview, which could be broader) we can also break each era down into periods and color them slightly differently, blending in both the current era and the era that its closest to. The eras / periods may slightly differ depending on things like location and profession.
Here are the color codes for the overview, which should be more specific within individual timelines, and a person spanning across two eras will be colored in between these two eras. These are the colors which are (for the most part) currently in the timeline sandbox.
Prehistory: Black
Ancient: Brown
Post - classical history: Gold
Early modern: Blue
Middle modern: Green
Late modern: Yellow
Long nineteenth: Dark pink
Early 19th century: Orange
Contemporary: bright pink
Some example of transitional color eras:
Code for Postclassical: PCH
Code for Renaissance: Ren
Transren: colored exactly in between ren and PC
mostlyren: colored between Ren and transren
lateren: colored between Ren and mostlyren
(the same will work for the rest of the eras for the most part)
Global era: Prehistory (3 million BC - 3,000 BC) - Black - Nobody currently on there, but this could be in case someone gets added onto there one day - between humans' formation and writing being invented. This can extend much later, for example, Australia extends to its Prehistoric period until 1788, which is when it was first colonized (unless you include the age of discovery, which started in 1400).
Iron age / middle ancient - 1,200 BC - 550 BC (can also be a part of prehistory) - mostly ancient, less prehistoric
- For Iron Age Europe this is 1,050 - 776 BC (for consistency)
- Iran (for them this is still a part of pre-history): 2,000 BC - 1,000 BC
- India: 1,800 BC - 200 BC
Late ancient (or sometimes late iron ages) - 550 BC - 476 AD (every established era during this time, such as late antiquity is not global) - color: ancient
Late 20th century (L20) - 1945 - 2000 - Bright Orange (these colors will be slightly different than the overview because of the background)
-Modern Mexico: 1910 - 2000 - color: E20-L20
21st century (color: 21) - 2000 - today - Bright Pink (this will help out more in the future)
Regional time periods:
-Contemporary Mexico: 2000 - Present - color: 21
Postmodernism - The west - 1960 - Today (exact end date unclear, 20th century still applies for the individual timeline) - color: depends; some combination of L20 and 21
Don't know why you posted this in the middle of the discussion, and not clear what you want to do with it. In any case, this doesn't belong in the mainspace. If some project wants to use this in projectspace then why not, but "vital-3" articles or any variation thereof are not a notable group. Fram (talk) 08:44, 16 December 2024 (UTC)[reply]
@Fram Yeah I know, it's supposed to be a part of the project space.
@Chaotic Enby That's fine, a lot of it could be guidelines in case we decide to add someone who's not in a previous category... It could also help in case someone decides to add vitality 4 to the individual timelines one day.
Still not clear what you really want to do with it, but it definitely does not belong in the mainspace (as a separate article or as part of other articles), if that was your intention. "level 3 vitality figures" is pure inner Wikipedia talk, not a reliably sourced definition. If you want to use it in other namespaces, then indeed the colours need changing: blue on purple on grey is not readable at all. The names displayed are also weird. "Miguel" for Cervantes? "Joan" for Joan of Arc? Fram (talk) 15:31, 5 December 2024 (UTC)[reply]
I concur with Fram on this point, "vital articles" are only a (more or less effective) classification of which articles are a priority for the encyclopedia, it doesn't correspond to anything in use by sources. Even with deep discussions and reliable reasons, having it as a criterion would be original research. Same for any other "homemade" ranking of important people. Chaotic Enby (talk · contribs) 15:36, 5 December 2024 (UTC)[reply]
@Fram@Chaotic Enby Are you guys opposed to having this timeline completely, or just parts of it? And also, it's not based on how important people are, but the level of prioritization, which is the reason the vitality levels exist in the first place. Wikieditor662 (talk) 22:36, 5 December 2024 (UTC)[reply]
For the unfamiliar, this follows from Wikipedia:Village pump (idea lab)/Archive 62 § Timeline of significant figures, where advice was heeded, to the OP's credit.Wikieditor662, thanks for updating your visualisation to use an inclusion criterion that will not lead to as much arguing. I still think that this is not appropriate for mainspace and will not become appropriate, since the basis is fundamentally OR— even though the original research is distributed amongst the Wikipedia community rather than your own personally.I notice you've brought this up twice at WT:PVITAL, but not at the much more active WT:VA or WT:V3. You could probably just move it to a WikiProject subpage.I concede that your project is not terribly different from List of classical music composers by era, which I also don't think is a great thing to have in mainspace, but it's twenty-one years old, and predates most of our content guidelines. As an aside, it's probable that most articles in Category:Graphical timelines are problematic: Graphical timeline of the Stelliferous Era is pretty bad; Timeline of three longest supported deck arch bridge spans is also a questionable choice. None of these articles are as contentious as the one proposed here.MOS:NOSECTIONLINKS non-compliances remain, and calling out the Western bias in the chronological taxonomy is not an adequate substitute for addressing them to conform with the periodisation used by WP:VA (which they would probably want for consistency). Folly Mox (talk) 12:10, 6 December 2024 (UTC)[reply]
I still don't think old articles should be "grandfathered in" despite not fitting our more recent content guidelines, and the subjective and nearly unsourced List of classical music composers by era (whose selection is only based on the personal choices of editors, rather than any analysis of sources) shouldn't really be kept in mainspace just because of its age. Chaotic Enby (talk · contribs) 12:31, 6 December 2024 (UTC)[reply]
There is a systemic problem: sections on "Funding" for non-profit organizations. They are often disinformation. For example, if an organization is partly funded by the USAID, the organization will be framed as proxy of the US Federal Government. Of, if an organization is funded by the Koch Brothers, it will be framed in a suitably FUD way. This framing is often done through emphasis on certain donors, word choices and so on. Sometimes it's explicit other times subtle. I can show many examples, but prefer not to make it into a single case. The problem is systemic, since the beginning of Wikipedia.
What we need is an essay about Funding sections. Best practices, things to avoid. A link to WP:FUNDING. And some effort to go through these articles and apply the best practices described. -- GreenC18:31, 4 December 2024 (UTC)[reply]
I'm not sure that we need a separate essay on this, though perhaps a paragraph (or a couple of examples?) at Wikipedia:WikiProject Organizations/Guidelines would be helpful. Generally, the sorts of things you would expect to find in an encyclopedic summary are broad generalities ("The Wikimedia Foundation is largely funded by small donors" vs "The Met is largely funded by large donors and ticket sales") plus sometimes a 'highlights reel' ("The largest donation in the organization's history was..." or "In 2012, there was a controversy over...").
It's possible that the section should be something like ==Finances== instead of ==Funding==, as financial information about (e.g.,) whether they're going into debt would also be relevant.
"Sensitive content" labels (only for media that is nonessential or unexpected for an article's subject)
You see, many Wikipedia articles contain images or other media that are related to the article's subject, but that readers might not want to see, and have no way of avoiding if they are reading the article without prior knowledge of its contents.
For instance, the article Human includes an image which contains nudity. This image is helpful to illustrate the article's subject, but many people who read this seemingly innocuous article would not expect to see such an image, and may have a problem with it.
Of course, if someone decides to read the article Penis and sees an image of a penis, they really can't complain, since the image would just be an (arguably, essential) illustration of the article's subject, and its presence can easily be known by the reader ahead-of-time.
My solution to this is to have editors look for media or sections of an article which could be seen as having a different level of maturity compared to the rest of the article's content, then ensuring that the reader must take additional action in order to see this content, so that readers of a seemingly innocuous article would not have to see content that could be considered "shocking" or "inappropriate" when compared to the rest of the article's content, unless they specifically choose to do so.
Who gets to decide? Editors, by consensus, just like everything else.
But more pointfully, @FluffyKittehz, our usual advice is not to do this, and (importantly) to be thoughtful about image placement. For example, decide whether a nude photo is better than a nude line drawing. Decide whether the nude image really needs to be right at the top, or whether it could be a bit lower down, in a more specific section. For example, the nude photos in Human are in Human#Anatomy and physiology, which is less surprising, seen by fewer users (because most people don't scroll down) and more understandable (even people who dislike it can understand that it's relevant to the subject of anatomy).
BTW, the people in that particular nude photo are paid professional models. They were specifically hired, about a dozen or so years ago, to make non-photoshopped photos in the non-sexualized Standard anatomical position (used by medical textbooks for hundreds of years). I have heard that it was really difficult for the modeling agency to find anyone who would take the job. WhatamIdoing (talk) 03:53, 11 December 2024 (UTC)[reply]
First, if you, dear reader, have a tendency to mouse over bluelinks much as I do, I'd suggest not doing so without first reading what I'm linking to.
There are certainly some pages where NOTCENSORED is taken more than a tad too far. My opinion is that if there exists a diagram that would do a comparable job in depicting an objectionable subject, the diagram is to be preferred to the photograph. We sometimes do a pretty good job of using diagrams, just look (or don't, your choice) at where Seedfeeder's illustrations are used.
Also, I think a diagram (even if inferior) is preferable in the lede, so as not to shock readers who open (or even mouse over) the page. The images human are alright in comparison. We're perhaps the only esteemed publication which has images reasonably portrayable as pornographic, and I don't think it's a good look. JayCubby23:12, 17 December 2024 (UTC)[reply]
if there exists a diagram that would do a comparable job in depicting an objectionable subject, the diagram is to be preferred to the photograph. Which subjects are "objectionable"? Who gets to decide? What if there is disagreement about whether a diagram does a "comparable" job? What about those who think a diagram is equally (or even more) objectionable to a photograph? Thryduulf (talk) 01:03, 18 December 2024 (UTC)[reply]
@Thryduulf By 'objectionable', I mean subjects that are considered to be objectionable on a fairly brad scope. There are very few places (let's say the Western world for sake of argument, but this would probably hold true across the world) where a photograph of an erect human penis or a woman pleasuring herself with an electric toothbrush wouldn't be taboo if put on a billboard. There are few (but certainly more than the above) public places where it's acceptable to parade around in one's birthday suit. That I think we can agree on. I'm not giving a concrete definition, because norms do vary across cultures, but there is a baseline of what most people agree on.
The reason we have media at all in articles, including for human penis or Female ejaculation, is to describe the subject matter. In some circumstances, the subject matter might be best not illustrated with a photograph (some aspects of anatomy, sexuality, society), or would be adversely affected by not having a photograph or video (.
On the diagram bit, I think that diagrams are almost always less offensive than images, certainly so in the case of simply objectionable subject matters. JayCubby14:53, 18 December 2024 (UTC)[reply]
1) what would be taboo on a billboard is not relevant to an encyclopedia. You mention "public places". This isn't a public place. We are not throwing these images out to the public with no warning. They are used to illustrate articles on the subject depicted. And, before you mention "bystanders" seeing what you are looking at: a) they need to not be so rude as to do that and b) if you worry about it so much, don't look at Wikipedia in public
2) "the subject matter might be best not illustrated with a photograph" I would be interested in what things you think could be best illustrated by not showing them. Because I can't really think of any. --User:Khajidha (talk) (contributions) 15:36, 18 December 2024 (UTC)[reply]
Re #1: I used a billboard as a more extreme example. I'd argue that we are throwing those images out to the public without warning. Were I to look at what other books or websites (not just encyclopedias) addressed to the general public informing people on the topic, I'd be hard-pressed to find instances where photographs are put as we do. Readers don't expect Wikipedia to be any different.
2. It was late when I wrote the above, I posted the unfinished bit earlier today. What I mean is there are cases where a diagram is sufficient and a photograph wouldn't add anything but shock value. JayCubby17:06, 18 December 2024 (UTC)[reply]
Other books in general and other websites in general are also not relevant. We are an encyclopedia. And we aim to be the most comprehensive one ever. And, no, we are not throwing things out to the public. We are allowing the public to access our work. You come here for information on a topic. We provide it. Including relevant images. --User:Khajidha (talk) (contributions) 17:45, 18 December 2024 (UTC)[reply]
(edit conflict) objectionable on a fairly br[o]ad scope so that means we should regard everything that is objectionable to any large culture, such as Christians, Muslims, Hindus, Jews, Americans, Indians, Chinese, Nigerians, etc (there is no single "western" culture)? Or do you mean only those cultures you are personaly familiar with? or perhaps agree with? Personally I find File:Redneck Revolt Armed Demonstration.jpg far more objectionable than an erect human penis.
I think that diagrams are almost always less offensive than images You are entitled to your opinion, but how representative is it? Why does your opinion matter more than e.g. my opinion or an Islamic cleric's opinion, or a pornographer's opinion? simply objectionable subject matters what does this mean in objective terms? Simply objectionable to whom? Thryduulf (talk) 15:41, 18 December 2024 (UTC)[reply]
On the first point, I mean there are things that Christians, Muslims, Hindus, Jews, Americans, Indians, Chinese, and Nigerians would agree to be objectionable. As I said, there's a baseline. I didn't suggest censoring everything anybody is offended by.
On the second, see above for the audience. Can you state instances of where diagrams are in fact more offensive than photographs of the same subject? JayCubby17:10, 18 December 2024 (UTC)[reply]
Obviously there isn't a baseline. Otherwise we wouldn't be having this discussion. You have not mentioned even a single thing that I would object to being illustrated in a comprehensive encyclopedia.--User:Khajidha (talk) (contributions) 17:48, 18 December 2024 (UTC)[reply]
There is a baseline taboo against depictions of sexual abuse of children, and we kick people who disagree with this baseline off the project. —Kusma (talk) 19:36, 18 December 2024 (UTC)[reply]
The primary reason we do not display images depicting sexual abuse of children is that nobody has uploaded any freely licensed images of this subject that we can legally host. If a free image depicting this exists (not impossible) that we can legally host (currently extremely unlikely) and is uploaded then we will include it in any articles where it is encyclopaedically relevant and due (whether there are any such articles is unknowable without seeing the image).
Off the top of my head, maybe an annotated diagram about a homemade bomb would be more offensive than a photograph of a bomb? There are certainly no shortage of examples where, to at least some people, diagrams are equally offensive as photographs.
I didn't suggest censoring everything anybody is offended by. then you need to state how you are choosing which things to censor. Whose opinions matter? How many people being offended by something is enough? Or does it matter who it is? Thryduulf (talk) 19:53, 18 December 2024 (UTC)[reply]
Jfc, that is not the primary reason. Even if we had a freely-licensed image, and WMF Legal was like "sure, go ahead," we would not go ahead. Levivich (talk) 20:01, 18 December 2024 (UTC)[reply]
It's obviously hypothetical given that such an image does not currently exist (and I can't think of an image that would be both encyclopaedically relevant* and legal), but if it did you would need to explain why NOTCENSORED didn't apply. Any arguments that an image were not DUE would have to be based on things other than "I don't like this image" or "I don't like the subject of this image". *Some years ago I remember images of FBI child pornography raids and/or of specific people convicted of child pornography were proposed to illustrate the Child pornography article, but rejected for not being clearly related enough/on BLP grounds. Thryduulf (talk) 20:48, 18 December 2024 (UTC)[reply]
WP pretty explicitly doesn't care if someone finds content offensive. Penises and vaginas are things that exist. Anatomically correct images of penises and vaginas are educationally useful. Anatomy isn't pornography. GMGtalk16:43, 18 December 2024 (UTC)[reply]
I do wonder if we should be considering sources when discussing this topic. Including a graphic image in an article, when sources do not typically include such an image, could be viewed as undue weight or a type of original research. It’s normal for anatomy textbooks to contain pictures of anatomy, so it should be normal for our anatomy articles to include that type of picture too. Barnards.tar.gz (talk) 21:08, 18 December 2024 (UTC)[reply]
Yes, it's appropriate to follow the sources' lead in choosing images.
We also have guidelines against the WP:GRATUITOUS inclusion of Wikipedia:Offensive material – and the near-total absence of disputes, for many years, about when and whether that guideline relevant pretty much disproves the "but nobody can possibly decide what's offensive" whingeing above – and we require that illustrations be WP:PERTINENT, and MOS:LEADIMAGE says that "Lead images should be of least shock value; an alternative image that accurately represents the topic without shock value should always be preferred". We comply with foundation:Resolution:Controversial content, which requires that readers not be astonished to discover (for example) sexual content on a page through methods such as (a non-exhaustive example) not putting sexual photos in articles that aren't about sexual content or even (for the advanced class) adding quick descriptions, so that people who might hover over or click on a link will know what it's about, so that "the sexual practice of ____" instead of just "____".
This is not that difficult. We don't "label" the images, as suggested above, but we do generally make decent choices, and where we could do better, we invite editors to WP:Be bold in making Wikipedia more closely conform with the long-standing policies and guidelines. WhatamIdoing (talk) 00:02, 19 December 2024 (UTC)[reply]
Changes to welcome banner
I've copied and restructured content from [RfC]. My initial proposal was to remove this content entirely, but consensus seems to be against that, so I've moved most of the discussion here.
The Welcome message is valuable and it makes sense for it to be at the top; the message includes a link to Wikipedia for those unfamiliar with the site, and "anyone can edit" directs readers (and prospective editors) to Help:Introduction to Wikipedia. The article count statistic is a fun way to show how extensive the English Wikipedia has become. (My only suggestion would be to include a stat about the number of active editors in the message, preferably after the article count stat.) Some1 (talk) 15:06, 8 December 2024 (UTC)[reply]
This proposal essentially restricts informing readers about one of Wikipedia’s core ideas: anyone can edit. The current text on the main page is important because it reminds readers that we’re a free encyclopedia where anyone can contribute. The article count also matters—it shows how much Wikipedia has grown since 2001 and how many topics it covers.Another point to consider is that moving it to the bottom isn't practical. I don't think readers typically scroll that far down—personally, I rarely do. This could lead to fewer contributions from new users.The AP (talk) 15:29, 8 December 2024 (UTC)[reply]
Why on earth would we want to hide the fact that we're the free encyclopedia anyone can edit? We need more information about how to edit on the MP, not less! We want to say, front and centre, that we're a volunteer-run free encyclopedia. Remove it, and we end up looking like Britannica. The banner says who we are, what we do, and what we've built, in a fairly small space with the help of links that draw readers in and encourage them to contribute. Cremastra ‹ u — c › 17:31, 8 December 2024 (UTC)[reply]
I strongly agree with the comments above about the importance of encouraging new readers to edit. However, I'm a bit skeptical that the current approach (a banner taking up a quarter of the screen with some easter egg links) is the most effective way to achieve this—how often do people click on any of them? Anyone have ideas for other ways to accomplish this better while using the same amount of space?– Closed Limelike Curves (talk) 00:05, 11 December 2024 (UTC)[reply]
I think that having some sort of banner like this is a good idea. I would be open to changing it if anyone else comes up with a good idea, but removing it entirely is a bad idea. QuicoleJR (talk) 19:12, 19 December 2024 (UTC)[reply]
Aesthetic concerns
While the message isn't information-dense like the rest of the Main Page, it is much more welcoming for a new visitor, and easier on the eyes, than immediately starting with four blocks of text. Chaotic Enby (talk · contribs) 13:09, 8 December 2024 (UTC)[reply]
Here's how the main page has changed over the years, despite theoretically being "frozen" for 2 decades now. In short, the main page was designed for 2006, when we had Monobook and no ads. At that point, the main page was genuinely a single page—people arriving at it got the opportunity to see all of our DYK, FP, etc. content.
Without ads, V22's default appearance isn't exactly horrific, but the last thing it needs is more whitespace. I actually think most of the complaints from readers (rather than editors) about V22 weren't really about V22 itself, so much as how bad the main page is at conveying information on V22. I think most people have learned to live with it at this point, but when the switch first happened I was annoyed as hell about how much I had to scroll to reach material further down the page.
(To some extent I feel like the aging millenial web designers at the WMF have been slowly developing eyesight issues, so they decided to turn it into somebody else's problem by doubling the text size.) – Closed Limelike Curves (talk) 00:09, 18 December 2024 (UTC)[reply]
I see no problem with the ad. You can just dismiss it. As for the text size, that was determined through a survey of all users who specified their favorite text size. After enlarging the text size in old Vector, I get only a slither further down than V22 without the ad. Aaron Liu (talk) 01:30, 18 December 2024 (UTC)[reply]
Yes, I don't have an issue with the text size (I think it's an improvement)—the issue is the combination of the new text size with the old main page design, which hides everything below the first row (and sometimes it hides that too)! – Closed Limelike Curves (talk) 18:46, 19 December 2024 (UTC)[reply]
In short: The top of the main page is where the most interesting material (the stuff people are most likely to click on) or most important material (the stuff we really want people to read) should go. DYK hooks are probably the most interesting material on Wikipedia's main page most of the time, so having them on-screen is very important. Basically everyone already knows that Wikipedia is edited by volunteers, and they definitely know they don't have to pay for it. – Closed Limelike Curves (talk) 19:18, 21 December 2024 (UTC)[reply]
Not everyone. The new generations should also know. It's not like seeing ~5 rows of text is going to change much, especially when the problem is easily solved by dismissing the welcome banner. Unfortunately I don't think we're going anywhere, so we may have to agree to disagree. Aaron Liu (talk) 19:47, 21 December 2024 (UTC)[reply]
DYK hooks are probably the most interesting material on Wikipedia's main page For what it's worth, I rarely look at the DYK box when I'm on the main page as I find it uninteresting. DYK apparently has its own set of problems (e.g. errors, etc.), so expanding and elevating it to the very top of the main page is not a good idea IMO. Some1 (talk) 20:25, 21 December 2024 (UTC)[reply]
This: Basically everyone already knows that Wikipedia is edited by volunteers is not true. If it were true, then I'd have received a lot fewer inquiries over the years about how to get hired as a Wikipedia editor. WhatamIdoing (talk) 23:20, 21 December 2024 (UTC)[reply]
What to do with space
Do you have another good reason that the top of the MP should be taken down? Do you have a alternative banner in mind? Moreover, this needs a much wider audience: the ones on the board. 2601AC47 (talk·contribs·my rights) Isn't a IP anon14:27, 8 December 2024 (UTC)[reply]
This is a strange concern; of course a community consensus can change the main page's content. It doesn't seem to be happening, but that has nothing to do with the WMF. ~ ToBeFree (talk) 16:16, 8 December 2024 (UTC)[reply]
I avoided discussing specific replacements because I didn't want to get bogged down in the weeds of whether we should make other changes. The simplest use of this space would be to increase the number of DYK hooks by 50%, letting us clear out a huge chunk of the backlog. – Closed Limelike Curves (talk) 17:43, 8 December 2024 (UTC)[reply]
Opt-in content warnings and image hiding
A recent discussion about sensitive images at VPP became quite heated, for reasons, but there actually appears to be little to no opposition to developing opt-in features to help readers avoid images that they don't want to see. Currently the options are very limited: there are user scripts that will hide all images, but you have to know where to find them, how to use them, and there's no granularity; or you can hide specific images by page or filename, which has obvious limitations. I therefore thought I'd bring it here to discuss ideas for improving these options.
My idea would be to implement a template system for tagging images that people might not want to see, e.g. {{Content warning|Violence|[[Image:Man getting his head chopped off.jpg|thumb|right|A man getting his head chopped off]]}} or {{Content warning|Sex|[[Image:Blowjob.jpg|thumb|right|A blowjob]]}}. This would add some markup to the image that is invisible by default. Users could then opt-in to either hiding all marked images behind a content warning or just hiding certain categories. We could develop a guideline on what categories of content warning should exist and what kind of images they should be applied to.
A good thing about a system like this is that the community can do almost all of the work ourselves: the tagging is a simple template that adds a CSS class, and the filtering can be implemented through user scripts/gadgets. WMF involvement on e.g. integrating this into the default preferences screen or doing the warning/hiding on the server side would be a nice-to-have, not a must-have. – Joe (talk) 07:34, 11 December 2024 (UTC)[reply]
Oh also, I suggest we strictly limit discussion here to opt-in systems—nothing that will change the current default of all images always being visible as-is—because experience shows that, not only is consensus on this unlikely to change, but even mentioning it has a tendency to heat up and derail discussions. – Joe (talk) 07:36, 11 December 2024 (UTC)[reply]
Would there be a way to tag or list the images themselves, rather than needing to recreate new template coding for each use? CMD (talk) 08:32, 11 December 2024 (UTC)[reply]
That would make sense, but since the images are (mostly) on Commons I couldn't figure out a way of doing it off the top of my head. It would also mean that control of what and how things were tagged would be on another project, which always tends to be controversial on enwiki. – Joe (talk) 08:56, 11 December 2024 (UTC)[reply]
From the experience with spoiler warnings, these things tend to proliferate if they exist at all. I would rather stay with the clean policy of no warnings whatsoever than discuss whether to introduce warnings for certain classes of offensive things. I am personally offended by the use of "His Royal Highness" or similar words when referring to citizens of Germany like Mr Prinz von Preussen, but I think it is better not to have a category of pictures offending German anti-monarchists. Even if we do not do the censoring ourselves, I oppose spending volunteer time on implementing something that can be used as a censorship infrastructure. —Kusma (talk) 09:33, 11 December 2024 (UTC)[reply]
This would retain the policy of no warnings because they would be invisible to anybody who didn't opt-in. Similarly, only volunteers who want to use their time in maintaining this system would do so. – Joe (talk) 10:45, 11 December 2024 (UTC)[reply]
Strongest oppose to tagging system, for which there was pretty clear consensus against in the previous discussion. It is against the spirit of Wikipedia and would be a huge headache for an end that goes against the spirit of Wikipedia. This project should not be helping people hide from information. ꧁Zanahary꧂15:33, 11 December 2024 (UTC)[reply]
Support: I don't see why would anyone oppose it. And since I have little knowledge on technical stuff, I don't have anything to add to this idea.
Sorry, I didn’t realize we don’t vote here. How are we supposed to voice opposition to an idea? Just exclude the bolded vote? ꧁Zanahary꧂18:36, 11 December 2024 (UTC)[reply]
I don't voice opposition to an idea? Here's my criticism: tagging to appeal to sensitivities that would have certain types of information and imagery hidden is validating those sensitivities, which is not the place of Wikipedia (and is against its spirit), and enables the concealment of informationm which is diametrically opposed to the spirit of Wikipedia. My proposed "fix" is to not pursue this content-tagging idea. ꧁Zanahary꧂19:23, 11 December 2024 (UTC)[reply]
I haven’t seen anyone bring this up, but this clearly goes against WP:No disclaimers. Please consider this a constructive note about the obstacles you will face if you try to add content warnings to Wikipedia. ꧁Zanahary꧂17:23, 16 December 2024 (UTC)[reply]
Having a general Opt-in system of blurring or hiding all images would be no problem. Having one based on tags, content, categories... would be largely unmaintainable. If you create an "opt-in here to hide all sexual images", then you have to be very, very sure that you actually can do this and not give false promises to readers. But as there is no agreement on where to draw the line of what is or isn't sexual, nudity, violence, disturbing, ... this will only lead to endless edit wars without possible resolution. Are the images on Breastfeeding sexual? L'Origine du monde? Liberty Leading the People (ooh, violence as well!)? Putto? Pavilion of Human Passions? Fram (talk) 10:03, 11 December 2024 (UTC)[reply]
Exactly. One of the issues is that some people think there is a thing such as non-sexual nudity, while others think that nudity is always sexual. —Kusma (talk) 10:14, 11 December 2024 (UTC)[reply]
So we could have a category "nudity" instead of or in addition to "sex". Part of the proposal here is coming to a consensus on which categories should exist and on guidelines for their use. I don't see how we can conclude that this is an impossible or impractical task before even trying. We manage to drawlinesthroughgreyareas all the time. – Joe (talk) 10:44, 11 December 2024 (UTC)[reply]
As with everything, we'd have to reach a consensus about such edge cases either in general or on a case-by-case basis. It's not for me to say how that would go with these examples, but I'd suggest as a general principle we should be descriptive rather than normative, e.g. if there is a dispute about what constitutes male nudity, then break the category down until the labels are uncontroversial – "male nudity (upper body)" and so on. – Joe (talk) 13:50, 11 December 2024 (UTC)[reply]
These aren't edge cases though. The more you have to break it down, the more work it creates, and the disputes will still continue. Will we label all images of women/men/children/other? All images of women showing any flesh or hair at all? Basically, we will need to tag every image in every article with an endless series of tags, and then create a system to let people choose between these endless tags which ones they want to hide, even things most of us might find deeply unsettling to even offer as an option? Do we want people to be able to use Wikipedia but hide all images of transgenders? All images of women? All images of Jews? Everything that isn't halal? In the 4 images shown below, the one in the bathtub is much more sexual than the one in the shower, but the one in the shower shows a nipple, and the other one doesn't. Even to only make meaningful categories to indicate the difference between those two images would be quite a task, and then you get e.g. the other image showing an artwork, which again needs a different indication. It seems like madness to me. Fram (talk) 14:05, 11 December 2024 (UTC)[reply]
There are just so many things that some people don't want to see... Dead Australians or Baháʼu'lláh are among the easier ones that might look near harmless to tag. However, people will also demand more difficult things like "images not appropriate for 12 year olds" that have no neutral definition (and where Europeans and Americans have widely differing opinions: just look for typical film ratings where European censors think sex, nudity, drug use and swearing are ok but violence is not, and American censors will think the opposite). There are also things some people find offensive that I am not at all ok with providing a censorship infrastructure for: images depicting mixed-race couples, images depicting trans people, images depicting same-sex couples. I do not think Wikipedia should help people avoid seeing such images, so I do not want us to participate in building a censorship infrastructure that allows it. —Kusma (talk) 11:18, 11 December 2024 (UTC)[reply]
The English Wikipedia community would control which categories are used for this system and I am confident they would reject all of these examples. "People will make unreasonable demands" does not sound like a good reason not to do something. – Joe (talk) 13:44, 11 December 2024 (UTC)[reply]
I am confident they would reject all of these examples Why? On what objective grounds are you labelling those examples as "unreasonable"? Why are your preferences "reasonable"? Thryduulf (talk) 14:14, 11 December 2024 (UTC)[reply]
Because if there's one thing the English Wikipedia community is known for, it'a always agreeing on everything?
This project already has enough things for ongoing arguments over. Making lists of what people may want to avoid and ranking every image on whether it falls into that list is a tremendous effort that is bound to fail. (The thread calling for such categorization on the policy page is an excellent example.... a user felt they were harmed by an image of a dead man smiling... only it seems not to be a dead man, we were supposed to police that image based on how they would misinterpret it.) I'm also wondering if we risk civil litigation if we tell people that we're protecting against image-type-X and then someone who opted out of seeing such images views something that they consider X.
This is just one more impediment to people adding information to the encyclopedia. I can't see that this censorship system would make more people enthusiastic to edit here (and if it did, I'm not sure we'd really want the sort of editor it would encourage.) -- Nat Gertler (talk) 14:39, 11 December 2024 (UTC)[reply]
One more general problem with the proposal is that you do not know whether people will be forced to "opt in" by "well meaning" system administrators trying to censor what can be accessed from their system. Having machine readable tags on images makes it very easy to do so and also easy to remove people's ability to click through and see the content. We should not encourage volunteer efforts on supporting such censorship infrastructures. —Kusma (talk) 11:46, 11 December 2024 (UTC)[reply]
I don't think the specific proposal here, placing templates in articles (even if they default to not obscuring any images), would be workable. It's too big of an opportunity for activist editors to go on mass-article-editing sprees and for people to edit war over a particular instance of the template. You'd also have to deal with templates where simply wrapping the image in a template isn't currently possible, such as Template:Speciesbox. If people really want to pursue this, I think it'd be better to figure out how to tag the images themselves; people will still probably fight over the classifications, but at least it's less likely to spill over into disrupting articles. Anomie⚔12:45, 11 December 2024 (UTC)[reply]
The idea was that, since these templates would have no effect if not someone has not opted-in to hiding that specific category of image, people who do not want images to be hidden would be less likely to fight over it or be worried about what "activist editors" are doing. The idea that Wikipedia should not be censored for everyone has solid consensus behind it, but the position some are taking here, that other people should not be allowed an informed choice of what not to see, strikes me as quite extreme. – Joe (talk) 13:40, 11 December 2024 (UTC)[reply]
I dispute your good-faith but naive assertion that these templates would have "no effect on people who have not opted in". If you tag images systematically, you make it easy to build proxies (or just censored forks) that allow high schools in Florida to ensure their students won't be able to click through to the photo explaining how to use contraceptives. There is no innocent "only opt-in" tagging; any such metadata can and will be used for censorship. Do you really want us to be in the business of enabling censorship? —Kusma (talk) 15:14, 11 December 2024 (UTC)[reply]
Well yes, the proposal literally to enable censorship. For those who want it. It may be that it is used by network administrators as you suggest, we can't stop that, but that's between them and their users. I agree that censorship should not affect what editors include in our content but I find the idea that we can enforce our ideal of Zero Sensitivity Free Speech to a global readership also very naive (and frankly a little creepy; I keep picturing a stereotypical Wikipedian standing in front of a Muslim child screaming "no you WILL look at what we show you, because censorship is bad and also what about Renaissance art"). A silver lining could be that the option of controlling access to our content in a fine grained way may convince some networks to allow partial access to Wikipedia where they would otherwise completely block it. – Joe (talk) 16:58, 12 December 2024 (UTC)[reply]
We are not in the business of enabling censorship, voluntary or otherwise, because voluntary censorship very quickly becomes involuntary cesnsorship. We are in the business of providing access to information, not inhibiting access to information. Thryduulf (talk) 17:07, 12 December 2024 (UTC)[reply]
"We're not in the business of leaving the phrase 'rimjob' to your imagination, Timmy, we're in the business of providing access to artistic depictions of bunny sex!" he screamed, and screamed, and screamed... you guys are really silly sometimes. – Joe (talk) 17:31, 12 December 2024 (UTC)[reply]
I've seen enough arguments over people doing mass edits and otherwise fighting over invisible stuff in articles, including complaints of watchlist flooding, to think this would be any different. Anomie⚔00:17, 12 December 2024 (UTC)[reply]
Antonin Carlès (1851-1919) - La Jeunesse (1883) (12387743075)Angela milk tub (LR-6395)Adult Caucasian woman - Breast Self-Exam (1980)Nude woman private portrait
* I would support an opt-in that turned off or blurred all images and made them viewable with a click. I would absolutely object to anything that used some categorization system to decide which images were potentially offensive to someone somewhere. There would be systemic sexism in such categorization because of different cultural norms. Valereee (talk) 12:56, 11 December 2024 (UTC)[reply]
Yes, or at least the three photographs. I'm standing on a crowded subway car and just scrolled past three pics of boobs. Totally unexpected, totally would have minimized/blurred/hidden those if I could, just for the other people around me. It has nothing to do with being offensive, I'm just in a place where pictures of boobs are not really OK to have on my phone right now. And I live in a free country, I can only imagine what it might be like for others. Levivich (talk) 15:16, 11 December 2024 (UTC)[reply]
If you are in a place where images of boobs are not ok to have on your phone, you should turn off or blur images on wikis in general as you can never guarantee there will be a warning. (As an aside, these images are not far from some that I have seen in on ads in subway stations). —Kusma (talk) 16:15, 11 December 2024 (UTC)[reply]
Levivich, I sympathize with the desire not to encounter NSFW content while “at work”. But your standard here is “not safe for a crowded American or British public space”, which admittedly is the default for the Internet as a whole. But on Wikimedia we at least try to respect the fact that not everyone has that standard. Dronebogus (talk) 17:49, 11 December 2024 (UTC)[reply]
It really doesn't feel like we're trying to respect anyone, based on this and related discussions. We seem to be saying to anybody who has personal or cultural sensitivities about any kind of image (so the majority of humankind) that they can either accept our standard of WP:NOTCENSORED or to not see any images at all. We're saying we can't possibly let your kids have the full experience of our educational images while also avoiding photos of dead bodies or graphic depictions of penetrative sex, because what about male nipples? – Joe (talk) 17:04, 12 December 2024 (UTC)[reply]
I don't think anyone is saying that people should not see images at all... simply that if they are concerned about seeing images, they get to be the ones to decide which images they should see by clicking on that image. For them to make it our responsibility to guess which pictures they'll want and be the baddies when we're wrong is not respecting them and their ability to make decisions for themselves. (And I'm not sure that you can say we're giving anyone the "full experience of our educational images" when you are hiding some of them.) -- Nat Gertler (talk) 21:10, 12 December 2024 (UTC)[reply]
Yes because what about male nipples. Because what about female nipples? Lots of more liberal-minded legal guardians wouldn’t oppose children seeing those. Or even full nudity. Or even dead bodies and penetrative sex! And then we have to go the whole opposite direction ad absurdum with women in bikinis, and Venus de Milo, and unveiled females, or female humans in general, and Mohammad, and dead aboriginal Australians and spiders and raw meat and Hindu swastikas and poop. Dronebogus (talk) 11:27, 13 December 2024 (UTC)[reply]
Try that with the policeman looking over your shoulder in the country where accessing "indecent" images gets you imprisoned. – Joe (talk) 17:06, 12 December 2024 (UTC)[reply]
Pretty much every image of a human being (and plenty of other subjects) has the potential to be regarded as indecent somewhere. This means there are exactly two options that can achieve your desired outcome: censor all images, or assigned every image, individually, to one or more extremely fine-grained categories. The first already exists, the second is completely impractical. Thryduulf (talk) 17:11, 12 December 2024 (UTC)[reply]
Someone on the subway asked me to stop looking at pictures of naked people on my phone and I said "WHAT?! I'M READING AN ENCYCLOPEDIA!" Levivich (talk) 00:22, 13 December 2024 (UTC)[reply]
I really don’t see why Wikipedia should work around the subway-goer looking at your phone and your ability to appease them. Look at another website if you want something censored and safe for onlookers. ꧁Zanahary꧂00:28, 13 December 2024 (UTC)[reply]
You can have your own script to toggle off every image. You can have a script that runs on an off-wiki index of images you don’t want to see. But to tag images as potentially offensive, I have an issue with, and I hope you understand why even if you don’t agree. ꧁Zanahary꧂02:44, 13 December 2024 (UTC)[reply]
I’m sorry but your situation is just weird. You should know Wikipedia is generally NSFW at this point if you’re complaining about it right now. Dronebogus (talk) 11:45, 13 December 2024 (UTC)[reply]
Seems that the problematic behavior here isn't us having the images or you looking at them, it is the random person looking at someone else's screen. We should not be required to modify our behavior because other people behave badly. --User:Khajidha (talk) (contributions) 15:49, 13 December 2024 (UTC)[reply]
You can look at other websites if you're in public and an uncensored one would disturb people who might glance at your phone! ꧁Zanahary꧂21:06, 11 December 2024 (UTC)[reply]
@Valereee: We don't, we let the people who want to hide images decide which images they want to hide. They can pick specific images, or categories, or use the Wikidata "depict" info (as Izno mentions below), and there's probably some other ways to do it besides those three. Levivich (talk) 19:01, 17 December 2024 (UTC)[reply]
Wouldn't it be simpler to set up a toggle on/off applied locally for all images that can be used by IPs as well as registered accounts? Sorry if I'm completely misunderstanding the tech details.
To be clear, I have no objection to allowing people to decide from among WC’s how many hundreds of thousands of categories which ones they don’t want to see. Sounds like a daunting iterative process if there's a lot someone would rather not be surprised by, but it's their time. And if someone wants to go through WC and make sure everything's categorized, ditto. And I guess someone could leave penises on their list all the time and take boobs off once they get off the subway. :D What I object to is for us in any way to suggest/imply which categories someone might want to block. Valereee (talk) 14:16, 18 December 2024 (UTC)[reply]
Yes I totally agree with all of that :-) An image switch would be simpler, and compiling a list would take a lot of time, but it's their time. (I would toggle the switch on the subway to protect myself from boobs and penises!) Levivich (talk) 17:12, 18 December 2024 (UTC)[reply]
Browsers already have a toggle so they can avoid downloading all images. As I discussed in another thread, users who need to limit their downloads of images are likely to need to do this across all web sites, and so handling this restriction on the client side is more effective. isaacl (talk) 19:54, 18 December 2024 (UTC)[reply]
Yeah, but if most of your online time is at, like, art or shopping or recipe sites, it seems like kind of a hassle to make someone flip that toggle every time they come to Wikipedia when we could just give them a toggle to set here. Again apologies for my tech ignorance. Believe it or not I was an early adopter when I was young. In the early 90s I taught workshops for my professional association in how to build a website. :D Age. It comes for all of us. Valereee (talk) 16:52, 19 December 2024 (UTC)[reply]
Some browsers will let you configure settings for specific sites, so you can block images from only Wikipedia. It's just more effective for users to have one interface that they can use across all websites, than to have to make adjustments on every website they want to manage. (For a similar reason, Wikipedia doesn't dictate a specific font for the body text; it uses the configured default sans-serif font.)
Regarding the tech side, the most straightforward way to implement a setting for non-logged in users without incurring additional caching costs is to use Javascript that is triggered through something stored on the client (such as a cookie), which is how I understand the Vector2022 width setting is done. That introduces a race condition where images may be downloaded before they can get blocked, and potentially shifting layouts, or the entire page load has to be delayed. isaacl (talk) 17:42, 19 December 2024 (UTC)[reply]
I'd be ok with such an opt-in too, if it can be made. Perhaps such a link/button could be placed in the main meny or floating header. The hamburger too perhaps, for the mobile readers. Gråbergs Gråa Sång (talk) 13:27, 11 December 2024 (UTC)[reply]
The idea is not to decide what is and isn't potentially offensive, but to add descriptive labels and then let readers decide what they do and do not want to be warned about. So for example we would not categorise any of your examples as "potentially offensive", but as containing "nudity" or "nude women" or whatever level of granularity was agreed upon. This idea is a reaction to the proposal to obscure all images (which is being discussed elsewhere) because a) letting users choose whether to see an image is only useful if they have some indication of what's behind the blurring and b) quite frankly, I doubt anyone will ever use such an indiscriminate option. – Joe (talk) 13:33, 11 December 2024 (UTC)[reply]
One generally does have indications of what is being blurred, both some sense in a blurred image but more importantly by caption. Some ways of hiding all images would ipresent not a blurred image present a filename, and image filenames are largely descriptive. -- Nat Gertler (talk) 15:59, 11 December 2024 (UTC)[reply]
That is actually a much better idea than blurring, thanks! Having a "see alt text instead of images" option would not only be more practical for people wanting to know if images are sensitive before seeing them, it would also give more of an incentive to add alt text to begin with. Chaotic Enby (talk · contribs) 18:31, 11 December 2024 (UTC)[reply]
I would also support an opt-in to blur all images (in fact, User:Chaotic Enby/blur.js does about that). However, categorizing images with labels whose only purpose is for reader to decide whether they are offensive is, by definition, flagging these images as "potentially offensive", as I doubt a completely innocuous image would be flagged that way. And any such categorization can easily be exploited, as above.Also, the ethical concerns: if some people find homosexuality offensive, does that mean Wikipedia should tag all images of gay couples that way? What is the message we bring if gay people have a tag for blurring, but not straight people? Chaotic Enby (talk · contribs) 14:04, 11 December 2024 (UTC)[reply]
You might be able to do it using categories, even Commons categories. Instead of (or in addition to) adding images one by one to special maintenance categories, add entire image categories to the maintenance categories. Keep in mind this isn't the kind of thing that needs consensus to do (until/unless it becomes a gadget or preference)--anyone can just write the script. Even the list of categories/images can be maintained separately (e.g. a list of Commons categories can be kept on enwiki or meta wiki or wherever, so no editing of anything on Commons would be needed). It could be done as an expansion of an existing hide-all-images script, where users can hide-some-images. The user can even be allowed to determine which categories/images are hidden. If anyone wants to write such a script, they'd have my support, hmu if you want a tester. Levivich (talk) 15:30, 11 December 2024 (UTC)[reply]
To get any sort of useful granularity you have to go multiple levels deep, and that means there are literally thousands (possibly tens of thousands) of categories you need to examine individually and get agreement on. And then hope that the images are never recategorised (or miscategorised), new images added to categories previously declared "safe" (or whatever term you choose) or new categories created. Thryduulf (talk) 15:43, 11 December 2024 (UTC)[reply]
c:Category:Penis. If someone wrote a script that auto-hid images in that category (and sub-cats), I'd install it. We don't need agreement on what the categories are, people can just make lists of categories. The script can allow users to choose whatever lists of categories they want, or make/edit their own list of categories. One thing I agree about: the work is in compiling the lists of categories. Nudity categories are easy; I suspect the violence categories would be tougher to identify, if they even exist. But if they don't, maintenance categories could be created. (Lists of individual images could even be created, but that is probably too much work to attempt.) Levivich (talk) 15:53, 11 December 2024 (UTC)[reply]
Going that private script route, you could also use the category of the article in which it appears in some cases. But I'd worry that folks would try to build categories for the specific reason of serving this script, which would be sliding from choice to policy. -- Nat Gertler (talk) 16:02, 11 December 2024 (UTC)[reply]
Nah, still choice. One option is to create new maintenance categories for the script. Another option is for the script to just use its own list of images/categories, without having to add images to new maintenance categories. Levivich (talk) 16:21, 11 December 2024 (UTC)[reply]
Allowing maintenance categories designed to hide images is very much a policy issue, no matter how many times you say "nah". The moment that "pictures which include Jews" category goes up, we're endorsing special tools for antisemitism. -- Nat Gertler (talk) 17:04, 11 December 2024 (UTC)[reply]
Nah. See, while we have a categories policy, new maintenance categories are not something we "allow" or don't allow -- they're already allowed -- and they don't create a "policy issue" because we already have a policy that covers it. People create new maintenance categories all the time for various reasons -- it's not like we have to have an RFC to make a new template or make a new maintenance category. This is a wiki, have you forgotten? We need consensus to delete stuff, not create stuff.
And you're totally ignoring the part that I've now said multiple times, which is that no new maintenance categories are required. That's one way to skin this cat, but it can also be done by -- pay attention please -- creating lists of categories and images. See? No maintenance category, no policy issue.
Anybody creating a list of "pictures which include Jews" would be violating multiple site policies and the UCOC and TOS. This is a wiki, remember? Did we not have Wikipedia because someone might create an antisemitic article? No! We still had a Wikipedia, knowing full well that some people will abuse it. So "somebody might abuse it!" is a really terrible argument against any new feature or script or anything on Wikipedia.
What are you even opposing here? You have a problem with someone creating a script to hide images? Really? Maybe just ... not ... try to imagine reasons against it? Maybe just let the people who think it's a good idea discuss the implementation, and the people who don't think it's a good idea can just... not participate in the discussion about implementation? Just a thought. It's hard to have a discussion on this website sometimes. Levivich (talk) 17:09, 11 December 2024 (UTC)[reply]
Creating a script to hide images is fine. Curating/categorising images to make them easier to hide is not. You are free to do the first in any way you like, but the second should not be done on Wikipedia or any Wikimedia project. —Kusma (talk) 17:30, 11 December 2024 (UTC)[reply]
Why yes, I can understand why having people who disagree with you about both intent and effect in this matter would be a disruption to the discussion you want to have, with all agreeing with you and not forseeing any problems nor offering any alternate suggestions. I'm not seeing that that would be particularly in the spirit of Wikipedia nor helpful to the project, however. "Someone might abuse it and it might require more editorial effort to work it out, all of which could be a big distraction that do not actually advance the goals of the project" is a genuine concern, no matter how many times you say "nah". -- Nat Gertler (talk) 17:40, 11 December 2024 (UTC)[reply]
If not categories then perhaps that image tagging system commons has? (Where it asks you what is depicted when you upload something). Not sure how much that is actually used though. – Joe (talk) 17:18, 12 December 2024 (UTC)[reply]
Yeah, given how Wikipedia categorization works (it's really labeling, not categorization), it's well known that if you go deep enough into sub-cats you emerge somewhere far away from the category you started at.
If the cost of muting the Penis category is having the bunny picture hidden, I'd still install the script. False positives are nbd. Levivich (talk) 16:23, 11 December 2024 (UTC)[reply]
And...? I thought we were hiding objectionable images (and considering that painting as "objectionable" is dubious to start with), not all images on a page where one image is objectionable? Plus, an image that is only used on page X today may be used on page Y tomorrow ("rabbits in art"?). So no, this is not a bad example at all. Fram (talk) 22:54, 13 December 2024 (UTC)[reply]
This is no better than the discussion running at the other VP and is borderline forum shopping. I’m disappointed in the number (i.e. non-zero) of competent users vehemently defending a bad idea that’s been talked to death. I keep saying that the only way (no hyperbole) this will ever work is an “all or nothing” opt-in to hide all images without prejudice. Which should be discussed at the technical VP IMO. Dronebogus (talk) 17:37, 11 December 2024 (UTC)[reply]
Maybe you missed it, ValarianB, but this is the idea lab, so a) as it says at the top of the page, bold !voted are discouraged and b) the whole point is to develop ideas that are not yet ready for consensus-forming in other forums. – Joe (talk) 17:10, 12 December 2024 (UTC)[reply]
Maybe you missed it, @Joe, but forum shopping, spending time developing ideas that have no realistic chance of gaining consensus in any form, and ignoring all the feedback you are getting and insisting that, no matter how many times and how many ways this exact same thing has been proposed previously, this time it won't be rejected by the community on both philosophical and practical grounds are also discouraged. Thryduulf (talk) 17:16, 12 December 2024 (UTC)[reply]
Yes, that's exactly the problem with forum shopping. If you keep starting new discussions and refusing to accept consensus, you might exhaust people until you can force your deeply unpopular idea through.135.180.197.73 (talk) 18:31, 12 December 2024 (UTC)[reply]
Because Thryduulf apparently thinks it's a waste of time to do so. And since the purpose of the idea lab is to develop an idea, not propose or build consensus for anything, I tend to agree that chiming in here just to say you oppose something is a waste of (everyone's) time. – Joe (talk) 18:43, 12 December 2024 (UTC)[reply]
How? If I were workshopping an idea to make Wikipedia cause laptops to explode, a discussion that omits opposition to that idea would be useless and not revealing. ꧁Zanahary꧂19:56, 12 December 2024 (UTC)[reply]
Because you're not participating to help develop the idea, your participating to stop other people from developing the idea. Brainstorming is not a debate. Brainstorming an idea does not involve people making arguments for why everyone should stop brainstorming the idea.
To use an analogy, imagine a meeting of people who want to develop a proposal to build a building. People who do not think the building should be built at all would not ordinarily be invited to such a meeting. If most of the meeting were spent talking about whether or not to build the building at all, there would be no progress towards a proposal to build the building.
Sometimes, what's needed (especially in the early stages of brainstorming) is for people who want to develop a proposal to build a building, to have the space that they need to develop the best proposal they can, before anybody challenges the proposal or makes the argument that no building should be built at all. Levivich (talk) 20:13, 12 December 2024 (UTC)[reply]
The issue here is that image filtering for this purpose is a PEREN proposal, with many of the faults in such a system already identified. Not many new ideas are being proposed here from past discussions. Masem (t) 20:27, 12 December 2024 (UTC)[reply]
I don't think this model works for a wiki. There's no committee presenting to the public. This project is all of ours, and if there's so much opposition to a proposal that it cannot be discussed without being overwhelmed by opposition, then I don't see it as a problem that the unpopular idea can't get on its feet. ꧁Zanahary꧂20:43, 12 December 2024 (UTC)[reply]
There's no problem with users voluntarily discussing an idea and how it might be implemented. They should, of course, remain aware that just because everyone interested in an idea comes up with a way to proceed doesn't mean there's a community consensus to do so. But if they can come up with a plan to implement an add-on feature such as a gadget, for example, that doesn't impose any additional costs or otherwise affect the work of any other editor who isn't volunteering to be involved, then they're free to spend their own time on it. isaacl (talk) 19:33, 12 December 2024 (UTC)[reply]
My personal thought on how this should work is image sorting by category, the onus is completely on the user using the opt-in tool to select categories of images they don't want to see. We don't need to decide for anybody, they can completely make their own decisions, and there's no need for upkeep of a "possibly offensive image list." Just Step Sidewaysfrom this world ..... today02:48, 13 December 2024 (UTC)[reply]
It’s interesting but I don’t support it. People don’t necessarily get how categories work. “Sex” isn’t about sexual intercourse, but it’ll be at the top of everyone’s block lists. And blocking a huge over-category like violence will block a lot of totally inoffensive images. In other words, this is too technical for most people and will satisfy no-one while catching mostly false positives. Which is actually worse than all-or-nothing. Dronebogus (talk) 11:19, 13 December 2024 (UTC)[reply]
A problem with this is that the tail may begin to wag the dog, with inclusion on block lists becoming a consideration in categorizing images and discussions on categorizations. ꧁Zanahary꧂15:00, 13 December 2024 (UTC)[reply]
Suggestion: we let those who think this is a good idea waste hours of their time devising a plan, and then we oppose it once they bring it to WP:VPPR. I guess they have received enough feedback and can look through the archives to see why this is a bad idea which has been rejected again and again. It's their choice if they want to add one more instance of this perennial proposal, if they believe that either the opposes here are a minority and they represent the silent majority somehow, or if they somehow can find a proposal which sidesteps the objections raised here. Fram (talk) 11:46, 13 December 2024 (UTC)[reply]
It'd be better for labels to be attached to images and not to inclusions of them
It'd be better to use an existing labelling (e.g. categories, captions) rather than a new system
However it's doubtful if it's feasible to use categories or if they are sufficiently consistent
An alternative could be to maintain a central list of labels
This suggests to me three, not mutually exclusive approaches: obscure everything any rely on captions and other existing context to convey what's shown (which is being discussed at Wikipedia:Village_pump_(proposals)#"Blur_all_images"_switch); develop a gadget that uses categories (possibly more technically complex); develop a gadget that uses a central list (less technically complex, could build lists from categories). – Joe (talk) 12:11, 13 December 2024 (UTC)[reply]
…this is your summary of feedback so far? How about "many editors believe that marking content as potentially sensitive violates WP:NOTCENSORED and the spirit of an encyclopedia?" ꧁Zanahary꧂14:58, 13 December 2024 (UTC)[reply]
That viewpoint has been well-heard and understood, and any actual implementation plan that develops will have to take it into account. isaacl (talk) 17:23, 13 December 2024 (UTC)[reply]
If you don't like it, don't use it. WP:NOTCENSORED applies to features or gadgets just as much as it does to content—Wikipedia should not hide information about optional content filtering extensions from users by excluding it from the preferences tab. – Closed Limelike Curves (talk) 19:00, 19 December 2024 (UTC)[reply]
My main questions would be what the criteria are for deciding what labels to have, and what steps would be taken to minimize the prejudicial effects of those labels (see Question 7 in this ALA Q&A)? (Asking in good faith to foster discussion, but please feel free to disregard if this is too contrarian to be constructive.)--Trystan (talk) 16:49, 13 December 2024 (UTC)[reply]
I think it'd be best if the user sets their own exclusion list, and then they can label it however they want. Anyone who wants to could make a list. Lists could be shared by users if they want. Levivich (talk) 18:20, 13 December 2024 (UTC)[reply]
One option would be to start with an existing system from a authorative source. Many universities and publishers have guidelines on when to give content warnings, for example.[47] – Joe (talk) 19:23, 13 December 2024 (UTC)[reply]
This is a review of what content warnings and trigger warnings exist, not guidelines on when they should be used. It examined electronic databases covering multiple sectors (n = 19), table of contents from multi-sectoral journals (n = 5), traditional and social media websites (n = 53 spanning 36 countries), forward and backward citation tracking, and expert consultation (n = 15), and no encyclopedia. ꧁Zanahary꧂19:46, 13 December 2024 (UTC)[reply]
Yep, that's why I linked it; to show that we have at least 136 potential models. Though if you read further they do also come up with their own "NEON content warning typology" which might not be a bad starting point either. – Joe (talk) 20:02, 13 December 2024 (UTC)[reply]
It seems like getting something running for images is enough of a challenge, both technically and w.r.t to community consensus. – Joe (talk) 07:59, 16 December 2024 (UTC)[reply]
Bet you can't name three encyclopedias that contain a picture of anal sex. Britannica, World Book, and Encarta don't, in any edition. Seems that not having pictures of anal sex is quite compatible with the nature of an encyclopedia. Wikipedia might be the first and only encyclopedia in history that contains graphic images. Levivich (talk) 00:42, 14 December 2024 (UTC)[reply]
But it does make me wonder whether anything that appears only in Wikipedia and not in other general-purpose encyclopedias is accurately described as "the nature of an encyclopedia". That sounds more like "the nature of (the English) Wikipedia". WhatamIdoing (talk) 01:18, 14 December 2024 (UTC)[reply]
Wikipedia has long ago stopped being similar to old general purpose encyclopaedias; it is a sui generis entity constrained only by WP:NOT. We do have massive amounts of specialist topics (equivalent to thousands of specialist encyclopaedias) and try to illustrate them all, from TV episodes to individual Biblical manuscripts to sex positions. —Kusma (talk) 07:40, 14 December 2024 (UTC)[reply]
I believe that the argument is that since Wikipedia is the only (known) general-purpose encyclopedia to include such photos, then their absence could not be "fundamentally incompatible with the nature of an encyclopedia". If the absence of such photos were "fundamentally incompatible with the nature of an encyclopedia", then Wikipedia is the only general-purpose encyclopedia that has ever existed. WhatamIdoing (talk) 02:10, 14 December 2024 (UTC)[reply]
Why shouldn’t we operate from the idea that Wikipedia is the ideal encyclopedia? To me it clearly is. The spirit of an encyclopedia is obviously better served with photos on the article for anal sex than with a lack of them. ꧁Zanahary꧂03:09, 14 December 2024 (UTC)[reply]
Because, as people who have a significant say in what Wikipedia looks like, that would be incredibly solipsistic and automatically lead to the conclusion that all change is bad. – Joe (talk) 06:00, 14 December 2024 (UTC)[reply]
Taken to extremes, all philosophies would pitfall into pointlessness. If we exclude illustrating images because Britannica and World Book do too, then we may as well just fuse with either of those, or shut down Wiki because those others have it covered. Photos of an article subject are educational illustrations, and encyclopedias that lack such photos are weaker for it. ꧁Zanahary꧂06:20, 14 December 2024 (UTC)[reply]
The point is that you shouldn't take an outlier and declare that unusual trait to be True™ Nature of the whole group. One does not look at a family of yellow flowers, with a single species that's white, and say "This one has white petals, and I think it's the best one, so yellow petals are 'fundamentally incompatible with the nature of' this type of flower". You can prize the unusual trait without declaring that the others don't belong to the group because they're not also unusual. WhatamIdoing (talk) 22:47, 16 December 2024 (UTC)[reply]
I honestly don’t care about the other encyclopedias. If they wanted my help, I’d tell them to be more like Wikipedia, including by illustrating educatively without regard for offense, sensitivity, or shock. And when I say censorship is incompatible with encyclopedias, I’m not comparing against an average of extant encyclopedias; I am comparing against the principles and essence of what an encyclopedia is, which is an educational, organized, thorough compendium of important information as derived from reliable secondary sources. I consider any sacrifice from the informing mission of Wikipedia (like hiding some images, let alone marking them as potentially offensive) to be a loss, and I don’t consider making Wikipedia more comfortable or calming to be a benefit. That can be handled by pajamas.com or whatever—or by a Wikipedia fork that balances reader comfort and sensitivity with information. Not this one, though. ꧁Zanahary꧂01:15, 17 December 2024 (UTC)[reply]
The right approach to take here is to use the depicts statement on Commons images (see also c:Commons:Structured data). This should have a fairly high true positive ratio (compared either to picking out specific images or using categories) as the intention of the property is to be pretty concrete about what's appearing in the file (see also c:Commons:Depicts and/or c:Commons:Structured data/Modeling/Depiction - it's not obvious to me which is the Commons preference for how to depict things). You'll need to figure out which Wikidata items you want to offer which indicate a screened image, but that can start in the penis, Muhammad, internal organ, and sex directions and go from there. The gadget will probably want to support querying the subclass chain of the Wikidata item (property P279) so that you can catch the distinction between any penis and the human penis. My impression of the problem in using depicts statements is that the structured data work on Commons is much younger than the categories work is and so you're probably going to end up with more false negatives than not. It's a wiki though, so the right way to improve those cases should be obvious, and can perhaps even start with a database query today tracking which images used in our articles do not yet have depicts statements. The other problem this direction is that it doesn't take into account images hosted locally since those don't have structured data, but I anticipate the vast majority of the kinds of images this discussion entertains are free images. Izno (talk) 10:09, 14 December 2024 (UTC)[reply]
As I said, the work is much younger. There are also detractors in that community. Yet, I expect that there are many people who do use them, and we can ourselves work just on the set of images that are used in our articles. I imagine that set is both small and queryable, especially for potentially offensive images, which itself is a much smaller set than the nearly 7 million articles we have lying around. Izno (talk) 02:39, 17 December 2024 (UTC)[reply]
This is sounds like a very promising approach POV, thanks. I have to say I also had the strong impression that the "depicts" feature was abandonware, but then again maybe having a concrete use for the labels will prompt people to create more of them. – Joe (talk) 08:06, 16 December 2024 (UTC)[reply]
It seems to get used a lot be people using c:Special:UploadWizard – half of uploads? I have the impression that using it might increase the likelihood of the tagged images being found in relevant searches, but I don't know why I believe that. But since I believe it, I'd encourage people to use it, at least for images that they believe people would want to find. WhatamIdoing (talk) 22:50, 16 December 2024 (UTC)[reply]
I don't see consensus in this discussion to create a new tagging/labelling system or to use existing Commons categories to hide images. People can argue until they're blue in the face, but the proposal(s) will ultimately be rejected at a community-wide RfC. That aside, I don't believe anyone here is opposed to having a toggle button that blurs or hides all images, right? The toggle switch could be placed in the Settings menu (on mobile view) or Appearance menu (on desktop view), and it would be switched off by default (meaning if editors want to blur/hide all images, they would have to manually switch it on). Only the WMF team has the ability to create such a feature, so that logged-out users can use it and logged-in users won't need to install user scripts. That idea could be suggested at the m:Community Wishlist. Some1 (talk) 15:31, 15 December 2024 (UTC)[reply]
@Some1: This is the idea lab. Discussions here are explicitly not about developing consensus one way or another (see the notice at the top of this page). The blur all images approach is being discussed elsewhere (linked several times above) and I would prefer to keep this on the original topic of labelled content warnings. – Joe (talk) 08:01, 16 December 2024 (UTC)[reply]
Probably some of why you're getting so much pushback is because of the first sentence of this section, where you refer to the previous discussion and say "there actually appears to be little to no opposition to developing opt-in features to help readers avoid images that they don't want to see", which is not at all the mood of that discussion. I saw one person saying that making it opt-in would sway them and a great many people saying that the very existence of such a system would be ripe for abuse. Also, this is the Idea Lab, it is for developing ideas, not staying fixed to the original proposal. Please stop bludgeoning the discussion by repeating your original proposal and allow people to develop a form of the concept that is more likely to have community support, such as blurring all images.135.180.197.73 (talk) 23:54, 17 December 2024 (UTC)[reply]
I feel like this section is trying to give false legitimacy to a widely opposed idea by saying the longstanding consensus that “content warnings and censorship are bad” (and by extension the opinions of anyone supporting that position) is illegitimate because it’s not “constructive”. People have a right to not help you “construct” an idea that’s against policy and been rejected time and time again. If you don’t want negativity don’t make a controversial proposal. Dronebogus (talk) 15:40, 15 December 2024 (UTC)[reply]
I find it curious how nobody ever calls opinions they support “bludgeoning”. Levivich and WhatamIdoing have contributed almost as much, and as repetitively, in agreement with you. I know idea lab is supposed to be all about open-mindedness and positivity but this is a perennial proposal that clearly violates WP:NOTCENSORED and WP:NPOV, two of the most fundamental policies of Wikipedia. You’re building something up that will inevitably get shot down if it actually made it to RFC. Dronebogus (talk) 00:00, 17 December 2024 (UTC)[reply]
Joe Roe, I remember reading somewhere on a wikimedia project (maybe it was Phabricator) thoughts about implementing a tool called OpenNSFW, which from my non-technical understanding, it's able to look at an image and label it as safe or NSFW. I don't know how accurate it is, whether it could be implemented on such a scale, etc, etc but I thought it might be relevant. JayCubby00:41, 19 December 2024 (UTC)[reply]
OpenNSFW is not something I've heard of previously. A few minutes research and all I can tell you about it is that it categorises images as either "safe for work" or "not safe for work" the latter being images containing either "pornography" or "nudity" but nowhere I've found are those terms defined. I was not able to find any independent analysis of how accurate OpenNSFW is, but other machine learning algorithms that attempt the same task seem to have best-case results between 79% and 94% accuracy. I was not able to find any indication of detail about how accuracy was determined beyond "it's subjective" and one inaccurate result being an image of a clothed young woman sat on the ground leaning against a wall playing a guitar being classed as not safe for work by one model (that was not OpenNSFW), my guess is that this was due to low contrast between the guitar and the woman's skin tone. Even if OpenNSFW equals the 94% success rate of the best model tested, that still leaves 6% of images wrongly categorised. Even in extremely unlikely case the errors were all safe-for-work images wrongly categorised as not-safe-for-work, this requires the viewer to have the same (unknown) definitions of "pornography" and "nudity" as the model's developers and for those two categories to cover 100% of images they regard as not safe for work (e.g. they are happy to view images of violence, drug use, medical procedures, war, disease, death, etc). It is also worth noting that these models are described as "computationally expensive", so are unlikely scale well. Unless someone is able to show that this model performs very significantly better than the others reviewed (on all metrics), this is not practical for Wikimedia projects even if this sort of censorship was something we would entertain (which it is not). Thryduulf (talk) 01:51, 19 December 2024 (UTC)[reply]
Let's say, for the sake of argument, that OpenNSFW could correctly label 80% of images deemed to contain nudity (which is what I think it's mostly trained for). It probably doesn't make sense to scan all images on Commons, a good deal of categories could be excluded (like the literally millions of pictures from the ISS, or ethnographic toplessness). Other offensive subjects or categories (graphic violence, gas gangrene) could be blanket-included and resulting false positive excluded by hand (let's say experienced users could apply for a patrol-type right).
Once again you are simply assuming that your definitions match other people's definitions. For example, many people who object to images of nudity do not distinguish between "ethnographic nudity" and other types, but many people do - who is right? Anything requiring human input (e.g. your "patrol-type right" suffers all the same problems that you are trying to solve by using machine learning in the first place (see extensive documentation of these problems in this discussion). Thryduulf (talk) 02:39, 19 December 2024 (UTC)[reply]
Wikipedia, at least the English version, is Western-leaning. In the West, there's some distinction between ethnographic and non-ethnographic toplessness and their perceived offensiveness, but I'm not trying to rigidly define offensive material, as a broad definition would be impossible. I don't want to censor everything possibly objectionable, only what readers of an encyclopedia really wouldn't expect to jump out at them. On the patrol bit, I'm saying there will be false positives and negatives, but likely a small enough number to be correctable manually. JayCubby02:49, 19 December 2024 (UTC)[reply]
Wikipedia, at least the English version, is Western-leaning this is a bug. We attempt to avoid systematic biases like this because our goal is to create a neutral encyclopaedia, not a western-leaning encyclopaedia. In the West, there's some distinction between ethnographic and non-ethnographic toplessness and their perceived offensiveness[citation needed] while this is true for some western people in some western places, it is not true of all western people in all western places. For example the distinction would matter in a UK university geography lecture, it would not matter in a UK university maths lecture. , I'm saying there will be false positives and negatives, but likely a small enough number to be correctable manually. If you think that a 20% incorrect categorisation rate (or even 2%) would produce manageable numbers then you haven't appreciated how many images are on Commons. You have also ignored (again) all the problems that are not about numbers. Thryduulf (talk) 03:11, 19 December 2024 (UTC)[reply]
On the accuracy bit, the accuracy numbers appear to be for people alone based on the paper I found. This would be a silly thing to implement if it falsely flagged tens of millions of images, .
On the distinction bit, I'm saying people would be less offended by the images in Himba than Topfreedom.
On the numbers aspect, yes, there are 99,475,179 images on Commons, but by my very rough estimates the vast majority of those could be excluded without creating many false positives.
I could do an in-depth analysis of this, yes, but it's a big enough subject that the only effective way to approach it is through numbers. JayCubby03:26, 19 December 2024 (UTC)[reply]
I'm saying people would be less offended by the images in Himba than Topfreedom. and I'm saying that while this is true for some people (group A) it is false for other people (group B). People from both groups will be using this filter. If you do censor ethnographic nudity then group A will rightly complain about being denied access to appropriate content (false positive), if you don't censor ethnographic nudity then group B will rightly complain about seeing inappropriate content (false negative). You cannot both censor and not censor the same image. Which group do you choose to side with? How are you explaining to the other group that their standards are wrong?
yes, there are 99,475,179 images on Commons, but by my very rough estimates the vast majority of those could be excluded without creating many false positives. even if you exclude 95% of images, that is still almost 5 million that you need to deal with by hand. If 95% of the 5% are automatically categorised correctly and you somehow don't need to check them, that still leaves about 250,000 images. All this assumes that there is no miscategorisation, no new images or categories, no renamed categories, and no instances of categories in your exclude/include sets being merged together (all but the last is provably false, the last is unknowable either way at this level of detail). Whose standards are the patrollers applying to the images they check? Why those standards? What happens if patrollers disagree?
the only effective way to approach it is through numbers. except considering only numbers is not effective, because the vast majority of the problems with this and similar proposals are nothing to do with numbers. Thryduulf (talk) 03:44, 19 December 2024 (UTC)[reply]
On the first, I think there should be a minimum of images that should be obscured. Maybe select ones on anatomy, I don't know.
On your second point, I'm not too sure of Commons' category structure, I'd like to see numerical distribution of images into different categories. JayCubby03:49, 19 December 2024 (UTC)[reply]
The Commons category structure is so disorganised that the backlog for images lacking any categories is six years old. (Not a knock on Commons editors, it's just such an overwhelmingly huge yet entirely thankless task.) Any system with heavy reliance on those categories would be at the whims of this. CMD (talk) 04:29, 19 December 2024 (UTC)[reply]
The following is a (genuinely) brief overview of Commons categorisation with relevance to this discussion. Commons categories come in multiple types.
Some categories are not relevant to image subject (e.g. user categories, copyright licenses, files by copyright license, project administration categories, etc).
Meta-categories - i.e. ones that should contain only subcategories (e.g. Commons:Category:People with objects by material). Note that many of these incorrectly contain images that should be in subcategories.
All these categories (and their subcategories) should be sub-categories (at some level) of Commons:Category:Topics, but I don't know if they all are. I also don't know whether that category contains any non-content subcategories, nor whether there are root categories that should contain all and only non-content categories (my guess is that in practice there isn't).
Mid-level categories that contain both images and sub-categories
Bottom-level categories that contain only images.
Of those categories that contain image, some contain only a single image others contain thousands (although no category should contain this many, there is no exact threshold for when a category needs diffusion, no guarantee it will get diffused, and some categories need perpetual maintenance.
Some categories contain only images that unambiguously show nudity, some contain only images that unambiguously don't show nudity, others contain both of the above and images that are ambiguous (e.g. Commons:Category:Fantasy Fest 2012, is opaque body paint nudity? what about translucent body paint? nipple pasties?).
this is a bug. We attempt to avoid systematic biases like this
In some cases it's a bug. In other cases, it's just about being useful. enwiki is meant for English-speaking internet users. If we randomly rewrote 10% of each page in Chinese, that would be less "linguistically biased", but very annoying for the 99% of enwiki users who can't read Chinese. In the same way, a filter should try to match the preferences of the median English-speaking internet user (on a "prudishness" scale). We'll never do a perfect job of that, but we can definitely do better than implicitly bowing to the preferences of the most extreme 1% of users (who think all images should be treated as safe-for-work). – Closed Limelike Curves (talk) 03:30, 21 December 2024 (UTC)[reply]
a filter should try to match the preferences of the median English-speaking internet user (on a "prudishness" scale). 1. Why? 2. What is a "prudishness scale"? 3. How are you determining the median on it? 4. How are you assessing each image on the scale? Thryduulf (talk) 12:34, 21 December 2024 (UTC)[reply]
The median is “whatever I personally consider it to be”; it’s a generalization of something Ellen Willis once said: “In practice, attempts to sort out good erotica from bad porn inevitably comes down to 'What turns me on is erotic; what turns you on is pornographic.” Dronebogus (talk) 09:26, 22 December 2024 (UTC)[reply]
This is exactly the opposite of my point (see below). The median is whatever readers consider it to be, completely independent of my opinions. My opinion is that no image should be censored or blurred. If the tool I proposed below existed, I'd personally vote "0 years old" on every image (because I don't think anything should be censored). But that's my personal opinion, as an extremely culturally liberal/libertarian kind of person. It's not my place to impose that on the readers. – Closed Limelike Curves (talk) 19:21, 22 December 2024 (UTC)[reply]
For #1, see median mechanism and an introduction to mechanism design/collective choice theory for an overview of desirable properties. In a sense, the median identifies the unique "consensus" position, because a majority of voters will oppose any other setting (a majority of voters will prefer the median to the alternative). For #2-4: a prudishness scale is a scale that measures prudishness. A simple example would be to ask every reader "at what age would you let your kids see this image?" For each image, we calculate the median to get that image's age rating. Users then get to select what age ratings they want to hide in their preferences.To clarify, this is a thought experiment; I'm not suggesting the WMF create an actual polling tool just for this. (Though I'd be very interested in it if we could use it for other things too, e.g. readers rating articles on their quality or neutrality.) Instead, my point is:
You can give a neutral definition for whether an image is appropriate or not, which has nothing to do with any editor's personal opinion; it's just a statement about readers' preferences. Every image already has an "age rating" (even if we haven't measured it), just like how every politician has an "approval rating" (even if we haven't polled anyone).
Having zero image filtering isn't some kind of magic "neutrality" that keeps us from having to make difficult choices—we're still making all of those decisions. We're just choosing to take the most extreme position possible on every image, by setting all of their ratings to "0 years old" (regardless of what readers think). That's a very opinionated decision—it's just as "neutral" as banning every image because someone might consider it inappropriate.
As you've now admitted you're just wasting everybody's time here with a thought experiment rather than an actual proposal, I shan't go into detail about all the ways you're comment is fundamentally wrong, but the most basic is that a majority of voters will prefer the median to the alternative is intended to apply to voting for a political candidate (which we are not doing here) and assumes a one-dimenional spectrum and, as the article states It is impossible to fully generalize the median voter theorem to spatial models in more than one dimension. What images to censor is almost fractally-dimensional - even if you take what appears to be a single dimension at first glance, say nudity, you quickly realise that you need to split that down further - the subject's age, gender, topless/bottomless/full nudity, pose, context (e.g. ethnographic or not), medium (e.g. painting, photograph, cartoon, sculpture, diagram, etc), prominence in the image, etc. all matter to at least some people, and they all vary differently. e.g. a sculpture of a topless elderly adult male hunched over is very different to an impressionist painting of a beach scene with a topless pre-pubescent girl in the background is very different to a medical photograph of a topless transgender 20-something man immediately post top surgery, etc. Thryduulf (talk) 18:53, 23 December 2024 (UTC)[reply]
a filter should try to match the preferences of the median English-speaking internet user (on a "prudishness" scale). I actually do not understand how one can think this is the job of an encyclopedia. ꧁Zanahary꧂20:12, 22 December 2024 (UTC)[reply]
Because you can change the settings to let you see whatever you'd like? This is just my suggestion for how to choose a sensible default—default to whatever most people would pick anyway. – Closed Limelike Curves (talk) 22:00, 22 December 2024 (UTC)[reply]
I explicitly do not. If a majority of people don't want to block any images for people of any age, the median age rating for all images would be 0 in the mechanism I described above. – Closed Limelike Curves (talk) 00:19, 24 December 2024 (UTC)[reply]
Though there is a point at which too much information, to the point of irrelevancy, can be given. We, I fear, are approaching that point with our use of images at times. JayCubby18:52, 23 December 2024 (UTC)[reply]
At what point does a conversation at Idea Lab get shut down as unproductive? Because at this point all I’m seeing is repetitive debates about what constitutes “NSFW” and how you would implement a filter on a technical basis (both without anything resembling consensus). These are the same problems that every other content warning proposal has run into and no groundbreakingly novel solution has been found during this very lengthy discussion. I’m going to say it: Toby was a better proposal than this. It was at least a genuinely original approach even if it was bizarre and ludicrous. Dronebogus (talk) 08:48, 21 December 2024 (UTC)[reply]
Making voluntary "reconfirmation" RFA's less controversial
Recently, there have been two "reconfirmation" RFA's from ex-admin candidates whose resignations weren't under a cloud. The RFA's received quite a few comments about the utility of the RFA's themselves. These are Worm That Turned's recent RFA and the ongoing RFA from Hog Farm. In both, there are multiple recurring comments, such as:
The candidate could/should have just gone to WP:BN to request the tools back
The reconfirmations were/are a "waste of community time"
The reconfirmations are a good thing, in order to increase transparency and give feedback to the candidate
I'm opening the topic here so that we can hash out ideas of making these situations less controversial, as this was a big talking point in both RFA's, and both sides are (in my view) making good points.
My initial proposal to improve this situation would be enacting the following:
Admins who resigned under their own volition (not under a cloud) who want the role back should be discouraged from opening formal RFA's and instead encouraged open a request at WP:BN
The standard holding period between a re-syssop request being posted on WP:BN and it being enacted should be increased from 24 hours to 5 days.
Whenever there is a resyssop request, a short notice should be posted to WP:AN and in WP:CENT. This notice does not explicitly ask for public input, or encourage anyone to support or oppose - just merely makes the request more visible. Anyone is free to comment on the topic at WP:BN, if they feel it necessary.
The request at WP:BN is enacted at the discretion of the bureaucrats, per the process they currently use, taking any comments that arise into account. It is explicitly not a vote.
This proposal would allow resyssopings to be more open and allow discussion when necessary, without being as public and time-demanding as a full RFA. Any thoughts on this? BugGhost🦗👻15:18, 15 December 2024 (UTC)[reply]
Oppose the first bullet. This seems to presuppose that reconfirmation RFAs are a "waste of community time" or similar, a position I cannot agree with. Reconfirmation RFAs definitively show whether someone does or does not have the trust of the community to be an admin, this is a Good Thing and they should be encouraged not discouraged. RFA is not overloaded (far from it), and nobody is compelled to participate - if you don't have anything useful to say, and don't want to spend any time investigating whether they are trustworthy or not then don't: just trust your fellow community members in the same way that you trust the 'crats. I don't oppose the other points, but absent evidence of a problem that needs to be solved, I don't see any particular benefit in them. Thryduulf (talk) 15:43, 15 December 2024 (UTC)[reply]
The first bullet wasn't intended to concede that they're "a waste of community time" - I personally don't think they're that useful, but I think calling them a waste of time is a bit far, as I do agree with their intended purpose. The reason why it was in quotes was because it's the phrase being debated at the current RFA's comments. The first bullet is simply intended to just say "the venue should be WP:BN, not RFA", and the subsequent bullets are just to make BN more accommodating for that purpose, and attempts to draw the attention of those that do have something to say. This proposal isn't to stop the general concept of reconfirmation or public scrutiny when resyssoping, just to alleviate the concerns that have been raised by a significant number of people in both RFAs. BugGhost🦗👻15:59, 15 December 2024 (UTC)[reply]
To further clarify: one intent of this proposal is to make making a BN request a more transparent and accountable route - less (as Hog Farm put it) "back-doorsy", in order to make all resyssopings go under a public lens, so that ex-admins don't feel like they should go under a full RFA to be fairly reapproved. If ex-admins are opening RFAs because they think the BN route doesn't give enough accountability or visibility, we should bake more accountability and visibility in. BugGhost🦗👻17:00, 15 December 2024 (UTC)[reply]
If a request needs more accountability and visibility than BN, then RFA is the correct venue to achieve that. Instead of making BN more like RFA, we should be encouraging editors to use RFA instead. This will, as others have pointed out, hopefully have the side effect of decreasing the problems at first-time RFAs. Thryduulf (talk) 21:50, 15 December 2024 (UTC)[reply]
I don't think there's anything here that needs to be fixed. Perhaps over time, the RfA route will become more popular, in which case we may choose to do away with the BN route. Or the opposite will happen, in which case no changes are necessary. Either way, this is much ado about nothing at the moment. – bradv15:53, 15 December 2024 (UTC)[reply]
I personally don’t see a major problem with re-RFA’s remaining an occasional thing where a former admin prefers it, but if a large number of editors do I think your proposal is a nice way to solve that while providing a slightly more deliberative process for returning admins who feel uncomfortable presuming that there is still consensus for their continued use of the tools.
Alternatively, we could do a bit of a petition process like with recall for editors who have been gone for more than a short, planned, absence. If few editors oppose it, the bureaucrat-led process can take place, but if more than some threshold of editors call for it, a re-RFA is required to confirm the return of tools.
That seems kinda potentially unpleasant though, so I’d support the status quo as my first choice, and your proposal as a second choice, and something like what I mentioned as a distant third.
I do think a humility before the will of the community is laudable in admins, and that the occasional easy-confirm re-RFAs would probably contribute to reducing the temperature of RFAs generally if they weren’t getting bogged down with arguments about the process. — penultimate_supper 🚀 (talk • contribs)18:09, 15 December 2024 (UTC)[reply]
Personally, I think RFA would be less toxic in general if it was less of a special occasion, and so I don't see any reason to limit these. The people who are upset by these RFAs are people whose opinions I usually both respect and understand, and in this case I can respect them but continue to not understand them. Maybe this is my problem; I'm open to being convinced. -- asilvering (talk) 18:40, 15 December 2024 (UTC)[reply]
I follow Asilvering on this point – if we make RfAs less of a special occasion, it will, down the line, have a positive effect for everyone involved: prospective new admins, admins going through a RRfA, and regular editors now having less pressure to !vote in every single RfA. Chaotic Enby (talk · contribs) 22:08, 15 December 2024 (UTC)[reply]
What if we fast-track them? Uncontroversial reconfirmations don't need to be a week; let's just let the 'crats snowclose them after 48 hours if they can be snowclosed and have right of resysop. theleekycauldron (talk • she/her) 18:52, 15 December 2024 (UTC)[reply]
Let them redo RfA if they want. Editors need to chill out. For those worrying about "straining editor time" or whatever, there's no need to participate in an RfA. You don't have to follow it. It doesn't have to take any significant portion of your time at all. The 'crats are good enough to know how to handle whatever arguments are made by those who give them and come to a decision. Plus, it's not like this is a super common thing. We just happened to have a couple re-admins in a row. Toxic behavior at RfA is definitely a thing and worrying about re-RfAs contributes a bit to this problem. Jason Quinn (talk) 21:26, 15 December 2024 (UTC)[reply]
I don't see what the controversy is. Requesting the bit back at RfA has always been an option, and I applaud anyone who is willing to go through that again. There are very few people interested in going through RfA, so it is not overloaded and is far from a "waste of time." Anyone who believes it is a waste of their time is free to ignore it, just like everything else on Wikipedia. The only thing making these "reconfirmations" controversial is that a very loud minority is saying they are. WP:BROKE is something those people really should read and take to heart. — Jkudlick ⚓ (talk)21:57, 15 December 2024 (UTC)[reply]
I agree with a lot of the comments that have already been made. I don't think that this has become enough of a trend that we need to fix anything now, and I very much like Asilvering's comment that we should try to make RfA less of a special occasion. I've been having a kind of "meh" reaction to the complaints about wasting the community's time. I'm ambivalent about allowing snow closes. On the one hand, it might make things easier, but on the other hand, once a candidate decides that they want community feedback, we might as well let the community feed back. I also want to say that I'm against the bullet point about increasing the amount of time at BN: I think that would be counterproductive. --Tryptofish (talk) 21:59, 15 December 2024 (UTC)[reply]
I don't agree with turning the discussion at the bureaucrats' noticeboard from one that examines if the administrator resigned in order to avoid scrutiny into one where the general community discusses if it trusts the editor in question to regain administrative privileges. (The first question is narrowly focused on the sequence of events leading to resignation, while the second is broad, covering all activity both before and after resignation.) While it would be nice if every administrator had a perfect sense of the level of community trust that they hold, in practice I can understand administrators having doubts. I agree with Barkeep49's remarks on their talk page that we should be looking for lower costs ways for the admin to have a better idea of the degree of trust the community has in them. isaacl (talk) 00:46, 16 December 2024 (UTC)[reply]
There is no need for more complicated rules here. If you are worried of 'wasting' your time on a reconfirmation RFA then just ignore it. People will waste their time writing comments about how the RFA is a waste of time whilst continuing to reply to others, further wasting time. Clearly their time isn't all that important but instead they feel some sort of obligation to comment on every RFA, that or they like arguing/opposing. Traumnovelle (talk) 02:57, 17 December 2024 (UTC)[reply]
Encouraging reconfirmation RFAs
At Wikipedia:Village pump (policy)#RfC: Voluntary RfA after resignation I commented that reconfirmation RFAs shouldn't be made mandatory, but they should be encouraged where the time since desysop and/or the last RFA has been lengthy. Barkeep49 suggested that this is something that would be worthy of discussion here (VPI) and I agree with that. If there is enthusiasm for this suggestion, an RFC to modify Wikipedia:Administrators#Restoration of the admin tools to include the encouragement can be drafted (unless this discussion shows the addition to be uncontroversial, in which case it can just be added). I do not propose to explicitly define "lengthy", that should be left entirely to the judgment of the administrator concerned, nor to make the statement stronger than "encouraged". Thryduulf (talk) 22:03, 15 December 2024 (UTC)[reply]
I definitely agree with the idea. I don't think an exact time period should be specified (as it isn't mandatory either way), but something in the ballpark of "several years" could be a good benchmark. Chaotic Enby (talk · contribs) 22:06, 15 December 2024 (UTC)[reply]
For the same reasons that editors are saying, above the section break, that this probably doesn't need to be fixed at this time, I see this, too, as something that probably does not need to be fixed. --Tryptofish (talk) 22:12, 15 December 2024 (UTC)[reply]
I have no problem with this proposal, nor would I attempt to define "lengthy" as it draws a relatively hard line where someone could complain that Former Administrator Example resigned the bit x+1 days ago and shouldn't be allowed to go through BN, or resigned x-1 days ago so shouldn't "waste the community's time." If we are to require an RfA after less time than is already prescribed at WP:ADMIN, that would require a separate RFC because it would be changing a policy and would absolutely be controversial. — Jkudlick ⚓ (talk)02:15, 16 December 2024 (UTC)[reply]
As Thryduulf noted I support this concept and think the generic, intentionally non-prescriptive, "length" is the right way to do it. Best, Barkeep49 (talk) 16:28, 16 December 2024 (UTC)[reply]
I support this. I feel like we're asking people to walk a tightrope when we complain that adminship is a life appointment but also criticize people for confirming that they still have community support/confidence. Valereee (talk) 22:12, 16 December 2024 (UTC)[reply]
I just wrote a rather long comment on that other RfC wherein I suggest that we should in fact discourage reconfirmation RfA's. At minimum, if we're going to put some formal wording up about it, I think we should be encouraging folks to do a deep think before doing a confirmation. The wording I used was take some introspection and humility to ask yourself: is it worth me inviting two or three hundred people to spend part of their lives to comment on me as a person? Personally, I'm a much bigger fan of what Barkeep49 has been doing recently, which is asking folks for genuine feedback about how he's doing as an admin. I don't think RfA is very well built for genuine feedback. I'd rather suggest that if folks are re-upping after years of being away, they seek out friends/mentors and try to get a sense for what has changed, and how they could improve, rather than running the gauntlet and us losing an admin because they're slightly out of touch. CaptainEekEdits Ho Cap'n!⚓03:46, 17 December 2024 (UTC)[reply]
I would much rather someone fail an RFA than BN resysop someone who doesn't have the trust of the community. Seeking feedback from others is completely compatible, and indeed recommended (see eg. WP:ORCP) prior to an RFA. Your comment about introspection and humility implies that every RFA is a selfish abuse of others' time, and I cannot disagree more. Thryduulf (talk) 09:03, 17 December 2024 (UTC)[reply]
Perhaps I ought have appended the unsaid bit: is it worth having two or three hundred people comment, when you've already had two or three hundred people comment in the past and already gained their trust? Like, you really need to think "should I do this time consuming thing again, after having already done this time consuming thing?" I didn't meant to suggest that RfA was inherently bad. But perhaps we're arguing in the wrong direction anyway. My overall concern here is that for years and years it's been okay to hang the tools up for a bit, and then come back without hassle. But if we implement a social standard to re-run, we're going to curtail some returns, because RfA is a massive time sink for the admin too. If the community says "you should rerun after hanging up the tools", that would encourage me to never hang up the tools. My RfA sucked and I never want to run one again. I'm sure I'm not alone. By encouraging confirmation RfAs, we discourage hanging up the tools. CaptainEekEdits Ho Cap'n!⚓18:03, 17 December 2024 (UTC)[reply]
My own resignation during Framgate did feel a bit cheap (almost phoney as a political statement) because I knew I could just get the tools back at BN at any time. So while I am not currently interested in running RfA again, I have a lot of respect for the people who do. Note also that rules for restoration at BN have been tightened over the last decade because a lot of people felt it was not appropriate to just "waltz back in" and get the bit after years of absence. —Kusma (talk) 19:59, 17 December 2024 (UTC)[reply]
@CaptainEekis it worth having two or three hundred people comment, when you've already had two or three hundred people comment in the past and already gained their trust? Yes. Especially, if it was a long time in the past, or you've been away for some time, it is a good thing to check whether you still have the community trust. For example a lot of things have changed in the 9½ years since 53 people supported my RFA in 2005. Either a reconfirmation RFA will run smoothly, in which case it wont be hell, or it will be controversial in which case a direct resysopping at BN would have been inappropriate. Thryduulf (talk) 20:55, 17 December 2024 (UTC)[reply]
"[I]s it worth having two or three hundred people comment, when you've already had two or three hundred people comment in the past and already gained their trust?" But that presupposes that the user base/admin corps will be mostly the same group of people as it was the first time. The admin who nominated me all the way back in 2007, for instance, retired almost a year ago after a long period of less and less activity. And if I were to look through my own RfA, I'm sure I'd find quite a few !voters also long gone for whatever reason.
For an admin requesting the tools back after a long absence (which was not the case with Hog Farm's recent request), I can see where maybe we might prefer them to demonstrate the trust of the current community rather than one of a different era with different norms. We ought not to let dead hands win today's table. Daniel Case (talk) 05:27, 18 December 2024 (UTC)[reply]
I don't see how it would be useful. It's a nearly sure bet that anybody who would voluntarily go through a reconfirm RFA and intends to remain active is already a keeper. North8000 (talk) 21:07, 17 December 2024 (UTC)[reply]
I was inspired by the sudden resurgence of the “content warnings/hide offensive images” idea (a few sections up and recently discussed at Wikipedia:Village pump (policy)) to propose this. While it’s currently acknowledged that people face an uphill battle (or rather a battle up a sheer cliff) trying to promote these ideas, I think the current situation fails to address the fact that most of the listed proposals were rejected for very good reasons and should probably stay that way. I don’t know how exactly you would limit the ability to re-litigate them besides promoting some to outright policy, but was wondering if anyone supported this idea. Dronebogus (talk) 00:12, 17 December 2024 (UTC)[reply]
I think it's useful to point people to previous discussion so they can see all the potential challenges. For better or worse, anyone is free to brainstorm ways to try to overcome those challenges, if that's what they want to do. Until they are actually seeking consensus support for a specific proposal, it's their own time they're spending. And some initiatives can be done as standalone projects that don't affect anyone, so don't need consensus support. (For example, there are a lot of challenges in getting a discussion reply script/gadget to work well with all supported browsers. But anyone can and has implemented their own scripts, without getting consensus from the community on which browsers are supported or the included features.) isaacl (talk) 00:26, 17 December 2024 (UTC)[reply]
I think that the current page does a good enough job of explaining why the previous attempts were rejected. What I would like on that page is a few examples of the actual discussions where they were rejected. I think that this would be useful for anyone attempting to propose these again, and especially useful in ensuring that if someone *does* try again it's not with the exact same bad argument that already failed. Loki (talk) 00:54, 17 December 2024 (UTC)[reply]
I think we can just be faster to close such discussions, or better yet, not comment on them beyond "this is a perennial proposal. here's why it won't work," with an understanding that most perennial proposals are coming from new users. Mostly, folks who propose them should be given an education about perennial, and then the thread closed unless they have a new angle or it actually starts to garner support. CaptainEekEdits Ho Cap'n!⚓04:06, 17 December 2024 (UTC)[reply]
No, let's not. The point of WP:PEREN is informative, not prohibitive, and if someone has an actual new argument to raise in favor of one of the proposals then they should do so. What would probably help more is if people were better about pointing out "this is a perennial proposal, see [section link] for reference to past discussion and why it was rejected. If you have new arguments to raise, please do, but please avoid wasting everyone's time repeating old arguments unless you have strong reason to believe consensus has changed." instead of diving in to to re-argue it for the nth time. Anomie⚔04:57, 17 December 2024 (UTC)[reply]
This would blatantly contradict WP:CCC as well as the purpose of this pump. Engaging in an open discussion of if and how an as-yet-unadopted idea can be improved is not "litigation" and does no harm. As an aside, I am impressed that you manage to vociferously object to allowing people to restrict what images their kids can see but be in favour of restricting what ideas we're allowed to talk about. – Joe (talk) 10:07, 17 December 2024 (UTC)[reply]
Of course I vociferously object to your censorship proposals, even if you try to claim they aren’t censorship, because Wikipedia is not censored! I’m not even trying to restrict “what we’re allowed to talk about”, I’m trying to prevent endless re-litigation of bad ideas that failed for a reason. It’s not like we’re allowed to just talk about anything we like here anyway— see WP:NOTFORUM, WP:CIVIL, WP:ASPERSIONS, WP:BLP, Wikipedia:NOTFREESPEECH, etc. Dronebogus (talk) 02:07, 19 December 2024 (UTC)[reply]
The German Wikipedia has binding decisions, very unlike our WP:CCC. That has advantages and disadvantages. Overall, I think our model here where perennial proposals are socially discouraged but not limited by another policy, works better. (And I have seen consensus change on a few things that seemed immutable). So no, I don't think any stronger defences against perennial proposals should be implemented. —Kusma (talk) 10:46, 17 December 2024 (UTC)[reply]
I think our current system of usually WP:SNOW-closing such discussions unless there's actually potential it can change works well; it allows the topic to be broached (*again*) but doesn't waste too much time. Cremastra 🎄 u — c 🎄 01:14, 21 December 2024 (UTC)[reply]
I doubt this will change the fairly clear consensus here against any kind of restriction, but if I were to propose a clear policy on this it’d be something like “unless a proposal is unambiguously novel in its approach to a perennial issue, it will be shut down at the discretion of any uninvolved admin”. Basically if it’s just “the same, but again”, it gets snowed on. Dronebogus (talk) 09:08, 22 December 2024 (UTC)[reply]
I'd broadly agree with that, but I'd phrase it is as something like requiring proposals to clearly explain how it is different to previously rejected proposals and/or clearly explain what has changed since this was previously proposed that now mean the previous objections objectively no longer apply. For example, if a proposal was rejected because it was technically impossible but that is no longer the case or the reason for rejection was because we don't allow X but we now do, then discussion could be productive. Thryduulf (talk) 11:36, 22 December 2024 (UTC)[reply]
Opt-in subscription status transparency
The subscription feature is great, thanks to the team that built that. This has spawned some over- or under-pinging based on editors' uncertainty about whether another editor is or isn't subscribed, and doesn't want/does want to be notified, including frequent in-discussion requests to be pinged (or the reverse). The uncertainty makes us wonder if we are annoying someone by pinging them (clearly we are, sometimes) or whether we are failing to appropriately notify someone who ought to be notified (this also happens).
This seems less than optimal, and a technical solution ought to be able to fix it. I'd like to propose an enhancement for subscription status transparency that would allow me the option to tick a box (or take some other action) that would make my subscription status in thatone single discussion visible to others in some fashion. The first method that occurs to me is some kind of change at or near one signature(s) in the discussion, perhaps an appended icon or tag. I am subscribed to this discussion, and as an example solution, I have interpolated Unicode U+1F440 ('Eyes' symbol) into my sig (with a tooltip on the icon) as an indicator that I am subscribed to this discussion, but there may be other or better ways.
Possibly this could be accompanied by a further enhancement involving a new Preferences setting Checkbox (default unchecked) called 'Enable subscription transparency', that if checked, would flip it to opt-out, such that all my subscribed discussions would be tagged for subscription transparency unless I took action to turn it off at a given discussion. (Note that this Preference setting would not automatically subscribe me to any discussion, it would just make my subscription status transparent.) And, um, finally, please don't ping me; I am subscribed. Mathglot (talk)👀21:50, 21 December 2024 (UTC)[reply]
Of course, that goes without saying, and should remain that way. But if I wish to share it, then that is my choice, is it not, just like telling everyone: "I am subscribed to this discussion" is my choice. The proposal is simply a more economical method of saying what I wish to say, and a time-saver. It's possible I wasn't clear that the main proposal would apply to *a single discussion*, and I have made a small redaction to that end. Mathglot (talk) 23:30, 21 December 2024 (UTC)[reply]
Why not just make a template (Template:subscribed perhaps) that someone wanting to indicate they are subscribed to (or are otherwise watching) a given discussion and do not wish to receive pings can transclude? Thryduulf (talk) 01:00, 22 December 2024 (UTC)[reply]
Sure, but that would be 17 characters (perhaps shorter with an intuitive shortcut), compared to 16 characters for 'I am subscribed.', and in a long discussion, you might have to use it repeatedly. I'm looking more for something you can do just once per conversation (just like subscribing is only done once), that would be visible in some way in a given discussion for other users to consult and then ping/not-ping as needed.
Currently, once you subscribe to a conversation, the Mediawiki software knows this, and is capable of "doing something" (i.e., notify you) every time anybody else posts a comment. This proposal requests that it "do something" when you, as a subscribed user, declare your status, which involves not notifications to bunches of users (rather complex), but adding something visible to the discussion (rather simple in comparison). Maybe it's a signature flag, maybe it's a hover tip, maybe it's a dropdown under the section title, or a collapsed floater that expands with a list of all the users who have declared their status (either way), maybe those using the [Reply] link will get a popup saying, User:Example1 is subscribed or maybe it's something else, but the point is, I'm looking for a set-once-and-forget solution for the user who wishes to declare their subscription status, so other users can respond accordingly. Mathglot (talk) 02:47, 22 December 2024 (UTC)[reply]
The prominence of parent categories on category pages
The format of category pages should be adjusted so it's easier to spot the parent categories.
I can see the Subcategories. Great. I can see the Pages in the category. Great. No parent categories. That's a shame --- discovering the parent categories can be as helpful as discovering the subcategories.
Actually, the parent categories are there (well, I think they are --- I'm not sure because they're not explicitly labelled as such). But I don't notice them because they're in a smaller font in the blue box near the bottom of the page:
Categories: Water | Chemical processes | Technology by type
I think the formatting (the typesetting) of the parent categories on category pages should be adjusted to give the parent categories the same prominence as the subcategories. This could be done by changing:
Categories: Water | Chemical processes | Technology by type
to:
Parent categories: Water | Chemical processes | Technology by type
and increasing the size of the font of `Parent categories', or, perhaps better, by having the parent categories typeset in exactly the same way as the subcategories. D.Wardle (talk) 22:21, 22 December 2024 (UTC)[reply]
Adding "template collapse" and "section collapse" capability in source editor of Wikipedia
Hi, I propose to add "Collapse and expand" capability for templates in source editor of Wikipedia. This way, readability in edition raises significantly. For example, by this capability, we can collapse the lines of Infobox of an article, and pay attention to the rest of the article very conveniently. This capability is very common Integrated development environments like Eclipse. The same idea can be implemented in the "source editor" of Wikipedia to enhance its readability. Additionally, by the same concept, we can collapse all other sections of an article, to pay attention to just one of them very conveniently. Hooman Mallahzadeh (talk) 07:50, 23 December 2024 (UTC)[reply]
Firstly, the idea lab is not for feature requests, which go on Phabricator.Code folding on Barack ObamaSecondly, template folding is already available as part of the "Improved Syntax Highlighting" beta feature, which can be enabled in your preferences. It does have some janky UX (pictured) though; work on adding conventional UX to the gutter is tracked in T367256Finally, section collapsing is available in the mobile view of all skins. Aaron Liu (talk) 16:16, 23 December 2024 (UTC)[reply]
WMF
Wikimedia Foundation Bulletin November Issue 2
Here is a quick overview of highlights from the Wikimedia Foundation from November 7 to November 21, 2024. Please help translate.
Upcoming and current events and conversations Talking: 2024 continues
Scholarships open for Wikimania 2025
Conversation with the trustees: Speak directly with the Wikimedia Foundation trustees about their work at the next Conversation with the Trustees on 27 November from 12:00 – 13:30 UTC.
Wikimedia Hackathon:Registration is now open for the 2025 Wikimedia Hackathon which will be held in Istanbul, Turkey, May 2–4, 2025.
Tech News: Admins and users of the Wikimedia projects where Automoderator is enabled can now monitor and evaluate important metrics related to Automoderator's actions; Stewards can now make global account blocks cause global autoblocks. Learn about the latest tech updates from tech news 45, 46, and 47.
Board Updates: The Board met in Katowice, Poland on August 5 and held its quarterly business meeting before Wikimania. Learn more about the outcomes of the meeting.
Wikimedia Foundation banner fundraising campaign in Australia, Canada, Ireland, New Zealand, the UK, and the US starts next week
Dear all,
As mentioned previously, the WMF is running its annual banner fundraising campaign for non logged in users in Australia, Canada, Ireland, New Zealand, the UK, and the US from the 2nd to the 31st of December 2024.
I am posting this here because it has very broad implications for the project and may require foundation help in the coming weeks. Wikipedia articles on energy and the environment and other many other subjects rely on data from US government web sites, which are generally regarded as authoritative. There is a significant likelihood that many or all of these sites will be taken offline after January 20, 2025 when the US administration changes over. Is the foundation participating in any organized effort to back this material up? Can we just rely on the Internet Archive? What happens if the new administration puts up conflicting data? Will editors be free to "correct" articles based on what newer Government websites say, regardless of scientific backing? We do not have a lot of time to think this through.--agr (talk) 19:02, 1 December 2024 (UTC)[reply]
I understand (and share) your concern, but deciding which sources are reliable is an editorial decision which the WMF does not get involved in. Sources that were once considered reliable can have their reputation reevaluated if conditions warrant, and even sources that are generally considered reliable should always be examined with a critical eye to ensure that any particular statement holds up to the general reputation.
As far as I know, whenever something is cited on Wikipedia, the Internet Archive automatically takes a snapshot of it. You can contact someone like GreenC to confirm this.
The rest of your post seems like it would be a good fit for WP:RSN. Reliable sources have become unreliable before, and RSN can handle reducing a source's ranking on the WP:RSPSOURCES list when that situation comes to pass. A note will even be added to the entry stating that it used to be reliable, and after what date it became unreliable. However, it might be jumping the gun to post about this before it actually happens. There's not really anything to do yet. –Novem Linguae (talk) 00:27, 2 December 2024 (UTC)[reply]
Do you have a specific source for the allegations that many or all of these sites will be taken offline after January 20, 2025? Yes, the Dept. of Ed website's not going to be up anymore if that agency is axed, but this isn't the first post that I've seen here predicting that the administration change will be the end of America as we know it. Yes, if the energy/climate/public health sites go downhill we can/will revisit how we handle those sources. But all of this doom and gloom is overwrought, like when people I knew thought Obama was the antichrist or that Hillary was going to put Christians into death camps. This is Wikipedia, not Reddit. I thought we were a little more level-headed here. Hog FarmTalk02:01, 3 December 2024 (UTC)[reply]
We had a nice four years where the main agitators in AMPOL were right-wing nuts. These are pretty easy to take care of, since they have virtually zero social capital on Wikipedia. They can be overruled and the community is ready to ban them at the drop of a hat if they get frustrated and lash out. Now we can look forward to four years where the main agitators will be left-wing nuts and #Resistance. This is harder to deal with because these people do have social capital on Wikipedia and have wikifriends (including several established editors and admins) to come back them up in disputes or tilt consensus. I suspect we can also look forward to more Anti-American bigotry toward subjects and editors as well. Thebiguglyalien (talk) 19:43, 3 December 2024 (UTC)[reply]
Just a note, since the new administration can make changes, this should have implications to the past of US government web sites as sources. Cinadon3608:05, 22 December 2024 (UTC)[reply]
You see, the East German anthem doesn’t have an audio file because when I tried to upload it, it doesn’t work. It keeps telling it is unconstructive, but there is no other file. Same thing for the Chechen anthem, even thought the file doesn’t work on mobile. 197.167.245.218 (talk) 11:27, 6 December 2024 (UTC)[reply]
Here is a quick overview of highlights from the Wikimedia Foundation since our second November issue. This will be the final bulletin for 2024 and we'll be back in late January 2025 with the next issue. Please help translate.
Upcoming and current events and conversations Talking: 2024 continues
Celebrating Chabota and his contributions to the movement.
Tech News: Chart extension is now available on Commons and Testwiki; a new version of the standard wikitext editor-mode syntax highlighter will be available as a beta feature; Edit Check will be relocated to a sidebar on desktop. More updates from tech news 50, 49, and 48.
Wikipedia 2024 Year in Review:Wikipedia 2024 Year in Review launched, showcasing the collective impact of Wikipedia and Wikipedia contributors in the last calendar year. The iOS App also released a personalized Year in Review to Italy and Mexico, with insights based on reading, editing, and donation history.
Wikipedia Android App: The Android team has launched the Rabbit Holes feature in the final release of the year as part of Wiki Experiences 3.1. Currently being tested in Sub-Saharan Africa and South Asia, this feature suggests a search term and a reading list based on the user's last two visited articles. For more details or to share feedback, visit the project page.
Annual Goals Progress on Equity See also a list of all movement events: on Meta-Wiki
WikiCelebrate: From Challenges to Change-Making: We Wikicelebrate Chabota Isaac Kanguya, a passionate contributor from Zambia, whose journey through the Wikimedia movement embodies resilience, collaboration, and a commitment to representing underrepresented voices.
Conference: Announcing Central Asian WikiCon 2025 which will be hosted at Diplomat International School on April 19–20, 2025, in Tashkent, Uzbekistan.
For information about the Bulletin and to read previous editions, see the project page on Meta-Wiki. Let askcacwikimedia.org know if you have any feedback or suggestions for improvement!
Everybody's different. Some people are on a mission to document every professional cricket player, every TV station, every species of reptile, every politician in their home country, etc, etc. I like to explore the history of where I live and as often as not, my interest in a topic is sparked by going past some building or park and wondering if there's more there than meets the eye. And, just like Anatole-berthe, my user space is littered with stubs of future articles that never went anywhere. RoySmith(talk)22:39, 5 December 2024 (UTC)[reply]
Yeah, "local consensus" was not the right choice of words, I meant a more specific guideline overruling the general one and not being in sync with most other ones. Fram (talk) 09:08, 12 December 2024 (UTC)[reply]
But anyway, the question is, is there a good reason why the band, movie, album, book, .... "Peeling Onions" would all be at the title "Peeling Onions", but for the painting we need to add the name of the artist? Fram (talk) 09:39, 13 December 2024 (UTC)[reply]
If there were two or more notable paintings called “Pealing Onions”, disambiguating by artist would be helpful.
Otherwise, we don’t need to be so specific. We can disambiguate as “Pealing Onions (painting)” to distinguish it from the book, album, etc of the same title. Blueboar (talk) 13:57, 13 December 2024 (UTC)[reply]
Suggestion to rename many criticism/controversies articles to include both concepts in name
Ok. First, I am posting this here, because I can't figure out a better forum (this is a cross-WikiProject issue). Second, sure, criticism and controversies are separate concepts. But consider for example Criticism of Facebook, CNN controversies/Controversies of Nestlé and existence of categories like Category:Facebook criticisms and controversies. Having looked at several of articles on criticism/controversies about companies/organizations, I am really hard pressed to find difference between them, and we already have several categories grouping those concepts together (like the mentioned Facebook one). (Rarely, we have two articles about this: consider Criticism of Wikipedia vs List of Wikipedia controversies - but this is pretty exceptionaland perhaps a case of navel gazines asking for a merge).
For those who care about category trees, few points:
according to our category structure, Category:Controversies is a subcategory of Category:Criticisms. Whether this is correct, I am not sure, trying to make a hierarchy for such content is challenging - here, I am just noting how they are related at present in our structure
And I am not feeling like tackling Category:Scandals by type into this (subcat to controversies by type).
But I'd like to suggest that we rename all articles and categories for criticism and controversies of organizations/companies to follow Category:Facebook criticisms and controversies and few others named in this fashion.
For people, I suggest "Criticism and controversies related to Person X" or just rename all controversies to criticisms (because Criticism and controversies related to Jesus, for example, sounds a bit weird). That said, again, conceptually, criticism of Jesus and Controversies surrounding Silvio Berlusconi are pretty much the same (Jesus is a controversial figure to some; Berlusconi has been criticized, and those pages cover all those aspects).
Really, almost all of those articles are pretty much conceptually identical, so even if you think you have a handle on how to draw the line between controversies of foo and criticism of foo, please note that enforcing this will be next to impossible. Rather than having multiple names and two category trees for conceptually identical articles, I think standardizing them to one is going to be best. Piotr Konieczny aka Prokonsul Piotrus| reply here09:34, 14 December 2024 (UTC)[reply]
I think a first step is to go through these controversy articles to make them more of a summary style rather than listing every single incident where the topic came under controversy. Criticism of Christianity is maybe halfway there but it still has too much dissecting to specific indicents.
A second step would be to strip legal aspects like lawsuits to separate articles, eg like Litigation involving Apple Inc. which generally stays more factual to actual things that happen in courts of law, rather than the commentary and criticism of from a range of sources. This might not be a possible step for several of these, but we should not try to mix criticism and ligitation. Masem (t) 03:59, 15 December 2024 (UTC)[reply]
Or how about we don't have either? I don't think that we should have stand alone criticism/controversies articles or sections (for aren't we advised to integrate such stand alone into the article? Aren't they simply relics of a less rigourous era doomed to be eventualy disassembled?) Horse Eye's Back (talk) 15:46, 14 December 2024 (UTC)[reply]
+1. By their nature, these articles are either POV forks or so close to it that the end result is the same. Controversies and criticisms shouldn't be made standalone solely for being controversies or criticisms, whether it be as a separate article or a section within an article. They should be incorporated into the article like any other facts, and if they don't fit, then they're probably not due. Thebiguglyalien (talk) 22:19, 14 December 2024 (UTC)[reply]
FWIW, Controversy does a good job at outlining its distinction as a state of prolonged public dispute—ergo, controversy is properly subcategorized under criticism, requiring additional narrative and intersocial characteristics. Remsense ‥ 论02:12, 15 December 2024 (UTC)[reply]
I agree; this likely should be done with many of these articles. I'm not sure that all of them should be liquidated, though I'm not immediately hitting upon a specific counterexample. Remsense ‥ 论02:45, 15 December 2024 (UTC)[reply]
Yes, I was talking in terms of individuals. My understanding is that criticism in the context of Criticism of capitalism or Criticism of Marxism is referring to scholarly criticism and not general negative feelings (we have separate pages after all for Anti-capitalism and Anti-communism). I would expect for example that an article "Criticism of Hegel" would note Critique of Hegel's Philosophy of Right but not that his mom thought he was a jerk. Horse Eye's Back (talk) 04:33, 15 December 2024 (UTC)[reply]
At a glance, I don't think that a one-size-fits-all renaming to "Criticism and controversies related to _____" would be appropriate for any of these. WhatamIdoing (talk) 06:28, 15 December 2024 (UTC)[reply]
I think that such an approach tailored to natural persons would be appropriate. I also see a major difference between an event which has controversy, criticism, or scandal in its proper name and the use as a descriptive title. Horse Eye's Back (talk) 00:49, 16 December 2024 (UTC)[reply]
Hey all, hope everyone here is doing well. Today I woke up to discover that a podcaster I follow had plagiarised part of an article I wrote, as well as parts of some other articles (some of which I had contributed to, others not). The podcaster did not cite their sources, nor did they make it clear that they were pulling whole paragraphs from Wikipedia, but they ran advertisements and plugged their patreon anyway. This is not the first time an article I wrote for Wikipedia has been plagiarised and profited off (earlier this year I noticed a youtuber had plagiarised an entire article I had written; I've also noticed journalists ripping off bits and pieces of other articles). Nor is this limited to articles, as I often see original maps people make for Wikimedia Commons reused without credit.
Obviously I'm not against people reusing and adapting the work we do here, as it's freely licensed under creative commons. But it bugs me that no attribution is provided, especially when it is required by the license; attribution is literally the least that is required. I would like attribution of Wikipedia to become more common and normalised, but I don't know how to push for people off-wiki to be more considerate of this. In my own case, the 'content creators' in question don't provide contact details, so I have no way of privately getting in touch with them. Cases in which I have been able to contact an organisation about their unattributed use of Wikipedia/Wikimedia content often get ignored, and the unattributed use continues. But I also have no interest in publicly naming and shaming these people, as I don't think it's constructive.
Does anyone here have advice for how to handle plagiarism from Wikipedia? Is there something we can do to push for more attribution? --Grnrchst (talk) 13:59, 16 December 2024 (UTC)[reply]
Sadly there are plenty of lazy sods who think that copying directly from Wikipedia is "research". This has happened with some of the articles that I have been involved with. It's rude, but hard to stop.--♦IanMacM♦(talk to me)14:13, 16 December 2024 (UTC)[reply]
I would start by writing to the podcaster and politely explaining to them that they are welcome to use the material but are required to provide attribution. They may simply be unaware of this and might be willing to comply if properly educated. Failing that, I assume the podcast was being streamed from some content delivery service like YouTube. You might have better luck writing to the service provider demanding that the offending material be taken down.
To support RoySmith's point, for those who may not have seen it, here is a very long youtube video about youtube and plagiarism [48]. (Works just having it on as background audio.) CMD (talk) 14:59, 16 December 2024 (UTC)[reply]
Aye, I figured it be an uphill battle trying to accomplish even minor changes on this front. As I can't find a way to contact the creator directly, sending an email to the hosting company may be the best I can do, but even then I doubt it'll lead to anything. Thanks for the advice, anyhow. --Grnrchst (talk) 15:12, 16 December 2024 (UTC)[reply]
@WhatamIdoing: It was more-or-less word for word, with a couple tweaks here and there. I don't want the episode pulled, I really just want Wikipedia cited, but I can't figure out any way to get in direct contact with any of the people involved. --Grnrchst (talk) 10:16, 17 December 2024 (UTC)[reply]
It's possible that the way to get in touch with them is a DMCA takedown notice. Having your platform take down the whole episode tends to attract attention. You could make it easy on them by suggesting a way to fix the problem (maybe they could add something like "This episode quotes Wikipedia in several places" to the end of the notes on the podcast?). WhatamIdoing (talk) 18:33, 17 December 2024 (UTC)[reply]
I'm curious as to what the plagiarized article in question is. Often there is no majority authorship of an article (in terms of bytes added), which might complicate DMCA claims. JayCubby18:35, 17 December 2024 (UTC)[reply]
Anyone who contributed enough content to be copyrighted can issue a DMCA notice. The glaring problem with this approach is that the DMCA only applies if the copy is published in the United States. Phil Bridger (talk) 18:51, 17 December 2024 (UTC)[reply]
@JayCubby: It's an article I wrote 99.9% of, minus minor copyedits by other users. I'm cautious about revealing which one as I think it would make it easy to figure out the podcast in question, and I'd still prefer to handle this privately rather than go full hbomberguy. Also, having now gone through more of the episode, it's not just that one article that got text lifted from it; text was also copied in whole or in part, without attribution, from other Wikipedia articles I have contributed to (but didn't author) and an article on another website that publishes under a CC BY-NC-ND license. I don't know how I would handle notifying the other parties that got plagiarised either. I haven't combed through the entire episode yet, but already a sizeable portion consists of unattributed text, either identical to the source or with minor alterations. --Grnrchst (talk) 19:29, 17 December 2024 (UTC)[reply]
Together , we could try to determinate if he does correspond to criterias about notability. I need answers to search data about him that can show if he's notable enough for Wikipedia.
1.This individual is deceased or alive ? Do you know an approximative year about his birth or / and death ?
Just a heads-up: for obvious reasons, the default Syrian flag is now the flag of the interim revolutionary government. If you want the Assad-era flag, you will want {{flag|Syria|1980}}, not just {{flag|Syria}}. You can explictly get the revolutionary flag (with precaution against it being changed if the national flag changes again) by using {{flag|Syria|revolution}}.
For the bulk of places where the Syrian flag is used, this is correct, and it spares us an insane number of edits. However, unfortunately, a lot of articles about the recent war used/use {{flag|Syria}} for the Assad side, and now show the wrong flag. These would probably be the highest priority to change.
Similar issues might arise with (for example) participation in international competitions and conferences, granting of awards, etc., but those seem to me to be much less potentially misleading than ones related to the revolution itself. I see things that long predate 1980 that were just using {{flag|Syria}}, so it is not as if there has been great discipline around this in the past.
@Jmabel I think you're right about this issue but I have few ideas for its resolution.
A possibility is to give an unique name to each flags.
For example we erase {{flag|Syria}} that gave the next result : Syria.
We keep {{flag|Syria|1980}} that gave the next result Syria
The same for {{flag|Syria|revolution}} that gave the next result Syria.
We can do the same for others flags. For example instead of {{flag|United States}} that gave the next result United States.
We keep {{flag|United States|1960}} United States that gave the flag of nowadays with 50 stars.
To get the previous flag {{flag|United States|1959}} = United States.
I discover a thing. If you write {{flag|Country of your choice|Year}} you get the flag of this country in force during the year selectionned for some countries.
I certainly don't oppose someone taking on a major, multi-person-month approach to the entire {{flags}} template, but I would not want to see us delay the solution to this immediate issue and have it wait for a massive, broad project. - Jmabel | Talk00:31, 23 December 2024 (UTC)[reply]
Comment: It would appear Jimbo responded indirectly in a interview: 
Just out of curiosity: If a certain case of IPs spamming at Help Desk is any indication, would a CU be able to stop that in its track? 2601AC47 (talk|contribs) Isn't a IP anon 14:29, 23 November 2024 (UTC)
Note: This section was split off from "CheckUser for all new users" (permalink) and the "parenthetical comment" referred to below is: 
.png)
.svg)
Change wallpaper Gnu779 (talk) 11:02, 21 December 2024 (UTC)
_-_La_Jeunesse_(1883)_(12387743075).png)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
wikimedia.org know if you have any feedback or suggestions for improvement!
.jpg)
Syria. 
Syria
United States. 
United States that gave the flag of nowadays with 50 stars.
United States.
![[6]](https://commons.wikimedia.org/wiki/Commons:Deletion_requests/File:Shibrul_Passport_Size_Photo.png){kind=link}
![[28]](https://commons.wikimedia.org/wiki/Commons:Deletion_requests/Image:Lick_it_3_(nude_photograph_by_artist_Peter_Klashorst).jpg){kind=link}
![[29]](https://commons.wikimedia.org/wiki/Commons:Deletion_requests/Image:Fuck_you!_(nude).jpg)){kind=link}
.jpg){kind=link}
