why is she running so many builds, that's ridiculous, I should stop these so that my builds have a chance to use the build servers

Hahaha. We had a version of this at Facebook where someone just started killing processes on shared development hardware so they could have more CPU for their REALLY IMPORTANT processes.

My inclination is something like this:

• Give build plans view/edit permission.
• To restart a build, you must have edit permission on the plan.
• Convert "Can manage build plans" into "Can create build plans".

How well would this map to reality in your use case?

(And the build-level buttons would only affect plans you could individually affect -- the build-level "Abort" just means "click every step-level abort I have permission to click".)

Alternatively, we can provide a "kill enemy builds" API and a "your build got killed" webhook and let everyone sort it out for themselves. We could put an action rate limit on build kills so people would be incentivized to band together into coalitions since they wouldn't individually have enough power to kill everyone else's builds or defend their own builds.

After further careful thought, I suppose introducing a "Protect Build" action might be better than rate-limiting build kills. Users protecting a build would increment a "Shield Level" counter, and users trying to kill it would decrement the "Shield Level". Once the level dropped below 0, the build would be terminated. So you could band together with 3 team mates to give all your builds a Shield Level of 4, and require a team of 5 or more attackers to steal your resources. I think this would immediately lead to a fair market for build resources.

We're already waist deep into modifying DB records in Harbormaster that we probably shouldn't be, any expanded control over policies there at all should enable our other custom apps to make it do what we like.

"out of the box" support would look something like: if you triggered the action that created this build, only you have control over stopping it (or admins). If an application started the build (eg, global herald rule in response to a commit), only admins have control.

I thought Phabricator was an adventure game, that sounds an awful lot like RTS.

I'm likely to restrict pause/abort but leave restart broadly available, since engineers generally won't gain anything by restarting enemy builds (it causes them to take more resources) and I think there are legitimate reasons for innocent bystanders to restart failed builds even if they don't have administrative/management powers.

If someone keeps restarting build purely to be a jerk, you can lock them out of Harbormaster or fire them or whatever.

My broad philosophical stance here is that engineers should be disciplined and professional about not killing enemy builds, but I think the complexity cost to put some more guard rails on the thing isn't overbearing and these additional policies are generally pretty reasonable and make sense, and have some redeeming value in preventing mistakes with tools like "Restart All Builds".

For future readers, this is an unusual case, and we're generally very resistant to solving social/cultural problems with technical bludgeoning.

See T10215 for broader discussion of abuse/mischief/etc.

I'll call this out in the changelog, but behavior here is changing slightly (see T13258 and T11415):

• By default, you now need "Can Edit" on a build plan to manually run, restart, pause, abort, or resume builds.
• You can change the "Runnable" behavior for a build from "If Editable" to "If Viewable" to allow anyone who can view the build plan to manually run, restart, pause, abort, or resume builds.