CLI: Feature Flag Solution

[rphovley]

We want to enable the community to be ab le to build features they want to try out, without the stress of releasing to the whole community to do so. We want to introduce a feature flag solution that allows community members to contribute code in a more risk free way. This will also allow our internal team to introduce features for testing with the community without hurting the group.

Please consider the following with the solution:

• How will a developer create their own flag and "release" it so that the existing user base can choose to turn that feature on?
• How will we handle features that make schema changes? Do we even allow features that make breaking changes?
• In what situations should we have backend feature flags. For many features, the flag may be required for the frontend only (i.e. no harm if there are endpoints that aren't being consumed) but there may be features that alter the logic for a particular report (maybe someone wants to test an alternate way to calculate time)
• What should we include in the PR template for community proposed features?

Potential open source option
https://www.flagsmith.com/open-source

[Idrinth]

I'm not sure if we can get all of that under a single hood. We can't really have random people add/remove/edit core feature flags possibly affecting all users. The same way we can't really provide a way to alter databases, because that could leave us with broken clients that we suddenly have to fix.

I believe we need to split this into a few issues:

• feature flags for core functionality controlled by us
  • pretty much disable/enable any feature in case we released something badly broken
  • locally cached in case there is no network
• plugin system allowing for 3rd party code to be added by an end user (NOT supported directly by us)
  • we should provide an abstraction layer for them to interact with database and existing code
  • direct database access only to tables with plugin name prefix?
  • any abstraction is likely reusable for core plugins
  • install db changes on enabling, rollback on disabling?
  • ability to request feature flags from the core?
  • ability to request feature flags from 3rd party? (user agreement required!)
• "core" plugins submitted to this repo, that we have to support
  • these may be affected by our feature flags directly, since they are core

[rphovley]

I like that. I think this splits up the concepts well. imo, I think priority is 1, 3, 2. Let's split this up into multiple issues for those unique cases. I think the 2nd item probably gets split into multiple issues as well.

My thought is that we use the core plugins as a starting point with people that are in our discord right now. Since it's part of the core code, it'll require more in depth review, but it'll help inform how we should build the 3rd party plugin system

Thoughts?

[github-actions]

Due to inactivity you will be unassigned soon and the issue be freed.

[github-actions]

Due to longer inactivity, this issue has been unassigned automatically.

[github-actions]

Due to inactivity you will be unassigned soon and the issue be freed.

[github-actions]

Due to longer inactivity, this issue has been unassigned automatically.