Meta description attribute for features

[connorwarnock]

We hardcode defaults for all features in the app in a config file to act as documentation for all existing toggles. And while the name is usually descriptive ('new_dashboard'), it's usually short and sweet. It'd be useful to have a meta attribute for a feature to describe the feature in more detail (intended to help other devs / non-technical admins fully understand a feature).

And while it's definitely possible to put this meta description in a readme, readme's aren't easily accessible to non-technical admin vs a dashboard like Flipper UI.

Example:

$flipper[:new_dashboard].meta = 'The new user dashboard layout including the a redesigned profile section.'

[jnunemaker]

The biggest thing for this is persistence. Right now we only persist the name of the feature. Part of me wonders if we need to persist anything. Perhaps we could go the same route as groups and just register features with name, description and anything else needed.

The only downside is that the flipper-ui would always need to be mounted from the same app as where the groups and features are registered, but that seems fine. Anyone have any thoughts on this?

[rsanheim]

I think this would be useful for GitHub's use of flipper right now. Having a description field we could throw arbitrary markdown into would be very nice.

[gdavison]

We're using https://github.com/paybyphone/flipperdotnet from .Net code, so obviously we can't mount the UI from the app. Though we're probably the only people using it :)

[jnunemaker]

@gdavison yeah I'm kind of leaning toward the "persist all this interesting metadata the whole way down" path right now, but I've been thinking through how to allow doing that, without forcing it. I think as long as only name/key is required to use flipper then what we could do is perhaps add some new methods for creating/updating a feature with more meta data (ie: description, which gates can be used, etc.).

[rmosolgo]

Thanks for the great gem! I was slow to see the light on feature flagging but I'm coming around at last.

Another kind of metadata I'd like is a description of various actors. For example, our application is really dependent on our client's hardware configuration (label printers hooked up to USB, which we communicate with via a natively-installed webservice on localhost, it's a nightmare).

We're currently rolling out an upgrade to how we communicate with the printers, but some small number of users are reporting bugs in the new implementation. So, we're using a flag for this new code, slowly testing it in some cases, and hopefully (eventually), turning it on by default, but blacklisting some users to stay on the old implementation.

I'd love to able to add a description to specific actors, for example:

That way, we could look back recall why certain people are getting certain flags!

[jnunemaker]

@rmosolgo What we do at github for that is to create an audit log per feature (in our custom UI). We hook into the ActiveSupport notification events and create audit log entries when things are enabled/dsiabled. Our custom UI then shows those when you are viewing a feature. I'd like to have some way of doing this for flipper in general as well.

I think the key would be to allow passing who and why to enable/disable and then having a format per adapter to store those. It is most likely a decent amount of work, but definitely something I would like to see at some point.

I'm currently spending some time on an alternate idea for adapters that is more key/value style. That would allow for storing random meta data along with features (like disabled gates, descriptions, etc.). It could allow for storing a message like this as well. The branch is backwards compatible kv. I need to write up somewhere here what I'm trying to do with that branch. I currently use trello for personal todo's so I've got a bunch in there, but it really should be in this repo somewhere.

[rmosolgo]

Thanks for the info, that sounds just like what I'm looking for! I'll keep an eye on that branch.

Now ... if only there was some kind of ... built-in trello in github where we could keep our ... projects 😆

[jnunemaker]

@rmosolgo wow, that is such a solid and a great point! I nearly did that by enabling projects for this repo before it was launched, but quickly realized that this is a public repo and that would be a bad idea, thus trello. I'll try to move things to projects here soon and get more written up so people have an idea of direction, even if it is happening slowly.

[rmosolgo]

I don't use projects either ... just wanted to crack a joke :P

[jnunemaker]

@rmosolgo are you using flipper in production? At planning.center?

[rmosolgo]

Yes, several of our teams are using it for their apps!

Actually I'm a late adopter -- I held off for a long time because I was afraid of "littering" the code with conditionals. Turns out that didn't happen, and now I'm a big fan of this technique. I use it for things other than new features too, for example, we have an external service that occasionally caused us slow-down (and the latency was during the SSL handshake, I couldn't find a timeout that would actually prevent it!), so now our integration is behind a "feature flag" which any staff member can flip as needed. Very nice!