Define a general term for a group of feature flags

[beeme1mr]

Overview

Many feature flag management tools allow users to group related feature flags. This helps organize feature flags based on their intended use. Given the prevalence of this concept, OpenFeature should define it in the glossary. It’s important that the term we define accurately reflects its usage and remains vendor-agnostic. The term will be used in various artifacts and throughout various specification documents.

Precedence

As mentioned in the overview, many tools already have this concept. Below is a non-exhaustive list of vendors and their terminology:

Vendor	Term
CloudBees	apps
ConfigCat	product/config
DevCycle	project
FeatBit	project
Flagsmith	project
Flipt	namespace
GrowthBook	project
Harness	project
Hypertune	project
LaunchDarkly	project
Posthog	project
Statsig	project
Unleash	project

Considerations

1. Flexibility: Must be applicable to vendors, open source projects, and in-house solutions.
2. Vendor-Agnosticism: The chosen term should be neutral and not tied to any specific vendor’s terminology to ensure broad applicability.
3. Clarity and Usability: The term should be intuitive and easily understood by users, regardless of their familiarity with specific tools.

Vote

With all that in mind, please vote for the term that best reflects logically grouping related flags. Please leave a comment if there's a term missing.

[anghelflorinm]

Hello everybody!

I wanted to share a few thoughts on the options of this poll after discussing with the folks a Google internally. We wanted to come with two additional proposals to be considered and some thoughts on some of the existing options.

Additional proposals to be considered - "Flag modules" or "Flag package"

We would like these two proposals to be taken in consideration. Words like "Module" or "Package" suggest composability.

Potentially modules in the future may contain more than flags, things such as static attribute definitions. From that perspective, module A defining attributes may be imported by modules B and C using flags and flags from modules B and C may use attributes defined in A in their evaluation rules.

On the other hand, modules are usually collections of packages, so choosing a word such as "package" would allow us to group packages in an even higher hierarchy in in the future.

Some thoughts on existing names

Flag set

On the one hand, we feel that the word is very simple and easy to understand. On the other hand, I the wording limits this as containing flags and nothing else (see the section above). Also, from a mathematical perspective, sets are not necessarily disjoint: if a flag named “A” is in set “X”, and set “Y” also contains a flag “A”, this could be the exact same flag. This is different from the intuitive understanding of grouping in namespaces/packages/modules, where elements belonging to different groups are never equal.

Namespace

We had an internal case where we had to switch the keyword "namespace" since it is a keyword in C++. This is a problem that may reoccur. We also feel like this may not propery explain how can it and should be used.

Project

This is more of a Google specific one, but we see it could clash with the term "Cloud Project".

Conclusion

I think beyond the votes we should also take into consideration a few of these aspects when choosing a vote, to make the term will match long term needs and is intuitive.

[beeme1mr]

I attempted to update the vote to include the new terms. Unfortunately, this is a destructive action and will reset the vote. I suppose this makes sense but I wanted to confirm that's what we want to do.

I feel that a module or package may make more sense as a superset of whatever term we define here. The additional metadata you're referring would be valuable for code gen but may not be necessary elsewhere.

[anghelflorinm]

Sure, and IIUC you could have:
Flag set: collection of flags
and
Flag module/package: flag set + other metadata and static properties.

In which case I'm wondering if a Flag module concept may end up completely absorbing the flagset concept, deeming it obsolete.
If we plan to add supporting the concept of importing modules into one another, it's probably likely the case of sharing some other data between them will appear.

[jonathannorris]

At DevCycle we have a bit of a different hierarchy Organizations -> Projects -> Features -> Variables, where a team is working on a Feature that usually contains multiple Variables (Flags). But if you are thinking of what is the higher level structure that contains all Flags that would be Projects for us.

[moredip]

Also, from a mathematical perspective, sets are not necessarily disjoint: if a flag named “A” is in set “X”, and set “Y” also contains a flag “A”, this could be the exact same flag. This is different from the intuitive understanding of grouping in namespaces/packages/modules, where elements belonging to different groups are never equal.

FWIW, I think there are probably OpenFeature providers where there could indeed be two identical flags that live in two different groups. For example there might be a flagset (or whatever we call it) for an android app that contains showOneDayShipping and showAndroidFeatureA as well as another flagset for the iOS app that contains showOneDayShipping and showiOSFeatureB.