Page MenuHomePhabricator

Add the abusefilter-modify-restricted right to enwiki EFMs
Closed, ResolvedPublicRequest

Description

This change is to add the abusefilter-modify-restricted right to enwiki EFMs, allowing them to enable revoke autoconfirmed on filters and edit filters with it on. The discussion ran for 7 days without objection, and as one participant put it "potential for abuse is very low".

Local discussion:
https://en.wikipedia.org/w/index.php?title=Wikipedia:Edit_filter_noticeboard&oldid=1314122191#Add_the_abusefilter-modify-restricted_right_to_EFM

Event Timeline

EggRoll97 triaged this task as Low priority.

Change #1192326 had a related patch set uploaded (by EggRoll97; author: EggRoll97):

[operations/mediawiki-config@master] Add abusefilter-modify-restricted to enwiki EFM

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

Change #1192326 merged by jenkins-bot:

[operations/mediawiki-config@master] Add abusefilter-modify-restricted to enwiki EFM

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

Mentioned in SAL (#wikimedia-operations) [2025-10-02T07:29:50Z] <hashar@deploy2002> Started scap sync-world: Backport for [[gerrit:1192326|Add abusefilter-modify-restricted to enwiki EFM (T405999)]]

Mentioned in SAL (#wikimedia-operations) [2025-10-02T07:36:23Z] <hashar@deploy2002> eggroll97, hashar: Backport for [[gerrit:1192326|Add abusefilter-modify-restricted to enwiki EFM (T405999)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-10-02T07:45:30Z] <hashar@deploy2002> Finished scap sync-world: Backport for [[gerrit:1192326|Add abusefilter-modify-restricted to enwiki EFM (T405999)]] (duration: 15m 40s)

This, in all probability, should not have been deployed given the current state of the discussion. Imo it needs wider input from the community, 3 people on enwiki cannot be called a consensus enough for such a sensitive change. I agree that the chances of abuse are low, but that does not preclude having a more robust discussion about this.

This, in all probability, should not have been deployed given the current state of the discussion. Imo it needs wider input from the community, 3 people on enwiki cannot be called a consensus enough for such a sensitive change. I agree that the chances of abuse are low, but that does not preclude having a more robust discussion about this.

I think the consensus was sufficient here. There was more than a full week before it was put into Phabricator, and multiple days after that before the change was deployed. The edit filter noticeboard has 351 people as watchers, and of those, 57 visited in the last 30 days, providing ample opportunity to leave any comments in opposition. It's not as if this was held in an obscure area, it's a noticeboard linked to in the noticeboard template, and yet still, there was not a single actual objection to this proposal.

This, in all probability, should not have been deployed given the current state of the discussion. Imo it needs wider input from the community, 3 people on enwiki cannot be called a consensus enough for such a sensitive change. I agree that the chances of abuse are low, but that does not preclude having a more robust discussion about this.

I think the consensus was sufficient here. There was more than a full week before it was put into Phabricator, and multiple days after that before the change was deployed. The edit filter noticeboard has 351 people as watchers, and of those, 57 visited in the last 30 days, providing ample opportunity to leave any comments in opposition. It's not as if this was held in an obscure area, it's a noticeboard linked to in the noticeboard template, and yet still, there was not a single actual objection to this proposal.

The reverse applies as well, for such a discussion. If it was getting only 3 supports, it shows that there isn't strong support for this action even on a noticeboard where folks are more likely than not to support it. With respect to Phabricator, I think folks bringing and subsequently scheduling and deploying site-wide changes have a significant responsibility to evaluate the consensus and make sure their actions have the clear-cut backing of the community (think implementing a close in enwiki terms). Also, folks will raise objections in egregious cases (where no links to discussions were provided), but the lack of dissent on phab is typically not a strong signal of nobody having objections, but rather people going "Yeah, everything mostly looks right, no technical concerns, EggRoll97 knows what they are doing".

This, in all probability, should not have been deployed given the current state of the discussion. Imo it needs wider input from the community, 3 people on enwiki cannot be called a consensus enough for such a sensitive change. I agree that the chances of abuse are low, but that does not preclude having a more robust discussion about this.

I think the consensus was sufficient here. There was more than a full week before it was put into Phabricator, and multiple days after that before the change was deployed. The edit filter noticeboard has 351 people as watchers, and of those, 57 visited in the last 30 days, providing ample opportunity to leave any comments in opposition. It's not as if this was held in an obscure area, it's a noticeboard linked to in the noticeboard template, and yet still, there was not a single actual objection to this proposal.

The reverse applies as well, for such a discussion. If it was getting only 3 supports, it shows that there isn't strong support for this action even on a noticeboard where folks are more likely than not to support it. With respect to Phabricator, I think folks bringing and subsequently scheduling and deploying site-wide changes have a significant responsibility to evaluate the consensus and make sure their actions have the clear-cut backing of the community (think implementing a close in enwiki terms). Also, folks will raise objections in egregious cases (where no links to discussions were provided), but the lack of dissent on phab is typically not a strong signal of nobody having objections, but rather people going "Yeah, everything mostly looks right, no technical concerns, EggRoll97 knows what they are doing".

Apologies, I wasn't meaning the lack of dissent on Phabricator, I was referring to the lack of dissent on EFN, even with ample time for anyone to raise such dissent. I think the change is consistent with prior changes without an RFC, like for example, https://en.wikipedia.org/wiki/Wikipedia:Edit_filter_noticeboard/Archive_14#Protected_variables_access_for_EFH/EFM which added abusefilter-access-protected-vars to EFH/EFM, and while it did have a few more supports, didn't really have that much more than the current proposal, and nor was there an RFC needed. I think it's also worth mentioning that calling this a "sensitive change" seems a bit of a stretch, considering the change only gives access to edit filter managers, who the community already trusts widely with editing filters in general.

@Soda I have deployed it because the same setting has been enabled on other wikis and there is a public RfC which showed it was low risk. Maybe I could have asked for a bit more discussions, then given it is low risk I choose to deploy it immediately to reduce the waiting time.

@EggRoll97 I am more than happy to revert and deploy the config change if that needs more discussion :/

There has not been an RFC.

And I don't think the abusefilter-access-protected-vars change is comparable.

  1. That discussion was advertised on VPP.
  2. That change had 7 supports on EFN, which is significantly more than the 2 or 3 supports for this change.
  3. It seems like that proposal was closed unnecessarily quickly with a very limited number of hours between it being posted on VPP and being closed. I don't think it is a good example of the process we should be following and I don't think this is a good trend for how change requests should be made.

Overall, I am on the fence about the change, but it seems clear that there has been insufficient notification and discussion about this change on Wikipedia (1) to file this ticket and (2) to push this configuration change into production.