Meta:Requests for comment/Create local meta abuse filter helper and abuse filter manager role

From Meta, a Wikimedia project coordination wiki
An editor has requested comments on the issue described below. Please feel free to share your thoughts.

Statement of the issue[edit]

Similar to Abuse filter helpers and Abuse filter maintainer. Per Requests for comment/Make global abuse filters opt-out, if local communities do not opt out we need to certainly grant the local admins read / write access on meta. I am very reluctant to grant RfLA on a very liberal basis which might inflate meta admin count to almost the most after enwp (imagine all the sysops on affected large / medium wikis wanting this access).

There are few practical considerations not to have too many limited admins.

  • With too many admins, it will make it very hard to monitor their activity to make sure are they within scope. We can try incubator test-wiki admin type but I don't think it is very practical.
  • Certain RDed diffs may contain attacks / libels but for a small admin pool on meta, we can safely RD without OSing. With more gaining access, we potentially might send it to OS too often which may overwhelm OS team.
  • Likewise for copyright issues, we can RD them also, with so large pool of admins, some rights owners might insist they be OSed.
  • A clog on RfLA page which can cause issues as most nominations will likely be just endorsed but with LA having more scope than TA, I don't think a TA like process will be safe given the sensitive access meta admins have.
  • There are certain admins on medium size wikis / large wikis that can be problematic elsewhere, we have PlaneSpotterA320 which is community banned but they are admin of uzwiki which is medium AFAICS. If we have a medium / large wiki automatic LA, I won't think what the implications this can be and the drama behind the requests.

I will then propose we have a local abusefilter helper (AFH) and local abusefilter manager (AFM) role. AFM AFH can be given on request to good standing to medium / large wikis admins and perm sysops for small wikis. This will be RFH. A crat (or admin?) can grant. AFM can be on RFH too with 3 days of discussions. Afterwhich crats can grant. Removal will be for crats to do. Other good standing users can be granted this on request.

Thoughts? Camouflaged Mirage (talk) 10:08, 24 March 2023 (UTC) Modified 14:52, 24 March 2023 (UTC) to just continue with AFH than both as early comments indicate the 1st is likely to garner more support than the 2nd. Camouflaged Mirage (talk) 14:52, 24 March 2023 (UTC)[reply]

