Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Dorkly – Open source feature flags

github.com

Post reply on HN
Print view View original

1–10 of 104 posts

Re: Show HN: Dorkly – Open source feature flags

#2

Post by hiatus »

I like the idea of the flags being managed via normal change-management processes. In your experience, is it primarily developers in charge of enabling/disabling flags or have you seen responsibility diffused across departments (marketing, sales, etc)?

Re: Show HN: Dorkly – Open source feature flags

#4

Post by drichelson »

hiatus wrote: post #2

I like the idea of the flags being managed via normal change-management processes. In your experience, is it primarily developers in charge of enabling/disabling flags or have you seen responsibility diffused across departments (marketing, sales, etc)?

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.

Re: Show HN: Dorkly – Open source feature flags

#5

Post by snapcaster »

If it's something controlled by the PR why is it even a feature flag? Seems like you lose a huge chunk of the benefit and might as well just change the code at that point. This to me seems like the wrong place to be controlling them, i certainly don't want to have to make a PR and merge it when a site issue is happening.

Open to missing something though, curious what others experience has been

Re: Show HN: Dorkly – Open source feature flags

#6

Post by alexchamberlain »

snapcaster wrote: post #5

If it's something controlled by the PR why is it even a feature flag? Seems like you lose a huge chunk of the benefit and might as well just change the code at that point. This to me seems like the wrong place to be controlling them, i certainly don't want to have to make a PR and merge it when a site issue is happening. Open to missing something though, curious what others experience has been

I think the idea is that it's a separate flags repo?

Re: Show HN: Dorkly – Open source feature flags

#7

Post by vosper »

drichelson wrote: post #4
hiatus wrote: post #2

I like the idea of the flags being managed via normal change-management processes. In your experience, is it primarily developers in charge of enabling/disabling flags or have you seen responsibility diffused across departments (marketing, sales, etc)?

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.

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

Re: Show HN: Dorkly – Open source feature flags

#8

Post by snapcaster »

alexchamberlain wrote: post #6
snapcaster wrote: post #5

If it's something controlled by the PR why is it even a feature flag? Seems like you lose a huge chunk of the benefit and might as well just change the code at that point. This to me seems like the wrong place to be controlling them, i certainly don't want to have to make a PR and merge it when a site issue is happening. Open to missing something though, curious what others experience has been

I think the idea is that it's a separate flags repo?

Can you say more? I think i'm missing the point, in my mind that would make it even worse because you have all the problems I mentioned + merge conflicts being a possibility

Re: Show HN: Dorkly – Open source feature flags

#10

Post by candiddevmike »

drichelson wrote: post #4
hiatus wrote: post #2

I like the idea of the flags being managed via normal change-management processes. In your experience, is it primarily developers in charge of enabling/disabling flags or have you seen responsibility diffused across departments (marketing, sales, etc)?

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.

> sales people can unlock features as they sell them

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

Post reply on HN