Change 354695 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Improve UI for blacklist preference

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

This is now ready, except that @Mattflaschen-WMF points out there's something that's not implemented yet or not quite right yet around exempting user talk pages.

In T150419#3395600, @Catrope wrote:

This is now ready, except that @Mattflaschen-WMF points out there's something that's not implemented yet or not quite right yet around exempting user talk pages.

Sorry, I was wrong.

It should be fine after rECHO813ab5b54e4b: Fix user talk exception for blacklist.

The following notification will not be received if they are initiated by a user who was blocked:

The following notifications will be received even if they were initiated by a blocked user:

QA Recommendation: Resolve

@TBolliger Per the above, Elena thinks this is ready to go. If you agree, the earliest this could be turned on on a production wiki is after our latest fixes for it have rolled out, which will be on July 12th or 13th depending on the wiki (normally it'd be a week earlier, but next week's deployment will be skipped because of the 4th of July holiday). Let us know what you want to do and when. The code is already on the beta labs wikis for testing, if you want to take a look.

Thanks, @Catrope and @Etonkovidova !

Can we enable this on meta on the 12th/13th? There are a few minor sub-tasks I'd like to have @dbarratt investigate before a wider release.

@Catrope, @TBolliger - the functionality is working fine, however, there are still outstanding issues: T169384: Blacklist UsersMultiselectWidget UI needs improvements and T166626: Update message copy for Mute feature.

@TBolliger Just a question: Restricting notifications from anon users - has it ever been discussed?

Change 363049 had a related patch set uploaded (by Catrope; owner: Catrope):
[operations/mediawiki-config@master] Enable Echo per-user blacklist on meta

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

In T150419#3401314, @TBolliger wrote:

Thanks, @Catrope and @Etonkovidova !

Can we enable this on meta on the 12th/13th? There are a few minor sub-tasks I'd like to have @dbarratt investigate before a wider release.

I have created a config patch for this (see above) and scheduled it for deployment during the evening SWAT on Wednesday (at 23:00 UTC / 4pm PDT).

In T150419#3402273, @Etonkovidova wrote:

@TBolliger Just a question: Restricting notifications from anon users - has it ever be discussed?

@Etonkovidova — Great idea! and yes. This would fall under a different project we're considering (no Phab ticket yet): https://meta.wikimedia.org/wiki/Community_health_initiative/User_and_User_talk_page_protection_tools

It would essentially allow users to wall off entire groups of users, as opposed to a blacklist.

This idea is still brewing. How our users react to this blacklist will certainly inform our decisions.

In T150419#3402331, @Catrope wrote:

In T150419#3401314, @TBolliger wrote:

Thanks, @Catrope and @Etonkovidova !

Can we enable this on meta on the 12th/13th? There are a few minor sub-tasks I'd like to have @dbarratt investigate before a wider release.

I have created a config patch for this (see above) and scheduled it for deployment during the evening SWAT on Wednesday (at 23:00 UTC / 4pm PDT).

Please document first! T169606: Document how to restrict notifications received

I've checked on Meta and I haven't seen anything there. Normal?

Roan and I agreed to pull it from Wednesday's release.

Sorry for not communicating that earlier. Some annoying bugs in the feature were fixed this week, and we probably want to wait for the next train to roll out next week with those fixes before we enable this on a real wiki.

In T150419#3436307, @Catrope wrote:

Sorry for not communicating that earlier. Some annoying bugs in the feature were fixed this week, and we probably want to wait for the next train to roll out next week with those fixes before we enable this on a real wiki.

We are next week. What's new?

@Catrope — I just tested the UI and the mute functionality on beta, looks good to me. I say we release it on Meta with the next release.

In T150419#3457353, @TBolliger wrote:

@Catrope — I just tested the UI and the mute functionality on beta, looks good to me. I say we release it on Meta with the next release.

Alright, scheduled for Wednesday at 4pm Pacific.

Announced in Tech/News and the Collaboration team newsletter.

Change 363049 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable Echo per-user blacklist on meta

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

Mentioned in SAL (#wikimedia-operations) [2017-07-26T23:30:14Z] <thcipriani@tin> Synchronized wmf-config/InitialiseSettings.php: SWAT: [[gerrit:363049|Enable Echo per-user blacklist on meta]] T150419 (duration: 00m 49s)

Feature is now live on Meta.

I don't know if you're aware of that, but I could see the title of T173475 and the title and initial description of T173854 in my email. (Note I'm a watcher of Anti-Harassment-Team.) This shouldn't happen if they were created properly, which I can't check. (Besides, the first one is so obvious, I wouldn't hide it at all, while I remember reading about the second one in public areas of WMF infrastructures.)

In T150419#3542351, @MGChecker wrote:

I don't know if you're aware of that, but I could see the title of T173475 and the title and initial description of T173854 in my email. (Note I'm a watcher of Anti-Harassment-Team.) This shouldn't happen if they were created properly, which I can't check. (Besides, the first one is so obvious, I wouldn't hide it at all, while I remember reading about the second one in public areas of WMF infrastructures.)

I created {T173854} as a sub-task of a security issue. It's baffling that it doesn't automatically (or at minimum provide the option during creation) mark subtasks of security issues as security issues.

But now I've learned and will avoid it in the future.

In T150419#3542516, @TBolliger wrote:

I created {T173854} as a sub-task of a security issue. It's baffling that it doesn't automatically (or at minimum provide the option during creation) mark subtasks of security issues as security issues.

Can you file the "subtasks of security not created as security" problem as a Phabricator issue (our tracker, tagged Phabricator) if you didn't already?

In T150419#3581774, @Mattflaschen-WMF wrote:

In T150419#3542516, @TBolliger wrote:

I created {T173854} as a sub-task of a security issue. It's baffling that it doesn't automatically (or at minimum provide the option during creation) mark subtasks of security issues as security issues.

Can you file the "subtasks of security not created as security" problem as a Phabricator issue (our tracker, tagged Phabricator) if you didn't already?

Done: T175072: Creating a sub-task of a security issue (via "Edit related tasks" menu) does not automatically protect the task as Security