Jump to content

Meta:Babel/Archives/2021-10

Add links
From Meta, a Wikimedia project coordination wiki

Let's talk about the Desktop Improvements

Latest comment: 3 years ago2 comments1 person in discussion

Hello!

Have you noticed that some wikis have a different desktop interface? Are you curious about the next steps? Maybe you have questions or ideas regarding the design or technical matters?

Join an online meeting with the team working on the Desktop Improvements! It will take place on October 12th, 16:00 UTC on Zoom. It will last an hour. Click here to join.

Agenda

  • Update on the recent developments
  • Sticky header - presentation of the demo version
  • Questions and answers, discussion

Format

The meeting will not be recorded or streamed. Notes will be taken in a Google Docs file. The presentation part (first two points in the agenda) will be given in English.

We can answer questions asked in English, French, Polish, and Spanish. If you would like to ask questions in advance, add them on the talk page or send them to sgrabarczuk@wikimedia.org.

Olga Vasileva (the team manager) will be hosting this meeting.

Invitation link

We hope to see you! SGrabarczuk (WMF) 15:09, 4 October 2021 (UTC)

Hello! I'd like to remind that the meeting will happen today. You are welcome to join! SGrabarczuk (WMF) (talk) 14:55, 12 October 2021 (UTC)

Talk to the Community Tech

Latest comment: 3 years ago1 comment1 person in discussion

Read this message in another language

Hello!

We, the team working on the Community Wishlist Survey, would like to invite you to an online meeting with us. It will begin on 27 October (Wednesday) at 14:30 UTC on Zoom, and will last an hour. Click here to join.

Agenda

  • Become a Community Wishlist Survey Ambassador. Help us spread the word about the CWS in your community.
  • Update on the disambiguation and the real-time preview wishes
  • Questions and answers

Format

The meeting will not be recorded or streamed. Notes without attribution will be taken and published on Meta-Wiki. The presentation (all points in the agenda except for the questions and answers) will be given in English.

We can answer questions asked in English, French, Polish, Spanish, German, and Italian. If you would like to ask questions in advance, add them on the Community Wishlist Survey talk page or send to sgrabarczuk@wikimedia.org.

Natalia Rodriguez (the Community Tech manager) will be hosting this meeting.

Invitation link

We hope to see you! SGrabarczuk (WMF) (talk) 23:00, 22 October 2021 (UTC)

Inactivity removal for CN admin

Latest comment: 3 years ago26 comments10 people in discussion

Per Meta_talk:Administrators/Removal/October_2021, I propose we add into the CN admin: Any CN admin who does not use the tools for 12 months will be removed of their access. For regular administrators who are also CN admin, they will lose their access if they fail to meet the activity requirement of administrator. This does not include temporary CN admins nor WMF decreed CN admins. For community discussion and approval. @Minorax and MarcoAurelio: as the participants in that discussion. Camouflaged Mirage (talk) 13:08, 10 October 2021 (UTC)

Thanks for starting this discussion. We should perhaps look at the whole, wider picture of the various inactivity policies around here and try to consolidate them where possible or convenient for the better execution of them. For now, I'd agree with removing CNA access for those who do not actively use them. I'm thinking that each October (so we can use the local inactivity checks) we should message local CNAs who have not used the toolset for at least one year and give them one or two weeks to sign if they wish to retain their permissions. I'd rather avoid automatic removal, even though CNA is probably as dangerous as Interface Administrator access, if not more. —MarcoAurelio (talk) 16:58, 11 October 2021 (UTC)
I don't really see why someone who is losing their normal adminship should also lose their CentralNotice adminship. The permissions are completly unrelated. Adminship is lost after 6 months of inactivity while it is proposed that CN admins are going to lose their CN adminship after 12 months of inactivity. This means that if someone is a normal sysop, their maximum allowed time period to be inactive as a CN admin decreases to 6 months. --Zabe (talk) 13:05, 12 October 2021 (UTC)
Fair point. I won't oppose 12 months. I have a counter-proposal: Why not make confirmations yearly for sysops also, the runs are time consuming and we are down to 2 crat on meta, if we want to prevent gaming, we can do 10 edits and 10 logged actions for either of the half of the year, if you don't fulfill either half, will be removed at the end of the year (i.e. Oct). This is to tie in with CN admin or etc. Just a thought. Camouflaged Mirage (talk) 13:14, 12 October 2021 (UTC)
I think revising the admin inactivity policy deserves its own thread, and I'd not be opposed. I agree with Zabe that CNA should not be tied to adminship. Regarding CNA inactivity, I think that we can agree that 12 months of inactivity should trigger removal? Given that CentralNotice should not be used every day, I don't think we should be operating under a automatic removal policy here, and instead give users one or two weeks to sign in order to keep their permissions. Thoughts? —MarcoAurelio (talk) 09:41, 18 October 2021 (UTC)
Sure. Let's do it like the regular AAR runs, i.e. the person can sign to keep the access. But can I propose we follow commons on the AAR for CN admin as it's more sensitive, I mean their normal AAR rules for normal sysops that if you signed once, the next year if you don't use the tools, it's then automatic removal. My 2 cents. Camouflaged Mirage (talk) 09:44, 18 October 2021 (UTC)

