Jump to content

Wikipedia:Village pump (idea lab)

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

Before commenting, note:

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

Discussions are automatically archived after remaining inactive for 10 days.

« Archives, 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]

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]
  • 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]

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]

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]

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]
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]
  • As I pointed out above, though, the recalls focused on inactivity also accused the administrators in question of WP:GAMING the existing inactivity requirements. I'm of the opinion that gaming is very different than just being inactive - an administrator who is intentionally gaming the activity requirements is abusing policy in a way that is, at least, clearly valid basis for a recall. Any restriction on recalls or petitions for inactivity would IMHO need to have a clause that it doesn't apply to accusations that an admin is gaming the activity requirements; such concerns are clear WP:ADMINCOND violations. (And since, so far, all the concerns about inactivity have focused on gaming, I don't think this change is necessary at all - this isn't about editors trying to backdoor through tighter activity requirements; it's editors pointing out what they believe to be conduct violations. Gaming the administrator activity requirements is no different than eg. gaming extended-confirmed, and we shouldn't let it pass just because the people in question are administrators.) If you want a fixed version of your proposal I would append This restriction does not apply to any case where an admin has been accused of WP:GAMING the activity requirements, which is a legitimate basis for a recall - but as I said, this makes the entire proposal moot because I suspect "inactivity"-based recall attempts will always actually be about misconduct due to gaming the activity requirements. --Aquillion (talk) 13:31, 5 August 2025 (UTC)[reply]
    I broadly agree with Thryduulf on this, those who want stricter inactivity requirements should do so by getting consensus for a change, not by demonstrating that they have 25 supporters of that stricter criteria. After all there could be hundreds who disagree with the stricter requirements, but that would be irrelevant if there were 25 who didn't have consensus but had found a way to act without consensus. I'm in a slightly different position though in that I think there could be instances where people game the system. For example if someone only met the activity requirement by creating some pages in their userspace and then immediately deleting them U1, then it would be fair to accuse them of gaming the system. But that would involve not just doing the minimum but creating the work that required that minimum. ϢereSpielChequers 19:13, 5 August 2025 (UTC)[reply]
    If someone is doing something like that, and talking to them about it hasn't achieved anything, and an AN(I) discussion has not resulted in them changing their ways and you cannot point to some actual (not theoretical) harm their having the tools is causing (if you can point to that, you can use that harm as the basis for recall) then you can always initiate an arbitration request as it will be a problem the community cannot solve. Thryduulf (talk) 22:36, 5 August 2025 (UTC)[reply]
    This is a repeated strawman, none of the recalls have been about getting 25 signatures for stricter procedural inactivity criteria. If you think there should be stricter procedural inactivity requirements, or perhaps inactivity requirements that are related to something other than procedural rights expiration, then please raise that in the positive case, but it wouldn't really affect any of the recalls that have happened so far. CMD (talk) 02:33, 7 August 2025 (UTC)[reply]
    If hundreds disagree with the stricter requirements, then the RRFA will fail. Hawkeye7 (discuss) 22:29, 7 August 2025 (UTC)[reply]
    Assuming it gets that far given what happened with the only RRfA so far. --Super Goku V (talk) 06:38, 8 August 2025 (UTC)[reply]
  • Sorry, I'm coming to this very late and there's a lot of discussion to read. But as a suggestion for an approach that could be taken in an RfC: when their recall petition was filed, Night Gyr hadn't used the tools at all in 11 years. I doubt that there's a single person who considers that to be an acceptable level of usage. If so, we can approach the question of "How recently should an admin have used the tools?" in the style of a Dutch auction and work down from that figure until we collectively hit upon an answer. What degree of weighting should be applied to that in combination with their use of regular edits can be examined separately.  — Hex • talk 14:21, 10 August 2025 (UTC)[reply]
    I doubt that there's a single person who considers that to be an acceptable level of usage. I don't care how often an admin is using the tools, as long as they use them correctly and appropriately when they are used and their account remains secure then everything else is irrelevant. The activity requirements were intended only to be a proxy for ensuring that someone remains in touch with community norms about correct and appropriate use of tools and for reducing the chances of account compromise, and we need to get back to that rather than all this hand-wringing and moral panic about gaming the system and appropriate activity levels. Thryduulf (talk) 15:44, 10 August 2025 (UTC)[reply]
    I don't care how often an admin is using the tools
    Thanks for the insight.  — Hex • talk 21:57, 10 August 2025 (UTC)[reply]
    That is a good summary. If you have not used tools in 11 years, one you don't need them anymore, and two I would not trust you to use them within current community norms. That is textbook the reason why we even have activity requirements. I would strongly support strengthening requirements to help prevent gaming. It has been the standard understanding until recently when some have tried to argue that it should be as written, instead of the normal intended. We need to bring the current wording in line with the current community understanding. PackMecEng (talk) 17:32, 10 August 2025 (UTC)[reply]
    I see no evidence that anything has changed, other than a small number of vocal users suddenly getting upset that some people are less active than they would personally like. Thryduulf (talk) 17:53, 10 August 2025 (UTC)[reply]
    I saw a lot of pearl clutching that we shouldn't enforce the spirit of the rule vs rule lawyering away from how it's always been treated. PackMecEng (talk) 17:58, 10 August 2025 (UTC)[reply]
    I see no evidence that the spirit of the rule is anything other than what is written, despite all the evidence-free assertions to the contrary by those who want to enforce something other than what gained consensus. Thryduulf (talk) 17:59, 10 August 2025 (UTC)[reply]
    Thryd, I'm insulted and disappointed that after months, and thousands of words of discussion, this is how you summarize the position of me and others. How disrespectful. Levivich (talk) 18:07, 10 August 2025 (UTC)[reply]
    I've read all those thousands (if not more) words of discussion. Despite all of the grand claims made to try and justify enforcing your dislike, I am unconvinced that my summary is inaccurate. Thryduulf (talk) 18:15, 10 August 2025 (UTC)[reply]
    Well, as long as you're unconvinced that your disrespectful summary is inaccurate, then it's fine. Levivich (talk) 21:07, 10 August 2025 (UTC)[reply]
    I don't see how stating my sincerely held belief is at all disrepectful either. Thryduulf (talk) 21:11, 10 August 2025 (UTC)[reply]
    Well, as long as you sincerely believe that I'm part of a vocal minority making grand claims to try and enforce a personal preference I like, how could saying so possibly be disrespectful? Levivich (talk) 21:14, 10 August 2025 (UTC)[reply]
    Good question. Thryduulf (talk) 21:16, 10 August 2025 (UTC)[reply]
    Yea, it’s a gross misinterpretation of our viewpoints. Don’t try to generalize an entire group/viewpoint if you unironically can’t understand where we come from when voicing our concerns. EF5 22:00, 10 August 2025 (UTC)[reply]
    Despite all your protestations to the contrary, literally every explanation for your viewpoints has boiled down to either "I don't like how active this user is" and/or "I don't like the manner in which this user is meeting the activity criteria" (I've explained this in detailed rebuttals to the arguments when they've been made). Unsubstantiated accusations of gaming the activity are a dislike of the manner in which someone is active. It is not a mischaracterisation to summarise your desire to interpret the inactivity policy in a way that allows you to enforce that dislike, despite never having attempted to get consensus for that interpretation, as exactly that. Thryduulf (talk) 22:08, 10 August 2025 (UTC)[reply]
    Thyr, I recommend stepping away from this subthread. Multiple editors, including myself, agree that your comments are a mischaracterisation. You have a right to disagree, just not to badger.
    In the interest of not beating dead horses for the 10th time this discussion, I strongly urge you to step away and let your current comments speak for themselves.
    I have the same request for others as well, we have clearly articulated our takes on GAMING so far, there is no need to argue again and derail the rest of proposal building.
    Apologies for my otherwise spotty activity, I plan to finish my coding of these stats and start the RFC I planned to, sometime in the next couple weeks. Soni (talk) 04:15, 11 August 2025 (UTC)[reply]
    Hi Hex, and welcome. We are considering holding an RfC on increasing the activity requirements, and one option on the table is some requirement for admin actions. Many people feel that consideration of those activity questions was inappropriate while we sort out a related matter: how should recalls based (at least in part) on activity levels be handled. That, rather than tweaking the activity minimum, is the purpose of this section. The discussions above that were more focused on INACTIVITY have gone a bit stale, but I still anticipate we'll revive the discussion at #RFCBEFORE on WP:INACTIVITY eventually. Firefangledfeathers (talk / contribs) 18:05, 10 August 2025 (UTC)[reply]
    Hey, thank you. I've not had a lot of time to be present for policy discussions of late, so hoping I can participate more in future.  — Hex • talk 22:05, 10 August 2025 (UTC)[reply]

