Change 883276 had a related patch set uploaded (by Samtar; author: Samtar):

[mediawiki/extensions/AbuseFilter@master] [WIP] AbuseFilterPermissionManager: Add oversight-only abuse filters

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

Change #883276 abandoned by Samtar:

[mediawiki/extensions/AbuseFilter@master] [WIP] AbuseFilterPermissionManager: Add oversight-only abuse filters

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

Change #1115319 had a related patch set uploaded (by Kosta Harlan; author: MolecularPilot):

[mediawiki/extensions/AbuseFilter@master] Support oversighter-only auto-suppressing AbuseFilters

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

@kostajh I just re-wrote this using the task template, but totally understand how busy everyone is with temporary accounts so no-rush re code review! :)

In T290324#10533367, @MolecularPilot wrote:

@kostajh I just re-wrote this using the task template, but totally understand how busy everyone is with temporary accounts so no-rush re code review! :)

Thanks for doing that!

@kostajh , Hello, has Trust and Safety completed this?

In T290324#10747052, @ARamadan-WMF wrote:

@kostajh , Hello, has Trust and Safety completed this?

L3SC approval is documented here. I'd like for Trust and Safety Product Team to take a look at this, because we recently reworked a bunch of code to support T354599: [EPIC] WE4.2.14b Provide IP reputation variables in AbuseFilter and we may have some learnings there that apply to this patch. I'm tentatively placing it in our next sprint for our team to provide code review.

@MolecularPilot Thank you for your work on this and sorry about the delay on our end. I've reviewed the task requirements and it looks good to me. My only question is whether this has gone through any community approvals process? Looking at the number of subscribers on this task it seems like this is a popular idea. If there is a community discussion about it that you can link to, that would be helpful.

I tried to pull the patch into a patch demo to review the feature but that failed presumably because the patch needs rebasing. Happy to look that over once the patch is updated.

@kostajh We can proceed with the engineering review.

Hi @Niharika. As a former fr-wp OS, and current AF: I don't think there are public community discussion on fr-wp, but we wanted to get such Oversight-level abuse filters because we have on fr-wp a (private) anti-harassment abuse filter (148) using real names of editors, especially functionnaries. Which is not optimal for privacy.

I can tell you this has gone through the en OS mailing list as a very popular idea. Crucially this also came out of the Wishlist process which, as I understand it, is supposed to be its own form of community discussion.

+User-notice: IMO this feature is worth a Tech/News announcement if/when it's implemented; feel free to remove the tag if you disagree :)

For Tech News (once this is ready to announce): Drafts/suggested wording would be welcome! (I always appreciate help understanding what exactly needs to be communicated).
Any estimates of the timing of the entry are also always welcome (for when I/other editors are skimming the workboard for recently-active tasks, each week). Cheers.

Test wiki created on Patch demo by MolecularPilot using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/c6c26351dc/w/

Change rebased ontop of protected variable changes (latest master) and ready for code review!

All tests are passing and you can see the patch demo of it working through the above link (login info specified on the main page).

For Tech News, I was thinking something like:

• Edit filters can now be suppressed to automatically restrict details and logs to oversighters only.

but the question does arise do we use enwiki/Wikimedia specific terms ("edit filter", "oversighter") or general MediaWiki terms ("abuse filter, "suppressor")?

The global terms should be preferred for i18n purposes. That said, I'd rewrite the note as "Edit filters can now be set to suppress attempted edits and actions [automatically]." which avoids part of the issue. (And I think edit filter is the wider known terminology these days too, but I could be wrong.) Link suppress to the relevant MW wiki documentation page or Wikidata item, and add a separate "see filters documentation about this feature" sentence after, wherever that lives.

How about "Certain edit filters can now be set to suppress their list of attempted edits and actions. The idea is to restrict information in edit filters related to doxing."

I've added four related wishlist links to the task's Description. I believe that, plus @Niharika's comment above, satisfies the Acceptance criteria for "Approval from Trust & Safety Product", but I'll leave checking-that-checkbox to someone else.

Re: terminology: I see the 4 wishlist pages all use "abuse filter". But I'm aware that that name isn't ideal for a few reasons (incl. inaccurate for some filters, and not universally used by editors). In the Tech News entry, I suggest using "edit filters", but I will also add a note in the "translation guidance" (qqq) telling the translators to use either term, as appropriate for their linguistic community.

Re: Acceptance criteria of "Documentation on mediawiki.org updated to reflect new suppression functionality." -- Is this part done, or planned to be done by someone? It would be ideal to have the updated content both ready for translation, and linked-to within the Tech News entry.

Re: draft of an entry: I'd suggest (but further edits/suggestions are very welcome!):

• Edit filters [[LINK TO NEW DOCS| can now be set]] to suppress their list of attempted edits and actions. This will help oversighters if they are using any edit filters to prevent doxxing.

@Jules78120 @Barkeep49 Noted, thank you. In that case this is all good on my end. The other remaining thing is for our team to do a code review. It's in our current sprint and should be looked at by someone hopefully soon.
@Quiddity let's leave the Approval for TSP checkbox open for whoever does the code review. They can sign off on it.

There was a minor merge conflict in the patch caused by a change merged to main in the last few days, I’ve reconciled this, so it’s ready for code review now, but absolutely no rush for that! :)

Removing our sprint tag as we provided code review but are now waiting for the patch to be updated for the new merge conflicts and the comments I left a few weeks ago.

We would want to take another look at this for code review once the patch has been updated.

Hi! Thank you very much for the patch review,. I’ve addressed all concerns, but due to a problem with WiFi (I am writing this on my phone) I’m currently unable to submit the new patch. I should be able to by next weekend when it is repaired. Thanks again! :)

In T290324#11037917, @MolecularPilot wrote:

Hi! Thank you very much for the patch review,. I’ve addressed all concerns, but due to a problem with WiFi (I am writing this on my phone) I’m currently unable to submit the new patch. I should be able to by next weekend when it is repaired. Thanks again! :)

Thanks for the update! Hope you can get the WiFi sorted soon and there are no other unexpected problems. If you could ping me when that's done, I can take another look at the patch.

My apologies, this slipped my mind once my WiFi was restored. I’ll resolve the merge conflicts and reviewer comments within a few days and submit an updated patch. :)

@Dreamy_Jazz I've addressed the merge conflicts and all of your feedback in the latest patchset - Patchset 12 - and it's ready for your review when ready. Thank you again for your detailed feedback!

Is this ready for Tech News?

It needs to be reviewed and merged first.

@STei-WMF Please look at the "Details" box to see patch statuses, and at the project tags which may include Patch-For-Review.