Comment Comment IMO the CN admins would typically already fall under AAR policy as "administrators". I don't see that there is an exception there. This puts the control of those rights with stewards. If we are looking to manage it ourselves, then we are creating an exception to the criteria. So the question is do we want local control of these rights, or with the stewards.

Personally I wonder why we grant permanent rights to so many people. I would suggest that we are better to:

  1. only grant non-WMF staff up to 2 years of rights and get them to reapply at the completion
  2. let stewards worry about those who haven't used them in two years and expire them normally

this doesn't require a change of policy, it simply allows the 'crats to change our practice of granting, and the community the ability to review their allocation and whether that need is still current.  — billinghurst sDrewth 12:35, 18 October 2021 (UTC)

Comment Comment I have specifically notated CN on AAR in special:Diff/22203813. It was an oversight by the community to not make that alteration when this group was created and split from the local admin role.  — billinghurst sDrewth 13:00, 18 October 2021 (UTC)
I feel we can manage CN inactivity on our end. AAR is already too burdensome, manual and heavily dependant on very few people. I'd support the idea of making the group temporary by default in the same way we grant global interface administrator access though. For those existing CNAs which are not Foundation staff, I'd say we could use the next local admin inactivity reviews and notify those who have not used their CNA permissions for more than one year and give them one or two weeks to sign if they'd like to keep them? The review should be independent of whether the user is a local admin or not, as the permissions are now independent. Thanks, —MarcoAurelio (talk) 09:37, 20 October 2021 (UTC)
A temporary assignment would be the easiest to keep track of. Would you say that the current CNAs become temporary after the proposed signing? --MF-W 13:36, 20 October 2021 (UTC)

Comment Comment Per MF-Warburg's comment, I would like to put a counter proposal for consideration.

  • All non-WMF assignations should become temporary assignations, and should be maximum of two year assignation.
  • That all RfCN rights request should have the proponent state the requested period of assignation, with the default period being 12 months.
  • That all existing non-WMF rightsholders who have used the right are converted to a new twelve month right; that all non-WMF rightsholders who have not used the rights have those rights removed, and can reapply for rights when they are required.

Happy for tweaks and I think that this should be converted to an Meta:RfC and be open for one month for comment.  — billinghurst sDrewth 00:00, 21 October 2021 (UTC)

Converting to temporary membership is potentially controversial. I agree a Meta:Requests for comment would be better if the community wants to go down that path. I've updated the message list for CNAs to easily notify them about this discussion and the future RfC. —MarcoAurelio (talk) 09:34, 21 October 2021 (UTC)
My take (pre-RFC). We do an one-time notification to all CNA which are not WMF staffers: Give them 2 weeks to sign. If they sign, their rights will be converted to 1/2 years temp CNA, if they don't, removal. At the end of 1/2 years we ask them to sign again and the process repeats. This is to tie in with the general AAR as well as to simplify the process. Camouflaged Mirage (talk) 09:37, 21 October 2021 (UTC)
I'll message existing volunteer CNAs and tell them about this discussion. —MarcoAurelio (talk) 09:46, 21 October 2021 (UTC)
  • Did a quick overview of the CNA's:
