Should we use flags to help with new feature development?

(Régis Hanol) #1

I want to start a discussion about implementing a feature flags system in Discourse.

Note that the meaning of the term implementing can be quite large: from having a set of rules developpers should follow when developing new and large features to actually developing and integrating a full-featured feature flags system.


  • Allows dark launches (all the work is done behind the scene but no UI is updated)
  • Allows staged rollout (features might be enabled for a limited amount of users at first, then an increasing number of users)
  • Improves uptime/quality of service (should there be a problem with one feature, any admin would be able to temporarily disable it until the issue is fixed)


  • Requires a lot of discipline (especially with removing the flags when the feature is stable)
  • Increases code complexity (adding a lot more of ifs/elses)

For starters, we could base this system on the site settings as they are already available throughout the whole application. The only caveat would be that we’re limited to on/off switches.

What do you guys think?

For those who want more information about feature flags, here’s a few interesting links:

(Matt Van Horn) #2

I use Rollout and Rollout UI for this and have been really happy with how it works.
You can see the source code where I use it on my site (at github, mattvanhorn/BJJLife)
config/initializers has the setup
app/views/layouts/application.html.haml invokes it on the navigation.

I really don’t think you want more stuff in site settings, at this point there is a lot of stuff in there that probably shouldn’t be there (especially stuff that shouldn’t be in source control at all).

(Jeff Atwood) #3

What are your current thoughts on this, @zogstrip?

(Régis Hanol) #4

I think there’s currently no need for a full-featured feature flags system. Using the SiteSettings system is enough for what we need.