@TheresNoTime I'm wondering, is there a reason not to add those actions into extension.json as default value? Allowing global blocking filters sounds risky in general. Just a suggestion to consider :).

Summary for User-notice: After patches associated to this task get deployed, it will be possible to add user (talk) pages of an user you unblocked to your watchlist, both via Special:Unblock and via the API. Here is a screenshot of the future interface at Special:Unblock:

I meant the searching box in the top left corner (where you can put the ticket number and go to a given ticket directly). However, it all seems to work fine now. Closing as invalid. Thanks for the ping!

I'm fine with making that change and owning it for the Security-Team, provided @Urbanecm or any other stewards do not have any objections.

If we want to make automatic, we have to figure out how to do that

In T331492#8681199, @sbassett wrote:

In T331492#8677457, @Urbanecm wrote:

Can you clarify what "verified" means in this context? Does that mean simply verifying that the Phabricator accounts actually belong to a duly elected steward? Or some other kind of verification that needs to happen?

Just that the Security-Team approves this task. And that, yes, we assume that you and/or other stewards have verified the steward => Phab account relationship.

In T331492#8677350, @sbassett wrote:

In T331492#8677279, @Urbanecm wrote:

Hi, I need the Security team to add the newly-elected stewards to the ACL group (acl*security_steward description says Security-Team needs to approve each addition).

Hmm, that's weird. We don't require that for other security ACLs. I think the idea of self-management for those (members performing these updates) was built into that architecture, but I guess that's another matter.

In T331492#8677242, @Mstyles wrote:

@Urbanecm do you need the security team to take any action on this? I can add if needed, but it not I will untag the security team.

FTR, I've already performed the removals. That section mostly serves as a notification of 2023 steward departures.

In T331150#8664702, @Aklapper wrote:

@Leaderboard: Hi, could you please add some context? Which code base is this about? Thanks!

Okta's 2FA codes are not used by Wikimedia developer accounts (this is because developer accounts are used by volunteers as well, and Okta credentials are only issued to WMF staff). If you still have at least two remaining emergency codes, please go to Wikitech preferences and disable two-factor authentication there. After that's done, you'll be able to set it up again with your new phone (if so desired). Generally, it is preferred to self-service the disabling, whenever that's possible.

Thanks for making this task! However, I think that 2 edits per minute is a very low number. According to the MediaWiki.org docs, the ip limit is enforced on all non-autoconfirmed accounts from one IP address combined. In another words, two for users who are editing Wikipedia from the same IP address share the same limit. IP addresses are frequently shared by multiple users thanks to NATs and similar features. Limiting the number of edits per minute to two will probably have huge effect on outreach events or school editing, where many people edit Wikipedia at once.

I can delete Template:* pages now at gucwiki.

Change requested in this task was done many years ago. It is supposed to stay resolved.

Issue reported in this task has been resolved. For new issues, there are other tasks. Thanks.

In T172284#8653345, @Aklapper wrote:

This ticket was resolved 5 years ago. If there is some new problem, please file some new problem instead. Thanks.

In T313114#8651820, @hashar wrote:

Good news, the page Cookie (informatique) no more shows up the top reads of the Android Wikipedia Application. So I guess something is now flagging those views as automated which is great. That is how I noticed it originally.

According to LDAP tool, this is missing the nda LDAP group, which is required for JupyterHub logins.

Deployed.

Done.

FTR, the database was already created by @Zabe (there was no notice for this wiki :)).

Did a final test with r891505, it works. Resolving!

Last step here should be deploying r891317 and making the newly-added job a voting one.

Deployed.

In T308932#8628692, @Ladsgroup wrote:

[...]

Can we agree on dblists a new typical wiki should have, and introduce a new comman, something like composer dblist-manage init newwiki wikipedia, which would add newwiki to dblists each Wikipedia usually is?

That's a great idea, I will try to do it (maybe a dedicated ticket?) if no one beats me to it.

In T308932#8603337, @gerritbot wrote:

Change 885064 merged by jenkins-bot:

[operations/mediawiki-config@master] multiversion: Create dblist-manage command for easy add/delete

https://gerrit.wikimedia.org/r/885064

thanks for the answer! It's possible I'm missing something here, but I don't understand how the bullseye image would help in this case. As far as I can see, the bullsyeye image has neither mysql nor wget available (both of those utilities are needed by the script):

In T311281#8434690, @jhsoby wrote:

BTW, this is most noticeable with the watchlist (because that's the most used one, I suppose), but it also happens for the other accesskeys in the personal tools menu: . for going to your userpage, n for your user talk, and y for your contributions page, Not very surprising, but good to kind in mind nonetheless.

In T323277#8596212, @Tgr wrote:

Or maybe just leave it to the user to backport the dependencies with separate scap backport calls, and ask for manual confirmation that that happened (or check via git but that seems more fragile).

Hi @thcipriani and other Relengers, could this be prioritized please? Currently, this means for some changes, the deployer needs to fallback to an old deployment mode.

Deployed

I'll try to fix this.

Can you try again please? It should work now.

Can you please connect your Phabricator account with your wiki account, so we can ensure this request is authenticated? You can do this in your Phabricator preferences, under "External Accounts".

Glad to hear it's helpful!

Hello, I have a question here: as of today, lmowiktionary is a fairly small wiki with few admins. As having more admins is generally helpful, I'm wondering, is there a reason to avoid granting full sysop rights to people who want with the moving described in the task's description?