CNA Summary
Grouping Count
WMF Accounts 24
WMDE Accounts 5
Admins or Stewards 12
Other 11
Total 52
So assuming we are ignoring WMF stuff as usual, and suspect WMDE as well as they got access via WMF-T&S; this is really a rather small matter to worry about isn't it? Admins and Stewards already have recurring activity requirements - leaving us with a paltry 11 people - and I don't see this population significantly growing in the near future. This isn't any proposed solution - just trying to frame the possible problem. — xaosflux Talk 11:14, 21 October 2021 (UTC)
@Xaosflux I meant there are some like Zabe who proposed above that CN admin shouldn't be removed per normal AAR run for meta sysop, which means admins may need a separate removal. If we can codify that admins will lose CNA per inactivity, that makes sense. This is why I started the next section to refine AAR for admins as WMF when they granted CNadmin they granted to those who uses the interface for the past 12 months. So some clarifications might be in place. And CN admins like Vogone did not use their tools for some time, like 2018 is the last, and this is sort of a sensitive priv, so it might be well if we have some sort of activity removal. My 2 cents. Camouflaged Mirage (talk) 11:58, 21 October 2021 (UTC)
  • I have the rights, and I use them rarely, but when I do use them, it's usually for an urgent fix of a banner that is broken in some languages. By coincidence, I've just done it earlier today; the previous time was a few months ago. I don't use the permissions for much else, and I actually wish we had a more robust system that takes care of direction automatically, so I wouldn't have to do it at all, but with the system we do have, I have to do it. So I don't need the permissions often, but I need them occasionally, and when it happens, it's urgent-ish, because these are banners that are already shown to many people. Also, no one complained about my use of these permissions ;)
    What I'm getting at is that it should be similar to how it is with Meta administrators: don't just remove the rights, but ask whether they are still needed, and if there is an affirmative answer and there are no issues with misuse, let the user keep them. --Amir E. Aharoni (talk) 11:57, 21 October 2021 (UTC)
    Strongly support! This is also my own context of using these rights. I use these rights very rarely, but when they are needed, they are needed for an urgent fix. I would like to participate in this on a wider scale, but due to a long time of non-use, I forget the rules, and I am afraid to disrupt the display calendar. Kaganer (talk) 21:27, 21 October 2021 (UTC)
  • Given the numbers collected by Xaosflux and the experience reported by Amire80, I would modify my position: let's have CNAs sign annually (or every second year) if they want to keep the tools. It can be done together with the admin signings. --MF-W 13:39, 21 October 2021 (UTC)
  • I'd be happy for CentralNotice admins to become a temporary role on a rolling 12 or 24 month basis, but I'd like us to consider that if an account has made no ( meaningful? ) edits or a user made no contributions as a developer over a 12 month period then the CN rights be removed irrespective of whether the users wishes to keep them. Seddon (talk) 14:17, 21 October 2021 (UTC)
  • The initial proposal makes sense, since it is better to remove the status of inactive users. However, I would not take the CN adminship activity into account, but instead consider if the user is globally active. I'm not often (not to say quite never) editing Meta, but I sometimes deal with last minute cache purges based on requests from fr.wp, my home wikis. Speaking of, I'm the only fr.wp user with these rights, which I consider as being a good practice, to have someone ready to reply to my community's questions and requests. Trizek from FR 15:26, 22 October 2021 (UTC)
  • My idea would be to check each year at a date to be determined (as MF-W suggested, we could use the admin inactivity session) which non-staff CNAs have not used their permissions in immediate last 12 months, notify them and give them some time to reply if they want to keep their permissions. A provision could be added mentioning that if next year you're notified too you get removed (I assume that if you've not used the permissions in two years you ain't really needing them, and CNA rights are sensitive). —MarcoAurelio (talk) 10:35, 23 October 2021 (UTC)
    Support Support 12 months signing. Let's give 2 weeks to sign. This applies to people who didn't use their access at all, if they do, automatically exempted. And automatic removal if signed and still didn't use the access for another 1 year as CNA is not a hat to collect and 2 years without using it seems sufficient that you won't need to use it that often. This also ties in with the general AAR for other wikis as well as those GR removals. Note that for some similarly sensitive tools, it's 1 year like Global renamer etc. Camouflaged Mirage (talk) 08:31, 8 November 2021 (UTC)

Review of Inactivity policy for normal adminship

Latest comment: 3 years ago11 comments5 people in discussion

Per the above thread, since there is a suggestion to do a split, here I am. Due to meta now down to 2 crats and the administrative burden to run half yearly confirmations, I propose we do it per year. We can double the requirements like 20 edits and 20 logged actions, an alternative is for every half a year, there must be 10 edits / logged actions, reviewed at the end of the year. For the 1st part, those who makes more than 20 edits can be given 1 week to sign; for the latter section those who meet the requirements for one half but not the other half can be given 1 week to sign. Ideas? Camouflaged Mirage (talk) 09:49, 18 October 2021 (UTC)

