Jump to content

Meta talk:Administrators/Removal (inactivity)

Add topic
From Meta, a Wikimedia project coordination wiki
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 30 days and sections whose most recent comment is older than 365 days. For the archive overview, see archives. The latest archive is located at 2024.

Amendment proposal (April 2023)

[edit]

Hello,

I'd like to propose an amendment to Meta:Administrators/Removal § Removal criteria point number 2 to expand the signing period from 7 days to 30 days.

The reason for this amendment is that 7 days is a short period of time in comparison with what other projects use. For example, Admin activity review gives users a one-month period to allow them to discuss their situation with their communities, other multilingual projects such as Wikimedia Commons, which use a very similar process like the one we have give their admins at :c:Commons:Administrators/De-adminship § De-adminship process as a result of inactivity also a one-month period to sign, and lastly the English Wikipedia deals with inactive administrators as well through a special process that gives admins a number of courtesy notifications before removing their rights (see Wikipedia:Inactive administrators for details).

April is also problematic for some users in Europe due to Easter hollidays, where it is usual to travel or be out of home.

Moreover, it's written all over Meta (e.g. Meta:Snowball) that this is not a project everyone visits everyday, thus I am not sure giving just 7 days to affected users is appropriate here.

The proposed amendment is as follows:

2. Users who have made more than ten edits but fewer than ten actions requiring admin privileges (remember, this includes edits to protected pages, etc.) in the same period are given a weekone month to indicate they would like to retain their access. Users in this category are to be notified in their talk pages on the first day the review starts, and adminship and other advanced permissions will be removed without further notice on the sevenththirty-first day after that notice if there is no response.

This proposal also clarifies what has been the rule for the last 14 years, that adminship and all other advanced permissions are removed as well.

While the policy could use some other changes, larger amendment proposals for this policy have failed to gather consensus in the past, so I hope this narrow proposal can get enough support to pass.

Thank you for your consideration,
MarcoAurelio (talk) 10:09, 11 April 2023 (UTC)Reply