Comments[edit]

  • Support Support local AFH/AFM roles for sysops from other wikis who want to check global filters, help with false positives or want to reduce redundancies between global and local filters seem useful. --Johannnes89 (talk) 10:31, 24 March 2023 (UTC)[reply]
  • Oppose Oppose I think there are enough local admins and stewards to handle global abuse filters without creating yet another maintenance burden of two more user groups to manage / take care of. I could support an abusefilter group à la enwiki so trusted users can manage abusefilters without the need to grant full admin access on meta, but I'm not sure the need exists, and certainly not for two user groups. Thanks, —MarcoAurelio (talk) 10:37, 24 March 2023 (UTC)[reply]
    Clarify that I'm opposing the proposal entirely, both before and after the change in scope. —MarcoAurelio (talk) 18:21, 25 March 2023 (UTC)[reply]
  • Support Support AFH, Oppose Oppose AFM. There is a decent argument made for making view-only access to private filters easier, as many global filters implact local projects. RFLA is fine for someone that really wants to help with global filter maintenance, I don't want a bunch of single-interest AFM's bloating up filters with things like "&NOT $mywiki". I disagree with the premise that local project admins need to be able to edit global filters. I agree we shouldn't be handing out lots of RFLA's either. Now what could be done - a better workflow for FP handling, change requests perhaps. — xaosflux Talk 12:18, 24 March 2023 (UTC)[reply]
    • Hi Xaosflux, as I mention in my own comment, while I do understand the need to see filters, I think that access can be safely provided with GAFH (considering Meta's helpers would be able to see log details on the majority of wikis already anyway, through the global filters hit). In other words, the level of trust needed for Meta's AFH or global AFH seems to be nearly equal. Not sure why a yet another group would help. But, your experience might vary! --Martin Urbanec (talk) 19:11, 24 March 2023 (UTC)[reply]
      @Martin Urbanec I've seen some headaches on local projects denying someone from "their" filters - and wouldn't want to the spill over to global requests with extra drama. GAFH is certainly an option, and would be the default fall back if this fails. A benefit for local AFH as written is that it would be an even more lightweight process, especially if divested to admin-discretion for granting. — xaosflux Talk 20:07, 24 March 2023 (UTC)[reply]
  • Support Support for a local Abuse filter helpers group. This is useful as most people only need the right to see logbook entries in in one e.g. frWiki. The global right in my opinion is wrong for local administrators who do not participate anywhere else, so I think it is a good idea. Oppose Oppose Editing abuse filters is the responsibility of the administrators. Abuse filter helpers are welcome to contact administrators if they would like to have a particular filter changed.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 14:36, 24 March 2023 (UTC)[reply]
    @Johannnes89@MarcoAurelio@WikiBayer@Xaosflux Thanks for commenting. I will be modifying the scope of this RFC to AFH only given the opposition to AFM. Camouflaged Mirage (talk) 14:53, 24 March 2023 (UTC)[reply]
  • Support Support Helper, Oppose Oppose Maintainer. - Local administrator must be able to see the global filter. However, global filters are global. Local administrator should not directly edit filters that act globally. Syunsyunminmin 🗨️talk 17:00, 24 March 2023 (UTC)[reply]
  • Oppose Oppose both flags. Global filters are special; ability to edit them affects (nearly) all wikis, viewing the filters/their logs gives insight into LTA behavior on (nearly) all wikis. This is very similar to members of the already existing global groups related to AFs (global abuse filter helpers/maintainers). Members of the global groups can also affect all wikis, as they're able to edit filters everywhere (or view details of LTA behavior everywhere respectively). If the community agrees it's best to separate access to all filters and global filters, it can be done, but I don't really understand the need for that level of separation. --Martin Urbanec (talk) 19:11, 24 March 2023 (UTC)[reply]
    Not strongly opposed to using GAFH (existing capability) option, we don't create a very high bar for it already. — xaosflux Talk 20:09, 24 March 2023 (UTC)[reply]
  • Support Support Helper. Giving local administrators the ability to see global filters is important. Abzeronow (talk) 20:20, 24 March 2023 (UTC)[reply]
  • Support Support. I think that trusted users should be able to handle the global abuse filters and that proper community vetting can be done to ensure that the individuals granted access are skilled and trustworthy. — Red-tailed hawk (nest) 01:05, 25 March 2023 (UTC)[reply]
  • Oppose Oppose a local AFH group, because the only thing that local AFH people can't see are private logs from other wikis. And I don't think that is strong enough to create a separate group, given that users in good standing who request AFH are usually given the right with little fuss. Were that not to be the case, I would have been more open to a local group. Most of the "private" stuff - rising to oversight-worthy material - are hit in global filters, not local, so it's not quite the case that local AFH users need less "trust" either. On the other hand, I would actually be open to creating a local abuse filter maintainer group. The reason is that AFM is restrictive in that using it for routine vandalism is frowned upon, so in that case we have a need for a local group which permits the use for antivandalism. Leaderboard (talk) 08:31, 25 March 2023 (UTC)[reply]
  • Oppose Oppose per Martin Urbanec --Ameisenigel (talk) 15:14, 2 April 2023 (UTC)[reply]
  • Support Support --Novak Watchmen (talk) 15:53, 3 April 2023 (UTC)[reply]
  • I have no issues with a helper group being created. I think anyone who wants to modify the filters should just become an admin; I don't want to split out the admin rights piecemeal so people need to request 20 different groups instead of one collection for relatively trusted users. – Ajraddatz (talk) 19:14, 23 May 2023 (UTC)[reply]