Jump to content

Wikipedia:Village pump (idea lab)

From Wikipedia, the free encyclopedia
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, note:

Before commenting, note:

  • This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
  • Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for 10 days.

« Archives, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69


Revisiting WP:INACTIVITY

[edit]

Of the 7 WP:RECALL petitions so far, at least three have some concerns at least adjacent to WP:INACTIVITY - Master Jay, Gimmetrow and Night Gyr (ongoing).

Currently admins are desysopped procedurally if they haven't made any edits/admin actions for 1 year OR have made less than 100 edits in 5 years. According to WP:RESTORATION, adminship is generally restored at WP:BN unless there were 2 years without edits OR 5 years since last tool usage.

Clearly, many editors believe we need to update WP:INACTIVITY but there has been no RFCs attempted on how.

This is a preliminary RFC to ask two main questions -

  • Q1: Do the thresholds for procedural desysoppings ( WP:INACTIVITY ) need changing? If yes, to what?
  • Q2: On return from inactivity, when do they generally get the tools back? ( WP:RESTORATION )

I'm hoping this narrows solutions down sufficiently that a future yes/no proposal can gauge consensus later.

Soni (talk) 16:53, 16 July 2025 (UTC)[reply]

Procedural comment. This is an RFCBEFORE but it has the {{rfc}} header template. Should it be removed? LightNightLights (talk • contribs) 17:02, 16 July 2025 (UTC)[reply]
Thank you for the correction. Somehow I had misparsed RFCBefore all these years. I think it's best described as a "preliminary RFC" than RFCBefore, and should retain the RFC tag. This discussion will likely involve wide community input, even if I'm not presenting multiple options for !voting. Soni (talk) 17:07, 16 July 2025 (UTC)[reply]
Then it's not an RfC. That's not how RfCs work. It's a terrible idea to do an RfC at this stage without work shopping anything. There's no rush and adding an RfC tag, which ultimately will lead to a demand for a closure, is more of a waste of time at this point. voorts (talk/contributions) 17:09, 16 July 2025 (UTC)[reply]
I am fairly confident I have seen multiple RFCs over the years that are effectively "Let's workshop here". Therefore I believe an RFC tag is appropriate, but I may be mistaken. I have no strong feelings on an RFC tag either way, the main intent is just to ask the "Do the thresholds need changing" question. Soni (talk) 17:14, 16 July 2025 (UTC)[reply]
Well if half of the editors say "yes increase" and the others say "yes decrease", all with equally valid arguments, twe'll have gotten precisely nowhere. It's alwaus better to have concrete proposals to !vote on IMO. voorts (talk/contributions) 17:18, 16 July 2025 (UTC)[reply]
I don't think so. I think that if we find the community evenly divided on increase vs decrease, that the reasonable conclusion is that we're doing things just about right.
The bigger risk is a multi-way split (e.g., change rules to X, change rules to not-X, change rules to X+Y, change rules to not-Y...). WhatamIdoing (talk) 19:13, 16 July 2025 (UTC)[reply]
I think there is a trend of being very bureaucratic about how a request for comments discussion should proceed. Yes, it's true: requests for comments are time-consuming. But so are discussions amongst a select group of people all in agreement about a certain direction, which fails to take into account broader concerns when a larger group of people are involved. We shouldn't force all discussions into one progression. Sometimes it's better to get broad input at a preliminary stage to stake out the scope of further discussion. isaacl (talk) 18:21, 16 July 2025 (UTC)[reply]
I agree. And FTR, at last check, we've been running only two new RFCs per day (it was usually three new RFCs each day ~pre-pandemic). So we probably have some capacity for the occasional "unnecessary" or "premature" RFC. WhatamIdoing (talk) 19:14, 16 July 2025 (UTC)[reply]
Soni, thank you for stepping up and starting a discussion on this (many people have lobbied for a discussion but nobody's actually carried it out). I don't have an answer to Q2 (I don't neccesarily think an RfA should be needed, though), but the minumum edit threshold for procedural desysopings definitely needs upped, although I need to see other's opinions before forming my own on what the exact number should be. — EF5 17:09, 16 July 2025 (UTC)[reply]
many people have lobbied for a discussion but nobody's actually carried it out See Wikipedia:Village pump (policy)/Archive 203#Admin inactivity rules workshopping from two months ago. Anomie⚔ 11:47, 17 July 2025 (UTC)[reply]
That proposal was mainly centred around WP:GAMING and WP:RECALL, neither of which are the emphasis of this discussion. I do not plan to use this discussion to inform what changes, if any, RECALL should take. I do want us to get a better idea on what we want our procedural policies on desysopping to look like.
So far we have a promising idea from User:Patar knight that can probably be workshopped further. Reduce the edit count criterion altogether, and focus on how to effectively use just admin tool usage. It probably needs proper wording from someone who understands this well. Soni (talk) 12:34, 17 July 2025 (UTC)[reply]
Yeah, that discussion was focused on GAMING. EF5 12:50, 17 July 2025 (UTC)[reply]
Seems to me that all three things were being discussed there. The second bullet in the initial post specifically targeted WP:INACTIVITY. You also brought in WP:RECALL from the start, and gaming has also been mentioned here (although without links to WP:GAMING yet). Anomie⚔ 13:00, 17 July 2025 (UTC)[reply]
Yeah that discussion led nowhere because it was not focused enough. Which is why this one mainly focuses on WP:INACTIVITY. RECALL was mentioned primarily to explain the initial context, but I very much plan for this workshopping to be centred, above all, around what our activity standards and expectations should be. Soni (talk) 13:17, 17 July 2025 (UTC)[reply]
Just to clarify, while we both support some kind of tool usage requirement, it was Levivich who suggested removing the edit count altogether while I merely suggested a possible system for doing so. Personally, I think requiring admins to have community involvement beyond just using the tools is a good thing and would keep the edit activity requirements, which had broad community support at WP:ADMINACTIVITY2022. For exact numbers, it would probably be useful to have stats similar to what Worm That Turned did for the 2022 RFC at User:Worm That Turned/Admin activity to see what has changed since 2022, with perhaps an additional query for how back 5/10 logged admin actions go back. -- Patar knight - chat/contributions 16:27, 17 July 2025 (UTC)[reply]
After going through the discussion I think 150 edits (#2) and fewer than five admin actions yearly (#1) would be a good compromise for Q1. ~150 yearly edits shouldn't be hard if they are active. 5 admin actions would show that admins still use, and have a need, for the toolset (although whether five admin actions is "having a need" is debatable). I also like Patar knight's idea below of using a sort of yearly "resume" of admin actions so admins can prove they are still active. — EF5 14:46, 18 July 2025 (UTC)[reply]
  • Other than some editors kvetching about the "unfairness" of desysops of some admins who haven't used their tools for several years, is anyone else calling for change? To those editors, I say: get over it. Being an admin is a privilege, not a right, and if you don't use it, you should lose it. voorts (talk/contributions) 17:10, 16 July 2025 (UTC)[reply]
    @Voorts, I think that what's missing – and what I think you might be able to supply – from these conversations is a description of the practical benefits to Wikipedia when we remove the tools from inactive admins.
    Imagine that an admin reliably makes one edit per month. In five years, that will be 60 edits, and they'll fail the five-year rule. This is the rule we've set, and I'm okay with it, but how does Wikipedia benefit from having one fewer person who could take an admin action?
    I think an agreed-upon idea about the benefits would help us match our rules to our goals. If we say, "Look, the principle is that completely abandoned accounts are at risk for getting hacked, and low-activity accounts are corrosive to community spirit because they make some non-admins jealous (even though very few of them would admit to that very human emotion)", then we should be able to get this settled a little more firmly. But if we don't identify (or can't agree upon) a purpose for the WP:INACTIVITY rules, then I don't think these conversations will ever stop. WhatamIdoing (talk) 19:34, 16 July 2025 (UTC)[reply]
    Many many many editors have already supplied rationales for inactivity rules, including the security one you cited and that those admins quickly become out of touch with community norms. The burden of persuasion here is on editors who want to change policy, not those who are fine with the status quo. voorts (talk/contributions) 20:32, 16 July 2025 (UTC)[reply]
    I've seen the security one, and it makes sense to me. I've seen the "out of touch" one (e.g., in this discussion).
    But – are those the real reasons? Because humans often begin with "Ugh, no!" or "Obviously yes", and then later seek out rational-sounding reasons to make them look smart when they're really just dressing up their intuitive or irrational response.
    I'm not trying to persuade anyone that the policy needs to be changed (or kept the same). I'm trying to figure out whether the policy achieves our goals.
    Consider the idea of "admins aren't out of touch with community norms". Is that best measured as "doesn't surprise people by taking admin actions that don't match the formal, written rules"? If so, then inactive admins are fine, because they're taking no actions, and therefore no actions that disagree with the written rules. Maybe it means "if taking an action, makes the same decision as 90% of other admins would". If so, we need to get rid of some active – and IMO some of our best – admins, but most inactive admins are fine. Maybe it means "Is a person who is familiar and active, because emotionally if I have to be rejected by my community, it needs to be done by someone whom I can respect and who feels like they're really part of the community, instead of someone who feels like an outsider or an unknown person". In that case, we might want higher activity levels, or at least to tell admins to avoid emotionally laden or socially fraught admin actions (e.g., blocking "the regulars") until they've been highly active again for months.
    But without an idea of what that phrase means to people, and whether that's their genuine reason or just the one that's socially acceptable for public consumption, it's impossible to know whether what we have works. WhatamIdoing (talk) 21:22, 16 July 2025 (UTC)[reply]
  • The recalls listed above as relating to inactivity were all closely tied to accountability (or lack of) in different ways. Procedural inactivity desysoppings are set at a very low bar deliberately, being technical and explicit, and adjusting the bar (even if it is merited for other reasons) would for the purposes of the diffuse concept of community discussion likely shift the grey area to whatever the new technical bar is. A change in requirements would further catch lower-activity admins who are engaged with the community, which is not something that I've seen expressed as desirable by any editor in discussions surrounding these Recalls. The recalls are not the best place to base a new discussion on inactivity from, as many of the suggestions that WP:INACTIVITY be updated were coming from those in opposition to these Recalls as something others may want to do, and so themselves don't represent belief that INACTIVITY needs changing/updating. CMD (talk) 17:16, 16 July 2025 (UTC)[reply]
    Well put. Considering our years-long collective dragging of feet in authorizing the community recall process (something which I always found mystifying at the time), a propensity for over-leveraging the process hasn't taken long to establish itself. I always assumed (perhaps a bit naively, in retrospect) that the process would (bar the occasional abusive filing) be applied mostly for the most blatant and severe cases of violations of community trust. While I don't consider the policy rationales that underpin the activity requirements to be completely without merit, I do worry about moving the needle very much in terms of shortening the timeline for de-sysopping. We are already in a state of slow-rolling crisis when it come to administrative manpower.
    I certainly don't think it's helpful for recall petition's to be based upon such factors, even indirectly. I haven't looked at the discussions in question, but to the extent some of these are apparently based upon gaming the system to stay above thresholds of activity, I have to say this is one area where at least my initial impression is "game away": any editor that invested in keeping the tools that they are pushing out a few extra actions to comport with the stats as a technical matter is showing enough interest to justify their continued possession of the tools, barring a showing of other factors suggesting unfitness. Of course, the devil is in the details, so perhaps I'm missing important context. But again: at first blush, I am fully in support of an express rule that recall petitions should not be based on inactivity. Equally, as you say, discussion of a change in the activity threshold should be divorced, to the maximum degree achieveable, from the context of the recall petitions, which I think colour the percpetions of participants with more impressionistic and anecdotal influences by way of the availability heuristic, whereas this is one area where we particularly want to predicating our approach in broader and empirically robust analysis. SnowRise let's rap 04:46, 18 August 2025 (UTC)[reply]
  • All I know for sure is that this gives weight to the idea that ADMINRECALL may need to eventually raise the signature threshold if it's going to be used as a place to get around community created activity guidelines, that's simply not what that venue was created for. I'm not advocating for any of those who lost the tools to keep them, but it leaves a bad taste in my mouth when we're using recall for a purpose I'd argue it wasn't intended for. Also noting that the Master Jay case was about more than their activity. Hey man im josh (talk) 17:35, 16 July 2025 (UTC)[reply]
    I do not necessarily disagree with any of those points, just that this discussion is specifically to judge whether the activity thresholds currently are sufficient or not. What precisely should RECALL change, is a separate question. Either we believe the current procedural thresholds are strong enough, or we'll raise/lower it accordingly. Soni (talk) 17:47, 16 July 2025 (UTC)[reply]
    used as a place to get around community created activity guidelines I think that's an unfair assessment of what's occurred in these cases. The inactivity policy is one thing. Making a token edit once in a while to keep the user right and then going back into dormancy is another. You could increase the length of time or change the requirements, but they'll always be game-able. Also, all of those petitions were swiftly completed. Increasing the signature requirement would have a negligible effect IMO. voorts (talk/contributions) 19:01, 16 July 2025 (UTC)[reply]
    the Master Jay case was about more than their activity As was Gimmetrow, whose single (and last ever) admin action to avoid being ineligible to automatically get the bit back after their incoming 100/5 inactivity desysop was to block a vandalism only account that used an anti-LGBTQ slur for 3 hours, which is far outside community norms. They later failed to response to a query that mentioned that block and their inactivity on their talk page, which led to the recall. -- Patar knight - chat/contributions 19:57, 16 July 2025 (UTC)[reply]
    (To clarify: The part about "far outside community norms" is that the block was only for three hours; it was later extended to an indef by someone familiar with the particular WP:LTA.) WhatamIdoing (talk) 21:28, 16 July 2025 (UTC)[reply]
    If we are re-litigating this: The edit in question (admin-only) added the text Fucķing [r slur] to a mainspace article, and told an LGBTQ editor to fuck off [anti-LGBTQ slur] in the edit summary. I don't blame anyone for not knowing it was an LTA. But ignoring everything else, that one edit is indef-able many times over. They intentionally placed the three hour block to allow time to look at other edits, as if you need more evidence to indefinitely block an account. (I very much hope the search was not for mitigating evidence; what would possibly make that acceptable?) All in all, I'd call that "far outside community norms". HouseBlaster (talk • he/they) 00:12, 18 July 2025 (UTC)[reply]
    Yes, that's what I said. The problem wasn't blocking the account; the problem was only briefly blocking the account instead of an indef or at least a very long block. WhatamIdoing (talk) 17:35, 29 July 2025 (UTC)[reply]
  • In response to Q1, I'd propose a revision to Criterion 1 of Inactivity and change Has made neither edits nor administrative actions for at least a 12-month period to Has made no administrative actions for at least a 24-month period. Thoughts? Iggy pop goes the weasel (talk) 17:53, 16 July 2025 (UTC)[reply]

When you edit this page, the edit notice says:

This Village Pump is for developing ideas, not for consensus polling. Rather than merely stating support or opposition to an idea, try to be creative and positive. If possible, suggest a better variation of the idea, or a better solution to the problem identified.

That has not been done here. In addition to this, not enough background has been provided via links to previous discussions (where some of the changes being proposed above were rejected and arguments provided for why it was a bad idea). When was the most recent RfC on this issue? 1 year ago? 5 years ago? Having said that, I agree with CMD who said:

Procedural inactivity desysoppings are set at a very low bar deliberately, being technical and explicit, and adjusting the bar (even if it is merited for other reasons) would for the purposes of the diffuse concept of community discussion likely shift the grey area to whatever the new technical bar is.

I disagree with CMD in the last part of what he says here:

A change in requirements would further catch lower-activity admins who are engaged with the community, which is not something that I've seen expressed as desirable by any editor in discussions surrounding these Recalls.

In my view, some editors really do want to cut a big swathe through admins and get rid of the inactive ones. There is demonstrable opposition to that, but recall (unfortunately) allows for persistent drip-drip actions against individual admins. Over and above that, in my view, what needs changing is the dynamic between WP:INACTIVITY and WP:ADMINACCT (admin accountability). Simply remove the ability of people to demand that admins respond to people who come to their talk page to complain about their activity levels. Let INACTIVITY deal with activity levels, and let ADMINACCT deal with responses to actual admin actions. I am sure that a properly phrased wording could separate these two concepts so that they don't conflict any more (arguably, they don't conflict at the moment, but clearly some people need it spelling out). On a personal level, as someone who has been more active and engaged with the community than I have been in years (though that activity will likely tail off, as I will (need to!) be very busy with other matters again soon), I would like to see INACTIVITY remain stable. I will also repeat what I have said elsewhere. Try and make this a positive thing about retaining inactive admins rather than fiddling with the paperwork.

That said: Q1: No change (current thresholds are fine). Q2: No need to change the current provisions of WP:RESTORATION. Carcharoth (talk) 18:03, 16 July 2025 (UTC)[reply]

  • If you believe there is a faction of editors that want to cut a big swathe through admins, please provide evidence. Recall has generated a lot of hypothetical concerns, but as for the "persistent drip-drip actions", the supposed persistency has resulted in just 3 (and it is likely one third of those won't even be certified). CMD (talk) 02:27, 17 July 2025 (UTC)[reply]

As I stated in a previous discussion, I feel the community wants its admins to have some ongoing connection with the community, and uses recent edits as a metric to determine this. However, I also previously stated that the community has desired to balance the volunteer nature of the role against this, and to allow for healthy breaks in activity. Thus if there is a consensus to change the activity thresholds, I think the best way to avoid increasingly fractal discussion on how much activity is enough is to shift the emphasis to one of security: remove administrative privileges with a much smaller inactivity threshold (such as on the order of a few months) to limit security concerns, but make it very easy to restore on request (as it is now, but perhaps with tweaks to make it even simpler, particularly for those who have recently been active). If someone has concerns about admin accountability, or with ongoing familiarity of community norms, they should make a case based on specific evidence, not just levels of activity.

Regarding accountability during hiatuses: I don't think the admin role should be one that locks editors into perpetually being active on Wikipedia. I think it's reasonable for questions to be answered upon a return to activity. If administrative privileges are removed based on a short period of inactivity due to security concerns, then there is only a limited time when issues of misuse of privileges may occur. isaacl (talk) 18:15, 16 July 2025 (UTC)[reply]

  • As I see it, the primary reason to (at least temporarily) de-sys-op admins who have been inactive is that the policies, guidelines and procedures they are supposed to be familiar with may have been amended while they were away. Thus they will be prone to making mistakes. They will need time to get up to speed on these changes. That said… once they are “up to speed”, there should be a quick and easy way to re-sys-op them. Blueboar (talk) 18:37, 16 July 2025 (UTC)[reply]
    Though I understand this point of view, I do think that part of trusting an editor sufficiently to grant them administrative privileges is to trust them to reacquaint themselves with community norms as needed. Some admins with lengthy absences have commented in these recent discussions about their returns. Perhaps we need to do more to impress this upon all administrators. isaacl (talk) 19:07, 16 July 2025 (UTC)[reply]
    I am doubtful of this "policies might have changed" rationale. After all, we see highly active admins (and non-admins) who are apparently unfamiliar with the rules they're enforcing. Admins, being more experienced editors, tend to have a good grasp of the long-term community POV on something (e.g., science is good and altmed is bad), but they don't actually track the drip-drip-drip of changes to policies and procedures with any more assiduity that anyone else. WhatamIdoing (talk) 19:41, 16 July 2025 (UTC)[reply]
  • Since the format is a bit unclear, it is best to workshop what we really want to ask here before moving on to a full RfC at WP:VPP. One aspect I've seen brought up during recall petitions is the question of how WP:ADMINACCT applies to low activity admins, and that is something that should be discussed in an RfC on activity thresholds. Chaotic Enby (talk · contribs) 19:24, 16 July 2025 (UTC)[reply]
    Why wouldn't it still apply? If you are an admin and you do something using your tools, you need to answer for it. If you use your tools once every few years as a token edit, then go dormant again, and someone questions you on it and you aren't either watching your watch page or decide not to answer, those are both conscious choices. Why is giving a break to people who haven't been a part of our community in any meaningful ways for years so pressing? voorts (talk/contributions) 19:34, 16 July 2025 (UTC)[reply]
    I'm not saying it shouldn't apply, and, to the contrary, I do think that it should apply in full to any admin actions. However, I've often seen it brought up (and criticized) as an argument in recall petitions, and I was surprised it wasn't discussed here. Since we're still in the workshopping phase, I figured it would warrant a mention. Chaotic Enby (talk · contribs) 19:38, 16 July 2025 (UTC)[reply]
    The key question to me is should administrators be able to take a complete break from Wikipedia? If the community consensus is yes, then it's reasonable for them not to respond to questions during their break. If no, then I think that administrative privileges should be removed based on a relatively short threshold of inactivity, since that matches community expectations (no administrative privileges for someone taking a break), with an easy restoration of privileges upon request. isaacl (talk) 21:45, 16 July 2025 (UTC)[reply]
    Is the story here something like "If Alice Admin usually only makes one edit a month, and she deletes an article today, then she might not check her User_talk: page for another month, which would violate the ADMINACCT requirement to respond promptly and civilly to queries about their Wikipedia-related conduct and administrative actions"? WhatamIdoing (talk) 19:44, 16 July 2025 (UTC)[reply]
    Roughly, although the cases brought up in recall petitions usually focused on specific issues about which admins didn't respond, rather than the possibility that they might not due to their activity level. Chaotic Enby (talk · contribs) 19:46, 16 July 2025 (UTC)[reply]
    In the past, I'm pretty sure that we had a rule saying that if an admin knew that they weren't going to be available for a few days (e.g., the day before leaving on a trip), they shouldn't take any admin actions, or if they did, they should try to leave a note to help other admins with appeals ("Any admin: It's okay to overturn this without talking to me first"). I wonder if that rule still exists. WhatamIdoing (talk) 21:33, 16 July 2025 (UTC)[reply]
    At the risk of sounding like Captain Barbossa, I don't recall it being a "rule." I think it was more of a guideline or suggestion. Joyous! Noise! 23:22, 16 July 2025 (UTC)[reply]

Thanks for starting this discussion, Soni. I'd support just dropping the edits part of the inactivity requirement (100 edits in 5 years) altogether, and instead just require the admin actions part (1 in a year... but not necessarily just logged actions). I think that change, alone (dropping the edits requirement, but not changing the admin action requirement, at least at this time), ought to be put to an RFC. If that's approved by the community, we can skip a long discussion about how many edits are enough edits. If it's approved, the community can later decide to increase the admin actions requirement if 1/year turns out not to be enough for whatever reason. Levivich (talk) 20:10, 16 July 2025 (UTC)[reply]

The issue is that non-logged actions can be very difficult to measure. Closing a TBAN proposal at ANI is pretty clearly a non-logged action that we can check for, but what about, say, looking at deleted edits to identify patterns of abuse? Chaotic Enby (talk · contribs) 20:36, 16 July 2025 (UTC)[reply]
If there's no logged action in a year, the admin could be prompted to edit some new subpage of Wikipedia:Inactive administrators to provide an example of edits that show use of the tools, perhaps with a short explanation if necessary, for bureaucrats to assess. If say an admin says they looked at deleted edits in the context of abuse, it's not unreasonable to require them to point to an edit in which they comment on the user being investigated/discussed or a revert of that user. -- Patar knight - chat/contributions 21:05, 16 July 2025 (UTC)[reply]
Actually a great idea, and it would also help with WP:ADMINACCT! Chaotic Enby (talk · contribs) 21:13, 16 July 2025 (UTC)[reply]
Agree, great idea. The automatic inactivity notice that's already posted on admins' talk pages could be modified to say something like "if this notice is in error and you have made an admin action within the past year, please post at [link]". Crats can review that page before the switch is thrown. I bet this would be a very, very rare occurrence and result in very little additional work. Levivich (talk) 21:21, 16 July 2025 (UTC)[reply]
Frankly, we could do with having some additional work. Useight (talk) 17:00, 17 July 2025 (UTC)[reply]
I'd be fine with just a "1 logged admin action per year" requirement. Keep it simple. Levivich (talk) 19:13, 17 July 2025 (UTC)[reply]
That's a pretty good idea Iggy pop goes the weasel (talk) 21:29, 16 July 2025 (UTC)[reply]
I'd sign up for that idea. Buffs (talk) 23:16, 16 July 2025 (UTC)[reply]
This feels much more in spirit of admin accountability without too much emphasis on arbitrary thresholds. I definitely prefer this as a lighter weight "Adminship is easy to remove and restore" than any alternatives. Soni (talk) 04:18, 17 July 2025 (UTC)[reply]
I have never found non-logged actions can be very difficult to measure to be a strong argument. If we have a user making so few administrative actions that they can only point to edits exercising administrative authority requiring the use of non-edit user rights to retain their tools (our current inactivity rules not being particularly onerous), it remains pretty questionable to me that they should need the full kit. Izno (talk) 22:35, 16 July 2025 (UTC)[reply]
I agree that if we ask for admin actions, we should ask for logged ones (perhaps including editing protected pages). Admins using the tools in a hidden but beneficial way without ever doing anything logged are probably a myth and not worth making the process more complicated, even by a tiny bit. —Kusma (talk) 07:12, 17 July 2025 (UTC)[reply]

I appreciate the initiative. However, I think it's not a well-formed question for Q1. Q2 is fine as it's a yes/no question. I would recommend an RfC along those lines, but give some new thresholds like:

  1. Change the thresholds
    1. Desysop at 1 year with no edits/admin actions or 100 edits in 5 years (0/1, 100/5)
    2. Desysop at 0/1, 50/2
    3. Current thresholds or 0 admin actions in 2 years or 10 in 5 years
  2. No change
  • etc

Set up some sort of threshold to assess from. Admins can make the assessment regarding whether people want a change and roughly where that consensus lies. 90% of the people could choose something in 1. showing there is significant desire for a change or conversely 60% of the people could choose option 2 and, regardless of the debate within the options under 1, no change should occur. Buffs (talk) 20:47, 16 July 2025 (UTC)[reply]

Before we can have a reasonable discussion about whether we should increase the activity requirements, we need to have some clear comments/proposals, etc detailing why they should be changed that clearly set out what the problem that changing the requirements is intended to solve, what is the evidence that this is actually a problem, and how changing the activity requirements will solve that problem. I don't recall seeing any of that in the recent discussions. Thryduulf (talk) 21:01, 16 July 2025 (UTC)[reply]

I agree. For example, @Levivich has an interesting idea. It makes intuitive sense to me (if you're not using the tools, you don't need the tools). But what problem does this solve? Is the problem it solves the same as the (social/emotional) problem that the community has with inactive admins? WhatamIdoing (talk) 21:36, 16 July 2025 (UTC)[reply]
WP:INACTIVITY should be amended to make it clear that the spirit of the law is more important than the letter of the law (just like with all other Wikipedia procedures), and that rights gaming is applicable to retaining admin rights. Admins should have the tools if the community supports them having the tools and they should not have the tools if the community does not support them having the tools. Right now, the barometer for whether the community supports tool-possession is RfA or AELECT. If someone can pass those, there is consensus for them to have the tools. If they cannot pass those, there is not consensus for them to have the tools. The problem here is that the tools are seen as a permanent entitlement of status rather than a tool for service, and that not being an admin is some kind of downgrade or lower class. Thebiguglyalien (talk) 🛸 21:41, 16 July 2025 (UTC)[reply]
rights gaming is applicable to retaining admin rights is something I do not think has consensus, but if we want to make that part of some question it seems reasonable.
We set a number deliberately. If we want to change that number to some number that we actually believe indicates real activity, we should (and I would personally welcome an adjustment to the numbers, but ~consensus gathering activity~). Taking potshots at admins who aren't here all the time isn't the way to do that. NB that I don't think all three of the admins above even fall into the category of "sent to admin recall solely because of inactivity", and I think we see the results of that with how quickly (or slowly) the admins have reached 25 signatures at recall.
Another approach to stopping what is perceived as gaming is to remove the "next month you're being desysoped" messages. Those are likely to be the primary cause of the once-a-year / couple-a-month edits. If people really want to keep their tools, they can do their own homework.
An appropriate change the opposite direction might be to forbid admin recall solely on the basis of inactivity directly in WP:RECALL. There's got to be something more than "the hard rule you've been provided for keeping your hat is the hard rule you're meeting". Our default position should be to trust administrators, because they earned that trust via RFA.
But I'm sure all of this was all argued in the last RFA review mess that has now spawned this growing pain. Izno (talk) 22:58, 16 July 2025 (UTC)[reply]
  • Soni, I think it would be useful at the top of this discussion to have links to previous RFCs and discussions we have had on this subject. We don't need to reinvent the wheel and I think this discussion would benefit from seeing ideas that have already been proposed in the past that didn't pass a vote. We are not starting from scratch here, we've gone through other RFCs on this matter. Thank you. Liz Read! Talk! 22:10, 16 July 2025 (UTC)[reply]
    @Liz Do you have a list of such RFCs and discussions you think should be listed? Soni (talk) 04:02, 17 July 2025 (UTC)[reply]
    There's the two RFCs in the footnotes from WP:INACTIVITY. There's some failed RFCs here in 2019 [1] and 2015 [2] from what I recall. Not sure if there were other RFCs here in the archives, elsewhere, or other discussions. -- Patar knight - chat/contributions 05:18, 17 July 2025 (UTC)[reply]
    There was another attempt at "workshopping" just two months ago at Wikipedia:Village pump (policy)/Archive 203#Admin inactivity rules workshopping. Anomie⚔ 12:02, 17 July 2025 (UTC)[reply]
  • For Q1: In my opinion, yes. Change criterion #1 from: Has made neither edits nor administrative actions for at least a 12-month period to Has not made any logged administrative actions for at least a 12-month period. Change criterion #2 from: Has made fewer than 100 edits over a 60-month period to Has made fewer than 100 edits over a 30-month period. Some1 (talk) 22:56, 16 July 2025 (UTC)[reply]
    Scratch that. I would support having only one requirement for INACTIVITY, and that would be for admins to make at least 25 logged admin actions within the past 12 months. If an admin completes those 25 actions in one day and does not edit for the rest of the year, I think that would be fine (though if they know they will be inactive for an extended period of time, they should voluntarily relinquish their tools for security reasons, etc.). If the admin appears every January, for example, to make 25 logged admin actions then goes inactive for the rest of the year, repeating this editing pattern for several years, I believe that would fall under GAMING. Some1 (talk) 13:42, 3 August 2025 (UTC)[reply]
    For the record, only 364 admins made 25 logged actions in the year from August 1, 2024 to July 31, 2025. Donald Albury 15:48, 3 August 2025 (UTC)[reply]
  • Q1: no. Q2: whenever. Think of this, instead, as being in a volunteer organization in a leadership role. If you've put in the time to be trusted as a "lead" in something, typically speaking, you've been filtered for sanity and dedication to doing the right thing. There are obviously exceptions (and sociopaths exist in any org). But you're not going to make someone re-prove themselves from the ground up if they step away for a year or two. Life freaking happens.
    Sure, you'll expect that they get back up to speed with current procedures, but that's something that "leads" are already used to doing, and know if they make a mistake, they apologize and fix it. That said, you probably should be cautious when someone comes back from absence; "trust but verify," because egos are a thing. And that could (and should) factor in. But the amount of assuming-bad-faith from some of the commenters here is incredible. When someone steps away from the project, it's not someone "cheating" on the project. It's someone doing something else to help the world. Or perhaps getting their crap together in real life. Or perhaps landing a new job. Or having a baby. Or just a really long bout of depression. Anything other than, "Well, they forgot everything about how to Wikipedia. Now we have to assume they're an idiot that can't be trusted." That's just not generally how people work. That's not how volunteer-driven orgs work. In fact the ones I work with now specifically carve out at least a year of inactivity before you're truly considered inactive.
    And just like in volunteer organizations, if someone's inactive, the assumption is that anyone can undo their actions. And I get where people are coming from: the faceless immediatism of the internet creates a bias toward seeing other editors as faceless while expecting of them the same immediatism. Giving into that fosters a situation where, eventually, only those truly dedicated to being an admin will be admins, and that should scare the living daylights out of anyone who pays attention to business or politics in the real world.
    --slakr\ talk / 06:51, 17 July 2025 (UTC)[reply]
    @Slakr, I hadn't thought of comparing it to real-world/face-to-face volunteer work before, but I think you're entirely right. Orgs that depend on volunteers don't treat those who come back after a break like they are ignorant, untrustworthy or like they have been unfaithful to the group. A return to activity is really treated as a situation that should be celebrated. You make sure their old friends know. You introduce them to the new folks. You brief them on any important changes and if there's something that might sound like any sort of reflection on them, you explain ("Oh, we got a new accounting firm, and they insist that two people always be present when the mail is opened. It's a bit of a pain, but they said that they always recommend it after discovering a thief stealing checks from one of their other clients..."). You don't treat them like they need to prove themselves again, unless you actually want them to quit. WhatamIdoing (talk) 07:30, 17 July 2025 (UTC)[reply]
    • As someone who has both volunteered and managed volunteers, I cannot think of many meatspace volunteering positions where you have the power to kick out other volunteers and tear up their work, and where those exist they generally don't get handed to people who have just returned to the organisation after a long absence. In my experience working with volunteers, that would be an absolutely terrible idea. Caeciliusinhorto (talk) 20:01, 17 July 2025 (UTC)[reply]
      Any organization that is entirely volunteer-run will have other volunteers who can "kick out other volunteers and tear up their work". This can be done explicitly (volunteers can get "fired") or implicitly ("Oh, we've already got the schedule set for next month, thanks").
      Very few of them will think that taking just 12 months off is "a long absence". You're hardly going to tell a trusted volunteer "Thanks for 20 years of service. We really missed you, and I'm so glad your cancer is is remission now. Oh, by the way, you can't be in charge of the volunteer schedule/re-join the Board/on the fundraising committee again, because of your 'long absence'." WhatamIdoing (talk) 17:47, 29 July 2025 (UTC)[reply]
@Slakr: Thank you, this is a good way to think about returning admins. But we do see a huge amount of bad faith displayed towards admins returning from inactivity and asking for the bit back. There is strong feeling in parts of the community that they should prove themselves first. I think those parts of the community have got it wrong and that their attitude is making it harder for people to volunteer to do admin work again, but I don't think we can just ignore them. See the NaomiAmethyst resysop discussion we had a few months ago. Perhaps it would be easier to have formal criteria for resysopping (but we'd still need a way to deal with the people who consider meeting the formal criteria to be WP:GAMING). —Kusma (talk) 13:42, 18 July 2025 (UTC)[reply]
  • Q1, maybe?, Q2, no, outside of a clause for recall for WP:GAMING As a person who has spent a fair bit of time working in security (simply out of the principle of least privilege), I'm always for make the desysop window tighter but allow for restoration with some activity. That being said, I'm not going to strongly advocate for desysopping faster since I do recognize that folks do take extended vacay, and often drop away from time to time. I think our priority there should be to build robust pathways for folks to reintegrate back into the admin corp, something that we severely lack at the moment. I don't necessarily think our WP:RESTORATION policy is bad, but I would advocate for enshrining recalling for WP:GAMING into the admin activity metrics, purely since I see it as a "I will follow the letter of the law, not the spirit" activity that Wikipedians just should not engage in. Sohom (talk) 18:14, 17 July 2025 (UTC)[reply]
  • I'm strongly against any addition of admin actions to the activity requirements. There was a conflict admittedly quite some years ago now where people tried to line up content creators and admins as separate groups. Part of the counter to this is content focused editors who just happen to have admin bits.©Geni (talk) 04:44, 21 July 2025 (UTC)[reply]
    I also don't see the benefit of requiring more admin actions. An editor who is almost completely focussed on other things and only uses the tools when they stumble across something -- and is up-to-speed enough to recognize that and know how to appropriately deal with it -- is useful. I think every active, experienced, well-intentioned, temperamentally-fit editor should be an admin. And probably would be if RfA wasn't seen as such an obstacle. Valereee (talk) 11:51, 21 July 2025 (UTC)[reply]
    Using the tools when I stumble across something is how I function as an admin. If many more editors could become editors admins of that type, it would spread the work around a little more, and hopefully reduce the "them vs. us" attitude that has crept into so much of the community dynamics. I think we have seen, though, how hard it would be to get back to that old idea that adminship is "no big thing". Donald Albury 13:18, 21 July 2025 (UTC)[reply]
    I always planned to be that type of admin. I said as much in my RfA. Very rarely do I go out of my way to focus on admin work specifically. That said, I do think that even with that style of adminship, one can easily make 25 admin actions over the course of 5 years. I can understand why people would want some sort of basic minimum for a toolset that can be quite powerful if misused (even if it's not out of malice). Clovermoss🍀 (talk) 13:50, 21 July 2025 (UTC)[reply]
    I am not worried for now about the inactivity rules. However, I have taken long breaks in the past, including a 5 year period with a little under 850 edits and just 6 logged admin actions, and if I had had the admin bit taken away during that break, I wouldn't have bothered trying to get it back if I had had to go through an RfA. I'll leave it to others to decide how much of a loss that would have been for the project. Donald Albury 14:44, 21 July 2025 (UTC)[reply]
  • The recall petitions in question don't just focus on inactivity, they focus on WP:GAMING. No matter what the criteria are, they'll be gameable (unless we set them to truly punishing levels solely to make them ungameable, which seems undesireable.) Any system can be gamed and, thanks to the existence of WP:RECALL, the community is now capable of stepping in in situations where gaming seems obvious; another advantage of relying on recalls is that it allows the community to consider other factors (both the successful recalls had other concerns come up during the discussion; and, conversely, if someone had few edits but they were high-impact ones that clearly showed they were keeping up with changes to policy and the community, a recall presumably wouldn't be attempted and would fail if it was.) In short, it seems like the community is handling this fine and that we don't need to change anything. If there was a massive flood of such recalls it might indicate that we should adjust the criteria to avoid wasting everyone's time with obvious cases, but that doesn't seem to be the case - three recalls isn't that many. Plus, RECALL is pretty new and most of the gaming involved happened before it existed; it's reasonable to assume that administrators will be less likely to blatantly game the activity requirements now that the community can do something about it. I would expect a small flood of such petitions focused on an accumulated backlog of admins who were gaming the requirements but who there was previously no easy way to do anything about get recalled, after which they'd rapidly dry up. That doesn't really require any changes. --Aquillion (talk) 13:51, 21 July 2025 (UTC)[reply]
    I don't think it's punishment to set activity thresholds at a much higher level when there is an easy path to have administrative privileges restored. It does mean that there is a delay between wanting to perform admin tasks and being able to do so. I appreciate this can discourage spontaneous activity, but I think most editors can find another similar opportunity soon afterwards, upon re-obtaining admin privileges. isaacl (talk) 16:35, 21 July 2025 (UTC)[reply]
  • Q1 yes, and I'd support any range of increased edit requirements starting at the status quo and ending at something like 200 edits per year average. I do think we should add an admin action minimum to both the 1-year requirement and the rolling average, and I'd support most reasonable numbers there as well. Q2 status quo is fine with me. I don't support the proposal to remove edit count fromt the 1-year criteria. In general, I think we're looking for admins to be active members of the community. Even with increased minimums, it would be possible for an admin to check out for 18 months or so and get the bit back. I'm strongly in favor of the "fix problems as I come across them" style of adminship, but I think those admins should have their "admin brain" turned on enough to hit the minimums easily (see clovermoss). My concerns with inactive admins are the same as those who initially set up the activity requirements and later increased them: compromised accounts and bad admin actions due to a lost sense of community norms. Firefangledfeathers (talk / contribs) 12:16, 28 July 2025 (UTC)[reply]
  • Q1 yes. I believe that the criteria should be changed to Has not made any logged administrative actions for at least a 24 month period. Let's face it: what sets administrators apart from non-admins are the fact that they have special tools. If they're not using those special tools... well, what's the point? IMO an edit threshold doesn't make a whole lot of sense, since 1) it opens up to a whole lot of WP:GAMING (which has happened, more times than appreciated) and 2) as previously mentioned, admins are admins since they're supposed to use the tools they have. At least people attempting to game this new criteria would be bringing in some benefit to the place. Not being an admin anymore isn't the end of the world, and I think it's fairer to the community to let old ones go. You can still edit if you're not an admin. I made the limit higher, 2 years. Q2 yes, since again, I don't think the edit threshold is all that useful for determining whether an admin gets to stay. I'd just swap out edits for administrative actions: Has made fewer than 100 administrative actions in the last 5 years. Imo these requirements should be changed as admin is a really important role, and it's definitely a risk for users who have not contributed meaningfully in years to have it. Yes, sad to see established users go, but everyone's gotta leave at some point, and delaying it through simple gaming and standing on the edge of the boundary really isn't constructive. I completely get that some people need a break and step away for periods of time, but years without administrative action should warrant some action being taken. It's not a kind of punishment to have adminship being taken away, it's just for the safety of the community. People who really want it back can apply for admin again, and if they still meet the criteria, they can receive it. I think my time period is fair enough to account for this. My 2 cents. jolielover♥talk 12:23, 29 July 2025 (UTC)[reply]
    100 admin actions is way too high. It's very easy to meet for admin who primarily works anti-vandalism tasks but tricky for one who focuses on bigger, slower, more considered tasks (e.g. controversial discussion closures). Thryduulf (talk) 12:31, 29 July 2025 (UTC)[reply]
    True... maybe like, 50? 25? Not sure. jolielover♥talk 12:42, 29 July 2025 (UTC)[reply]
    What is the point of removing adminship for inactivity?
    • There's a security question for compromised credentials, although this materializes very rarely, especially now 2FA is well-used
    • Inactive admins may return and make bad decisions based on out of date policy knowledge
    Are there any others? Because neither of these two issues (a) arise frequently enough to make a difference, or (b) would be fixed by changing the requirements. Stifle (talk) 09:32, 6 August 2025 (UTC)[reply]


Updated Admin Activity Stats

[edit]

Someone suggested that we should have an updated version of User:Worm That Turned/Admin activity for 2025, to get an idea of how many admins would currently be hit by "Last admin action" rule, among other things. Is there someone who can generate such a table relatively easily? I don't know what kind of querying will allow that. Soni (talk) 23:48, 17 July 2025 (UTC)[reply]

I believe it was @Patar knight who suggested it. I re-ran my old scripts and added a bit. User:Worm That Turned/Adminship term length/new for anyone who wants the data. WormTT(talk) 10:41, 18 July 2025 (UTC)[reply]
Oh and just noting - ~100 of our admins haven't made 50 edits in the past 2 years, ~200 haven't made 50 edits in the past year, and ~250 admins haven't taken any admin action (defined as appearing in delete / protect / block) in the past year... we have about 850 admins. WormTT(talk) 11:11, 18 July 2025 (UTC)[reply]
Thanks for these stats, but I think there is an error. Looking at my entry, it states my most recent admin action was 2025-06-25, 5 actions go back to 2025-06-25 but 10 actions go back to 2025-07-15. The relevant dates should be 2025-07-16, 2025-06-25 and 2025-06-17 respectively. Thryduulf (talk) 12:26, 18 July 2025 (UTC)[reply]
Putting the data in a spreadsheet, there doesn't appear to be a problem with the edits but there are 548 entries where the most recent action is older than the 5th and/or 10th most recent and/or the 5th most recent action is older than the 10th most recent. Thryduulf (talk) 12:53, 18 July 2025 (UTC)[reply]
Thanks @Thryduulf I'll have a look WormTT(talk) 12:57, 18 July 2025 (UTC)[reply]
@Thryduulf, I see the bug, will regenerate. Though I will say I get slightly different dates for you, as 5 events in this log go back to 2025-07-04, and ten between the three logs go back to 2025-06-25... so those will be the numbers that should come out the other end. Give me a few mins. WormTT(talk) 13:16, 18 July 2025 (UTC)[reply]
Hopefully all correct now :) WormTT(talk) 13:59, 18 July 2025 (UTC)[reply]
Thanks, this is great. Would it be possible to add other logged admin actions such as User rights/Edit Filter Modification which are already options at Special:Logs? -- Patar knight - chat/contributions 08:53, 19 July 2025 (UTC)[reply]
Wow, that's way less activity than I imagined. I'm now thinking like 100 edits and 10 admin actions per year. The people who have the power to sanction me need to be at least as active as I am. The idea that I'm at constant risk of being sanctioned by people who make less than 50 edits a year is upsetting. Levivich (talk) 14:33, 18 July 2025 (UTC)[reply]
But you aren't at constant risk of being sanctioned by people who make less than 50 edits a year. Sure, there are lots of people who have the technical ability to sanction you, but if they have less than 50 edits a year, they do not have the social standing to block you and make it stick; if they wrongly block you they are probably going to be desysopped. Your claim The people who have the power to sanction me need to be at least as active as I am is also obviously nonsensical. In practice, you are far more likely to be blocked by an active power user than by a near-inactive one. —Kusma (talk) 14:56, 18 July 2025 (UTC)[reply]
Somehow "don't worry, it won't stick" doesn't make me feel better :-) As for being desysopped for bad blocks? Think about admins who have been desysopped for bad blocks (anyone), and then ask yourself: how many bad blocks of how many editors over how many years did it take before they were finally desysopped? It was never "1", was it? Yeah, no, people who make like 50 or 100 edits a year shouldn't have access to these tools. They should be pulled for inactivity and they can get them back when they regain activity levels. I am now also thinking that WP:RESTORATION should require compliance with activity requirements before restoration (rather than just the expression of an intent to comply). Levivich (talk) 17:13, 18 July 2025 (UTC)[reply]
People have been desysopped after a single bad undelete that showed they were out of touch. The people who aren't desysopped for bad blocks are usually highly active and their blocks are against newbies, not against noticeboard regulars. Desysopping people who never use the block button has no effect on the number of bad blocks at all. But forcing people to make admin actions will mean more bad admin actions. Not really seeing the benefit there.
We need less suspicion towards returning admins, not more. If asking for activity before resysop helps to make it a more friendly process, we can try it. —Kusma (talk) 17:57, 18 July 2025 (UTC)[reply]
I can think of one admin who was desysopped (by arbcom) over one undeletion and that's the only example, I think, in at least 5 years? Is it more common than that? But I don't want to get sidetracked by that; I think we'd both agree that it should take more than one bad undeletion or one bad block to be desysopped--everyone makes mistakes.
I do share your concern that upping the minimum tool use will cause bad tool use. Part of me thinks "yeah, let it happen so we can desysop those people." As a side note, I'm shocked to see there are admins who apparently have used the tools less than 5 or 10 times ever, and I think that's concerning. I do strongly believe admin tools should be "use it or lose it." I'd support a two-prong requirements: minimum edits and minimum logged actions, rather than one or the other.
These lines in the sand (20 edits/yr or 50 or 100) seem very arbitrary. It's not like if you make 100 edits in a year you'll be great but if you make 50 you'll be totally out of your depth. It's hard to find a logical place to draw a line, although it has to be drawn somewhere. One logical place to draw the line is at the same place as some other suffrage or similar requirements. WP:TWL requires 10/month, which is 120/year. Maybe it'd be good to have one site-wide line for "active" that applies everywhere: RFA/AELECT, ACE, TWL, and admin inactivity. 120 edits/year or 10/month seems reasonable to me. Maybe admin req's should be 2x that, the logic being that an admin should be more active than a regular editor?
And then having return-to-activity-first-then-restoration I think would help eliminate some of the drama we've seen surrounding return to activity predictions. Levivich (talk) 18:23, 18 July 2025 (UTC)[reply]
Admins are trusted with the tools so they can carry out admin actions. How is it that there can be any admins that have not carried out a single admin actions in the last 5 years? -- LCU ActivelyDisinterested «@» °∆t° 10:18, 19 July 2025 (UTC)[reply]
@ActivelyDisinterested: Because our current admin inactivity requirements are mostly about edits and not admin actions. From what I remember reading discussions about this in the past, people opposing admin action requirements will mention there's uses for the tools that aren't logged (like viewing deleted edits). I do think that the hypothetical situation where someone is only using the tools for that for multiple years to be a fairly extreme edge case, though. Obviously we don't want to discourage people going through normal ebbs and flows in their lives (parenting, seasonal workers, grieving, health issues, etc) from contributing when they feel ready to get back in the swing of things but there has to be a way to be considerate of those needs while also increasing the pre-existing requirements. Clovermoss🍀 (talk) 03:10, 20 July 2025 (UTC)[reply]
An admin whose only use of the tools in the last five years is to check deleted edits isn't using the tools to be an admin. The tools aren't there to allow editors greater access than they would usually have, they are given so admins can carry out admin tasks. There are limitations to the data presented by WTT, but having admins who have not carried out a logged admin task in a half a decade is somewhat absurd. -- LCU ActivelyDisinterested «@» °∆t° 09:28, 20 July 2025 (UTC)[reply]
@ActivelyDisinterested: I wasn't disagreeing, simply explaining what I understand to be the reason for why things are the way they currently are. Something like 100 admin actions over 10 years would be better than nothing and be considerate of people's varying real life commitments. Clovermoss🍀 (talk) 14:54, 20 July 2025 (UTC)[reply]
Vary life commitments are one thing, but every admin on that list has made at least one edit in the last 15 months. If they are not carrying out admin tasks they have no need for the admin tools. When regaining the bit only requires making a request, admins who are not using the tools have no need to retain them. As well as 1000 in the last decade there needs to be a 10 in the last year minimum. -- LCU ActivelyDisinterested «@» °∆t° 15:16, 20 July 2025 (UTC)[reply]
@ActivelyDisinterested: My suggestion would work out to 10 actions a year (100/10=10) but I do think an annual cut off like that might be too stringent to pass an RfC (life can easily get in the way and people too tend to be concerned that raising the requirements at all will cause harm). I think there's a difference between someone being less active for a year vs it being an ongoing phenomenon. I think that's why the recent 100 edits over 5 years criteria passed. 50 actions over 5 years would still be ten a year and is more likely to get enough support from the community. Clovermoss🍀 (talk) 17:02, 20 July 2025 (UTC)[reply]
How about 20 admin actions over 2 years? The problem I have with 5 years is that if someone makes 50 admin actions this year, they can keep the admin bit while inactive for four more years before it's pulled, and I think that's too long. A 2-year window would allow people to take breaks of over one year but not over two years, which seems reasonable to me. Levivich (talk) 17:16, 20 July 2025 (UTC)[reply]
I think a 2 year window would probably be best. Long enough that people can take breaks as necessary but not long enough that consistency can become an issue. Also, having a lower threshold over a shorter period means that if there are edge cases where submitting diffs to show non-logged actions, it would be easier for both the submitter and a reviewing bureaucrat. -- Patar knight - chat/contributions 17:20, 20 July 2025 (UTC)[reply]
Though I appreciate the desire of a short period, I actually prefer the current longer period. Life changes like (particularly) children are a sizeable bump on time expenditure on non-wiki things.
I would also prefer to avoid adding to 1-year related inactivity as a result. Some count ~= 1 of admin actions seems fair in that time frame like currently. Izno (talk) 18:14, 20 July 2025 (UTC)[reply]
The main reason I suggested the five years was for simplicity's sake. The more time based activity requirements we have, the harder it will be for any one person to remember (I have to do x per year, y per 2 years and z every 5 years gets a bit messy). A 2:1 ratio for edits vs admin actions seems a bit high, so something like 25 admin actions every 5 years might be more comparable. Alternatively, one could raise the current 100 edits over 5 years requirement to something higher. Clovermoss🍀 (talk) 19:18, 20 July 2025 (UTC)[reply]
The stats are interesting. Thanks, WTT. I was having a quick look over them, though do not have time to comment in any detail. I did want to pick up on Levivich's comment about wanting admins to be as active as they are. Forgive me for asking, but do any of these feelings come from the quote on your user page (which I looked at today)? And as another comment, the activity numbers you are coming up with for other areas are interesting. I wonder why, historically, they are so different? Is it possible to see how many admins would fail to meet your increased requirements (e.g. the Twinkle ones)? Carcharoth (talk) 19:31, 18 July 2025 (UTC)[reply]
No, the quote on my userpage has nothing to do with inactive admins. Levivich (talk) 17:38, 19 July 2025 (UTC)[reply]
Thank you for clarifying. I am trying to tie up a few loose ends where I asked questions and did not want to miss this one. Carcharoth (talk) 21:01, 19 July 2025 (UTC)[reply]
@Worm That Turned Is the script you are using something that can be widely shared? I don't know if there's any info in there that shouldn't be leaked, but otherwise having the script be open source/editable by others seems like a positive. Soni (talk) 07:50, 19 July 2025 (UTC)[reply]
I'd need to spend a bit of time converting it into a form that doesn't just run on my computer. It's based on an old java wikibot and just scrapes the logs. Nothing clever, I'm sure anyone techy could do it, and probably much more efficiently that I did. WormTT(talk) 08:02, 21 July 2025 (UTC)[reply]
Very interesting, thanks WTT. How many edits that can only be made by an admin don't make the logs, I wonder? Valereee (talk) 14:15, 19 July 2025 (UTC)[reply]
Lots. In the past 30 days there have been 211 edits to pages in the MediaWiki namespace for example. Thryduulf (talk) 18:30, 19 July 2025 (UTC)[reply]
As someone who in the past moved a lot of preps to queue in DYK, I feel that. I'd certainly hate to see an admin desysopped for admin inactivity who was actually making such edits. But maybe that's not really an issue? Valereee (talk) 18:52, 19 July 2025 (UTC)[reply]
I imagine it would be possible to include the edit histories of certain designated pages like DYK queues, the major mainspace templates, and the main page itself in whatever automated check there is. Also to cover what can't be easily automated, I think my suggestion of a subpage at Wikipedia:Inactive administrators where admins could post diffs showing their non-logged activities would probably be fine for all parties as long as the threshold of actions/year isn't too high. -- Patar knight - chat/contributions 19:31, 19 July 2025 (UTC)[reply]
re your last sentence, if we go that route it needs to be very clear to everybody, including not-very-active admins and especially those who are care about inactive admins, that that page exists and must be consulted before determining whether an admin is or is not inactive. Thryduulf (talk) 19:57, 19 July 2025 (UTC)[reply]
Yeah, I imagine it would be integrated into the existing notification system for inactivity and the relevant bureaucrat/process pages updated. -- Patar knight - chat/contributions 20:24, 19 July 2025 (UTC)[reply]
There is already an edit filter that tracks edits to protected pages, but I forgot where it is. The only non-logged action I am aware of is viewing deleted edits. I don't really see the point of an extra page where inactive admins claim to have looked at deleted pages. —Kusma (talk) 20:07, 19 July 2025 (UTC)[reply]
Under my proposal, it would have to be tied to an edit that could be directly linked to view delete (e.g. “I looked at the revdeled contributions by X and think they should remain banned” at a notice board, “Looking at the previous version, I don’t think the G4 was appropriate at DRV before a restoration is requested). I wouldn’t expect this to be the bulk of non-tracked actions though. -- Patar knight - chat/contributions 20:39, 19 July 2025 (UTC)[reply]
Kusma, so moving prep>queue is tracked there? The reason I ask is that at one point there was an admin whose only admin actions were that, but they did it regularly. Valereee (talk) 21:53, 19 July 2025 (UTC)[reply]
@Valereee, back when the queues were fully protected, this was tracked. See your log of editing fully protected pages. —Kusma (talk) 06:07, 20 July 2025 (UTC)[reply]
Always something new. Or something I once knew but forgot. :) Valereee (talk) 12:54, 20 July 2025 (UTC)[reply]
The filter does not seem to track all edits to protected pages though: pages protected via cascading like the TFA blurbs are excluded. —Kusma (talk) 15:58, 20 July 2025 (UTC)[reply]
It may have got lost above, but is it non-trivial to find out how many current admins would fail to meet the proposal by Levivich to raise the activity levels to the Twinkle-permissions one? 120 edits/year or 10/month? And for those who have trouble counting... How many admins fall into each of the columns in WTT's table? Carcharoth (talk) 08:45, 20 July 2025 (UTC)[reply]
And maybe the Legend from User:Worm That Turned/Admin activity? And by numbers, I mean the numbers of yellow and red instances. And how much has this changed since the previous snapshot? Carcharoth (talk) 08:49, 20 July 2025 (UTC)[reply]
I've added some stats to User:Worm That Turned/Adminship term length/new#Stats based on the latest figures, I have not attempted to capture change. Thryduulf (talk) 09:37, 20 July 2025 (UTC)[reply]
Um. My eyes glazed over when trying to interpret those stats. Any chance of an example in words? E.g. XYX admins have made less than N logged actions in ABC years? An example would be 18 admins have made 5 logged actions in the past five years. And am still trying to work out what the last five rows mean... Carcharoth (talk) 10:03, 20 July 2025 (UTC)[reply]
The last five rows are there to help answer that sort of question, e.g. sum >1 means that it's the total number of admins whose last e.g. logged action was greater than 1 year ago. To use some words though, 107 admins made their last logged admin action more than 1 year ago, 89 more than 2 years ago, 74 3 or more years age and 58 5 or more years ago.
507 of the 835 (61%) of admins made 10 or more logged actions between 18 July 2024 and 18 July 2025. 94 admins made fewer than 10 logged actions in the 10 years to 18 July 2025.
Nine accounts have made fewer than 10 logged actions total:
Using this list as the basis for recall discussions would be highly inappropriate as it is devoid of any context. Thryduulf (talk) 11:10, 20 July 2025 (UTC)[reply]
Hi!
Just as an additional note: I also use the edit filter to combat spam, e.g. month. i guess, this does not show up in the logs either.
Nevertheless, I am indeed very rarely active here in the enwiki.
If my case complicates things, then it might be better to revoke my admin rights. I don't think the enwiki community would notice the change given my low participation.
However, I would be happy to keep my admin rights. It's nice that I'm allowed to help - even if only rarely - with the maintenance of the SBL or similar.
-- seth (talk) 16:09, 20 July 2025 (UTC)[reply]
It's often more efficient for one person do deal with cross-wiki spam. @Lustiger seth, you might consider becoming a m:Global sysop, if you haven't looked into that already. WhatamIdoing (talk) 16:33, 20 July 2025 (UTC)[reply]
From what I understand, you've consistently done good work here since your RfA without issue, so if there is no way to automatically track the work you do, you would be the prime example of why a manual review component like I suggested should exist in the event of an admin action requirement being implemented. -- Patar knight - chat/contributions 16:43, 20 July 2025 (UTC)[reply]
Nixdorf will be desysopped in a few days and seems ok with it according to his talk page. —Kusma (talk) 17:08, 20 July 2025 (UTC)[reply]
The abuse filter role account (User:Edit filter) is a system account. It is used by the extension if blocking abuse filters are enabled. (It currently does have 1 log entry). — xaosflux Talk 20:51, 27 July 2025 (UTC)[reply]
Holy cow. I am shocked that we have over a dozen admins whose last logged action was over 10 years ago. Toadspike [Talk] 13:30, 29 July 2025 (UTC)[reply]
That people have not noticed earlier probably means they have not actually caused any problems. —Kusma (talk) 14:01, 29 July 2025 (UTC)[reply]
Just noting here that the stats on this page are inaccurate. It does not include all logged admin tasks. It was flagged to me because someone thought my own stats looked wrong - and they are. Most of my admin actions are permission changes - an admin-only logged task - and it makes me wonder how many other admin tasks aren't included. I think this could easily be fixed by having this page managed by an automated process that includes all admin-only logged actions, and I have no doubt that someone reading this section is perfectly capable of doing this. Risker (talk) 06:15, 21 July 2025 (UTC)[reply]
I believe I mentioned above, and will make clearer on that page - that it's simply based on "block / delete / protect" admin actions. There are significantly more areas that admins work. I can (and when I get a chance will) extend, but these numbers are meant to give a rough idea of how busy our admins are. WormTT(talk) 08:25, 21 July 2025 (UTC)[reply]
I think it'll be helpful to see this full list generated before afull RFC on this. Mainly because it'll give people a good idea of exactly how many admins meet the proposed activity requirements. What's the usual place for such requests? Wikipedia:Bot requests doesn't feel right for a one time job Soni (talk) 19:16, 27 July 2025 (UTC)[reply]
It's pretty common for WP editors to display their edit count. For editors who don't display their edit count, it's not uncommon for other editors to check out what it is, if they are working on an article (or wrangling about an article). Reading the above, I'm not sure if this kind of scorekeeping -- whether it is healthy or not -- goes on with admins. Do admins display their "admit action count"? Do other admins or editors poke around and look to see what the "admin action count" an admin they have encountered has to their credit? I've never seen anything like this and the fact that folks above have had to do some work to pull up lists of admins who haven't done many admin actions recently suggest that this kind of scorekeeping and these kinds of counts are not routinely done. I'm asking myself if the world at Wikipedia would be a better place if this were a routine part of life at WP and my intuition is "no". Novellasyes (talk) 19:49, 27 July 2025 (UTC)[reply]
I do display my personal admin stats on a sub-page User:Donald Albury/Useful links, which is rarely, if ever, viewed by other editors. I also look at the Admin stats every once in a while to see where I stand compared to the admin corps as a whole, but, no, I do not look up the stats of other admins. Why should I? Donald Albury 20:20, 27 July 2025 (UTC)[reply]
An example of a vital admin action that isn't logged is participation at AE. I would also consider an admin who spends a lot of time on administrative tasks like closing AfDs to be performing admin actions even though such things can also be done by a non-admin. Zerotalk 03:05, 29 July 2025 (UTC)[reply]

