Meta talk:Administrators/Removal (inactivity)
This page is for discussions related to the Meta:Administrators/Removal (inactivity) page. Please remember to:
|
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)
editHello,
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 thesevenththirty-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)
- ‡ 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)
- Support as proposer. —MarcoAurelio (talk) 11:19, 11 April 2023 (UTC)
- 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 this change. Wiki13 (talk) 11:09, 11 April 2023 (UTC)
- 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)
- Hello @MF-W and @Krd: Would 15 days be more acceptable for you? —MarcoAurelio (talk) 22:52, 11 April 2023 (UTC)
- 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)
- I would have less of a problem with 15 days. --MF-W 19:26, 4 July 2023 (UTC)
- Hello @MF-W and @Krd: Would 15 days be more acceptable for you? —MarcoAurelio (talk) 22:52, 11 April 2023 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- @MarcoAurelio: In case you didn't see what I responded here. Liuxinyu970226 (talk) 22:45, 31 May 2023 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- Thanks @Camouflaged Mirage: you are right, it was a typo. I've fixed it. —MarcoAurelio (talk) 15:13, 12 April 2023 (UTC)
- Upon thinking, I am not very inclined to allow inactivity removal to drag to like 1 month, so 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- Upon thinking, I am not very inclined to allow inactivity removal to drag to like 1 month, so 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)
- Thanks @Camouflaged Mirage: you are right, it was a typo. I've fixed it. —MarcoAurelio (talk) 15:13, 12 April 2023 (UTC)
- 30 days is a bit much in my opinion, but I agree that seven days for signing might not be enough in some cases. I would support extending the signing period to two or three weeks. --Johannnes89 (talk) 15:50, 12 April 2023 (UTC)
- Support just because someone could be on vacation and not see the posting. Sometimes I just choose to unplug. --Rschen7754 00:08, 13 April 2023 (UTC)
- I'd love to know who that guy is. Liuxinyu970226 (talk) 03:30, 11 October 2023 (UTC)
- Support admins travel, have more important things in real-life, or could be on a simple wikibreak. 7 days is ridiculously short, IMO. --SHB2000 (talk | contribs) 11:06, 16 April 2023 (UTC)
- @SHB2000 There are examples of administrators on other wikis which are only having rare edits in the every 2-year periods, but still have "reasons to keep their rights", 7 days? Then let's drop 66% of our sysops in the whole WMF wikis PLUS phabricator: & translatewiki:, as well as a lot of 3rd-party wiki farms like wikia:, wikiapiary:, Miraheze, ShoutWiki... etc. Liuxinyu970226 (talk) 12:58, 29 May 2023 (UTC)
- Oppose per MF-W. Administrators need better quality, not quantity.--Jusjih (talk) 18:07, 16 April 2023 (UTC)
- Support with some hesitation and thought bubbles. I am comfortable with someone having a month to respond, if that more aligns with the current xwiki norm. Though I wouldn't want this to be a recurring theme where we are having to prod people time after time.
I would also note that I would like to see it somewhat easier for returning admins who have been removed due to inactivity to be reinstated more readily within a stated period following inactivity removal (6 months?), again not recurring, on the judgment of the deciding 'crat. This is about security and currency, so a reasonable approach can be followed. — billinghurst sDrewth 22:58, 16 April 2023 (UTC)
- One month is even too short for me for such a respond, there are issues pending for more than a decade and no respond in regard to admin removal issues. Liuxinyu970226 (talk) 05:12, 30 October 2023 (UTC)
- Oppose Per MF-W, Unless if there are ways that an active administrator can also be nominated for removal in cases of abusing adminship privileges. --Liuxinyu970226 (talk) 22:34, 28 May 2023 (UTC)
- There is no invulnerability to any adminship here. One makes a proposal to remove an admin with the reasoning for why, there is nothing stopping that now. This proposal is solely about a removal without further reason. If you think that there is the need for overt statements for removal, then please propose them, not muddy the water in this proposal. — billinghurst sDrewth 06:37, 29 May 2023 (UTC)
- @Billinghurst there is nothing stopping that now?! Liuxinyu970226 (talk) 12:52, 29 May 2023 (UTC)
- Also @Mykola7: ^^ Liuxinyu970226 (talk) 12:52, 29 May 2023 (UTC)
- Sure Liuxinyu970226. This process/page specifically relates to inactivity removal as stated all through the header and through the documentation. Please take the time to get into that introductory text and read the links there. That the page is not called Meta:Administrators/Removal (inactivity) is sheerly historical because no one has bothered to do it, nor has there been a need. Inactivity is never the only means to remove an administrator, the community always has that ability to be removed by a no-confidence consensus of the community, we just typically have well-behaving admins. — billinghurst sDrewth 21:59, 29 May 2023 (UTC)
- @Billinghurst Why not try blocking such sysops that intend to violate inactivity policy instead? From practices of zh.wikisource, administrators can also block another administrator when necessary. Liuxinyu970226 (talk) 13:15, 3 June 2023 (UTC)
- @Liuxinyu970226: This proposal is solely about administrators at Meta wiki and the loss of the right through inactivity, nothing else. zhWS sets its own admin policies, or they fall under the global approach. Please do try to muddy the water with your issues at other places. — billinghurst sDrewth 22:55, 3 June 2023 (UTC)
- Okay but even so, my opposition on this "proposal" remains valid, unless and until there's a major, REALLY MAJOR, modifications on all kinds of admin removal proposal process within the Meta-Wiki. Liuxinyu970226 (talk) 05:09, 30 October 2023 (UTC)
- @Liuxinyu970226: This proposal is solely about administrators at Meta wiki and the loss of the right through inactivity, nothing else. zhWS sets its own admin policies, or they fall under the global approach. Please do try to muddy the water with your issues at other places. — billinghurst sDrewth 22:55, 3 June 2023 (UTC)
- @Billinghurst Why not try blocking such sysops that intend to violate inactivity policy instead? From practices of zh.wikisource, administrators can also block another administrator when necessary. Liuxinyu970226 (talk) 13:15, 3 June 2023 (UTC)
- Sure Liuxinyu970226. This process/page specifically relates to inactivity removal as stated all through the header and through the documentation. Please take the time to get into that introductory text and read the links there. That the page is not called Meta:Administrators/Removal (inactivity) is sheerly historical because no one has bothered to do it, nor has there been a need. Inactivity is never the only means to remove an administrator, the community always has that ability to be removed by a no-confidence consensus of the community, we just typically have well-behaving admins. — billinghurst sDrewth 21:59, 29 May 2023 (UTC)
- There is no invulnerability to any adminship here. One makes a proposal to remove an admin with the reasoning for why, there is nothing stopping that now. This proposal is solely about a removal without further reason. If you think that there is the need for overt statements for removal, then please propose them, not muddy the water in this proposal. — billinghurst sDrewth 06:37, 29 May 2023 (UTC)
- Absolutely Support. On my homewiki simplewiki, there is an inactive admins policy and admins are usually notified they have not made the 100 actions minimum at the beginning of October. If they do not meet the minimum, their rights are then removed on 1 January. So 7 days compared to this is way too short. I have had breaks of weeks and months before, due to real-life priorities or travel, and while the actual amount you have to be to not be inactive is pretty minimal, if we are going to have a signature required, we should actually give some time for people to do it. --Ferien (talk) 20:44, 9 September 2023 (UTC)
- Weak oppose I don't think this is a major issue either way or will change many outcomes but the removal criteria is there to remove admins that are inactive. If someone is unable to respond to a notification of adminship removal within a week then I don't think they should be an admin until their activity can increase again. Terasail[✉️] 11:41, 29 September 2023 (UTC)
- Indeed, probably it's the time we can close this section as "Not done, no consensus" Liuxinyu970226 (talk) 09:50, 6 October 2023 (UTC)
- Disappointingly it seems to be the case. We have recently lost Beetstra who can no longer change the protected settings file for COIBot that he runs. I shake my head at the lack of ability to see that metawiki is a different sort of wiki with its coordination aspects, and people apply a content wiki mentality. We have more specialised needs in centralised bots, blacklists, global abuse filters, etc. and the only means to control is through the administrator role. — billinghurst sDrewth 22:27, 30 October 2023 (UTC)
- By Beetstra, you pointed me an interest thing, I'm still waiting for their answers on why that (wo)man opposes to rename MediaWiki:Spam-blacklist to be MediaWiki:Spam-disallowlist, as well as MediaWiki:Spam-whitelist to be MediaWiki:Spam-allowlist, that user is indeed inactive, not only on sysop actions, but also some non-admin edits, or probably, in full of wikibreak mode. Liuxinyu970226 (talk) 13:03, 31 October 2023 (UTC)
- As far as I can tell, that is a software discussion, not a project discussion - see phab:T190521 and phab:T254649 for tickets about renaming the SBL. — xaosflux Talk 15:06, 31 October 2023 (UTC)
- Why both Phabricator tasks are required (to resolve?!) when just renaming two interface administrators' pages? :P Liuxinyu970226 (talk) 15:12, 31 October 2023 (UTC)
- There are extension and integrations (including off-WMF project integrations) that are expecting configurations to be in specific files; this is certainly far off topic from this discussion, feel free to continue in the ticket. — xaosflux Talk 15:33, 31 October 2023 (UTC)
- FWIW, the SBL is being slowly replaced, and eventually MediaWiki:BlockedExternalDomains.json will be used as the replacement; some projects have started building this - but the backend needs more work still. — xaosflux Talk 15:36, 31 October 2023 (UTC)
- There are extension and integrations (including off-WMF project integrations) that are expecting configurations to be in specific files; this is certainly far off topic from this discussion, feel free to continue in the ticket. — xaosflux Talk 15:33, 31 October 2023 (UTC)
- Why both Phabricator tasks are required (to resolve?!) when just renaming two interface administrators' pages? :P Liuxinyu970226 (talk) 15:12, 31 October 2023 (UTC)
- As far as I can tell, that is a software discussion, not a project discussion - see phab:T190521 and phab:T254649 for tickets about renaming the SBL. — xaosflux Talk 15:06, 31 October 2023 (UTC)
- By Beetstra, you pointed me an interest thing, I'm still waiting for their answers on why that (wo)man opposes to rename MediaWiki:Spam-blacklist to be MediaWiki:Spam-disallowlist, as well as MediaWiki:Spam-whitelist to be MediaWiki:Spam-allowlist, that user is indeed inactive, not only on sysop actions, but also some non-admin edits, or probably, in full of wikibreak mode. Liuxinyu970226 (talk) 13:03, 31 October 2023 (UTC)
- Disappointingly it seems to be the case. We have recently lost Beetstra who can no longer change the protected settings file for COIBot that he runs. I shake my head at the lack of ability to see that metawiki is a different sort of wiki with its coordination aspects, and people apply a content wiki mentality. We have more specialised needs in centralised bots, blacklists, global abuse filters, etc. and the only means to control is through the administrator role. — billinghurst sDrewth 22:27, 30 October 2023 (UTC)
- Indeed, probably it's the time we can close this section as "Not done, no consensus" Liuxinyu970226 (talk) 09:50, 6 October 2023 (UTC)
- Support 2 weeks/14 days, per Johannnes89, there can be real life constraints. -- CptViraj (talk) 05:13, 31 October 2023 (UTC)
- Yep, shorter periods can just be an easy way to introduce higher quality of sysop's actions, so why not 2 hours/14 milliseconds instead? Liuxinyu970226 (talk) 05:29, 1 November 2023 (UTC)
- Support I think the changes are reasonable. Nothing wrong with giving people more time.--BRP ever 15:13, 31 October 2023 (UTC)
- @BRPever So? I think 2 hours/14 milliseconds are more reasonable than the de facto Liuxinyu970226 (talk) 02:21, 1 November 2023 (UTC)
- I am not sure what this means; I am too tired to figure it out right now. Honestly, I am fine either way but I have never seen harsher inactivity policy do any good. Instead, there are plenty of instances where it could be counter-productive. That said, in meta, RFAs for admins removed for inactivity are generally kind, so I think 15-30 days time is a good idea. One week is very easy to miss, especially for those of us who travel frequently. BRP ever 11:26, 1 November 2023 (UTC)
- @BRPever As someone said, we need better quality, not quantity. Liuxinyu970226 (talk) 13:50, 5 November 2023 (UTC)
- Yeah, I agree with this, but more in a way that numbers don't necessarily show if someone is active or not. I appreciate those that contribute a lot to the project; we are all doing whatever we can as volunteers.--BRP ever 05:19, 6 November 2023 (UTC)
- @BRPever And how do you believe that such "shorten" of quantity can make our adminship much better than other wikis? There are records that random one Meta adminship violates certain policies on other wikis. Liuxinyu970226 (talk) 02:44, 22 November 2023 (UTC)
- Yeah, I agree with this, but more in a way that numbers don't necessarily show if someone is active or not. I appreciate those that contribute a lot to the project; we are all doing whatever we can as volunteers.--BRP ever 05:19, 6 November 2023 (UTC)
- @BRPever As someone said, we need better quality, not quantity. Liuxinyu970226 (talk) 13:50, 5 November 2023 (UTC)
- I am not sure what this means; I am too tired to figure it out right now. Honestly, I am fine either way but I have never seen harsher inactivity policy do any good. Instead, there are plenty of instances where it could be counter-productive. That said, in meta, RFAs for admins removed for inactivity are generally kind, so I think 15-30 days time is a good idea. One week is very easy to miss, especially for those of us who travel frequently. BRP ever 11:26, 1 November 2023 (UTC)
- @BRPever So? I think 2 hours/14 milliseconds are more reasonable than the de facto Liuxinyu970226 (talk) 02:21, 1 November 2023 (UTC)
@MarcoAurelio: How is it going? Is this discussion still active as shown on the Maintenance announcements template? —— Eric Liu(Talk) 17:53, 13 August 2024 (UTC)
- (btw I support the amendment proposal) —— Eric Liu(Talk) 17:54, 13 August 2024 (UTC)
Square pegs and round holes; presenting something sustainable for the future
editThis 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)
- @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)
- @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)
- @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)
- 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)
- @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)
- @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)
- I'm afraid that I 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)
- 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)
- 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)
- 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)
- @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)
- @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)
- @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)
"Administrators" in warning templates
editEach 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)
- Sorry, not exactly sure which template you are referring to here. Link please? — xaosflux Talk 09:31, 18 August 2024 (UTC)
- I was talking about /RemovalNoticeAutomatic, /RemovalNoticeProposed, and /RemovalNoticeNoResponse. — Alien333 ( what I did &
why I did it wrong ) 09:33, 18 August 2024 (UTC)- @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)- 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)
- Oh, ok, I should have thought of that, or at least checked the code. Thanks! — Alien333 ( what I did &
- @Alien333 those templates are using ROOTPAGENAME. That's why it shows „administrators“ on a page called „Meta:Administrators...“ – if you put
- I was talking about /RemovalNoticeAutomatic, /RemovalNoticeProposed, and /RemovalNoticeNoResponse. — Alien333 ( what I did &