If we are down to 2 crats, then we should simply appoint more, that is not a hard thing for us to do and requires no policy change. Two weeks and we are there. Our current advanced rights count is a = 61; ia = 20; b = 2; c = 6; o = 4; bot = 33.  — billinghurst sDrewth 12:21, 18 October 2021 (UTC)
This can work too, well we need someone volunteering for it. I am still keen so called on reforming the inactivity policies to tie in with the rest of the policies like bot inactivity, CN admin inactivity, limited admin inactivity (for the special confirmation). I think once a year seems to be more standardize across the board. Camouflaged Mirage (talk) 12:24, 18 October 2021 (UTC)
We keep running into this problem. It needs to crats and we are back in the same situation as 2017 when I raised that exact issue in Meta:Requests for bureaucratship/Billinghurst. We are either going to get serious about this or not. The fiddle-faddle that goes on. Appoint two or three crats, get numbers up and we can do the job. Ensure that we keep numbers up.  — billinghurst sDrewth 12:49, 18 October 2021 (UTC)
Some brainstorming from me:
  • Do just one admin activity review per year.
  • Change the inactivity definition to 20 edits or admin log actions in the last 12 months.
  • Remove or reword the automatic removal criteria.
    • Automatically removing admins that use their tools but fail to make 10 edits, as it happens now, do not make much sense to me and should be repealed.
    • We could perhaps keep it but reword the criteria to apply only for admins that were totally inactive (0 edits/log actions) or that fail to make a number of edits and log actions since the last notification/review.
  • Expand the time to answer from one week to two weeks to ensure fairness to those that can't log-in every day but whose contributions we value as well.
