I'm assuming these tags were kept because they were in the parent task, rather than included because this specific part needs to be reported. If I'm wrong, please readd them and explain why.

@TBolliger Since the mute list is a user preference, should this be part of T16950: [Epic] Support global preferences on Wikimedia wikis? Alternatively it could not use the user preference system (which might be the better choice, idk).

Perhaps. But I don't see any strong value in an option to not make this cross-wiki, which is what I believe T16950 will do.

There are probably a few ways to accomplish this, thus this investigation task to find the most optimal solution.

In T171624#3531218, @TBolliger wrote:

Perhaps. But I don't see any strong value in an option to not make this cross-wiki, which is what I believe T16950 will do.

That indeed is one of the things that will be discussed as part of that but there's a lot more that will be done as part of that ticket which will be helpful for this one. This can piggyback on the GlobalPreferences train and have the list as a global preference.

The one problem with that is that this doesn't act like a typical preference. You don't want the value in one wiki to be globally overridable. You want to be able to amend that list from any wiki. If we want that in GlobalPreferences, it'd need some modifications to the code in that extension and I don't know how big a task that'll be.

I'd personally vote for this to a special page of it's own bundled in Echo and not being a user preference. Instead having a table for it along with other Echo tables, maybe?

In T171624#3531805, @Niharika wrote:

I'd personally vote for this to a special page of it's own bundled in Echo and not being a user preference. Instead having a table for it along with other Echo tables, maybe?

I think that makes sense to me, but we're also wondering if the email block list will be the same list as the echo block list (in which case, it's just a notification block list).

@kaldari

It looks like these are the options:

1. Leave the Echo Mute List as a User Preference
   1. Wait for Global Preferences to be implemented
   2. Start the work on Global Preferences and this can be the first field that is globalized.
2. Move the Echo Mute List to it's own table within the echo extension (which we will then globalize)

What is your preference?

"Wait for Global Preferences to be implemented" seems like the best solution.

@TBolliger does that work for you? Will that mess up our quarterly goals?

Our quarterly goals never mention exact implementation details. Also — we should always favor building the right product if our decision-making leads us in new directions.

@kaldari , @Niharika , @MaxSem , @DannyH and I just had a quick discussion. We agreed on two things: 1) Mute needs to always be global. There is no use case otherwise. 2) Because the Mute feature will probably grow in scope (to include email, etc.) we will likely want something a little more robust than what Special:Preferences can offer. Therefore, we should start exploring how to build this outside of preferences.

I renamed this ticket because Mute will include (at minimum) Echo notifications, their email counterparts, and Special:EmailUser direct emails.

Fantastic! So the next question we need to answer is whether the notification block list should be in core or the Echo Extension.

Here are the choices as I see it:

1. Echo & Email share the same Mute List
   1. The mute list goes into core and Echo uses core's mute list. (least amount of work)
   2. The mute list is created for Echo. At a later date when we build the mute list for email, we move the Echo mute list to core. (most amount of work)
2. Echo & Email have separate Must Lists and we build/release them separately. (somewhere between the other two options)

My preference is 1A since it's the least amount of work. :) I also don't see why most people would want to block someone on email and not on echo (or vice-versa).

However, is there a use case where someone would want a separate Mute List for email? Even so, would it be more difficult for most users to manage both lists (i.e. is the option that some will use not worth the hassle to the majority?)

If we don't want to answer that question now, we can always build them separately, and combine them later if we want.

Thoughts?

In T171624#3532447, @TBolliger wrote:

I renamed this ticket because Mute will include (at minimum) Echo notifications, their email counterparts, and Special:EmailUser direct emails.

oh ok, so that answers my question then.

We plan on having a single Mute List (per user) for all notifications across all wikis.

My operating assumption as Product Manager is that there should be one Mute list — I see very little reason why someone would want to Mute a user for one communication channel but not another. I know @SPoore has voiced a different opinion, so we still need to discuss and decide.

Today I learned (TIL) that Echo handles email and web notifications. I was previously using "Echo" to refer to only web notifications.

This change will only be a change to Echo, not to core.

Whoops... I'm forgetting about Special:EmailUser which is part of core. So what I said above is still accurate. :)

Though perhaps it would be best if we created a new extension for the Block List (rather than adding it to core)?

@dbarratt — As soon as you, Dayllan and @kaldari (and anyone else from CommTech) agree to an implementation plan, please create whatever Phab tasks are needed, close this ticket, and bring the pertinent tickets into the Sprint 3 board.

