[drichelson]

I have mostly seen developers in charge of changing flags, but there is also great value in empowering other roles to change flags (One example: sales people can unlock features as they sell them).

Thankfully GitHub has an easy web-based Pull Request process. It's not as simple as a custom UI, but could be used by non-engineers to change flags.

[willsmith72]

That's not a feature flag, that's a feature of the product. I would keep the 2 very distinct.

[candiddevmike]

> sales people can unlock features as they sell them

That's a licensing thing, not a feature flag.

[yoz]

Not always. The most common counter example is beta features which customers opt into, controlled by the product team. It's too early for that to be part of the license, especially because pricing often hasn't been decided yet.

But there's also a surprisingly common situation with big customers who want to limit and control certain UI updates so they can ensure that employees are trained appropriately.

[yjftsjthsd-h]

What's the difference? Either way you're turning on and off code that's already in the application. The only difference I can immediately see is that some people do feature flags as being on or off for the entire application instance, but I'm pretty sure you can do A/B testing with them at arbitrarily fine granularity and still count as a feature flag.

[shagie]

There are many different types of toggles of functionality. Not all of them are enabling code features. Well, they are but the why they are is what is at issue.

But it's all the same code under the covers. The functionality of what is enabled encoded into a license key - that's the same type of functionality as "does this deployment allow people to sign up by email" or "has this deployment enabled the super secret power user test functionality?"

But that's all under "if dataSource.toggle then {something}"

https://martinfowler.com/articles/feature-toggles.html

[vosper]

It’s a trusting and non-siloed org that gives the sales team access to the repos