Admin ease of return

[edit]

Some editors have expressed some sentiment of "We should also make it easy for admins to return". From the discussion above, I saw @WhatamIdoing, Carcharoth, Isaacl, Slakr, Kusma, and Sohom Datta:

If we make changes to alter inactivity criterion, it seems prudent to also do this. How can we make things for returning admins easier?

Soni (talk) 15:42, 20 July 2025 (UTC)[reply]

All they have to do is make a request at WP:BN (unless the have been inactive for more than five years), or did I miss something? -- LCU ActivelyDisinterested «@» °∆t° 16:25, 20 July 2025 (UTC)[reply]
I occasionally drop a note to a friend to say that it'd been a few months, and they might want to make an edit. (Even correcting a minor typo reassures me that you're alive and probably well.) A couple of the admins have made and edit and written back that life's incredibly busy (babies, two jobs, serious illness, that kind of thing) and thanks for the note, because if they lose their admin bits, they will never reapply. I think that they weren't thinking that a simple request at BN is all it takes.
However, even a simple request at BN requires a willingness to take a social/emotional risk. Some admins have dedicated enemies; what if you ask to be re-sysopped, and someone shows up to try to re-re-re-litigate a decision you made "against" them five years ago? Mud sticks, even if it's unfairly thrown. WhatamIdoing (talk) 16:44, 20 July 2025 (UTC)[reply]
Just in terms of editor motivation/dynamics and even sociology if you stretch the definition, this is incredibly interesting that people actually say this to you (I assume these are real examples): "thanks for the note, because if they lose their admin bits, they will never reapply". As is the fact that you email Wikipedia friends to check in on them. I think I have only ever done that once. Well, maybe twice. Carcharoth (talk) 17:47, 20 July 2025 (UTC)[reply]
Yes, they're real examples. Sometimes people reach out to me; somewhat more often, I contact them, or I hear from a third friend about them. Since I'm not on any anti-social media platforms, I don't have the "check their Facebook account" option. I wouldn't be surprised if that approach were more typical for editors. I don't carefully track editors' activity levels. Usually, what happens is I see a name in a page history or old discussion and realize I haven't seen them around for a while, so I drop them a note.
(In case you were curious, I avoid mentioning anything about RFA, because I don't want to influence people's thinking. I've had a two or three admins volunteer this, unprompted. RFA's reputation is really that bad.) WhatamIdoing (talk) 18:10, 29 July 2025 (UTC)[reply]
Some people have said that their participation on English Wikipedia gets triggered by seeing something they want to fix. The smoother the path to put this desire into effect, the more likely it will happen. Personally, I agree with the idea that administrators ideally would be willing to delay their participation and follow the current process. But I appreciate that in practice, people are motivated in different ways, and it may be helpful to accommodate a variety of considerations. isaacl (talk) 16:47, 20 July 2025 (UTC)[reply]
A few ideas off the top of my head:
  • If an admin voluntarily relinquishes administrative privileges and states an intention to return to editing within N months (the maximum sabbatical duration; for purposes of having an initial number to discuss, say 6), at the time of relinquishment, have bureaucrats determine whether or not they can have privileges restored without an open viewpoint request for adminship or election. If they make a request to have privileges restored within the maximum sabbatical duration and are eligible for restoration upon request, they are exempt from the 24-hour waiting period.
  • If the inactivity threshold is changed to something shorter than the maximum sabbatical duration, then exempt any admins whose inactivity duration lies between the inactivity threshold and the maximum sabbatical duration from the 24-hour waiting period. However if the bureaucrats have not already determined that privileges can be restored by simple request, they retain the ability to remove privileges after they complete their determination. Alternatively, make this the standard rule for all admins whose privileges were removed due to inactivity.
isaacl (talk) 16:36, 20 July 2025 (UTC)[reply]
We kind of need that 24-hour waiting period to make sure the request isn't the first step in a wave of account compromises. WhatamIdoing (talk) 16:45, 20 July 2025 (UTC)[reply]
I hadn't considered compromised accounts (I think concern about one is enough, even without a wave). Unfortunately, I can't think of any good ways to quickly confirm that an account remains under control of the original user. (Two-factor authentication is one possible mitigating approach, but it's still vulnerable to the scratch codes being stolen, and the current implementation on Wikipedia doesn't scale up well.) That being said, that's still true with a 24-hour waiting period if the returning account hasn't yet made a significant amount of edits. To really improve the probabilities, the account would have to resume activity for a sufficient enough time to see if their communication style was consistent. Perhaps the risk is acceptable in cases where the admin has voluntarily declared a sabbatical period (below the maximum sabbatical duration), and acknowledged they are following appropriate security practices. isaacl (talk) 17:02, 20 July 2025 (UTC)[reply]
Thus making accounts with declared sabbaticals the hackers' next target.
The point about multiple account compromises is that if you get a request for re-sysopping, followed by other, seemingly unrelated reports of hacked accounts, the crats might want to be slow to react to the request for re-sysopping. The story we want in that unusual situation sounds like this:
  • Admin: "Hi, Wikipedia:Bureaucrats' noticeboard, I'm back! Please re-sysop me after the 24-hour delay per standard procedure."
  • WP:VPT: "We're getting reports about a possibly compromised account...there's another... Okay, guys, it's red alert time!"
  • Crats: "Yeah, um, nothing personal, Admin, but this is going to take a bit longer than usual. Also, any editor who knows this admin in real life or can reach them through other channels, please get in touch privately."
The story we don't want sounds like:
  • Admin: "Hi, Wikipedia:Bureaucrats' noticeboard, I'm back! Please immediately re-sysop me, because of course I'm me and of course I follow good security procedures."
  • Crats: Here you go.
  • Admin "Mwah ha ha, I'm going to replace the Main Page with spam!"
WhatamIdoing (talk) 18:22, 29 July 2025 (UTC)[reply]
As I said, it's about tradeoffs. Sure, there may be occasions when Wikipedia admins and bureaucrats might need to be extra-vigilant about potential compromised accounts, but in general, I feel high vigilance is always needed, as I think there are always ongoing attempts to steal accounts online. So I don't think the 24-hour delay offers much additional security in practice. That being said, I acknowledge so far there hasn't been any other interest expressed in paring down the delay period.
Regarding the risk of inactive admins being targeted, I don't see a 24-hour delay significantly changing the risk. In the end the problem is authenticating the user, and waiting time doesn't change the problem. Requiring significant participation in tens of discussions might help, to provide enough writing samples for comparison. isaacl (talk) 20:44, 29 July 2025 (UTC)[reply]
If you target a benefit (e.g., low scrutiny re-sysopping) to a certain set (e.g., "in cases where the admin has voluntarily declared a sabbatical period"), then you can expect the accounts with the desirable benefit to become more interesting to hackers. WhatamIdoing (talk) 22:29, 29 July 2025 (UTC)[reply]
I think the benefit of attacking an unattended account is sufficiently attractive on its own that a 24-hour delay is just noise. For better or worse, be design, wikis are designed to make all activity easily traceable, so I can't think of a good way to try to hide when an account for an admin (whether or not they are currently have administrative privileges assigned to them) hasn't been active for some time. isaacl (talk) 02:30, 30 July 2025 (UTC)[reply]
Note I am not proposing an exemption for bureaucrats to evaluate whether or not the requesting account has been compromised. (As I recall, the 24-hour period was introduced to allow time for anyone to raise concerns about eligibility for restoration on request, but I appreciate that it also allows non-bureaucrats to examine patterns of behaviour, if there's enough to evaluate.) isaacl (talk) 17:15, 20 July 2025 (UTC)[reply]
Right now WP:RESTORATION's assessment of a return to activity is subjective: A bureaucrat is not reasonably convinced that the user has returned to activity or intends to return to activity as an editor. As Levivich mentioned upthread, we have multiple definitions of inactivity, some of which are more stringent than others (e.g. Wikipedia:List of administrators/Active defines "Active" as 30 edits in the last two months). We could do explicitly noting that if the WP:INACTIVITY thresholds are met at the time of the request than they are automatically considered to meet this criterion, though failing to do so is not an automatic fail. Otherwise people who might be able to return and help out a bit but not to the extent of the 180 edits/year required at Wikipedia:List of administrators/Active might be put off if they think the have to maintain that instead of something closer to the actual inactivity level which is 1/9 that. -- Patar knight - chat/contributions 16:55, 20 July 2025 (UTC)[reply]
I like the idea that if an admin already meets the thresholds, that's an automatic "yes" for WP:RESTORATION, and if they don't, it's not an automatic no but it's left to the crats to determine (as per current policy). Levivich (talk) 17:19, 20 July 2025 (UTC)[reply]
It also presents a very easy checklist to meet as opposed to thinking that they need to go review past BN discussions to see what precedents there are around activity. -- Patar knight - chat/contributions 17:22, 20 July 2025 (UTC)[reply]
...of course that won't work if the activity requirements are changed to require admin actions only and not just edits. Levivich (talk) 17:20, 20 July 2025 (UTC)[reply]
@Patar knight, this particular line is just documenting reality. Wikipedia:Wikipedia is a volunteer service. Even the crats are volunteers. There are only about 16 crats. Nobody can get (re)sysopped unless one of those 16 people agrees to push the necessary buttons. If all 16 of them refuse to do so – even if you think their reasons are wrong, and even if you think they are 😱Violating Consensus!!!!11!! – then the fact is that the account isn't going to have the sysop bit. WhatamIdoing (talk) 18:33, 29 July 2025 (UTC)[reply]
I get that. I'm just saying that for someone who is already somewhat not engaging with the community, having an explicit "do X and you don't have to worry about the return to activity requirement" is a lot easier to understand and start them on their return journey if they want to pursue it. There's considerable friction in de facto forcing someone to search BN archives to find what the precedent is and many people might walk away thinking the activity requirements for returning are significantly higher than they already are. -- Patar knight - chat/contributions 19:16, 1 August 2025 (UTC)[reply]
  • I'd like to see admins be able to return easily, but with a period of activity. Maybe 1 month of active editing (whatever that is) for each year inactive (whatever that is), to encourage getting up to speed. So someone desysops for five years becuz: toddlers. Toddlers go off to school, former admin starts editing again, and five months later the crats flip the switch. Valereee (talk) 18:04, 20 July 2025 (UTC)[reply]
    Sounds good. You do realise you are making all the active admins with toddlers feel guilty? :-) Carcharoth (talk) 19:50, 20 July 2025 (UTC)[reply]
    lol...I can remember not having time for a shower before it was time for bed. Valereee (talk) 20:00, 20 July 2025 (UTC)[reply]
    While personally I don't have an issue with a resumption of a minimal level of activity being a precondition, note by design it would make it harder to return to administrative duties compared with the current process, not easier. That aside, it would provide an opportunity for the editor to re-establish connections with the community, and to demonstrate through their communication style that the account was not compromised. Perhaps it could apply for admins who have been away for more than some maximum sabbatical period. isaacl (talk) 21:51, 20 July 2025 (UTC)[reply]
    by design it would make it harder to return to administrative duties compared with the current process, not easier: Feature, not a bug. If an admin is actually becoming active again, this doesn't make it harder. Just makes it take a few months, which seems like no big deal. If an admin isn't actually becoming active again, this makes it harder. Valereee (talk) 22:50, 20 July 2025 (UTC)[reply]
    Yes, as I said, I personally agree that it's a feature. Just noting that it falls into a different category than making it easier to return. isaacl (talk) 16:25, 21 July 2025 (UTC)[reply]
Funny, but people are getting genuinely confused by this tangent. Collapsing Soni (talk) 21:10, 21 July 2025 (UTC)[reply]
  • As Valereee says, a feature, not a bug. Let them produce a featured article before restoring the admin bit. Hawkeye7 (discuss) 05:34, 21 July 2025 (UTC)[reply]
    Let them produce a featured article before restoring the admin bit. does not seem to me to be the best predictor of fitness to be an admin. Donald Albury 13:25, 21 July 2025 (UTC)[reply]
    Indeed, content creation and administration are different skillsets and requiring administrators be featured article writers would simultaneously deprive the community of skilled administrators and deprive the community of featured article writers by forcing them to do admin work rather than write featured articles. Thryduulf (talk) 13:37, 21 July 2025 (UTC)[reply]
    If ever I were to need an FA before resysopping, I'm out of luck. FA does not heart my work. Valereee (talk) 20:34, 21 July 2025 (UTC)[reply]
    I thought this discussion was about making it easier, not harder. :P --Super Goku V (talk) 19:46, 21 July 2025 (UTC)[reply]
    It's not harder for anyone who actually does want to return to active editing. For them, it just takes a little longer. It's harder for anyone who doesn't want to spend any time actively editing. Valereee (talk) 19:57, 21 July 2025 (UTC)[reply]
    I think @Super Goku V was responding to Hawkeye's comment about producing a featured article. That would be very significantly hard for a great many of even the best administrators, because it simply does not align with their skills or interests. I know I'm far from the best or most active as admins, so it wouldn't be the biggest loss to the project, but if you told me I couldn't be an admin until I'd produced a featured article then you've lost me as an admin because my skills and interests lie in improving the encyclopaedia in different ways. Thryduulf (talk) 20:08, 21 July 2025 (UTC)[reply]
    Oh, sorry! Yes, it would be nigh impossible for me. I could probably get a GA for almost anything I've written recently, but I just do not produce FA content. Valereee (talk) 20:35, 21 July 2025 (UTC)[reply]
    Same here, but I cannot, because I am not an admin. Hawkeye7 (discuss) 20:44, 21 July 2025 (UTC)[reply]
I am not sure it needs to be as "easy" as "no effort", but it should be clear what there is to do (if anything). I would like it to be unnecessary to make a fuss like I did at Wikipedia:Bureaucrats'_noticeboard/Archive_50#Resysop_Request_(NaomiAmethyst): we should have clear criteria, not come up with ad hoc hoops for the returning admin to jump through. —Kusma (talk) 09:29, 21 July 2025 (UTC)[reply]
I think as long as there's a minimum "in the last year" activity level, then the resysop should be as close to "no effect" as possible. The only real issue should be in the admin is inactive, asks to be resysop'd, does nothing with the bit, and repeats. Any other concerns with an admin can be addressed at ANI, XRV, Arbcom, or with initiating a recall. -- LCU ActivelyDisinterested «@» °∆t° 13:33, 22 July 2025 (UTC)[reply]
Taking a newly-resysopped admin to ANI, Arbcom or recall is something we would want to avoid. Hawkeye7 (discuss) 05:40, 23 July 2025 (UTC)[reply]
I don't believe that recall would be a problem. I believe that a user who is re-given their admin status is immune for a year. The petition may not be created within twelve months of the administrator's last successful (...) re-request for adminship (...) --Super Goku V (talk) 06:42, 23 July 2025 (UTC)[reply]
My point was that the resysop for inactivity should be as easy as possible, e.g. issues other than inactivity bouncing (being desysop'd for inactivity, asking for resysop, doing nothing and being desysop'd again, asking for resysop, repeat) shouldn't be handled as part of the resysop.
As to recall a 're-request for adminship' is a specific thing (WP:RRFA), being resysop'd after inactivity doesn't immunise an admin from recall.
If editors believe that an admin is problematic they have routes for highlighting that, and for calling for action. It doesn't need to happen as part of the request for resysop at BN. -- LCU ActivelyDisinterested «@» °∆t° 10:36, 23 July 2025 (UTC)[reply]
  • Ease of return presumes likelihood of returning. I suspect this is at the heart of our disagreements about inactive admins. Some see this as a tidying up exercise dealing with people who have gone and aren't coming back. Others see this as longterm thinking- the adolescent who became admin may have an on off relationship with the project over many decades, and the more open our door to returnees the healthier our community longterm. I'm definitely in the latter camp - in one of my real life activities I deal with volunteers who in some cases I've known for four decades, and my recent conversations there include a returnee who has spent the last few years caring for dying relatives. I think after 24 years we have a long enough baseline that the WMF could usefully fund some research on editor and admin activity patterns, especially as different wikis have handled this differently. We need data as to how likely are people to return after five or ten year gaps? How does making our community less inviting to returnees alter their likelihood of returning? If we can identify a bit more of the real cost to desysopping inactive admins then I think we will design a better system. As for a quick change to the current system, I like the suggestion someone made earlier of a one month pause before we accept that someone has returned and is active. I think one month gives returnees time to get reacquainted with the system and catch up on changes, and is a steep test for compromised accounts to pass unnoticed. ϢereSpielChequers 23:28, 18 August 2025 (UTC)[reply]

RFCBEFORE on WP:INACTIVITY

[edit]

What do we think of an RfC asking these three questions:

  1. Should WP:INACTIVITY require edits AND admin actions?
  2. Should the edits requirement be changed, and to what?
  3. Should the admin actions requirement be changed, and to what?

Thoughts? Levivich (talk) 15:34, 28 July 2025 (UTC)[reply]