Automatic IP block exemption

[edit]

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

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

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

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

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

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

Distinct styling for Simple Wikipedia

[edit]

When I stumble across a Simple Wikipedia article on mobile it is not easy to realise I am viewing the "cut-down" wiki.

I Google searched vulkan wikipedia, scrolled down by habit as I often do to skip the Google AI summary and ad nonsense, saw the Vulkan (API) result with the Wikipedia logo and started reading. I was surprised by the lack of breadth, quality and outdatedness of the article. I was inadvertently reading the Simple Wikipedia version.

On Chrome mobile you can't see the start of the url, the logo bar is the same as regular Wikipedia and even Simple's Main page gives no clear indication of the difference.

This isn't the first time I have been caught out using Simple Wikipedia via a Google search.

I suggest that Simple Wikipedia gets a distinct logo bar or tagline on mobile. I will mention this discusiion on Simple's Village pump. Commander Keane (talk) 23:36, 26 July 2025 (UTC)[reply]

There is nothing we can do or meaningfully say about this here. We do not (and should not) have any influence over the appearance of other projects. Thryduulf (talk) 00:26, 27 July 2025 (UTC)[reply]
For sure it is a Meta issue. I am just noting it here (and at Simple Wikipedia) as participation at Meta is generally limited. If someone has the energy to persue the situation please ping me at the relevant discussion. Commander Keane (talk) 09:40, 27 July 2025 (UTC)[reply]
IF you are soliciting input to discussion elsewhere, then please be explicit about that and provide a link to that discussion. Your initial message reads to me as though you will be inviting editors at the Simple English project to contribute to the discussion here. Thryduulf (talk) 11:46, 27 July 2025 (UTC)[reply]
You could change your skin here or on simple, then you immediately notice when you are on the other page. (Also makes getting logged out more noticeable). —Kusma (talk) 11:55, 27 July 2025 (UTC)[reply]
But the occasional random logouts would again make it undifferentiable since MinervaNeue simplewiki looks exactly the same as MinervaNeue enwiki. Aaron Liu (talk) 14:29, 27 July 2025 (UTC)[reply]
I agree that the similarity between Simple and En wiki can be confusing, especially for casual readers. Making the tagline "From Simple English Wikipedia, the free encyclopedia" more prominent can help. Ca talk to me! 15:47, 3 August 2025 (UTC)[reply]
I think it's alright on desktop and the problem's pretty much just on mobile. Aaron Liu (talk) 18:16, 3 August 2025 (UTC)[reply]