@dmaza and I had a conversation about this and we were a little confused about the difference between Mute and Block, but I think we have a handle on it now (I vaguely remember a conversation about this a while ago).

Muting: User can still preform an action, but you never hear about it.
Block: User cannot perform certain actions.

Blocking, as I understand it, is an escalation of Muting (i.e. you would block people you've muted, not the other way 'round). Also, Blocking someone would potentially reveal to the other user that you have blocked them (i.e. if they try and email you, and it doesn't let them). But Muting someone would never be revealed.

Twitter makes this two separate lists:
Mute: https://twitter.com/settings/muted
Block: https://twitter.com/settings/blocked
As far as I know, if someone is blocked, they are also Muted.

Facebook also makes this two separate "lists"
Blocking: https://www.facebook.com/settings?tab=blocking
Muting: https://www.facebook.com/help/community/question/?id=10152335242449842

What we'd like to do is create a "Mute List" (and perhaps it needs a better name) on a Special page. Then Users can select (checkbox?) which users they would like to also block. This prevents having to have two separate lists, but also let's users remove more access.

We could also make this more granular in the future if we want (i.e. a checkbox to block emails, a checkbox to block user talk page changes, etc.).

That's an important distinction — if a user is aware that they have been blacklisted or not. But I still think there's an argument to be made that we only need one list. That muting blocking are one and the same. Users can already disable Special:EmailUser entirely, so if a Muted user attempts to email the Muter, the UI will look identical as if the Muter had the entire feature disabled.

In general, I like to build small and expand later if there's really a need. No need to boil the ocean for hypotheticals. We could start by building a single list and split later if necessary. That said, we are meeting on Wednesday to discuss how we will conduct out community consultation (see also: T173535: Perform Email Mute community consultation.)

Also also — the word "block" already has an established definition so we'd be best to find an alternative if we go this route.

I'm confused. MediaWiki already supports blocking users from using the email feature. That shouldn't be related to the muting feature.

In T171624#3534062, @kaldari wrote:

I'm confused. MediaWiki already supports blocking users from using the email feature. That shouldn't be related to the muting feature.

Where? I thought it was all or nothing?

Special:Block allows you to block a user from sending email (as an optional part of an editing block). This is commonly used against sock-puppet accounts that are created just for harassing people. This workflow has existed for years and works well. I would prefer that we not disrupt that particular feature unless there's a really good reason to.

That page is only for administrators. The only block action we can think about right now is a regular user blocking another user from sending them emails (which in my opinion should fall into "Mute")

In T171624#3534101, @kaldari wrote:

Special:Block allows you to block a user from sending email (as an optional part of an editing block). This is commonly used against sock-puppet accounts that are created just for harassing people. This workflow has existed for years and works well. I would prefer that we not disrupt that particular feature unless there's a really good reason to.

We have zero intentions of changing how Special:Block works, in regards to this Mute feature. As Dayllan said, this is just about user-controlled user-to-user muting.

So I was thinking maybe it would be best to do something like this?

1st Iteration would be the existing multiselect from echo and only limit echo notifications

User Restrain

Some Text Explaining the what this is (i.e. it mutes notifications from specific users).

Users: [ (Username multiselect field to add to the list) ]

2nd (optional) Iteration would list out the users with multiple options. Mute would always be selected so the user understands that the user is muted, but would be given the option to block or unblock a user. This is where we would do the work to actually prevent users from doing certain actions.

User Restrain

Some Text Explaining the what this is (i.e. it mutes users and allows you to block them).

Add: (Username outcomplete field to add to the list)

3rd (optional) Iteration would make the options more granular.

User Restrain

Some Text Explaining the what this is (i.e. it mutes users and allows you to block them).

Add: (Username outcomplete field to add to the list)

What do you think?

Regardless, since we know that the "list" will be used for both muting and blocking, it doesn't make sense for this to be in the Echo extension.

@kaldari Should this be in a new extension or in core? (I'm thinking the former)

In T171624#3534343, @dbarratt wrote:

Regardless, since we know that the "list" will be used for both muting and blocking, it doesn't make sense for this to be in the Echo extension.

What does "blocking" mean here?

In T171624#3534377, @Niharika wrote:

In T171624#3534343, @dbarratt wrote:

Regardless, since we know that the "list" will be used for both muting and blocking, it doesn't make sense for this to be in the Echo extension.

What does "blocking" mean here?

See T171624#3534010 :)

Block: User cannot perform certain actions.

The way "Blocking" is usually defined in context of our wikis is to ban someone from say editing, emailing other users etc. Blocks are not currently applicable by general users for specific actions applicable to them. For example you cannot block User:X from writing to your user talk page. Only admins can block accounts.

If you're planning to undertake this, I think it's a significant expansion of the original scope of the Mute feature.

I'd suggest this feature be restricted to only the Echo notifications and the emails that Echo sends out. I also don't see a reason to have multiple lists for the two.

In T171624#3534383, @Niharika wrote:

Block: User cannot perform certain actions.

The way "Blocking" is usually defined in context of our wikis is to ban someone from say editing, emailing other users etc. Blocks are not currently applicable by general users for specific actions applicable to them. For example you cannot block User:X from writing to your user talk page. Only admins can block accounts.

If you're planning to undertake this, I think it's a significant expansion of the original scope of the Mute feature.

I'd suggest this feature be restricted to only the Echo notifications and the emails that Echo sends out. I also don't see a reason to have multiple lists for the two.

I know. But I'm taking into consideration the future roadmap, which is not only to allow users to mute other users, but to block other users as well (of course it would only block them from interactions with that user).

We may never implement user-to-user blocking (whatever we want to call it), but it's certainly a possibility.

This gives us three choices:

1. Put the mute list in the echo extension and move it out later if necessary (based on the roadmap, within this quarter)
2. Put the mute/block list in a new extension that will be used by Echo (or anything else for that matter) and that extension will change core actions through hooks (as necessary).
3. Put the mute/block list in core

If per-user-per-page blocking is on your roadmap, then you probably want to build a new extension for it. If it's not, then the functionality is best left inside Echo. So I'd go with...

1. Put the mute list in the echo extension and move it out later if necessary (based on the roadmap, within this quarter)

In T171624#3534398, @Niharika wrote:

If per-user-per-page blocking is on your roadmap

Well it's per-user-per-action.

So what is coming up is T138166: Allow users to restrict who can send them direct emails via Special:EmailUser which would allow users to block specific users from sending them notifications (through core's email feature).

@Niharika — The Mute feature for Q1 2017-2018 will include all Echo on-site and email notifications, as well as direct emails from Special:EmailUser. In the future we may add other actions, but nothing has been decided or prioritized: https://meta.wikimedia.org/wiki/Community_health_initiative/User_Mute_feature#Potential_future_elements_to_Mute

IMHO two lists would be overkill. Instead, I think it's important here to distinguish the different types of notifications (SendEmail included) considering how they behave if they're disabled completely, for instance Mentions, Thanks etc, would be muted, while emails would be blocked.

However, isn't this whole discussion completely out of scope for this task??

In T171624#3534515, @MGChecker wrote:

IMHO two lists would be overkill. Instead, I think it's important here to distinguish the different types of notifications (SendEmail included) considering how they behave if they're disabled completely, for instance Mentions, Thanks etc, would be muted, while emails would be blocked.

However, isn't this whole discussion completely out of scope for this task??

The topic is not out of scope, but the granularity certainly is. :) Yesterday we realized that if Mute were just to be for Echo then a user preference may suffice. But because Mute will also cover Special:EmailUser it needs to be outside of Special:Preferences.

In T171624#3534515, @MGChecker wrote:

However, isn't this whole discussion completely out of scope for this task??

I agree that user's shouldn't have to manage more than one list of users they don't want to hear from. Do you have any feedback on T171624#3534281?

Yes it is out of scope, but since we know that we're planning on blocking actions outside of Echo (i.e. Special:EmailUser) soon, then I think it's important to figure out if we want to have a single list that covers multiple use cases or just let each extension have it's own list (which I think is a lot for a user to manage).

In T171624#3534398, @Niharika wrote:

If per-user-per-page blocking is on your roadmap, then you probably want to build a new extension for it. If it's not, then the functionality is best left inside Echo. So I'd go with...

1. Put the mute list in the echo extension and move it out later if necessary (based on the roadmap, within this quarter)

Seems a little bit connected to T2674.

The problem is how fine to set the granularity of mute/block possibilties. While I think, in most cases a user would be completely happy to just press a button "Don't show any notifications, block all E-Mails" there are other situations where some finer granularity can be useful, for example if I'm annoyed by the flood of thanks a specific user is sending to me all the time – while I still want to get mentions from him.

Your approach is a compromise between these extremes, but personally I'm unsure if it's even useful to differentiate between email and notification (while I really would make a single talk page checkbox as this would be a whole new level – and to be honest, I'm not even sure if this is a goof idea (in my experience, the problematic users are those who have and informal list of people who shouldn't edit their talk pages)) because why would I want emails from someone who spams with mentions (or vice versa, which wouldn't be supoorted by your concept)? Is this really a good distinction to make? Of course it's appealing because of the internal software design, but is this really that important?

@dbarratt, @TBolliger: Please do not involve blocking in this feature (as proposed at T171624#3534281). Blocking is a huge can of worms and if we try to incorporate blocking (especially non-admin blocking), I'm afraid it will derail the entire muting project. Can we take blocking off the table here and just concentrate on muting?

Yes it is out of scope, but since we know that we're planning on blocking actions outside of Echo (i.e. Special:EmailUser) soon, then I think it's important to figure out if we want to have a single list that covers multiple use cases or just let each extension have it's own list (which I think is a lot for a user to manage).

Blocking (in any form: email, per-page, etc) will almost certainly operate through a different UI as blocking is the purview of administrators. The muting feature, however, is intended for regular users.

In T171624#3534664, @kaldari wrote:

@dbarratt, @TBolliger: Please do not involve blocking in this feature (as proposed at T171624#3534281). Blocking is a huge can of worms and if we try to incorporate blocking (especially non-admin blocking), I'm afraid it will derail the entire muting project. Can we take blocking off the table here and just concentrate on muting?

Absolutely! That means this will be part of Echo for now. :)

In T171624#3534667, @kaldari wrote:

blocking is the purview of administrators.

uhh... so that conflicts with this:

In T171624#3534440, @TBolliger wrote:

direct emails from Special:EmailUser

@kaldari I assume we will allow User Apples to block User Bananas from sending email to User Apples (User Bananas could still send emails to all other users)? Unless you're thinking that we'll just block User Apples receiving the email? But if we do that, what's the point of letting User Bananas write the email at all? Regardless, Special:EmailUser is a part of core (afaik) so it should not depend on something in Echo correct?

Maybe I'm confusing everyone, but in my mind:

• Muting does not stop User Bananas from doing anything, just stops User Apples from receiving notifications (email or web) from User Bananas.
• Blocking on the other hand, allows User Apples to prevent User Bananas from performing some action against User Apples (i.e. send an email to User Apples with Special:EmailUser, write on User Apple's talk page, etc.).

And I admit, "Blocking" is a bad word since it's used for Admins already, but "Muting" is not appropriate in this context either (imho).

@dbarratt: Hmm, I see what you mean. In the blocking interface, the UI verbiage for disabling email is: "Prevent user from sending email". Maybe we could use similar verbiage:

Mute notifications from these users:
[                                  ]

Prevent these users from sending me email:
[                                  ]

Prevent these users from editing my talk page:
[                                  ]

Personally, I prefer a more verbose UI for this (rather than a matrix). The above interface should also be easier to implement with the current UI components, and would likely be easier to adapt to a small screen for mobile use, but I'm not a Product Manager :)

In T171624#3534782, @kaldari wrote:

Personally, I prefer a more verbose UI for this (rather than a matrix).

That's basically what Facebook does:
https://www.facebook.com/settings?tab=blocking

But I feel that it would be really difficult if users have muted/prevented a large number of users and they are trying to find what list they are on or not on (without relying on the browser's "Find on Page").

Although, you are right, it could become a problem on smaller screens if there was a lot of granularity (other than some sort of horizontal scroll). If the granularity is kept small it could be alright though (i.e. just "mute" and "prevent").

We also talked about for now just having a single list and then we can decide later if we even need more than one list (we could just assume that everyone who is muted is also prevented).

Regardless, should this be a Special Page I assume? Where should I put it (new extension or core)?

Regardless, should this be a Special Page I assume? Where should I put it (new extension or core)?

It should either be a Special Page or a set of preferences. For me that decision hinges on whether we want to always make these settings global or not. If they are always global, that is a significant departure from how preferences normally work and I think we should put them on a separate special page. If they are not intended to always be global, I would favor including them in the regular preferences, personally. So I guess we'll have to see what comes out of the community consultation. As far as extension vs. core, I imagine this would at least partially be built in core either way. The specific notification muting feature would probably live in Echo, but work through a core hook (either in preferences or a new core special page).

@kaldari Fantastic! Yeah per T171624#3532227 this will always be global (which I agree with) so new core special page it is!

New core special page? If it's always global, it relies on an external database. It can't be in core.

In T171624#3534664, @kaldari wrote:

@dbarratt, @TBolliger: Please do not involve blocking in this feature (as proposed at T171624#3534281). Blocking is a huge can of worms and if we try to incorporate blocking (especially non-admin blocking), I'm afraid it will derail the entire muting project. Can we take blocking off the table here and just concentrate on muting?

To reduce confusion, I propose we use another word than block for an other-user-is-aware-mute, for example reject.

In T171624#3534667, @kaldari wrote:

Yes it is out of scope, but since we know that we're planning on blocking actions outside of Echo (i.e. Special:EmailUser) soon, then I think it's important to figure out if we want to have a single list that covers multiple use cases or just let each extension have it's own list (which I think is a lot for a user to manage).

Blocking (in any form: email, per-page, etc) will almost certainly operate through a different UI as blocking is the purview of administrators. The muting feature, however, is intended for regular users.

I don't think you can do this project without at least email blocking per user (/per group, T138165). This is one of the key features people want to have. User-per-page blocking is another thing indeed.

In T171624#3534797, @kaldari wrote:

Regardless, should this be a Special Page I assume? Where should I put it (new extension or core)?

It should either be a Special Page or a set of preferences. For me that decision hinges on whether we want to always make these settings global or not. If they are always global, that is a significant departure from how preferences normally work and I think we should put them on a separate special page. If they are not intended to always be global, I would favor including them in the regular preferences, personally. So I guess we'll have to see what comes out of the community consultation. As far as extension vs. core, I imagine this would at least partially be built in core either way. The specific notification muting feature would probably live in Echo, but work through a core hook (either in preferences or a new core special page).

I think we should add this to perferences, everything else would be more confusing than helpful in my opinion. While it would be a big change of the way that preferences work by now, this would resolve itself with the introduction of MediaWiki-extensions-GlobalPreferences hopefully soon.

In T171624#3534886, @Niharika wrote:

New core special page? If it's always global, it relies on an external database. It can't be in core.

I think no matter you implement this, it would have to work with and without CentralAuth, as Echo isn't Wikimedia only. I think a feature to block specific users in email can be in core, personally I don't see the benefits of using extensions that much, because often they implement features everyone wants (ParserFunctions, Notifications, Nuke, TitleBlacklist) or are nice to have for everyone, like this. But maybe the reason I think so is a lack of MediaWiki coding experience…

That this feature is global would have to be implemented by some cooperation between CentralAuth and Core in my opinion, if you add the mute/reject list into core for the sake of EmailUser

In T171624#3534886, @Niharika wrote:

New core special page? If it's always global, it relies on an external database. It can't be in core.

Just to clarify, this isn't strictly true. See how BotPasswords implements a global table for example, but still in core. As long as it defaults to a single-wiki setup and is configurable to be shared, it should be fine to include in core.

In T171624#3535437, @Legoktm wrote:

In T171624#3534886, @Niharika wrote:

New core special page? If it's always global, it relies on an external database. It can't be in core.

Just to clarify, this isn't strictly true. See how BotPasswords implements a global table for example, but still in core. As long as it defaults to a single-wiki setup and is configurable to be shared, it should be fine to include in core.

Fantastic! So we'll stick to a new core Special Page (and see how that goes!).

In T171624#3535041, @MGChecker wrote:

To reduce confusion, I propose we use another word than block for an other-user-is-aware-mute, for example reject.

@kaldari proposed the word "prevent" which works for me. Since this is a list I was thinking a "User Restrain List"? I don't think "User Prevent List" makes sense and "User Reject List" sounds too much like Mean Girls. But I'm open to suggestions.

I don't think you can do this project without at least email blocking per user (/per group, T138165). This is one of the key features people want to have. User-per-page blocking is another thing indeed.

Yes. Here is an overview T164542. This is why I'm talking about not having the prevent list be in echo (since it also covers direct emails in T138166

I think we should add this to perferences, everything else would be more confusing than helpful in my opinion. While it would be a big change of the way that preferences work by now, this would resolve itself with the introduction of MediaWiki-extensions-GlobalPreferences hopefully soon.

It's actually already a preference T150419. But in T171624#3532227 we decided to make it outside of preferences since it will always be global.

I think no matter you implement this, it would have to work with and without CentralAuth, as Echo isn't Wikimedia only. I think a feature to block specific users in email can be in core, personally I don't see the benefits of using extensions that much, because often they implement features everyone wants (ParserFunctions, Notifications, Nuke, TitleBlacklist) or are nice to have for everyone, like this. But maybe the reason I think so is a lack of MediaWiki coding experience…

That this feature is global would have to be implemented by some cooperation between CentralAuth and Core in my opinion, if you add the mute/reject list into core for the sake of EmailUser

Yes, it will use the central auth id (if it's enabled) or the local user id (if central auth is not enabled).

In T171624#3538394, @dbarratt wrote:

In T171624#3535437, @Legoktm wrote:

In T171624#3534886, @Niharika wrote:

New core special page? If it's always global, it relies on an external database. It can't be in core.

Just to clarify, this isn't strictly true. See how BotPasswords implements a global table for example, but still in core. As long as it defaults to a single-wiki setup and is configurable to be shared, it should be fine to include in core.

Fantastic! So we'll stick to a new core Special Page (and see how that goes!).

So technically, this task is indeed more CentralAuth than Notifications related by now.

In T171624#3535041, @MGChecker wrote:

To reduce confusion, I propose we use another word than block for an other-user-is-aware-mute, for example reject.

@kaldari proposed the word "prevent" which works for me. Since this is a list I was thinking a "User Restrain List"? I don't think "User Prevent List" makes sense and "User Reject List" sounds too much like Mean Girls. But I'm open to suggestions.

I'm fine with prevent.

I think we should add this to perferences, everything else would be more confusing than helpful in my opinion. While it would be a big change of the way that preferences work by now, this would resolve itself with the introduction of MediaWiki-extensions-GlobalPreferences hopefully soon.

It's actually already a preference T150419. But in T171624#3532227 we decided to make it outside of preferences since it will always be global.

I don't think this is a good idea, because there's a risk that the number of user setting related special pages grows exponentially once we start like this, resulting in a giant mess. Instead I think we should wide the functionality of GlobalPreferences by making it possible to lock the "Use this setting globally" flag to be set always, just as we make it mandatory to get an Echo notification for user talk messages now.

I don't think this is a good idea, because there's a risk that the number of user setting related special pages grows exponentially once we start like this, resulting in a giant mess.

Can you elaborate on that, @MGChecker?

Thank you, David. Good work. T167902: Build a unified, cross-wiki Mute feature for multiple types of on-wiki and email communication contains a link to your write-up.

For now, we will keep Echo Mute as local only. We'll generate a report of how many user are active on multiple wikis so we can have a better understanding of how important globalizing this feature will be in the future. And when CommTech completes T16950: [Epic] Support global preferences on Wikimedia wikis we will have some level of cross-wiki functionality.

For Q1, our AHT team will attempt to complete:

• T173475: Echo Notification Mute (Block List) can be bypassed by changing username
• T173838: Enable EchoPerUserBlacklist on all Wikimedia wikis with Echo enabled
• Any other urgent Echo Mute bugs that arise
• T138166: Allow users to restrict who can send them direct emails via Special:EmailUser
• T138165: Allow users to restrict which user groups that can send them direct emails via Special:EmailUser

In T171624#3539279, @Niharika wrote:

I don't think this is a good idea, because there's a risk that the number of user setting related special pages grows exponentially once we start like this, resulting in a giant mess.

Can you elaborate on that, @MGChecker?

I fear that a pattern might arise for extensions to manage their settings on a "better" special page than Preferences, if we once start to do it that way in some rare cases. And does anyone want to manage his preferences at ten distinct pages? Even now I think it's highly contrainutitive to have all settings about the wiki at one place Except this one.

In T171624#3541682, @TBolliger wrote:

For now, we will keep Echo Mute as local only. We'll generate a report of how many user are active on multiple wikis so we can have a better understanding of how important globalizing this feature will be in the future. And when CommTech completes T16950: [Epic] Support global preferences on Wikimedia wikis we will have some level of cross-wiki functionality.

I don't think this is that important for that feature. Not the wikis where I am active are important, but the ones the harasser can use. An EmailUser blacklist is quite useless if the harasser can go to one of the other 700 wmf wikis and send emails from there.

In T171624#3542270, @MGChecker wrote:

I don't think this is that important for that feature. Not the wikis where I am active are important, but the ones the harasser can use. An EmailUser blacklist is quite useless if the harasser can go to one of the other 700 wmf wikis and send emails from there.

I agree, which is why we need to explore T169934: Reconsider how users can be contacted (email, talk page, notifications) on wikis where they have never edited but have logged-in.