Meta:Requests for comment/Change to Meta Admin Inactivity Policies

The following request for comments is closed. There's no consensus about the change to the inactivity policy, and the participation is also very low (all in January, one edit in this month of March). As suggested by MarcoAurelio on the talk page, I recommend that a future RFC on this should be more widely advertised, if someone wants to start one. In that case, I would also recommend first starting an open discussion / brainstorming about the possibilities to establish a wide consensus of Meta users before getting it enacted via RFC. --MF-W 13:22, 16 March 2022 (UTC)[reply]

Statement of the issue

edit

In 2020, I had started some conversations about Meta Admin Inactivity Policies, and there seems to have some rough consensus that a change might be possible. Meta:Babel/Archives/2021-10#Review_of_Inactivity_policy_for_normal_adminship. For this part, we are amending Meta:Administrators/Removal#Removal criteria. The reasons of change is articulated in the Babel thread.

The changes are as follows(Bold means addition, strikethrough means removal ):

  1. Users who have made fewer than ten 20 edits / logged actions in the six twelve months immediately prior to the designated removal date (April 1 or October 1) are desysopped without notice.
  2. Users who have made more than ten 20 edits / logged actions but fewer than ten 40 edits / logged actions requiring admin privileges (remember, this includes edits to protected pages, etc.) in the same period are given a week to indicate they would like to retain their access. Users in this category are to be notified on the first day, and adminship is removed without notice on the seventh 14th day if there is no response.Camouflaged Mirage (talk) 09:36, 15 January 2022 (UTC) Using the new formula MA proposed below. Camouflaged Mirage (talk) 12:36, 15 January 2022 (UTC)[reply]
  1. Administrators who fail to make any edit or logged action[1] in the twelve months immediately prior to the designated review date (October 1st) will have all their advanced permissions[2] removed.
  2. Administrators that fail to make at least 20 edits or logged actions in the same period will be notified on their talk pages and be given two calendar weeks to indicate whether they wish to retain their permissions or not in a dedicated page. If the holder fails to answer to the notice their advanced permissions will be removed.
    [1] Actions for which advanced permissions are required to be performed, including checkuser checks and suppression (oversight) actions.
    [2] Advanced permissions are any of the following groups: administrator, bureaucrat, checkuser, interface administrator or oversight.

Comments

edit

Comments from MA

edit

Thanks for starting this. As I said on Babel last year, I'd prefer if we got rid of automatic removal clause, although I'd support a 0 edits or logged actions automatic removal though. It does not make sense to me to remove administrators who are still around without any warning whatsoever. As for the thresholds for proposed removal, I keep thinking that 40 edits or logged actions might be too much and I would leave it at 20 edits or logged actions.

I'd replace the "desysop" word with "removal of advanced permissions", considering that historically all advanced permissions have been removed, instead of just the sysop one.

My proposal would be in the lines of the following:

  1. Administrators who fail to make any edit or logged action[1] in the twelve months immediately prior to the designated review date (October 1st) will have all their advanced permissions[2] removed.
  2. Administrators that fail to make at least 20 edits or logged actions, for which advanced permissions are needed in both cases, in the same period will be notified on their talk pages and be given two calendar weeks to indicate whether they wish to retain their permissions or not in a dedicated page. If the holder fails to answer to the notice their advanced permissions will be removed.
    [1] Actions for which advanced permissions are required to be performed, including checkuser checks and suppression (oversight) actions.
    [2] Advanced permissions are any of the following groups: administrator, bureaucrat, checkuser, interface administrator or oversight.

CentralNotice admin permissions are out of this, as it is an independent group. We should probably consider some sort of inactivity criteria and use the October inactivity checks for these as well (but this is for another RfC).

MarcoAurelio (talk) 11:38, 15 January 2022 (UTC)[reply]

Interface-admin should be on that list too. — xaosflux Talk 12:29, 15 January 2022 (UTC)[reply]
True that. Done. It's already stated at Meta:Interface administrators § Activity requirements but no harm in adding it here too. Thanks, —MarcoAurelio (talk) 12:33, 15 January 2022 (UTC)[reply]
No objection to this revised list and criterion. Will update the above to show the latest. Camouflaged Mirage (talk) 12:35, 15 January 2022 (UTC)[reply]
  • Oppose Oppose I don't see a problem with the current criteria, fwiw they are a good nudge when I have sometimes falled short of the required number of actions. If we need more crats for the process to run we can appoint some more. --Base (talk) 14:21, 15 January 2022 (UTC)[reply]
    @Base: I personally find the current criteria to be horrible to be honest. Even if you make 1,000 admin actions, if you fail to make 10 edits (even to your user page) you will be desysopped. Does that sound fair to you? —MarcoAurelio (talk) 14:37, 15 January 2022 (UTC)[reply]
    I don't know. Shouldn't admins be involved in the community? --Rschen7754 18:11, 15 January 2022 (UTC)[reply]
    Definitely, we should. I am just not sure the current criteria as currently written makes the administrators in question really involved in community affairs. Shall we perhaps require some edits to the admin requests pages (RFD/RFH/etc.)? —MarcoAurelio (talk) 18:22, 15 January 2022 (UTC)[reply]
    There are extreme cases whatever the rule would say, but realistically I don't think it is likely. Fwiw if one is doing 1000 of actions there should also be comments from them on request pages etc. --Base (talk) 11:17, 19 January 2022 (UTC)[reply]
  • Oppose Oppose This is a solution in search of a problem. * Pppery * it has begun 18:54, 15 January 2022 (UTC)[reply]
  • Oppose Oppose This would loosen the inactivity policy for Meta administrators considerably, to the extent an administrator would need only patrol one revision or thank one user every 12 months to be considered as notionally active. The current system seems to be working. Dmehus (talk) 20:50, 15 January 2022 (UTC)[reply]
    @Dmehus You might be mistakened in the logged action part, in the current policy and the proposed policy and long standing meta conventions that logged actions refer to admin actions. Patrol, thanks are always exculded (as they don't need +sysop access to undertake). I hope this explains. Camouflaged Mirage (talk) 09:43, 16 January 2022 (UTC)[reply]
    Camouflaged Mirage, ah, okay, thanks, that makes sense. This doesn't change my view, as I still don't feel the policy requires amendment, but that's helpful clarification. Though, personally, I would consider patrolling to be an administrator action, as it requires the patrol user right that's included within the sysop toolset. The fact users can also request the patroller group separately, I don't feel, makes a difference. Either way, it's included within the patroller and sysop toolsets and not available to unprivileged users. Dmehus (talk) 01:51, 3 March 2022 (UTC)[reply]
    @Dmehus Valid arguments, but to be honest, if any user would ask for sysop access just for patrolling, I think it will be opposed as we have patroller group just for that purpose. In addition, we don't count any rights that can be obtained from a lower access group, likewise, MMS sending won't be counted as they can be done via MMS senders. Many of us started from patrollers, so when we ask for the right we likely want to do more than just patrolling. I will say that the main reason for policy amendment is so called to reduce the AAR runs from 2 to 1, which ease the load on those who are involved (crats, sysops helping as we don't have so many) as well as to clarify the logged actions and actions components, things that can be controversial at times. Hope this helps to explains. Camouflaged Mirage (talk) 08:14, 4 March 2022 (UTC)[reply]