Meta:Babel

From Meta, a Wikimedia project coordination wiki
(Redirected from Babel)
Jump to navigation Jump to search
 ← Index of discussion pages Babel archives (latest) →
This is the general discussion forum for Meta (this wiki). Before you post a new comment please note the following:
  • You can comment here in any language.
  • This forum is primarily for discussion of Meta policies and guidelines, and other matters that affect more than one page of the wiki.
  • If your comment only relates to a single page, please post it on the corresponding discussion page (if necessary, you can provide a link and short description here).
  • For notices and discussions related to multilingualism and translation, see Meta:Babylon and its discussion page.
  • For information about how to indicate your language abilities on your user page ("Babel templates"), see User language.
  • To discuss Wikimedia in general, please use the Wikimedia Forum.
  • Consider whether your question or comment would be better addressed at one of the major Wikimedia "content projects" instead of here.
Wikimedia Meta-Wiki

Participate:

Filing cabinet icon.svg
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.
Communication
Wikimedia Social Suite
Meetup
Babel
Distribution list
ComCom
Mailing lists
Overview
Administration
Standardization
List info template
Unsubscribing
Wikimedia IRC
Channels listing
#wikidata-admin
#wikimedia-admin
#wikipedia-en-admins
Channel operators
#wikimedia-admin
#wikipedia-en-admins
#wikipedia and #wikipedia-en
Instructions
Guidelines
#wikipedia
Group Contacts
Noticeboard & Log
Cloaks
Bots
FAQ
Stalkwords
Quotes (en)
archives
Quotes (fr)
Other chat networks
Telegram
Discord
Matrix.org
Steam

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

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 LiuTalk 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 LiuTalk 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 LiuTalk 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 LiuTalk 11:08, 10 November 2021 (UTC)

Inactivity removal for CN admin[edit]

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)
  • Just a note, see comments in Meta talk:Administrators/Removal/October 2021 - when checking for "activity" of CN's - there are additional places that need to be checked as all of the logs for that system are not integrated. — xaosflux Talk 13:42, 20 October 2021 (UTC)
    • This is why a regular check if people want to continue would be the easiest - no need for anyone to check multiple logs. --MF-W 13:44, 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)
    • By "contributions as a developer", do you mean actions requiring the CNA rights? --MF-W 21:54, 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[edit]

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)

Stop allowing 24 hour crat nominations[edit]

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 LiuTalk 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)

Mi Wikimedia no envía correos de resetear contraseña[edit]

Hola, tengo Wikimedia sobre Raspberry Pi 4. Funciona perfectamente. La tengo privada, es decir con clave de acceso para poder entrar. El problema está que he creado usuarios nuevos y le he agregado su correo yen la contraseña le he puesto que la genere automáticamente y se la envíe al nuevo usuario. Sorpresa que no envía correo al usuario nuevo. El usuario pone su nombre de user y le da a olvide su contraseña y el sistema le dice que le ha enviado un correo con el restablecimiento de la contraseña, pero no recibe nada. He probado a olvidar mi contraseña (admin) y si me la envía a mi correo. Que hago mal? A alguien le ocurre esto? El Localsetting.php he agregado SMTP con mis datos del correo del admin. No sé qué hacer más.

—The preceding unsigned comment was added by Rubicop (talk) 4 November 2021

@Rubicop: Hola. Desde esta página no podemos ayudarte con tu pregunta. Quizás tengas más suerte preguntando en mw:Project:Support desk (en inglés, preferentmente, dado que la mayoría de los desarrolladores que responden allí son angloparlantes). En esa página hay una caja a la derecha con más enlaces donde se puede obtener asistencia en relación con las instalaciones MediaWiki en otros sitios web. Un saludo, —MarcoAurelio (talk) 11:18, 6 November 2021 (UTC)

Meet the new Movement Charter Drafting Committee members[edit]

The Movement Charter Drafting Committee election and selection processes are complete.

The committee will convene soon to start its work. The committee can appoint up to three more members to bridge diversity and expertise gaps.

If you are interested in engaging with Movement Charter drafting process, follow the updates on Meta and join the Telegram group.

With thanks from the Movement Strategy and Governance team

15:52, 5 November 2021 (UTC)

Help in regard to local admins/crats revocations[edit]

