As of now, completing this task means submitting the block will always trigger two blocks: one global, one at meta-wiki. With the "also block locally" checkbox, this makes sense, but after this change, not so much. Can we whitelist blocks partially?

Also, note the form has an associated API, which the stewards make an use of.

@Niharika there are a few other options that currently possible to specify when blocking the user on the local wiki. These are:

• Whether the local block disables emailing other users (unchecked by default)
• Whether the local block should disable account creation (checked by default)
• Whether the local block should affect anonymous users only (checked by default, only affects IP and IP range blocks)

What, if anything, are we going to do with these check boxes on the modified form?

See the following for the expanded list of checkboxes:

I think this needs wider discussion, not a discord chat - especially if the ask is for some reason to actually remove technical capabilities (as opposed to just changing the webui (and api?) pre-filled check boxes).

Blocking on needing community discussion, I can't see why staff would need to mandate removing technical options from volunteers.

In T380743#10353058, @Urbanecm wrote:

As of now, completing this task means submitting the block will always trigger two blocks: one global, one at meta-wiki. With the "also block locally" checkbox, this makes sense, but after this change, not so much. Can we whitelist blocks partially?

Also, note the form has an associated API, which the stewards make an use of.

Assuming local admins could still unblock-locally, then re-block locally just like any other project?

In T380743#10353501, @Xaosflux wrote:

I think this needs wider discussion, not a discord chat

Can you clarify? What kind of discussion would you imagine? And more importantly: do you have any objections to the proposal (and if so, what objections)?

especially if the ask is for some reason to actually remove technical capabilities (as opposed to just changing the webui (and api?) pre-filled check boxes).

! In T380743#10353502, @Xaosflux wrote:

Blocking on needing community discussion, I can't see why staff would need to mandate removing technical options from volunteers.

No proposal in this task removes a feature. The only thing that is proposed to change is how the global block form behaves. There is nothing preventing a steward from manually applying a local block in different ways (or lifting a block that was automatically applied). After implementing this task, applying a global block on "all wikis except enwiki" (Special:GlobalBlock => whitelist@enwiki) and "all wikis except metawiki" (Special:GlobalBlock => unblock@meta) would work equivalent to each other.

Since the explanation in the comment that adds the track is not correct, I'm removing the tag, until it can be clarified.

The task description literally asks to "remove" an option.

The current feature is that gblocks don't apply to metawiki. This can be useful to allow blocked network ranges to have somewhere to appeal.

In T380743#10353711, @Xaosflux wrote:

The task description literally asks to "remove" an option.

The current feature is that gblocks don't apply to metawiki. This can be useful to allow blocked network ranges to have somewhere to appeal.

Maybe I can clarify. The point some stewards made was that it is unintuitive to make a "global" block to later realize that the global block did not apply to meta. Also in most global block cases meta blocking is warranted.
The idea proposed on this task is to default block user on meta as well but leave their meta talk page open to allow them to appeal.
We're not removing any ability - just rejigging the options in a way that is more intuitive.

So back to the list, I can also see reasons why when blocking a network globally we wouldn't want to block 'send email' locally -- as that will prevent use of Special:Contact (which is used for appeals as well).

If the user story here is that due to the 'also block locally' box being off by default on the webui form - stewards are not applying local blocks when they probably should be, wouldn't this be more simply improved by just having that option checked by default on the web form?

In T380743#10353886, @Xaosflux wrote:

So back to the list, I can also see reasons why when blocking a network globally we wouldn't want to block 'send email' locally as that will prevent use of Special:Contact (which is used for appeals as well).

Good point. I think we shouldn't block Special:Contact or "sending emails" by default (but allowing a steward to do that if they want to do so). This would be similar to allowing talk pages by default (for public appeals). What do you think?

If the user story here is that due to the 'also block locally' box being off by default on the webui form - stewards are not applying local blocks when they probably should be, wouldn't this be more simply improved by just having that option checked by default on the web form?

By itself, that would have basically the same effect as what is proposed – it's very unlikely we would uncheck that particularly actively. I also like making metawiki's behavior (as to global blocks) more similar to the rest of projects. While metawiki serves for appeals, that only applies to certain parts of metawiki, not metawiki as a whole.

Using local meta blocks means that globally blocked users get the Meta appeal instructions when editing Meta, instead of the global block appeal instructions. Then some annoyed Meta admin pings the blocking steward, who then probably ignores it because they won't review appeals for their own block, and it sits in the Meta unblock category until someone who's both a Meta admin and a steward comes along.

Meta user talk and email access should be enabled by default.

This was discussed during the December Stewards meeting. Stewards agreed on continuing this, We should also add a new global block option that would control whether emails are allowed to be sent (since sending an email from the wiki is the appeal process). To summarize the consensus, we would:

• make metawiki a standard consumer of the global blocks (exemptions can be done via whitelisting as needed),
• global blocks would not apply to user talk edits at any wiki (unless specifically enabled), and
• global blocks would not apply to sending emails (unless specifically enabled)

@Tchanders @Niharika Do you have any thoughts on that change?

Note:
(1) Actually there are four options of talk page access in theory but I am not such which is needed or wanted:

1. Disallow user from edit all user talk pages (the de facto with Meta block without talk page access, and the de facto for global locks)
2. Allow user to edit all user talk pages (what Martin said "global blocks would not apply to user talk edits at any wiki (unless specifically enabled)")
3. Allow user to edit all non-Meta user talk page (the current task description says "Add an option to 'Block user from their meta talk page' (unchecked by default)") - of course if we have the first two we can also achieve this one by also imposing a local block in Meta, but this will direct blocked user to appeal process in Meta
4. Disallow user from edit all user talk pages except Meta (what ACN proposed, and de facto with talk page access)

(2) Currently GlobalBlocking disables user's talk page and email access on wikis block is active, and provides no option to enable the access, nor does the database schema support such. So if we want to add such options we need to do a schema change. Though we will do a much breaking schema change when we introduce global multiblock (T375992#10187120).
(3) My opinion on social side: to interfere autonomy of local projects as little as possible, talk page access in local should not be revoked in advance unless cross-wiki user talk pages disruption occurs. However, since e-mail are global and it is easy to circumvent one wiki's email block by using email in another wiki, and there are no public log of emails so detect crosswiki email abuse is harder, I will prefer an all-or-nothing approach: email access should be revoked globally for globally blocked users when email is abused in any wiki and user should direct appeal to UTRS or stewards@wikimedia.org if they can neither edit their Meta user talk page.

In T380743#10384764, @Urbanecm wrote:

@Tchanders @Niharika Do you have any thoughts on that change?

Thanks for the ping. Sounds like it could benefit from some design specs, particularly if we work on this alongside T375992: Design the workflow to prevent access to IP Reveal for specified users.

If this may be incorporated in to a larger work, perhaps part of the user story can be delivered with the initial change being to the WEBUI default option:

CHANGE:
- "Also block the given user locally on this wiki" : TRUE

Keep defaults for the discovered options:
Locally block anonymous users only: TRUE
Locally disable account creation: TRUE