I think there should also be discussion on expectations for responding to questions. Are admins expected to remain continually available to respond to questions quickly, or can they respond after returning from a sabbatical period? Specific circumstances can of course override the general rule – other than routine cleanup actions, admins are expected to be respond in a timely manner for their most recent administrative actions. isaacl (talk) 16:36, 28 July 2025 (UTC)[reply]
Based on how the other RFCs have gone for the last year, I am now in favour of a specific proposal being given than an invitation to bikeshed. This is why we are discussing this in Idea Lab right now, because I want to float ideas and get community feedback already, and collect stats on "Who would be currently affected by this proposal" before the proposal. I would not like to effectively repeat chunks of the Idea Lab again. My plan was to put a very straightforward proposal for yes/no/yes but modify.
And my current leaning is just "1 admin action in the last 12 months" (no edit requirements). And to set up a dedicated space for Admins with 0 actions to log unlogged admin actions (like viewing deleted edits). It's simple enough and gets the core concept that enough people desire. Soni (talk) 16:47, 28 July 2025 (UTC)[reply]
What other RFCs from the last year are you referring to? Levivich (talk) 17:24, 28 July 2025 (UTC)[reply]
I do think #1 is pretty much ready to go, with a little though maybe needed on "what counts as an admin action" and "should we explicitly name an admin action count or ask that participants list their preferred number"? We should also say that it's INACTIVITY criterion 2 that's at stake. For 2 and 3, I think it's necessary to propose specific options, and I'm hoping this broad discussion will be useful in revealing some trends in what numbers people prefer. Firefangledfeathers (talk / contribs) 18:41, 28 July 2025 (UTC)[reply]
Do you think all three should be asked in one RfC, or should we have three (or two?) RFCs? For specific options, should we do a straw poll here to figure out what to propose? Levivich (talk) 19:42, 28 July 2025 (UTC)[reply]
I'd suggest #1 by itself and the other two bundled. Waiting for #1 to conclude will better inform #3, since there'd then be an admin action requirement in both INACTIVITY criteria. Firefangledfeathers (talk / contribs) 19:54, 28 July 2025 (UTC)[reply]
I'd support running #1 first, and then when it concludes, talking about #2/#3. Levivich (talk) 20:09, 28 July 2025 (UTC)[reply]
@Soni (ye olde OP), what do you think of this idea? Levivich (talk) 17:00, 29 July 2025 (UTC)[reply]
I prefer all questions at once, but I won't stop anyone who prefers otherwise. Both have their merits (Long drawn discussions vs clear consensus/outcomes) but I always am in favour of the good over stalling for perfection. You and FFF both agree on #1 before #2/#3. I disagree. It would be perfectly cromulent if you ran only #1 next. I prefer having an RFC than not. Soni (talk) 17:34, 29 July 2025 (UTC)[reply]
Would you prefer the three specific questions I posed all at once, or a different set all at once? I know you mentioned a preference for a specific proposal e.g. 1 admin action/past 12 months. I'm wondering if there is an alternative to my/FFF's idea of just running the "and" question alone, which alternative might get more support. (I'd also prefer having an RFC than not and my attempt to move this forward has, so far, only gone sideways.) So for example, another option might be to run all 3 questions at once, but change 2 and 3 to be specific proposals vs open ended questions. Levivich (talk) 16:34, 30 July 2025 (UTC)[reply]
What counts as an admin action? Most obvious ones are present at WP:MOPRIGHTS. Should any of those be excluded, like viewing deleted pages or editing fully protected ones? There are some admin actions that are not present, like closing community TBAN discussions at ANI or unban requests at AN. Can we entrust bureaucrats with judging the edge cases? Firefangledfeathers (talk / contribs) 22:43, 28 July 2025 (UTC)[reply]
My first response would be: what counts as an admin action for current WP:INACTIVITY requirements and how do the crats (or the bot) measure it? I don't know the answer to that.
My personal definition would be "any action that requires admin perms," so that would include editing through full protection and closing discussions that only admins can close. I'd be hesitant to include viewing deleted pages as an "action," although I suppose it might be, but I really don't think "I looked at deleted edits" should count towards meeting any activity requirements.
I'm not sure that "what's an admin action?" is something we need to address though. We've had these inactivity requirements in place for 3 years now. Have we had any problems with regard to what counts and what doesn't count as an admin action? The notion of an admin who performs only unlogged admin actions seems more hypothetical than real--has there ever been an inactivity problem resulting from unlogged admin actions? It seems our current vague definition might be working just fine?
With all that said, I'd be fine with specifically requiring logged admin actions. I'm just not sure that's a requirement that's needed, given the apparent lack of any problems arising from the logged/unlogged issue. Levivich (talk) 22:54, 28 July 2025 (UTC)[reply]
The qualitative difference with the new proposals is that now admin actions will actually be required, since the status quo only desysops those who have "made neither edits nor administrative actions". My assumption here is that the "what is an admin action" question hasn't been tested because everyone tends to edit more than take admin actions. I'm not desperate to have this conversation now, but if it ends up being a sticking point at least we have a starting point. Firefangledfeathers (talk / contribs) 22:59, 28 July 2025 (UTC)[reply]
That's actually a good point, I think you're right that "what is an admin action" will become relevant under the proposed change in a way that it wasn't before. (Although I was surprised to learn from Worm's updated stats that there are admins who meet the admin-actions requirement but do not meet the edit requirements. That's one of the things that persuaded me that we need "and" rather than admin-actions-only.) Levivich (talk) 23:39, 28 July 2025 (UTC)[reply]
What might be needed in an RFC is a discussion about whether the inactivity requirements are intended to be as they are currently written essentially an automated security feature that is "reversible" and "never considered a reflection on the user's use of, or rights to, the admin tools", or as seems to be a common interpretation, a target to be achieved that by itself justifies the toolbox. CMD (talk) 23:08, 28 July 2025 (UTC)[reply]
Admin actions are currently part of the requirements, but only when assessing the eligibility for resysop after handing in the tools, or for asking for the tools back after an activity-related auto-desysop. For admins who have always kept up with the editing requirements, there has never been a need to assess number or frequency of admin actions. If this change (to require admin actions as well as edits) is brought in, there will be a need to consider how to transition from the old requirements to the new ones, otherwise you will get people returning after a lengthy break to find the requirements changed in their absence and the point at which they needed to become active again changed without them knowing. Does that make sense? In other words, try to only apply the new rules once the relatively inactive admin has become aware of them. And/or allow a grace period or allow the bureaucrats discretion to judge such edge cases. Carcharoth (talk) 23:09, 28 July 2025 (UTC)[reply]
This issue was handled fine in WP:ADMINACTIVITY2022 via notifications and delayed implementation; no reason to think we'll have a problem here. Levivich (talk) 23:40, 28 July 2025 (UTC)[reply]
Still best to make those provisions clear at the outset, otherwise people might object on that basis. Carcharoth (talk) 10:49, 29 July 2025 (UTC)[reply]
I don't think a list of questions is the sticking point. What you need are well-articulated reasons for changing the activity requirements, and reasons why the current policy is insufficient and how your changes will remedy that. The first RFC, establishing the 12 months with no activity at all, was a security measure that passed handily. The second was ostensibly about admins "losing touch with the community", but also had a strong sideline of people dumping on "legacy admins". Recent attempts (e.g. December 2024, May 2025, this, and an even newer attempt) seem to be much more of the same, with the ones this year being strongly pushed by some people using WP:RECALL to pick off individual admins who aren't active enough for their tastes but are meeting/gaming the letter of the existing inactivity policy.
So what are your reasons? Security? I don't see it. "Losing touch"? Present evidence that the existing requirements aren't good enough. WP:RECALL abuse? Maybe you need an RFC about that instead. Just dumping on "legacy admins" and/or admins who aren't as active as you'd like? I suppose you might win with that, if you can rouse enough of a rabble. Something else? What is it. Anomie⚔ 23:35, 28 July 2025 (UTC)[reply]
The time for sharing reasons for changing the activity requirements is in the RFC, not the RFCBEFORE. The RFCBEFORE is about developing the RFC question, it's not about developing the RFC answer. You can read my reasons when the RFC launches and I vote; whether those reasons will be well-articulated, I can't promise. But to give you a preview of what I'd say in the RFC on #1 (requiring both edits and admin actions), we have recently learned that there are dozens and dozens of administrators who haven't made a single administrative action in over 5 years. Dozens who have made less than 10 actions in the last 10 years. Nine admins have made less than 10 actions ever, and eight have made less than 5 actions ever. And that's just crazy. People who haven't used the admin perm in 10 years, or 5 years, or ever, should not be admins. And I don't want to take those people to RECALL one by one, it'll take too long and require too much editor time; we should just up the standards for everyone at once. Similarly, there are a number of admins who have recently taken admin actions, but have made like less than 100 edits in the last 5 years, or less than 300 edits in the last 10 years. That's also crazy: people who barely edit should not be using the admin tools. Both editing, and using the tools, should be a requirement for keeping the tools. Levivich (talk) 23:54, 28 July 2025 (UTC)[reply]
What is missing from that all that is why. Why should people who haven't used the admin tools in X years be desysopped? Why do you believe that "both editing and using the tools should be a requirement for keeping the tools"? What problems are inactive admins causing? I'm not implying you don't have answers to those questions, but unless you can and do clearly articulate them, an RFC to change the activity requirements will just be a waste of community time. Thryduulf (talk) 01:09, 29 July 2025 (UTC)[reply]
This is the question I'd most like to see answered. Lots of the discussion seems based on a notion that the issues are self-evident, but they aren't. "Use it or lose it" is a slogan, not an argument. The only thing that makes sense to me is that an admin should have bulk experience of editing so that they understand the problems that ordinary editors face, but that doesn't have to be recent. Zerotalk 02:59, 29 July 2025 (UTC)[reply]
I think it does have to be recent, because things change. Just because someone knew what they were doing 10 years ago doesn't mean they still know what they're doing today.
And it's not like we're asking anyone to pass RFA to prove they still know what they're doing, all an admin has to do to regain their bit after an inactivity desysop is be active again--not even that, just say they intend to be active again. It's so easy to restore that I'm comfortable erring on the side of high activity requirements.
What I'm not comfortable with is people who make a few edits for a decade having the power to block editors and delete pages. The risks of bad adminship are great: one block that drives off a good editor might mean we lose thousands or tens of thousands of good edits. So it just takes one admin, out of almost a thousand, to make one bad block (or bad unblock), that will result in significant loss. The chances of that happening are relatively high. I've seen it happen more than once, and as recently as the past year (specifically: an inactive admin returning and making a bad block or unblock). (And before anyone asks, no, I'm not going to name names.)
Whereas, on the other side of the scale, what's the worst that's going to happen if our inactivity requirements are higher than they need to be? More admins might have to say they're active before regaining their bits? The crats might get more such requests than they otherwise would? These are minuscule trade offs to ensure the admin corps -- all of them -- are up to date, active members of the community, to reduce the risk of bad blocks (and unblocks and other bad admin actions).
The other part is that I don't think it's fair that current admin candidates are rejected for failing to meet certain criteria, while dozens or hundreds of admins also fail to meet that criteria.
Finally, the no-two-classes-of-editors, it's-not-a-lifetime-title thing. Adminship shouldn't be something that you achieve once and get to keep for the rest of your life as long as you don't break the rules and make 100 edits every five years. For security reasons, competency reasons, trust-of-the-community reasons, equality reasons...lots of reasons...it should be use it or lose it. Not just a slogan: it's a whole philosophy :-) Levivich (talk) 07:06, 29 July 2025 (UTC)[reply]
I accept that recent editing experience is better than ancient editing experience. But I don't find the rest convincing. Consider A = an admin who blocked 10 people in the past year, B = an admin who last blocked someone 5 years ago. Who is the most likely to make a bad block in the next year? If you think it is B, I think you are wrong. Someone who rarely uses their admin powers is less likely to misuse them. I'm not going to name names either, but I'm sure you can think of some active admins who did bad in the not-distant past. I also believe, but don't ask me for stats, that most complaints are about active admins. Zerotalk 07:37, 29 July 2025 (UTC)[reply]
Even if so, if I desysop A, I prevent the bad blocks but I'll also lose the good blocks. If I desysop B, I prevent the bad blocks and lose nothing. Levivich (talk) 13:12, 29 July 2025 (UTC)[reply]
Nobody suggested defrocking A. You also seem to have not considered the possibility that admin B blocks rarely because they are super-cautious and only block when they are sure it is necessary. Personally I prefer that approach rather than someone who blocks on a whim, wouldn't you? Zerotalk 07:25, 31 July 2025 (UTC)[reply]
So cautious they haven't taken an admin action in 10 years? :-) Levivich (talk) 14:01, 31 July 2025 (UTC)[reply]
I often find that while I am considering whether an editor should be blocked, another admin blocks them. So, an admin more cautious than I am will not place many blocks. You may think that makes them a bad admin. I am not so sure. Donald Albury 15:21, 31 July 2025 (UTC)[reply]
If an admin's approach to adminning results in them not taking any admin actions for years (whether due to extreme caution or whatever reason), then yes, that's a bad approach to adminning. An admin who doesn't admin for a long time isn't an admin at all, just like a person who hasn't edited in years isn't an editor anymore. They might have been, they might be again, but no one is good at something that they don't do at all. Levivich (talk) 16:32, 31 July 2025 (UTC)[reply]
We can agree that an admin who did nothing for a long time isn't an asset. But you have not established that they are a liability. To me it seems solidly in the "who cares?" column. And moving the goalposts is not good argument; you are suggesting a much tougher rule than "nothing for years", are you not? Sorry if I misunderstood, this debate is very messy. Zerotalk 05:45, 1 August 2025 (UTC)[reply]
I don't think it's fair that current admin candidates are rejected for failing to meet certain criteria, while dozens or hundreds of admins also fail to meet that criteria. RfA is indeed broken, but that is a poor argument to break other things. If you want to fix intergenerational fairness, why not make things better for the newbies instead of kicking out old hands? Given the state of RfA, admins returning from inactivity are still one of our better sources for active admins.
Your argument about the risk of adminship applies much more to highly active admins than to inactive ones: an editor making thousands of blocks can easily cause significant damage, as seen in some of the recalls of active admins. —Kusma (talk) 10:27, 29 July 2025 (UTC)[reply]
Levivich says "we have recently learned". My understanding is that all the points he raised were either raised in the previous discussions, or those who participated in previous discussions were aware of this already (the activity stats were used back then as well). Mostly the same legacy admins and levels of legacy activity were present at the previous discussions. Why is it more of a concern now then it was then? What has changed? Is this a case of "did not like the previous result, so now attempting to right this wrong" or is this a case of "X has changed since last time, so we need to revisit this issue" (in which case, say what 'X' is)? The other consideration is stability in the requirements. It might be a good idea to get a clear and overwhelming consensus and then leave it alone for a good while. Otherwise there is a sense of the goalposts shifting every few years. One option (to see how much support it gets) maybe should be: "stop fiddling with the requirements, and leave this alone for the next five years." Carcharoth (talk) 10:49, 29 July 2025 (UTC)[reply]
You know, the exact same set of statements could be said about WP:RFA2024 as well. Several of the passing proposals were in fact perennial proposals. WP:Consensus can change and so I don't think your arguments hold as much merit.
What has changed in the last half decade, in my opinion, is that the culture of accountability has grown. And I see it as a clear positive, not treating adminship as a lifetime privilege. We are nowhere near WP:NOBIGDEAL but we are closer than we ever have been over the last 10 years.
An option to provide stability might be a solid call regardless, you have very valid points about clear expectation setting. I just want to rebut the other arguments, because these changes have several very logical reasons behind them, even if you don't accept them. Soni (talk) 14:40, 29 July 2025 (UTC)[reply]
I see you've gotten several useful replies from others already. I'll just add that maybe I'm out of step, but IMO unless everyone likely to participate is familiar with the background then just a bare question is liable to attract votes based on bias and emotion rather than to bring about reasoned discussion of the issue and solutions to it. Anomie⚔ 11:49, 29 July 2025 (UTC)[reply]
It will also draw some oppose votes "because no reason for change was given". WhatamIdoing (talk) 19:56, 29 July 2025 (UTC)[reply]
  • This might be out of scope of the RFC you envisioned here, but I would like to see consideration of what happens at the other end of inactivity when a user asks for the tools back. Currently we have a hard jump from "no problem, standard 24 hour hold" to "No can do, RFA is that way". I'd like to see an intermediate standard where someone returning from a lengthy inactivity (total or partial) should have to re-engage with he community meaningfully before the bit is flipped back on. My spitballed proposal would be that an admin should be required to return to earnest engagement in the project for 1 month per year they were inactive/mostly inactive. I get that this is a little fuzzy for the crats, and also that it might be out of scope for the RFC, but I'd rather bring it up now than risk trainwrecking or being drowned out of the full RFC. Tazerdadog (talk) 02:33, 29 July 2025 (UTC)[reply]
  • I'm just going to throw this out because there are too many concurrent discussions happening about admin activity, and sorry but I'm not going to read them all to see if this has already been proposed (though I'm pretty sure I've proposed it before). The problem that WP:ADMINACTIVITY2022 was meant to address was inactive admins whose only activity is logging in once a year in response to the notification that they're about to lose the bit due to inactivity, and by doing this some admins retain the bit for many years without meaningfully participating in the community and are out of touch with current expectations when they do return. Of course the 2022 RFC failed to solve that problem because we're still talking about it. We've already spent hundreds of thousands of words in many discussions over many years getting to the requirements we currently have, and talking more about tweaking the requirements is bikeshedding as somebody else aptly put it. The issue isn't the requirements, it's a matter of simple human nature - holding onto the bit is easy, asking for it back after it gets removed is also very easy but just a tiny bit harder. Instead of informing an inactive admin that they're about to have the bit removed for inactivity, we should instead inform them that it has been removed and that they can request it back at WP:BN when they want it back. If we simply change the process from "easy to keep when you're not using it" to "easy to recover when you haven't used it", we will likely find that many inactive admins who are no longer invested in the project will simply not bother. I mean, it's worth a try. As for recall petitions started by editors who invent their own criteria for admin standards, that's literally what the community asked for, a downside that many of us warned about, and a consequence that we now have to live with. Ivanvector (Talk/Edits) 15:22, 29 July 2025 (UTC)[reply]
    Oh, but to address the questions that were asked: per past discussions, many "admin actions" are things that aren't logged or technically can't be logged, especially viewing deleted content, and it has been pointed out before that there are a few admins who only do things that aren't logged. And the activity requirements are about a desire for admins to be active participants in the community, not just button pushers. My opinion is that the activity requirement should be edits only: we can presume that an admin who actively edits is engaging with the community, but the reverse is not true for logged actions. As for questions 2 and 3: no, the requirements should not be changed, per WP:BIKESHED and my comment above. Ivanvector (Talk/Edits) 15:29, 29 July 2025 (UTC)[reply]
  • This discussion has been opened for nearly a month now... is anyone going to start the RfC? I suggest asking one simple question, something along the lines of Should the WP:INACTIVITY requirements be changed? Y/N or Should the requirements in WP:INACTIVITY be more strict? Y/N. If the RfC outcome is No, then we have our answer and nothing further needs to be done. If the RfC outcome is Yes, then we can have further discussions about what needs to be changed. (And if the RfC outcome is Yes, then the editors who voted !No in the initial RfC would be considered disruptive if they attempt to claim in these subsequent discussions that nothing needs to be changed.) Some1 (talk) 22:13, 10 August 2025 (UTC)[reply]
    And if the RfC outcome is Yes, then the editors who voted !No in the initial RfC would be considered disruptive if they attempt to claim that nothing needs to be changed That's not how things work around here. And let's not set up a requirement for a politician's fallacy. Anomie⚔ 22:23, 10 August 2025 (UTC)[reply]
    I also wonder if the RfC should have separate sections for admin/non-admin !votes (similar to how there's separate sections for participants/non-participants or involved/uninvolved). Some1 (talk) 23:44, 10 August 2025 (UTC)[reply]
    I'd be fine with starting an INACTIVITY RfC any time. There's a segment of the community that feels the RECALL question needs to be settled first (not me), so maybe we'd be more likely to reach consensus if we wait? If we do start an INACTIVITY RfC, I'd strongly prefer more specific questions. I still like Levivich's 3-part framework, and I'm coming around to Soni's side on running all three at once. My condensed, tweaked, and fleshed-out suggestion would be:

    WP:INACTIVITY criterion 2 currently says that an admin who "Has made fewer than 100 edits over a 60-month period" may be desysopped. If you support a change on either of the two questions below, please indicate minimum and maximum numbers that would be acceptable to you.

    1. Should it additionally require admin actions, and if so, how many?
    2. Should the edits requirement be changed, and to what?
    • Hopefully, !votes would then look something like "Q1 Yes, between 1 and 100. Q2 Yes, between 150 and 500. Reasons reasons reasons." I believe a closer would be more likely to assess some consensus there than if some people say "'Yes, 20" and others say "Yes, 100" without indicating how they rank those options compared to the status quo.
    I'm also interested in Soni's proposal. He say below he's working on some stats. Firefangledfeathers (talk / contribs) 14:47, 11 August 2025 (UTC)[reply]

Interaction with RECALL

[edit]
Any such RfC should include wording that rules out the use of Recall as a backdoor way to implement stricter requirements. Otherwise I don't see a point in having numerical standards at all. Make admin recall about tool misuse, not about edit count. —Kusma (talk) 17:49, 28 July 2025 (UTC)[reply]
I completely agree with this. If we want to have objective inactivity standards then we need to have a single set of objective inactivity standards and enforce them consistently, which precludes the use of recall for activity-related issues. If we want to have inactivity-related recall petitions then we need to deprecate the objective inactivity standards (optionally replacing them with guidelines that are explicitly not minimums) and do all enforcement via recall petition. My very strong preference is for the former. Thryduulf (talk) 18:13, 28 July 2025 (UTC)[reply]
I think it would be a bad idea to raise this question at all and an especially bad idea to bundle it with other INACTIVITY reforms. I think existing PAGs prevent recall votes based on obviously inappropriate bases (like racism) and that pretty much anything else should be fair game. I still see procedural inactivity procedures being useful in a world where some community members view low activity levels to be recall-worthy. Firefangledfeathers (talk / contribs) 19:54, 28 July 2025 (UTC)[reply]
Agreed, any proposed changes to WP:RECALL (or WP:RESTORATION) should be handled by separate RFCs; this one is about WP:INACTIVITY. Levivich (talk) 20:09, 28 July 2025 (UTC)[reply]
Seems like a waste of an RfC then. —Kusma (talk) 20:17, 28 July 2025 (UTC)[reply]
+1. I am very much against hijacking this proposal with any RECALL reforms, and have been consistently phrasing the current "RFCBefore" question accordingly. That is a separate discussion and a separate set of RFCs; anyone who prefers them is welcome to start them off, separately to the the INACTIVITY focused RFC. Soni (talk) 01:28, 29 July 2025 (UTC)[reply]
Recall is the central point of contention here. It is where admins meeting the activity criteria are desysopped for inactivity, making the activity criteria worthless. —Kusma (talk) 08:07, 29 July 2025 (UTC)[reply]
Let's put an end to this misinformation here and now: nobody has ever been recalled for inactivity alone. The three recalls where inactivity was a factor were based on communication problems and/or gaming. Had there not been communication problems and/or gaming, those three would not have been recalled. Levivich (talk) 14:51, 29 July 2025 (UTC)[reply]
Inactivity has not been the sole reason for recall, but it has been a significant and (depending on individual perspective) in some cases principal, factor in recall. Had inactivity not been a factor then the petition against Night Gyr would not have been initiated and multiple supporters made it clear that inactivity was the reason they were supporting. Kusma's comment is not misinformation and I'd ask you to withdraw the accusation that it is. Thryduulf (talk) 15:20, 29 July 2025 (UTC)[reply]
When an editor gets their XC pulled for gaming XC, we don't say that they got their XC pulled because they reached XC. That would be inaccurate bordering on dishonest. When an admin is recalled for gaming inactivity requirements, we don't say "desysopped for inactivity," for the same reason. Levivich (talk) 15:43, 29 July 2025 (UTC)[reply]
Nobody has been desysopped for "gaming inactivity requirements" because they were not "gaming the inactivity requirements", they were meeting the minimum activity standards set out by the community in a manner that a small number of editors disliked. I have never seen a case of someone getting their XC pulled for gaming where it was not objectively clear to everyone involved that the editor was actively and purposefully editing with the intent to game the restrictions - which is very dissimilar to the editing those deysopped for not being active enough for some editors' personal taste were engaging in. Thryduulf (talk) 15:52, 29 July 2025 (UTC)[reply]
I don't see a way that you can look at this recall or this recall and claim that nobody has been desysopped for gaming inactivity requirements. Just because you disagree that they were gaming, doesn't mean they weren't desysopped for gaming. 25 people thought otherwise and signed within 24 hours. You have a right to disagree with the outcome, but don't misrepresent the outcome. It's dishonest, Thryd. Levivich (talk) 16:35, 29 July 2025 (UTC)[reply]
I don't think that's fair, Levivich. Some of those "25 people" thought the behavior met their personal idea of "deliberately misusing Wikipedia's policy or process for personal advantage at the expense of other editors or the Wikipedia community" (Hmm, another candidate for WP:UPPERCASE?), but that doesn't mean that those 25 people were right. Thryduulf doesn't think that compliance with the written rules meets his idea of "deliberately misusing Wikipedia's policy or process for personal advantage at the expense of other editors or the Wikipedia community". He could be wrong, just like the people holding the opposite opinion could be wrong, but he could also be correct (just like the people holding the opposite opinion could be correct).
If you want to find out whether it's a case of "deliberately misusing Wikipedia's policy or process for personal advantage at the expense of other editors or the Wikipedia community", then you need to collect some facts:
  1. Was it done "deliberately"?
  2. Was it "misusing Wikipedia's policy or process"?
  3. Was it done "for personal advantage"?
  4. Did said personal advantage come "at the expense of other editors or the Wikipedia community"? (What exactly did it cost those other editors to have a barely active admin? Is there any actual cost you think the non-admin majority in the RECALLs would publicly admit to? I assume that they'd like to say something that makes them sound better than being green with envy that this slacker got to keep his all-powerful admin bit for another year, when they didn't get it in the first place, or that the pack perceived a weakness in someone near the top of the dominance hierarchy and decided to attack.)
I am really interested in what you said above about if you get blocked, you want it to be done by someone who is at least as active as you. I think there is an important social fact buried somewhere in there. WhatamIdoing (talk) 20:18, 29 July 2025 (UTC)[reply]
Levivich's understanding of the history matches my own. I'll add that the suggestion that RECALL invalidates INACTIVITY is also falsifiable using the record. RECALL has been in place since last November, and since its establishment there have continued to be procedural desysops for inactivity. About 20 admins have lost the bit through the INACTIVITY process during that time, with 7 of those happening since the mid-March Master Jay recall, the first of the ones where activity was a major concern listed by signatories. Firefangledfeathers (talk / contribs) 15:21, 29 July 2025 (UTC)[reply]
It invalidates the expectation that if you are more active than the inactivity threshold, you will not be desysopped for inactivity. So the threshold is now completely unreliable. —Kusma (talk) 16:04, 29 July 2025 (UTC)[reply]
If you are more active than the inactivity threshold, you will not be procedurally desysopped for inactivity. The current threshold is reliable for determining procedural desysopping, and every new proposal I'd support will similarly be reliable. Admins who are using the criteria for procedural desysopping as a minimum for retaining the trust and support of the community are welcome to continue doing so, but I wouldn't be comfortable with that myself and would discourage it generally. Firefangledfeathers (talk / contribs) 16:17, 29 July 2025 (UTC)[reply]
And that is the point. Either meeting the inactivity thresholds mean you will not be desysopped for inactivity, procedurally or otherwise, or they are worthless. Thryduulf (talk) 16:20, 29 July 2025 (UTC)[reply]
I can't think of a way to state my disagreement with this without repeating myself. I'll leave a final restatement that I oppose trying to bundle INACTIVITY reform with RECALL reform, and I'll anticipate with some mild dread that arguments of this type will eventually be presented in the RfC. Firefangledfeathers (talk / contribs) 16:27, 29 July 2025 (UTC)[reply]
This is precisely why this thread was specifically focused on INACTIVITY and not RECALL. I've repeatedly stated it, only to be bludgeoned by the same few editors, all of who seem to be admins. At this point, I suspect we'd be all better off if these side tangents are collapsed or otherwise split into a section so they don't keep trying to derail this discussion over and over. (I have now split this tangent) Soni (talk) 16:32, 29 July 2025 (UTC)[reply]
The point is that the two are, at present, inextricably linked because whether admins can be recalled for inactivity or not impacts what the inactivity requirements should be. Thryduulf (talk) 16:35, 29 July 2025 (UTC)[reply]
As a non-admin who has been less active in this discussion - I basically agree with Thryduulf. The live controversy around admin activity is around recall. The only real discussion of whether our admin activity standards are appropriate prior to this is within the context of a recall petition. I don't think calling recall as out of scope is practical for this discussion when it goes live. Tazerdadog (talk) 17:59, 29 July 2025 (UTC)[reply]
@Firefangledfeathers, the fact that RECALL will inevitably be mentioned in any RFC about INACTIVITY is IMO the reason to address this directly.
If you'd like to deal with it preëmptively, then you could start a RECALL-focused RFC that either says "Don't use RECALL if your primary complaint is inactivity – we'll get there soon enough without wasting community time" or that proposes the addition of a couple of short lines to INACTIVITY: "There are two ways to get de-sysopped for inactivity. One is a semi-automated process if that desysops anyone who doesn't make X edits/Y admin actions over Z time period. The other is if anyone decides that, in their personal opinion, you are too inactive for their taste and opens a successful RECALL". WhatamIdoing (talk) 20:31, 29 July 2025 (UTC)[reply]
That second way is not about inactivity, but Recall. You'd achieve a similar effect noting you can IAR on every policy page. CMD (talk) 20:36, 29 July 2025 (UTC)[reply]
The second way is absolutely about inactivity. It is entirely about some editors being dissatisfied with someone's possession of an admin bit despite their lack of activity, and deciding to band together to remove the sysop bit. Consider some of the comments in the two RECALLs linked above:
  • "they have been quite inactive"
  • "An account this inactive with the tools is a security risk"
  • "I would expect an admin to be far more active"
  • "lack of activity"
  • "has not been contributing"
  • "currently gaming the activity requirement"
  • "Clearly inactive"
  • "Sparse activity"
  • "their low activity level"
  • "Inactive"
  • "not an active editor"
Sure, some editors gave multiple reasons or a different reason, and some editors gave no reason at all, but when I skim down the list, some variation on inactivity or its results was the most common reason given. WhatamIdoing (talk) 22:45, 29 July 2025 (UTC)[reply]
The point is not that inactivity was not involved in some cases, it is that any reason can be used for a recall. CMD (talk) 14:37, 30 July 2025 (UTC)[reply]
My point is that maybe "any reason" shouldn't be acceptable for a recall. Maybe the community should not say, out of one side of its mouth, that we have established some objective WP:INACTIVITY rules, and then say, out of the other side of its mouth, that any 25 editors who disagree with the community's compromise on inactivity is welcome to flout it by dragging rules-compliant admins off for a no-holds-barred WP:RECALL. WhatamIdoing (talk) 19:51, 23 August 2025 (UTC)[reply]
I could not possibly agree more. The implications made above (and in the petitions cited) that these admins are "gaming the system" are incredibly euphemistic and worrisome. I fail to see how adhering to the standards the community has adopted becomes a form of bad faith activity merely because the admin in question complies with the minimum expected of the standard, or does so in a perfunctory or last minute manner. Their doing so still demonstrates they are engaged with the project and aware that they are at the floor of expectations. If the community wishes to raise that floor, it may do so, but it is one of the most staggering displays of WP:ABF that I have ever seen taken by a significant minority on this project that these users (whose dedication and contributions to the project are high enough that the community gave them the bit in the first place) are framed, by shoddy rhetorical flourish, as having acted against the project's interests merely by hitting a threshold just above what the community has said it expects.
Indeed, some of the speculation in those petitions is simply wild and/or downright ugly, and a real slap in the face to the work of these volunteers. I don't understand this reasoning at all. It seems to be based on the worst kind of WP:BURO thinking--a bit of policy verbiage that I am not disposed towards citing reflexively, because I think complex systems of administration are the name of the game on this project because of its nature and scale. But if ever there was an occasions to cite it, this is it. We've been in the middle of an admin retention crisis for years, and yet here we see a rush to desysop editors who have evidenced no indication of abuse of the tools, or lack of familiarity with evolving community standards, or security concerns.
Both these petitions and the drive for more onerous inactivity guidelines seem the epitome of solutions in search of a problem, but at least with regard to the latter, I can see the situation as one where variation in upkeep with community standards in individual cases gives some grist for the mill for an ongoing conversation about calibrating the exact figures. Some of the cited petitions, on the other hand, are disturbingly wrong-headed, contain perspectives that are needlessly punitive of non-issues, and, I don't doubt, have deeply hurt the prospect of those admins continuing to contribute to the project at all, going forward. I'd certainly feel kicked in the teeth if I saw some of those comments directed at me as if I was a problem user trying to cling on to advanced permissions for nothing other than cred, merely because I didn't have the time to do more than the minimum, but did foresee using the tools for the betterment of the project moving forward, and so met those requirements.
Bluntly, the drive to increase the threshold for inactivity reeks of WP:CREEP--another principle I think should be invoked sparingly, but which I think applies here. But at a minimum, I agree that no inquiry to advance more restrictive standards should take place without integrated discussion of establishing that admin recall and procedural desysoping for inactivity are parallel and separate processes, and that, whatever we decide the standards for activity are, it is only express, brightline failure to meet those figures which triggers the desysoping for inactivity. Recall was unambiguously created to address abuse of tools, and I recall a lot of us pushed back hard against those who advocated for no recall process at all, when they said it would be abused for this kind of nonsense an thus exacerbate the challenges with keeping admins on the job. It's now time to push in the other direction and be as good as our word as to that. The only time I can ever fathom "gaming" to be an issue is when an admin takes an action against another editor in the 11th hour in order to satisfy the activity requirements. And that's highly unlikely to happen so long as admins can satisfy the requirement through normal editing alone--a strong argument for preserving that aspect of the status quo at a minimum.
These issues are part and parcel and cannot be discussed effectively in isolation for one-another. I'm open to reviewing the data and arguments for heightening the activity standards, but first we need to make it clear that whatever standard the community settles on, good faith administrator-contributors are not going to be hauled before recall on the most specious, pointless, tedious arguments that they are not operating in good faith, even when they meet those standards. I cam out vociferously in support of a recall process every time the subject came up (and began to despair that it would never happen) because I felt the community ought to have the ability to rescind those permissions it granted in the first place, and because accountability is essential to good governance. But nit-picking the heels of good faith mops over small margins on the metrics of their activities is not what I had in mind when I speculated on that need, and I think the vast majority of those of us who argued for the process would say the same.
We need an unambiguous delineation of the roles and standards for recall and procedural loss of the tools for inactivity. Recall should have flexibility for the community to address substantive problem behaviour in those with the tools. Inactivity should have clear, firm standards, and admins should not be harassed if they meet them, however minimally and formulaicly. Good golly, so much effort to put up walls on this project over recent years. On this very page right now, we have discussions proposing disempowerment of parties who run the gamut from the very newest editors all the way through to most veteran and trusted users. Do people not get just how critical our retention and recruitment problems are, and how dangerous this trend is to the long-term sustainability of the project? SnowRise let's rap 02:40, 24 August 2025 (UTC)[reply]
In re Do people not get just how critical our retention and recruitment problems are, and how dangerous this trend is to the long-term sustainability of the project?
No, they don't get it. But the numerate among them may want to look at the numbers in Wikipedia talk:Wikipedians#Numbers of editors each year. Our overall editor numbers were stable until the pandemic lockdowns, and we got a bump in editors during the lockdowns. We expected that to reverse, and it did, but it's fallen even further since then. In particular, we are losing newbies and occasional contributors – the people who make one or two edits, 10 or 20 edits, even 50 or 100 edits in the course of a year. These are the people who write content, rather than running scripts. They are also the source of the next generation of editors. Between 2023 and 2024 alone, we lost 5% of the editors who make just one or a few edits in the course of a whole year. WhatamIdoing (talk) 04:48, 24 August 2025 (UTC)[reply]
Maybe the community shouldn't say, out of one side of its mouth, that adminship can be reviewed, and then out of the other side of its mouth, say that actually admins cannot be reviewed on certain matters and carve out exceptions to community discussions. Maybe the editors who disagree with the community's very arduous journey towards RECALL should not try to immediately undermine it (despite the furore, the number of closed petitions a year on can be counted on one's fingers). Easy to make rhetorical formulations like that, and these ones don't even conflate procedural standards with a community process. CMD (talk) 03:38, 24 August 2025 (UTC)[reply]
I agree: The community's written rules and practices should be consistent. I believe that one way to make those be consistent is to say that there are some limits to valid use of RECALL. For example, I don't think that outright bigoted complaints should be a valid RECALL petition, and if anyone started one with a discriminatory justification like 'We can't have an admin who is that race/nationality/gender/religion', I'd like to see it stopped and the editor blocked. I bet you would feel the same way. Thankfully that hasn't happened, but I don't really want to wait until it after it happens before we say that actually admins cannot be reviewed on certain matters. WhatamIdoing (talk) 04:34, 24 August 2025 (UTC)[reply]
Respectfully, the recall process exists to give the community the ability to arrest habitual abuse of the tools, not to create opportunities for a relatively small number of editors (compared against those who authorized the bit in the first place) to conjure up complaints about activity levels that exceed the express standards which the community at large has already agreed to through consensus process.
You're quite correct that the path towards recall was tedious and difficult. Much of that was because some feared the process would be too permissive and create knock-on effects which would result in it doing more harm than good. Many of us dismissed that concern as either histrionic or not sufficient to justify not having the process. I believe the resulting process will still end up being an advisable and beneficial development for project administration. But I think it's clear that the concerns have proven not unfounded. We do not need this process becoming a portal for parties to appoint themselves special prosecutor and go after admin tools on grounds which are not even supported by our own community-agreed standards on activity. It's bad for retention, its bad for community goodwill, and its bad for the operation of oversight.
Setting some guardrails here is not just good sense; I'd argue it's essential for maintaining the integrity and credibility of the process. Part of how we ultimately got community recall authorized was the argument that the ultimate procedure could be appropriately calibrated for the right cost-benefit result. Setting parameters to prevent specious arguments that exceed community-agreed terms for de-sysoping for inactivity is an entirely reasonable step towards that refinement of the process, and one that preserves the core function of recall and protects the process and admins who are otherwise in good standing. SnowRise let's rap 04:49, 24 August 2025 (UTC)[reply]
People moving my comments makes this hard to track. The written rules and practices are currently consistent. The recall process exists to provide a process by which admins can be recalled by the community. What seems bad for community goodwill is that after a couple of decade of resistance to community review, when community review is put in place the response is "no, not like that". It also seems bad for community goodwill to exempt the admin rights from guidelines that apply to other rights. As noted above, there is a continued appeal to treat the procedural desysop limit as an activity target in itself, which is not in policy and is not a community-agreed standard. CMD (talk) 11:44, 24 August 2025 (UTC)[reply]
The community consensus is that:
  1. Admins who make at least X number of edits within y period of time are active and those that do not are inactive.
  2. Inactive admins are desysopped for inactivity.
  3. Active admins are not deysopped for inactivity.
If you want to change that so that admins who are active can be desysopped for inactivity, you need to get a new consensus. Using recall to desysop active admins is the abuse of the process. I'm not sure why you think doing that will generate good will? Thryduulf (talk) 13:28, 24 August 2025 (UTC)[reply]
I don't want to change made-up community consensuses. If you want to put those into policy, propose an RfC. CMD (talk) 15:18, 24 August 2025 (UTC)[reply]
That is policy: WP:INACTIVITY. Thryduulf (talk) 16:05, 24 August 2025 (UTC)[reply]
Both are policy, the proposal is the change the recall policy. I don't know why one community consensus is considered more valuable than the other. PackMecEng (talk) 16:40, 24 August 2025 (UTC)[reply]
as SnowRise explains, the consensus for recall was for a process that allowed the community to deal with administrators who were abusing policies and guidelines, not to desysop administrators who were following policies and guidelines. Can you really not see the difference? Thryduulf (talk) 17:21, 24 August 2025 (UTC)[reply]
The policy of WP:INACTIVITY is that below two thresholds admin flags are procedurally removed. The varied extrapolations you make are not policy. CMD (talk) 04:23, 25 August 2025 (UTC)[reply]

But that is not actually the case is the issue. If you read WP:RECALL it makes not mention of that. So lets not make up policy and just follow what is there. PackMecEng (talk) 17:27, 24 August 2025 (UTC)[reply]

Just because a policy does not explicitly state that it was created with the intention of being used in X circumstances does not mean that it wasn't created with that intent. It's almost never necessary for a policy to explicitly state that it isn't intended to be used to bypass a different community consensus, partly because WP:BEANS and partly because we generally trust editors not to do that. Sadly it seems that trust has been misplaced on this occasion. Thryduulf (talk) 17:46, 24 August 2025 (UTC)[reply]
Okay cool, so we agree what you are saying was not in the policy. But if you want to amend it to have that we could have that discussion. Honestly I don't see why WP:INACTIVITY would override WP:RECALL, which seems to be what you want to happen. Recalling someone for any reason is legal and its not invoking the inactivity policy, so it does not come into play. PackMecEng (talk) 18:11, 24 August 2025 (UTC)[reply]
Ah I think I see the fault in your logic now. INACTIVITY isn't overriding RECALL. RECALL exists to deal with editors who are breaching policies and guidelines, that isn't stated explicitly in the policy because it is there implicitly: the entire basis for the consensus establishing it was that there was need for a process to deal with admins who are breaching policies and guidelines. Everybody assumed that abuses of the process, such as attacking editors who were complying with all the relevant policies and guidelines, would either not happen or would be swiftly shot down. I'm only seeking to make things explicit now because that assumption has proven to be naive: editors have weaponised recall to enforce their personal, arbitrary standards rather than the standards of the community. I'm not sure you do understand how disheartening it is to have to explain, repeatedly, to veteran editors that misusing community processes, assuming bad faith and misrepresenting community consensus isn't OK. Thryduulf (talk) 19:16, 24 August 2025 (UTC)[reply]
You keep saying that Recall is for X, Y, and Z and that is just false. Which seems to be the heart of the matter, you see it how it should be, and I am quoting what it is. Recall is policy, it has no limits on what can trigger it, and because of that has nothing to do with the inactivity policy. Because they are not being brought up under the inactivity policy, they are being brought up under the recall policy. As written, a recall could go through because they don't like that the admin like using the Oxford comma and that would be valid under that policy. We can have a discussion on how to modify policy to prevent that, but first we have to recognize what it is vs what it should be. What you keep repeating is what you think it SHOULD BE, not what IT IS. That seems to be the disconnect, and causing an argument based on a false premise. Also as a side note, accusing other editors of weaponizing something is in itself an assumption of bad faith. PackMecEng (talk) 20:51, 24 August 2025 (UTC)[reply]
I'm saying that RECALL is for X, Y, Z because that's what all the discussions about having a recall process, and the ultimate consensus that emerged from them, were predicated on it being about admins who have abused their tools or otherwise actively engaged in serious midconduct that discussions at other venues have failed to resolve. It's true this is not explicitly stated in the policy, but that does not invalidate those discussions or mean that the consensus built on those discussions can be ignored because of that lack of specificity (which, as noted, should not be needed). Thryduulf (talk) 21:46, 24 August 2025 (UTC)[reply]
but that does not invalidate those discussions or mean that the consensus built on those discussions can be ignored That is not really correct though. Think of it this way, there is an RFC somewhere that produces a consuses for whatever. The consesnus is for whatever, its not for things talked about reaching that consensus. If it were, those parts would be part of the final prodcut and they are not. Which means, those parts do not have consensus. Again, the things you are saying are facts simple are not. PackMecEng (talk) 12:42, 25 August 2025 (UTC)[reply]
Right. We are talking about what it should be. Or more specifically, what community consensus in the authorizing discussions intended it to be. If there are defects in the clarity of the process description page, remedying them is exactly what is being proposed now. Recall was meant to give the community an ability to react to manifestly abusive conduct by an admin without having to wait for an ArbCom case to be filed and resolved. Not to be used flippantly to prosecute some individual's idiosyncratic view of INACTIVITY that goes beyond what that policy actually calls for, by agreement of the community.
And again, to be clear, much of the delay in authorizing recall came from concerns about precisely these situations happening. That and axe-grinding foes leveraging the process to make lifer miserable for admins who had previously acted against them. Now, we haven't seen one of those cases yet, but you can bet your bottom dollar they are around the bend, because the ultimate threshold initiating recall is kind of rather minimal, in the grand scheme of things. To be frank, the precise mechanisms probably could have done with a lot more tweaking, but after years of having the process delayed, those with remaining concerns were out!voted and the process was authorized. Which I still think is a good thing, and was overdue.
But we have to acknowledge at the same time that the reservations have already proven extremely prescient. Even as someone who was gobsmacked by how many years (indeed, decades) it took to create this process, and who was increasingly critical of the opposition arguments in recent years, I have to admit that and recognize that it is time to start reigning in the blue sky approach here. We're already seeing petitions that are miles away from the kind of serious abuse cases the process was meant for, and the cost-benefit of having the process, and the validity the community regards it with, are going to plummet fast if we can't create some reasonable limitations on what kind of conduct justifies a petition.
Such adjustments were always part of the expectation of how this process would evolve, and the only way this process stays valid and does not become uglier than ANI on its worst day is by making good on the assurance that would happen. Codifying the separate intents of INACTIVITY and RECALL by clearly dilineating their aims and different standards, as understood by those who authorized them in community discussions, is a simple place to start, and also clearly the most pressing issue, since this has already obviously become the flashpoint for problematic petitions in the first year. SnowRise let's rap 21:51, 24 August 2025 (UTC)[reply]
And to be fair, some of those who held up the process of authorizing the recall process were specifically concerned about such weaponization. Though, I would also hasten to add that I am uncomfortable descrining all of the cases of problematic petitions we are talking about now as weaponization, as I do think the proponents see themselves as having the best interests of the project at heart. I would describe these cases rather as overzealous misapplication of the process for purposes for different for which it was expressly adopted (that is, misuse of the tools primarily, or other habitual violations of policy and community good will conducted pursuant to their work as administrators, or conduct which otherwise proved them fundamentally unfit for the tools). We are talking about two very distinct functions here, with different expectations of when and how they would be used and how a problem in each area should be demonstrated and acted upon:
  • WP:INACTIVITY = the process by which we remove tools from accounts, following a stream-lined process with clear usage metrics. It is not meant to reflect judgment of the admin in question or indication of bad faith conduct--it is merely a pro forma step taken rather than leave advanced permissions attached to dormant accounts. It does not come with a presumption of misconduct and most people can get the tools back without needing to re-RfA.
  • WP:RECALL = the process by which we remove tools for gross misconduct, including abuse of tools, serious violations of policy and other conduct that raises the question of suitability for the tools. It is very much expressly focused in judging the admin's conduct and qualities as an advanced permissions holder, and should be reserved for serious cases of abuse of the position, since it does come with serious consequences for the admin, including (at a minimum, engagement with an arduous re-RfA process and possible stigma, whether accusations are good-faith and well justified or not.
    Let's put aside for the moment what it puts the subject through and the fact that we ought to have good reason for doing that to someone the community trusted enough to invest the tools in to begin with. It also potentially deprives us more permanently of another admin, during a longterm and ongoing admin retention, and the process requires much more community volunteer time. For all of these reasons and more, it was always meant to be reserved for serious misconduct, not desysoping for bureaucratic technical reasons: we have other well-defined processes for those, including INACTIVITY.
I am honestly very surprised that this is so controversial. These were always meant to be discrete processes, with different goals, and different mechanisms As Thryduulf says, maybe it was naive to have not foreseen that some people would conflate the purposes of these process and over-reach with petitions that have little to do with the kind of abuse of the tools/position cases recall was intended for. But now that we are seeing just how easy it is for people to make that mistake (or recognize the distinction and just not care about using recall abusively), we clearly need to more clearly express the different roles of these processes and put reasonable limitations to prevent both willful abuse and unintentional but wholly avoidable wastes of community time and resources--including losing admins who did nothing that comes close to the kind of serious abuse for which recall was intended.
Rushing to hit your activity threshold at the last minute because you want to keep the tools and believe you are still capable of using them effectively on occasion, even if you are currently in a pronlongued activity slump ≠ abuse of the tools, violation of policy, or conduct calling into question basic suitability for the role. And though hindsight is 20/20 on failing to condify this into the process description, even though it was clearly part of the community consensus authorizing the process, I remain surprised it has to be spelled out in those terms here. But obviously it does, so...let's do that? SnowRise let's rap 21:34, 24 August 2025 (UTC)[reply]
WP:RECALL is about cases where an editor "believe[s] that the administrator has lost the trust of the community." The definition you are using to propose a distinction that is apparently being missed/ignored is unfounded in the actual process page, which does not mention "misconduct", "tools", "violation", or other key words used above. CMD (talk) 04:32, 25 August 2025 (UTC)[reply]
Right. That's what we're talking about here. Clarifying the intended distinct role of that process, and the problems it was designed to address. As Thryduulf effectively explains above, the failure to render the consensus of the authorizing discussions more precisely into the process page in no way obviates the existence of that prior community discussion and consensus. Nor for that matter, I will add, does it forestall our re-affirming the reasoning beind said consensus and adjusting the language of both WP:RECALL and WP:INACTIVITY to more effectively and pragmatically codify their respective roles and clarify when and how the processes allow us to challenge an admin's fitness for the tools.
I appreciate that some people are quite happy with this current free-for-all system we effectively fell ass backwards into with the current wording of the process page. But bluntly, the idea that such a system will sustain a good cost-benefit ratio of utility with that laissze-faire approach is an extremely credulous view. And more to the point, not the view the community adopted when authorizing the process, or is likely to permit if/when we put it to the community at large again. Anybody with the mop being subject to an immediate recall on anyone's notion of improper conduct as an admin may feel very empowering and egalitarian, especially after years of that ability being gatekept for ArbCom, but having absolutely no further guidance is, for a lot of reasons, just not feasible in the longterm.
That's my belief anyway. I don't advocate that we rely on the previous consensus discussions for what RECALL is meant to accomplish. I do think it's worth putting to the community again, expressly. I'm just confident that the history of this project has taught us enough about how people will abuse process that the same good sense in those previous discussions will come to the surface again. This process was meant to enable us to disempower admins who had turned out to be fundamentally ill-suited to the bit. Not to bean count the contribs of some of our most dedicated community members and create extra purity tests for them that go beyond that which the community has authorized in INACTIVITY. SnowRise let's rap 09:55, 25 August 2025 (UTC)[reply]
I don't remember being involved in the discussions that led to the creation of either of the guidelines so I am not familiar with what may have been discussed them. Whatever the views are of the current system, or the past system or discussions, it is not helpful nor an effective explanation to assert that RECALL or INACTIVITY say things that they do not. CMD (talk) 11:32, 25 August 2025 (UTC)[reply]
There's something about this part of the discussion that feels like this:
  • A: The rule is X.
  • B: I propose changing the rule to X'.
  • A: You can't do that! The rule is X!
  • B: I'm proposing to change the rule. Then the rule would stop being X, and start being X'.
  • A: You can't do that! The rule is X!
So, sure: The rule is "Any extended confirmed editor may start a petition for an administrator to make a re-request for adminship if they believe that the administrator has lost the trust of the community." But the point of this whole discussion is: Maybe the rule should be changed. Then the rule would stop saying "if they believe that the administrator has lost the trust of the community" and start saying something different, such as "if they believe that the administrator has lost the trust of the community and their reason is not primarily about the admin's WP:INACTIVITY". Then that new text would be "the rule" and would be followed.
Wikipedia:Administrator recall/RfCs lists the prior discussions. Glancing through the main ones, I see the word abuse a few dozen times, and inactivity is barely mentioned, except in a proposal that would have replaced WP:INACTIVITY. When it is mentioned, it is usually by way of contrast. I saw nobody mentioning RECALL as a way of addressing admin activity. I therefore suspect that if you asked the supporters of RECALL whether their original intention was to have RECALL address low-activity admins, they would deny any such thoughts. WhatamIdoing (talk) 17:36, 25 August 2025 (UTC)[reply]
I don't think the issue is wanting to change the policy. That is fine, we can have that discussion. The issue is when people say the policy means a certain thing when it does not state it. That is basically SnowRise's and Thryduulf's argument. Picking and choosing certain parts of a decades long discussion to say this policy is really meant for, really anything, not stated in the policy is a road to nowhere. PackMecEng (talk) 22:13, 25 August 2025 (UTC)[reply]
I'm sure it's unintentional, but you're misrepresenting my position (and I believe Thryduulf's). I must have said five times now, and with substantial detail each time, that this discussion is (and should be) about clarifying the existing policy verbiage so that it does conform with the consensus that authorized the process in the first. So I'm not sure how anyone could continue to think otherwise at this point. WhatamIdoing is quite correct: this is getting to be quite cyclical and a waste in time. If discussion can't proceed in good faith towards trying to figure out what a proposal could look like, this discussion will not benefit the community. SnowRise let's rap 22:51, 25 August 2025 (UTC)[reply]
The issue is the verbiage DOES conform with the consensus. Period, full stop. That is what I mean when I say you two are trying to pick and choose from those discussions what you like, vs what we actually have as policy and it is super unhelpful. It feels strange to say I am misrepresenting you and that you have explained it and then launch into a rant about exactly what I said you were doing. It's weird, don't do that. PackMecEng (talk) 23:18, 25 August 2025 (UTC)[reply]
I have a hard time understanding how anyone who particpated at any length in the discussions that authorized recall (did you?) could come away with the impression that the kind of habitual and serious abuse of tools (and/or position) that was contemplated in those discussions would include "adding a few edis at the 11th hour to comply with WP:INACTIVITY" as consistent with those concerns. You're welcome to your opinion, but I don't think you'll stand a shadow of a chance in getting the community to endorse that perspective.
Regardless, your tone here has now turned completely combative and non-collaborative (to say nothing of presumptuous with regard to telling me what I intend my own words to convey) and I won't be engaging with you further. Believe what you want to believe with regard to what I am saying: I think I've said more than enough for my perspective to be obvious to anyone following this discussion. SnowRise let's rap 00:18, 26 August 2025 (UTC)[reply]
"it is not helpful nor an effective explanation to assert that RECALL or INACTIVITY say things that they do not."
Except nobody is doing that, that I am seeing. The discussion is about how we might adjust the information pages to more closely reflect the consensus which created the process in the first place, including the prospect of further community input to confirm that consensus, to be careful and pro forma. And I would submit to you that consensus discussion to amend policy is nothing more than the normal and expected approach to such situations, and represents best practice, while making accusations against admins that they have violated policy and community trust on the basis of behaviour that is not expressly endorsed as proscribed by the community through policy or consensus (such as implying that they have done something in bad faith by complying with WP:INACTIVITY by a narrow margin or at the last moment, even though nothing in policy or community consensus forbids this) is very problematic. SnowRise let's rap 21:48, 25 August 2025 (UTC)[reply]

I've just looked at all the certified petitions and classified the supporters' comments based on how they relate to inactivity:

Petition No reason Inactivity only Inactivity primary Inactivity equal Inactivity secondary Other % inactivity relevant
Bbb23 1 25 0%
Fastily 25 0%
Gimmetrow 5 13 5 2 100%
Graham87 1 26 0%
Master Jay 9 9 3 2 3 82%
Night Gyr 1 7 3 6 2 6 75%

I've interpreted "No reason to use the tools because they aren't using them" and "Gaming the system" as comments related to inactivity because in context they are. The final column is the proportion of supports who gave a reason for supporting who indicated that inactivity was relevant to their supporting. Thryduulf (talk) 00:10, 30 July 2025 (UTC)[reply]

Quick quip, but I'd recommend pinging those whose votes were analyzed; I've had issues before where I've misinterpreted other's votes and they couldn't explain their own vote as being unaware of the discussion. I get that'd be a ton of pings, though, so just a thought. Although I don't know which categories my votes fall into; it seems like a fair assessment. — EF5 00:16, 30 July 2025 (UTC)[reply]
"Those whose votes were analysed" is everybody who signed one of the petitions. I haven't recorded to what categories I analysed individual votes (only the totals above) so if I (or someone else) did it again the numbers wouldn't necessarily exactly match as there were some borderline ones, but it would be very similar. Thryduulf (talk) 00:30, 30 July 2025 (UTC)[reply]
Good table and stats. Maybe include links to the six recall petitions that were analysed? Carcharoth (talk) 16:04, 30 July 2025 (UTC)[reply]
I'm going to disagree that there's no difference between simple inactivity -- a less-active admin who is editing just enough in an organic, non-gaming way -- and gaming the requirements. I know we disagree there's a difference, but to me that difference is valid and crucial. I'll even let slide the ones who clearly are simply reacting to alerts with a flurry of edits. But someone desysopped for inactivity who requests resysop because they're "now active again", then immediately becomes inactive again, has just proven they'll lie to get what they want. That's a trust issue and has zero to do with inactivity. Valereee (talk) 12:11, 3 August 2025 (UTC)[reply]
"I'm going to disagree that there's no difference between simple inactivity -- a less-active admin who is editing just enough in an organic, non-gaming way -- and gaming the requirements."
Except that very much begs the question, doesn't it? Rhetorically framing acts that fully comport with relevant policy as "gaming" is a false tautology. If an admin is at least observationally engaged enough with the project to know that they are about to be procedurally desysoped, but anticipates being able to make use of the tools productively in the future, and therefore takes steps to comport with activity expectations to keep them, how is any of that in the least bit inconsistent with policy, or with an intent to do right by the project or the community? If the community wants to set stricter standards, that is one thing. But manifesting hidden extra "implicit" rules for these users on the fly? That's unreliable, unreasonable, and can only serve to disrupt process and foster ill will, to be perfectly blunt.
"But someone desysopped for inactivity who requests resysop because they're "now active again", then immediately becomes inactive again, has just proven they'll lie to get what they want.
Or, and stay with me here: they are a user who acted in good faith and then had an unfortunate turn in their off-project life that prevented them from following through. Or they just changed their mind. Assuming that such an admin was lying is an example of extreme ABF towards a community member who showed enough commitment to this project to have passed RfA in the first place. See, this is another problem with creating vague, idiosyncratic personal rules about activity that go beyond those agreed by the community through consensus: it creates an incentive for needless and unhelpful speculation about the state of mind of other users--something we are generally meant to avoid here, for a bevy of reasons. This area needs objective metrics that can be reliably and equitably applied, not fishing expeditions based on mere suspicion and the self-assured belief that one has pegged the motives of another.
"That's a trust issue and has zero to do with inactivity."
Well, let's say for the moment that were so: that cuts against the argument for not having a clear rule against using recall in cases where activity is the underlying concern. For example: if an admin were, on the last day before they qualified for automatic removal of the tools, to go around blocking left and right in some concerning edge cases, then yes, I don't think anyone here would argue that situation is not ripe for recall. But as you say, at that point the petition is clearly not based on inactivity itself but a significant indication of abuse of the tools themselves. Which is what recall is actually for. SnowRise let's rap 05:26, 24 August 2025 (UTC)[reply]
Assuming that such an admin was lying is an example of extreme ABF unless said admin never bothered to explain that change in intention/ability, refused to discuss it, and refused to consider maybe just setting the tools down voluntarily until life became normal again/they actually did develop interest again. Valereee (talk) 17:49, 24 August 2025 (UTC)[reply]
That is still an assumption of bad faith on your part. And even in the unlikely event that you are correct it does not justify your assuming that in the first place, let alone extending that assumption to other editors. Thryduulf (talk) 19:07, 24 August 2025 (UTC)[reply]

RFCBEFORE on RECALL

[edit]

I think there's been a lengthy enough (in words and time) dispute over the use of RECALL for inactivity that we should proceed to an RfC. I'd propose a question like Should Wikipedia:Administrator recall include guidance that "Recall should not be used if the primary concern is inactivity. Signatures added with rationales based primarily on inactivity may be removed by any extended confirmed editor."? I'm hoping that I'm doing an ok job of representing a view that I don't hold, but I would gladly support an alternative question formed by someone who does support adding guidance like this to RECALL. I believe the best place for this RfC is at WT:RECALL, and I'd suggesting posting notices at WP:VPP, WT:ADMIN, and maybe at WP:CENT and WP:AN. Firefangledfeathers (talk / contribs) 14:31, 1 August 2025 (UTC)[reply]

I'd prefer a wording something like "Recall may not used for concerns regarding inactivity. Signatures added with rationales based primarily on inactivity may be removed by any extended confirmed editor." I agree with the desire for an RFC and with your comments about venue and notifications. Thryduulf (talk) 14:41, 1 August 2025 (UTC)[reply]
I'd be fine with that. Firefangledfeathers (talk / contribs) 15:33, 1 August 2025 (UTC)[reply]
Not meaningful when just tacking on "# ~~~~" is treated as valid. —Cryptic 16:05, 1 August 2025 (UTC)[reply]
I think whether supporting rationales should be required is probably a useful question to ask, but it's a different question to this one. Thryduulf (talk) 16:27, 1 August 2025 (UTC)[reply]
That is a "per nom" so as valid (or not) as the opening rationale. But if the rationale given by the person opening the recall petition is invalid, we should close the petition, not worry about individual signatures. —Kusma (talk) 16:46, 1 August 2025 (UTC)[reply]
Signatures on a recall petition are votes in support of the admin making a re-request for adminship (either via the open viewpoint process or standing for an election). The process intentionally doesn't provide a way to strike signatures based on others deciding that the reasoning of the signatories is invalid. isaacl (talk) 16:58, 1 August 2025 (UTC)[reply]
It currently does not provide a way. If this or a similar proposal passes that will change. Thryduulf (talk) 17:37, 1 August 2025 (UTC)[reply]
My comment was with respect to Kusma's comments on "per nom" for plain signatures, and invalidating a petition based on someone determining that an initially expressed rationale is invalid. With the current process, an unadorned signature does not implicitly refer to rationales expressed elsewhere. As the current proposal says "Signatures added with rationales", it doesn't cover the case of plain signatures, and Cryptic was raising the possibility that the change may just prompt signatures without rationales. isaacl (talk) 22:16, 1 August 2025 (UTC)[reply]
@Thryduulf, what if the signer is telling us it's not about inactivity, it's about gaming requirements, which they believe means the person will behave disingenuously to get what they want and as a result they no longer trust the editor with the tools? Are we going to call that a "concern regarding inactivity"? As we've discussed at length, I sincerely disagree that's about inactivity and is instead about gaming. Valereee (talk) 14:58, 5 August 2025 (UTC)[reply]
See below for more detailed comments on gaming, but in a nutshell accusations of gaming activity requirements is a concern about activity. Thryduulf (talk) 22:29, 5 August 2025 (UTC)[reply]
No, @Thryduulf. It's a concern about trustworthiness. Valereee (talk) 17:26, 6 August 2025 (UTC)[reply]
Please see my reply to you below to keep this all in one place. Thryduulf (talk) 18:44, 6 August 2025 (UTC)[reply]
Doing this would require signatures to have explanations, which is a fundamental change to RECALL that would arguably turn it into a mini-RFA and create incentives to argue the "primary" reason behind every single signature. I don't think such a change will pass.
I think it would be better to pass something like "The opening signature of a recall petition must present an argument that is not solely grounded in the activity level of the administrator." This would require the petition to start with a substantive, non-activity related concern while not imposing a burden on future signers.
Looking at the past three recalls, all had signatures that would meet this criteria, so I don't think this would be particularly burdensome. Obviously Levivich's unfortunately late comment in Night Gyr's [3] and HouseBlaster's opening signature for Gimmetrow would qualify, but I think even Extraordinary Writ's comment for Master Jay [4] would suffice. -- Patar knight - chat/contributions 19:12, 1 August 2025 (UTC)[reply]
Is there any more feedback on this. We currently have Thryduulf's draft and Patar knight's. We could agree on a single option or we could present a multi-option RfC with both options and option C being "no change". Firefangledfeathers (talk / contribs) 12:58, 5 August 2025 (UTC)[reply]
I believe it should never be "can be removed by any extended confirmed editor". That allows an incredible amount of strife in RECALL that we are not equipped for. If it needs to be a provision, it must either be only by uninvolved administrators or something stronger.
Additionally, the current wording from Thryduulf does not specify whether it enforces "every signature" to have a reasoning, or just the initial signature, or something else. It should be explicit in either case, especially if there's a new "Every signature on a RECALL petition must be accompanied with reasoning" added to the process. Soni (talk) 13:07, 5 August 2025 (UTC)[reply]
Thryduulf, some feedback on your draft opener. Firefangledfeathers (talk / contribs) 13:13, 5 August 2025 (UTC)[reply]
I didn't intend my suggestion to be seen as requiring all signatures to be accompanied with a reasoning, just that the opening signature must not be based (in whole or in part) on activity levels and that all subsequent signatures that do give a rationale must give one that is not based (in whole or in part) on activity levels. That said I would happily support a requirement that either all signatures must be accomplished by a rationale, or a requirement that none of them are with the latter accompanied by an explicit note (instruction?) that by signing the petition you are endorsing the opener's concerns and agree that desysopping the admin would an appropriate and proportionate response to those concerns.
I also firmly disagree with @Aquillion below that alleged gaming of activity levels is a suitable use of recall: someone either meets the minimum activity levels or they do not. If they do meet the minimum activity levels, regardless of their manner of doing so, then they should not be subject to recall based on their activity levels. If you think someone is gaming the activity requirements then demonstrate some way in which their actions are actually (not theoretically) harming the project and recall them over that. If you cannot demonstrate that an administrator is actually harming the project in some concrete manner then recall is not appropriate. Thryduulf (talk) 14:43, 5 August 2025 (UTC)[reply]
I would hard recommend you also more explicitly make the distinction between "Allowed" and "Disallowed" reasonings in your RFC. How you see GAMING is clearly not how everyone else does, therefore there will be a lot of problems using the current wording as is. If you intend for the proposal to imply "No proposal should be started with INACTIVITY as the only reason. GAMING does not apply to INACTIVITY as long as the procedural pre-requisites are met." then you should say the second line as well in that proposal. Soni (talk) 16:11, 5 August 2025 (UTC)[reply]
That's fair (although I didn't intend my wording above to be final). I don't see how one can logically regard "gaming the activity requirements" being about something other than activity, but people do. Thryduulf (talk) 22:30, 5 August 2025 (UTC)[reply]
As a second draft, how about:

Recall may not used for concerns regarding inactivity, this includes allegations related to gaming inactivity

  • Petitions started with a rationale based, in whole or in part, on inactivity (including gaming inactivity) may be speedily closed by any uninvolved administrator.
  • A new petition to recall the same editor may not be made within 7 days of a speedily-closed petition.
  • Signatures added with rationales based on inactivity (including gaming inactivity) are not permitted and may be struck by any extended confirmed editor.
  • Signatures added without rationales are permitted. These are taken as fully endorsing all parts of the rationale provided by the editor who started the petition.
The last sentence of the final bullet (at least) needs wordsmithing and may be better as a stand-alone question. The second bullet is new, the intent is to prevent a knee-jerk renomination with a spurious rationale while the temperature might remain high, but allowing for genuine concerns to be addressed without too much delay (if matters cannot wait 7 days then recall is the wrong process, regardless of what happens with this proposal - it is an emergency matter that arbcom need to be made aware of so they can take action if required). Thryduulf (talk) 23:02, 5 August 2025 (UTC)[reply]
I 100% disagree that concerns about gaming = concerns about inactivity. Concerns about willingness to game are concerns about trustworthiness. Valereee (talk) 17:26, 6 August 2025 (UTC)[reply]
I couldn't disagree more. I can understand how, in some situations, an editor saying "I'm going to become active again" and then not subsequently becoming active might be relevant to trustworthiness, but that is not gaming. An editor meeting the minimum standards in a way some editors disapprove of is not relevant at all to whether that editor is or is not trustworthy, it is a matter of their activity levels. If you do not trust an editor, then you need (per AGF, aspersions, etc) to be able to identify some particular reason why you do not trust them and that reason needs to be relevant to trust. Meeting or not meeting the minimum activity standards is not a matter of trust. Thryduulf (talk) 18:38, 6 August 2025 (UTC)[reply]
I get that you aren't seeing this from my point of view. I don't know how to emphasize more clearly: the lack of trust is not about meeting inactivity standards.
The lack of trust is about gaming to get what you want and in some cases lying -- or at minimum doing the opposite of what you say you'll do and never bothering to explain, even when questioned -- to get what you want, which makes me think the person will do other underhanded things to get what they want, which makes me think I don't trust the person with the tools.
I really hate to talk specifics here. It feels mean. But what I saw, with the petition I brought, was an editor who had done just enough to keep the tools. Then the requirements changed, and oops, desysop for inactivity. Request for resysop. Then again just enough to keep the tools. Then the requirements changed, and oops, desysop for inactivity. Then request for resysop saying they were becoming active again. No evidence of becoming active again, no explanation for not becoming active again followed. On their user page, they refused to discuss further. This is not someone I trust to use the tools. I do not effing care that they're inactive. I care that they don't appear to care whether we trust them or not. Valereee (talk) 00:03, 7 August 2025 (UTC)[reply]
So, your problem is that their activity levels do not live up to your personal standards, despite meeting the minimum requirements and despite satisfying the 'crats - who are the people we have explicitly empowered to make decisions about someone's return to activity. Please can you articulate what harm they are actually causing to the encyclopaedia. Note I'm looking for evidence of harm, not of things they might theoretically do or not do in the future. Thryduulf (talk) 00:44, 7 August 2025 (UTC)[reply]
No. My problem is they're gaming to get what they want. My problem is they are willing to be duplicitous to keep their tools. My problem is that someone willing to do that is not IMO trustworthy. They've done something underhanded to get what they want. We can all see this. IMO allowing an admin who has shown they're willing to do this to retain the tools already causes harm. Thry, I get it that you don't agree with me here. I respect it. Can you please respect my opinion? Valereee (talk) 22:05, 8 August 2025 (UTC)[reply]
Re: Please can you articulate what harm they are actually causing to the encyclopaedia. Sure. Allowing admins to game harms the trust we expect/hope non-admin editors have for admins. We need non-admins to trust admins. If an admin has proved themself untrustworthy, IMO we admins should support desysopping. If an admin games, IMO they've thrown their trustworthiness into contention, and it's not unreasonable to ask for RRfA. Valereee (talk) 22:11, 8 August 2025 (UTC)[reply]
@Valereee, what's the difference between "complying with the written rules" and "gaming the written rules"? Compare:
  • Alice is required to make 1 edit every year + 100 edits every five years to avoid desysopping under INACTIVITY. She does exactly this, and we say she complies with the rules.
  • Bob is also required to make 1 edit every year + 100 edits every five years to avoid desysopping under INACTIVITY. He does exactly this, and we say he is gaming the system.
How do you differentiate between these two admins? What makes one of them an untrustworthy rules gamer, and the other one a perfectly fine admin who meets all the ordinary requirements? WhatamIdoing (talk) 19:55, 23 August 2025 (UTC)[reply]
WhatamIdoing, Alice makes an edit or two a month and every once in a while uses one of her tools. She never even gets an alert. Not gaming.
Bob makes zero edits for a year, gets an alert, and makes just enough edits to keep from being desysopped. Meh. Yes, it's certainly gamey, but meh. Bob may not even realize what he's doing looks like gaming or be aware others may see it that way. I may roll my eyes at Bob's behavior, but I haven't necessarily lost trust.
Carl is on Bob's plan. But one year Carl misses the alert, gets desysopped, comes into BN, says he's back to active editing, gets resysopped, and immediately stops editing completely except for just enough edits in response to each notice. Gaming plus lying about it is really the point at which I've lost trust. Valereee (talk) 17:30, 24 August 2025 (UTC)[reply]
Personally, I would like to avoid giving B and C incentive not to say anything about their plans in future, lest it be interpreted to be insincere later on. The reality is that many English Wikipedia volunteers are overly optimistic about their future time allocation to Wikipedia tasks. I'm OK with someone saying they aren't sufficiently convinced that C's predictions for their future plans are sufficiently accurate based on previous history. I don't think, though, we should attribute this to insincerity absent additional evidence. isaacl (talk) 18:21, 24 August 2025 (UTC)[reply]
Valeree, in my story, Alice and Bob are doing "exactly" the same thing.
I would also not want to judge Carl as being "lying". People can sincerely overestimate their ability to engage, or forget the irritations that caused them to disengage. "Come back when you've made x edits" might be a perfectly reasonable response from the buros to inactivity re-sysopping requests. (Yes, our policy is that re-sysopping is free on demand within ~12 months of an inactivity de-sysopping, assuming you took an actual admin action in the previous 60 months, but it's also our policy that no buro can be forced to sysop someone if they think it's a bad idea, and if they were all to decline to click the buttons for a given admin, then that's the end of that.)
It sounds like one source of irritation is perceived motive: "I was busy with real life, and I didn't realize that it had been so long since my last edit, so when I got an e-mail message about the 11-month alert, I made one edit" is "gaming". But "Having the bit gives me extra status online, and maybe someday I'll want to be active again, so I've secretly put a reminder on my private calendar so that I'll make at least one edit every 10 months, shortly before the alerts go out" – that's "not gaming". WhatamIdoing (talk) 19:55, 24 August 2025 (UTC)[reply]
I agree with Valereee that being concerned that someone is circumventing the intent of Wikipedia guidance and norms on engagement with the community is a valid reason to lose trust in an editor to hold administrative privileges. While personally I do not feel that simply meeting the minimum activity standard is a circumvention, absent other factors, I appreciate there are community members who feel that way. I'd rather there be a request for comments discussion directly on this question, rather than implicitly asking the question by proposing a restriction to the recall process. isaacl (talk) 22:23, 6 August 2025 (UTC)[reply]
@Patar knight: any thoughts on Thryd's second draft (above), and on FFF's question above as to whether we should work on a single-option RFC, or whether your suggestion (something like "The opening signature of a recall petition must present an argument that is not solely grounded in the activity level of the administrator.") should be run alongside Thryd's in a multi-option RFC, or something else altogether? (I assume no one else has any options to propose for a WP:RECALL-and-WP:INACTVITY RFC, but if someone does, I think now is the time to propose it.) Levivich (talk) 18:48, 6 August 2025 (UTC)[reply]
Personally, I don't like bundling the question of whether a plain signature should be interpreted as having the same rationale as the person who started the petition. I feel it has a broader effect beyond the scope of the introductory paragraph about inactivity, and thus should be considered separately. (I also think it's unduly constraining, compelling anyone who has different concerns to express them under certain circumstances, but that's something to cover in an actual request for comments discussion.) isaacl (talk) 21:52, 6 August 2025 (UTC)[reply]
Thryduulf, based solely on procedural concerns—not my opinion on the merits of your proposals—I think the RfC will be more successful if we drop the fourth bullet point. The first three are strongly thematically connected, but the fourth would have much wider consequences. If we're just considering recalls based primarily on inactivity, we would get a speedy close based on your proposal anyway. The fourth bullet point would never really get a chance to kick in.
All that said, I'd be happy to get an RfC going with your draft as is, if that's what it takes. I'm trying to balance patience against the diminishing returns of continued discussion, and I think we're getting close to the limit. It would be helpful to get feedback from Patar knight (hope you don't mind the second ping on this), Kusma, and Tazerdadog, all of whom have (loosely speaking) endorsed raising the question of recall and inactivity. Firefangledfeathers (talk / contribs) 12:31, 7 August 2025 (UTC)[reply]
I think that there should be 2 thresholds for admin activity. We have the first one, which is a threshold below which you are going to have the tools removed, but does not imply you're sufficiently active just because you meet it. The missing threshold is a higher one where if you meet it, you are active enough for all practical purposes, and anyone going after you for inactivity is out of line. Edit warring has these 2 thresholds well defined. The 3 revert rule is the threshold where if you fall short of it, you're almost certainly edit warring. BRD is the threshold where if your conduct is at that standard you have nothing to worry about from an edit warring perspective. In the context of recall, I think that there should be a "fuzzy zone" just above the minimum requirement to avoid an automatic desysop, and a recall based on gaming that threshold is appropriate. There should, however, be a higher activity standard above which any recall petition that cites inactivity is not entertained. Tazerdadog (talk) 14:54, 7 August 2025 (UTC)[reply]
Say the "higher" standard is 100 logged admin actions per month. If someone protects 150 user subpages with an expiry of one month, repeating each month, that's clearly gaming but is still meeting the higher threshold. So then you try to get more specific with just what counts. But will you really be able to get to an https://xkcd.com/810/ style requirement? I doubt it (and check the title text on that comic too). Anomie⚔ 17:11, 7 August 2025 (UTC)[reply]
This is an interesting idea, though I'm not sure if it could fit into an RFC that is already set to discuss potentially raising inactivity levels, creating new admin activity requirements, and imposing inactivity restrictions on recall. I would probably save this for a second cycle. If implemented, I think for simplicity's sake, the higher threshold should just be meeting whatever the inactivity thresholds are for 5 years in a single year. -- Patar knight - chat/contributions 22:55, 7 August 2025 (UTC)[reply]
@Firefangledfeathers if we're droppuing the 4th bullet (which I'm OK with) then I think the third needs to have an addition sentence saying something like "this does not affect the admissibility of signatures left without a comment" (but much better phrased than that). That way it makes things explicit so we don't cause the issues someone identified with the first draft, but also it allows for changes to the admissibility of such signatures in the future without needing to change this at the same time. Thryduulf (talk) 22:03, 7 August 2025 (UTC)[reply]
@Thryduulf, for phrasing, how about "Signatures added with rationales based on inactivity (including gaming inactivity) are not permitted and may be struck by any extended confirmed editor. Signatures without reasoning are still permitted."? Firefangledfeathers (talk / contribs) 14:04, 11 August 2025 (UTC)[reply]
That's fine as long as we note that it will need to changed should signatures without reasoning be prohibited or restricted in the future (not part of this proposal, but I recall it has been mentioned in some of the other discussions about changes to RECALL), which I was going for a "this doesn't change" rather than "are permitted" so we don't have to open up any more fraught discussions of inactivity in an unrelated future proposal regarding signatures without rationales. If you think that's not a big deal, then we can go with the simpler option of just saying "still permitted" here. Thryduulf (talk) 15:58, 11 August 2025 (UTC)[reply]
I do think it's not a big deal. Assuming there's a future RfC on sigs without rationales, I don't imagine the presence, absence, or specifics of this proposal (if enacted) will have much of an effect. Firefangledfeathers (talk / contribs) 16:00, 11 August 2025 (UTC)[reply]
I don't think a proposal barring any consideration of inactivity levels by petitioners would pass and wouldn't personally support it. History has shown that activity levels is a valid factor in determining if an admin is WP:NETPOSITIVE or not. Only requiring a non-inactivity basis for the initial petitioner would also largely avoid the issue of policing comments, since RECALL is a petition and it seems very unlikely that any signature would entirely dissent on the non-activity issues of the petition.
I'm not convinced that a 7-day period is required as the inactivity-focused recalls haven't really been problematic or heated is required. Having a clearly defined group who can do the clerking on invalid petitions (or comments) seems fine to spell out. Maybe in terms of structure, something like a ranked ballot of three choices:
  1. Option 1 barring all discussion of inactivity by petitioners
  2. Option 2 only requiring a the initial petitioner to include a non-inactivity reason
  3. No change (everything allowed)
If there's enough support for classifying gaming inactivity as a non-inactivity reason, then perhaps there could be a separate question to clarify the definition of "gaming" such as:
  1. If 1 or 2 passes, should a well-articulated WP:GAMING argument (i.e. with reference to the frequency, utility, and complexity of edits; the level of engagement with the community; as well as past inactivity and promises) be allowed?
-- Patar knight - chat/contributions 22:48, 7 August 2025 (UTC)[reply]
Thryduulf, thoughts on this suggested approach. We're stuck for the moment because we have two proposed RfC approaches and nobody seems interested in weighing in on which to launch. PK has opposed your proposal, but maybe you're fine with his? Firefangledfeathers (talk / contribs) 14:30, 25 August 2025 (UTC)[reply]
Sorry for the late reply, I've been away for a few days. I'm not going to be able to break the impasse with this comment though as Patar's options are too light on detail and miss the important points about gaming. Basically I think my proposal needs workshopping not replacing wholesale. Thryduulf (talk) 21:29, 28 August 2025 (UTC)[reply]
  • As I pointed out above, though, the recalls focused on inactivity also accused the administrators in question of WP:GAMING the existing inactivity requirements. I'm of the opinion that gaming is very different than just being inactive - an administrator who is intentionally gaming the activity requirements is abusing policy in a way that is, at least, clearly valid basis for a recall. Any restriction on recalls or petitions for inactivity would IMHO need to have a clause that it doesn't apply to accusations that an admin is gaming the activity requirements; such concerns are clear WP:ADMINCOND violations. (And since, so far, all the concerns about inactivity have focused on gaming, I don't think this change is necessary at all - this isn't about editors trying to backdoor through tighter activity requirements; it's editors pointing out what they believe to be conduct violations. Gaming the administrator activity requirements is no different than eg. gaming extended-confirmed, and we shouldn't let it pass just because the people in question are administrators.) If you want a fixed version of your proposal I would append This restriction does not apply to any case where an admin has been accused of WP:GAMING the activity requirements, which is a legitimate basis for a recall - but as I said, this makes the entire proposal moot because I suspect "inactivity"-based recall attempts will always actually be about misconduct due to gaming the activity requirements. --Aquillion (talk) 13:31, 5 August 2025 (UTC)[reply]
    I broadly agree with Thryduulf on this, those who want stricter inactivity requirements should do so by getting consensus for a change, not by demonstrating that they have 25 supporters of that stricter criteria. After all there could be hundreds who disagree with the stricter requirements, but that would be irrelevant if there were 25 who didn't have consensus but had found a way to act without consensus. I'm in a slightly different position though in that I think there could be instances where people game the system. For example if someone only met the activity requirement by creating some pages in their userspace and then immediately deleting them U1, then it would be fair to accuse them of gaming the system. But that would involve not just doing the minimum but creating the work that required that minimum. ϢereSpielChequers 19:13, 5 August 2025 (UTC)[reply]
    If someone is doing something like that, and talking to them about it hasn't achieved anything, and an AN(I) discussion has not resulted in them changing their ways and you cannot point to some actual (not theoretical) harm their having the tools is causing (if you can point to that, you can use that harm as the basis for recall) then you can always initiate an arbitration request as it will be a problem the community cannot solve. Thryduulf (talk) 22:36, 5 August 2025 (UTC)[reply]
    This is a repeated strawman, none of the recalls have been about getting 25 signatures for stricter procedural inactivity criteria. If you think there should be stricter procedural inactivity requirements, or perhaps inactivity requirements that are related to something other than procedural rights expiration, then please raise that in the positive case, but it wouldn't really affect any of the recalls that have happened so far. CMD (talk) 02:33, 7 August 2025 (UTC)[reply]
    If hundreds disagree with the stricter requirements, then the RRFA will fail. Hawkeye7 (discuss) 22:29, 7 August 2025 (UTC)[reply]
    Assuming it gets that far given what happened with the only RRfA so far. --Super Goku V (talk) 06:38, 8 August 2025 (UTC)[reply]
  • Sorry, I'm coming to this very late and there's a lot of discussion to read. But as a suggestion for an approach that could be taken in an RfC: when their recall petition was filed, Night Gyr hadn't used the tools at all in 11 years. I doubt that there's a single person who considers that to be an acceptable level of usage. If so, we can approach the question of "How recently should an admin have used the tools?" in the style of a Dutch auction and work down from that figure until we collectively hit upon an answer. What degree of weighting should be applied to that in combination with their use of regular edits can be examined separately.  — Hex • talk 14:21, 10 August 2025 (UTC)[reply]
    I doubt that there's a single person who considers that to be an acceptable level of usage. I don't care how often an admin is using the tools, as long as they use them correctly and appropriately when they are used and their account remains secure then everything else is irrelevant. The activity requirements were intended only to be a proxy for ensuring that someone remains in touch with community norms about correct and appropriate use of tools and for reducing the chances of account compromise, and we need to get back to that rather than all this hand-wringing and moral panic about gaming the system and appropriate activity levels. Thryduulf (talk) 15:44, 10 August 2025 (UTC)[reply]
    I don't care how often an admin is using the tools
    Thanks for the insight.  — Hex • talk 21:57, 10 August 2025 (UTC)[reply]
    That is a good summary. If you have not used tools in 11 years, one you don't need them anymore, and two I would not trust you to use them within current community norms. That is textbook the reason why we even have activity requirements. I would strongly support strengthening requirements to help prevent gaming. It has been the standard understanding until recently when some have tried to argue that it should be as written, instead of the normal intended. We need to bring the current wording in line with the current community understanding. PackMecEng (talk) 17:32, 10 August 2025 (UTC)[reply]
    I see no evidence that anything has changed, other than a small number of vocal users suddenly getting upset that some people are less active than they would personally like. Thryduulf (talk) 17:53, 10 August 2025 (UTC)[reply]
    I saw a lot of pearl clutching that we shouldn't enforce the spirit of the rule vs rule lawyering away from how it's always been treated. PackMecEng (talk) 17:58, 10 August 2025 (UTC)[reply]
    I see no evidence that the spirit of the rule is anything other than what is written, despite all the evidence-free assertions to the contrary by those who want to enforce something other than what gained consensus. Thryduulf (talk) 17:59, 10 August 2025 (UTC)[reply]
    Thryd, I'm insulted and disappointed that after months, and thousands of words of discussion, this is how you summarize the position of me and others. How disrespectful. Levivich (talk) 18:07, 10 August 2025 (UTC)[reply]
    I've read all those thousands (if not more) words of discussion. Despite all of the grand claims made to try and justify enforcing your dislike, I am unconvinced that my summary is inaccurate. Thryduulf (talk) 18:15, 10 August 2025 (UTC)[reply]
    Well, as long as you're unconvinced that your disrespectful summary is inaccurate, then it's fine. Levivich (talk) 21:07, 10 August 2025 (UTC)[reply]
    I don't see how stating my sincerely held belief is at all disrepectful either. Thryduulf (talk) 21:11, 10 August 2025 (UTC)[reply]
    Well, as long as you sincerely believe that I'm part of a vocal minority making grand claims to try and enforce a personal preference I like, how could saying so possibly be disrespectful? Levivich (talk) 21:14, 10 August 2025 (UTC)[reply]
    Good question. Thryduulf (talk) 21:16, 10 August 2025 (UTC)[reply]
    Yea, it’s a gross misinterpretation of our viewpoints. Don’t try to generalize an entire group/viewpoint if you unironically can’t understand where we come from when voicing our concerns. EF5 22:00, 10 August 2025 (UTC)[reply]
    Despite all your protestations to the contrary, literally every explanation for your viewpoints has boiled down to either "I don't like how active this user is" and/or "I don't like the manner in which this user is meeting the activity criteria" (I've explained this in detailed rebuttals to the arguments when they've been made). Unsubstantiated accusations of gaming the activity are a dislike of the manner in which someone is active. It is not a mischaracterisation to summarise your desire to interpret the inactivity policy in a way that allows you to enforce that dislike, despite never having attempted to get consensus for that interpretation, as exactly that. Thryduulf (talk) 22:08, 10 August 2025 (UTC)[reply]
    Thyr, I recommend stepping away from this subthread. Multiple editors, including myself, agree that your comments are a mischaracterisation. You have a right to disagree, just not to badger.
    In the interest of not beating dead horses for the 10th time this discussion, I strongly urge you to step away and let your current comments speak for themselves.
    I have the same request for others as well, we have clearly articulated our takes on GAMING so far, there is no need to argue again and derail the rest of proposal building.
    Apologies for my otherwise spotty activity, I plan to finish my coding of these stats and start the RFC I planned to, sometime in the next couple weeks. Soni (talk) 04:15, 11 August 2025 (UTC)[reply]
    Hi Hex, and welcome. We are considering holding an RfC on increasing the activity requirements, and one option on the table is some requirement for admin actions. Many people feel that consideration of those activity questions was inappropriate while we sort out a related matter: how should recalls based (at least in part) on activity levels be handled. That, rather than tweaking the activity minimum, is the purpose of this section. The discussions above that were more focused on INACTIVITY have gone a bit stale, but I still anticipate we'll revive the discussion at #RFCBEFORE on WP:INACTIVITY eventually. Firefangledfeathers (talk / contribs) 18:05, 10 August 2025 (UTC)[reply]
    Hey, thank you. I've not had a lot of time to be present for policy discussions of late, so hoping I can participate more in future.  — Hex • talk 22:05, 10 August 2025 (UTC)[reply]

Automatic IP block exemption

[edit]

I am thinking about this because I am currently on a family trip and I have found that in the country I am in right now there are all sorts of problems from inability to access Wikimedia Commons (which yes is a separate project) to slow speeds when accessing Wikipedia.

In addition, almost every browser has an in-built or promoted VPN including Microsoft Edge Secure Network, iCloud Private Relay, Mozilla VPN, etc. And there are free VPN providers such as ProtonVPN that are extremely handy on trips.

I am wondering if we can maybe discuss automatic IP block exemption and potential criteria for automatic, indefinite grants. Maybe:

  1. Having a confirmed email address that is not in use on another account;
  2. Account at least one year old;
  3. Account has made at least 10,000 edits;
  4. Not more than 10% of all edits within the last year being reverted;
  5. No history of sockpuppetry, meatpuppetry, or misuse of VPNs for nefarious purposes on Wikipedia or another Wikimedia project (which probably there should be a way to cancel the autopromotion).

Aasim (話す（はなす）) 19:49, 24 July 2025 (UTC)[reply]

The first 2 criteria are completely useless. Apart from that you've probably roughly described one set of criteria that admins should be using to grant temporary IPBE (we often grant IPBE using lesser criteria). An admin should still be looking over the details, like they do for pretty much every other user right. Once you meet the threshold you're automatically good forever? Not a chance. "No history of sockpuppetry", "nefarious purposes", and dodgy logged out editing, are all impossible to detect automatically. These are judgment calls, for which admins and checkusers are paid the big bucks. I also maintain that we should only be granting permissions to people who actually need them. You can define 'need' in various ways, but 'going to use the permission' would definitely fit in there. -- zzuuzz (talk) 20:24, 24 July 2025 (UTC)[reply]
Also, for the case of "I hit a block" - bypassing the block isn't always the right solution. Blocks can be bad, underlying block reasons can change -- as such fixing the block may be the best solution. (That doesn't cover the case of I should be allowed to use any VPN or Proxy I want because I've been around a while but is another factor.) — xaosflux Talk 20:54, 24 July 2025 (UTC)[reply]
I don't see why the current IPBE process isn't good enough (while promoting security against proxy vandals). Aaron Liu (talk) 21:13, 24 July 2025 (UTC)[reply]
It is going to be very difficult to WP:GAME 10,000 edits as rate limits make it all but infeasible save for bot accounts (which are already IP block exempt from all but Tor exit nodes). And those 10,000 edits have to be either 1. while manually IP block exempt or 2. via non-proxies or open proxies that have not yet been blocked. If we are really concerned about gaming we could measure account age from first edit. Self reverts would count towards that 10% limit. The more edits and older the account must be, the less likely we will have serious gaming of existing processes.
We can lower the revert threshold to 5% or 1% if we are concerned about gaming. Or double the requirements to 20,000 and 2 years old, at which point fewer than 10,000 Wikipedians would qualify. The fifth point would be a matter of enforcement.
We could also have procedural revokal based off of inactivity, so that there must be a minimum activity requirement to maintain the automatically granted role.
This is just a brainstorm to try to address a legitimate issue with browser VPNs (which many may be unaware that they have them on, yet alone how to turn them off). Aasim (話す（はなす）) 12:17, 25 July 2025 (UTC)[reply]
The legitimate issue with browser VPNs is already solved by linking to instructions in the proxy block message template, which everyone sees when they encounter this form of block, for how to disable almost all of the popular ones, or how to whitelist Wikipedia. We don't need to make holes in our security features for people who won't read instructions, and for the editors who have a legitimate use case for proxy use, listen to the functionaries here telling you that it is practically no administrative burden at all to review IPBE requests. Automatic IPBE grants are a solution in search of a problem. Ivanvector (Talk/Edits) 15:20, 25 July 2025 (UTC)[reply]
I am also trying to figure out how VPNs are a unique problem to Wikimedia projects. I am not saying that open proxies aren't problematic, I just think the approaches to them might be a little draconian. VPNs have only gotten more popular in the past decade, because they are extremely useful. I also understand security is important but there has got to be a more intelligent way that doesn't require widespread human intervention where bot downtime potentially leaves hundreds of IP addresses that are currently being used for coordinated disruption open (as many other websites that are not MediaWiki wikis do).
A verified email and phone number can make things really hard; with filtering out of VoIP and throw-away email/phone number services it can be very hard to circumvent account bans. But that might also raise privacy concerns.
Another thing websites and forums do for anonymous users is collect email addresses (that again are not from throwaway providers) and require verification codes to protect against abuse. This might work well for temporary accounts as Wikimedia eventually moves to phase out IP addresses entirely for most purposes. Apple and Cloudflare have been trying to introduce private access tokens to try to encourage legitimate users, and maybe MW can recognize private access tokens and allow the user through despite a VPN block (but then the edit would be attributed to the access token).
I do wonder if this could become a major problem in the future if certain browsers make VPNs mandatory, but that is the discussion happening on m:Apple iCloud Private Relay. If we want to kick the can down the road sure but then there might be entire ecosystems unable to edit Wikipedia. IP addresses might always remain useful especially for autoblocks and non-VPN use cases, but for VPNs something more intelligent to identify different users is needed. Aasim (話す（はなす）) 16:21, 25 July 2025 (UTC)[reply]
While I believe the linked expression is very overused, I agree with Ivanvector and the usage here. We should wait for the problem to arise first because the security benefits against sockpuppeting are much higher than the bits of convenience automatic IPBE might provide. If things gets to the point where we should have automated granting, we'd see a far cloggier IPBE request queue. I'd rather not risk having the very rare 10k-edit sock elude us than satisfy the rare active editor who can't wait to get their request approved until we see a mensurable need for this thing.
The additional things you propose in this comment won't add anything as they're reusable. Many sockpupeteers used to be legit editors who would've needed to pass anything required of that account, and nothing stops a sock from being verified with the same phone number. Aaron Liu (talk) 01:56, 27 July 2025 (UTC)[reply]
The idea of a verified phone number on most services is to make it harder to ban evade. Discord already does this; server bans are by username and by IP, but Discord also says that requiring a verified phone number to be granted the role can make evasion very difficult, presumably because we can make it so. Discord does filter out phone numbers that belong to VoIPs and we can do the same thing as well. Aasim (話す（はなす）) 13:33, 28 July 2025 (UTC)[reply]
I don't think automated detection of using the same phone number as another account is a good idea as phone numbers are very much transferable; i.e. one can hand in their phone number back to their carrier, which can give that same phone number to me, which is how I end up confusedly replying "new phone who dis" to my inbox.
So if you want to do that you would have to expose phone numbers to CheckUsers. Which is an even bigger security thing whom I do not see the rare convenience of this proposal eclipsing. Yes, we trust CheckUsers, but still I doubt it's something Wikipedians are comfortable with, especially in places like China where WMF office-actioned a dozen trusted users for possible governmental collusion. Aaron Liu (talk) 16:40, 28 July 2025 (UTC)[reply]
It is also important to remember that the United States is not representative of the whole world, not all phone numbers work the same as they do in the US, and not every editor (let alone every potential editor) has a mobile phone of their own.
In the UK I can eaisly get a working, second-hand phone for less than £5 and PAYG and no-contract sim cards for the same or even lower price. If I spent more than 1 minute looking I could probably get it even cheaper than that. It's not free and there is hassle involved, but the barrier for me to be able to verify with multiple phone numbers is extremely low at the same time the identical restriction places an (almost) insurmountable barrier on some people verifying a single account. Thryduulf (talk) 18:27, 28 July 2025 (UTC)[reply]
I don't see how that changes anything. Is pay-as-you-go supposed to stop you from reselling the sim card to someone else? Aaron Liu (talk) 19:24, 28 July 2025 (UTC)[reply]
No, PAYG it makes it easier to resell the the SIM card as there are no contracts involved. You just buy the SIM card and put credit on it. Thryduulf (talk) 20:12, 28 July 2025 (UTC)[reply]
So that makes the situation I described more common. I don't think you understood, so I'll repeat what I said:
Transferred phone numbers can cause one account to have the same phone number as another, meaning you can't rely on just detecting duplicate phone numbers to find block evasion. And blocked users will just bypass this measure by verifying all their accounts with the same phone number. Unless you give CheckUsers access to phone numbers, which I doubt is a cost the community will accept just for the sole convenience of allowing some editors to access their accounts faster. Aaron Liu (talk) 20:28, 28 July 2025 (UTC)[reply]
I think we're arguing the same thing (against the proposal) but from opposite angles.
Your argument seems to be that accounts legitimately operated by multiple people could have the same phone number, and I don't disagree with that but it isn't directly relevant to my argument. I'm saying that (a) for some people getting a single phone number is a barrier high enough that requiring a phone number to edit would prevent their participation here; and (b) for other people getting multiple phone numbers is such a low barrier that requiring each account to have a unique phone number would prevent almost no barrier to socking (especially if backed by corporate resources).
The proposal only works if there is a 1:1 relationship between person and phone number. You are (I think) arguing against it because a single phone number could relate to multiple people. I'm arguing against it because a single person could easily have multiple phone numbers. Together that means the relationship is actually many:many. Thryduulf (talk) 22:55, 28 July 2025 (UTC)[reply]
Now I'm curious - why would someone want to sell a SIM card second hand? Also aren't eSIMs making traditional SIMs obsolete? It is not like you can't get a phone that has no SIM tray unless you are talking the US model of iPhone. But given that most phone numbers are semi permanent (my phone number has not changed since my teenage years, and my parents' have not changed since they got cell phones in California) blocking by phone number makes it really difficult to evade a block as it would necessarily mean going through the costs of acquiring a second phone number.
If there is a way to identify pay as you go phone numbers we can block those as well and have human review based on the circumstances. Nowhere am I suggesting that we don't eliminate the existing channels for manual grants of IP block exemption. Aasim (話す（はなす）) 21:59, 28 July 2025 (UTC)[reply]
You don't want it anymore—because you're moving somewhere, because you don't like how it looks, or because everyone's blocked you, etc—and you want to get back some of your costs.
eSIMs can be resold too.
I know that manual grants will still coexist. My point is that introducing phone number verification for this is a very bad idea because they touch the private information nerve and far from guarantee uniquely identifying the person behind them. I've also talked about giving CheckUsers phone number access already. Aaron Liu (talk) 22:22, 28 July 2025 (UTC)[reply]
... okay, the instructions are in {{blocked proxy}}, but not in {{blocked p2p proxy}} where they're more relevant. We should fix that. Ivanvector (Talk/Edits) 15:22, 25 July 2025 (UTC)[reply]
I'm not sure what problem this is intended to solve, and how it is in keeping with core security policies. No open proxies has been a global policy since 2006. It is not just an English Wikipedia policy. I do a lot of IP block exemptions (it is probably the largest percentage of my logged admin actions), am probably more liberal with it than most people, and I cannot remember the last time that I granted indefinite IPBE. If people need it, they will likely get it. It is not really a hardship to make their case. I've been working on some guidance for admins deciding whether or not to grant IP Block exemptions, and pretty much the first line is "don't grant it indefinitely". Risker (talk) 22:38, 24 July 2025 (UTC)[reply]
  • I remain convinced that all automatic rights grants are a bad idea, with the exception of autoconfirmed (I have complicated opinions about extendedconfirmed). They invite permission gaming, and yes we absolutely have bad actors dedicated enough to wait out these arbitrary conditions so that they can keep using their open proxies. It really takes no time at all to evaluate an IPBE request, and as Xaosflux said sometimes granting the permission is a less ideal solution than modifying an overly-aggressive block, or one where there is too much collateral. I pretty much grant IPBE to anyone who bothers to ask - it shows they can read instructions. I also never grant it indefinitely, I thought that was already forbidden by policy. Even my own alt doesn't have indefinite IPBE. Ivanvector (Talk/Edits) 12:15, 25 July 2025 (UTC)[reply]
I understand the desire behind this, but I don't think this is warranted. VPNs are security theater and it doesn't really matter if Wikipedia doesn't allow it. Seeing as its been global policy for nearly 20 years (with good reason--would make Checkuser useless) I don't see a strong need to locally reverse it. Its already open to all editors who ask, and its not very hard to ask. Just like with all rights, if you don't need it, then you don't have it. JackFromWisconsin (talk | contribs) 01:31, 27 July 2025 (UTC)[reply]
VPNs are security theater Are you sure? They have their use cases, such as when you want to hide the geolocation of your IP address, when you want to protect yourself / your IP address from legal action, and when you need to bypass geo-restrictions. I'll bet mainland Chinese editors of Wikipedia, for example, would not consider VPNs to be security theater. –Novem Linguae (talk) 11:12, 14 August 2025 (UTC)[reply]
  • I agree with others that this seems unnecessary. The only time it would be useful would be if a long-term, active editor editor is unaware of the proxy policy until the first time they try to edit using a proxy (plausible), and that first proxy edit attempt happens in a context where they are unable to disable the proxy briefly while they request a block exemption (less plausible). So it's a rare situation to begin with, and even in that situation, we only lose a few hours/days/weeks of their editing until they get to a context where they can request an exemption. It just seems like the auto block has large benefits and small costs, so it's unnecessary to change it. -- LWG talk 18:56, 28 July 2025 (UTC)[reply]
    @LWG Or the much more common scenarios of a long-term, active editor needing to edit from a mobile device away from WiFi coverage, only to discover that they subscribe to one of the many mobile operators whose entire IP range is blocked, or they move to an area only serviced by an ISP that is subject to a rangeblock, or they need to edit from a corporate network that run all traffic through filtering software hosted on AWS, Google Cloud, or Azure. --Ahecht (TALK
    PAGE    )     20:05, 28 July 2025 (UTC)[reply]
    Ahecht right, but how often are those edits going to be so important that it's a big deal to take a wiki break for a couple days while you request a block exemption? -- LWG talk 22:12, 28 July 2025 (UTC)[reply]

A Learning Management Platform - The Wiki Walkthrough

[edit]

I am looking forward to developing an educational platform where all the courses are going to be about wikipedia and its sister projects. The courses are going to have structured learning paths, interactive exercises, and community collaboration.

So this is how it works, a user logs onto the platform, enroll in a course, learn ( some courses might have quizzes depending on the instructor ) and earn certificates after completing a course. There is also a forum where learners can ask questions for more info on a specific topic.

I look forward to partnering with expericed wikipedians to create the courses.

This is the link to the prototype the wikiwalkthrough Tiisu Sharif (talk) 14:44, 20 August 2025 (UTC)[reply]

Don't we already have WP:TUTORIAL and WP:TWA? Aaron Liu (talk) 19:32, 20 August 2025 (UTC)[reply]
Why exactly do you feel qualified to be creating instructional materials for Wikipedia editing when you have never edited a Talk page, only edited a Wikipedia-space page to make this announcement, and your article contributions so far have either been riddled with unusable AI content, or else look like this? signed, Rosguill talk 19:52, 20 August 2025 (UTC)[reply]
I'll mention WikiEdu's training modules which anyone can take even without a WikiEdu account. Also, I highly suggest you remove "Wikimedia" from the site description metadata per the Trademark Policy, unless you got permission to use that word. OutsideNormality (talk) 22:04, 20 August 2025 (UTC)[reply]
Note that it's fine to have nominative use without implying WMF endorsement, which the site currently does. Aaron Liu (talk) 22:27, 20 August 2025 (UTC)[reply]
I was talking about the site's meta description (visible in the source code), which currently says Wikimedia Education Platform - Learn to contribute effectively to Wikipedia. OutsideNormality (talk) 00:03, 21 August 2025 (UTC)[reply]
Yeah, I meant "the site currently does imply WMF endorsement". Aaron Liu (talk) 00:17, 21 August 2025 (UTC)[reply]
Hello. Thanks for your feedback
First of all, the platform is designed in such a way that other people can create courses on it. So we are therefore open to collaborating with experienced wikimedians to work on the courses. @Rosguill So i created the courses myself because we are still at the initial stage.
Yes @Aaron Liu, there are other platforms that have tutorials as well however, we building on where the other platforms endend by adding other features. For instance, the platform will provide certificates for individuals who will complete the courses
And lastly, I joined the wiki space last year and therefore has little knowledge and experience. I am still learning and exploring so any guidance or mentorship is welcomed. Here in Ghana, I attend workshops at most once a month ( not every month though ) and some online workshops as well.
However, there are times that you need some answers but there is no one to ask and when you go on youtube, most of the content are over a year old. This is the problem myself and other members of my community are facing hence the reason why I am developing this platform. Tiisu Sharif (talk) 01:20, 21 August 2025 (UTC)[reply]
I don't see your value proposition for certificates.
You're welcome to find answers at the WP:Teahouse, the WP:Help desk, or any of our Help: and Wikipedia: pages! Aaron Liu (talk) 03:23, 21 August 2025 (UTC)[reply]

However, there are times that you need some answers but there is no one to ask

But there are multiple places on Wikipedia where new editors can get help? Why exactly is it a good idea for new editors to go to a random website off-Wiki?
This is a tremendously bad idea and feels very scammy. qcne (talk) 09:53, 21 August 2025 (UTC)[reply]
From the website Expert Mentorship Learn from experienced Wikipedia editors and administrators who provide guidance, feedback, and support throughout your contribution journey. I'm going to call bullshit on that. Who are these 'experienced Wikipedia editors and administrators'? If this isn't a scam, it is a parasitic leeching off of potential contributors, for no useful purpose. Note also that the site has neither a privacy policy, nor any terms of service, and accordingly it would be very ill-advised for anyone to sign up. AndyTheGrump (talk) 10:51, 21 August 2025 (UTC)[reply]
In addition to the problems other people have mentioned above, it appears that the "course content" on that website was generated by a Large Language Model like ChatGPT. Given that you have a track record of using LLMs inappropriately to edit Wikipedia, there's no way we are going to trust you to use LLMs to teach other people how to edit Wikipedia. Your enthusiasm for increasing accessibility for new editors is good, but it really doesn't seem like you have the necessary skills to to build an app like this or the necessary Wikipedia experience to develop useful content for new editors. I would suggest continuing to grow your app developer skills on some other non-wikipedia project, and continuing to learn about Wikipedia policies and build a track record of useful, non-LLM contributions. To get to the level of experience where a project like this would be feasible would probably going to take years, so I would suggest finding something else to focus on for now. -- LWG talk 16:23, 21 August 2025 (UTC)[reply]
I have heard your feedbacks and I will work on them. THanks Tiisu Sharif (talk) 01:52, 22 August 2025 (UTC)[reply]
I believe that something similar was done ~10 years ago at the French Wikipedia – a type of Massive open online course. WhatamIdoing (talk) 20:07, 23 August 2025 (UTC)[reply]
Hello Tiisu, I would really appreciate it if you had an "about us" section to clarify who exactly is running the site. Furthermore, there are a host of unknowns that will need to be addressed in order for any sort of collaboration to feasible. Does the WMF know about this? Why are we hosting this off Wikipedia? Is this a commercial endeavour?
Teaching new Wikipedians is an admirable goal, but I'm afraid that this approach does not seem to be wise. I would recommend you check out the Wikiversity entry for getting started on editing Wikipedia. Bremps... 16:37, 29 August 2025 (UTC)[reply]
Thank you very much for your feedback I will work on the "about us" session as well as other concerns raised. WMF is not aware of this. It is a problem i have faced and observed in my community so I decided to try and build something to solve that problem. Hosting it on wikipedia willl be great and I think that is where the problem is. Most of my community memebers come to wikipedia only to edit. If not until I started building this platform, I did not know wikipedia is this huge with a lot of resouces, articles and a lot to explore and there are only a few poeple who explore wikipedia to this extent. Again, all the courses shall be free. The courses are not going to be about only wikipedia but wikidata, wikicommons and other sister projects as well. Tiisu Sharif (talk) 08:53, 30 August 2025 (UTC)[reply]

This week's article for improvement

[edit]

I have an idea for a new section for the mainspace of Wikipedia.

Wikipedia:Articles for improvement is an obscure initiative that seeks to highlight subpar articles with the aim of improving them. The project is currently nearly dormant.

I propose reviving the project on the main page, as a template (like TFA or DYK). The idea was previously discussed here with a rough consensus in favor, with dissents that pointed out issues such as vandalism or ambiguity in the proposal. I created a (nonfunctional) mockup here.

I would appreciate a) discussion about the proposal, so that we may iron out any issues or ambiguity, and b) someone technically proficient at Wikipedia helping me create a functional mockup.