Hello there! I'm a bureaucrat from SqWiki. Can someone inform me a bit about the steps that would need to be taken if we'd want to change the time needed for admins/crats to have their privileges removed automatically? Where we can see the needed time? How does the overall procedure work in general? Our list of admins has started to become a bit large de jure but de facto we only have 1-2 admins active while others just do 1 edit only in some months/years just so they can keep their status and disappear for the rest of the time. (Maybe the same can be said about the crats list.) We'd like for things to be a bit more flexible, easier to become one (that part is on us) and easier to lose your privileges automatically if you're not active (and maybe easier to regain them once you become active again). For that I plan to open a discussion with my community but I want to be well-informed before so I can be clear with them, given that the topic might be of a delicate nature. I of course know that we can remove them locally (at least the admins) but I'd like for a system a bit "automatized" set upon certain criteria so it feels fair and it doesn't leave much place for complains, which can arise if the removal is let on local crats' hands. - Klein Muçi (talk) 21:48, 11 November 2021 (UTC)

@Klein Muçi: This is not really a question for this form as this is meant to be metawiki only conversation. The global policy for admin removals is AAR, and wikis are able to have their specific policies for the removal of accounts with any advanced right. There are a list from AAR of wikis that have policies different from the global. If the stewards were addressing a matter at a wiki they would want to see that there has been a discussion and a consensus of the community for them to act. So if you are looking for an automated process outside of AAR then have a community discussion and set your criteria. You can see English Wikisource's policy and processes for appointment and removal at s:en:Wikisource:Adminship and you can see the list of wikis that do something at d:Q4039395.  — billinghurst sDrewth 23:54, 11 November 2021 (UTC)
@Billinghurst, thanks a lot for your explanation! I found this page. I'll try to ask at the talk page there for further details. If you want to move the conversation you are free to do so. :) - Klein Muçi (talk) 00:07, 12 November 2021 (UTC)
@Klein Muçi: That is the page that identifies local policies as mentioned above. If you develop a local policy for de-admin then it should be listed there after you have had your local discussion and it has reached a consensus.  — billinghurst sDrewth 00:16, 12 November 2021 (UTC)
@Billinghurst, assuming local consensus was reached, would it need any extra step or can we just put our project there together with the limits and they're guaranteed to be taken into consideration? - Klein Muçi (talk) 00:21, 12 November 2021 (UTC)
It is my understanding that if your community reaches a reasonable consensus around administrator term, and the process for appointing and removing they are seen as your process. If you have a removal component for inactivity then that should be noted on the AAR subpage, if there is no activity component in your process then the global AAR process will apply for activity. If your community has a stricter process then usually the 'crats at a wiki will eityher remove per that community's rules where they have that right, or where they do not then they would put a removal request at SRP for the stewards to undertake.  — billinghurst sDrewth 06:01, 12 November 2021 (UTC)
@Billinghurst, no, we're talking exactly for an inactivity removal component only. We want, for example, to switch it from 1 edit in 2 years to, let's say just for an example, 50 edits in 1 year. If that quota isn't met, you get removed for inactivity. Is that possible if we are able to reach a consensus locally? - Klein Muçi (talk) 06:23, 12 November 2021 (UTC)
@Billinghurst, sorry for the disturb. Maybe my last message has gone unnoticed. I need an answer so I can start the procedures at my local community. If I'm not asking the right person, can you direct me to the right place/user? - Klein Muçi (talk) 10:59, 13 November 2021 (UTC)
Klein Muçi: AAR is the default removal for inactivity (please read the corresponding RFC for full background), it is the minimalistic approach while trying to leave decision making in local communities. Anything else is a variation and has to be a community consensus and noted on the AAR subpage. Have your discussion, and reach your preference, then update the AAR subpage with your new policy and a permalink.  — billinghurst sDrewth 11:10, 13 November 2021 (UTC)
@Billinghurst, yes. I fully understand what you wrote. My question is if there is needed any extra steps beside that or not. If we have our discussion, reach our preference and then update the AAR subpage with our new policy and a permalink, is it guaranteed to be followed? Whatever it is that we agreed on our discussion? Or are there limits we can't cross? That's what I was asking. Because I need to state these limits, if they exist, in the beginning of the discussion. - Klein Muçi (talk) 11:37, 13 November 2021 (UTC)
@Klein Muçi: I can only tell you to what the global community has agreed as their minimum standard for activity, and that is why I pointed to the RfC and the process that it set (yes, I was one of the architects of the original draft, the community amended through discussion). Stewards generally wish to see a community consensus for community's standards, and as I am no longer a steward so it is not my place to tell you the thinking of the current batch of steward's and how that discussion may occur and circumstance around which it occurs.  — billinghurst sDrewth 11:44, 13 November 2021 (UTC)
@Billinghurst, I understand. So at least there is not any known limits stated somewhere or any extra steps needed beside reaching an agreement and stating it there after the policy is done. Anything else I believe will be communicated to me by stewards if something is wrong after we get through with it, (if we do get through with it). Thanks a lot! :) - Klein Muçi (talk) 11:47, 13 November 2021 (UTC)
Policy is not particularly negotiable, and where it is not followed your process and decision can be challenged. Convention is negotiable. Interpretation is negotiable.  — billinghurst sDrewth 11:51, 13 November 2021 (UTC)

