[wfme]

There are more options than store in git, or flip willy nilly.

For systems of sufficient scale, it's fairly standard to keep flag changes outside of git so that they can be flipped without a pr. That way the flag change UI can apply other validation steps before any change is attempted such as ensuring valid enrolment ranges (no accidental overlap, and no accidental rollouts to 100% instead of 10%), and the associated rollout analytics can be shown alongside the changes.

You can also override things in emergencies more easily, which is the parent's point.

[hinkley]

But it’s also common to stick those flags back under some sort of audit system so we know why and how weird states got set. The simplest way is a separate repo with simpler rules for pushing to master.

Though you could also create your own audit system (just make sure it functions even when the entire site is down)

[bottd]

This is all decided by business needs, not by engineer preference. If devs aren’t pulling the levers it is good to expose them in an accessible interface, not plaintext.

[teeray]

Chatbots are great for this too. You get flippiness, but you also get auditing implicitly from the chat log.