When creating a feature flag (or segment or metric for that matter), it's a good idea to create a convention that your team can follow. Your approach will be specific to your organization, of course. Below are some suggestions based on conventions we use internally:
You could enforce names that are lower case only, camel case, or snake case (no periods, no spaces, etc.). Use a common taxonomy, for example:
Feature flag: project_feature
Metrics: Descriptive, also useful to note per v. across
- Tasks completed per user
Split's user interface can get crowded, and we are constantly trying to improve this experience. Below are some tips to help stay organized as a team.
Tags: Add tags to feature flags to associate them with projects, teams, features. For example, multiple feature flags for the same feature should all utilize the same tag for better filtering. You may want to indicate where the feature is built. Tags are case sensitive, and lowercase is recommended. For example:
- frontend feature flags, use
- backend feature flags, use
Owners: At a minimum, the feature flag creator will be an owner (along with Admins). Typically, an engineer and PM will both own a feature flag. Segments and metrics may only have a single owner, and are less likely to change. Groups, such as an engineering team, are also useful to make as owners.
Starring: Star any feature flags that you would like to surface easily. Starring is isolated to you, so it's a good way for an individual to drill into currently used feature flags.
Traffic Type: While not the primary use for Traffic Type, you can use it as a way to filter in on a specific set of feature flags.
You may want to tag objects that need to be deleted as a reminder, depending on your process, or as a check before taking action. For example:
- Feature flags should only be deleted if they have the tag
- Please confirm with a member of the appropriate team before removing any feature flags.