A userscript to detect WP:OWN behaviour - it would be nice if it was built into MediaWiki

[edit]

I wrote a Tampermonkey userscript to detect WP:OWN behaviour: User:Félix An/Who dominates your article?

It would be nice if this feature was built into MediaWiki. Félix An (talk) 13:59, 28 July 2025 (UTC)[reply]

Pick a random article, click on history, and at the top you have "page statistics". This includes both the top editors by bytesize and by edit count. Neither of these indicates WP:OWN though. Number of reverts might be a slightly better indicator, but even then it is most likely an editor protecting a page from vandalism. Fram (talk) 14:10, 28 July 2025 (UTC)[reply]
WP:Own is really about other offenses that are rooted in a sense of ownership of the article. It isn't about being the most active editor/contributor. Sincerely, North8000 (talk) 14:20, 28 July 2025 (UTC)[reply]
From a technical perspective this doesn't have to be a *Monkey script. MediaWiki has its own way of loading userscripts; see mw:Manual:Interface/JavaScript and/or Wikipedia:User scripts#How do you install user scripts?. It also provides far better interfaces: for example, to access the API, you can use wmdoc:mediawiki-core/master/js/mw.Api.html instead; to add a subtitle, you can use wmdoc:Wikipedia:User scripts#How do you install user scripts?; and to get the page title, you can use mw.config.get, which is documented in the Interface/JavaScript page I linked above. Nice to see another editor interested in scripts here! Aaron Liu (talk) 16:47, 28 July 2025 (UTC)[reply]
To add to what other editors have said, we also have XTools which is pretty helpful for that stuff, and which you can incorporate into your script with mw:XTools/API. Chaotic Enby (talk · contribs) 18:43, 28 July 2025 (UTC)[reply]
One limitation I noticed is that your script seems to only look at the 500 most recent revisions. Skynxnex (talk) 20:22, 28 July 2025 (UTC)[reply]
(A side note on byte/edit counts: there does have to be an upper limit to the number of revisions processed, because processing takes time. The 500 here is probably mw:API:revisions's max rvlimit; at XTools we can do 50k because we directly query the replicas; but everything has to stop at some point. — Alien  3
3 3 17:56, 2 August 2025 (UTC))[reply]

Thanks a thanks

[edit]

Sometimes I want to show appreciation for a thanks but obv messaging people is a bit much, maybe you could thanks a thanks, like a mini high-five Kowal2701 (talk) 22:26, 30 July 2025 (UTC)[reply]

