Wikipedia

Wikipedia:Village pump (idea lab)

(Redirected from Wikipedia:IDEALAB)
Latest comment: 9 hours ago by Thryduulf in topic The problem of AI generated deletion nominations
 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, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68


Revisiting WP:INACTIVITY

edit
Latest comment: 11 hours ago370 comments56 people in discussion

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
Latest comment: 3 days ago42 comments17 people in discussion

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

Require accounts for live edits, move IP edits to pending

edit
Latest comment: 4 days ago35 comments18 people in discussion

This is my first time doing this so sorry if this is the wrong place, or an imperfect proposal, I don't have the technical aspects of this fleshed out, I'm just trying to gauge public opinion.

Preface

edit

I want to be very clear up front: this is not a call to block IP editing.

Wikipedia has discussed 'blocking IPs' many times before, and those proposals have consistently failed and for good reason. There are a lot of good edits from IPs: typo fixes, factual corrections, and contributions from people who might never sign up for an account but still add value. What I’m proposing is different. I’m suggesting that IP edits shouldn’t automatically go live the second they’re made. Instead, they should enter a pending review queue (similar to how “pending changes” works now) and only appear in articles after being approved by a reviewer. But this doesn't change the fact that 97% of vandalism comes from unregistered users.

This way:

  • Good-faith IP contributions are still welcome.
  • Bad edits don’t immediately reach readers.
  • We acknowledge that most IP edits are already being reviewed by experienced editors anyway - this just makes that review step happen before the edit goes public, instead of after.

This would dramatically reduce visible vandalism - the biggest reputational issue for Wikipedia is when blatant vandalism sits live for minutes, hours or even days. This system would almost eliminate that problem.

Summary

edit

Wikipedia allows unregistered users (IP editors) to edit most pages directly. While this openness has been part of the project’s ethos since its founding, it has also meant that experienced editors must constantly patrol for vandalism, spam, and poorly formatted contributions.

This essay argues for a structural shift:

  • IP edits would no longer go live instantly.
  • Instead, IP edits would enter a pending review queue before appearing in articles.
  • Brand-new accounts would also have their edits reviewed until they demonstrate basic good-faith editing (significantly less than the 500 to become an EC, but enough to vet whether the account is just purely for trolling).


This system preserves openness, anyone can still suggest changes, while reducing the burden of reverting vandalism and repairing broken pages.

Think of it as a universal “Pending Changes” model for IPs and brand-new accounts. Pending Changes has been controversial but ultimately accepted for certain high-profile or vandalism-prone pages - this would expand that system massively, but with the same core idea. And it's worth noting German Wikipedia already disables IP editing altogether. Compared to that, this proposal is less restrictive - it doesn’t ban IP edits; it just restricts them.

Why change the current system?

edit
  • Constant cleanup is already the norm. Nearly every IP edit is already double-checked by experienced editors to make sure it isn’t vandalism, spam, or just poorly formatted. In practice, patrollers treat these edits as "pending" already - the only difference is that readers see the unreviewed version first, which is often vandalism or nonsense.
  • Vandalism is instantly visible. Even if it’s reverted within minutes, IP vandalism harms Wikipedia’s reputation and can mislead readers.
  • Editing without an account is too easy for trolls. Throwaway IP edits mean vandals can disrupt pages endlessly without consequences.

How the new system would work

edit

1. IP edits go into a pending queue by default.

  • They do not immediately change the article.
  • Reviewers (autoconfirmed users or above) can approve, reject, or modify them before they go live.

2. Newly registered users also have pending edits until they make enough constructive edits to be deemed trustworthy.

  • This strikes a balance: new users aren’t stuck for months before they can edit freely, but they do show a basic level of good faith before their edits go live.

3. Established accounts (autoconfirmed and above) see their edits publish immediately, as now.

Benefits

edit
  • Vandalism won’t go live - readers will see a stable version of articles.
  • Patrolling becomes calmer - instead of frantically reverting vandalism, editors can review suggested changes at their own pace.
  • Makes formal what already happens informally - since experienced editors already double-check nearly every IP edit, this simply streamlines the process and prevents bad edits from ever reaching readers in the first place.
  • Lower barrier than Extended Confirmed - this proposal doesn’t require 500 edits and 30 days, just a short “training period.”

Challenges

edit
  • Review backlog risk: If every IP edit needs approval, there must be enough reviewers to handle the queue. Otherwise, good edits might languish. However, this backlog would likely taper off over time - much of today’s vandalism is driven by the 'instant gratification' of seeing your prank or nonsense appear on Wikipedia immediately. Once vandals realize the days of seeing their edits show up live are over, a lot of that behavior will fizzle out.
  • Openness concerns: Some editors fear any restriction could discourage casual contributors or whistleblowers who value anonymity.

Likely outcomes if implemented

edit
  • Short-term: Chaos. There will be a big backlog and potential frustration for both IP editors and reviewers.
  • Medium-term: Adjustment. Vandalism will drop as the “instant gratification” factor disappears, reviewers will adapt, and tools may even improve to automate simple approvals (typo fixes, formatting).
  • Long-term: Stability. Wikipedia becomes more stable and vandalism becomes far less visible - but there’s a real risk that casual, one-time editors might contribute less.

Possible refinements

edit
  • Require IP editors to pass CAPTCHAs or rate limits to stop automated spam.
  • Allow certain “low-risk” edits (like typo fixes) to bypass the queue if detected by filters.

Conclusion

edit

Wikipedia thrives on openness, but openness doesn’t have to mean instant, unreviewed edits from anyone with an internet connection. Since experienced editors already double-check almost every IP edit - and vandalism bots only catch the most obvious junk, shifting IP edits (and a short probation period for brand-new accounts) into a pending review system would still uphold Wikipedia’s core principle of “anyone can edit,” while dramatically reducing visible vandalism and the endless cycle of cleanup. This change would keep Wikipedia open to contributions from everyone, but cut visible vandalism to nearly zero, eventually easing the workload on patrollers and reducing the current reliance on chance that someone spots and reverts bad edits in time.

Nswix (talk) 20:35, 31 July 2025 (UTC)Reply

How would this interact with Wikipedia:Temporary accounts which are soon going to be deployed here? I will also note that visible vandalism is far from an IP-only problem, and that, in your new system, "cleanup" will still need to be performed even if the edits are not visible during that time. Chaotic Enby (talk · contribs) 21:39, 31 July 2025 (UTC)Reply
Regarding "vandalism is far from an IP-only problem" (emphasis mine, no evidence provided), the proposal cites evidence that it is the overwelming majority (97%!) of it. But even if it's only 40%, I agree that single-step proposal that targets a substantial chunk of a problem is worth at least testing. This proposal explicitly defines itself as a reader-facing improvement, not an editor-timesaver or way to prevent bad edits in the first place. These two aspects seem to hint at a "Perfect is the enemy of good" problem. DMacks (talk) 16:19, 1 August 2025 (UTC)Reply
The linked study is from 2007, and other studies from the same time found much lower numbers (around ~80%), with the caveat that the vast majority of IP contributions were not vandalism. Even then, my point is that, beyond the numbers, the ability to vandalize is not fundamentally connected to editing under an IP – many of the worst long-term abusers regularly create new accounts instead. On the other side, one-time constructive editors would be confused by not seeing their contributions appear (and might even believe that they were reverted), and might be discouraged from editing further.
While there is certainly an improvement on the reader-facing side, it might come with the price of a steep decline in new contributors, which will have an impact as they are responsible for a large proportion of the encyclopedia's edits. This has been evaluated more recently in meta:Research:Value of IP Editing, which found that restricting IP edits generally led to a decrease in both vandalism and productive edits. I do not believe the trade-off is necessarily good, although I am not opposed to something like A/B testing to help ascertain it. Chaotic Enby (talk · contribs) 16:46, 1 August 2025 (UTC)Reply

And it's worth noting German Wikipedia already disables IP editing altogether.

