Page MenuHomePhabricator

Ensure that auto-created Phabricator projects for Toolforge tools are always editable by that tool's maintainers
Open, MediumPublicFeature

Description

Feature summary
When Striker creates a Phabricator project for a Toolforge tool, it should configure that project to be editable by that tool's maintainers (at least, when its maintainers aren't already members of the Trusted-Contributors Phab group).

Use case(s)
Not all maintainers of Toolforge tools will be members of the Trusted-Contributors Phabricator group, which (by default) is necessary in order to edit a newly-created Phab project. This means that a tool's maintainer might not be able to configure/edit the project that's been created for tracking work for that tool -- at least, not without specifically requesting to be able to do so (either by being manually added to that project's 'edit policy', or by being added to Trusted-Contributors).

An example of this type of situation is present in T412580: Grant TausheefHassan edit access to auto-created Toolforge Phabricator project (Tool-pid-bangladesh-uploadbot), where @TausheefHassan had to request to be able to edit the Phabricator project (Tool-pid-bangladesh-uploadbot) that @StrikerBot had created for their own tool. However, it seems probable (to me) that not everyone in this position would end up making such a request.

Benefits

  • Ensure that (where Striker can find a Phabricator account for them) a tool's maintainers are always able to modify the Phab project for their own tool (e.g. add workboard columns, edit the project description, etc.), so that they can use it for task-tracking in a way that suits them best as tool maintainers.
  • ...and, therefore, make life easier for those who contribute technical tools to the Wikimedia community :)

Event Timeline

After looking a little bit at striker/phabricator.py, I feel like I might be up for submitting a patch for this myself; but I'd first want to hear from the Striker & Phabricator maintainers regarding (e.g.) whether this'd be a desired change or not :)
In particular, it feels like the easiest way to implement this might be to have a tool's maintainers be unconditionally added to the 'edit policy' of the Phab project that Striker creates for that tool (i.e., regardless of whether or not they're a member of Trusted-Contributors, as figuring that out would presumably require an extra Phab API call & additional logic). So, I guess I'd like to know, would that sort of approach be acceptable to Striker/Phabricator folks?

Anyone who has access to Toolforge is clearly trusted. Striker should just add them to Trusted-Contributors

If folks are okay with that then that's maybe okay with me (but I might not be the person to put that patch together). I wouldn't want this feature to get inadvertently stalled on deciding whether that should happen automatically (if if happens to be a contentious proposal), though :)

edit: added 'maybe', due to potential concerns coming to mind after leaving this comment

taavi subscribed.

Seems reasonable to me. We could even just add people to Trusted-Contributors after their Toolforge access request has been approved, instead of only adding those who end up creating a project.

Seems reasonable to me.

Just to be absolutely clear, would this be about the idea to include tool maintainers in the edit policy of auto-created projects, or about the idea to automatically add tool maintainers/Toolforge members to Trusted-Contributors (or about both)?

it should configure that project to be editable by that tool's maintainers

If that means "tool's maintainer(s) and/or Trusted-Contributors", then I don't believe this is currently supported by the API as that would require creating a custom policy object first. (I'd love to be wrong.)

Just to be absolutely clear, would this be about the idea to include tool maintainers in the edit policy of auto-created projects, or about the idea to automatically add tool maintainers/Toolforge members to Trusted-Contributors (or about both)?

To add people to Trusted-Contributors. Adding individual people to ACLs of individual objects would create an unnecessary unmanageable mess.

it should configure that project to be editable by that tool's maintainers

If that means "tool's maintainer(s) and/or Trusted-Contributors", then I don't believe this is currently supported by the API as that would require creating a custom policy object first. (I'd love to be wrong.)

FWIW, from looking a bit at the code, I believe that Striker's internal Phabricator library might currently support doing this with regards to Diffusion repos (using the policy.create endpoint (T135249: create conduit method for the creation of phabricator policy objects)).

Adding individual people to ACLs of individual objects would create an unnecessary unmanageable mess.

Ehh; to be honest, I'm not personally sure if/why it'd be necessary to 'manage' these sorts of ACLs - maybe I'm missing something but I don't currently see an inherent problem in some projects having different/custom edit policies to other projects, as long as they all also include Trusted-Contributors. (If I had to guess, I'd assume that there are probably a lot of custom Policy objects that have been created on Wikimedia Phabricator so far.)
Though I do hear what folks are saying in this task so far that the better approach here would be for Striker to just add tool maintainers/Toolforge members to Trusted-Contributors. I asked a couple of questions in the parent task regarding some thoughts that came to mind about that idea (T364516#11459312).

For the records, policy.create and policy.query are Wikimedia downstream hacks and don't exist in upstream Phorge.
The current problem of lots of custom policies might be a bit more described in https://we.phorge.it/T15277

My only concern about linking Toolforge membership and Trusted-Contributors was what would happen on the Phabricator side in the infrequent but still possible case where the Toolforge membership is used in an abusive way and subsequently revoked. I think I have convinced myself that existing processes will handle this, but I welcome others checking my assumptions and logic. I believe that the existing process on the Toolforge side would be to use Bitu (idm.wikimedia.org) to lock the abusive Developer account. This would as a consequence also lock/block any Gerrit, GitLab, and Phabricator accounts connected to that Developer account. The Bitu based locking is the modern equivalent of blocking the Developer account on Wikitech which used to trigger the same cascade of revoking rights in the related developer platforms.

I believe that the existing process on the Toolforge side would be to use Bitu (idm.wikimedia.org) to lock the abusive Developer account.

What about in a hypothetical case where a person has broken the Toolforge rules to the point of being removed as a member, but hasn't been overtly/intentionally abusive to the point of blocking their entire development account? (Would this sort of hypothetical scenario ever happen?)

This would as a consequence also lock/block any Gerrit, GitLab, and Phabricator accounts connected to that Developer account.

Something maybe worth bearing in mind: to my knowledge, an end-user can remove the link to a developer account from their Phabricator profile. So IIUC, a malicious actor could theoretically:

  • (a) become a Toolforge member with a development account that is linked to their Phab account,
  • (b) unlink their dev account from their Phab account,
  • (c) be abusive/malicious on Toolforge (resulting in their dev account being blocked via Bitu), and
  • (d) still have an un-disabled Phab account.
fgiunchedi triaged this task as Medium priority.Dec 19 2025, 1:25 PM

What about in a hypothetical case where a person has broken the Toolforge rules to the point of being removed as a member, but hasn't been overtly/intentionally abusive to the point of blocking their entire development account? (Would this sort of hypothetical scenario ever happen?)

It hasn't happened yet, and honestly I don't think it is a likely scenario. Folks are in practice only kicked out of Toolforge for TOU violations like abusing compute resources to mine crypto, send spam, or generally harass folks. I really can't think of a scenario where this has happened and we still want the human behind the account to continue to contribute Gerrit patches, etc. When people show that they are jerks we should believe them.

Ancient but https://wikitech.wikimedia.org/wiki/User_talk:Dispenser#Blocked seems to fit that description.

If we had had https://www.mediawiki.org/wiki/Code_of_Conduct and global Developer account blocking at the time that would have without doubt been a global block.