Addenda: While I have proposed 30 days, this is not a closed number. As such feel free to suggest any period, if you support expanding it. —MarcoAurelio (talk) 12:10, 13 April 2023 (UTC)Reply
  • Support Support as proposer. —MarcoAurelio (talk) 11:19, 11 April 2023 (UTC)Reply
  • Since I already had a talk with Marco on this subject earlier today, due to the fact I was impacted by the current policy. This was mostly because of the provision that you only have 7 days to reply on adminship review page. You could argue (and I would somewhat agree) that be usually enough for most people to reply, this does not take in account the fact that people might travel around this time to be with family or have some time off away with little to no internet access. That is what happened to me: I had no way of responding to the message in a timely manner due to the timing and length of my holiday. If the change were to made, it would harmonize the amount of time you have time to reply with other de-adminship processes (on other wikis). I would therefor Support Support this change. Wiki13 (talk) 11:09, 11 April 2023 (UTC)Reply
  • I cannot agree to this change. One months is a full sixth (>16%) of the whole period that gets reviewed for activity. That's too long. It can always happen that one is away for a week and can't respond in time, but if one gets listed for possible removal, one is already not that active anyway, so I wouldn't consider that to be too bad. A new RFA is always possible anyway, if need be. --MF-W 15:00, 11 April 2023 (UTC)Reply
    Hello @MF-W and @Krd: Would 15 days be more acceptable for you? —MarcoAurelio (talk) 22:52, 11 April 2023 (UTC)Reply
    As far as I see, at Commons most of the signatures appear within 7 days. I think most of these early-signers are users who are generally active but just failed to be that active on the local project. On the other hand, the number of late signers who also manage to stay active afterwards, is very low. I'm still in favor of keeping the 7 days regarding signature. (Just my personal opinion of course.) --Krd 06:27, 12 April 2023 (UTC)Reply
    I would have less of a problem with 15 days. --MF-W 19:26, 4 July 2023 (UTC)Reply
  • Weak oppose per MF-W. Meta may be not a project everyone visits everyday, but for an admin it should be at least most of the days. --Krd 16:10, 11 April 2023 (UTC)Reply
  • Oppose Oppose If you don't respond to a request in seven days, then you're not active enough to remain an admin. I do not see the problem with that, as if you made a controversial admin action and then went AFK for a week that would be a problem too. * Pppery * it has begun 00:19, 12 April 2023 (UTC)Reply
    To preempt the inevitable reply, 15 days would not be more acceptable to me - the current situation is fine. * Pppery * it has begun 00:20, 12 April 2023 (UTC)Reply
    Reading this reply, it looks like you kind of missed the point on why this is brought up. If you were to be reviewed in one of two periods (either April or October) and take time off around that time for a prolonged period, which isn't unusual, you have no time to reply. And yes, to prevent the argument, you are not active enough and it is warranted to be reviewed for that. But then simply saying "You are not active enough" based on "If you don't respond to a request in seven days" is incorrect in this particular case in my honest opinion. You can't expect people to reply during their holidays or even plan around them. For me it doesn't have to be necessarily be only the 1 month or 2 week option. Another solution is to move the review dates back by a month. Wiki13 (talk) 12:10, 12 April 2023 (UTC)Reply
    I've seen users replying to inactivity notifications like "Please exempt me, I'm busy at the front of the Ukrainian war." I don't think there are many situations where somebody hasn't any chance to react to a talk page message, which get notified by e-mail for perhaps most of us, within a week, but within a longer time. Thats just too unlikely to build a new rule upon. Krd 14:05, 12 April 2023 (UTC)Reply
    People don't have always access to internet when they are away. Assuming they always do is wrong imo. Wiki13 (talk) 14:31, 12 April 2023 (UTC)Reply
    Over the years I've been enforcing this policy I can't help but feel it is creating unfair situations. First, it stupidly mandates automatic removal of admins that, while making actual use of the tools, just fail to make 10 edits in 6 months; but on the other hand it allows administrators making no or marginal use of their tools to keep them over and over signing every 6 months because they manage to make 10 edits in that period. What are we really enforcing here? Perhaps 30 days to sign may be too much, but 15 or even 10 days feels like a reasonable courtesy period to me. Of course, the community has the last word and if there's no consensus to change this I'll keep enforcing the policy as I'm expected to do, but considering that currently edits weight more than actual use of the tools, I don't get why this needs to be over and done in just 7 days. Respectfully, —MarcoAurelio (talk) 14:32, 12 April 2023 (UTC)Reply
    This is unrelated to the topic of this discussion. And yes, it is odd, and I would probably support making logged actions count against automatic removal too. * Pppery * it has begun 02:23, 13 April 2023 (UTC)Reply
    Also, I would prefer to move this section to be a Meta:RFC, using talk page to discuss modifications to policies won't be appropriate on many wikis. Liuxinyu970226 (talk) 03:27, 31 May 2023 (UTC)Reply
    @MarcoAurelio: In case you didn't see what I responded here. Liuxinyu970226 (talk) 22:45, 31 May 2023 (UTC)Reply
    Yes, I would also support enforcing admin activity criteria continuously rather than in blocks. I don't see that as relevant here. Making 10 admin actions every 6 months is also not hard, and not doing so is close to enough by itself, so the signing period could be seen as an extra opportunity rather than an inherent expectation. * Pppery * it has begun 02:23, 13 April 2023 (UTC)Reply
  • Weak oppose Think that is too far, maybe 10 days if there is an actual problem (I'm not convinced there is a problem). It's not like it is hard to regain adminship here should someone decide to come back. I'm not convinced by the argument that meta isn't a project you visit regularly as x-wiki talk notifications are on by default. — xaosflux Talk 13:26, 12 April 2023 (UTC)Reply
  • Support Support I've been on both sides of the fence for this one. On the one hand, 7 days does seem like a reasonable time -- hard to imagine not having internet for that long these days, even on a trip. But as a now relatively inactive admin, I can also see the benefit of giving a bit more leeway to keep the old timers around. Even if I'm not mega-active like I once was, I still enjoy popping by to contribute here and there. Having a lax inactivity policy that allows me (and other less active types) to still participate where we can seems like a nice thing. 30 days is a bit more generous, and there's really no rush to kick people out the door. – Ajraddatz (talk) 14:43, 12 April 2023 (UTC)Reply
Just a comment, "firsth" seems odd, I think "first" is adequate. I will personally think something along the lines of the 1st day of the next month will be simpler. Will come back to support/oppose after more thought. Camouflaged Mirage (talk) 14:47, 12 April 2023 (UTC)Reply
Thanks @Camouflaged Mirage: you are right, it was a typo. I've fixed it. —MarcoAurelio (talk) 15:13, 12 April 2023 (UTC)Reply
Upon thinking, I am not very inclined to allow inactivity removal to drag to like 1 month, so Oppose Oppose the proposal. However, I am very in support of giving more time for users to respond per Meta:Snowball. I will counterpropose that why not we keep the removals and add the provision of any admin that is inactivity removed (i.e.>10 edits but <10 logged actions) may automatically regain the tools without a RFA if they request for resysop within 31 days counting from the day where they are notified and asked to sign for confirmation. Camouflaged Mirage (talk) 14:39, 13 April 2023 (UTC)Reply
I don't follow your argument. If you are in favor to allow more time to respond you can propose an alternative period as stated above which is less than 30 days as it's not a closed number. On the counterproposal, I'm afraid it'd cause more work for us as I'm expecting virtually anyone whose bits got removed to request a resysop, making the whole inactivity review process pointless. —MarcoAurelio (talk) 17:38, 13 April 2023 (UTC)Reply
What I am thinking is that should we extend to 31 days, if in the situation you mentioned that within 31 days of removals, all will ask back the bit I am sure if we extend to 31 days for signings, almost all will sign. What we end up will be a sysop literally absent for 6 months, and then active for the 1 day in the 7th month to sign (and maybe make 9 more edits - no logged actions) and repeat. My proposal is to obtain the same outcome but just maybe reduce the risk of compromised accounts by removing the bit a little earlier. If we expect people to ask back the bits in 31 days, I think if we extend the signing to 31 days we are seeing all as keep. In this case, the only removals will be those <10 edits which I think will significantly reduce the policy intent. If we want people to have a little more time the maximum I can think of is around 14 in line with RFGRn/RFGS etc, but we are not solicitating inputs from broad basis but just the sysop indicating intent to retain. I will think therefore a easier way to restore might be better manner, why not say a shorter RFA to regain within 31 days etc. That's why I ended up with like an auto resysop if requested. Hope you understand my POV. Willing to consider any alternatives to make the process a little less abrupt. Thinking aloud: Commons have a policy if I remembered correctly a sysop can sya they are inactive for sometimes before the review and they won't be affected by a round of inactivity. Might be worth considering (didn't know if this had been discussed in the past on meta). Camouflaged Mirage (talk) 06:57, 14 April 2023 (UTC)Reply
In theory this makes a lot of sense, and I second that there is a psychological difference between having a longer time to sign or being able to regain the rights. But in practise the project goal is not to build the most sophisticated ruleset, but to achieve simple solutions to actual problems.
The mentioned problem was: If you are on vacation during the removal week, 7 days may be too short to sign.
Mentioned possible solutions that already exist:
  • Don't be inactive the 6 months before your vacation.
  • If you are hit by the undue hardness, put up a new RFA after your deadmin.
Krd 07:24, 14 April 2023 (UTC)Reply

@MarcoAurelio: How is it going? Is this discussion still active as shown on the Maintenance announcements template? —— Eric LiuTalk 17:53, 13 August 2024 (UTC)Reply

(btw I support the amendment proposal) —— Eric LiuTalk 17:54, 13 August 2024 (UTC)Reply

Square pegs and round holes; presenting something sustainable for the future

[edit]

This is becoming totally problematic. With the expansion to global abuse filters now being almost universal, we now have the situation that those interested in working on global AF have to be administrators and then meet the activity criteria when their sole interest is a particular and discreet part of this wiki. The site is a real hotchpotch of functionality that is local and uniquely global and we try to manage it with a set of criteria that considers it more typically a normal content wiki.

One of the people who undertakes the diligence in this space is saying that there is a problem with the process and people are essentially saying "maintain the status quo as it has worked for years". Are people listening? Are people setting us up for the future, or grabbing onto a piece of the past?  — billinghurst sDrewth 14:03, 17 July 2023 (UTC)Reply

@Billinghurst I have a feeling that such people "interested in working on global AF" aren't really interested in that at all - they may be interested in how specific filters impact single projects -- and perhaps they should just use a normal request process. Perhaps we need to improve that request/report process? — xaosflux Talk 15:41, 17 July 2023 (UTC)Reply
@Xaosflux: How about I turn that around. If you were designing a system today to manage global filters, would you tie that into the administrative function of metawiki? Would you also tie that into an activity requirement? I have sat through each phase of the introduction of the AF, and the extension to global. Every time it has been a case of reverse engineering to fit the metawiki right, not what is best for the AF management. The activity requirement and the model for administration here reflects an early-mid 2010s view of metawiki, not something for the future metawiki. We need to modernise the approach.  — billinghurst sDrewth 00:28, 18 July 2023 (UTC)Reply
@Billinghurst I would probably diverge all the global things (GAFs, user/global.*s editing, SBL, TBL) from local sysop - perhaps with some sort of access group short of stewardship that can deal with them. If we had a discreet group for just GAF editing requiring some sort of vote, I'd be hesitant to support someone who's only interest was adjusting filters for their homewiki (I do think there should be some sort of local GAF whitelist though). However for this specific point I don't think our admin activity requirements are very onerous here at 10edits/6 months, and that those working to support components for all global projects should generally be able to meet that. — xaosflux Talk 01:17, 18 July 2023 (UTC)Reply
My main concern with the current policy as written can be found here: I find it weird that it weights edits more than use of the tools, and as such fellow administrators making actual use of the tools but failing to make 10 edits automatically lose their access without notice. Looking at the discussion that led to this new removal policy it is not clear to me that was really the desired outcome, since the proposal mentioned a combination of edits and logged actions. So perhaps we should be removing without notice only people making no edits and no logged actions in the past 6 months instead?
About AbuseFilter, I'm divided about this. On one hand, we could create an abusefilter local group so trusted users can help in that area without requiring full administrator acccess, but that would mean another user group to policy and maintain. The panorama is already confusing enough, with other global groups (abusefilter helpers and managers) for similar purposes. On the other hand, we can convert these to limited-in-scope-adminships and require them to sign once a year sort of "yes, I'm still around" (see e.g. Meta:Requests for adminship/lustiger seth4). —MarcoAurelio (talk) 10:50, 18 July 2023 (UTC)Reply
@MarcoAurelio I'd be OK moving criteria one to Users who have made fewer than ten edits or logged administrative actions in the six months... - is this meaningful, not sure? How many admins don't make 10edits a month, but do make that many logged actions? — xaosflux Talk 13:51, 18 July 2023 (UTC)Reply
@Xaosflux: I'd find that an improvement over the current situation, in which we're removing admins without any warning for failing to make 10 edits in 6 months. I admit there have been not many cases, but when we had them these were controversial. See e.g. Meta talk:Administrators/Removal (inactivity)/October 2018 for the latest I can remember. I'd reserve automatic removal without warnings for those totally inactive though. —MarcoAurelio (talk) 10:28, 21 July 2023 (UTC)Reply
I'm afraid that I Oppose Oppose restrict "administrative actions" to be "logged only", there are some remote Toolforge tools designed only for sysops' works, such actions by tools are unlikely to be logged, so such restrictions maybe unfair for sysops active on Toolforge but not elsewhere. Liuxinyu970226 (talk) 05:34, 1 November 2023 (UTC)Reply
How do you want to count administrative actions that are not logged and no edits (which are being counted anyway)? And which toolforge tools are there that neither produce log entries nor edits but are still somehow relevant metawiki admin activities? Johannnes89 (talk) 08:58, 1 November 2023 (UTC)Reply
As this would be changing from edits to (edits+actions) I'm not concerned about it NOT counting something niche in addition, specifically an action in Special:Log, that is the result of an on-wiki action only available to administrators. That it "doesn't count" something like "viewing a deleted page" is of no concern. — xaosflux Talk 09:08, 1 November 2023 (UTC)Reply

"Administrators" in warning templates

[edit]

Each of them starts with "Administrators,". Shouldn't that be "Administrator,"? — Alien333 ( what I did &
why I did it wrong
) 07:53, 18 August 2024 (UTC)Reply

Sorry, not exactly sure which template you are referring to here. Link please? — xaosflux Talk 09:31, 18 August 2024 (UTC)Reply
I was talking about /RemovalNoticeAutomatic, /RemovalNoticeProposed, and /RemovalNoticeNoResponse. — Alien333 ( what I did &
why I did it wrong
) 09:33, 18 August 2024 (UTC)Reply
@Alien333 those templates are using ROOTPAGENAME. That's why it shows „administrators“ on a page called „Meta:Administrators...“ – if you put {{subst:Meta:Administrators/Removal (inactivity)/RemovalNoticeAutomatic}} on someones user talk page, it will show the user name instead (e.g. Hello Alien333, I regret to inform you...) Johannnes89 (talk) 10:36, 18 August 2024 (UTC)Reply
Oh, ok, I should have thought of that, or at least checked the code. Thanks! — Alien333 ( what I did &
why I did it wrong
) 11:20, 18 August 2024 (UTC)Reply