Not true. It simply does the IP part of the universal pending changes thing you propose. And right now, their de:Special:PendingChanges backlog is 17 days long. It's also said that the lack of immediate feedback makes editing a lot less rewarding and encouraging of newcomers. Aaron Liu (talk) 21:57, 31 July 2025 (UTC)Reply
Do we have data for how long the enwiki pending-changes wait-time typically is? More importantly, do we have data for what percent of IP edits are not reverted (undone, whatever technical process) in mainspace? An edit getting reverted means there was a second set of eyes, so that latter could be a maximally pessimistic gauge for how much increased editor load there would be for requiring review of all IP edits. DMacks (talk) 16:24, 1 August 2025 (UTC)Reply
Is the CAPTCHA part active right now? I'm getting that prompt on every edit starting today. -- 65.93.183.181 (talk) 04:35, 1 August 2025 (UTC)Reply
Well, except this one. So, every edit in article-space -- 65.93.183.181 (talk) 04:36, 1 August 2025 (UTC)Reply
This is just an idea page, so no - that is not the reason. If you don't like entering CAPTCHA verifications, consider creating an account. ;-) ~Oshwah~(talk) (contribs) 04:38, 1 August 2025 (UTC)Reply
That's because of a certain long term abuser and is unrelated to this proposal. Children Will Listen (🐄 talk, 🫘 contribs) 07:20, 1 August 2025 (UTC)Reply
1. dewiki does this. It has caused them very, very many problems. I do not want us to head in that direction.
2. "97% of vandalism comes from unregistered users" – that statistic is meaningless. What is more important, what we assess every time we protect a page, is what proportion of IP edits are vandalism, not the other way 'round. Toadspike [Talk] 17:06, 1 August 2025 (UTC)Reply
+1 on "let us not follow dewiki". —Kusma (talk) 18:10, 1 August 2025 (UTC)Reply
From my perspective, vandalism is very low these days and not a big problem thanks to filters. Unlike 20 years ago, it is quite rare to see defaced pages. Wikipedia has a very high reputation. What we need to worry about is getting enough people to edit so our community does not fossilise. We are already far less open than we used to be. I do not think we can afford to become even less open. —Kusma (talk) 18:16, 1 August 2025 (UTC)Reply
Depends on the topic area and the type of vandalism. We still see a lot of POV vandalism in our more controversial subject areas. And I still find myself frequently having to revert school kids who think it fun to add their mate’s name to “list of people in X” articles. Blueboar (talk) 18:39, 1 August 2025 (UTC)Reply
I fully agree. Honestly I've slowed down on editing simply because vandalism has gotten so low, and most of my time here was spent reverting it. It might be because of policy changes, but honestly I'm beginning to think it's just because people nowadays have better things to do. Either way, this proposal is a very bad idea. The amount of IP edits is enormous, and the backlog would quickly grow to a point where it would be impossible to go through all the edits. Gaismagorm (talk) 17:52, 4 August 2025 (UTC)Reply
Besides, nowadays Vandalism isn't why people criticize Wikipedia usually. Instead people often criticize bias (or perceived bias), and in some cases unsourced content. Gaismagorm (talk) 17:54, 4 August 2025 (UTC)Reply
You are massively underestimating the amount of edits that will be added to the pending changes backlog, and massively overestimating the number of editors who will work on that backlog. Gnomingstuff (talk) 04:59, 9 August 2025 (UTC)Reply
A benchmark here might be the NPP backlog. They probably have much better stats on this, but today it looks like there have been roughly 5-20 new entries per hour, and 921 new entries in the last week. The backlog is 18,472 articles, the earliest of which is 6 years old. NPP reviews take much longer than reviewing diffs, but given that we get roughly 2 edits per second, the workload would likely be much longer too.
Another, better benchmark might be the patrol backlog on Commons, which is more similar to this. Unpatrolled edits are removed from the queue after 30 days, and even then the backlog reached 57,083 IP edits in 2023 (of 1,255,051 edits total). You can extrapolate what the numbers would be here. And if we impose a similar 30-day cutoff, then we basically are banning IP edits, stochastically. Gnomingstuff (talk) 18:59, 9 August 2025 (UTC)Reply
The NPP "oldest entry" backlog numbers are misleading. If you convert a six-year-old redirect to an article, that's reported as a "six-year-old backlog" by the software, even if it's only been in the queue for five seconds. WhatamIdoing (talk) 04:16, 13 August 2025 (UTC)Reply
Good to know, thanks. Gnomingstuff (talk) 20:54, 17 August 2025 (UTC)Reply
Is there a sizeable amount of volunteers ready to take on this task? If no, how do you expect the transition from the short-term to the medium-term scenario to occur? We have many backlogs as is, and the number of active editors has been ~stagnant for years. Dege31 (talk) 16:23, 9 August 2025 (UTC)Reply
You know what I could see. Maybe hold edits tagged as "potentially vandalism" for review. Might be a good idea, But I'm too lazy to do a formal suggestion. But hey, still an idea. Gaismagorm (talk) 19:37, 9 August 2025 (UTC)Reply
Automatically labeling newcomer edits as "potentially vandalism" could easily scare them away from the project altogether. Please do not bite the newcomers is one of our guidelines, after all. Chaotic Enby (talk · contribs) 21:20, 9 August 2025 (UTC)Reply
I don't think that's what they meant. You know the ORES-based "potentially vandalism" filter under recent changes? I think they means maybe we could make all edits assessed as such go through PendChang. Though that would probably take quite a bit of coding. Aaron Liu (talk) 21:28, 9 August 2025 (UTC)Reply
exactly. It's just an idea, I don't really care too much, but hey, it's a neat idea. Gaismagorm (talk) 21:42, 9 August 2025 (UTC)Reply
Oh, my bad for misunderstanding it! Yes, that makes more sense (and wouldn't be as bite-y), the question is really whether we have the manpower to do so. Chaotic Enby (talk · contribs) 09:16, 10 August 2025 (UTC)Reply
I find the backlog risk concerning. As Aaron Liu pointed out, German Wikipedia implemented this policy, and 2 week+ backlogs do happen there. I don’t see why a similar backlog wouldn’t arise here if we gated all IP edits behind review in this project.
As Toadspike noted, the key missing data point is what share of IP edits are vandalism. To quantify the impact on the total number of non-vandalism edits to the project, here are two scenarios using this year’s Wikistats share that ~13–14% of human edits come from IPs [7]:
  • Assume 20% of IP edits are vandalism (1 in 5!). If the policy is highly effective and reduces IP vandalism by 10x (90% removed) while reducing good IP edits by 2x (50% removed), we would remove about 5.3-5.8% of all non-vandalism human edits on English Wikipedia.
  • Assume (more realistically) that only 5% of IP edits are vandalism. If the policy reduces IP vandalism edits by 10x but reduces good IP edits by 5x (80% removed), we would remove about 10.0-10.7% of all non-vandalism human edits on English Wikipedia.
Those are just near-term effects. Longer-term, adding friction to a first edit likely suppresses participation by removing low-commitment on-ramps. I would guess that this effect has been previously studied in depth.
I don’t work in anti-vandalism, but if the goal is reducing manual workload, I’d prefer we first exhaust automation-heavy alternatives that don’t erode openness. You can always “improve quality” by restricting who can edit. Taken to the extreme, you get Britannica, but that runs directly against the project’s ethos. If less-restrictive options haven’t been tried here, we should really make sure to explore those first. spintheer (talk) 02:47, 13 August 2025 (UTC)Reply
Another way to see it: your work doesn’t just stop vandalism, it keeps about 10% of good edits flowing by making it unnecessary to gate all IP edits. That’s exceptionally high leverage, and everyone pushing our anti-vandalism efforts should be proud of that impact. spintheer (talk) 03:00, 13 August 2025 (UTC)Reply
Previous research has also shown that many IP edits are reverting vandalism. (AFAICT all the research is outdated.)
This graph shows why I don't want to follow the German-language Wikipedia's model: https://stats.wikimedia.org/#/de.wikipedia.org/contributing/editors/normal%7Cline%7C2015-08-03~2025-07-31%7C~total%7Cmonthly WhatamIdoing (talk) 04:18, 13 August 2025 (UTC)Reply
Thanks for the pointer. This has probably been said before, but the dynamic is self-reinforcing: each step toward less openness in the project shrinks the constituency who might advocate for it, making the next restriction easier. spintheer (talk) 05:16, 13 August 2025 (UTC)Reply
I also remember research saying that new editors depend on instant feedback/displaying of changes to maintain interest. Aaron Liu (talk) 21:33, 13 August 2025 (UTC)Reply
A more likely conclusion is that anyone wishing to vandalize will just create throw away accounts to do so unless there is also an additional requirement to link the registered account to a verified phone number or email address (which cannot be from an provider that doesn't further link to the user's identity in some way e.g., no @proton.me email addresses). 199.224.113.11 (talk) 02:56, 16 August 2025 (UTC)Reply
I have a recent changes filter to show non-reverted edits from IPs and non-autoconfirmed accounts. IP edits swarm the list, and this proposal may become unmanageable as not all users would like to review such a backlog, even considering the drastically lower entry requirements compared to pending changes protection. Perhaps a system where only edits from IPs that get a certain ORES score would be sent to review is an option. (As an aside, do the CAPTCHAs actually work? They seem quite weak, especially with the "improved" system introduced in phab:T141490.) OutsideNormality (talk) 20:34, 23 August 2025 (UTC)Reply
I've heard that the old system was more likely to prevent a human from editing than a bot. WhatamIdoing (talk) 21:29, 23 August 2025 (UTC)Reply
I do think it should be possible to mark an edit as patrolled. The current logistical hiccup is that the patrolling system is deeply tied into new pages, and I don't know if it can be unbundled so that edits can be separately marked as patrolled. Aasim (話す（はなす）) 15:59, 24 August 2025 (UTC)Reply

New Editor Throttle/Cooldown after Warns?

edit
Latest comment: 5 days ago19 comments11 people in discussion

I've been doing a bit of recent change patrolling, and there's a pattern that I keep seeing with new editors who appear to start as well intentioned editors very quickly make a large number of problematic changes, often become increasingly frustrated as their changes are reverted in a way for reasons they don't understand. In parallel, they quickly pick up a bunch of warn templates and often very quickly a ban. At no point in this process do they engage any of the warning editors in conversation, and I'm frankly skeptical in a lot of cases that they actually see their talk page until they are banned if at all.

It doesn't feel like we are doing brand new users any favors by allowing them to plow onward with rapid-fire edits without actually seeing warnings or engaging other editors in conversation. What I am observing (albeit anecdotally) is that if the new user does engage in a discussion, they are much more likely to be guided towards being a constructive editor. You could argue that the eventual ban they receive is the mechanism to force them to engage in dialog, but frequently at that point they are frustrated/angry and looking a pile of scary sounding warn templates and a ban and it is much harder to guide them back to being a good editor.

I'm wondering whether these new users would be better served if we had mechanisms to prevent them from shooting themselves in the foot before they are fully committed to that path. Could we somehow throttle very new users to a smaller number of edits per hour for their first day? Or perhaps some kind of enforced slowdown or gate that prevents them from editing once they get a warning(s) until the acknowledge that their talk page exists? Or an earlier criteria for a very short ban (15m? 60m?) just to prod them into slowing down and engaging in conversation? To be very clear, my concern here is entirely around the new user experience; the process is doing a great job quickly correcting problem edits. My worry is that we're losing out on people that potentially could have been good editors by allowing them to throw themselves head-on into the gears of that process.


Driftingdrifting (talk) 15:28, 13 August 2025 (UTC)Reply

While a ban from article space until they've acknowledged warnings might work for desktop editors, WP:THEYCANTHEARYOU means we cannot reliably know whether someone using a mobile device is even aware that anyone can communicate with them, let alone that people are trying to do that. Some sort of throttle on the number of edits per hour is an interesting idea I don't recall seeing proposed before. I don't know whether it would be enforceable technically or not? Thryduulf (talk) 20:41, 13 August 2025 (UTC)Reply
I think the throttle idea is intriguing, especially if removal of the throttle is tied to first use of a talk page, but I don't think it's workable for IP editors and it really would be unfair to new accounts to limit their editing more than we do for IP editors. Schazjmd (talk) 20:44, 13 August 2025 (UTC)Reply
I find the idea interesting, although we should make sure to avoid it leading to a WP:COOLDOWNBOCK-like frustration. With IPv6, the address can spontaneously vary across a /64 subnet (one billion billion addresses!), making it unworkable for some editors to even see past warnings, let alone use a fixed talk page for communication. While we could theoretically have a subnet-wide throttle, the lack of /64-wide talk pages makes it much less useful until temporary accounts are deployed. Chaotic Enby (talk · contribs) 20:55, 13 August 2025 (UTC)Reply
I don't know how technically viable it is, but honestly I'd be pretty ok with the editor being able to pretty easily bypass the throttle if they so chose as a way to avoid that frustration. Since it's not an attempt to stop vandalism, just a small speed bump to keep the editor from shooting themselves in the foot, I feel like it is less critical that it can't be bypassed. The IPv6 thing is something I hadn't thought about and does seem like it would make this hard or less useful. I'm not super familiar with the temp accounts thing, would that make this kind of idea more viable? Driftingdrifting (talk) 22:04, 13 August 2025 (UTC)Reply
Temp accounts would make the idea much more viable, as it would centralize the warning system to a single talk page instead of randomly switching between a billion billion potential talk pages. This means IPv6 users have an incentive to watch their (unique) talk page, and that this throttle system encouraging them to look at it can be implemented in a way that makes sense. Chaotic Enby (talk · contribs) 22:08, 13 August 2025 (UTC)Reply
I like the idea. I wonder if we can get some type of mainspace block that is automatically lifted when the users say they understand the warning. Only for more severe warnings of course. For a level-4 warning, we might even give them a mini-quiz. Will probably require quite some WMF work to implement this well. —Femke 🐦 (talk) 11:48, 14 August 2025 (UTC)Reply
Yep, we would have to make it clear enough that it's just a "making sure you understand this" thing rather than a full block, to avoid coming off as WP:BITEy. There's also the question of who can put these mini-blocks – if it's only admins, then we might not have enough of them to warn new users, but if any user can give a mini-block by adding a warning template, there might be a lot of potential for abuse. Maybe that could become an actual function of the rollbacker role? Chaotic Enby (talk · contribs) 11:57, 14 August 2025 (UTC)Reply
I'd support that becoming something a rollbacker could do. But how would we make it clear that we are trying to be friendly and not WP:BITE? Gommeh 🎮 14:33, 16 August 2025 (UTC)Reply
One billion? More like 18.4 billion billion. That is 64 bits - (264), or 18,446,744,073,709,551,616 addresses per 64. 166.205.97.96 (talk) 06:40, 16 August 2025 (UTC)Reply
If the throttle is something that 'lifts' automatically (which I would expect as a throttle doesn't stop things forever, conceptually) then it would work for most IP editors as well (or temp editors who clear cookies every now and then). IPs can be dynamic but as long as they're not changing faster than the throttle it would work, and if the throttle occasionally eases up early due to an IP change that seems a small harm at worst. CMD (talk) 14:58, 14 August 2025 (UTC)Reply
The issue I'm having in mind are: 1/ if the IP changes after the throttle is lifted, then they may be throttled/blocked again despite having seen their previous talk page, which we don't want to happen; and 2/ many IPv6 users don't have as much of an incentive to look at their talk page, as it can be gone in an instant (and pretty much impossible to find, since most editors don't know the Special:Contributions range search thing, or even how that IP stuff works). Chaotic Enby (talk · contribs) 15:23, 14 August 2025 (UTC)Reply
Just spitballing here in order to play out a couple of the scenarios. All these numbers are just random pulls, obviously could be set differently. Let's assume for a moment that we apply a 15m throttle when a a new* editor receives a warning. *new is going to have to be differently defined for different user types:
  1. normal account user: account was created within the last 24hrs.
  2. ipv4 user: this could be a shared IP. Treat an IP as "new" for 24hrs following an editing gap of at least three months.
  3. ipv6 user: this is a unique user. Treat them as new for 24hrs after their first edit.
  4. temporary user: this is a unique user. Treat them as new for 24hrs after creation.
Once a user is throttled, they are either prevented from making main space edits or are rate limited for main space edits (say, one edit every 5m). The throttle is lifted if the editor makes any non-main space edit (e.g. interacting with their talk page, someone else's talk page, Tearoom)
Ok, so what are the implications of this for different users:
  1. For normal account users this behaves entirely as expected.
  2. For ipv4 users where the IP is shared, we have a few more scenarios:
    1. A returning ipv4 editor after a long break could potentially be treated like a new user again and throttled again. This will only happen if someone on the IP collects a warning within the 24hr window and the maximum worst case impact is that they get throttled for 15m one time.
    2. A returning ipv4 user changes their IP and begins editing on an IP that hasn't edited before. They could potentially be treated like a new user and throttled again. Again, the worst case impact is a 15m, one-time throttle following a warning.
    3. A IP editor on a shared IP is throttled because of a warn given to a different editor on the same IP. This will only happen in a very specific (i'd guess rare-ish situation) of multiple editors on the same IP, in the 24hrs after a long break. Again, the worst case impact is a 15m, one-time throttle.
    4. An IP editor who should be throttled, changes their IP and becomes un-throttled. This will only occur if they change their IP *during* an active 15m throttle. That's an extremely small window and the normal time that IPs change is much longer than the throttle window, and the consequences here aren't very severe (status quo). Also, I think in this case this editor actually benefits because this would only happen in a situation where someone else on the IP has them on the track to a ban.
  3. IPv6 & Temp Account: These are a unique users. While they could switch to a new IP or account arbitrarily fast, IPv6 addresses generally don't cycle more than once a day.
    1. IP/Temp Account who should be throttled creates a new account and becomes un-throttled. This will happen more frequently than with the IPv4 editor scenario, but still, the period for new IP/new account is typically going to be longer than the throttle period.
    2. IP/Temp Account could be throttled multiple times. This will only happen if they do something to earn a warn, and the maximum impact is 15m of throttle or until they interact with any non-main space page.
Overall - there seems to be very little harm in the scenarios where the throttle is bypassed. The more valid harm is an IP user being throttled more than once, but in order for that to happen they would have to meet some narrow criteria, earn themselves a warn, and the maximum impact is 15m of slowdown. This doesn't seem that drastic in the grand scheme of things and arguably good?
There is also the possibility of missuse/abuse of the throttle but it doesn't seem like it would be that enticing of a target. At best, they can give another editor a 15m cooldown, once, as long as that editor is 'new' and that editor can bypass by interacting with any non-main space page. There are more effective ways to disrupt wikipedia if that is your goal, and this would be pretty obvious if someone was doing this routinely. This could also be managed by controlling the eligibility for triggering a throttle (say, must be confirmed, or extended confirmed, or have rollback, etc) or by changing the level of required warn, or needing warns by multiple editors. Driftingdrifting (talk) 16:23, 14 August 2025 (UTC)Reply
WP:LTA/HR would have a field day with this. To prevent this, we would need to throttle upon warning only if the user who placed the warning is experienced. I recommend processing warnings only from users that meet any of the following criteria:
  • Having any manually granted right on any WMF wiki (excluding IPBE)
  • Having any global right, excluding IPBE and CAPTCHA exempt
  • Having >= 1000 edits globally
  • Being created by a user who meets #1 or #2 or has >= 5000 edits globally (for instance, for a legitimate alternative account)
This is hard to meet by sockpuppets, as permissions require trust, and it would be difficult to game 1000 edits globally without someone noticing. (Alternatively, just require the rollback permission to trigger the throttle, which is simpler.) OutsideNormality (talk) 19:11, 23 August 2025 (UTC)Reply

Helping users avoid 0 talkspace edits

edit
  Merged here from its own section

Basically twice a year or more, we have a learning curve problem that caused users to have wp: "never edited a talk page" subpageof:"Administrators' noticeboard". I'm thinking:

  • At 100 edits, have an automatic notification asking them to reply to concerns or their welcome message on their user talk page
  • At 500 edits, automatically pblock them from articlespace until they edit a talk page, so they learn how to do so before they end up at ANI
  • Any other ideas to help make them aware that talk pages exist?

Will this make the learning curve easier for them or not? 174.138.218.72 (talk) 21:50, 16 August 2025 (UTC)Reply

A pblock might be too harsh, but other solutions to this are being discussed above at New Editor Throttle/Cooldown after Warns? (although they only apply to editors having been warned but not realizing that their talk page exist) Chaotic Enby (talk · contribs) 22:20, 16 August 2025 (UTC)Reply
Most people never end up at ANI, so why bother making sure that everyone has the technical skill for editing ANI (a particularly, egregiously difficult page to edit)? WhatamIdoing (talk) 01:26, 17 August 2025 (UTC)Reply
If those people had the skill to find/edit article talk, they wouldn't need the skill for editing ANI 174.138.218.72 (talk) 02:09, 17 August 2025 (UTC)Reply
Most people don't, of course, but editors not realizing that their talk page exists (sometimes not their fault, see Wikipedia:Mobile communication bugs) are at a much higher risk of getting reported to ANI for a lack of communication. From what I understand, the proposal isn't about making them learn to edit ANI, but making them learn about the existence of talk pages to avoid such a report. Chaotic Enby (talk · contribs) 11:38, 17 August 2025 (UTC)Reply

Require an edit history to propose sanctions (gauging support for such a rule)

edit
Latest comment: 5 days ago76 comments26 people in discussion

Sometimes amid a discussion of user behavior at ANI or AN, a brand new account or IP with no substantial edit history shows up to propose a sanction (blocks/bans). Then other users in good standard support the proposal. Given the extent to which such a proposal itself can generate ill will and demotivation, combined with blocks/bans being the strictest measures we have to curb user behavior, I think a demonstrated edit history should be required to make such a proposal. A demonstrated edit history might simply be a history of contributions, but can also take the form of a LEGITSOCK explanation or evidence of past IPs on a dynamic IP. None of this would mean discussions opened by the new/dynamic user which then found support would necessarily be nullified, but it would require someone else in good standard to "take over". (Yes, this is connected to a current ANI thread, but it's something I've seen -- along with debates over the extent to which provenance taints the proposal -- many times). — Rhododendrites talk \\ 20:16, 15 August 2025 (UTC)Reply

I haven't thought this through enough to weigh in overall, but I'm generally supportive some consideration of this matter. I would suggest exceptions for personal dispute resolution: if the IP or new registered user is filing due to misconduct directed at them, it would be unwise to make a filing more onerous. Firefangledfeathers (talk / contribs) 20:39, 15 August 2025 (UTC)Reply
I don't know how I feel about a hard and fast rule just yet but I think administrator/CheckUser judgement is key here. If an administrator feels like an IP is being disruptive in proposing a site ban or a block, they can hat it if they so choose. Same thing for a CheckUsers, if they know certain users are targeted by serial sockpuppeteers, they can hat the discussion and block the IP accordingly. I really don't want to go down the ABF rabbit hole and assume that every IP that proposes a site ban is doing it for nefarious purposes or has ulterior motives. ♠JCW555 (talk)♠ 20:52, 15 August 2025 (UTC)Reply
It surely merits suspicions and careful scrutiny of undeserved good faith if that IP has never shown up EXCEPT for that "ban this user" engagement. — Very Polite Person (talk/contribs) 00:14, 16 August 2025 (UTC)Reply
Of course, that's why I emphasized administrator judgement in my original comment. If they feel like the IP proposer is doing it in bad faith, they can hat it and block the IP. I feel like I can generally trust admin's judgement around here to make that determination. ♠JCW555 (talk)♠ 00:41, 16 August 2025 (UTC)Reply
I dunno. I feel like if an IP comes out of nowhere citing rules mid-conflict saying "ban X user per [these historical receipts] it would take deliberate closing of eyes to not have any conclusion but it's a user trying to game things offline. I'd even say that should be an immediate cut-the-bullshit checkuser and public detonation of the troublemaking user if identified. — Very Polite Person (talk/contribs) 00:50, 16 August 2025 (UTC)Reply
That's a flawed view, IP addresses change so there's no way of knowing if an IP editor is coming out of nowhere. Having said that IP comments in such situations can be less than helpful, there are many trolls, previously blocked users, and other editors who like to use IP editing as a way of avoiding scrutiny. It just important to remember to assume good faith whether the editor has an account or not.
On the other hand if there is a known troll who goes around reverting a particular editors comments and generally harassing them, then some common sense might be needed. I don't think there's a easy simple answer to this issue. -- LCU ActivelyDisinterested «@» °∆t° 20:35, 17 August 2025 (UTC)Reply
I agree that the risk of sockpuppetry/disruption at ANI is something to have in mind, but I don't think that a lack of contributions alone should be a limitation. IPs and newcomers should be treated, as much as possible, in the same way as established contributors, and limiting them from proposing sanctions (especially in disputes where they have been involved) might make it difficult for them to assert their rights. I'm pretty sure that what you have in mind are cases where the IP/account rushes to ANI as their first contribution, but I wouldn't be surprised if that rule ended up being used against less than "brand new" users, in the style of "how dare this user with 300 edits suggest a block against a user with 30,000 edits".
In general, while I do agree that ill will against sanctions being proposed by a very new user can easily derail a proposal, I believe that an opposite approach could be more helpful. Namely, clarifying that the discussion should focus on the proposal, not the proposer, and that WP:FOC should be extended to these proposals (although, obviously, a separate proposal can always be started in WP:BOOMERANG cases).
I do believe a caveat should be made for IPs or accounts where going to ANI is literally one of their first contributions, but it should be seen as a legitimate question asked to the user, and not weigh on the value of the proposal itself. In these cases, like @JCW555 suggests, admins could use their judgement to determine whether the proposal is legit (for example, from someone who lurked or edited as an IP and familiarized themselves with our processes before creating an account), or whether sockpuppetry has been going on. Chaotic Enby (talk · contribs) 21:12, 15 August 2025 (UTC)Reply
Just to be clear, I did mean to include an exception for disputes one is involved with directly. — Rhododendrites talk \\ 21:27, 15 August 2025 (UTC)Reply
Thanks a lot, that is indeed helpful to note! I also like your idea of a more experienced editor "taking over" the proposal to avoid derailing, and (even if a full restriction against new proposals doesn't come to fruition) it could be helpful. I feel like this should be, in a way, compared to the parallel discussion about closing AI-generated proposals: while the specifics are different, in both cases, proposals seen by someone else as having merit should still be given due consideration (and maybe "taken over"), while editorial judgement can be applied otherwise on whether to close them (although, of course, giving more leeway to new editors than to AI-generated proposals). Chaotic Enby (talk · contribs) 21:41, 15 August 2025 (UTC)Reply
I'm realizing that my analogy might not be really ideal, as newcomers certainly shouldn't be treated with a similar harshness as AIs, even if the discussions do share broadly similar questions. While "editorial judgement" can technically work as an umbrella term, what I had in mind for each was closer to, respectively, "checking if the user isn't an obvious sock" and "hatting the AI proposal if you don't feel confident in taking over it". Chaotic Enby (talk · contribs) 23:30, 15 August 2025 (UTC)Reply
I think this would devolve into arguments about who qualifies as an editor in good standing. In situations where a logged-in user swiftly supports a proposal, which is fairly common, this approach would just add another dimension to argue about: do the supporters qualify? This moves English Wikipedia towards a model where only good-standing editors are permitted to weigh in. There are pros and cons to this which may be worth exploring, but my instinct is that there isn't consensus for this at the moment. isaacl (talk) 22:09, 15 August 2025 (UTC)Reply
Maybe, but if we had consensus for such a rule, over time we'd take more notice of the proposer and gradually see fewer people jumping in to support a proposal with invalid provenance. — Rhododendrites talk \\ 22:15, 15 August 2025 (UTC)Reply
I don't personally feel there would be a signficant effect. I think people generally like to support proposals they agree with. (On English Wikipedia, a lot of the editors who like to participate in such matters really like to express a support or oppose opinion.) isaacl (talk) 23:43, 15 August 2025 (UTC)Reply
But why should provenance (or lack thereof) weigh against a proposal that is logically sound? 173.177.179.61 (talk) 19:26, 21 August 2025 (UTC)Reply
I would support such a restriction in principle, would need to hammer out the language. Something along the lines of Any logged in user may propose sanctions in a discussion they did not start at any time. If the discussion was started by a logged out user, that user may propose sanctions at any time. The issue I see with my wording is that it makes an "out" for potential abuse, a logged out user would simply need to start their own new discussion and immediately make sanction proposals. Though I suppose they lose the benefit of anyone that was subscribed to the original discussion. —Locke Cole • t • c 00:32, 16 August 2025 (UTC)Reply
I don't see what this achieves. No proposal goes anywhere without support of the community as it is. 199.224.113.11 (talk) 02:38, 16 August 2025 (UTC)Reply
I would Oppose this full stop. In addition if it's, bad faith, or trolling, we just hat or remove it like we already do. Per 199,it would not matter in the end anyways as the community is the one who decides if it's an acceptable proposal. If an user submitted a proposal that got a lot of legitimate support and midway through we found out they are an LTA, it would be absurd to discard it.
We already have ways of handling disruptive proposals. LakesideMinersCome Talk To Me! 03:25, 16 August 2025 (UTC)Reply
Could you provide some examples of situations where IPs being able to suggest a sanction at ANI has been enough of a problem that we need additional rules? Is this a real problem? 166.205.97.96 (talk) 06:12, 16 August 2025 (UTC)Reply
For me it would depend on the situation. You shouldn't have to have a long history here if the thing you're reporting is obviously harmful to the wiki. Gommeh 🎮 14:43, 16 August 2025 (UTC)Reply
I think this would be a poor idea for the project, with very possible chilling effects on future interaction and editing. I do understand that navigating the line between WP:AGF and keeping socks from tipping decisions is a nontrivial task, but further ensconcing a privilege of suggestions and proposals to registered users only is not the way it should be done. Sophia∠θ pr′me 19:59, 16 August 2025 (UTC)Reply

Asking seriously: is not stretching good faith to the level of silliness if an IP's first or basically initial contributions are to show up on something like ANI to argue a user's banning, with seeming knowledge of site inner workings and that "target" users history?

How could that be anything but a user logging out to avoid scrutiny on their own history? — Very Polite Person (talk/contribs) 00:20, 16 August 2025 (UTC)Reply

It can be a user like myself who has been around since 2003 and who doesn't want to create an account. 199.224.113.11 (talk) 02:40, 16 August 2025 (UTC)Reply
But that's a choice you made to limit yourself by not having a continuous history to demonstrate you. This IP has four net edits only in the past day. You can't prove what you say. That's the conundrum. If this IP showed up cold into a years-long dispute, how do we know it's not an involved player wanting to get things without accountability to their account? — Very Polite Person (talk/contribs) 17:15, 16 August 2025 (UTC)Reply
Does it matter? A few IPs are not going to impact the outcome either way. (Note: My preferred solution would be to always disclose everyone's IP, including logged in users. Why should people with accounts be able to hide their ___location, affiliation and potential COIs?) 50.206.43.26 (talk) 02:19, 20 August 2025 (UTC)Reply
This would be very helpful to head off sockfarms manipulating our processes to try and sanction editors dealing with them (not just on AN/I but in 3RR reports etc.), but it seems a blunt instrument to achieve that. In general I suspect adherence to WP:DENY to the point we lose our internal documentation of issues (eg. not tagging sock accounts) may be detrimental to us, but that's a much broader discussion. CMD (talk) 03:52, 16 August 2025 (UTC)Reply

I think this would be a terrible new step in the slow (and with respect to many changes in recent years, intentional) erosion of IP inclusion in the project. The ways in which users who choose--for any number of legitimate reasons--not to register have, through a piecemeal process, been frozen out of anything that remotely resembles contribution to even slightly controversial content is bad enough. Now we're going to begin the backslide on even permitting them access to process on the back end? I'm sorry, but that cure is far worse than the disease. People are perfectly free to discount IP behavioural proposals if (as a general principle, or just in individual cases) they incline towards suspicion to a proposal. I see only down sides here. Or at least, so much more downside relative to legitimate concerns as makes no difference. Can anyone here provide even one example of a case where an IP later connected with an LTA or other abusive party resulted in a sanction for another editor at ANI? Because I'd be frankly gobsmacked if anyone could. Meanwhile, the value to our spirit of collaboration and the quality of transparency on the project that accrues from allowing everyone a say in process and behavioural norms is of immensely greater value.

I really hope the community will not ultimately seriously contemplate this step towards further isolating our processes and community hubs as spaces for an increasingly rarefied few. The consequences to important needs, from retention and recruitment, to openness and transparency, to equanimity and diversity, would be non-trivial to say the least. SnowRise let's rap 08:38, 16 August 2025 (UTC)Reply

Now we're going to begin the backslide on even permitting them access to process on the back end? - No. We're just preventing someone with no edit history from proposing a sanction against someone in a matter they're not already involved with. ...Unless they demonstrate that they do have a history. I agree with what a couple other people said that how to demonstrate as much would be tricky, though. — Rhododendrites talk \\ 14:07, 16 August 2025 (UTC)Reply
Yes, but, though I recognize that slippery slope arguments have their weaknesses, disenfranchisement of people on the periphery of a system always start with little moves like this, and the recent history of this project very much proves that said principle applies here. Even the presumption that non-established editors should be held in immediate suspicion while trying to participate in an important part of of our processes for applying behavioural norms and restraining abuse sets a bad precedent.
We should only even contemplate such a move if there had been some extremely compelling evidence of a longterm destabilizing influence of the current openness of our structures. And bluntly, not only do we not have that, but no one here has even been able to point to so much as a single concrete example of abuse.
I mean, afterall, what happened in the immediately relevant discussion concerning HEB? Someone made an overzealous (but hardly entirely unfounded) proposal that took us from 0 to 100. Par for the course at ANI and hardly something that is going to go away if we begin excising the access of IP contributors. A non-trivial number of community members supported (or rather, most tried to support more moderate efforts), but the majority of us just saw the proposal as premature and shot it down in quick order. The system worked precisely as designed, and even if the proposal had attracted overwhelming support, that would only have meant that there was even more merit to the proposal. And again, proposals like this are routinely the product of established editors and we do not harangue them for having a perspective out of lock-step with the majority.
So, what harm was done here that even begins to justify this kind of re-assessment of access to our processes for as-yet un-established contributors? Because I am just not seeing how this can possibly pass a cost-benefit analysis when we consider the utter dearth of empirical evidence that there is an issue here, beyond hand-wringing about the unknown. This would be policy creep at its worst, and part of a pattern (deeply concerning to me at least) about increasingly insularizing our community spaces and processes. No thank you: not on this (lack of) evidence. SnowRise let's rap 01:05, 17 August 2025 (UTC)Reply

This proposal risks being just another barrier that is used by experienced users to avoid scrutiny. If you look at the ANI thread that's provoked this, then these sorts of arguments (that proposals from IP editors should be dismissed automatically) are being used in an attempt to deflect concerns about behaviour of a very experienced editor, where other experienced editors are agreeing with the IP.Nigel Ish (talk) 09:40, 16 August 2025 (UTC)Reply

Yes, and while the last thing I would typically want to do is inject polemics into a Wikipedia discussion, I don't think I can avoid the feeling that there is something disquietingly familiar to what we see in the world at large right now when the argument essentially boils down to "This newcomer/outsider (or at least person who looks like one) can't possibly have something of value to say if they are criticizing one of us. And if they are calling out abuse, they are probably bad actors, and their true purposes to disrupt and take advantage."
And let me be clear: I don't meant to imply that anyone who embraces this attitude on-project is necessarily someone likely to embrace it in other contexts. I'm just saying that in all spheres where it appears, this type of impressionistic, reactionary, and ramshackle thinking has obvious flaws and tends to appear in particular circumstances. SnowRise let's rap 11:25, 16 August 2025 (UTC)Reply
You see bad faith efforts to "deflect concerns"; I see good faith efforts to treat proposed indefinite blocks of long-standing users (or anyone) with the greatest care possible -- and that means a drive-by proposal to do the harshest possible thing we can to an editor from someone with no edit history gets scrutiny. — Rhododendrites talk \\ 14:10, 16 August 2025 (UTC)Reply
How is an indefinite block the harshest possible thing we can do to an editor? DonIago (talk) 16:18, 16 August 2025 (UTC)Reply
You see bad faith efforts to "deflect concerns". . . Well no, not necessarily in every instance, but it can't be denied that this is often an aspect of such efforts. And I don't think it's entirely coincidence that others have raised colourable concerns that this was what was happening in the instant case. Whether Levivich was consciously attempting to deflect is a harder thing to prove (and I would suggest unproductive) but their very broad impugnment of the validity of the proposal is unambiguously a choice to eschew engagement with the proposal on its merits in favour of a fallacy of virtue argument. You're absolutely right that an ndef (indeed, any form of CBAN, insofar as it creates a mark of community censure) should be treated "with the greatest care possible". But that care is a product of the conscientiousness and perspicuity of our indivual deliberations and the fair application of our agreed upon behavioural standards. I don't see how either of those is enhanced by trying to erect barriers that prevent a non-trivial portion of our community from participating in vetting solutions to problems. Quite the contrary.
I absolutely understand the impulse to treat such proposals with more scrutiny, as you frame it. I would never blame someone for treating an IP proposal with extreme caution, nor from voicing to others that we should do so. Indeed, on that narrow issue I gave full-throated support to Levivich when they were accused of casting aspersions, despite finding their broader approach to the discussion despiriting and problematic. But there's a difference between having (and expressing) an extra dollop of doubt and instead turning towards blanket bans on access to processes that are meant to check abusive behaviour. SnowRise let's rap 01:26, 17 August 2025 (UTC)Reply
Why should we subject ourselves to scrutiny by people with no editing history, by any random person on the internet? Levivich (talk) 14:17, 16 August 2025 (UTC)Reply
That's the wrong question. The right questions are
  1. Why should we assume that every proposal by someone with no immediately-visible edit history is inherently bad?
  2. Why should WP:AGF only apply to experienced editors?
Thryduulf (talk) 14:25, 16 August 2025 (UTC)Reply
  • In general, I wholeheartedly agree with the concept that to bring any complaint it should be brought in good faith. Where we have an editor with a reviewable record we have partial ways in which to assess whether the complaint is in good faith or not. But ultimately, it is the substance of the complaint that will determine the GF aspects; or more simply, don't shoot the messenger. Nevertheless, as the current AN/I thread that catalysed this discussion demonstrates, the time required of editors to make genuine assessments can be extremely lengthy and complicated. Different editors can interpret statements and phrases in very different ways - and the thread at AN/I demonstrates this manifestly. And it's this last point that raises the wider issue of prejudgement - I've had run ins with so and so, they were rude here, ah a complaint, let's go. That said, I don't think we have a widespread problem with frivilous complaints (and I'm not suggesting the current complaint at AN/I was frivilous, although I might condsider it other things) so I'm cautious about endorsing a process that would restrict complaints. However, in particular in distinction to the points raised by Snow Rise above, this is about *third-party* complaints. For those reasons I'd suggest something more along the lines of a "seconding" type system for IPs in no standing to review a third-party complaint (complaints that involve the IP would not need to follow this). Possibly by admins? Possibly by editors with a minimum level of active editing? Regards,--Goldsztajn (talk) 13:04, 16 August 2025 (UTC)Reply
    One further point - I think we need to be careful about the use of analogies in making points here. This is not a question of inclusion/exclusion, this is about credibility. Editors subject to complaints should be held to be in good standing until shown to be otherwise as determined by the edivence presented and assessed by their peers, not simply by the presence of a complaint. In making a third party complaint, some expectation of credibility is not unreasonable - did the person making the complaint demonstrate appropriate skill in presenting a legitimate complaint? This is I think the crucial conundrum; it's extremely hard to see how a third party complaint by an IP in no standing is that and only that. Regards, Goldsztajn (talk) 13:26, 16 August 2025 (UTC)Reply
No. This is basically assuming bad faith of every IP and, as if that wasn't enough, stripping more rights away from them (as if IPs aren't already under-represented in the community). WP:IP editors are human too makes a great read in situations like this. EF5 15:25, 16 August 2025 (UTC)Reply
I think this is a bad idea. Most experienced editors know that a suspected WP:LOUTSOCK can be easily taken off to Wikipedia:Sockpuppet investigations, and some of us even know that when you want to avoid retaliation, then e-mail's your friend. As a result, we're not very likely to do this. "Let's ban all the IPs, just because some small fraction of them might be bad" is incompatible with our principles, e.g., that it's the strength of the argument that matters rather than the identity of the first proposer.
More broadly, we probably do need a way for casual users to weigh in on disputes where WP:UNBLOCKABLE is being thrown around. Real accountability means that you have to give an account of your choices even to a dynamic IP, instead of saying that you're too important to respond to people who don't have at least X edits. WhatamIdoing (talk) 21:20, 16 August 2025 (UTC)Reply
Ok. Last response in this thread for me. Let's ban all the IPs, just because some small fraction of them might be bad - Nobody is saying this. I'll restate to avoid ambiguity: Let's prohibit accounts with no edits and IPs with no edit history (and who do not provide evidence of editing under another account/IP) from initiating proposals to remove someone from the project unless they're directly involved in the dispute. That's the extent of what I was suggesting, but the amount of hyperbole I'm seeing in response is enough to tell me there's not support for it. — Rhododendrites talk \\ 21:39, 16 August 2025 (UTC)Reply
I don't think VPIL ever reflects broader community consensus; I've seen too many proposals get shot down at VPIL only to easily gain consensus later (recall and admin inactivity requirements come to mind as examples). But FWIW, my thought was to propose just a prohibition on siteban proposals (the most serious kind), and only from dynamic IP editors (who are incapable of ever having an editing history), in order to test consensus, although I wouldn't be surprised if an RfC proposing the narrow version ends up with consensus for a broader application. Levivich (talk) 22:04, 16 August 2025 (UTC)Reply
There is no meaningful difference between what you say you are proposing and what you characterise as hyperbolic responses to your proposal. Thryduulf (talk) 23:21, 16 August 2025 (UTC)Reply
There's a very specific proposal being presented, mischaracterising it as something else is hyperbole. Regards, Goldsztajn (talk) 00:21, 17 August 2025 (UTC)Reply
I'm with Thryduulf: There is no meaningful difference.
Sure, my statement is an oversimplification. The OP proposes to exempt all of us from scrutiny not just from IPs, but also from newbies. It's also "only" one (more) tiny little way for editors like me to retain power and privilege against the unwashed mass of dynamic IPs and newbies rather than a total ban. But the net result, in the end, is what matters, and the net result in the end will be: Good (and bad) ideas will be rejected because of the editor's identity instead of being rejected because of the strength of the argument.
Also, the net result will be avoidable drama (How dare you agree with that IP?! Didn't you know that IPs are prohibited from making such suggestions in the royal court? Only us nobles get to suggest sanctions – those IPs and newbies are unworthy!) and confusion (Wait, what? I have to read a long rulebook before I can figure out which things I'm allowed to say on which pages?). It will also result in stupid outcomes, as some "experienced" idiot is going to think that it means IPs aren't allowed to report blatant vandals, LTAs, and other serious abusers, because they believe that starting a discussion at ANI (and especially at pages with a narrow, sanctions-oriented focus, such as WP:ANEW or WP:RFPP) is tantamount to "proposing sanctions", which would be a banned activity under this proposed rule. WhatamIdoing (talk) 01:21, 17 August 2025 (UTC)Reply
IPs that seek to delete an article require review; it's not exclusionary, it's the result of needing to manage behaviour. Implying this is a floodgates issue is simply mischaracterising the proposal. We have all sorts of limits on inexperienced editors and IPs because of 20+ years of experience. This is no different. Regards, Goldsztajn (talk) 05:45, 17 August 2025 (UTC)Reply
Here's a counterfactual - would those opposed to the proposal be willing to accept responsibility for *all* third party complaints from IPs of no standing going forward? That is, any boomerangs, counter sanctions etc resulting from a bad faith complaint will be applied to those accepting responsibility. FWIW I think that would be both outrageously unfair and stupid. Therefore, why should an editor in good standing (remember, which is different that an editor universally liked) be subject to the possibility of inaccurate (let alone wild) anonymous third party accusations with no consequence? The proposal only seeks to limit that possibility. Regards, Goldsztajn (talk) 05:58, 17 August 2025 (UTC)Reply
That's another straw man: the proposal does not limit (or even seek to limit) review or allow any accusations (made by anybody, not just IPs) to be without consequence. The only change is that all discussion of proposals must be based on the merits of the proposal not on the merits of the proposer. Discussion of the merits of the proposer will still be allowed, just in a separate (sub)thread to the proposal. Thryduulf (talk) 09:54, 17 August 2025 (UTC)Reply
@Goldsztajn, it's true that IPs that seek to delete an article require review. It's also true that if I seek to delete an article, that requires a review. Only admins – about 1 out of the 1,000 registered editors who will make 1+ edits this year – are capable of deleting an article without an admin reviewing that request. The other 99.9% of us "require review". Therefore I find that saying "IPs can't delete articles without review" is completely unrelated to whether IPs should be able to make a suggestion for a path forward in a behavioral discussion. WhatamIdoing (talk) 20:00, 23 August 2025 (UTC)Reply
@WhatamIdoing "that seek to delete" is not "delete". I should have been more specific: IPs that wish to nominate an article for deletion. Regards, Goldsztajn (talk) 23:47, 23 August 2025 (UTC)Reply
Yes, IPs require some technical assistance to start an AFD. They don't require any such assistance to start a PROD or CSD. And admins can delete CSD-worthy articles on sight, even if nobody else has nominated the article. WhatamIdoing (talk) 23:53, 23 August 2025 (UTC)Reply
  • If an IP editor is expected to provide previous IPs to demonstrate editing history do we also need a mini-SPI mid-ANI to prove behaviourally that they are the same user? It would be easier for a malicious user to shovel out fake IPs than for an actual IP editor to dig up all their previous ones. If the proposal that triggered this conversation was (for the sake of argument) raised by a previously involved editor, what consequences would they be dodging by logging out? REAL_MOUSE_IRL talk 12:25, 17 August 2025 (UTC)Reply
With the obvious exception for disputes in which the IP/new user is involved, I support this. In specific I'd suggest requiring extended-confirmed. We already do that for particularly contentious topic areas, and there's few things more contentious than bringing someone to ANI. Loki (talk) 01:08, 19 August 2025 (UTC)Reply

Alternate idea: make WP:FOC apply to projectspace proposals

edit

An alternate idea I had in mind (and briefly mentioned above) is to extend WP:FOC to projectspace proposals (it currently only applies to articles). This is to avoid derailing proposals based on their provenance, and instead focus the evaluation on their merits. To clarify, if a new user bears the hallmarks of a suspicious sock, relevant discussion can take place (separately from the discussion of the proposal) and action can still be taken if the suspicions are confirmed, which could lead to the proposal's closure if no one else endorsed it. Chaotic Enby (talk · contribs) 11:43, 16 August 2025 (UTC)Reply

I cannot see any downsides to this. Thryduulf (talk) 12:05, 16 August 2025 (UTC)Reply
This would not affect the preceding incident, which involved an IP rather than a new user, and was on an administrative board rather than a project one. On a related note, strictly speaking IPs cannot be confirmed as sockpuppets, they can only be heavily suspected. CMD (talk) 13:49, 16 August 2025 (UTC)Reply
To clarify, I meant projectspace as including the whole namespace, rather than a specific subset of project-oriented boards. Chaotic Enby (talk · contribs) 14:48, 16 August 2025 (UTC)Reply
If you include boards such as AN/I, that is a complete philosophy change from the current principle editors who post to AN and AN/I are also open to scrutiny. CMD (talk) 16:31, 16 August 2025 (UTC)Reply
Reporters are open for scrutiny, and changing that is not proposed. The only change would be that when someone (anyone) makes a proposal discussion of that proposal needs to remain focused on that proposal. The reporter's conduct is and will remain firmly open for scrutiny, it just needs to happen in a different (sub)section to discussion of their proposal. Thryduulf (talk) 16:36, 16 August 2025 (UTC)Reply
Exactly. Adding to this, the general discussion (that usually and ideally takes place before specific sanctions get proposed) can touch on the behavior of everyone involved. I just want the discussions of sanction proposals to be streamlined, so that issues with one editor's conduct don't derail a proposal for sanctions on another editor. Chaotic Enby (talk · contribs) 16:41, 16 August 2025 (UTC)Reply
A little formalistic and bureaucratic, but honestly ANI could arguably use a little more structure in that respect. This seems like it would preserve the access of IP editors to the process, but create a channel for any legitimate discussion about abusive proposals. I really only have two concerns. 1) it's not the most intuitive idea in the world, especially for free-wheeling ANI, so I'm wondering if people won't become easily confused about how to initiate and proceed with such side discussions, and 2) I worry that formalizing a process for investigating the basis of proposals will lead to automatic (and quickly streamlined and weaponized) witch hunt responses to every IP proposal. SnowRise let's rap 00:39, 17 August 2025 (UTC)Reply
Regarding 1), I agree – we have to strike a balance between "free-for-all" and "complicated ruleset", and, while ANI often feels a bit too close to the former, we should be careful about keeping it intuitive enough. Maybe admins could add a reminder template at the top of proposals if they see them derailing?
For 2), I understand your worry, but I have the hope that these "retaliatory proposals" won't be much of a thing. Suggesting WP:BOOMERANG sanctions on a new user/IP with no evidence beyond a lack of edits might be seen as WP:ASPERSIONS, and I am (maybe too) optimistic that they will be shot down by the community if nothing more is provided. Chaotic Enby (talk · contribs) 00:47, 17 August 2025 (UTC)Reply
That is not how WP:FOC works at all. We don't create subsections on RfCs to discuss the nominator. CMD (talk) 16:42, 16 August 2025 (UTC)Reply
Yes, that is because RfCs are not the place to discuss such issues – sorry for my imperfect analogy. But if a RfC's nominator shows conduct issues, then WP:FOC doesn't make them immune to scrutiny, but their conduct shouldn't be a factor in !voting for or against the RfC. Instead, it is to be taken to an appropriate place (usually ANI).
In the same way, an ANI commenter's conduct isn't immune to scrutiny either, but it shouldn't come into play in !voting for or against their proposal, and is to be taken to an appropriate place (a (sub)thread not already focused on a separate proposal). Chaotic Enby (talk · contribs) 16:48, 16 August 2025 (UTC)Reply
Thanks for the clarification. So adding structure to AN/I? Happens sometimes, but requiring new threads/subthreads to discuss each individual editor is something that is not currently used in structured areas such as WP:AE. It also seems unlikely that the two subsections would not bleed into each other anyway, especially as we expect variation in existing proposal discussion anyway. eg. a block proposal may include !votes for ibans, page protections, etc., which can be heavily affected by the editors involved. CMD (talk) 17:01, 16 August 2025 (UTC)Reply
Thanks! Yep, exactly, adding structure to AN/I is what I had in mind. Similar in spirit to FOC, but if it doesn't fit neatly, it can be a separate guideline. I don't think threads/subthreads for each individual editor are needed, as most ANI threads start with a general discussion of facts. It is only when specific sanctions are proposed that I don't want to see an editor's behavior influence sanctions for another. Which is not just about the proposer, by the way. For another example, if editors A and B were on the same side of a dispute, and editor A's behavior in it was less than ideal, then this shouldn't be used as an argument to !vote for sanctions against editor B.
I agree that various proposals are likely going to be made, and, given the diversity of suggestions added in new !votes, I don't think this should be a firm rule – more of a guideline to avoid threads completely derailing. Chaotic Enby (talk · contribs) 17:09, 16 August 2025 (UTC)Reply
?? The premise here is proposing sanctions on contributors. In one of the only forums where we focus on contributors, not content. What you're actually proposing, in effect, is that when someone focuses on a contributor, proposing to do remove that person from the project completely, then that user becomes off limits for scrutiny. — Rhododendrites talk \\ 14:25, 16 August 2025 (UTC)Reply
Eh? What Chaotic Enby is sugesting is that when someone proposes to remove a person from the project completely (or indeed proposes anything else) that discussion focuses on the merits or otherwise of the proposal not the merits or otherwise of proposer. If you want to discuss the merits or otherwise of a person making a proposal, start a separate discussion about that person so you don't derail the discussion about their proposal. Thryduulf (talk) 14:33, 16 August 2025 (UTC)Reply
Yes, that is exactly what I had in mind. If editor A proposes a sanction against editor B, then editor A isn't off-limits, but any discussion of their conduct should be a separate proposal (like Suggestion: WP:BOOMERANG sanction for Editor A) to avoid derailing the original discussion. The "content" analogy might not be perfect, but my idea is that discussion of a given proposal should focus on the substance of the proposal itself (which in this example relates to whether editor B's conduct warrants a sanction). Chaotic Enby (talk · contribs) 14:44, 16 August 2025 (UTC)Reply
Strong oppose to that. We should have more care for our contributors than to put on blinders to the context and provenance of the proposal. This is "AGF is not a suicide pact" stuff. That doesn't mean I'm unfamiliar with the concept of attacking the proposer in order to derail, but IMO the harm of making the proposer off-limits for scrutiny is worse than having to sift through efforts to derail. I'm much more interested in ensuring procedural integrity for the sake of the person who might be ejected from the project, and provenance is part of that. Yes, these threads can be chaotic as people scrutinize the proposer, but that's often because of disagreements on whether to look at the proposer. There are two ways to fix that (that I can think of): one preserves all proposals, providing those trying to remove people from the project first-mover advantage, including socks and SPAs, and makes the proposer off-limits (requiring separate discussions to take place in parallel to address that user, all the while their proposal moves forward); the other says "if you're not involved and you don't have an edit history, you don't get to try to remove people from the project". — Rhododendrites talk \\ 15:04, 16 August 2025 (UTC)Reply
No blinders are being suggested let alone proposed, you're arguing against a straw man. Try reading what is being proposed again and responding to that rather than an imagined bogeyman. Thryduulf (talk) 16:37, 16 August 2025 (UTC)Reply
Reread. Same understanding. [Beyond FOC being largely unintelligible to mean "focus only on one contributor at a time] - If a brand new account or IP with no edit history opens a proposal to indef/ban someone, the default should not be to start a separate process to analyze the proposer, which will take who-knows-how-long, while the subject is thrown into the stressful situation of defending themselves against a sanction -- we would be treating the proposal as if it came from anyone else. At best it renders criticism of the proposal invisible by removing it from the site of the proposal itself. I am surprised to see people supporting the idea. Better to have the first supporter take over the proposal, or else remove it if nobody steps forward to do that (and if the new account doesn't provide evidence that they're either involved or have a prior edit history, of course). — Rhododendrites talk \\ 16:52, 16 August 2025 (UTC)Reply
It won't at all render criticism of the proposal invisible, because criticism of the proposal is not the same thing as criticism of the proposer (which will also not be prohibited or invisible, just focused). Thryduulf (talk) 16:57, 16 August 2025 (UTC)Reply
Sorry if I wasn't clear, but the separate process shouldn't be to analyze the proposer as a prerequisite to do anything with the original thread, it is just if someone feels the need to discuss the new account's conduct. Of course, if no one supports a proposal, then it can naturally be closed as WP:SNOW to avoid undue stress, without needing for another proposal's thread to conclude first.
Regarding the FOC analogy, I see it as "focus on the content (of the proposal)". It isn't about the number of contributors involved – someone could suggest an IBAN between two contributors, and the discussion of whether the interactions between the two rise to that level would still be focused on the content of the proposal. Chaotic Enby (talk · contribs) 16:59, 16 August 2025 (UTC)Reply
I'd support this. I brought this exact thing up at the AN/I thread yesterday but was mostly met with sarcastic responses, so it may be a minority viewpoint. While it's important to discuss people who are brought up, discarding entire proposals simply because the proposer is someone with less experience than others shouldn't be a common thing, as it derails the thread (i.e. the current ANI) and leads mostly to bickering. EF5 15:31, 16 August 2025 (UTC)Reply
"FOC" ("focus on content") isn't the perfect way of describing this idea, but I think the intention behind it is sound. We'd just have to sort out a way to explain what we mean, which would allow:
  • Alice complains about Bob's behavior.
  • Bob complains about Alice's behavior and suggests a WP:BOOMERANG.
  • Chris complains about both of their behavior.
  • David says that both of their behavior is fine.
  • An IP editor suggests a sanction on one (or both) of them.
but does not allow:
  • Eve to say that IPs/newbies/people whose WP:CUSTOMSIG includes an emoji/whatever have no business suggesting sanctions against registered editors.
WhatamIdoing (talk) 21:25, 16 August 2025 (UTC)Reply

Working towards a policy on generative AI

edit
Latest comment: 6 days ago16 comments10 people in discussion

I've written out here what I think are the de facto community expectations of what acceptable use of generate AI/LLMs are; in the enforcement section I've written a suggested framework for dealing with it. Please, suggest changes. Cremastra (talk · contribs) 23:14, 16 August 2025 (UTC)Reply

This looks like a great start! Asking an LLM to find sources on a topic, and then using those sources in the usual manner. should explicitly exclude "asking LLMs to read/summarize the sources for you" (or it could be added in a "Restricted" bullet point), as this is something I've seen quite often. LLMs are prone to misinterpret sources and add synthesis not present in the original material, and relying on an LLM's interpretation of sources can be very risky. Chaotic Enby (talk · contribs) 23:36, 16 August 2025 (UTC)Reply
This "Restricted" bullet point could also include "asking AI to add sources to your writing, and not checking if those sources verify the text".
On another point, the "Discouraged" use could mention that rewording by AIs is at risk of introducing synthesis and editorializing, and that it should at the very least be proofchecked for a neutral tone.
Something that I don't see mentioned (and that might be a more controversial) is how we might, if at all, decide whether something counts as a "confirmed use" of AI beyond the unambiguous G15-like tells. Additionally, I feel like a rigid series of warnings/partial blocks might not necessarily be the best option, and a more flexible approach could be taken (for instance, if someone abuses projectspace, a mainspace block doesn't necessarily make sense, while for someone who clearly doesn't care about stopping, going through a partial/timed block and then a warning before an indef might be unnecessary). Going straight from initial to final warning might also be a bit of an escalation, compared to our (usually) 4-step warnings – although, of course, jumps can be made in obvious cases. Chaotic Enby (talk · contribs) 23:44, 16 August 2025 (UTC)Reply
I wonder why not just elevate WP:LLM to a guideline? It seems much more fleshed-out and I don't see any deficiencies in it for a newly-written guideline to correct. Loki (talk) 00:04, 17 August 2025 (UTC)Reply
The problem is that (1) there was an RfC to raise WP:LLM to guideline, and it failed, and (2) that essay is ridiculously bloated and oversized, IMO. Cremastra (talk · contribs) 00:20, 17 August 2025 (UTC)Reply
The thing is that if it isn't policy then we're contradicting ourself by saying that editors simultaneously are and aren't really doing anything wrong. WikiEdu, for instance, has an entire student handout about using AI that discourages but stops short of restricting a lot of this. Gnomingstuff (talk) 01:29, 17 August 2025 (UTC)Reply
How about {{policy|type=section}}? 174.138.218.72 (talk) 12:55, 17 August 2025 (UTC)Reply
Thanks for writing this out, Some thoughts besides what I mentioned above:
  • In the section on using AI to find sources there should be something about how the sources still need to be reliable, relevant, etc.
  • "Asking an LLM to write an article or draft on a topic" doesn't cover everything, very frequently it's new sections or paragraphs but still substantively new material.
  • I would add a step 0 to "How do we respond?" -- ask the writer, neutrally and non-accusatorily, whether they are using AI and how. Best way to confirm it is if someone says so.
Gnomingstuff (talk) 01:27, 17 August 2025 (UTC)Reply
The draft seems to use AI and LLM interchangeably. Personally, I'm not in favour of singling out specific technologies. I'd prefer to set policy based on using any form of text generator, regardless of underlying implementation. isaacl (talk) 02:18, 17 August 2025 (UTC)Reply
On the other hand, "AI" is a very vague term – maybe clarifying "generative AI" could be more helpful? It would still include future AI models that wouldn't be based on a large language model framework, but still be able to generate text (see multimodal learning). Chaotic Enby (talk · contribs) 11:47, 17 August 2025 (UTC)Reply
Yes; that's why I didn't use AI in my suggestion. (I appreciate that the full wording would exempt mail merge/skeleton-based content, as such content isn't what people are concerned about with respect to this particular discussion). isaacl (talk) 16:40, 17 August 2025 (UTC)Reply
@Cremastra How about mentioning something about using LLM to write your talkpage posts? Gråbergs Gråa Sång (talk) 07:19, 17 August 2025 (UTC)Reply
That part is already covered under WP:HATGPT and {{beepboop}}, although, if this new policy gets passed, it could be moved/duplicated there. Chaotic Enby (talk · contribs) 11:40, 17 August 2025 (UTC)Reply
I think this is a good start but will need some further refinement, especially in the enforcement guidance. I think "AI" is an unhelpfully vague term. I would say something more like "technology in which the substance of a contribution, and not merely the form, is generated by the tool". That gets to the heart of why bad forms of AI use are bad: wiki contributors are expected to contribute their own thoughts and decision-making skills. I would also like to see a stronger expectation of disclosure of AI use, as disclosure mitigates a lot of the worst AI harm. -- LWG talk 23:58, 17 August 2025 (UTC)Reply
Agreed. Laypeople have been using the term "AI" for years before the concept of LLMs and GPTs were ever even conceived. Although the media might be latching onto this term as a catch-all for such tools, it's not helpful in allowing us to distinguish between LLM and non-LLM usage. Duly signed, ⛵ WaltClipper -(talk) 12:37, 22 August 2025 (UTC)Reply
Just a quirk of the wording, but a tweak could make it clear that AGF should be applied to all categories, not just the third one. It's often a misunderstanding of the risks, similar to why we restricted previous translation tools. CMD (talk) 00:47, 18 August 2025 (UTC)Reply

A guideline for how to deal with Wikinews?

edit
Latest comment: 5 days ago24 comments10 people in discussion

I have obvious concerns about when wikinews content is linked within enwiki articles in a way that could violate BLP, see [8] and [9]. This got me down the path of looking at how often this template is transcluded in the first place: [10]. I haven't had a chance to comb through them all but spotchecking has made me realize that a lot of these are kind of awkwardly shoved into sections (for example, someone famous dies and then the wikinews obituary gets its own highlight in that section specifically or election information will include a link to an interview with the candidate). I don't see why we give priority to user generated content like this. Is anyone opposed to a restriction like "if wikinews is incorporated into article content, it must be in the external links section"? Clovermoss🍀 (talk) 02:35, 19 August 2025 (UTC)Reply

Hasn't Wikinews been dealt with permanently? I thought that project is being closed down. TurboSuperA+[talk] 07:45, 19 August 2025 (UTC)Reply
That doesn't mean they'll remove the existing news stories. I would suggest a simple guideline would be to treat Wikinews like other external links, which does mean they will usually not appear in the article content. CMD (talk) 07:58, 19 August 2025 (UTC)Reply
I would suggest a simple guideline would be to treat Wikinews like other external links
That is a good solution. TurboSuperA+[talk] 08:11, 19 August 2025 (UTC)Reply
Well it's what I suggested in the first place so it's good that at least so far no one has any objections. Clovermoss🍀 (talk) 10:15, 19 August 2025 (UTC)Reply
Sorry, my intention wasn't to make it sound like it was Chipmunkdavis' idea, I just responded to their comment. TurboSuperA+[talk] 10:28, 19 August 2025 (UTC)Reply
It's not something that anyone needs to apologize for, just a detail that mattered to me a bit on personal level. Clovermoss🍀 (talk) 12:21, 19 August 2025 (UTC)Reply
I apologised because I know how it feels, and I understand what you mean. The apology was also on a personal level. TurboSuperA+[talk] 16:20, 20 August 2025 (UTC)Reply
Not necessarily. Currently being discussed still on Meta. --Super Goku V (talk) 05:15, 24 August 2025 (UTC)Reply
Since Wikinews falls under WP:UGC, I would be even stricter even in the external links section: WP:ELNO #12 discourages open wikis, and I don't see Wikinews in particular as being especially valuable compared to other sources. It doesn't add a unique type of content like Commons, Wikisource or other sister projects, and the current situation feels like giving prominence to it over better news outlets simply because of its Wikimedia affiliation. Chaotic Enby (talk · contribs) 13:15, 19 August 2025 (UTC)Reply
Interesting, #12 also states that except those with a substantial history of stability and a substantial number of editors. I don't think wikinews qualifies as either. My suggestion was meant to be a bit of a middle ground since wikinews links are in areas other than external links to begin with (a random example is Colin Powell#Other foreign policy issues). But I do think your option is important if this gets to the level of an RfC. Clovermoss🍀 (talk) 14:57, 19 August 2025 (UTC)Reply
I am fairly sure we reached a consensus not to cite wikinews -quite a while ago. However, it is possible that citations existing prior to that consensus were “grandfathered” (we did stuff like that back in the “old” days - as a way of compromising when consensus was mixed). Also possible that we simply never got around to removing all the links. Blueboar (talk) 21:57, 19 August 2025 (UTC)Reply
From what I understand, the links to Wikinews aren't used as traditional citations, but more as a "see also" kind of thing interspersed in the article, which is not ideal. External links also have different standards compared to citations (e.g. Wikipedia:External links/Perennial websites), so consensus on one doesn't imply consensus on the other. Chaotic Enby (talk · contribs) 22:01, 19 August 2025 (UTC)Reply
Unless the Wikinews article is being directly mentioned in the text of the Wikipedia article (e.g., "The English Wikinews went viral when they published an article titled Top Ten Reasons to Edit A Wiki.[indepent source]"), then links to it should only appear in the ==External links== section, where they should normally use Template:Wikinews or Template:Wikinews inline (or equivalent). WhatamIdoing (talk) 22:32, 19 August 2025 (UTC)Reply
Looking at {{Wikinews}}, the documentation does state that the template shouldn't be used in the main body of the article, so that's good. Although it appears to be at odds with some of its actual uses, like the one mentioned above. Chaotic Enby (talk · contribs) 22:36, 19 August 2025 (UTC)Reply
In terms of WP:ELNO#EL12, the purpose is to determine whether the wiki has enough users and activity to deal with any blatant vandalism or other serious problems that crop up. Generally, if you look at Special:ActiveUsers (or the equivalent for wikis that don't use MediaWiki software), you want to see at least several dozen editors – say, a minimum of 50 registered editors who actually made an edit during the last month, though you might raise the baseline a little if it's a super-sensitive subject, or lower it a bit if it's a low-controversy subject.
We don't normally apply this rule to Wikipedia:Wikimedia sister projects, as they fall under WP:ELMAYBE #5. WhatamIdoing (talk) 22:29, 19 August 2025 (UTC)Reply
True, but might ELMAYBE #5 be implicitly presuming that our sister projects would have enough participation to not fall under ELNO #12? Chaotic Enby (talk · contribs) 22:34, 19 August 2025 (UTC)Reply
No, it isn't. (As in: We had specific conversations in the past about the bar being lower for sister projects than for external wikis.)
Given the existence of groups such as m:Global sysops and m:Small Wiki Monitoring Team, I suppose someone could argue that the local editor count wasn't necessarily a full description of the people keeping an eye on the sister projects' contents. WhatamIdoing (talk) 01:32, 22 August 2025 (UTC)Reply
Thanks, that's reassuring to know! Chaotic Enby (talk · contribs) 12:56, 22 August 2025 (UTC)Reply
m:Public consultation about Wikinews is still open. I haven't looked in on it in a while. When I was watching it, I was not impressed by what I saw from the proponents of keeping Wikinews open, but perhaps others would have a different view. WhatamIdoing (talk) 22:15, 19 August 2025 (UTC)Reply
The action is now mostly happening at meta:Requests for comment/Sister Projects next steps Bawolff (talk) 00:35, 20 August 2025 (UTC)Reply
Already closed Ymblanter (talk) 12:33, 20 August 2025 (UTC)Reply
I don't really have strong feelings either way since I don't edit Wikinews and know the background as well as others. What I do care about is that their articles aren't meant to be updated (going by talk page comments on that consultation, it's a key part of how operate), which leads to content incompatible with enwiki's BLP policy like in the diffs I opened the thread with. This would still matter even if Wikinews suddenly revitalized itself tomorrow. Blueboar, is there any chance you know how to find the previous discussions you remember about similar issues? Clovermoss🍀 (talk) 15:15, 20 August 2025 (UTC)Reply
We already have WP:MOSSIS, a guideline which says "Links to Wikinews should not be made within the main body of an article, being made only as per the external links guideline." I believe it was the result of this RfC. Firefangledfeathers (talk / contribs) 01:46, 22 August 2025 (UTC)Reply

A Learning Management Platform - The Wiki Walkthrough

edit
Latest comment: 5 days ago14 comments8 people in discussion

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

Option to exclude redirects and disambiguation pages from Special:AllPages

edit
Latest comment: 5 days ago3 comments3 people in discussion

Honestly it's kinda baffling how there's currently no way to browse the full list of articles; only full list of pages. Sapphaline (talk) 15:08, 22 August 2025 (UTC)Reply

Regarding redirects, you may want to review T173479 and T387537. Excluding disambiguation pages would be much of the same, but without a simple solution like T387537 proposes. Anomie⚔ 17:23, 22 August 2025 (UTC)Reply
Given that there are about 7,000,000 articles, there's no realistic way for a human to browse them all anyway. At one second each, 24 hours a day, it would take 80 days to look at the list. WhatamIdoing (talk) 20:11, 23 August 2025 (UTC)Reply

This week's article for improvement

edit
Latest comment: 1 day ago20 comments9 people in discussion

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
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 →   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

Establishing a precedent

edit
Latest comment: 1 day ago9 comments5 people in discussion

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

The problem of AI generated deletion nominations

edit
Latest comment: 9 hours ago35 comments10 people in discussion

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
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
Add topic
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)&oldid=1308348575"