Page MenuHomePhabricator

Devise a strategy for optimal utilization of abusefilter-maintainers group
Closed, ResolvedPublic

Description

Now that the "abuse filter maintainer" (AFM) group has been created on WMF wikis, we should devise a strategy on how best to utilize this group.

Ideals (and questions about them)
  • Every time a change in AbuseFilter code results in functionality change without backward compliance, we should try to identify affected wikis
    • Should we use DB queries?
    • Should we use on-wiki search?
  • Every time we find filters that must be edited to match the new AbuseFilter code, AFM should start by letting the sysops of that wiki know, in case they would want to fix it themselves
    • What venue do we post this in? Should we curate a list of pages in each wiki in which such notice should be posted?
    • What format do we use for communication? Do we just say something like "this function needs a third parameter in all of its use cases" or do we specifically say "update filter #14 and change foo to bar"?
    • What do we communicate about private filters? Do we even mention them on-wiki? Do we ask for a sysop to email the AFM for more details?
  • If an AFM ends up editing a filter on some wiki, s/he should clearly state the purpose of the edit, so that there are no future surprises to local sysops
    • Should we require a mention of the Phabricator ticket or Gerrit patchset ID in the filter comments?
    • Should we ask each request for AFM edits to have its own Phab ticket? Should they be tagged with Wikimedia-Site-requests or not?
    • Should we create a tracker task (or a Phabricator tag) to mark all such tickets?
  • We should have a mechanism to keep track of how (and how often) AFM right is being used.

Event Timeline

Aklapper renamed this task from Devise a strategy for optimal utilization of abuse filter maintainers to Devise a strategy for optimal utilization of abusefilter-maintainers group.Apr 26 2020, 9:35 AM

T251071 is an example of a recent case where a DB query and a follow-up AFM action might be necessary. I only stumbled upon it by happenstance. This is why we need a tracker or Phab tag.

T251071 is an example of a recent case where a DB query and a follow-up AFM action might be necessary. I only stumbled upon it by happenstance. This is why we need a tracker or Phab tag.

Do you want a phabricator component created? Something like #wikimedia-abusefilter-maintainers with columns for not ready yet, ready to be fixed, etc?

Quick answers and other things that come to mind:

  • Every time a change in AbuseFilter code results in functionality change without backward compliance, we should try to identify affected wikis
    • Should we use DB queries?
    • Should we use on-wiki search?

I think using a DB query is the only way, currently. On-wiki search is very useful to refine results on single wikis, though.

  • Every time we find filters that must be edited to match the new AbuseFilter code, AFM should start by letting the sysops of that wiki know, in case they would want to fix it themselves
    • What venue do we post this in? Should we curate a list of pages in each wiki in which such notice should be posted?

It wouldn't be bad to have a WikiData item of pages like enwikis' Edit Filter Noticeboard. I don't know whether it's feasible though. Either way, the fallback should be the (technical) village pump (for which I think a WD item already exists?)

  • What format do we use for communication? Do we just say something like "this function needs a third parameter in all of its use cases" or do we specifically say "update filter #14 and chnage foo to bar"?
  • What do we communicate about private filters? Do we even mention them on-wiki? Do we ask for a sysop to email the AFM for more details?

I think this depends on the specific filter. If it's a public filter, I'd say just write down what should be done and why. Otherwise, it depends... If the technical fix doesn't give away the content of the filter, & if the filter isn't already broken, perhaps a complete explanation is fine. Otherwise, asking for private contact with an AbuseFilter editor would be better.

  • If an AFM ends up editing a filter on some wiki, s/he should clearly state the purpose of the edit, so that there are no future surprises to local sysops
    • Should we require a mention of the Phabricator ticket or Gerrit patchset ID in the filter comments?

Probably a good idea.

  • Should we ask each request for AFM edits to have its own Phab ticket? Should they be tagged with Wikimedia-Site-requests or not?

Another good idea. But I'd say it doesn't need the Wikimedia-Site-requests tag.

  • Should we create a tracker task (or a Phabricator tag) to mark all such tickets?

I'd say yes, see below.

  • We should have a mechanism to keep track of how (and how often) AFM right is being used.

I think this could be (easily?) doable if someone writes a bot ad hoc.