People should lessen spamming appreciation messages on talk pages and focus more on building articles. See WP:NOTSOCIAL. Ahri Boy (talk) 04:18, 31 July 2025 (UTC)[reply]
It’s not on talk pages, it’s the thanks tool. Efforts to make a friendlier and more collegial environment are conducive to building articles, quality ones at least Kowal2701 (talk) 11:44, 31 July 2025 (UTC)[reply]
I don't see how you got the impression of thanks spam from what Kowal said. Aaron Liu (talk) 14:06, 31 July 2025 (UTC)[reply]
I think I saw a "thanks for your thanks" template once. Gråbergs Gråa Sång (talk) 08:26, 3 August 2025 (UTC)[reply]
{{Because you thanked me}}. DMacks (talk) 10:31, 3 August 2025 (UTC)[reply]
I think messaging people is appropriate for this. — Preceding unsigned comment added by Aaron Liu (talk • contribs)
I definitely know what you are getting at Kowal2701 and have occasionally wanted to acknowledge a thanks with a quick headnod, smile or "you're welcome", much like in the real world. However, as Aaron Liu suggested, a talk page note is probably best and you may strike up a conversation around quality article building while you are there. If editors find the process of visiting a user's talk page, starting a new section and saving is too onerous, a quick-reply feature might be useful?--Commander Keane (talk) 07:05, 4 August 2025 (UTC)[reply]
Perhaps a quick button to let them know that you saw the thanks and are now happy is a good idea. Gaismagorm (talk) 17:55, 4 August 2025 (UTC)[reply]
Thanks, yeah that’s what I had in mind, rather than another full on thanks Kowal2701 (talk) 18:50, 4 August 2025 (UTC)[reply]
I don't see how that would be any better than the original idea. Aaron Liu (talk) 00:51, 5 August 2025 (UTC)[reply]

better tools to revert

[edit]

Twinkle may sound good, but maybe a tool that has a more friendly UI, stricter criteria, and better features should be added to detect more efficiently and revert more efficiently. DallolEthyoppiaFan (talk) 00:56, 31 July 2025 (UTC)[reply]

