I don't plan to pursue field-level permissions in any application. They were somewhat recently removed from Maniphest in T10003. That task discusses some of the complications that field-level permissions create in the general case.

I'm not sure I really understand the use case here. For example, editing URIs allows you to replace the contents of a repository with the contents of some other observed repository. The observed repository may be empty, so this is equivalent to pushing a commit which deletes everything. This operation seems dangerous if you consider deleting the repository to be dangerous.

Deleting a repository also isn't necessarily particularly dangerous. If this is the major concern you have, making reverting a repository across a force push easier (T10861) might be a shorter path to a similar goal.

Editing projects can also be dangerous, if object rules or "repository project" rules in Herald are used to protect the repository.

Finally, you can set some controls in Herald which are stronger than Diffusion controls. If you have a global Herald rule which prevents anyone from pushing dangerous changes, users won't be able to force-push a repository even if they disable protection for that repository. If this is your only concern, this permission is already effectively separable. You could conceivably even use Herald to enforce a stronger "Can Push" policy, although this may make the UI somewhat confusing.

Another thing to consider is that your worries may be entirely solved at a social level. Giving people access but reminding them to only modify 'safe' fields. If your users are somewhat trustworthy this is entirely reasonable.

It's also vaguely possible that we'll add "suggest an edit" (ala T4104) in a generic way, then untrusted users could suggest edits and trusted users could approve them. I don't currently plan to build this as a general-purpose workflow, though.

At some point the bulk editor will be generalized to work with all EditEngine applications, including Diffusion. If your edits are primarily "we need to tag a thousand repositories", this would let volunteers do something like this:

• Find all the repositories that need tag #x.
• Compile a list of their IDs.
• Write on a task somewhere "All these repositories need to have tag #x added: link to query results".

Then a user with edit permission could click the link, review the results to make sure they make sense, click Bulk Edit → Add Tag and add #x. This isn't perfect, but could reduce the setup cost.

This issue also probably impacts WMF more than other installs (most private installs can afford to give users broader edit permission, since the barrier to entry is higher).

This issue also sounds like it might be largely an onboarding/setup issue, not an ongoing issue? Tags can be edited via the API, so if you have a one-time need to tag a thousand repositories you could conceivably use something like a spreadsheet to coordinate and then have someone just bulk-apply the edits via the API with a few lines of script.

FWIW: I believe @paladox means well, he's just young/inexperienced and overly enthusiastic. The decision to ban him is entirely reasonable for upstream though, given the circumstances.