Marking as assigned to David since he was the one who added the floating IP (title of the task)

(Just as an extra note, mailcow’s default logo branding is still present on dark mode, only light mode is using the Wikimedia logo)

If using the same config, we would need to disallow global and local groups having the same name

This probably best avoided, quickly looking at Wikimedia Meta, this would at the least require the steward global or local group to be renamed, which may cause more headaches for updating things that rely on the group name (don't have an example on hand but I would not be shocked if some existing bots or tools check if a user is a steward by group name. Off Wikimedia, the Miraheze project also has at least 4 groups that have a local and global group of the same name. Making a slightly modifed version of the existing config seems to be the least bothersome option overall.

At least sometimes, no wiki accounts mentioned there would be created

Seems in both your example and mine, Alice, Bob and Mallory are created indeed, but I don’t think any of them use the password(haven’t thoroughly tested)

Seems to be fine -some 5 years later-.

In T383466#10450797, @MBH wrote:

As far as I understand,

• an admin enters "Москва" into text field in the blocking interface. Block doesn't work.
• an admin enters "москва" into text field in the blocking interface. Block works.

Gave this a try on another mediawiki instance, failed to reproduce. See https://publictestwiki.com/wiki/Special:Log?logid=38189. Maybe an issue on the alpha version of MW that Wikimedia is on?

In T383466#10450473, @MBH wrote:

Cyrillic. Capital-first-letter is enabled, I think, in all wikipedias (and definitely enabled in Russian).

Is this using the standard Latin alphabet or using uppercase in the Russian alphabet? Also, does ruwiki have the setting to always capitalize page names on? Capital titles is the default so partial blocks not working on capitalized doesn't make sense.

In T345477#10305980, @SomeRandomDeveloper wrote:

Should this be a magic word? Another thing to consider would be to show these stats on Special:Statistics, like Semantic MediaWiki does.

@Pppery if we move the m: messages to a Wikimedia specific collection, what would we make the default message. Would we have a link at all?

In T383362#10446516, @Tgr wrote:

Should be straightforward technically via the LinkerMakeExternalLink hook, but yes it would raise all kinds of SEO and usability and tool B/C issues, and on Wikimedia sites it would increase the amount of user tracking (currently we don't learn about a user clicking a link, I think it would be hard to avoid that data getting at least into the webrequest table).

In T383362#10446414, @Izno wrote:

I can only assume there was another event that caused this task since this is the second similar item showing up in my inbox today, please consider connecting that if it's not already connected.

Yeeeaaah, I’m going to get a gander and point at… this

In T381138#10446364, @bd808 wrote:

Tool was archived by its prior maintainer.

In T378901#10289683, @Himacharanbatchu wrote:

Thanks @taavi for the nice observations you made, I'll fix this :)

In T381138#10369300, @JJMC89 wrote:

FYI, there is nothing useful remaining in the tool's directory - any files to run the tool were removed prior to disabling. Other than the URL, there would be no difference to creating a new tool. (Anything that links to it can be updated.)

Hm, it is possible/worth it/has precedent to set a domain redirect to wherever the new version of the tool is hosted to minimize confusion?

(my 2c) I agree this should be changed for clarity, but given that the only people who would encounter this should be users who are experienced in its functions and read up on how it works, having a confirmation for changing the publicity of a Filter probably isn't needed.

Reported in https://issue-tracker.miraheze.org/T12766

I don't have the ability to do so, but can someone move this to the deployment requests column of Automoderator, please?

Fix merged, should work now but I'm not familiar with the CI system so if someone who knows how to use it and verify the issue is solved, feel free to close this!

Got a seemingly working one line fix, I’m going to test it a bit more and reformat, then see about merging it(great now I have to learn how to use gerrit)

(Miraheze Volunteer, Non-SRE) if this relys on the Job Queue it makes sense it's not functioning, Miraheze is recently moved it's jobrunner to Kafka from Redis and it's causing a few issue we are still working out(ie delayed notification) I'll see if there's anything we can do if we have time. Thanks Ciencia for pointing that out