What specific features are you thinking of? We do have Twinkle alternatives (I'm sure there's more but WP:Ultraviolet comes to mind for me). GoldRomean (talk) 01:43, 31 July 2025 (UTC)[reply]
I think we need a new gadget, called UltraWiki. It can work on most devices, uses JavaScript, and very efficient at referring vandalism. But we need a New Gadget called UltraWiki, ok Graspbony (talk) 01:10, 10 August 2025 (UTC)[reply]
The stricter criteria is mostly extended confirmed criteria Graspbony (talk) 01:11, 10 August 2025 (UTC)[reply]
UltraWiki the new gadget is easy to use and has customizable watchlists. I think this is why a new gadget called UltraWiki should be made by someone Graspbony (talk) 01:27, 10 August 2025 (UTC)[reply]
I don't understand. What doesn't Ultraviolet and Antivandal already have? Aaron Liu (talk) 14:30, 10 August 2025 (UTC)[reply]
We need a unique notification for this new gadget. It is called Warning, and it describes the issue, timestamp, date of vandalism, and offers in-depth communication of why vandalism is bad for Wikipedia Graspbony (talk) 14:52, 11 August 2025 (UTC)[reply]
The new gadget Ultrawiki stricter criteria
• Must have 500 edits
• Account at least 30 days old Graspbony (talk) 14:57, 11 August 2025 (UTC)[reply]
UltraWiki also has to have semi - automation. You remember ClueBot NG, right? Well, the automated part of this gadget has machine learning to catch vandalism faster. Now thatd helpful Graspbony (talk) 15:10, 11 August 2025 (UTC)[reply]
This is so confusing and so seemingly large that I think the best way forward for your idea is to code it yourself! Aaron Liu (talk) 21:05, 11 August 2025 (UTC)[reply]
Do you remember ClueBot NG, the automated bot on Wikipedia. If so, machine learning is study of algorithms that improve automatically. And you remember Huggle, the diff browser, right? Well, this gadget is going to be more lightweight, making it like a "data saver" version of Huggle. I will explain simply
Extended confirmed means you have at least 500 edits and your account is at least 30 days old.
JavaScript is a programming language,right? Yes. Graspbony (talk) 13:50, 12 August 2025 (UTC)[reply]
Most anti vandalism tools are just on English Wikipedia. We need cross - wiki tools, like on German Wikipedia or Kirundi Wikipedia or Arabic Wikipedia. We need to fix vandalism across Wikimedia projects, and we also need to stop vandalism. Now I see Huggle in this sense and Twinkle as not catching subtle or "sneaky" vandalism, and now because of this, UltraWiki 's features help catch all types \ variants of vandalism. Graspbony (talk) 13:54, 12 August 2025 (UTC)[reply]
Even the name UltraWiki has a meaning. Ultra implies it is a powerful gadget limited to certain trusted users, and Wiki means it is on Wikimedia Projects. So the name implies a powerful gadget on Wikimedia Projects limited to trusted, experienced users. Graspbony (talk) 13:57, 12 August 2025 (UTC)[reply]
Well yes, "sneaky vandalism" is hard to catch. If it was easy, Cluebot/Huggle could already do it. But it is easy to say "we should use machine learning to detect this", but how? I agree that the best way to move forward is to make it yourself. If it can actually be done, it would be a big help (but that's a big "if"). GoldRomean (talk) 19:28, 12 August 2025 (UTC)[reply]
We need you to make it, as well as Ioeth Graspbony (talk) 20:46, 12 August 2025 (UTC)[reply]
Please do it yourself. I cannot understand your vision enough to fully realize it, and only you know what's best for the product. Aaron Liu (talk) 20:59, 12 August 2025 (UTC)[reply]

Require accounts for live edits, move IP edits to pending

[edit]

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

Presenting 'Templates used in this preview' in multi-column format

[edit]

For longer articles, scrolling up through the long list of template shown during preview mode is getting to be a chore. Wouldn't it make sense to present this information multiple columns so less scrolling is needed? Thanks. Praemonitus (talk) 14:54, 3 August 2025 (UTC)[reply]

That could indeed be more practical, although I don't know if that is something interface admins can do or if it is inherent to the MediaWiki software. Chaotic Enby (talk · contribs) 15:17, 3 August 2025 (UTC)[reply]
Tracked in Phabricator
Task T401066
I'm not an interface admin, but as far as I've been able to work out this is something that would have to be changed in software. It's a good idea though (the list is almost 11 screens long for me at London for example), so I've created phab:T401066. Thryduulf (talk) 16:18, 3 August 2025 (UTC)[reply]
While this is incorporated into the software, you should be able to see the effects yourself by adding this CSS to your personal userstyles page:
.mw-editfooter-list {
	column-width: 27em;
}
Aaron Liu (talk) 18:20, 3 August 2025 (UTC)[reply]
Seems fairly unnecessary as a software change to me. The list is already in a collapsible box (which remembers whether you last expanded or collapsed it, defaulting to collapsed), so if it bothers you you could just collapse it. People who really want this could add the CSS snippet Aaron Liu posted just above, much like how other people use my user script User:Anomie/previewtemplatelastmod to get more information in the list instead. Anomie⚔ 13:47, 4 August 2025 (UTC)[reply]
That does the trick. Thanks. Praemonitus (talk) 23:23, 6 August 2025 (UTC)[reply]

Dash Bot

[edit]

Assuming that strict criteria are met, would a Dash Bot be practical? kencf0618 (talk) 03:58, 4 August 2025 (UTC)[reply]

That would depend what you wanted it to do and why. Thryduulf (talk) 08:34, 4 August 2025 (UTC)[reply]
User:DASHBot already existed, but stopped running in 2013. Vague question gets a useless answer. 😀 Anomie⚔ 13:49, 4 August 2025 (UTC)[reply]
Primum non nocere - bots often break things, so be very careful. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:05, 4 August 2025 (UTC)[reply]
Given that your most recent edit was inexplicably replacing en dashes with em dashes on a policy page in contravention of MOS:DASH, I'd be concerned about any bot you might be proposing for this, strict criteria or not. Dan Leonard (talk • contribs) 01:25, 5 August 2025 (UTC)[reply]
User:Bot1058 Task 10 is operating on an unscheduled basis, under operator supervision. Let me know if you have any problems with its edits. There's still a known bug that I need to fix. – wbm1058 (talk) 02:13, 5 August 2025 (UTC)[reply]
Thanks. That answers my question! kencf0618 (talk) 02:48, 5 August 2025 (UTC)[reply]
I reverted a bold demand and filed Talk:Asia–Pacific#Requested move 3 August 2025 to stop the bot from making over a thousand edits to change Asia-Pacific links to Asia–PacificAsia–Pacific. For this bot to operate smoothly, we need to have competent executive editors. Since anyone with an inflated sense of expertise can edit, I'm not sure how soon I'll take the governors off my bot's operation, and let it run unsupervised. – wbm1058 (talk) 02:32, 5 August 2025 (UTC)[reply]

Proposed merges

[edit]

Merge discussions are buried away, which means they often don't get much input, and it takes even longer to get them merged once there's consensus. Wikipedia:Proposed article mergers isn't providing much value, as it has to be updated manually and it doesn't provide a full list of ongoing merge discussions. We currently have a list of discussions at Wikipedia:Proposed mergers/Log, as well as the categories Category:All articles to be merged, Category:Pages currently being merged, and Category:Articles to be merged after an Articles for deletion discussion. I'm wondering if anyone has thoughts on the merge process or how we can make it more visible. Thebiguglyalien (talk) 🛸 19:55, 4 August 2025 (UTC)[reply]

I've suggested on at least one previous occasion that it should work like either RM or an XfD to increase visibility. I think it got some support last time but I don't remember the detail. Thryduulf (talk) 20:01, 4 August 2025 (UTC)[reply]
WP:PM updating automatically like WP:RMC would go a long away, I remember being surprised this wasn’t the case merges weren't handled similarly to RMs and RfCs etc. Kowal2701 (talk) 20:02, 4 August 2025 (UTC)[reply]
Maybe it’d make sense to format it similar to WP:RFC/A since merges require more familiarity with the topic than for article titles Kowal2701 (talk) 20:06, 4 August 2025 (UTC)[reply]
wbm1058 runs Merge bot to keep the log page updated, so there's at least some automation involved. Thebiguglyalien (talk) 🛸 20:06, 4 August 2025 (UTC)[reply]
I have always thought that merge proposals should be integrated (merged? :) ) with WP:AFD, since often commenters on a deletion discussion propose to merge (part of) the article into a different article anyway. To me, the question in a deletion discussion is whether Wikipedia should have a standalone article on a given topic, which is very much like what merge proposals are asking anyway. CapitalSasha ~ talk 19:32, 5 August 2025 (UTC)[reply]
I agree with this. PropMerg is under-active and under-seen too much that I don't think there would be problems sending its workload to the afd userbase. Aaron Liu (talk) 23:59, 6 August 2025 (UTC)[reply]
Merging merging (lol) with AfD is absolutely something I'd support if a viable way to do it is proposed. It's listed at Wikipedia:Perennial proposals#Rename AFD, but I don't know if it's been seriously proposed in the current "generation" of Wikipedia. Thebiguglyalien (talk) 🛸 00:10, 7 August 2025 (UTC)[reply]
I also checked that list just to be sure before making my reply; the workload part I mentioned tries to address some of its arguments. I'm not even sure if there are previous discussions for only merging merging (nice) instead of also merging the vastly different ReqMoves. Aaron Liu (talk) 03:37, 7 August 2025 (UTC)[reply]
Do you (or anyone else reading this) have thoughts on what the merging of merging would look like, or how it should be proposed? Thebiguglyalien (talk) 🛸 20:38, 7 August 2025 (UTC)[reply]
Probably at least marking Wikipedia:Proposed article mergers as historical and adding merging to WP:CONRED. Not sure what exactly to do with TM:AfD and TM:Merge though; the laziest way would be to just replaec the "discuss" link with a link to the AfD.
To propose this, we would make a threat at WP:VPR and advertise it in Template:Centralized discussion. Not sure if it needs to be an RfC, but something this large definitely needs to be Cent-listed.
I've notified WT:AfD and WT:PropMerge since we probably need their input. Aaron Liu (talk) 17:06, 9 August 2025 (UTC)[reply]
I favor this. This reflects how AfD is already being used in many cases. We get AfD's like Wikipedia:Articles for deletion/List of Black Widow supporting characters every week. Wikipedia:Perennial proposals#Rename AFD still exists, but maybe it's finally time to break the logjam and make it "Articles for Discussion" and intentionally enshrine the fact that many articles shouldn't be standalone articles, don't need to be entirely deleted, but DO need a formal input process to minimize disruption and promote consistency across the project. Jclemens (talk) 19:25, 9 August 2025 (UTC)[reply]
Turning the "D" into "Discussion" is one way we could do it, but I want to make a distinction from the other fD's in that the proposal would not also merge ReqMoves, since that venue needs a completely different skillset unrelated to discussing notability. If BLankAndRedirect counts as Deletion, I think merging should to. Aaron Liu (talk) 20:59, 9 August 2025 (UTC)[reply]
Yeah, I have little participation in/insight into requested moves. But yeah: delete vs. keep vs. merge/redirect is already the threefold outcome in AfD so it's not been purely delete-or-not for years. Jclemens (talk) 01:36, 10 August 2025 (UTC)[reply]
Sometime back I noticed that the AfD statistics tool switched from treating a merge result as a keep (and colouring it green), to treating it akin to a delete result (and coloured red) - I don't agree with this (and I'm guessing I missed the discussion on this change?). For me, a merge result is a sign of notability and for various reasons while editors conclude that it is not a sign of stand alone notability, nevertheless it is an acknowledgement of notability. So, I'm not quite in agreement with the idea that AfD produces three types of results - rather it is a discussion purely focussed on notability and merge is a measure of notability relative to the standards that have been set. That said, I agree that seeking ways in which merge outcome can be more steadily followed up on would be useful. I agree that it does require some understanding of the topic at hand - while one might make explicit (at WP:ATD-M?) that those who propose merge have an onus to follow up, I imagine that would be impossible to police. Regards, Goldsztajn (talk) 09:10, 10 August 2025 (UTC)[reply]
Just to be clear - I can see that from a "process" perspective an AfD discussion can produce multiple different processes from the outcome of notability. Regards,--Goldsztajn (talk) 09:15, 10 August 2025 (UTC)[reply]
I frequently !vote to merge at AfD when the subject is not notable. Thebiguglyalien (talk) 🛸 18:14, 10 August 2025 (UTC)[reply]
The merge process does not need to be as formal as AfD because merging can be done WP:BOLDly, by any editor without the need for advanced permissions. We could more expressly allow AfD to lean into merge discussions, but it would not be good to make it mandatory. Merge discussions take a long time to process in part because merging is much harder than deletion. Depending on the articles in question it can take quite a lot of work. CMD (talk) 12:26, 10 August 2025 (UTC)[reply]
Makes sense. I want merging to be just like BLAR, though. BLAR can also be done boldly, discussed in some random talk page discussion, or discussed at AfD. I think it would make sense for Merge to be the same. Aaron Liu (talk) 14:33, 10 August 2025 (UTC)[reply]
They are very similar so they could use the same processes, a merge is a BLAR with some extra steps. CMD (talk) 16:44, 10 August 2025 (UTC)[reply]
I don't think that combining the process with AfD would be the way to go, but RM becoming RMM (requested moves and merges) would be a natural improvement. There's always scope for an AfD to emerge from a move or merge discussion, at which point more formality is appropriate.  — Hex • talk 13:59, 10 August 2025 (UTC)[reply]
An improvement for merging perhaps, but the two kinds of discussions are so different that I think it'd be a big detriment to participants who follow RM for their interest in article titles. Aaron Liu (talk) 14:34, 10 August 2025 (UTC)[reply]
I don't think a merger with RM would be a good idea. An RM-closer doesn't need to understand topic in order to carry out a consensus for a move, but unless it's a very simple case of "merge the whole of article X into article Y as a new section" then that is not true of article mergers.
Taking the structure of RM discussions and applying that to article mergers though would be helpful. Thryduulf (talk) 15:38, 10 August 2025 (UTC)[reply]
I fully support this. Proposed mergers is not a great system and merge discussions often sit months before they're resolved. voorts (talk/contributions) 22:45, 11 August 2025 (UTC)[reply]
And once there's consensus to merge, it can take even longer. Over the last few weeks, I've completed a bunch of merges that achieved consensus in 2023 and 2024. They're just put in a category and forgotten about if the proposer or the closer doesn't do the merge. Thebiguglyalien (talk) 🛸 00:57, 12 August 2025 (UTC)[reply]
I'd also support formalising this process. It would make merger discussions a lot more productive if they were handled the same way as requested moves. --Grnrchst (talk) 14:03, 12 August 2025 (UTC)[reply]
I support merging merges into AfD, and I oppose a merger with RM. "Merge" is already a possible outcome from AfD, and merges have more in common with deletion (since all the content in a page is blanked) than renaming (since no page is renamed). That said, I think we'll continue to have a merge backlog, since merges take work and time. It's rare that a page can be mindlessly cut and pasted into the merge target. Firefangledfeathers (talk / contribs) 14:09, 12 August 2025 (UTC)[reply]
I support merging merges into AFD and as per several of the editors above, change the D in AFD to discussion.Davidstewartharvey (talk) 14:27, 12 August 2025 (UTC)[reply]
This is a workshop discussion to hash out an idea, not the actual proposal yet, but I'm glad to see so much support. But there's still parts to hash out: Should the D stand for Deletion or Discussion? (There's arguments on both sides.) What do we do with the {{merge}} templates, and should we place the deletion banner on pages proposed to be merged? (I think we agree that the proposal should involve treating merging like BLARs.) Aaron Liu (talk) 21:02, 12 August 2025 (UTC)[reply]
If we want to increase the visibility of merge proposals, then I think that promoting Wikipedia:Article alerts is a low-risk method for doing this.
In my experience, though, what really stalls a merge proposal is that nobody wants to do the work of merging the article. "I vote for somebody else to merge this" is a common, if usually unstated, sentiment. We need more "If there's a consensus to merge, then ping me – I volunteer to do the work" statements. WhatamIdoing (talk) 04:22, 13 August 2025 (UTC)[reply]

Idea: Overriding system messages at user level

[edit]

I have proposal to overriding default system messages at user level (who are registered).
For example: If a user have a subpage with title like: User:{{{Username}}}/MediaWiki:{{{Message key}}} with syntax same as system messages -> Use this user-created message instead of the default.

Caveat:

  • Cannot override JS, CSS or JSON files
  • The protection policy at interface pages and User' JavaScript, CSS and JSON, apply.

Any comments? Thanks. DinhHuy2010 (talk · contribs · logs · rights · email · sandbox · links to user page · global contribs) 14:12, 5 August 2025 (UTC)[reply]

What's the use case for this? I think any user advanced enough to use a feature like this would also be advanced enough to understand what the various messages mean without needing to customize them. Is there a particular system message that you have in mind for customization? --Ahecht (TALK
PAGE) 14:21, 5 August 2025 (UTC)[reply]
Example like MediaWiki:Tagline
The current workaround is via JavaScript, example: User:DinhHuy2010/global.js, where I have to change the text at the element.
Could it be easier to customize the tagline without needing to using JavaScript.
and yes, is written in TypeScript, built using esbuild on the Deno runtime. DinhHuy2010 (talk · contribs · logs · rights · email · sandbox · links to user page · global contribs) 15:00, 5 August 2025 (UTC)[reply]
This doesn't replace, but you might be interested in wmdoc:mediawiki-core/master/js/module-mediawiki.util.html#.addSubtitle. Aaron Liu (talk) 18:54, 5 August 2025 (UTC)[reply]
this use #siteSub @Aaron Liu DinhHuy2010 (talk · contribs · logs · rights · email · sandbox · links to user page · global contribs) 06:37, 6 August 2025 (UTC)[reply]
Yeah I see that. There isn't much of a difference.
(Also, your signature is too long. See WP:SigLength. Aaron Liu (talk) 14:43, 6 August 2025 (UTC)[reply]
@Aaron Liu Signature fixed DinhHuy2010 (talk | contribs) 14:17, 7 August 2025 (UTC)[reply]
I missed the part where you "have to" change the text. Why do you "have to" change the text? Did you mean you "want to" change the text? WhatamIdoing (talk) 04:24, 13 August 2025 (UTC)[reply]
@WhatamIdoing, Because just for fun, I like customization. DinhHuy2010 (talk | contribs) 06:33, 13 August 2025 (UTC)[reply]

Informing readers when a government orders censorship of Wikipedia

[edit]

It was suggested I move this to the Idea Lab from Wikipedia:Village pump (WMF). Discussion of the incident itself should take place there to avoid fragmentation.

Now that there's been an instance where a court has ordered that sourced content is not allowed on a Wikipedia article, it's important that we set a precedent in how we respond and how we inform the public that this has occurred. I'd like to brainstorm a statement that can be placed on the main page or as a banner similar to the "Wiki Loves" notices.

These are the examples to demonstrate what I have in mind, but I'd love to hear different approaches too:

  • On 4 August 2025, information was censored from the Wikipedia article about Portuguese businessman Caesar DePaço by order of the Portuguese Supreme Court of Justice. The Wikipedia community strongly opposes this as a violation of freedom of information, and we believe it is the right of the public to be informed when information on Wikipedia is censored by a governmental body.
  • As of August 4, 2025, a lawsuit brought by Portuguese businessman Caesar DePaço has resulted in the removal of information from his article. Wikipedia and its editors condemn this attack on the right to freedom of speech, and this will not deter our commitment to providing free information to the world.
  • As of 4 August 2025, legal pressure from businessman Caesar DePaço, upheld by Portugal's highest court, has led to the censorship of his Wikipedia article. Wikipedia encourages all readers to recognise the importance of the rights to freedom of speech and freedom of information in an era where global attacks are launched on your right to be informed.

Pinging Horse Eye's Back, who suggested that it could potentially be mentioned in the context of fundraising instead, in case that's something they want to discuss here. Thebiguglyalien (talk) 🛸 20:51, 7 August 2025 (UTC)[reply]

I think an appropriate action is a banner on the article saying that some content has been censored due to a legal case. Cremastra (talk · contribs) 20:57, 7 August 2025 (UTC)[reply]
Given the general trend of discussions on the other VP page, I don't think a deliberately escalatory notice like this on every page would be a wise decision, however it is worded. Andrew Gray (talk) 21:02, 7 August 2025 (UTC)[reply]
Speaking on the combined fundraising/education angle what I find from talking about these sorts of things with people who are regular wikipedia users but not editors is that they are completely unaware that the WMF serves a legal function. IMO its the most actually valuable thing the WMF spends money on besides servers, its where the WMF actually stands up for all the principles that they fundraise on and I want our readers to know that. Lord knows I'm the first to criticize the WMF but I also think they deserve kudos where due. Horse Eye's Back (talk) 00:40, 8 August 2025 (UTC)[reply]
Yes. The WMF does a good job of handling the legal implications of running an international encyclopedia (and there are many). Cremastra (talk · contribs) 00:48, 8 August 2025 (UTC)[reply]
That reminds me, we have the Wikipedia:Fundraising/2025 banners. Maybe someone could propose a banner message there that focuses on the Caesar DePaço case, explaining how donations to Wikipedia are being used, among other things, to cover legal defense costs for lawsuits like that one. Some1 (talk) 02:14, 8 August 2025 (UTC)[reply]
I'd agree with User:isaacl below if this were ever implemented. Something like "Wikipedia is unable to provide some information about XYZ due to local laws. Please see [link] for more information." Bremps... 22:36, 9 August 2025 (UTC)[reply]

Personally, I think if there is consensus for a notice, it should be worded neutrally and be brief. I don't think the Wikipedia community should be spending time on arguing over what label to use in mainspace for each instance of prohibited content. Too often "censorship" is inappropriately used by the supporters of including a certain passage. The Wikipedia editing process is not infallible, so like it or not, sometimes externally imposed remedies will happen. For articles, it's enough to mention there is a court order, and to possibly point to a project page for more information (as much as legally permitted). (The community can of course discuss in project space whatever actions they want to take, which can include labelling specific actions.) isaacl (talk) 22:18, 7 August 2025 (UTC)[reply]

The Lumen database of takedown requests exists, and the WMF has been submitting the ones that it receives to it for a long time. It would be useful to link to them from any affected article.  — Hex • talk 14:07, 10 August 2025 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)&oldid=1305636074"