Thanks, —MarcoAurelio (talk) 09:53, 20 October 2021 (UTC)
I agree with you that it does not make much sense to separate edits and log actions in the current way in the removal criteria. Maybe it should just become "less than 10 edits or log actions" (20 for yearly) for the automatic removal, and "less than 20 edits or log actions" (40 for yearly) for the signature-required-removal. --MF-W 13:34, 20 October 2021 (UTC)
Defining inactivity as less than 20 edits or log actions in the last twelve months looks sensible to me. Maybe 40 is too much? I ain't sure about automatic removal. It is unfair as it is written now. I'd be in favor to keep it maybe for the situation were the admin was notified once and is still inactive in the immediately next inactivity check, or maybe for people that has not made any edit or log action in the last year. Shall we discuss this in Meta talk:Administrators/Removal instead of here? —MarcoAurelio (talk) 10:55, 23 October 2021 (UTC)
Agreed to the move. Now we need 10 logged actions with 10 edits to be free from removal notices, 10 edits to be free from automatic removal. If we are doing once a year, it will mean 20 logged actions with 20 edits to be the former, 20 edits to be the latter, which means 40 in this sense. I will think since there dramas before w.r.t. the edits components and logged actions, let's put it as logged actions and / or edits to be easier for administration. Simple wiki now have it as 100, I don't oppose 20 but will think 40 will be acceptable (as it's the status quo anyway). Camouflaged Mirage (talk) 08:52, 27 October 2021 (UTC)
I don't know. If someone has not made 10 edits in the last 6 months to Meta, how familiar are they with community norms? --Rschen7754 02:21, 29 October 2021 (UTC)
I get your point. Maybe we could ask them to sign. However, I'd not expect admins unfamiliar with community norms or policies to remain in the role for too long. The community would complain at wrong actions and eventually a request to remove his permissions would be lodged should the admin behaviour continued to be grossly erratic. I feel the current 10 edits criteria does not solve the lack of familiarity with community norms either considering that 10 edits anywhere (e.g. your user page and/or user talk page) do count and can be easily dodged. —MarcoAurelio (talk) 11:12, 6 November 2021 (UTC)
I don't see honestly how 10 edits can be seen as knowing the community norms to be honest. 10 reports to SRG counts as 10 edits, if we want to be meaningful to gauge admins community involvement, a better but harsher way is to use edits to Meta namespace or maybe for CNA is on central notice request pages, but these are very normative in nature as I can be reading discussions and have nothing to add, one support without justification isn't the most helpful and people wanting to pander can just blind support 10 times. Camouflaged Mirage (talk) 08:27, 8 November 2021 (UTC)

Should user groups' page titles use singular or plural form?

Latest comment: 3 years ago7 comments4 people in discussion

ex. Meta:Bureaucrats, Meta:Administrators, Meta:Confirmed users, Abuse filter helpers; Bureaucrat, Administrator, Registered user, Abuse filter maintainer. Maybe we should try to unify the format? Except for groups like Founder which is specific. Even if there's a legit reason behind these though, I would still like to learn. —— Eric Liu（Talk） 15:28, 7 October 2021 (UTC)

The former of those are project local policies, etc, for how we manage those groups of people. The later of your example are definitions of what those things are globally, don't see any need to change that, and redirects already exist. — xaosflux Talk 13:08, 8 October 2021 (UTC)
There are still inconsistencies (Abuse filter helpers? And Interface administrators etc.), but well I guess it's fine. Thanks for your explanation. —— Eric Liu（Talk） 13:38, 8 October 2021 (UTC)
I had requested some sort of change at Talk:Abuse filter maintainer#Page move, so thanks for raising this here. ~~~~
User:1234qwer1234qwer4 (talk) 15:36, 22 October 2021 (UTC)
Just found out that Category:Abuse filter maintainers in Category:Abuse filter maintainer, aren't these two literally the same thing lol —— Eric Liu（Talk） 10:50, 10 November 2021 (UTC)
Both are different in scope, one is the maintainers (holders of the right) another is the pages related to the right. Better to file a WM:PPM discussion? Camouflaged Mirage (talk) 12:22, 10 November 2021 (UTC)

Here's some statistics, may be incomplete:

  • Pages with "Meta:" and with "s": Meta:Account creators, Meta:Administrators, Meta:Autoconfirmed users, Meta:Autopatrollers, Meta:Bureaucrats, Meta:Central notice administrators, Meta:CheckUsers, Meta:Confirmed users, Meta:Interface administrators, Meta:MassMessage senders, Meta:OAuth administrators, Meta:Oversighters, Meta:Patrollers, Meta:Push subscription managers, Meta:Translation administrators, Meta:Uploaders, Meta:ZeroRatedMobileAccess administrators.
  • Pages without "Meta:" and with "s": Abuse filter editors, Abuse filter helpers, API high limit requestors, CAPTCHA exemptions, Global deleters, Global IP block exemptions, Global renamers, Global sysops, Interface administrators, Interface editors, New wikis importers, Stewards, System administrators, WMF Researchers.
  • Pages with "Meta:" and without "s": (Meta:Flood flag,) Meta:IP block exemption.
  • Pages without "Meta:" and without "s": Abuse filter maintainer, Administrator, (Blocked user,) Bot, Bureaucrat, Flooder, (Founder,) (Global rollback,) Importer, (IP block exempt,) (Newly registered user,) (Recursive export,) (Registered user,) Rollbacker, (Unregistered user).

Clearly no definitive standard, though what Xaosflux saids is mostly true. —— Eric Liu（Talk） 11:08, 10 November 2021 (UTC)

Stop allowing 24 hour crat nominations

Latest comment: 3 years ago18 comments11 people in discussion

Our policy allows 'crat nominations to be closed successful after just 24 hours when there is endorsement by two current crats, 150 edits/log actions in the last 6 months and no objections by other users within those 24 hours. While this is allowed by the policy, it is quite snowbally in my opinion. As long as two of the current bureaucrats agree, other users only have 24 hours to raise concerns. That is very little time. In my opinion, too little time for a responsible office like that of a bureaucrat. Besides, I don't really see the advantages, bureaucrat candidacies are very rare and I think they can run for a week, so that all users have the chance to express their opinion. --Zabe (talk) 19:36, 21 October 2021 (UTC)

When this policy was made, it was specifically with the goal of making RfBs very easy, based on the idea was that all meta admins are, in principle, trustworthy enough to be bureaucrats (see here for the old discussions, continuing in several sections). RfBs and consequently bureaucrats on Meta have become a rare species in the last few years, so that I have found myself one of only two bureaucrats twice, but I think that's actually a sign of the diminishing importance of bureaucrats, who, compared to the past, can neither rename nor help with SUL unifications nor desysop anymore. The 2008 situation described as "since all of our admins are promoted by pretty much all the community's approval" still (or again?) seems rather fitting to me. On the other hand, 24 hours is really a short period in the context of usual deadlines. --MF-W 22:14, 21 October 2021 (UTC)
Maybe three days or something? If a week is too long. —— Eric Liu（Talk） 11:18, 22 October 2021 (UTC)
Keep at 24h, the meta community is quite small and I still believe that all admins are trusted enough to be crats here, no point prolonging the holding time and I trust the crats will extend if they find something fishy or not right. What the issue with the policy is that it needs 2 existing crats to endorse, with now we having 3, we cannot expect all the crats to be 24/7 on wiki, so the timing might be a little longer than 24h in some situations. Camouflaged Mirage (talk) 12:28, 22 October 2021 (UTC)
Trust your 'crats. This is not a high risk, high use item. It isn't being abused, and the crats can push back to the community as they choose.  — billinghurst sDrewth 13:07, 23 October 2021 (UTC)
  • I've never liked the current process, and don't think it needs a complete overhaul but some ideas:
    1. Just make this a week like most other timed discussions here.
    2. Have two paths to success:
      (a) The current "two current bureaucrats" endorse and a lack of a consensus in objection is present
      (b) an actual consensus of support is present
    This would eliminate pocket vetoes from current crats, allow the no-objection route to continue if endorsed, but allow sufficient time for any actual objections to be heard. I can't see a week being onerous, this isn't a process that requires urgency. — xaosflux Talk 12:58, 27 October 2021 (UTC)
    Support Support Camouflaged Mirage (talk) 13:01, 27 October 2021 (UTC)
    Emphasizing the route (a) I will support it to remain as 24h or at most 48h, or else it's really moot as (b) will take around the same time. Camouflaged Mirage (talk) 14:00, 27 October 2021 (UTC)
    @Camouflaged Mirage: my idea with (b) was that it didn't require the crat's to be involved. I'm still in favor of just using a week - but if there is the current endorsement not actually requiring "supporters" (i.e. it can just sit there and not be objected to). We have pretty much rejected speedy closures on most everything else here (Meta:Snowball) due to nature that contributors may not check in very often. — xaosflux Talk 15:11, 27 October 2021 (UTC)
    @Xaosflux I think I get your point now. Yes, we do have that policy here. What I am thinking is that for crat since there are other criterions which significantly narrow the candidate pool, and the existing crats now are all well trusted to make that judgement call and it requires 2, I don't see how a lightweight process is that risky in these narrow parameters. If we want, we can make the crats needed to 3, but based on the status quo now, it will restore the pocket veto situation. 3 pairs of eyes is better than 2, so I am saying if we really want to be careful to promote, we can do 2 crats endorsements, and an uninvolved crat close the speedy promotion. Camouflaged Mirage (talk) 11:55, 28 October 2021 (UTC)
    I absolutely would not want to require more crat endorsements! I'm not really in favor of requiring any, but recognize that it is historical and has some support from others so I wasn't proposing removing that path to success. — xaosflux Talk 14:29, 28 October 2021 (UTC)
    @Xaosflux Not to worry, I also don't wish to see the requirements to 3, just giving all possible options to consider if the concern is perceived lack of scrutiny of the candidate due to the short timeframe. What my point is that if the crat endorsement route is as long as the community support alone route, then it seems more practical to just do the full 7 days, community support alone. I will support having both routes existing concurrently when there are significant enough differences between the 2, now it seems that what the crats have is a more powerful vote in the RFB. Correct me if I am wrong, just trying to make sense of the proposal. Camouflaged Mirage (talk) 17:39, 28 October 2021 (UTC)
    Support Support. No prejudice against current appointment process, but Xaosflux's proposal seems fair enough. Sgd. —Hasley 13:50, 27 October 2021 (UTC)
    I agree with Xaosflux's proposal. I'm not aware of any actual issues as a result of the current way of crat nominations, but the objections here are valid, and Xaosflux's proposal seems a good way of mitigating future issues. Best, Vermont (talk) 23:35, 28 October 2021 (UTC)
    I'd be in favour to just run RfBs the same as regular RfAs for the sake of simplicity. Thanks, —MarcoAurelio (talk) 11:00, 6 November 2021 (UTC)

Comment Comment I want to hear a better argument than "I don't like it".  — billinghurst sDrewth 12:07, 29 October 2021 (UTC)

"We have pretty much rejected speedy closures on most everything else here (Meta:Snowball) due to nature that contributors may not check in very often." is a clear enough argument for me. ~~~~
User:1234qwer1234qwer4 (talk) 15:34, 17 November 2021 (UTC)
Support Support RfAs and RfBs on Meta should not be closed after 24 hours, since administrator and bureaucrat rights are positions that require strong community support and trust, as well as the ability for the holder of the rights to continue to uphold that standard after being given the flag, and as such, these are not the kinds of positions where decisions about granting access should made with urgency. Hx7 (talk) 19:06, 9 December 2021 (UTC)
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Meta:Babel/Archives/2021-10&oldid=22558882"