Project:Village Pump

This page is only for discussing issues related to MediaWiki.org site.

To get help with MediaWiki software, ask on Project:Support desk.

Hello. A policy regarding the removal of "advanced rights" (administrator, bureaucrat, interface administrator, etc.) was adopted by global community consensus in 2013. According to this policy, the stewards are reviewing administrators' activity on all Wikimedia Foundation wikis with no inactivity policy. To the best of our knowledge, your wiki does not have a formal process for removing "advanced rights" from inactive accounts. This means that the stewards will take care of this according to the admin activity review.

We have determined that the following users meet the inactivity criteria (no edits and no logged actions for more than 2 years):

1. Petrb (bureaucrat, administrator)
2. VasilievVV (bureaucrat, administrator)
3. AhmadF.Cheema (administrator)
4. BRUTE (administrator)
5. Catrope (administrator)
6. Guillom (administrator)
7. Isarra (administrator)
8. Magnus Manske (administrator)
9. Mardetanha (administrator)
10. SVG (administrator)

These users will receive a notification soon, asking them to start a community discussion if they want to retain some or all of their rights. If the users do not respond, then their advanced rights will be removed by the stewards.

However, if you as a community would like to create your own activity review process superseding the global one, want to make another decision about these inactive rights holders, or already have a policy that we missed, then please notify the stewards on Meta-Wiki so that we know not to proceed with the rights review on your wiki.

Thanks,

