Meta talk:Administrators/Archives/2020
Please do not post any new comments on this page. This is a discussion archive first created in 2020, although the comments contained were likely posted before and after this date. See current discussion or the archives index. |
Inactivity / removal criteria
I would like to bring back one topic to think about - inactivity/removal criteria.
The current policy (By the way, I didn't find any discussion and/or voting on which it would be based, could anybody point me to the relevant place if it exists? Thanks.) says:
Inactivity
Any sysop inactive on Meta will be desysopped. "Inactivity" is normally defined as fewer than 10 logged actions in the past six months. Desysopping is formally undertaken at Meta:Administrators/Removal. Users who are desysopped may reapply through the regular avenue.
Removal criteria
- Users who have made fewer than ten edits in the six months immediately before the removal date (April 1 or October 1) are desysopped without notice.
- Users who have made more than ten edits but fewer than ten actions requiring admin privileges 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 day if there is no response.
I see two issues (apart from possible (see the small note above) lack of proper procedure to create this policy) there:
The first is rather formal: The first paragraph mentions limit of logged actions as a requirement, the numbered list mentions edits as a (primary) requirement and logged actions as secondary. I would prefer that this should be unified and/or reformulated thus it would be clear which requirement is in fact being used.
The second issue is quite essential: Requiring edits for adminship confirmation seems a bit odd to me (and while looking around some other wikis (not all obviously) I didn't find any similar requirement anywhere else; logged actions are mentioned as the only or primary criteria). Adminship gives some extra rights on top of basic user rights, such as (un)deleting or (un)blocking and also some rights available to other groups (such as translation admins or patrollers). Thus I believe that eligibility for further usage of adminship rights should be based on usage of those and not on the trivial number of edits.
Consider the following scenario (all users with admin rights):
- User 1 discusses a lot on Meta, but did just two deletions,
- User 2 popped around for a week within the halfyear period, did 10 random edits (ie. of his userpage) and 10 logged admin actions and then hibernated for half a year again,
- User 3 did not find so many relevant or interesting things to discuss, thus made just few edits, but is continuously patrolling eg. against spam, vandalism and test edits, thus deleted ie. hundred of pages and blocked some users.
Now, which scenario testifies the best about the usage of admin rights? I strongly believe that the third one. However, paradoxically exactly the third user is going to be automatically removed such rights, while the first will be "warned" and the second will automatically continue (in fact technically only two calendar days of activity in a whole year, which could be only few hours if spread over the midnight, are enough to be considered "active admin").
This (all three types described above) actually happens nowadays: Only User 1 despite having the most admin actions (of listed users) within the recent halfyear and year has been removed rights due to "admin inactivity" (sic! in comparison to other users in chart) while other users (despite some haven't used admin rights for year and half or more, especially when discounting actions available also for other usergroups such as translation admins or patrollers) have been just warned and can simply have their rights prolonged by simply signing in...
User | admin actions | edits | ||
---|---|---|---|---|
count | most recent | count | most recent | |
User 1 | 10 (80 in last year) | 2020-03-18 | 5 | 2020-03-07 |
User 2 | 1 (available for translation admins anyway) (1/0 in last year) | 2020-03-22 (translation) / 2018-08-12 (admin) | 155 (only in a single day) | 2020-03-22, other before then 2019-10-10 |
User 3 | 0 (0 in last year) | 2018-07-10 (available for patrollers anyway) / 2017-10-30 (admin) | 18 | 2020-02-27 |
User 4 | 0 (0 in last year) | 2018-10-04 (approved an OAuth consumer) / 2017-10-14 (admin) | 11 | 2020-03-20 |
User 5 | 1 (max 17 in last year, some available for patroller or translation admins) | 2020-03-30 (changed group membership), other admin before then 2019-07-30 | 14 | 2020-02-29 |
User 6 | 2 (8 in last year) | 2019-12-09 | many (over 500) | 2020-03-31 |
User 7 | 5 (max 24 in last year, some available for patroller or translation admins) | 2019-11-05 (available for patrollers anyway) / 2019-10-04 (available for translation admins anyway) / 2019-10-06 | 351 | 2020-03-26 |
User 8 | 6 (13 in last year) | 2020-03-08 | 65 | 2020-02-25 |
I think that the current criteria are significantly unbalanced and do not reflect the reality when being applied, thus I would advocate and speak for change.
Considering that usage of absolute numbers is popular for policies, I would propose for example to use the following set of criteria:
× | Logged admin actions | |||
>N | M–N | <M | ||
Edits | >N | auto pass | auto pass | notification |
M–N | auto pass | auto pass | notification | |
<M | auto pass | notification | auto remove |
(M & N to be set based on discussion, assuming M would perhaps stay on the current 10)
(I created that based on looking around on other policies here and on other wikis while I realized that counting or setting minimal absolute numbers is the most popular method assuming it would be the most acceptable way.)
This is just a first kick to have some base to start to talk about. Please feel free to throw in your alternative proposals for criteria if you are not comfortable with that one proposed above, the discussion is not supposed to be "current policy vs. this single proposal". The core of this proposal is to remove contradictory statements in the policy and preferably remove dependency on pure edit count which does not reflect usage of admin rights.
Which actually leads to another, yet simplier, possible proposal: Simply remove from the rule the dependency on edit count at all and measure only by the really admin activity, ie. like:
- Users who have made fewer than n actions requiring admin privileges in the six months immediately before the removal date (April 1 or October 1) are desysopped without notice.
- Users who have made more than n but fewer than x actions requiring admin privileges 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 day if there is no response.
Thanks for thoughts.
— Danny B. 03:00, 3 April 2020 (UTC)
- This is too much text to read, but the inactivity policy has never made sense and we should simply get rid of it. --MZMcBride (talk) 20:51, 5 April 2020 (UTC)
- I agree with the first point, but think the policy should stay as it is. --MF-W 20:18, 7 April 2020 (UTC)
The conversation has been had repeatedly over the years where admins haven't had their ten edits, and no one has taken it to an RFC. I have never seen it a problem to maintain eligibility. I also have never seen it as an issue with a trusted administrator regaining the tools. If you want it, put your hand back up in the appropriate forum. — billinghurst sDrewth 13:39, 26 April 2020 (UTC)