[drichelson]

The PR is optional, but governance often requires documented peer approval for all production changes.

Flag changes can be pushed directly to the main branch with the correct repo permissions. When using the GitHub UI this involves just a little bit of typing and a few clicks.

>might as well just change the code at that point

If changing the code, running tests, building, and deploying is quicker and less risky then yes that makes more sense.

[wewtyflakes]

This seems like a reach. A nice benefit of having these server-owned configuration flags with a slick UI (like launchdarkly) is that they can be modified by people on the fly, and by people who may not even be engineers (like product managers). I imagine, that if the ask is that they instead get GitHub permissions, make a PR, wait for a review, etc, then perhaps you are not competing with launchdarkly. Though, having Git controlled server-owned configuration is still nice regardless.

[willsmith72]

Depends on the feature. In 99% of cases, I'd prefer an engineer to launch it and have the change tracked by source control

[randerson]

The sole reason I like feature flags is that I can quickly toggle off a change if it causes a problem. I'd hate to need to find someone to sign off on restoring service. Anything more than 1 or 2 clicks is just adding precious seconds to an outage. I've worked at places that gave broad implicit approval to developers to toggle away as needed. It worked well.

[teeray]

> I'd hate to need to find someone to sign off on restoring service.

In these shops, this gets handled via paging on-call engineers. The on-call is sometimes given more latitude if their actions are auditable.

[mosselman]

Imagine being called out of bed to turn off a feature flag.

This is nonsense.