@Superpes15: Hi there, can you please point to where this wiki was notified that you think we follow this process? I don't recall any discussion, but I might have missed it. At first glance, many of the individuals you've listed are active but on other accounts, which is allowed on this wiki (as we're rather unlike normal SUL wikis), and so I don't think your assessment is necessarily valid. Where can we opt out?

@Jdforrester: Mediawiki falls under the AAR as far as we know since it doesn't have an inactivity policy - see also AAR2022 for example (we removed some sysop flags last year)!

Thanks for linking there. It shows that that posting also didn't get any response from the local community, sadly. :-(

See Project:Requests/RfC/Removal of inactive bureaucrats and interface admins#AAR

Catrope is wmf staff, i dont think he should be considered inactive unless his staff account is also inactive.

I also think gerrit commits should count towards activity, generally speaking.

Edit: guess this was discussed in the past... oh well.

Fine with Catrope being kept. Guillom is also WMF staff, but their staff account also has no edits or logged actions in two years.

On Gerrit commits (aside from the WMF staff) the only people I could find Gerrit commits for are Petrb and Isarra, neither of whom appear to have committed anything in the last two years. Personally I'm more inline with Skizzerz's comment in the linked RfC and think that since MediaWiki.org adminship gives you no authority over Gerrit then Gerrit commits are irrelevant, but I'll respect the consensus that the community comes to.

Given Project:requests states "Being a developer (someone with merge access who uses it to maintain code that runs on Wikimedia sites) automatically entitles you to at least administrator status", it seems weird that someone could be both "inactive" and meet the criteria for being promoted to admin. I'd argue that one of these two policies should change for consistency.

I think establishing our own policy so we can manage it ourselves would be more practical than worrying about AAR being done on our behalf regardless of the disposition of the above list of users.

@Charitwo Do you think mwwiki is large enough to self maintain and run the process reliably every year?

I believe so. I also believe in project autonomy, and the less the stewards have to worry about, the better. This wiki has also been sort of unique from other projects and has always had a degree of autonomy, this process shouldn't be any different.

@Charitwo I think you're right, especially with the special rule that @Bawolff highlighted for this wiki that gerrit (and GitLab?) activity counts as "activity". Do you want to start an RfC?

@Jdforrester: @Charitwo: I started an RfC a few years ago to adopt AAR because we weren't doing anything about it otherwise. The rule before then was "you just keep admin forever." While we might be large enough to self-sustain and run a yearly process, historical evidence has proven otherwise. If an RfC is opened for us to do our own thing, I think the point of "who is doing this work" needs to be tackled.

I'm not necessarily opposed to us adopting some other criteria, although my stance remains that activity off-wiki isn't sufficient to maintain sysop bits here. Sysop bits shouldn't be a mark of community status, but rather an indication that you're willing and able to perform cleanup/maintenance tasks on the wiki. If you've literally never edited the wiki once in 2 years, well, it's pretty obvious you aren't doing that.

I think the point of "who is doing this work" needs to be tackled.

Why? What problem does reducing the number of people who can help out in an emergency fix?

You can read the RfC I linked for reasoning as to why I believe people should not have advanced privileges if they are inactive, or the reasoning behind why AAR as a thing was established globally (the reasoning is much the same). I don't see a particular need to re-hash that here.

Given my stance that we need some process to deflag inactive accounts, and since before my RfC that adopted AAR we were not deflagging anyone, I believe that any RfC to regain autonomy in this area would need to answer the question of "who will be performing the work in enforcing the new policy" because adopting a new policy that says we'll do something but then never enforcing it would run counter to why the policy exists in the first place.

In that entire thread you linked there's only one active developer who voted in approval, and then you closed it in your own favour. I feel extremely uncomfortable about you pushing this POV about how to run this wiki, but of course it's policy until we overturn it.

In terms of "who will run this process", I'm happy to do so each January or whatever if that's the will of the community.

The poll was open for almost two months, and I believe it was linked on IRC a couple of times as well during that period (although I haven't gone back and checked that to confirm). I don't appreciate that you seem to be implying that I somehow acted inappropriately in closing the straw poll simply because it ended up going in my favor.

If you want to open an RfC to change the process, go for it. My request above was simply to identify who would be doing the enforcement of the changed process. If the community opts to go forward with it, then all is well.

Not arguing against the above list, if you're inactive here you're inactive here. Especially if you seem to not care about the rights being removed. My comment was centered around it being nice if we were more autonomous.

As far as off-wiki activity, I agree with you completely. The rights don't benefit you on off wiki, on platforms with their own access system.

I noticed that many translatable templates use code like {{#invoke:Template translation|renderTranslatedTemplate|template=<!--Template name-->|noshift=1|uselang={{int:lang}}}}. However, then translation will not show properly when using interface language like zh-cn or other variants of Chinese (zh), because templates were translated to Chinese only in zh.

For example, the Chinese translation of sandbox header only shows in (zh) but not in (zh-hans), (zh-cn), (zh-hant) etc.

I thought of two maybe practical solutions:

1. Replace all {{int:lang}} with {{Zh other}}. This may be a big project.
2. Edit Module:Template translation. When uselang input variants of Chinese(like zh-hans, zh-cn, zh-hant etc.), automatically change it into zh. This works like {{Zh other}}, and may be easier.

Hope someone would help with this problem.

(Sorry for my poor English)

I think there are some other languages with variants too (File:MediaWiki fallback chains.svg). I'd prefer a more generalized template name. Full support can be added over time.

Oh, maybe you are right. I did't noticed that.

You can edit Module:Template translation/sandbox and I can review and deploy.

Sorry, but I can't write Lua… Besides, according to the words of 94rain, I think maybe we need a separate template or module to deal with the Language fallback, and maybe I'm not able to make it.

No action taken at this time.

Please block Special:Contributions/2A01:5EC0:5019:79BC:1:0:47DD:B704

No block was made by the deleting admin.

Okay, I assume that is just at admin discretion @Tropicalkitty?

Depends which admin is reverting/deleting and the situation. I only see that one edit though. There’s nothing of significance in the edit log other than blanking attempts.

Alright then. Well I'll be more hesitant to post requests in the future. Sorry about that.

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Dear all,

Thank you everyone for following the progress of the Universal Code of Conduct. I am writing to you today to announce the outcome of the ratification vote on the Universal Code of Conduct Coordinating Committee Charter. 1746 contributors voted in this ratification vote with 1249 voters supporting the Charter and 420 voters not. The ratification vote process allowed for voters to provide comments about the Charter.

A report of voting statistics and a summary of voter comments will be published on Meta-wiki in the coming weeks.

Please look forward to hearing about the next steps soon.

On behalf of the UCoC Project team,

RamzyM (WMF) 18:23, 12 February 2024 (UTC)

Tracked in Phabricator
Task T355445

Hello! It seems to me that it is a little wrong that 'user' users can edit manual tags, since such vandalism is easy to overlook and quite difficult to rollback: https://www.mediawiki.org/w/index.php?title=Special:Log&page=Special%3ALog%2Fpagetranslation&type=tag

I support this. There's another right called "applychangetags" that won't affect the ability to tag their own edits when using gadgets to perform actions.

Agreed. We've had a years-long history of vandalism using this feature not being noticed or reverted.

+1; I blocked the most recent user vandalizing via tags but didn't go further with cleanup when I saw how many tags were added, we definitely shouldn't allow the cleanup problem to be compounded further.

Also as a general note, it's not just pagetranslation stuff that gets vandalized with tags: Special:Log/tag.

Support. And I feel this should probably be removed from 'user' user group by default. Is there a reason to enable it for users when we already have 'applychangetags'?

Tracked in Phabricator
Task T355639

@94rain, I agree with you, the right should be removed from regular users by default.

I've been wondering the whole time why we can do that 🤣

ABS2030 Philipnelson99 (talk) 20:19, 3 February 2024 (UTC)

See deleted contributions as well https://www.mediawiki.org/wiki/Special:Contributions/ABS2030

Blocked

Pointed to relevant pages

i just made a profile for a music artist and cant seem to get it posted, anyhelp will be appreciated

If you are referring to this wiki, Please see Project:About#What MediaWiki.org is not.

hello

can you please check my sandbox and let me know what is wrong exactly and how to solve this

thanks

Please direct your questions on this matter to w:WP:TEAHOUSE

Please block 5.124.254.188 Philipnelson99 (talk) 02:04, 1 February 2024 (UTC)

Contribs for convenience: https://www.mediawiki.org/wiki/Special:Contributions/5.124.254.188

Range blocked by Dinoguy1000.

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Hello all,

I am reaching out to you today to remind you that the voting period for the Universal Code of Conduct Coordinating Committee (U4C) charter will close on 2 February 2024. Community members may cast their vote and provide comments about the charter via SecurePoll. Those of you who voiced your opinions during the development of the UCoC Enforcement Guidelines will find this process familiar.

The current version of the U4C charter is on Meta-wiki with translations available.

Read the charter, go vote and share this note with others in your community. I can confidently say the U4C Building Committee looks forward to your participation.

On behalf of the UCoC Project team,

RamzyM (WMF) 16:59, 31 January 2024 (UTC)

User blocked.

spammerLOLfukNIGGASrapistBECHfag Philipnelson99 (talk) 20:07, 29 January 2024 (UTC)

 Done