Many thanks in advance! Bremps... 20:31, 25 August 2025 (UTC)[reply]

Yes. We'll get a flood of incompetent edits, but (1) most of them will be from well-meaning people and (2) it will likely attract new people onto the project. I've long said the Main Page needs much more reader engagement on it, and that the WMF should advertise "learn to edit" rather than "give us your money". This is a step in the right direction. Cremastra (talk · contribs) 20:58, 25 August 2025 (UTC)[reply]
For historical context: when the articles for improvement section was on the main page in the past, there wasn't a flood of edits. Edits were primarily from the people already involved with the initiative. isaacl (talk) 22:22, 25 August 2025 (UTC)[reply]
What format did it appear on in the main page? There may need to specifically be a note that YOU, the READER, can add sources and edit the text. CMD (talk) 02:52, 26 August 2025 (UTC)[reply]
For reference, this is how the main page appeared on May 4, 2013. isaacl (talk) 16:25, 26 August 2025 (UTC)[reply]
Thanks. There is definitely scope to test different formats. CMD (talk) 11:55, 27 August 2025 (UTC)[reply]
I notice that the section was comparatively very small, and easy to overlook for casual readers not familiar with Wikipedia, which is the opposite of what we want to achieve. By making it larger and adding an encouraging editing tip, it could be more effective. Chaotic Enby (talk · contribs) 13:44, 27 August 2025 (UTC)[reply]
Indeed. It also provided no explanation of what exactly was meant to be done or how to edit. Cremastra (talk · contribs) 14:14, 27 August 2025 (UTC)[reply]
This is why the pairing I'm having in mind could have good synergy – teach users one specific aspect of editing (adding references, removing promotional wording, writing out-of-universe, ...), and give them the chance to apply it on some relevant articles for improvement. Chaotic Enby (talk · contribs) 14:21, 27 August 2025 (UTC)[reply]
As a (very) frequent reader, but an under-experienced, sporadic editor of Wikipedia, I'd like to offer my opinions on this subject, as I often find myself wanting to contribute in simple ways, but not sure where to look.
For one thing, I rarely find myself on the main page anyway. Anytime I want to simply look something up here, I type "wq" (search keyword) then, "thing I want to look up" into the address bar in Firefox". And while I can see the benefit of advertising on the main page to attract new people, is that really the issue? It already says, right at the top: "Welcome to Wikipedia, the free encyclopedia that anyone can edit." Is there really anyone who has heard of Wikipedia, and is NOT aware that they can open an account, and start editing? "Oh anyone can just write whatever they want on there!" is what my own beloved mother, and too many other folks, say to disparage the credibility of information on Wikipedia. So I think it's not a matter of making that aspect more visible, though a reminder probably won't hurt.
The problem I see, at least for people like myself, is the difficulty I find in just navigating the massive labyrinth of behind the scenes stuff, and easily finding stuff to do, as an editor. Um.. okay, I feel kinda stupid now, because I kinda just discovered the "Main Menu" button in the top left, ah geez.. I mean okay that should have been super obvious, but, for some reason I've always focused so much more on the buttons on the top right okay? that HUGE distracting globe icon just goes to the main page, so I guess I've kinda been ignoring the smaller menu button next to it, which I didn't even realize has direct links to some of the stuff I've been struggling to find...
Okay but as for AFI stuff specifically, it would be nice if I just had an obvious button for that, showing a list of AFI's, ranked by parameters that I was able to customize. or maybe an option in that drop-down menu at the top right? possibly between Watchlist and Contributions. Or perhaps some sort of gadget, enabled by default in the preferences, and customizable, that would notify me of things in need of doing. And perhaps an ability to quickly, and easily flag articles for an AFI list.
I guess what I'm really trying say here, is that instead of putting AFI on the Main Page, it should be somehow integrated directly into the registered users' GUI, tailored by default to simple editing tasks for new users, but customizable to fit the needs of more advanced editors. Some thing that would generate a list of editing tasks that I could just go straight to work on. OwlParty (talk) 10:15, 7 September 2025 (UTC)[reply]
I think what you describe is already very close to another feature we currently have! It's at Special:Homepage (not the same as the main page!), and provides users with a "dashboard" of articles they can improve, among other things. You can take a look at it and tell us whether that's what you had in mind. Chaotic Enby (talk · contribs) 13:05, 7 September 2025 (UTC)[reply]
I think input from the participants in the articles for improvement initiative is essential. I don't see any discussion of this at Wikipedia talk:Articles for improvement, but perhaps I overlooked it? isaacl (talk) 22:20, 25 August 2025 (UTC)[reply]
Good point. I just sent out a notice here. Bremps... 23:14, 25 August 2025 (UTC)[reply]
Hmmm... Right now, the sections on the main page are purely reader-serving, and don't intend to attract editors. I think encouraging more editing is a good thing, but should be done carefully, as to not obstruct the encyclopedia's purpose.
I'm not sure if AFI is a good idea for new editors. Usually the articles need prose writing and research, and have tags and large structural issues. Something small like copyediting or adding short descriptions for example are easier places to start. I feel as this idea will likely attract large amounts of editors, and dissuade most of them, when they find that their edits have been reverted for OR, RS, etc. — PerfectSoundWhatever (t; c) 23:28, 25 August 2025 (UTC)[reply]
I'd support some sort of ongoing funnel of readers and new editors to WP:TASK. signed, Rosguill talk 16:28, 26 August 2025 (UTC)[reply]
I suggest joining the discussions at Wikipedia talk:Growth Team features about suggested tasks on each user's home page. (The username link at the top of the page links to the user's home page automatically for new users; users with older accounts can enable direct access to their home page at Preferences → User profile → Newcomer editor features → Tick Display newcomer homepage.) isaacl (talk) 17:00, 26 August 2025 (UTC)[reply]
I think it's reasonable to have these concerns. I have them myself. If the trial run devolves into anarchy or stagnation we may have to pull the experiment. But I think we should still err on innovation given that we're trying to keep Wikipedia dynamic to keep up with the times.
From a cost-benefit standpoint, the worst that can happen is that a page is no better off than when it was showcase. The best that can happen is a large recruitment drive for an encyclopedia that's been taken over by ChatGPT in traffic. Bremps... 02:35, 27 August 2025 (UTC)[reply]
Definitely agree – now is the time to innovate and try new things, and I don't see any negative effects on our reputation that "here are articles you can improve!" could have (compared to, say, the Simple Summaries trial). If anything, even if it doesn't work out, it still showcases Wikipedia as more dynamic and inviting for readers/potential editors. Chaotic Enby (talk · contribs) 11:41, 27 August 2025 (UTC)[reply]
I think this is a good idea. This is a part of the Wikipedia community that deserves a bit more love, honestly.Danubeball (talk) 02:38, 26 August 2025 (UTC)[reply]
I agree with the above, that the project's effectiveness could be improved. Sahaib (talk) 06:44, 26 August 2025 (UTC)[reply]
I would definitely agree – one other thing I had in mind was "this week's editing tip", and both could maybe go hand in hand? Learning how to deal with a specific type of issue, and having an article to apply your knowledge on. Chaotic Enby (talk · contribs) 15:14, 26 August 2025 (UTC)[reply]
I like the idea. Bremps... 02:36, 27 August 2025 (UTC)[reply]
Note: I have requested technical help at Wikipedia:Village_pump_(technical)#Requesting_help_for_creating_mockup_of_proposal. Bremps... 16:30, 29 August 2025 (UTC)[reply]
I'm concerned about the lack of comment from those who currently support the articles for improvement initiative. Unless there is buy-in, or a new influx of volunteers to help support the new process (in collaboration with the existing process), I'm reluctant to direct a group of volunteers that they must now spend time supporting a main page section. isaacl (talk) 16:41, 29 August 2025 (UTC)[reply]
The only WikiProject members that seem active are Danubeball, Sahaib, and PerfectSound who've already commented above as well as @SVcode and @Clovermoss. Aaron Liu (talk) 18:30, 29 August 2025 (UTC)[reply]
My interest in the wikiproject has come and gone over the years. It's definitely an interesting idea but actually getting everyone interested in a specific article doesn't always work. If there's interest in spotlighting articles that need some work on the main page, maybe implementing something like Wikipedia:Community portal would be better? I was drawn to that when I was a newbie. Clovermoss🍀 (talk) 18:51, 29 August 2025 (UTC)[reply]
As part of "buy-in", I think there should be some discussion among these volunteers about what needs to be done on a regular basis to keep a main page section going and the queue full, which was a problem last time. (Although some agreement on success criteria might be nice, in practice that'll just be rehashed in future anyway, should someone propose removing the section.) isaacl (talk) 21:29, 29 August 2025 (UTC)[reply]
A queue implies options, which is good. I think it'd be very chaotic to point at any article in particular and then encourage the thousands of people looking at the main page to improve it, especially without guidance. Clovermoss🍀 (talk) 06:57, 30 August 2025 (UTC)[reply]
By "queue", I was referring to a queue of what will appear on the main page in order to ensure that it is updated in a timely manner, which did not always happen last time and resulted in the section being pulled. However, note the initiative was called "Wikipedia:Today's articles for improvement" because it did shift from initially suggesting one article into suggesting several, as can be seen in the example I previously linked from 2013. However, this change was seen as diffusing focus, which I believe is why there is only one suggested article per week in the current format. isaacl (talk) 17:12, 30 August 2025 (UTC)[reply]
I'd expect the article to receive more watchers/RC patrollers as well. Aaron Liu (talk) 23:03, 30 August 2025 (UTC)[reply]
Who here would be willing to participate in the queue process? I would be, see my comment below. Bremps... 17:19, 1 September 2025 (UTC)[reply]
Regarding buy-in, I would be an avid participant in the process. In terms of the workload, it would be less than, say, WP:DYK or WP:ITN, as we are promoting articles that are by definition not good. The key issue in my opinion is article selection, which will be more contentious because the template is going on the main page. Bremps... 16:46, 1 September 2025 (UTC)[reply]

Establishing a precedent

[edit]

I suggest a new policy be enacted and yes, not sure about how to go about that. On the 2025 Midtown Manhattan Shooting talk page there is a RFC in progress. There are very few editors weighing in with their opinions. To me some of the really wrong or faulty opinions being expressed go as follows: This is one incident and it shouldn't be compared to others. To me that absolutely is strange. Who decided that all tragedies are not similar? Why should they not be treated the same? As for a policy, here is my proposal. I have no difficulty in naming perpetrators, I do stringently feel their names should be sparingly used (they can be referenced by generic descriptions). I don't believe their names should ever be in bold print or linked (as in re-directs). Why can't that be the official policy or some guidelines be drawn up saying so? Are there other places to suggest this besides the village pump? Perhaps on the bureaucrats noticeboard? Other secondary topics which go along with the above would be the consideration of those affected (the perpetrator's family in addition to both victims' and survivors' relatives. That's not much to ask. Dignity and looking at how they feel. It's not censoring to takes these matters and remedy what to me is a puzzle. Why wasn't this addressed before? Lastly some or at least one user brought up confusing people who are searching for certain names (people). That makes no sense to me. Are we really dumbing down say to the LCD? It is not difficult for anyone to find almost anything they would want to look up. As Nike would say, Let's do it. Efficacity (talk) 08:12, 26 August 2025 (UTC)[reply]

I don't think the bureaucrat's noticeboard is a relevant place (bureaucrats don't make policy). We rarely rely on precedent for these types of decisions, and a wider-ranging policy could be helpful, although sources might treat different events in different ways and we should try to follow this. Nevertheless, you've come to the right place here to suggest such a policy/guideline proposal. Other editors can give feedback and work with you on how to word it more precisely, and, once you have something you feel is ready, you can then submit it to Wikipedia:Village pump (policy) with the {{rfc}} template. Chaotic Enby (talk · contribs) 15:17, 26 August 2025 (UTC)[reply]
A starting point: you talked about different ways, do you have specifics? For example how many possibilities? Efficacity (talk) 16:43, 26 August 2025 (UTC)[reply]
The RfC noted above is this one: Talk:2025 Midtown Manhattan shooting#Bolding. As for "some of the really wrong or faulty opinions being expressed go as follows: This is one incident and it shouldn't be compared to others", I don't think anyone there said that, nor was that the idea being conveyed. Rather, the point was that an RfC at a single article does not affect site-wide manual of style or guidelines. That kind of broad change requires a broad community discussion such as you're bringing here. ButlerBlog (talk) 17:25, 26 August 2025 (UTC)[reply]
Besides the village pumps, policy changes are usually proposed on the talk page of the policy being changed. The policy for bolding is MOS:BOLDREDIRECT. Aaron Liu (talk) 20:38, 26 August 2025 (UTC)[reply]
Alright, Aaron Liu. Efficacity (talk) 21:31, 26 August 2025 (UTC)[reply]
Any such discussion would normally happen at Wikipedia talk:Manual of Style/Text formatting. It's probably best to start it as an ordinary discussion, so you can talk to an experienced editor or two about possible wording changes.
You should probably also read pages such as Wikipedia:Casualty lists and Wikipedia:Victim lists, and perhaps WP:NVICTIM (the standard rules for whether victims and perpetrators get separate articles, or are only mentioned in the event-focused article). WhatamIdoing (talk) 00:18, 27 August 2025 (UTC)[reply]
Will you help with that? Efficacity (talk) 06:50, 27 August 2025 (UTC)[reply]
I think you should look for help from people who agree with you that mentioning a perpetrator's name in an article about a crime is somehow glorifying the perp. WhatamIdoing (talk) 22:56, 27 August 2025 (UTC)[reply]
Thoughts anyone? I began a discussion to change what seems to pass for accepted use of redirects and also bolding certain individuals. If the conversation is archived here have we made enough progress to adopt this policy? The discussion is on Wikipedia talk: Manual of Style/Text Formatting. Thank you everyone. Efficacity (talk) 06:26, 30 August 2025 (UTC)[reply]
@Efficacity: What do you mean by accepted use of redirects? I thought your primary contention was to change the MOS regarding the bolding of names per WP:BOLDREDIRECT, but the phrasing of "accepted use of redirects and also ..." seems to imply your suggestion goes beyond simply bolding, and goes to the use of redirects themselves. It sounds like you're also suggesting there not be a redirect for a perpetrator's name to a crime article, for example Shane Tamura should not be a redirect to 2025 Midtown Manhattan shooting#Perpetrator. Is that the case, or am I misreading your premise? ButlerBlog (talk) 15:55, 30 August 2025 (UTC)[reply]

The problem of AI generated deletion nominations

[edit]

I think we have a vested interest in making sure our deletion nominations have been sufficiently reviewed by humans and proposed by humans. I don't know if this is the only example, but currently there is Wikipedia:Articles for deletion/World War 3 (video game) where a large language model was clearly used to propose the article's deletion. I personally am of the opinion that AI generated deletion nominations should be automatically speedy closed, and that we require all noms to be human written. Regardless, we currently do not address the issue at AFD and this a problem only likely to continue to grow. Others might have better policy ideas or a more nuanced approach. Regardless, I do think we need to consider how to handle AI generated deletion proposals at WP:Deletion/WP:AFD as a policy point. The issue isn't going to just go away. 4meter4 (talk) 13:38, 26 August 2025 (UTC)[reply]

You can WP:HATGPT the LLM text and then the AFD is WP:CSK speedy keep due to lack of an intelligible deletion rationale. -- LWG talk 13:52, 26 August 2025 (UTC)[reply]
Also, Wikipedia talk:WikiProject AI Cleanup is a good place to bring concerns like this. -- LWG talk 13:59, 26 August 2025 (UTC)[reply]
LWG Thanks. These are good to do suggestions. If this is how we are to handle this type of thing at AFD it should probably be articulated on the WP:AFD policy page itself so that the community is informed on how to respond in future similar contexts. That's the point of this thread, to formulate some sort of guide at AFD on a standard way to respond to this type of scenario. Best.4meter4 (talk) 14:41, 26 August 2025 (UTC)[reply]
I looked at the AFD page, and it takes ~550 words to say that there's a problem, but – wasn't there actually a real problem there, identified in the nom statement as "The body of the article relies almost entirely on two articles from TheGamer and on primary sources (the game’s official website and Steam store pages), rather than on significant, independent, reliable secondary coverage"?
I'm looking through the list of sources at the time of the nom, and it's an internet forum, TheGamer x2, official website, sales page x2, official website x3, and finally PC Gamer. That's 70% non-notability-suggesting sources. When someone points out a problem like this, do we really want to be playing Mother, May I? with them about how they described the problem, or do we want to say thanks for letting us know about the problem? WhatamIdoing (talk) 00:27, 27 August 2025 (UTC)[reply]
Sure there were problems, but not ones that demonstrated a fundamental lack of notability as pointed out by multiple editors. I spent quite a lot of time fixing those problems through editing. The nominator could have easily done that themselves. I still found the LLM nomination disruptive, and I wouldn't want to see a flood of nominations made this way. It should be discouraged.4meter4 (talk) 00:44, 27 August 2025 (UTC)[reply]
Wouldn't you have found a hand-written nom that made the same points, and put you on a seven-day WP:HEY timer just as disruptive? I have a hard time looking at that AFD, and the work you put in as a result, and thinking that the biggest problem was the style of the nom's statement. WhatamIdoing (talk) 22:58, 27 August 2025 (UTC)[reply]
I think over focusing on this nomination is a red herring. That nomination isn't the topic raised here.4meter4 (talk) 23:35, 27 August 2025 (UTC)[reply]
That nom, though, gives us an opportunity to ask: Is the real problem bad noms (e.g., treating AFD like a form of on-demand cleanup), or is the problem bad explanations for the nom? WhatamIdoing (talk) 00:36, 28 August 2025 (UTC)[reply]
Sure, if you want to distract attention away from the original more pressing question. I find the line of discussion unproductive within this thread. 4meter4 (talk) 00:45, 28 August 2025 (UTC)[reply]
I find the idea that an AFD nom should be considered invalid based on how the OP wrote the nom statement to be too close to tone policing for my comfort.
It reminds me of other communication problems that we see in the real world. For example, after a natural disaster, the victims spend a couple of days saying how grateful they are for the help and support of the government agencies and non-profit organizations. Around day four, they start saying how terrible these same people are: the sleeping arrangements are bad, the food is lousy, nobody knows what's going on, and why isn't there a government agency sending a drone over my house this directly minute, so I can see whether it's still standing?! This is considered a good sign by the professionals (because it means that the complainers are no longer terrified that they'll die any minute now).
To give another example, when there's bad medical news to share, there's an initial shock, and after that, whoever told you that the baby's going to die/the cancer is untreatable/fill in your nightmare here was the worst possible person to do this and did the worst possible job at it. It should have been the first provider to suspect it, instead of making you wait for the specialist. Or if the first person told you, they should have made you wait for the expert. They should have told you the situation straight out instead of beating around the bush, or if they were direct, they should have slowly and gently led you to the information, instead of dumping it directly on you. And so forth. These complaints, too, are considered good by professionals, because if you don't hear complaints about how you were told, it often means you didn't understand what you were told. The best way for an oncologist to get high scores as a "good communicator" is to never tell the patients any bad news and never encourage the patients to think they might die.
So when I see a complaint about AFD nomination statements being written in the Wrong™ way, I wonder: is the problem with the nom's statement, or is the problem with the nom's decision to nominate it in the first place?
There is no LLM-based bot that creates the AFD nominations. The decision to send an article to AFD is being made by a human, and the 'problem' of an AFD nomination is the fact that the article is listed at AFD at all, not that the nom's statement does/doesn't match a certain style. Noms are encouraged to write a nom statement, but it's not, strictly speaking, a necessity. The {{afd2}} template doesn't break if you provide no rationale at all.
I could imagine a "rule" that says that most AFD nom statements are less than 150 words, in the hope that any LLM users would then add "in 150 words or less" to their AI instructions. In practice, I would expect this to work just about as well as the existing rule that says not to merely say that it's non-notable, which a glance through AFDs suggests is "violated" in about 10% of the noms. But I don't think that we need a rule that says "BTW, after you used your human brain to decide to send this article to AFD, don't use LLM to polish up your reasons for AFDing it". WhatamIdoing (talk) 03:41, 28 August 2025 (UTC)[reply]
Oh, and just for context: I looked through about a hundred AFDs without seeing a single one that looked like the nom used an LLM to write their explanation. So even if we agreed that it's inherently bad to use an LLM to organize the nom's statement, it probably doesn't make a practical difference in >99% of the cases. WhatamIdoing (talk) 03:43, 28 August 2025 (UTC)[reply]
This diatribe is hardly helpful in this context, and I personally am not interested in engaging with any editor who uses an adversarial conversation style. This is a place to incubate solutions and ideas productively and collegially. We still need guidelines at AFD on how to respond to AI written text, and guidance for editors on what to do when AI written text creates problems. There is a reason why there is an entire WikiProject dedicated to this problem, and already policies being crafted at RFCs; such as WP:HATGPT. If you aren't here to make useful contributions in policy writing, and can't communicate in a calm and respectful manner, I respectfully suggest you move on so that others can work.4meter4 (talk) 04:10, 28 August 2025 (UTC)[reply]
We still need guidelines at AFD on how to respond to AI written text – do we? If almost none of the noms, and very few of the responses, use LLM-generated text, do we really need rules about this, or might that be WP:CREEPY?
We still need...guidance for editors on what to do when AI written text creates problems – Maybe, but do we need anything actually specific to AFD for this? Do you expect a rule that says "If it's a talk page, do X, if it's an RFC, do Y, if it's AFD, do Z"? I don't. WhatamIdoing (talk) 04:38, 28 August 2025 (UTC)[reply]
I believe we do, yes. There's already confusion over how or when to implement WP:HATGPT for example. If you aren't in agreement that there is a problem, that's fine. Don't expect me to engage with you though. I'm interested in developing guidelines that restrict AI use and/or limit its damage at AFD because I do perceive it as harmful. If you don't agree with the premise and aren't interested in helping with that I respectfully request you keep your opposition to yourself and wait to express it during a formal policy proposal. Please don't impede other editors wishing to incubate an idea that they believe in, even if you do not.4meter4 (talk) 04:52, 28 August 2025 (UTC)[reply]
Please don't WP:INTERLEAVE comments.
The idea lab isn't a "supporters only" page. If there are problems with an idea, those should be pointed out clearly and early, so that editors can think of ways to adjust the idea, or at least to prepare an explanation. For example, you think this is a big deal, and I've determined that less than 1% of AFDs are affected, so you should either adjust your perception (maybe it's a pet peeve instead of a big deal) or you should prepare an argument ("Sure, it's only 1%, but 1% drives me nuts, so we should have special rules for AFD that are different from the normal TPG rules anyway just in case it gets worse in a few years"). It's better to hear about the holes in your idea now than to have your proposal fail later. WhatamIdoing (talk) 05:00, 28 August 2025 (UTC)[reply]
My simple response at present to you is that, AI use can be a form of WP:DISRUPTIVE editing at AFD both intentionally and unintentionally. It could also be a tool used for good when used responsibly. This is where guidelines on using AI at AFD could be helpful in both determining appropriate use and what is disruptive use. WP:VANDALISM only happens in a small % of edits, but that doesn't mean the consequences aren't serious and that a standard response isn't needed with set community guidelines/protocols in place. Additionally, current AI use at AFD is low because AI use overall is in its infancy. The problem is likely to grow rapidly in the near future and we need to have responses and guidelines in place before that exponential growth happens not after. Being prepared for what's coming is responsible and smart. Additionally, the assertion that humans are automatically behind the decision to enact AFDs is a supposition that we can't necessarily hold fast to when LLMs are used. As AI becomes more sophisticated and more independent from human oversight it's possible in the near future that we may have nominations made with no human engagement, input, or direction at all in the process. These are issues we should be discussing and planning for now as they are foreseeable problems. Lastly, there isn't yet a formed idea here to vet, and for that reason I don't find the adversarial questioning particularly helpful. Constructive input on what a potential guideline could be would be more useful at this stage as no fully formed idea has been developed yet. Best. 4meter4 (talk) 05:49, 28 August 2025 (UTC)[reply]
How exactly was that response not "calm and respectful"? Gnomingstuff (talk) 05:36, 28 August 2025 (UTC)[reply]
To me the tone came off as overly combative, but perhaps that's just my impression.4meter4 (talk) 05:59, 28 August 2025 (UTC)[reply]
The decision to send an article to AFD is being made by a human Hardly relevant – said human was so lazy they then turned their brain over to an LLM to write a shoddy nomination for them, and we should dismiss it with the same lack of effort. Unlike you, I don't believe the ends justify the means: we should inspect the process, not just the result – hence our heavy restrictions on paid editing, on COI, and mainspace bot use. Cremastra (talk · contribs) 06:55, 3 September 2025 (UTC)[reply]
I think Wikipedia:Product, process, policy has the order right. WhatamIdoing (talk) 17:00, 3 September 2025 (UTC)[reply]
Related to the above: I have just WP:PGBOLDly added a new point "E" to Wikipedia:Articles for deletion#Before nominating: checks and alternatives, to say that nom statements are usually less than 150 words. Maybe, eventually, it will have some small effect on bloated statements from newbies. WhatamIdoing (talk) 15:29, 4 September 2025 (UTC)[reply]
Which policy or guideline defines a percentage limit on how many sources in an article have to be "notability-suggesting"? 😕 Anomie⚔ 01:49, 27 August 2025 (UTC)[reply]
None. Regardless, this is off topic to the main point of discussion in this thread which isn't really about any one specific nomination.4meter4 (talk) 02:02, 27 August 2025 (UTC)[reply]
NPOV says "In principle, all articles should be based on reliable, independent, secondary published sources with a reputation for fact-checking and accuracy", which could be interpreted as meaning (using very approximate numbers) that half or more of an article should come from/be possible to cite to a "notability-suggesting" source. This isn't about the percentage of sources (e.g., three out of the ten sources cited in the article) but about the percentage of the article content (e.g., everything in two out of three sections).
Having said that, I don't find that this is a very common interpretation (hardly surprising, as the sentence itself is only a couple of years old, and it usually takes a couple of years for a critical mass of editors to notice the existence of such a sentence in a policy). WhatamIdoing (talk) 00:39, 28 August 2025 (UTC)[reply]
Sigh, more primary source paranoia getting snuck into policies by people who focus only on the contentious parts of contentious articles. Anomie⚔ 00:55, 28 August 2025 (UTC)[reply]
The "secondary" language was boldly added about 2.5 months ago; "independent" is from 2.5 years ago, and was discussed on the talk page. If you don't think it's helpful in that location, you could always revert it. WhatamIdoing (talk) 02:22, 28 August 2025 (UTC)[reply]
I don't have the energy to fight a battle against all the people who love WP:PSTS because it lets them say "this is primary so it's bad" instead of having to address the actual reliability or POV of the source directly. Same goes for "independent" there.
Primary, first-party sources are perfectly fine, and possibly even preferable, for statements of plain fact about which there's no challenge or controversy. If an article consists of mainly those kinds of facts, it would be fine for the article to be mainly based on such sources once WP:N is satisfied. Maybe the article is just that uncontroversial, or maybe it's still stub- or start-class and no one has added the controversial parts that need independent sources to avoid POV issues or the kind of analysis that isn't present in primary sources. Anomie⚔ 14:33, 28 August 2025 (UTC)[reply]
In particular, as pointed out in the response to the deletion request, an article being based almost exclusively on primary sources is not a reason for deletion. Rather, it would be a reason to mark the article as low-quality and in need of improvement per the guidelines documented at WP:SURMOUNTABLE.
But beyond that, this thread is about the use of AI tools for creating deletion proposals rather than the specifics of a particular proposal. However, the debates around the legitimacy of this deletion request point to a good reason to disallow AI agents to create the requests. The rules for whether an article should be retained are not clear cut and there are instances where a discussion is needed before we can decide that an article should be deleted. If a human did not submit the request, who is going to defend its existence when somebody objects to the deletion? Normally, I'd expect that the requestor can respond with their rationale for submitting the request.
I would also be concerned about the fact that if an AI-submitted deletion request is accepted by one individual, that would mean that only one person was involved with the deletion. Under the expected process, we would at least have two people making the decision: the person that initially reviewed the article and submitted the request for deletion, and the other who approved it.
However, I can see the benefit of using machine learning models to identify articles that should be deleted, but I don't think that those deletion requests should be listed among the normal deletion queue. At the very least, they could be in a separate queue that humans can review and decide whether they want to sponsor the deletion request through the normal process. And if they do prove to generally be of high quality, then we could make a better determination about how to integrate LLMs into the deletion process.
Ovenel (talk) 21:11, 28 August 2025 (UTC)[reply]
This is almost entirely irrelevant:
  • AI agents are not submitting requests, humans are.
  • Only one person is involved with very nearly all XfDs: the person who nominated the page for deletion (the exceptions are when someone is unable to create the nomination page for some reason).
  • The only time a single person is involved in a deletion is when an administrator speedily deletes a page themselves. All administrators are human.
  • The person who nominated the page for deletion can respond to/defend the nomination. Whether the deletion rationale was or was not written using an LLM is completely irrelevant to this. Thryduulf (talk) 23:04, 28 August 2025 (UTC)[reply]
I agree that the idea of a bot submitting articles to AFD feels like a bit of a tangent to the original question, but I also agree with Ovenel, in that I think such a bot would be a bad idea.
If it were possible to have a bot that could do a proper WP:BEFORE search (and someday it might be, though probably not any time soon), I wouldn't trust its (non-existent) judgement about notability, and I'd worry about flooding AFD. But I might also wonder about whether it could be useful in reverse, e.g., to suggest sources that the human noms had missed. WhatamIdoing (talk) 23:15, 28 August 2025 (UTC)[reply]
I agree with you. Any such bot would obviously be limited to machine-readable sources (although it's probable that a greater proportion of future sources will be machine-readable and possible that some sources which are not currently machine-readable will be in future) that are indexed online in some fashion (I don't have an opinion on whether it is likely that the proportion of sources this represents will change), which is obviously insufficient for a proper BEFORE search in at least some topic areas. These all mean that a bot would be much more reliable for articles related to e.g. 21st century American pop culture than it would be for articles related to e.g. 17th century African poetry. WP:SYSTEMATICBIAS would therefore obviously be very relevant. This is getting very off-topic for this discussion though. Thryduulf (talk) 23:34, 28 August 2025 (UTC)[reply]
I guess I was misunderstanding the policy proposal that is being discussed here. I thought the issue was in regards to setting up a bot to submit AFD requests, using an LLM to generate the language of the request after some automated process has determined that an article should be deleted. I.e., supplementing the sorts of bots that already exist in the Wikipedia ecosystem with an LLM. If the concern is that people would be using an LLM to write up their request after they've already determined an article should be deleted, I'm not opposed to that.
I can appreciate the concern about allowing minimal effort submissions, and I know that people who have experience working with open-source software have likely seen the issues that LLMs can bring to the table (namely, many open-source maintainers have found that reviewing low-quality, LLM-generated pull requests have ultimately made it harder to work on their projects rather than easier). But I'm reticent to reject a new tool before we really see it being used unless there is a very clear cause for concern.
Ovenel (talk) 14:44, 2 September 2025 (UTC)[reply]
@Ovenel Check out Category:Articles containing suspected AI-generated texts from August 2025. And these are the article-space issues obviously, but it’s definitely turning into a time sink there already. —Locke Cole • t • c 15:12, 2 September 2025 (UTC)[reply]
Also, if you want an idea of how many LLM/AI comments are being made and documented so far, here's a good place to start. —Locke Cole • t • c 15:31, 2 September 2025 (UTC)[reply]
@Locke Cole Thank you for the links. From a quick review, I found this chain in Talk:History_of_Christianity#Errors_according_to_AI that exemplifies the problem well. The AI-generated text can be very long and take a lot of effort to review. And the issues that the AI identifies do not appear to generally be legitimate, or, at the very least, miss the context that justifies the choices made by the contributors to the article. In this case, it looks like somebody spent a minute generating a big wall of text to post in the talk page, and it had to have taken at least an hour for somebody else to review it and ultimately find that no changes to the article were warranted. Ovenel (talk) 04:27, 3 September 2025 (UTC)[reply]
it looks like somebody spent a minute generating a big wall of text to post in the talk page, and it had to have taken at least an hour for somebody else to review it and ultimately find that no changes to the article were warranted. And that is kind of the crux of the problem. We need more editors to replace folks who retire, quit, burn out, or simply die, so there's this natural inclination to not want to WP:BITE the newbies (or in this case, someone who isn't even that new as far as account age goes). But if this goes unchecked, our volunteers (you, me, everyone else) who have to deal with this will find ourselves bogged down in many times pointless discussions when we could have been researching, writing, or maintaining many of the other important elements of a project like this.
I don't know what the answer is. Or if there even is one that would be compatible with how Wikipedia works. —Locke Cole • t • c 04:40, 3 September 2025 (UTC)[reply]
When discussions feel low-value, people will ignore them. WhatamIdoing (talk) 19:22, 3 September 2025 (UTC)[reply]
I'm not sure if this is really a continuation of the sorts of bots that already exist – as far as I know, we don't have bots determining whether articles should be deleted, or submitting AfD requests by themselves. Chaotic Enby (talk · contribs) 13:26, 7 September 2025 (UTC)[reply]
We don't, nor am I aware of any proposals to do so. Thryduulf (talk) 13:52, 7 September 2025 (UTC)[reply]
  • Didn't read the full discussion but my 2 cents - if an AI started the deletion discussion, no matter how many participants have commented, the discussion should be closed, negated, and filed away. AI does not run Wikipedia and should certainly have no "voice" in determining which articles, categories, etc., to keep or not to keep. Randy Kryn (talk) 14:55, 29 August 2025 (UTC)[reply]
    No AIs have started (or can start) deletion discussions. Thryduulf (talk) 15:14, 29 August 2025 (UTC)[reply]
    People often use AI as a proxy for their own thinking, so I can see where Randy is coming from. Bremps... 16:30, 29 August 2025 (UTC)[reply]
    @Bremps, could you explain this a little more? I'm not seeing the connection between what I think @Randy Kryn is talking about (an autonomous AI bot starts an AFD discussion with no human input whatsoever – because that's "an AI started the deletion discussion", as opposed to "a human started the deletion discussion, and happened to use AI to write out some of the sentences") and what you seem to be talking about (people using AI to produce sentences). WhatamIdoing (talk) 17:04, 29 August 2025 (UTC)[reply]
    I'm not 100% sure if this is what Randy meant, but I interpreted the comment as referring to someone lazily using AI to decide to nominate for deletion and to come up with the rationale. Bremps... 17:07, 29 August 2025 (UTC)[reply]
    I'm not sure how AI could decide to nominate an article for deletion? Even if it somehow did, a human would have to be the one to decide to nominate, place the tags, create the nomination page, and submit a rationale. They should also be the one to transclude the nomination page but a bot will do that for them if they don't.
    The only relevance any sort of AI has to deletion is that it is possible for someone to use an LLM to write or assist with writing some or all of the deletion rationale. I don't think that we need anything more than the existing policies and guidelines to deal with this - particularly HATGPT and speedy keep. Thryduulf (talk) 17:19, 29 August 2025 (UTC)[reply]
    Thanks for the speculation, there's a good Wikipedia short story in there somewhere. As I mentioned, I didn't read the discussion and jumped in after reading the original post above, which strongly implied that AI can open a deletion discussion without human input. Having no idea what AI can or cannot do (I've never used any of the things, including Chat, and have no intention of trying them out) I followed up on that. Glad to hear that it, and I, were mistaken. Randy Kryn (talk) 22:55, 29 August 2025 (UTC)[reply]
    I just wanted to clarify that building a script that uses AI to fully autonomously start deletion discussions is within the technical of many editors. The design would look like this.
    1. Find an article that you want to delete
    2. Press F12 and go to your network tab
    3. Inspect the network traffic that occurs when the existing XfD tool runs the AfD script.
    4. Port these curl requests to your favorite scripting platform
    5. Modify the requests to take in parameters
    6. Create a list of articles to check similar to how AWB works. If I was to do this I would get the list of low quality status for WikiProject Energy
    7. Use existing libraries to get the article text for each article in the list
    8. Implement a chunking strategy that provides some of the article text, a prompt, and makes the LLM return JSON indicating a deletion likelihood and reasoning
    9. Create a separate but similar script that runs a BEFORE on the articles that score high. Existing google search packages can be used to run the BEFORE without AI
    10. Then the results of the two scripts are returned back to the LLM which is requested to create another JSON indicating if after the BEFORE AfD is still the right path.
    11. This json is used to algorithmically call the curl endpoints that the existing XfD tool runs.
    One could even use the tokens from their browser to make the AfD appear as their user. Czarking0 (talk) 15:32, 2 September 2025 (UTC)[reply]
    The part that worries people isn't 2 through 11. The part that worries people is "Find an article that you want to delete". That's the part that must be done by a human. WhatamIdoing (talk) 17:56, 2 September 2025 (UTC)[reply]
    It does not have to be done by a human. As I stated you could pick a category and recurse arbitrarily. I could run this on every article in category BLP. That does not meet the bar of a human picking an article to delete. Czarking0 (talk) 19:36, 2 September 2025 (UTC)[reply]
    Oh nevermind my first comment, you misunderstood the first point. That first article is just to get the network traffic that you need to replicate with the script. If you already know the network traffic or are familiar with how the existing XfD tool works you can skip the first step. Czarking0 (talk) 19:38, 2 September 2025 (UTC)[reply]
    I suspect that automating step 1, in the sense of sifting through categories to find unwanted articles (but not so much in the sense of getting the network traffic needed to automate the rest), is exactly the thing that scares people and would result in flooding AFD.
    I suspect that the very minimum amount of human thought people would normally accept is:
    • a human finding the unwanted article (I personally sift through the category; I personally scroll through Special:NewPages to spot articles about subjects I believe are non-notable; I personally stumbled across the article while doing something else; maybe I personally check the result of some complex search or scan [e.g., BLPs in Category:Professors with an ORES category of STEM*, whose inline citations all have URLs whose domain names end in .edu]), and
    • the human glancing over the bot's output to see whether it's reasonable (e.g., to notice that the BEFORE search relied entirely on checking recent news reports, when the subject is not the kind you expect to find in the news).
    Even that would upset people if too many of these happen. (And speaking for myself, I want the human to decide what the deletion reason is, even if they're feeding their reason to an LLM, and even if their reason is wrong/on the WP:ATA list.) WhatamIdoing (talk) 20:11, 2 September 2025 (UTC)[reply]
I agree with this, though I also like @Tryptofish's idea at the RFC of making LLM/AI something people must disclose. That sub-discussion is ongoing at Wikipedia:Village_pump_(policy)#Alternative_approach:_make_transparency_policy. —Locke Cole • t • c 06:37, 30 August 2025 (UTC)[reply]
I have been thinking about the "must" and wondering whether we should treat this the same way as we do other rules about obviously bad behavior. For example, we have {{uw-vandalism1}}, {{uw-vandalism2}}, {{uw-vandalism3}}, and {{uw-vandalism4}}. Vandalism is obviously/inherently bad in a way that LLM use isn't (i.e., someone with dyslexia or limited English might think that using an LLM is helpful, whereas nobody thinks that poop vandalism is helpful), but we give four warnings for it, and we normally require one warning before you can make a report to Wikipedia:Administrator intervention against vandalism. Only vandalism happening after the first warning risks a block (unless it's egregious).
So maybe we should follow our usual pattern. That would mean re-writing {{uw-llmtalk}} to assume that the person is doing their best and posting their own ideas (just not in their own words), and not strike or remove the comments until multiple warnings have been delivered and the person persists in using LLMs post-warning. WhatamIdoing (talk) 19:41, 30 August 2025 (UTC)[reply]
That would certainly be less bitey. Donald Albury 20:46, 30 August 2025 (UTC)[reply]
I keep thinking about how I respond to rambling, long winded talk page comments that are NOT written by LLMs… my reaction is almost always: “TLDR - please summarize”.
So perhaps the first warning when LLMs are used should be something similar… a friendly request to “summarize using your own words”. Blueboar (talk) 20:46, 30 August 2025 (UTC)[reply]
There are already escalating templates for llms: Template:Uw-ai1, Template:Uw-ai2, Template:Uw-ai3, Template:Uw-ai4, although they are not included in the Twinkle defaults so I don't think they are very well known. CMD (talk) 04:57, 3 September 2025 (UTC)[reply]
Thanks for those links. It is in Twinkle, under "Behavior in articles". WhatamIdoing (talk) 17:55, 3 September 2025 (UTC)[reply]
Sigh, looks like another trip back to the personal script mines. CMD (talk) 14:19, 4 September 2025 (UTC)[reply]
•Opinion : I generally support the use of LLMs, specifically in Edits, 3-O, RfC, RSN, NPoVN, DRN, ArbCom etc, as I have conveyed in the other discussion ongoing in the village pump.
But constructing an entire article simply takes too much time and effort to be nominated for deletion by a single promt. Thus, using LLMs to delete an entire article should be considered disruptive and bad faith. Cdr. Erwin Smith (talk) 11:50, 4 September 2025 (UTC)[reply]
I don't think the second half of this makes sense. We have no way to know if the LLM's output is from a single prompt. You can do much more precise things with multiple prompts linked by scripts. See my design above. Czarking0 (talk) 14:12, 4 September 2025 (UTC)[reply]
If you are talking about using an LLM to write the deletion nomination, then a single prompt is very likely going to be sufficient to produce a coherent and relevant nomination if the rationale is straightforward and the application of the relevant policy/guideline to the article is clear. I do fully agree though that an LLM should not be deciding whether and/or why to nominate an article for deletion. Thryduulf (talk) 14:26, 4 September 2025 (UTC)[reply]
I agree that there is a significant distinction between having an AI search for articles to delete, and an editor using an LLM to generate the text to explain why the article should be deleted.
For the latter… the primary issue seems to be that LLM’s tend to generate walls-of-text. However, so do editors writing their own rationals.
We deal with human written walls-of-text by saying “TLDR” and asking the human to summarize their argument (and respond to the summary. We can do the same with nomination text generated by LLMs. This forces the human behind the LLM to engage. Blueboar (talk) 14:58, 4 September 2025 (UTC)[reply]
The same LLM can summarise its generated text as well. Cdr. Erwin Smith (talk) 15:48, 4 September 2025 (UTC)[reply]
So? If someone is asked to summarise their arguments there are three possibilities:
  1. They don't.
  2. They do, and it results in a concise, coherent and relevant rationale
  3. They do, but the result is still lacking in one or more of those attributes.
In none of those cases does it make a difference whether any of the text was written by a human or by an LLM - we already have all the policies, guidelines and practices to deal with the matter, and we already apply them as appropriate on a daily basis so we don't need anything more than we currently have. Thryduulf (talk) 16:00, 4 September 2025 (UTC)[reply]
But I do like the idea of asking people who post long LLM-generated messages on the talk page to summarize their comments.
The existing Template:Uw-ai1 template series is all about suspected LLM-generated content in articles. I think we might need a separate one for discussions. WhatamIdoing (talk) 17:13, 4 September 2025 (UTC)[reply]
As I've stated, I have no problem with people using AI for all the different purposes, but using AI for deleting an ENTIRE article is on a whole other league.
I've witnessed an article in which I've contributed significantly getting deleted firsthand, and believe me, it hurts.
People need to feel the gravity of this type of a request. The only barrier which can prevent any random person from waking up and posting a request for AFD is the manual mental labour that he'd have to put in.
So I believe atleast this sector needs to be kept clear of any AI. Cdr. Erwin Smith (talk) 17:50, 4 September 2025 (UTC)[reply]
Random people don’t have to put in much mental labor to file an AfD, even if they are human. We get lots of AfD nominations where the only rational given is “Not notable”.
Hell, such minimalist nominations probably take less mental effort than using an LLM (with an LLM you at least have to type out a prompt) Blueboar (talk) 19:31, 4 September 2025 (UTC)[reply]
One wrong doesn't justify another.
With LLMs in the mix, you'll start getting a flood of increasingly sophisticated proposals which you would't be able to dismiss instantly.
And guess what will be their targets? Articles crafted by you and me through our hands. Cdr. Erwin Smith (talk) 19:56, 4 September 2025 (UTC)[reply]
WP:EFFORT is on the list of arguments to avoid in deletion discussions. WhatamIdoing (talk) 20:32, 4 September 2025 (UTC)[reply]
That was written with humans in mind, not machines. Cremastra (talk · contribs) 21:18, 4 September 2025 (UTC)[reply]
Yes: It was written to say that even if we're talking about "Articles crafted by you and me through our hands", the fact that it took human effort to create an article does not mean that the article is exempt from our notability standards. WhatamIdoing (talk) 21:39, 4 September 2025 (UTC)[reply]
As @Cremastra stated, this rule should be abided if a human writes the AfD. But the discussion is about creating a new rule which discards all types of AI written requests for AfD, and that was the rationale behind my comment. Cdr. Erwin Smith (talk) 03:54, 5 September 2025 (UTC)[reply]
But we don't need such a rule, because the rules that apply to humans already apply to AI equally: if it's disruptive in some way we deal with it in the manner appropriate to the nature of the disruption. If it isn't, then we treat the good faith contribution as a good faith contribution. Thryduulf (talk) 04:39, 5 September 2025 (UTC)[reply]
I agree.
My comment is narrower: If it's bad for me to write the article ___, for a human to decide it's non-notable, and for a human to use an LLM to write a fancy-sounding AFD nomination statement because deleting "my" article will lose all my WP:EFFORT, then it's equally bad for the same thing to happen, only using a hand-written AFD nomination statement.
The nom statement isn't what causes my WP:EFFORT to be kept or lost. The other editors' analysis of whether "my" article is appropriate for Wikipedia is what determines whether my EFFORT is lost.
To put it another way: No matter who/what writes the AFD nom statement, and no matter what they write in in, editors are not going to agree to delete articles I've written, such as Breast cancer awareness. And conversely, if someone writes an article about a totally non-notable subject (e.g., a brand-new garage band, a very minor character in a video game), there is nothing anyone can write in a nomination statement that will make editors agree to keep it.
AFD runs on sources and facts about articles. It does not run on eloquent statements. WhatamIdoing (talk) 04:57, 5 September 2025 (UTC)[reply]
What's slightly more annoying is when you have articles that fall in between "garage band" and "something the vast majority of English speaking are familiar with". Bird Conservation Nepal, is my go to example, especially as of this revision, notability tagged since 2018 and sourced mostly to the organization's own website. It was tagged for deletion[7] by an UPE sock gaming autopatrol, and in part using AI-generated !votes and deletion nominations to make themselves seem like a real editor[8] much more quickly and lazily and, from the looks of the SPI page, effectively than they would otherwise. This nomination in particular irked me at the time, because part of it wasn't true and searching the organization's name gave me a lot of sources, but I knew that, as a short stub on a business on the Indian subcontinent sourced to the organization's own website, written not in slightly SEA-influenced English that was very deferential to the org's founder, was quite likely going to get killed at AFD no matter the merits of the article. But yes, the use of AI was disruptive in this case, because it allowed the spamfarm to spamfarm more effectively, but then again, I and four other editors didn't catch on at the time & the discussion had to go for two weeks.
What I'm really disagreeing with, is, I suppose, is that idea that AfD runs on sources and facts, not eloquent statements, because people themselves tend to give a lot of attention to presentation than they should. I had a great conversation with a linguistics professor once, about the fact that when he switched to his natural (American) Southern accent, people looked at him like he was stupid, but when I spoke in my (then quite strong) English accent, people saw either "sexy" or "genius", and it had very little if anything to do with what we actually said. Similarly, I once had a mind-boggling conversation with somebody who kept insisting that somebody using the phrase "do the needful" was obviously up to no good, because 'only scammers spoke like that'. And maybe I'm really cynical, but I don't think AfD participants are immune to those biases. I definitely don't think a non-obvious AI telling them in perfect, American English that this slightly clumsily written article on an Indian actress or business isn't compliant with Wikipedia policies is going to prompt much push back. Not that this is entirely a problem with AI... I mean, it was an open secret, for years, that a large number of U5s were being done on just normal, attempted drafts or Wikipedia profile pages from SEA editors. And, back to the 'LLM generated deletions are used by bad faith actors for disruption' - if anybody discovers a way to get intentional UPE sockfarms to stop being the little shits that they are, lmk and I'll try and get you to, idk, negotiate a peace deal in Gaza while you're out there doing miracles. GreenLipstickLesbian💌🦋 07:20, 5 September 2025 (UTC)[reply]
I don't think that LLM nomination statements (i.e., the ones we've noticed) cause Wikipedia editors to agree with the nom. If anything, the reaction seems to be the opposite: If you're so unfamiliar with AFD and its conventions that you post 450 words with bullet lists and bold-faced headings, your nomination is automatically suspicious.
A nom statement of "lacks significant independent coverage, relies on non-reliable sources, or serves as promotional content rather than a neutral, verifiable encyclopedic entry" (from your example) doesn't make me suspect the use of an LLM. (It might make me wonder whether someone copy/pasted this from an unofficial summary of our notability standards.) WhatamIdoing (talk) 20:34, 5 September 2025 (UTC)[reply]
Yeah, the copy-pasting thing wouldn't surprise me either - but that phrase has never been used before on the Google-indexable internet[9], so, combined with the other evidence at the SPI, I'm pretty sure they copy-pasted a sentence fragment from a chatbot's explanation, to obscure what they were doing. And I wouldn't have thought LLM either (and didn't - tbqh I thought "oh, joy, somebody gunning for NPR who has no idea what they're doing"), until I saw the fact that several other socks had made the same style of !votes and nominations, after the SPI had concluded. But that brings us back to the same issue - the obvious LLM generated statements are (likely) going to be ignored by human editors some of who will !vote to spite the machine, and the non-obvious ones brought by editors acting in bad faith won't be impacted by any policy, because, well, editors acting in bd faith don't listen GreenLipstickLesbian💌🦋 22:00, 6 September 2025 (UTC)[reply]
Hmm, I was thinking more of an inept person copying from a UPE business' internal documentation:
"Dear New Hires, welcome to Scammers R Us. Your first assignment, after setting up your account, is to build up your credentials by finding and nominating some articles for deletion. Wikipedia will delete any article that lacks significant independent coverage, relies on non-reliable sources, or serves as promotional content rather than a neutral, verifiable encyclopedic entry. Look for articles about smaller businesses or non-profit organizations that have very few citations and no active editors. Before nominating an article, you must get written approval from your manager, so your manager can check the list of past clients in our confidential client database. After you have approval, use Wikipedia:Twinkle "XfD" to nominate the article for deletion. Put a short description of the reason for deletion into the Twinkle form." WhatamIdoing (talk) 23:00, 6 September 2025 (UTC)[reply]
But sterner regulations can and should cover AI use.
Your approach of ignoring the use of AI as if its not problematic and steadfastly denying that AI is fundamentally incompatible with a human encyclopedia is troubling to me, as I think it misses the gravity of the situation we're facing. Cremastra (talk · contribs) 05:33, 5 September 2025 (UTC)[reply]
But sterner regulations can and should cover AI use. Why?
Your approach of ignoring the use of AI as if its not problematic I'm absolutely not doing this. AI can be disruptive, and when it is disruptive it needs to be dealt with. However given that we can deal with this disruption using existing policies and guidelines we don't need new policies or guidelines. As an advantage this means that disruption can be dealt with as disruption even if it isn't clear whether the editor causing the disruption is using an LLM or not.
AI is fundamentally incompatible with a human encyclopedia this is statement of your personal world view presented as if it were incontrovertible fact. You are entitled to hold that opinion, but it is not factual or based on fact and you really need to stop claiming it as fact. Thryduulf (talk) 09:11, 5 September 2025 (UTC)[reply]
The capability of AI in making a good faith AfDs isn't in question here. The significant uptick in AfDs if it's kept legal is what worries me. Tomorrow, anyone with an agenda in mind could get up and file multiple sophisticated AfDs by using AI generated text.
This can cause a major disruption in the entirety of Wikipedia, and with how much popular the AI apps are getting day by day, I don't think we should take that chance. Cdr. Erwin Smith (talk) 07:14, 5 September 2025 (UTC)[reply]
If someone does this then they will be quickly stopped as disruptive, regardless of whether we have a specific policy against it because we already have policies about disruptive deletion nominations and policies about unauthorised bot and bot-like editing. The existence or otherwise of a policy like this specifically targetted at a very low likelihood event will not make any difference to whether it happens or not - relatively few people are capable of scripting in the manner that would be required, only some of them will be aware we have a specific policy against it and even if they are they would be violating several other, better known policies anyway so one more won't stop them. At absolute best it's pointless theatre, at worst it will make it harder for the disruption to be dealt with given that there will be utterly pointless but time-consuming debate about whether it is LLM disruption, human disruption or some combination of human and LLM disruption that will take time and effort that could be better spent dealing with the disruption (or you know, improving the encyclopaedia). Thryduulf (talk) 09:21, 5 September 2025 (UTC)[reply]
@Cdr. Erwin Smith says that Tomorrow, anyone with an agenda in mind could get up and file multiple sophisticated AfDs by using AI generated text.
I say: Today, anyone with an agenda in mind could get up and file multiple sophisticated AfDs by using hand-written text.
If flooding AFD is a concern, we need a rule against flooding AFD. If flooding AFD is a concern, we do not need a rule against one of the many ways that AFD could be flooded.
  • checkY Good: Flooding AFD would be bad, so we create and enforce a rule against flooding AFD.
  • ☒N Bad: Flooding AFD would be bad, so we create and enforce a rule against using LLMs to write the nomination statement, but all the other ways people might flood AFD are okay with us!
Previous discussions on the risk of flooding AFD have suggested limits around 20 articles on a similar subject at a time (e.g., 20 Brazilian Olympic athletes on Monday, 20 Alaskan cosmetic surgeons on Tuesday, 20 European military units on Wednesday, 20 African businesses on Thursday...). A simpler approach might be "maximum of X nominations every Y days". WhatamIdoing (talk) 22:13, 5 September 2025 (UTC)[reply]
•Support a blanket rule against flooding, since that's the primary issue, and this will automatically solve the potential threat posed by LLMs.
But the limit needs to be much lower. Honestly speaking, 20 at a time per user sounds ludicrously high regardless of the subject barrier. I would like to hear :
1. What others think this limit should be?
2. Whether filing an AfD should be ECU restricted? Cdr. Erwin Smith (talk) 07:22, 6 September 2025 (UTC)[reply]
@Cdr. Erwin Smith, the community won't agree to restrict AFD nominations only to 0.25% of registered accounts. For one thing, many hands make light work: we actually need newer editors (like you) to let us know when they find a problem. For another, if you don't allow AFD nominations, the restriction will encourage other editors to misuse other process, such as Wikipedia:Proposed deletion, Wikipedia:Drafts, and Wikipedia:Merging to get rid of articles they believe are inappropriate. I wouldn't bother having that discussion at all.
For your first question, why don't you start a new ==Topic== at the bottom of this page? You might want to look at first are how many AFDs we see in a given week, or how many are usually from the same person. For example, Wikipedia:Articles for deletion/Log/2025 August 20 has 79 discussions and 752 comments. About 18 of them are relisted discussions from previous dates. So if you said there was typically 60 new nominations each day, there would be 420 new nominations each week. Maybe 20 separate nominations per week (less than 5%) is just fine. Maybe even 10 per day would be fine. WhatamIdoing (talk) 20:12, 6 September 2025 (UTC)[reply]
I would also support a rule against flooding. To refine the rule I think we should keep two kinds of flooding in mind.
  1. Flooding the number of AFD. To determine this limit I suggest we use a data driven approach where we run a query to determine the number of AfD it is appropriate to have at once. Specifically, I think for each week of the past five or ten years we should count the number of AFD opened by each user who opened an AFD. Then for each year we plot a histogram of the number of AFD opened in a week by each user. These should be compared to observe any significant time series effects. If a time series effect is seen it may need to be investigated on a month by month basis. Then combine all the data together into a sample histogram and determine the 99%-tile of the histogram. Non admins should be limited to opening less than the 99%-tile number of discussions in a week. To enforce this a bot could speedy keep AFD noms that exceed the limit.
  2. Flooding in an AFD. In this scenario an editor uses an LLM to make extremely long winded points causing them to dominate the conversation. To prevent this, I think non-admin users commenting on an AFD should be character limited once the length of the discussion has exceeded 10,000 characters. The limit should be also data driven by checking the distribution of number of characters per user in the past year's AFDs. Also set around the 99%.
If flooding is still seen as a problem after these limits then the percentile can be lowered. Czarking0 (talk) 23:48, 6 September 2025 (UTC)[reply]
If you're able to do the analysis for #1, then I believe you can get the data via Wikipedia:Request a query. It sounds like you'll just need the username for the editor who created the AFD subpage + the creation date. WhatamIdoing (talk) 00:28, 7 September 2025 (UTC)[reply]
It's worth noting that absolute number of AfDs isn't the only concern regarding flooding, but also the number of concurrently-open AfDs about similar subjects, e.g. If someone has opened 5 AfDs each day this week about African sportspeople active in the 1950s, all of which are still open, then another 5 AfDs on the same subject is potentially problematic as the number of people interested in and able to look for sources etc is limited and they only have a finite amount of time in which to do so. In contrast that same person opening 10 AfDs about North American business people active in the 1990s is unlikely to be problematic as the editors involved with those articles are unlikely to significantly overlap with those dealing with the sportspeople. Whether this is something that can be even investigated algorithmically I don't know. Thryduulf (talk) 08:32, 7 September 2025 (UTC)[reply]
I don't think a 99% limit is necessarily ideal. In a case where AfD nominations and character counts per AfDs are reasonable (no flooding), then that cutoff would still penalize 1% of (non-admin) editors, while the same amount would be penalized after a year with massive AfD flooding issues. Also not sure about limiting this to non-admins specifically – besides the person closing the discussion, admins shouldn't have more power than non-admins as participants in the discussion. Chaotic Enby (talk · contribs) 13:43, 7 September 2025 (UTC)[reply]
I think to address your first concern the community could, after seeing the data, determine a consensus cutoff (maybe it is 99.9%) that automatically expires after one year. The cutoff could be reanalyzed the next year and if the same value is chosen the community could opt to implement the cutoff for two years.
I think it is wise to not limit admins because there are niche cases where a lot of articles need to be deleted and admins are trusted users who if they engage in flooding have additional mechanisms to be held accountable like ARECALL. Czarking0 (talk) 17:06, 7 September 2025 (UTC)[reply]
I think that it's reasonable to calculate a 99% limit, but if we think the number is unreasonably low, then we should probably pick a higher number. We can start with some basic descriptive statistics and use our judgment and experience to figure it out from there.
@Czarking0, can you do this kind of analysis? WhatamIdoing (talk) 17:41, 7 September 2025 (UTC)[reply]
Can I? Yes. However, I am not planning to unless there is somewhat wide agreement that it will be used. Czarking0 (talk) 17:46, 7 September 2025 (UTC)[reply]
If RAQ will give us the data, and you will do the analysis, I'll use your numbers to write an RFC to adopt an anti-AFD-flooding rule. Does that sound like a fair plan to you? WhatamIdoing (talk) 17:48, 7 September 2025 (UTC)[reply]
In principle yes, but for me think an RFC is not a waste of time I would at least need to see that at least half the people in this thread agree. Things are not going to get implemented if just you and I agree on something. Czarking0 (talk) 23:42, 7 September 2025 (UTC)[reply]

Firearm brands and models in articles about mass shooting events

[edit]

It is an established fact that gun sales in the United States increase after mass shooting events. [10] [11] [12] [13] Including firearm brands and models in articles about mass shootings and shooters is akin to advertising.

I think we should have a MOS:FIREARMS section in WP:MOS that would say that inclusion of gun brands and models is strongly discouraged unless absolutely necessary and relevant to the article (as determined by consensus on the article talk page). TurboSuperA+[talk] 04:43, 3 September 2025 (UTC)[reply]

At a quick glance at those citations, I see a clear correlation between violence and gun purchases, but I don't necessarily see a clear causation, and also don't see anything linking specific makes/models. What am I missing in these citations, or do I misunderstand your thesis? With regards more broadly if we're contributing or advertising in a promotional sense, I would fall back on not-censored -- we do not shy away from topics people find objectionable, even if they might seem to shine a good or bad light on a specific topic. We're interested in verifiable facts, not necessarily shaping WP in alignment to our personal beliefs or morality. TiggerJay (talk) 05:24, 3 September 2025 (UTC)[reply]
  • Bad idea per WP:CREEP and WP:RGW. Those studies furthermore have pretty limited scope and unclear significance and even some self-contradictory parts. There's also nothing I see that has any specifics on linking make/model sales to those used in specific incidents, or that anyone needs to look at Wikipedia for that information. 35.139.154.158 (talk) 05:25, 3 September 2025 (UTC)[reply]
Truthfully, I see where you're coming from, but TiggerJay is correct, WP:NOTCENSORED is a real reason to not preemptively exclude such information. That being said, WP:NPOV (specifically, WP:DUE, but also WP:BALASP) should be considered when attempts are made to say exactly what brand/model of firearm was used for the mass shooting of the week. Also consider WP:IINFO, WP:VNOT and WP:ONUS. Taken together, unless there's significant RS coverage of these kinds of details (and not just a passing mention in a minority of sources), these are all good reasons to consider excluding (and they're already WP:PAG, so no need for more instructions). If there's disagreement, start an WP:RFC to help determine whether there is consensus to include or exclude. —Locke Cole • t • c 05:35, 3 September 2025 (UTC)[reply]
I agree totally with LC above, already covered by WP:DUE etc if properly applied. It really doesn't matter why people are obsessed with such details - if they can't provide evidence of the level of WP:RS coverage needed, out it goes. AndyTheGrump (talk) 06:19, 3 September 2025 (UTC)[reply]
This sort of very low-level content prescription isn't usually in scope for the MoS, so I think WP:CREEP applies here. Locke Cole is quite correct -- if a detail isn't generally reported in high-quality, reliable sources, we shouldn't be reporting it anyway per WP:DUE. On the other hand, if it is generally included in those sources, we shouldn't exclude it just because we find it distasteful or worry about how people may react to it. The closest similar guidance (regarding whether to include or exclude certain factual details) is MOS:DEADNAME, which follows more-or-less the same principle -- a former name under which someone was widely known in reliable sources should be included; one under which they weren't covered in RS shouldn't. UndercoverClassicist T·C 06:43, 3 September 2025 (UTC)[reply]
I see little value in routinely including commercial brand names of firearms in articles about mass shootings but I think the information about the model and the caliber of ammunition used is relevant. For example, there has been extensive discussion for years about how AR-15–style rifles have certain features that make them common weapons of choice in these crimes, and many readers will wonder whether or not one was used in a given mass shooting. Many other models of firearms have also been used in these crimes. Similarly with caliber. The .223 Remington and the very similar 5.56×45mm NATO are the most common cartridges used with AR-15s but many other calibers and cartridge are also used with AR-15 models that are available with a variety of chambers, and I think that information, when well referenced, is of encyclopedic value as well. Cullen328 (talk) 07:26, 3 September 2025 (UTC)[reply]
I agree with Locke Cole, and with S Marshall below. @Cullen328 when you say I think the information about the model and the caliber of ammunition used is relevant. that's fine but irrelevant. What information is relevant varies by the individual article based on what information reliable sources determine is relevant. For example, while I haven't followed the news coverage of the Annunciation Catholic Church shooting that closely, I don't recall any mention of the ammunition at all, let alone type and brand, and nothing more detailed about the weapon used than rifle, shotgun and pistol. I'm sure it's out there in some reliable source, but unless there is extensive coverage of either of those facts it's simply not DUE - and DUE is the only policy or guideline I think we need for situations like this. Thryduulf (talk) 10:32, 3 September 2025 (UTC)[reply]
Thryduulf, WP:DUE deals with how to handle a range of viewpoints and the words "view" and "viewpoint" are used consistently in that section of policy. The example used is the flat Earth notion. The type of weapon used in a crime is an objective factual matter and is not a "viewpoint". There are not a range of viewpoints about which firearm was used in a crime. If reliable sources report that competent legal authorities verify that an AR-15 was used in a crime, there are not a range of viewpoints arguing that it was really a bolt action deer hunting rifle or a Colt .45 revolver instead. Applying WP:DUE to objective factual matters is a misreading of policy. Cullen328 (talk) 16:37, 3 September 2025 (UTC)[reply]
DUE applies to how much weight to give to factual matters as well as viewpoints. Thryduulf (talk) 17:39, 3 September 2025 (UTC)[reply]
Looks like, until somewhat recently, WP:MINORASPECT was a subsection of WP:DUE, while now it's a subsection of WP:BALANCE. That may be a source of some of the confusion here. Anomie⚔ 17:44, 3 September 2025 (UTC)[reply]
  • This is too prescriptive, too detailed, and too low-level. The manual of style already overreaches way beyond "style" in far too many places, and it needs to be cut back, not expanded.—S Marshall T/C 07:44, 3 September 2025 (UTC)[reply]
    Thumbs up icon Thumbs up icon - But, as always, if you want it done right, BOLDly do it yourself. Seems to me that simply stating meta/tangential/strictly-off-topic opinions like yours is rarely very effective, even when a handful of editors offer two thumbs up. A more direct, more focused approach is necessary; without that, good ideas can bounce around non-fiery Wikipurgatory indefinitely. We've all witnessed that.
    WikiProject Manual of Style is "defunct" (sounds vaguely like "defucked"); I would support a WikiProject Manual of Style reform (full-body battle armor required). I would not only support its creation but would become an active member unless and until I decided I was wasting my time. But that in itself is an idea lab discussion unless one can BOLDly create a WikiProject. ―Mandruss ☎ IMO. 10:23, 3 September 2025 (UTC)[reply]
  • I don't see any need for specific guidance. It is already policy that article content is subject to consensus on the talk page. Phil Bridger (talk) 10:13, 3 September 2025 (UTC)[reply]
  • Unnecessary as inappropriate inclusions of this kind of information can already be removed if consensus to do so exists, or if an argument for removal can be made from WP:DUE or WP:OR. If the content survives WP:DUE objections and can be cited to significant coverage in reliable sources, then WP:NOTCENSORED. -- LWG talk 15:32, 3 September 2025 (UTC)[reply]
  • This is a common problem in mass shooting articles, but I don't think a new policy is needed. Exact details about make, model, calibre etc should be included only if they have significant coverage in reliable sources. I've seen numerous mass shooting articles where users added this type of info, but a lot of it was poorly sourced or WP:OR.--♦IanMacM♦ (talk to me) 16:48, 3 September 2025 (UTC)[reply]
    I agree that this has a distinct whiff of US politics about it, but I think that where the information is well-sourced, too much detail is a "problem" that we don't need to worry about here. This is an encyclopaedia that has articles about individual episodes of US TV shows; individual townships in Where the Heck, Utah (pop. 99); individual species of extinct coleoptera; more than 4,000 words about sexuality in Star Trek; and quite a well-written one about that precognitive octopus. The fact that Johnny R. Fruitcake used a 9mm Penis Extender 9000 for his shooting spree in the Tiny Tots Preschool is hardly the most urgent detail to remove.—S Marshall T/C 17:26, 3 September 2025 (UTC)[reply]
    I often remove things that are not the most urgent things to remove. And I have little problem with a community consensus to remove them. ―Mandruss ☎ IMO. 18:32, 3 September 2025 (UTC)[reply]
  • I agree with the OP. These articles can get way into the details of the guns and ammo. It's usually sufficient to simply say "an automatic rifle" etc.. without needing the brand and/or model - unless that is a factor. I have observed when gun information is generalized, invariably somebody will re-add the specific brand and model of the gun. For some editors, it is a focus of their attention. -- GreenC 18:09, 3 September 2025 (UTC)[reply]
    • I do not agree with the OP about the MOS (yet). That's a very high level of consensus that takes time to achieve. The place to start is with an essay. Write a good essay describing the problem, why it's not a good idea, alternative suggestions. Create a capletter redirect like WP:FIREARMS then start using it in edit summaries. See if it catches on and other people start using it and start contributing to the essay. When you run into conflicts, start RfCs. This is very important. You need a record of dispute over the issue. Once you have 5 or 10 RfCs that have shown clear community consensus, now you got something that has weight, This is when it gets added to MOS. The pathway I describe is exactly what happened with the essay WP:FRAUDSTER which was then added into MOS:CONVICTEDFELON. Why? Because we demonstrated the problem, described it, linked to the essay repeatedly, showed overwhelming consensus in many RfCs, and that was it. It got added to the MOS. — GreenC 18:29, 3 September 2025 (UTC)[reply]
  • I agree with the OP, GreenC, and a number of others. For those saying local consensus is enough, I say how's that working out so far? When something hasn't worked very well after years of "trial", try something else that stands a reasonable chance of working better. Repeat as necessary, or until you run out of somewhat viable ideas. Our respective personal crystal balls have unacceptably high error rates that are largely masked because we accept what they tell us (i.e., safely maintain status quo) far more often than we put them to the test (i.e, try a change and see; the sky shall not fall if the trial fails). ―Mandruss ☎ IMO. 18:27, 3 September 2025 (UTC)[reply]
  • This information should be included if and only if reliable sources cover it in reasonable detail. If it is WP:DUE, it should be included, if it is not, it should not. Don't make a rule about it (WP:MOSCREEP). —Kusma (talk) 18:35, 3 September 2025 (UTC)[reply]
My meta comment. (WOT did you say?) Ok to continue within if meta makes you sexually aroused. Call me! ―Mandruss ☎ IMO. 07:45, 5 September 2025 (UTC)[reply]
  • I gather that future local disputes should refer to this discussion in the VPI archive—IF something resembling a consensus emerges here. I call that "distributed CREEP" and posit that a short paragraph in MoS—a concise summary with a shortcut—is far more efficient.
    (More "distributed CREEP": template docs. I've just spent a day or two, on and off, reworking and polishing the doc for {{hr}}. It could easily be moved to MoS and removed from the template doc to avoid redundancy, with a link to the related MoS guideline. But MoS proper mustn't be allowed to grow too large, so we dump the overflow into template docs etc, self-illusioned that we're fighting MOSCREEP. We are not; rather, we are merely distributing it and scattering it—a clever accounting trick like moving your assets offshore. We are accomplishing little except for increasing the complexity of the "editing landscape", thereby lengthening the learning curve that seriously needs shortening. Now, a novice editor can't use many templates correctly and effectively until they learn how to display template doc (TM:sic), which is distinctly different from shortcutting to an MoS guideline (MOS:SIC). More trees don't always make a better forest and often make an undesirable jungle. Substitute buckets, compartments, or a different metaphor of your choice. It has been well-known/widely-accepted for decades that complexity increases with the number of conceptual pieces, and I've yet to understand why Wikipedia thinks it knows better. This is like the fifth time I've raised this point in a community forum during the past year, and always to deaf ears. Folks simply don't want to talk about it because they aren't accustomed to thinking "Big Picture", or don't feel they have anything worthwhile to say about it. It's pretty sad when we can't address one of the most important Big Picture issues in the project, simply for lack of editor interest. If I gave more of a fuck, I'd be downright frustrated. Thankfully, I don't; I gave up giving so much of a fuck as one of my conditions for my return from full-retirement to semi-retirement. But I still give enough of a fuck to write all this (I estimate 40% of a standard metric fuck).
    In this context, WP:MOS is a conceptual piece but MOS:ITALPUNCT and MOS:LINKQUOTE are not. We could add many individual guidelines to WP:MOS; that would increase its length but not its complexity. It would only become a problem when its size created a performance issue or it exceeded the PEIS limit (currently at 40% of that limit); then we would be forced to trim and/or split. This concludes the longest parenthetical aside of my Wikipedia career.)
    Or, if you like CREEP better when it's distributed, get an uninvolved experienced editor to close this discussion with a concise summary, add a shortcut box before archival, and create the redirect after archival. Then start using the shortcut in local discussions. If it ever makes it into the MoS, simply retarget the redirect. Et voila, problem solved. Almost solved, rather. If any editors like to learn guidelines before they get referred to them, by perusing WP:MOS, WP:TPG, and similar pages (not I), this option doesn't serve them.
    What not to do, which is what I predict we will do: Let this discussion disappear into the barely-accessible recesses of the archive, then move on, thinking we have accomplished something here. I am now pointfully on record with this prediction, said record to endure long after I shuffle off this mortal coil, and I hate being right all the time (prove me wrong. please.). No doubt, I'll be merely one of countless editors who have legacies eternally preserved like bugs in the amber of village pump archives. ―Mandruss ☎ IMO. 18:46, 3 September 2025 (UTC)[reply]
  • The mention of specific firearms in mass shooting articles, and mention of mass shootings in specific firearms articles, have long been contentious. See e.g. The Verge in 2018. My perception, similar to that story, is it's predominantly been the pro-gun folks trying to erase connection between "mere tools" and what those tools have been used for. Personally, I don't get the push to censor the weapon used. I get that in an article about a firearm, there needs to be some substantial coverage focused on that weapon in relation to one or more events to satisfy WEIGHT, but the weapon used in a mass shooting/mass killing event seems like a pretty basic piece of information, and I don't see a good enough case to violate NPOV here.
    I do get the impulse to look for ways to reduce harm, but if we're going to pull an IAR with regard to NOTCENSORED, how about:
  • just stop creating biographies of mass shooters? I noted a while back that our article on Anders Behring Breivik is 200,000 bytes, going into intricate details of his beliefs and activities to an extent that dwarfs articles about far more important historical figures.
  • have a higher bar to include the name of suspects/shooters in event articles?
  • stop racing to create articles on mass shootings and then relying on WP:RAPID (as opposed to WP:DELAY) to prevent it from being deleted?
  • get rid of the mass killing leaderboard articles?
Do we even have any evidence of a mass shooter going to Wikipedia to find out which gun was used, and then using that gun? Because we do have evidence of mass shooters explicitly wanting a Wikipedia page (e.g. [14] [[15]). Simply conceding the "guns are just an incidental tools that have nothing to do with a mass shooting" narrative seems like a step backwards, not forwards. — Rhododendrites talk \\ 17:33, 4 September 2025 (UTC)[reply]

Arbitrary break 1: Firearms

[edit]

I'm very much on the side of not including excessive detail of gun brands and models in articles on most mass-shootings, but this has absolutely nothing to do with NPOV, NOTCENSORED, reducing harm or trying to erase connection between "mere tools" and what those tools have been used for. indeed I'm firmly pro-gun control (an approach similar to the one we have in the UK would be a Good Thing imo) and argued for the inclusion of the suspect's name in the Killing of Austin Metcalf article. My objection is based entirely on the detail being, in most cases, undue weight. In some shootings it makes a difference whether a handgun or rifle was used, and some characteristics of those weapons can be relevant (automatic vs manual for example). However, in the absence of detailed commentary in reliable secondary sources about things more specific than that, such detail in our article is unencyclopaedic. Thryduulf (talk) 18:56, 4 September 2025 (UTC)[reply]

Your argument is functionally indistinguishable from the one I mentioned. You're both creating a higher bar for WP:WEIGHT as it applies to a particular data point, and writing off objections with a hand-wave at what's "encyclopedic". — Rhododendrites talk \\ 19:08, 4 September 2025 (UTC)[reply]
No, I want the same bar of WEIGHT to be applied as it is for other aspects that are not central to the article. Thryduulf (talk) 19:29, 4 September 2025 (UTC)[reply]
Great! But the bar for WP:WEIGHT is not "detailed commentary". Just using the article you mentioned for convenience, although it's not about a shooting, where is the detailed commentary of his birthdate, GPA, his height, the name of the jail he was taken to, the amount of the bond? More likely, these bits of information are merely mentioned in multiple sources, establishing weight. What you are arguing is that information about a gun must meet a higher bar of not just being included as part of the story in multiple reliable sources about the subject but "detailed commentary". — Rhododendrites talk \\ 19:54, 4 September 2025 (UTC)[reply]
The bar for WEIGHT is frequently some sort of detailed commentary.
Here's an example: James W. W. Birch was murdered in 1875. The Wikipedia article says they "speared him to death". It does not say "they speared him to death using a long single-edged sword with a steel blade and a curved black handle with a tooled leather grip and small guard" – even though that is true and verifiable.
Under what circumstances would we provide a detailed description of the murder weapon? Most of the time, the answer to that question is when the reliable sources at least give us a hint that a detailed description of the murder weapon is relevant somehow. The sources in the Birch article apparently didn't indicate that any details about the sword were relevant (it's in a museum; the details are easily available), so we didn't include it. But if a source had written something like "Since the assassins used a single-edged sword, the murder took twice as long" or "Birch tried to dodge away from the blade, but the sword was so long that the end hit him anyway", then presumably we would have.
Why should the rules be different for a 21st century firearm vs a 19th century sword? WhatamIdoing (talk) 20:15, 4 September 2025 (UTC)[reply]
Most of the time, the answer to that question is when the reliable sources at least give us a hint that a detailed description of the murder weapon is relevant somehow - Being mentioned by multiple sources in the context of of the event is what we need, not a special "detailed description". i.e. "we tend to mention things that other sources decide is worth mentioning" not "we tend to mention things only when other sources provide 'detailed commentary' about those things". That would be closer to the bar for us the include, well, a detailed commentary.
This section isn't about whether to provide a long explanation based on brief mentions. It's about including the name/type of gun at all. So yes, if in the course of covering a stabbing, multiple sources described a murder weapon as a spear, I would expect us to say it's a spear and not to censor that fact pending "detailed commentary" of the spear. — Rhododendrites talk \\ 22:18, 4 September 2025 (UTC)[reply]
Being mentioned by multiple sources isn't sufficient. Think about it: Donald Trump wears red ties. Multiple sources mention this.[16][17][18][19][20][21][22][23][24]. But the article Donald Trump does not mention this. Why not, if "Being mentioned by multiple sources in the context of a description of the event is what we need"?
I think that Wikipedia editors are meant to provide an encyclopedic summary, which does not necessarily include providing exact details for some things. That is, I believe we should say that the murder weapon was a sword (because it was a sword, not a spear), but not provide a detailed description of the murder weapon. Leave out the trivia; just say "three firearms" or "a handgun" or "an AR-15–style rifle". Don't say "Smith & Wesson M&P15 Sport III with laser sight, adjustable stock, and free-float handguard in black" – unless the sources indicate that there is something specific about one of those details that actually matters. WhatamIdoing (talk) 22:42, 4 September 2025 (UTC)[reply]
Trump doesn't make a good analogy for much because of scale. I'd reply by just pointing up to my GPA, et al. examples above. We include a ton of detail based on it coming up in a variety of sources about the subject. The % of articles about a shooting that mention the type of gun is going to be an awful lot higher than the % of sources about Trump that mention his red tie.
I mostly agree with Leave out the trivia; just say "three firearms" or "a handgun" or "an AR-15–style rifle". Don't say "Smith & Wesson M&P15 Sport III with laser sight, adjustable stock, and free-float handguard in black" – unless the sources indicate that there is something specific about one of those details that actually matters - for that level of detail, yes, we need a reason to include it. That's not what this section is about -- at least not from the top -- which is about naming the brand/type. So I see the Charleston church shooting article as more or less the way to go: opened fire with a Glock 41 .45-caliber handgun. Don't know why we'd need more than that, but doesn't see a reason not to include that. — Rhododendrites talk \\ 13:27, 5 September 2025 (UTC)[reply]
Why do we need more than "handgun"? What encyclopaedic information does the manufacturer or calibre convey? What (according to reliable sources) difference did it make to the event and/or outcome that it was a Glock handgun vs any other manufacturer's handgun? Thryduulf (talk) 13:40, 5 September 2025 (UTC)[reply]
The main answer is that it's the same as any other little detail, like I said above. It's encyclopedic because we tend to defer "what's encyclopedic" to the prevalence of details in coverage of a story elsewhere, not because "Thryduulf and Rhododendrites say it's encyclopedic". But more directly, exactly what it communicates will vary. There's a lot that's communicated in saying that someone used a Beretta Model 93R vs. a Colt Single Action, which are both "handguns". The media often mention the type knowing about metacommentary about certain gun types and mass shootings. Mentioning it being an AK-47 puts the event in the context of other AK-47-related shootings. Certain models are commonly used in high-profile crimes and have become culturally or politically significant because of the broader context of these events, even if not mentioned in detail. Censoring such information when there's obviously relevance to the event just seems like advocacy to me. I don't know if I'm saying anything new, though, so I don't plan to follow up on this further. — Rhododendrites talk \\ 14:23, 5 September 2025 (UTC)[reply]
Apparently, we have decided that the Glock 41 isn't a notable handgun model; editors have decided that it deserves a mere 41 words' worth of description in Wikipedia.
I asked Mr Google how many Ghits it would give me for Charleston church shooting -wiki -wikipedia. It said 2.73 million. I then asked how many ghits for the same thing, only with "Glock 41". It said 557. That means that only 1/5,000th of sources mention the model.
Looking only at news articles, the ratio is 68,500:9 – only 1/7,600th of news articles mention the model.
Asking it to compare news sources mentioning "Glock" but not "Glock 41" and vice versa was interesting; 810 mention the company without the model number, and 271 mention the model number but don't mention the company separately.
That doesn't make me think that we've made the right choice in this article. Most sources don't mention either the brand or the model, so why are we mentioning both? Most sources that mention either the brand or the model mention only the brand and not the model, so why are we making the less common choice? That doesn't really look like "following the sources" to me. WhatamIdoing (talk) 22:34, 5 September 2025 (UTC)[reply]
My meta comment. Ok to continue within if meta makes you sexually aroused. Call me! ―Mandruss ☎ IMO. 01:49, 5 September 2025 (UTC)[reply]
Not at all. The problem is a widespread practice that (many editors believe) does not serve the encyclopedia or its readers—a perfectly fine use for this page and/or WP:VPR. Now I'll use this opportunity to hold forth (again). Outside of my user space, places like this are the only places I'm allowed to write essays, these days. (Inside joke between me and myself.)
I've spent considerable time at many of these articles and I'm quite confident that most of the editors adding this kind of information are firearms aficionados who are not in good positions to evaluate its value to the reader community. They assume, quite incorrectly, that readers will be interested because they are. Local consensus is a great thing, over all, but it hardly makes sense when the content is justified in perhaps 5% of affected articles. And the average local group very often makes decisions counter to the interest of the overall encyclopedia, sorry. Local consensus is not compatible with site-wide consistency, which is sometimes a worthy goal. The two can coexist as well as fire and water can (they can't coexist at all, for those playing at home).
In my view, en-wiki's editing community needs to get down off the fence and take a position, one way or the other. How much do we care about site-wide consistency, when all is said and done? Where is the correct balance? We need to be on the same page with this, at least a strong majority of us. We need to form a community consensus on this meta issue, and then for God's sake write it down, concisely and coherently, and make that easily accessible to ordinary editors (sounds like a WP:WIKICONSIST policy to me).
All guidelines allow for well-reasoned rare exceptions by definition of the word "guideline" (and WP:IAR). If tens of thousands of editors don't understand this, I say we should get started educating them, not try to accommodate them in defensive mode. It is not a difficult concept, it just requires some committed outreach by the community (call it a campaign if that works for you). Take more community control of the damn thing, for the betterment of English Wikipedia and the furtherance of world peace. (Strangely, our friend Donald Trump concurs, with three smiley emojis, two thumbs up, one userbox, one barnstar, and a partridge, sporting the Trump brand, in a pear tree. "Stop farting around and do something!!!!!!", he wrote. "And charge it to 'world peace', or something. Americans eat that stuff up! Idk about those foringers you got hangin around there. Buy more shovels and covfefe!" Now I'll be up all night.)
This does not come down to IDLI, as evidenced by this large discussion teeming with arguments for and against the proposal. If one has no position one way or the other, there's no need to comment. ―Mandruss ☎ IMO. 23:17, 4 September 2025 (UTC)[reply]
  • Doesn't the firearm brand and model fall under 'trivia' in some way? Unless the brand/model is widely reported in RS, it seems the same to me as including the color or brand of the perp's shirt or shoes, etc. Some1 (talk) 18:08, 5 September 2025 (UTC)[reply]
    I agree, but I think that the difficulty is in whether "widely reported" means "mentioned in a large fraction of sources" (10 mention it, out of 30 total sources) vs "mentioned in a tiny fraction of a very large number of sources" (10 mention it, out of 300 total sources). WhatamIdoing (talk) 22:36, 5 September 2025 (UTC)[reply]
  • I agree that this information is generally undue. Unless the type of firearm is specifically notable in and of itself (i.e. calls to restrict the usage of said firearm, or WP:SIGCOV specifically about the firearm type), this is undue excessive information for the average reader. WP:TECHNICAL applies here, aside from any concerns over copycat shootings. This should be covered by WP:DUE (policy) and WP:FANCRUFT (essay), but having something spelling this out in full will prevent editiors from adding this minutiae to an unfortunately commonplace and ever-growing category of articles without consensus. GnocchiFan (talk) 10:02, 7 September 2025 (UTC)[reply]
  • I was one of the editors involved in some of the firearms/crime inclusion/exclusion debates from about 10 years back. I think it's interesting that some argue that pro-firearms people want to include make/models in the articles about the crimes. That was never my impression but that may indicate just how big the gap in perception was/is. We are all looking at the same picture yet seeing something that is so different. Certainly a good argument for AGF! My concern then was the feeling that an article about the firearm was often becoming an article about crimes. This is around the time I challenged the idea that WEIGHT has reciprocity. That is if A has weight in context of subject B, does B have weight for inclusion in the article about A? My view is no and at least one well attended RfC I was involved with supported that view. As for including model name/number in an article about the crime, my feeling is that should be decided by weight in sources about the crime. In general, I agree with those who feel such details aren't, in most cases, encyclopedic and inclusion shouldn't be assumed. I'm sure there are cases where more detail is warranted and I'm sure RS can help us establish weight for inclusion. I would also suggest that we shouldn't have any blanket MOS on this content. I don't think the MOS should, as a general rule, govern article content outside of perhaps the intro material in things like BLP. How such content is displayed, sure, but not what is included/excluded and certainly the deeper into an article the less the generic MOS guidelines would apply. That said, absent a specific source review/details, I would generally favor leaving make/model out of articles about the crime. Springee (talk) 13:32, 7 September 2025 (UTC)[reply]
    We are all looking at the same picture yet seeing something that is so different. This is unusual? Otherwise, good comment. ―Mandruss ☎ IMO. 14:58, 7 September 2025 (UTC)[reply]

Edit tools for canonical forms

[edit]

There are situations where WP:MOS specifies a format or where a format is consistently used in an article, but data from an external source are in a different format. It would be convenient to have tools in the wikisource and visual editors to transform those data to a canonical form. Examples are:

  • Transform selected date to article default or to explicitly specified format.
  • Translate upper case title to sentence case or title case

The transforms need not be perfect; even if manual tweaking is needed, they would still save time. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:23, 3 September 2025 (UTC)[reply]

The {{Date}} template performs transformations of dates. Template:Case templates table lists some case-transformation templates. Sentence case and title case are not in this list, though. It's not hard to make a simple version work most of the time, but there are exceptions (like dealing with upper case abbreviations) that would be hard to handle without maintaining an exhaustive list of them. isaacl (talk) 16:03, 3 September 2025 (UTC)[reply]
I was thinking of editing tools rather than templates. A tool for title case shouldn't require manual fixup of more than a few letter except where there is an initialism. A tool for sentence case would only need manual fix-up for initialisms and proper nouns. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:41, 3 September 2025 (UTC)[reply]
Sorry, when you said data from an external source, I was thinking it would be transcluded into the article through some mechanism, and so passing it to a template for formatting would fix it up automatically. isaacl (talk) 21:57, 3 September 2025 (UTC)[reply]
Maybe take a look at AWB and AutoEd — GhostInTheMachine talk to me 06:47, 4 September 2025 (UTC)[reply]
The two tasks I'm most concerned about are
  • Convert a selected date to the appropriate format for the article, including
    • Month Day, Year
    • Month Year
    • mm/dd/yyyy
    • ISO
  • Change the case of a selected string to
    • Upper
    • Lower
    • Sentence
    • Title
The two tool mentioned look usefull for bulk edits, but not for those two tasks. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:11, 4 September 2025 (UTC)[reply]
In all the cases you mention, changes must be made with care and human attention because context matters massively. There are many examples where articles should contain mixed usage of dates/cases, including articles discussing different formats, quotes, and instances where case changes the meaning of a term. Thryduulf (talk) 16:12, 4 September 2025 (UTC)[reply]
For date conversion, substituting the {{Date}} template is a workaround you can use. Unless someone implements a case-changing feature, the only workaround I can think of is to use your favourite external text editor's case-changing feature. (Google Docs, for example, has a capitalization sub menu under Format → Text.) isaacl (talk) 16:56, 4 September 2025 (UTC)[reply]
This, frankly, is the use case for developing some form of AI-assisted editing, to find and prompt edits for likely instances of overcapitalization and incorrect date presentation. BD2412 T 17:03, 4 September 2025 (UTC)[reply]
The dates I'm concerned with are in correct formats but not consistent with other dates in the same article. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:34, 4 September 2025 (UTC)[reply]
The documentation for Template:Date says This template should only be used internally in other templates.
Yes, I sometimes use an external editor for long uppercase titles; I copy them into Tritus SPF (TSPF), use the lower case (LC) line command, over-type individual letters that should be capitalized, insert hyphens to indicate explicit line breaks, use the text flow (TF) line command to remove extraneous line breaks, remove extraneous hyphenation and copy the text back. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:34, 4 September 2025 (UTC)[reply]
By substituting the template contents, the transformed results are saved to the page, so you won't actually be using the template within the wikitext source. isaacl (talk) 23:47, 4 September 2025 (UTC)[reply]
@Chatul, I'm not understand what you're trying to accomplish. I see your suggested solution, but what's the specific problem itself? For example, here are two different stories:
  1. As a WikiGnome, I'd like to tweak the existing article content so that the dates and capitalization are correct. It would save me time and effort if I could select AN ALL CAPS TITLE in an existing citation template, click a button in the toolbar, and have it transformed into sentence case or title case (whichever is appropriate for the individual article's style).
  2. As an article creator, I frequently add citations to articles. It would save me time and effort if automated citation tools such as Citation bot or mw:Citoid would correct the capitalization when automatically generating the citation.
Your story might be different, of course, but it'd help if you gave me something concrete to think about. WhatamIdoing (talk) 17:26, 4 September 2025 (UTC)[reply]
My specific problem is the second: creating a citation from an online PDF document, doing cut-and paste for, e.g., date, title. I normally use the source editor rather than VE. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:34, 4 September 2025 (UTC)[reply]
(PDFs are the worst.) If the date is a common form, and you're using a CS1 citation template, then they'll display the date in the correct format. That is, if the article has {{use dmy dates}}, but you paste "2025-09-01", it will display "1 September 2025" to the readers. Eventually, someone running AWB will "correct" the wikitext, but you don't usually need to worry about the dates.
Capitalization can't be handled that way. You may remember participating in the RFC about preserving mismatched "found state" capitalization (which concluded that mismatched capitalization does not deserve the protection of WP:CITEVAR). But you may have forgotten that someone in that discussion said there is a user script that converts to title case. I understand that it's fairly easy to turn a user script into a button inside the 2010 wikitext editor. Maybe you could ask at VPT for someone to do that? WhatamIdoing (talk) 20:28, 4 September 2025 (UTC)[reply]
User:ZKang123/TitleCaseConverter puts a menu item in the "Tools" menu that I believe will make changes to the edit box for the wikitext editor (not sure if it will work with Visual Editor). (I see in the source that it has a list of manually maintained exceptions, as I mentioned would be necessary.) isaacl (talk) 23:58, 4 September 2025 (UTC)[reply]
The code for inserting a button in the 2010WTE toolbar vs in the VE toolbar is different, so I always assume that a script will not work in both. So far, my assumption has never been proven wrong. WhatamIdoing (talk) 02:17, 5 September 2025 (UTC)[reply]
Sure; I wasn't commenting on how to add a button to the toolbar. Since the original poster typically uses the wikitext editor, they might find the current user interface sufficient. isaacl (talk) 02:22, 5 September 2025 (UTC)[reply]

Promoting WP:DRAFT?

[edit]

So I've been thinking about this for a bit on how almost all other projectspace pages on namespace are listed as guidelines (i.e WP:Template namespace), however Wikipedia:Drafts is still only an essay. I've read through it and I'm not seeing any glaring issues, and some points made a few months ago at Wikipedia talk:Drafts#Promotion to Guideline? make me wonder if it should be promoted to a guideline soon. Are there any barriers in the way preventing this? Sophisticatedevening(talk) 00:18, 5 September 2025 (UTC)[reply]

Do we really need it to have a {{guideline}} tag at the top? What changes, if any, do you think would happen in editor behavior, if a WP:PROPOSAL were successful? WhatamIdoing (talk) 02:21, 5 September 2025 (UTC)[reply]
From what I've seen (a comment somewhere that I cannot remember for the life of me) some people do seem to disregard things like WP:DRAFTIFY, citing that it is only an essay and they don't have to follow things like WP:DRAFTNO. And while on one hand they're technically right, I see a far greater attitude with it being treated as a de-facto guideline in that it should generally be followed. I also see it mentioned in things like the policy WP:ATD-I, so I think it would be helpful to gauge what a more broader community thinks it, and settle things like that in the future with a documented community support for it. Sophisticatedevening(talk) 02:35, 5 September 2025 (UTC)[reply]
Or documented community opposition, or documented community division. Not every PROPOSAL results in a determination of support. WhatamIdoing (talk) 04:40, 5 September 2025 (UTC)[reply]

IPs shouldn't be allowed to create drafts

[edit]

Just came across an IP editor who is trying to get some articles into mainspace: 1 2 3 This editor has been making good faith contributions and I would like to help them, I just can't. Their IP keeps changing all the time so it is impossible to have any kind of communication with the editor. Communication is required. The editor won't even see that their drafts have been declined or why. TurboSuperA+[talk] 06:24, 5 September 2025 (UTC)[reply]

It's an unfortunate loss that the IP in question has a dynamic account, but one incident is not a strong case for such a large change. Some IPs are relatively stable, and some IP editors do check back on places, allowing for some communication. I'll add some welcome templates, just in case they work. CMD (talk) 06:36, 5 September 2025 (UTC)[reply]
I wonder if IPv6 addresses could get a unified Talk page for the subnet. Someone correct me if I'm wrong, but I think that usually all IPv6 addresses on the /64 subnet are assigned to the same household. TurboSuperA+[talk] 07:01, 5 September 2025 (UTC)[reply]
Yes, this is true; a /64 is one household.
Also, I managed to create a talk page for a /64 subnet (User talk:2600:4041:5CE9:B300:0:0:0:0/64) somehow, so it's definitely possible, but I'm not sure if the IP editor actually got the message I left there. SuperPianoMan9167 (talk) 22:07, 5 September 2025 (UTC)[reply]
I might also have created a talk page for a nonexistent user, but that seems unlikely since the talk page does indeed show up in block logs for the IP range.
When temporary accounts are deployed, I think that much of the issues currently affecting IP users will be addressed (for example, the confusion caused by dynamic IP allocation and the inability to ping IP editors). SuperPianoMan9167 (talk) 22:11, 5 September 2025 (UTC)[reply]
(Sorry for the broken-up replies) @TurboSuperA+: try creating User talk:2001:1970:49DE:8C00:0:0:0:0/64 directly and see if the user gets the message. SuperPianoMan9167 (talk) 22:14, 5 September 2025 (UTC)[reply]
So there is a talk page for the /64! Thanks for this. TurboSuperA+[talk] 07:35, 6 September 2025 (UTC)[reply]
IP4 editors often have a stable IP address, but IP6 from mobiles tends to change much more. I assume that the imminent rollout of temporary accounts will reduce this issue and allow more viable feedback to the user's talk page — GhostInTheMachine talk to me 07:04, 5 September 2025 (UTC)[reply]
That doesn't explain how the temporary accounts will work. If the temporary account is tied to an IP address, then doesn't that mean that the username will change when the IP changes? TurboSuperA+[talk] 07:07, 5 September 2025 (UTC)[reply]
The system adds a cookie so that the returning user can be identified as a previous IP editor — GhostInTheMachine talk to me 07:19, 5 September 2025 (UTC)[reply]
The temporary account is tied to a browser cookie and not an IP address. The same temporary account can have edits made using multiple IP addresses (which will solve a lot of the confusion regarding IP editors on a /64). The only caveat is that the temporary account, being temporary, only lasts for 90 days or until the cookie is deleted. SuperPianoMan9167 (talk) 21:57, 5 September 2025 (UTC)[reply]
Isn't one of the primary rationales for draft space existing to allow unregistered editors to create drafts? In any case, unimproved drafts are deleted after six months, so there is no inherent cost to the project to allow such creation. BD2412 T 22:20, 5 September 2025 (UTC)[reply]
There is always an inherent cost in volunteer time. The theory is that it is made up for in the volunteer time that can be contributed by unregistered editors. My off-hand suspicion is that for any non-llm drafts that theory holds up quite well, for example the drafts created by the IPs here feel like they have potential to form content even if not as standalone articles. CMD (talk) 00:29, 6 September 2025 (UTC)[reply]
Anonymous ip should not be allowed too post at all IMOH. Jp33442 (talk) 00:32, 6 September 2025 (UTC)[reply]
the drafts created by the IPs here feel like they have potential to form content even if not as standalone articles.
Exactly! TurboSuperA+[talk] 07:36, 6 September 2025 (UTC)[reply]
Allowing unregistered editors to created articles is the reason that Wikipedia:Articles for creation exists.
The Draft: namespace exists because a WMF staffer thought it would be a good place for collaboration. It turns out that he was wrong. WhatamIdoing (talk) 20:18, 6 September 2025 (UTC)[reply]
You've said that about the draft namespace before. As I believe I've already pointed out to you, the draft namespace was proposed by an English Wikipedia user (then TheOriginalSoni, now just Soni) at the proposal village pump and received community consensus. isaacl (talk) 04:01, 7 September 2025 (UTC)[reply]
The idea did not originate in that RFC. WhatamIdoing (talk) 06:05, 7 September 2025 (UTC)[reply]
The point is that it was proposed and discussed within the English Wikipedia community. It wasn't created because one WMF staffer thought it was a good idea. isaacl (talk) 17:58, 7 September 2025 (UTC)[reply]
The editor won't even see that their drafts have been declined or why. They can see that for all of the drafts that have been declined by looking at the draft, for example Draft:Visarion II, Metropolitan of Cetinje. Generally, the draft's talk page should be the place where any discussion about the content is held. —Kusma (talk) 09:46, 7 September 2025 (UTC)[reply]
With temporary accounts soon to be implemented, it seems that the communication issue will be resolved (as they are not tied to individual IPs but to browser cookies), so I don't think there will be much to worry about. Chaotic Enby (talk · contribs) 13:36, 7 September 2025 (UTC)[reply]

AI Moderator proposal

[edit]
Moved from Wikipedia:Administrators' noticeboard § AI Moderator proposal
 – voorts (talk/contributions) 12:47, 5 September 2025 (UTC)[reply]

On Reddit, there is a very useful extension called AI Moderator (AI Moderator | Reddit for Developers). It allows users to configure rules (eg "remove the post if it is spam") and the AI will evaluate the comment/post to see if it meets the criterion. I am thinking of bringing a similar system here, with the following notes:

  • This is distinct from the WMF-developed mediawikiwiki:Moderator_Tools/Automoderator and ClueBot in a key way - the former is binary "revert/don't revert", while this proposal allows authorised wiki users to set up custom rules that need not be pure "vandalism". I think this can be very useful for some of the chronic LTAs that tend to obfuscate whatever they want to say.
  • On the Reddit system, only Gemini/OpenAI are supported. The proposed system will only use open-source AI (eg the 1b/4b Gemma models, to keep speed reasonable) running on Cloud VPS. I am expecting up to 60 seconds' delay before the system reverts a flagged edit, but this is subject to change.
  • This proposal complements and does not replace the current edit filter system.

I'm hence requesting feedback from the community on whether this is something they'd like to have on this wiki, or whether I've missed something (eg someone has already developed a similar tool). Please ping me in a response. Leaderboard (talk) 08:53, 5 September 2025 (UTC)[reply]

No, we don't want AI bullshit-bots 'moderating' anything around here. We have enough problems with their hallucinatory garbage already. AndyTheGrump (talk) 09:02, 5 September 2025 (UTC)[reply]
@Leaderboard What problem faced by the English Wikipedia would this solve? I don't see the need for this; our talk pages are generally quite civil, and when they are not, the best solution is usually warning the offender, not removing the post outright. Toadspike [Talk] 09:21, 5 September 2025 (UTC)[reply]
@Toadspike A few that come to mind:
  • LTAs that obfuscate or otherwise exhibit behaviour that is difficult to handle using edit filters (eg MidAtlanticBaby). AI tends to be significantly better from my experience, and this should reduce the need to constantly update the filter and should also reduce false positives.
  • Complex requests that cannot be easily handled by a filter or where a high risk of false positives exist. For example, determining the intent of a comment or edit to a page, or verifying a source for an article that a user added.
  • As Tamzin said, it can be useful as a first-stage log.
Leaderboard (talk) 09:45, 5 September 2025 (UTC)[reply]
While there's obvious pitfalls, I could see some use in integrating an LLM into AbuseFilter for log-only filters. A filter that can track, for instance, "Did this edit change a date of birth without changing/adding a citation?" or "Does this edit look like it's trying to convey the same message as some recurring LTA rant?" would be useful. Anything "AI moderator"-like, though, is a complete nonstarter. The actual moderation decisions need to be made by humans. -- Tamzin[cetacean needed] (they|xe|🤷) 09:30, 5 September 2025 (UTC)[reply]
I agree to this. There is no way we get the consensus for AI actioning on stuff, but it works be useful if does some work of scouting for bad edits and notifying volunteers (interested ones) through either a separate platform on toolforge or integrated with edit filters. ~/Bunnypranav:<ping> 09:40, 5 September 2025 (UTC)[reply]
My perspective is different, especially given that the wiki is already making use of (or was - not sure) similar automated tools, such as ClueBot. Having tested this with multiple subreddits (not the same as this wiki, but still), I can say that AIModerator should be effective as a first-stage defense for many types of common undesirable edits. Yes, there can be false positives, but that's true with an edit filter or ClueBot as well.
And also: the same development process as for an edit filter applies here - eg first by logging the edits, then warning the user, and then disallowing. So there's enough opportunity to test the effectiveness of the filter. Leaderboard (talk) 09:49, 5 September 2025 (UTC)[reply]
I should add that this proposal is unquestionably misplaced on this noticeboard: if AI is ever to be introduced for any function similar to that proposed, it will require the assent of the broader community, after first (a) having clarification as to what problem it is supposed to be solving, (b) seeing evidence that it is capable of solving (or ameliorating) said problem, and (c) an appropriate period for discussion. AndyTheGrump (talk) 09:46, 5 September 2025 (UTC)[reply]
There are similar initiatives (eg. Wikipedia:Edit check/Tone Check), but AndyTheGrump is right that this is the wrong location, and I would further add that any proposals should be much more specific. CMD (talk) 09:48, 5 September 2025 (UTC)[reply]
@Chipmunkdavis and @AndyTheGrump Apologies, can you then move this to the right place? I was under the impression I had to solicit feedback here from past experience. Leaderboard (talk) 09:51, 5 September 2025 (UTC)[reply]
Based on how I am reading it, VPP and AN were the two best options for your Leaderbot proposal regarding temp rights. This case is different as it doesn't really deal with anything that is related to administrators in general.
(While I am commenting, you might want to review WP:AI since it covers past AI proposals and more.) --Super Goku V (talk) 10:43, 5 September 2025 (UTC)[reply]
@Super Goku V "This case is different as it doesn't really deal with anything that is related to administrators in general" - actually it does as admins (and other trusted users to be defined) are the ones going to be configuring the system. Leaderboard (talk) 11:00, 5 September 2025 (UTC)[reply]
No they aren't. Not without prior community approval of any such addition to admin (or other 'trusted users') rights/responsibilities. Leaderboard, I'm going to be blunt here. You have only made 500-odd edits to Wikipedia, less than half of which are in article space. You clearly have little idea as to this place works. You appear to be making a proposal of which you have yet to either define properly nor demonstrate an actual need. You are now apparently telling us who exactly gets to 'configure' this AI-bot. That isn't how it works. In my opinion, you would do well to drop this proposal, along with any other bot proposals, until you actually have the necessary experience as a normal editor to understand what we actually need, and how to appropriately ask for approval. AndyTheGrump (talk) 11:17, 5 September 2025 (UTC)[reply]
@AndyTheGrump Are you serious? I may not be familiar with en.Wikipedia policies, but I'm a fairly experienced global editor (check my CentralAuth), admin on multiple wikis, and also have an approved bot on this wiki. I also regularly work with wikis where I have little to no experience. Just because I come up with an idea does not mean that it's going to happen or that I am "unqualified". After all, I've been clear from the beginning that this is a proposal, and things like these, especially when they involve significant development work, absolutely do not need to be "properly defined" at this stage. Your criticism would be better placed if I were to just go to WP:BAG and ask for bot rights. P.S: other users, like Anomie, have provided appropriate criticism and suggestions without feeling like I'm being insinuated, and that's what I'm looking for. Leaderboard (talk) 13:39, 5 September 2025 (UTC)[reply]
Just confirming, Leaderboard has over 17,000 edits distributed across dozens of wikis (but mostly from their top half dozen) over an eleven year period, and has sysop rights on multiple projects. BD2412 T 18:52, 5 September 2025 (UTC)[reply]
@Leaderboard: The strong negative reaction your proposal is receiving here (and the feelings of insinuation) might be explained by the fact that the English Wikipedia appears to be the Wikimedia project that is the most vocally critical and skeptical of generative AI and LLM usage. To give an example, WikiProject AI Cleanup, a WikiProject I am a member of that aims to find and clean up unreviewed LLM-generated content, only exists in two languages: English and French. The English WikiProject has 173 participants, but its French counterpart fr:Projet:Observatoire des IA only has 17. (Both figures are as of writing this comment.) SuperPianoMan9167 (talk) 22:33, 5 September 2025 (UTC)[reply]
If you didn't know, enwiki also has a recently-created speedy deletion criterion, G15, that specifically applies to unreviewed LLM-generated content. Many proposals about AI-powered features on enwiki have received considerable pushback; there's a list of current and past discussions that you can read here if you're interested. SuperPianoMan9167 (talk) 22:43, 5 September 2025 (UTC)[reply]
@SuperPianoMan9167 And that is OK. Hence why this discussion - I also plan to do this with other wikis to see what their stance on this is. Leaderboard (talk) 04:24, 6 September 2025 (UTC)[reply]
@Chipmunkdavis this is a very early-stage proposal so the lack of specifics is natural. We'll get there as I get feedback - feel free to ask any clarifying questions in the meantime. Leaderboard (talk) 09:52, 5 September 2025 (UTC)[reply]
Wikipedia:Village pump (idea lab) is probably a better place for this discussion. — rsjaffe 🗣️ 09:56, 5 September 2025 (UTC)[reply]
I agree, this noticeboard is more for recent disruptions on the project. 98.235.155.81 (talk) 10:03, 5 September 2025 (UTC)[reply]
Tone check does not use a LLM. The term "AI" is heavily overloaded. * Pppery * it has begun... 16:13, 5 September 2025 (UTC)[reply]
The tone check page claims it uses a SLM, which doesn't seem much of an overload from LLMs at all. CMD (talk) 00:22, 6 September 2025 (UTC)[reply]
Regarding Tone Check, I wonder if the "AI Moderator" can review the tone of editors' talk page comments and give them a "friendly reminder" to be more civil if their comments are deemed overly aggressive or unfriendly. Not saying it's a good idea, but it's an idea. Some1 (talk) 18:21, 5 September 2025 (UTC)[reply]
I find the idea of an "AI moderator" policing the tone of human beings to be intrinsically offensive. Stepwise Continuous Dysfunction (talk) 23:25, 5 September 2025 (UTC)[reply]
I am deeply against the idea of such a chatbot "moderator". Also why is this posted in this forum at all? Simonm223 (talk) 11:22, 5 September 2025 (UTC)[reply]
@Simonm223 your question is being discussed directly above. Thryduulf (talk) 11:35, 5 September 2025 (UTC)[reply]
Absolutely not. This would just create massive amounts of problems and not solve anything. We already have more than enough AI nonsense on this site as it is. 2A0E:1D47:9085:D200:EF8D:3F1F:719E:C21C (talk) 11:37, 5 September 2025 (UTC)[reply]
As seen above, I doubt there will be much acceptance at all of a new LLM-based AI actually reverting things. User:ClueBot NG does use machine learning, but it's a well-established and carefully developed system specific to Wikipedia maintained by people who have been active in the community for a long time, not a "LLMs are the new Blockchain, let's use them in everything" idea. You might do better to look into a classification system that humans can use as input, similar to mw:ORES and the successor that's being worked on, rather than trying to jump straight to an LLM-based bot. Anomie⚔ 12:33, 5 September 2025 (UTC)[reply]
It's worth pointing out that some smaller wikis do use mw:Extension:AutoModerator which works using the ORES system. * Pppery * it has begun... 16:13, 5 September 2025 (UTC)[reply]
The only response this deserves is trout Trout signed, Rosguill talk 16:17, 5 September 2025 (UTC)[reply]
I utterly disagree, based on the actually sensible discussions occurring in this section of what sort of parameters we could use as guardrails for such a tool. BD2412 T 18:41, 5 September 2025 (UTC)[reply]
To the extent that this is a proposal to use a LLM to populate a list of potentially problematic edits for a human sysop to review, I think it's a really good idea and I hope you go ahead. We might eventually get to the stage where human sysops experienced with the AI's output are prepared to recommend a trial of a bot to run it (or to exapt ClueBot NG to do so).—S Marshall T/C 16:54, 5 September 2025 (UTC)[reply]
A simple question: why would we need a separate bot for this anyway? Wouldn't it make more sense (if it is actually feasible, solves a real problem, and is accepted by the community) to add such AI-driven functionality to ClueBot NG? AndyTheGrump (talk) 17:06, 5 September 2025 (UTC)[reply]
Same as why I am not recommending that such functionality be added to the AutoModerator project by WMF. That is, I see them as complementary - handling related but distinct tasks. Leaderboard (talk) 18:08, 5 September 2025 (UTC)[reply]
ClueBot NG is a trained neural classifier, and its codebase appears stable and largely unchanged in a while. I'm not even sure if it's regularly retrained. LLM-based AI should probably be a different bot altogether, as it's sufficiently different technology. It definitely shouldn't run under the same bot account. ProcrastinatingReader (talk) 10:25, 6 September 2025 (UTC)[reply]
@Leaderboard, what if you run a trial of the tool where no edits are made by the bot and its flagged changes are examined? JayCubby 18:11, 5 September 2025 (UTC)[reply]
@JayCubby At a later stage. This will only be once the specification has been designed (after getting feedback from different communities, like what we're having now) and I develop a working POC (proof-of-concept). Leaderboard (talk) 18:14, 5 September 2025 (UTC)[reply]
I see no reason why this would be trustworthy, and three or four reasons why it wouldn't be ethical. Even using this to create a list of edits for humans to review would bias our moderation priorities towards what the slop machine says is important. That's not a burden we need. Stepwise Continuous Dysfunction (talk) 23:24, 5 September 2025 (UTC)[reply]
No, absolutely not. SCD gives a good reason. Another is simple: we're busily fighting off AI being used to edit articles. Even if this could be ethical and useful, giving AI promoters a "but you use AI!" argument to use is not something we need to do. - The Bushranger One ping only 00:13, 6 September 2025 (UTC)[reply]
I find that an absurd line of reasoning. We use bots to revert spambots. It does not give spambot promoters a "but you use bots!" argument. – SD0001 (talk) 11:07, 7 September 2025 (UTC)[reply]
I think the first mistake was to use the word "moderator", especially in conjunction with the word "AI". By doing so, you're going to get kneejerk opposition. (I was expecting something far more dubious when I saw the section title.) To be honest, a variant of this idea might actually be a useful tool in combating vandalism. If it worked well, it would help us better use anti-vandalism editor labour. Technically, I'd imagine it'd need some finetuning, and for some LTAs the nuance may be too specific or the false positive rates unacceptable, but so long as it can distinguish well and the precision is sufficiently high, then it's hard to argue against adopting this technology, except perhaps on a cost basis, but those would be considerations for the Cloud VPS teams.
If you wanted to pursue it, if I were you I'd coordinate with anti-vandalism editors and/or SPI to figure out where it'd be most useful, with Cloud VPS to figure out if you have the GPU compute needed to run open source models for inference, and probably editors interested in AI/ML with some free time if you needed technical assistance on model building. VPI is probably the wrong audience for brainstorming this. ProcrastinatingReader (talk) 10:25, 6 September 2025 (UTC)[reply]
My Cloud VPS allocation right now is 8 cores/32 GB RAM, which should be enough for smaller models. Things like GPU can come later, but @ProcrastinatingReader I'd appreciate if you could crosspost or otherwise notify users that are likely to be interested in this. Leaderboard (talk) 11:04, 6 September 2025 (UTC)[reply]
Most LTAs trying to game edit filters end up getting reverted almost instantaneously for vandalism/disruption even if they aren't identified as socks immediately. In any case the tool should not be making the reverts by itself. I could see something on the lines of what Tamzin proposes for more complicated conditions that can't be straightforwardly handled by regex; but I'm not sure that ends with a manageably-sized list of problematic edits. My thinking tends a bit towards WP:BROKE for now, but I doubt a trial would cause any harm either. For all I know the list of flagged edits could end up being manageably small after all. JavaHurricane 16:24, 6 September 2025 (UTC)[reply]
Strong support an easily reversible 60-day trial. Work out the details of said trial (config details etc) amongst yourselves. Strong oppose crystal ball reasoning, on principle. Those balls are unreliable and overrated, basically quackery. Strong abstain (lol) if trial would not be easily reversible. ―Mandruss ☎ IMO. 16:51, 6 September 2025 (UTC)[reply]
I see I'm the only one using bolded !vote format, suggesting it's improper for VPI. Not sure what to do with that. I'm just trying to voice my strong support for trials over crystal, which applies to any idea that's somewhat viable. There is way (did I mention way?) too much risk-aversion at en-wiki for the encyclopedia's good. Most reliable way to determine whether something will be a net improvement: Try It And See™ (TIAS).
Consider if you will a fictional big pharma company. Their scientists have created a new medication and the company needs to decide whether to put it on the market, ie release it for sale. It hasn't undergone any trials, since the company has twenty really smart, experienced people who are certainly capable of deciding among themselves whether it's safe. Trials would be an unnecessary waste of time. Today, those twenty are seated at a conference table, discussing the question. Is this wise?
No.
So, what, en-wiki is different because we don't develop drugs that could maim or kill people? I truly don't see why that would make a difference. In reality, the company knows they can't really know until they... wait for it... Try It And See™. They know this because they have twenty really smart, experienced people. So they schedule the TIAS to begin in 14 days and last for 60 days. Then they adjourn the meeting. ―Mandruss ☎ IMO. 17:18, 6 September 2025 (UTC)[reply]
Where would you suggest that discussion take place instead of VPI? WP:LLMN? WT:EF? Or some other noticeboard or talk page? SuperPianoMan9167 (talk) 19:24, 6 September 2025 (UTC)[reply]
1. I wouldn't know. 2. When did I say there should be a "that discussion"? lol. 3. I laid down my argument and others are free to pick up that ball and run with it. I'm happily semi-retired so I would be a no-show. ―Mandruss ☎ IMO. 19:32, 6 September 2025 (UTC) Edited per discussion. 20:12, 6 September 2025 (UTC)[reply]
I was interpreting "that" as a relative pronoun ("I know that I like books) instead of a demonstrative ("I like that book"); I was talking about further discussion that would take place developing this idea. I probably could have worded it better :)
The more I learn about other languages, the more confusing and nonsensical my native language (English) seems. SuperPianoMan9167 (talk) 19:44, 6 September 2025 (UTC)[reply]
LOL. That's crazy. I've never seen that happen in my 69 years. No, don't blame yourself even a little. English is a crazy language, far below the state of the art, and needs to be replaced by Esperanto. Is this the right place to propose that? :D Ok, so I'll fix that. ―Mandruss ☎ IMO. 20:12, 6 September 2025 (UTC)[reply]
This sounds interesting, but we should first figure out what the parameters (and especially the success criteria) are for the experiment. If we start a trial, and have a high rate of spam getting reverted, but also some amount of good-faith comments getting reverted, then should we accept it as a success? Invariably, this is – to some extent – what we will see: some true positives, some false positives, and some false negatives.
The other difference with your big pharma example is that trials usually aren't done on the whole live population. Having a smaller test case on which we could run the trial for 60 days could be much better, avoiding the risk to either Wikipedia's reputation or editor retention.
For now, we don't have all of that. A controlled trial isn't just "let's run the proposal for 60 days", especially since we don't have a single proposal – do we directly import the "AI Moderator" tool with an open-source model? Do we fine-tune it, give it specific prompts? Do we train smaller models on specific cases (as was suggested below)? All of this has to be known in order to be able to Try It And See. Chaotic Enby (talk · contribs) 13:22, 7 September 2025 (UTC)[reply]
Here's my thoughts: this feature should probably be tested as a client-side, on-demand feature only, perhaps as a gadget or user script that makes API calls to an LLM. The advantage of this approach is that those users who are interested in this kind of tool and would like to test it are able to do so, while those users who oppose the tool are not forced to use it. It's best to not set up stuff like this server-side without obtaining broad community consensus. I do see the merits of this proposal for identifying sneaky LTAs that are able to figure out how to bypass regex in filters, although like current filters, this feature would definitely have some false positives. If this proposal moves forward, I would recommend developing it more as a way to "improve abuse filter detection with machine learning" rather than act as an "AI moderator", as calling it an "AI moderator" may drive away users who would otherwise support the idea. As already mentioned, Wikipedia already uses some machine learning for anti-abuse workflows, most prominently in ClueBotNG. SuperPianoMan9167 (talk) 19:24, 6 September 2025 (UTC)[reply]
I believe an LLM is too heavy for combating LTAs. I think we can get away with a specialized model such as an LSTM or GRU model or a small transformer. Each LTA would have their own model trained on known-LTA diffs and known-not-LTA diffs, making the model a classifier. This would be better than using an LLM to distinguish e.g. Master12112wp and having it either hallucinate AGF on every single LTA edit (making it effectively useless) or WP:ABFing by classifying every piece of Hindi text as LTA (relevant lemmy post). LLMs are optimized towards the general task of predicting a plausibly-human token given previous tokens, but we can do better for this specialized task. (On the other hand, LLMs may be useful for other tasks, such as spotting NOTFORUM comments on controversial talk pages.) OutsideNormality (talk) 21:59, 6 September 2025 (UTC)[reply]
I don't think having this kind of "automoderator" determining whether posts are spam or not would be helpful, as it would essentially be a more WP:BITEy version of ClueBotNG. The latter is already only configured to revert the most obvious kinds of vandalism, and a LLM trained on a much wider definition of spam from other websites (and with the risk of errors) would be much worse, and could lead to systemic bias depending on which posts it considers "spam" or not.
However, I do agree with the idea of training smaller models against specific LTAs, as an addition to existing abuse filters – they can be more flexible in learning complex rules than regex, and can be trained for a more specific task than a generic LLM, instead of flagging any text they don't recognize as plausible. I don't think this should be extended to NOTFORUM comments, as human judgement is often key in these cases, and the risk of "grey area" comments being reverted by a model is too high. Chaotic Enby (talk · contribs) 13:13, 7 September 2025 (UTC)[reply]
The NOTFORUM comments example was just an example off the top of my head of a task that would be better done with a large language model than a small language model. OutsideNormality (talk) 15:25, 7 September 2025 (UTC)[reply]
My reply about NOTFORUM was regarding language models in general, not specifically small/large. Chaotic Enby (talk · contribs) 00:34, 8 September 2025 (UTC)[reply]
Enough of shoving AI down our throats. Plus, I don't consent to any of my edits being used to train this - even if I'm in somewhat of a good standing somehow. LilianaUwU (talk / contributions) 20:28, 7 September 2025 (UTC)[reply]
Enough of shoving AI down our throats. Oh Liliana. Such language. This is not a group of powerful elites talking about what to do to the huddled masses yearning to breathe free. At least, not any more than any village pump discussion. Wikipedia is self-governed. We'll take your comment as opposing the idea, although you didn't say why, sort of making it a WP:IDLI argument. ―Mandruss ☎ IMO. 20:57, 7 September 2025 (UTC)[reply]
The original proposal uses a pre-trained model (1b/4b Gemma 3), so none of your edits would be used to train it (as they've already been trained on ¯\_(ツ)_/¯). My small language model proposal above would use Wikipedia diffs as training, however. If you oppose even that, I'm curious as to why (and note that ClueBot NG already does a similar thing, just using a hybrid of a Bayesian classifier and feedforward neural network instead of an RNN like my proposal). OutsideNormality (talk) 21:37, 7 September 2025 (UTC)[reply]
The use-a-specialized-langugae-model-as-the-next-step-of-protection-against-abuse-filter seems to be a good idea and perhaps we can take this to its own subsection. The community seems to be more on-board with this from what I have seen. You can never have enough AI.--85.98.23.90 (talk) 20:52, 7 September 2025 (UTC)[reply]

Specialized small language models as advanced edit filters?

[edit]

To elaborate on the previous discussion, the idea of using specially trained smaller language model sounds more promising. Edit filters (being regex-based) can't capture more complex language patterns that are often useful in spotting LTAs, and training small language models for very specific tasks like this is absolutely feasible. This shouldn't be used to build a generic spam filter (given the high risk of false positives), but to perform specific tasks that edit filters can't necessarily achieve on their own. Chaotic Enby (talk · contribs) 00:45, 8 September 2025 (UTC)[reply]

I think this is a far more reasonable idea, like a much more targeted CluebotNG, and is worth exploring. There is less of a systemic risk of introduced bias at scale. fifteen thousand two hundred twenty four (talk) 01:48, 8 September 2025 (UTC)[reply]

Merging Wikipedia:Requests for comment/User names with WP:AN

[edit]

Wikipedia:Requests for comment/User names is a venue to request comment on editors' usernames to determine whether they comply with the username policy. There have been three (3) archived requests in 2025, and there were six (6) in 2024. We have too many noticeboards, discussion venues, and processes; dealing with this one seems like some low-hanging fruit.

My thought would be directing future requests to WP:AN and/or WP:ANI if community consensus is required—like all other nuanced "does this person need a block" question. Thoughts? HouseBlaster (talk • he/they) 19:50, 6 September 2025 (UTC)[reply]

Notified: Wikipedia talk:Username policy. HouseBlaster (talk • he/they) 19:54, 6 September 2025 (UTC)[reply]
I'll add one other thing: a good portion of the RFCs here result in blocks for vanilla disruptive, which would also belong at AN(I). HouseBlaster (talk • he/they) 19:54, 6 September 2025 (UTC)[reply]
I had zero idea that the venue in question even exists; I just assumed problematic usernames that aren't quite problematic enough for WP:UAA are discussed at AN and ANI anyway. We don't need a specialized process for everything, so I would definitely get on board with this idea. SuperPianoMan9167 (talk) 20:08, 6 September 2025 (UTC)[reply]
I did know that the venue existed, but I didn't know that the volume was so low these days.
Yes, I think merging up to WP:AN is reasonable.
I wonder whether the Wikipedia:Administrators' newsletter could benefit from an occasional reminder about what WP:U actually says, such as:
  • Usernames like "User:Name at Business" are recommended. Disclosing a COI in your username is not promotional. Do not ask them to change their usernames, and do not block them unless you would block a user with a generic name for the same reason.
  • Usernames like "User:BusinessName" and "User:Marketing department at Business" are not permitted under WP:NOSHARE rules. Do not block these editors (unless they are breaking other rules), but instead encourage them to follow the directions at Wikipedia:Changing username#Requesting a username change.
  • Accounts with disruptive, inappropriate, profane, or offensive usernames should be blocked on sight, even if they have not made any edits.
Think of this suggestion as a type of filler ad: It's not time sensitive, but if there were one or maybe two short bullet points in most issues, then admins and their talk-page stalkers might be more aware of the rules. WhatamIdoing (talk) 21:13, 6 September 2025 (UTC)[reply]

Increase rights to move base user pages (especially not their own)

[edit]

I've seen a few times over the last 6 months that accounts with far less than 25 edits (not sure whether more or less than 10) have moved other users base user and user talk pages. Should that need more rights/ more edits?Naraht (talk) 23:48, 7 September 2025 (UTC)[reply]

Could you link to an example? Generally a user should NEVER move another user’s base page or talk pages… at least not without an explicit request to do so. However, there could be extenuating circumstances that we are unaware of. Blueboar (talk) 23:54, 7 September 2025 (UTC)[reply]
Well, here's the last thousand third-party base user/user-talk page moves, which goes back to February. A bit more than a hundred of them were by users who currently have 100 or fewer edits, and are mostly problematic; the remainder were overwhelmingly moves into draft, with a scattering of renames. (quarry:query/96990 has the last thousand by users currently with 200 or fewer edits; those thousand go back almost a decade.) —Cryptic 01:59, 8 September 2025 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)&oldid=1310166760"