T251071 is an example of a recent case where a DB query and a follow-up AFM action might be necessary. I only stumbled upon it by happenstance. This is why we need a tracker or Phab tag.

Do you want a phabricator component created? Something like #wikimedia-abusefilter-maintainers with columns for not ready yet, ready to be fixed, etc?

I think this is a good idea now. I had previously created a column in the AbuseFilter workboard ("Requiring manual fix of filters in production"), but a workboard would allow for fine-grained tracking of what needs to be done.

Quick answers and other things that come to mind:

  • Every time a change in AbuseFilter code results in functionality change without backward compliance, we should try to identify affected wikis
    • Should we use DB queries?
    • Should we use on-wiki search?

I think using a DB query is the only way, currently. On-wiki search is very useful to refine results on single wikis, though.

On-wiki might actually work; I have a script somewhere that can search for all filters using deprecated variables by matching the filter content to a regular expression, and it should be possible to adapt that to search for other stuff and to do it for all wikis

  • Every time we find filters that must be edited to match the new AbuseFilter code, AFM should start by letting the sysops of that wiki know, in case they would want to fix it themselves
    • What venue do we post this in? Should we curate a list of pages in each wiki in which such notice should be posted?

It wouldn't be bad to have a WikiData item of pages like enwikis' Edit Filter Noticeboard. I don't know whether it's feasible though. Either way, the fallback should be the (technical) village pump (for which I think a WD item already exists?)

Perhaps a dedicated global mass message list for the noticeboards to send updates to?

  • What format do we use for communication? Do we just say something like "this function needs a third parameter in all of its use cases" or do we specifically say "update filter #14 and chnage foo to bar"?
  • What do we communicate about private filters? Do we even mention them on-wiki? Do we ask for a sysop to email the AFM for more details?

I think this depends on the specific filter. If it's a public filter, I'd say just write down what should be done and why. Otherwise, it depends... If the technical fix doesn't give away the content of the filter, & if the filter isn't already broken, perhaps a complete explanation is fine. Otherwise, asking for private contact with an AbuseFilter editor would be better.

  • If an AFM ends up editing a filter on some wiki, s/he should clearly state the purpose of the edit, so that there are no future surprises to local sysops
    • Should we require a mention of the Phabricator ticket or Gerrit patchset ID in the filter comments?

Probably a good idea.

  • Should we ask each request for AFM edits to have its own Phab ticket? Should they be tagged with Wikimedia-Site-requests or not?

Another good idea. But I'd say it doesn't need the Wikimedia-Site-requests tag.

  • Should we create a tracker task (or a Phabricator tag) to mark all such tickets?

I'd say yes, see below.

  • We should have a mechanism to keep track of how (and how often) AFM right is being used.

I think this could be (easily?) doable if someone writes a bot ad hoc.

T251071 is an example of a recent case where a DB query and a follow-up AFM action might be necessary. I only stumbled upon it by happenstance. This is why we need a tracker or Phab tag.

Do you want a phabricator component created? Something like #wikimedia-abusefilter-maintainers with columns for not ready yet, ready to be fixed, etc?

I think this is a good idea now. I had previously created a column in the AbuseFilter workboard ("Requiring manual fix of filters in production"), but a workboard would allow for fine-grained tracking of what needs to be done.

I can work on such a bot; I'm making the phab project now

On-wiki might actually work; I have a script somewhere that can search for all filters using deprecated variables by matching the filter content to a regular expression, and it should be possible to adapt that to search for other stuff and to do it for all wikis

That could do. I also forgot to mention that sometimes a good way to have a list of affected filters is to add some logging to the deprecated code.

I can work on such a bot; I'm making the phab project now

Thanks!

Urbanecm subscribed.

A purely site request point of view: I do not think tasks like this one should be marked with Wikimedia-Site-requests, the only exception would be when you require someone with production access to do something (run a query or a maint script), but I don't think that would happen normally.

taavi subscribed.

Does this task have anything actionable remaining or can it be closed?

Abusefilter Global Maintainers: What exactly / is there anything left to do in this task? Thanks in advance for clarifying.

No reply from anyone. Please feel free to reopen and clarify if there's something left to do here. Thanks.