Inactive importers[edit]

Daniel Kinzler (WMDE) (talk · contribs) and Thehelpfulone (talk · contribs) have been inactive on this wiki since 2018 and 2020, respectively. Daniel has also concluded employment with WMDE. Should importer rights be removed? --Rschen7754 23:01, 13 November 2021 (UTC)

  • Remove both. — xaosflux Talk 12:39, 14 November 2021 (UTC)
    I'll remove Daniel's as his WMDE account is no longer used. I'd check with @Thehelpfulone whether he still needs/wants the permission, but if there's no reply after some time I'd say to remove it as well. —MarcoAurelio (talk) 10:29, 16 November 2021 (UTC)
    Asked [1], we'll see if there is a response. --Rschen7754 21:49, 20 November 2021 (UTC)

This Month in GLAM newsletter migration from Outreach to Meta[edit]

This Month in GLAM logo 2018.png

Hi everyone,

I'm here to announce and discuss an important project that the GLAM and Culture team at the Wikimedia Foundation is taking part in during the next few weeks.

Due to Outreach having a limited readership and visibility within the movement, our community newsletters (GLAM and Education) don’t always receive the attention they deserve. To address this, we’re working to facilitate with our colleagues in the Movement Communications team the migration of the This Month in GLAM newsletter from Outreach to Meta-Wiki.

Both teams are working on this task in the next few weeks in order to:

  1. Increase visibility and participation in the GLAM newsletter.
  2. Ensure the GLAM community has a place (Meta-Wiki) where they feel seen, engaged, and supported by the Wikimedia community, partners, and Foundation.
  3. Increase the amount of multilingual (or translatable) content to engage contributors from other languages and more regions.

This activity already has the support of the active newsletter’s main editors and it will also be accomplished by the newsletter main editor. It was also already announced in this October report in the newsletter, on Outreach's Village Pump, on social media, and on several mailing lists.

The migration of the report pages, talk pages, categories, and templates is planned to happen from November 19th to 30th, 2021. This period is important to accommodate the migration before the reports from next month. Any other modifications or corrections will be made before December 15th, 2021.

It is also important to notice that, as this is a migration, the pages from the newsletter on Outreach will move with their entire history and they will receive a redirect. For that reason, of course, that no content will be lost, forgotten, nor any page will be deleted or have its link erased.

If you have any other questions or ideas about the migration, please share your thoughts here or feel free to contact the GLAM & Culture team at glam(_AT_)wikimedia.org and the community editors at thismonthinglam(_AT_)gmail.com. --GFontenelle (WMF) (talk) 23:16, 17 November 2021 (UTC)

What does this mean in clear, understandable terms? Which pages will be imported (surely they will be imported as in Special:Import or equivalent mechanisms?), and under which titles? By whom? And what are "any other modifications or corrections" that will be made before December 15? Will outreachwiki be closed on December 15? --MF-W 00:46, 21 November 2021 (UTC)
Hey @MF-Warburg, the conversation on Outreach's Village Pump mentioned above has more context that might be helpful. As for what will be imported and how, there's a phab task tracking that work. It sounds like an import/export should work with some redirects and cleanup on Outreach (via a bot). Modifications or corrections is just a way of saying anything we've missed or hadn't considered before the next newsletter is published. There are no plans to close outreach on the 15th. We're working to move just the newsletters for now. The folks at the WMF helping with this process, myself included, are excited to be part of this change and know that it's an important one. Appreciate the thoughts and questions. Chris Koerner (Wikimedia Foundation) [he/him] (talk) 18:47, 24 November 2021 (UTC)

Talk to the Community Tech: The future of the Community Wishlist Survey[edit]

Magic Wand Icon 229981 Color Flipped.svg

Hello!

We, the team working on the Community Wishlist Survey, would like to invite you to an online meeting with us. It will take place on 30 November (Tuesday), 17:00 UTC on Zoom, and will last an hour. Click here to join.

Agenda

  • Changes to the Community Wishlist Survey 2022. Help us decide.
  • Become a Community Wishlist Survey Ambassador. Help us spread the word about the CWS in your community.
  • 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) 20:03, 26 November 2021 (UTC)