Research - Random ideas & observations

Add in a end date & time feature (similar to scheduling a start date & time for feature deployment)

Chris:

• split.io - don’t support this

• LD - supports scheduling start the rollout

• configcat - doesn’t support this

• rollout.io - i don’t know

• Did you mean like timing how like the feature you’ve wrapped in a feature flag takes to run?

Anuj:

• That makes sense. Considering Chris wants to build this into an experimentation platform, that would be good. You want to have your experiments runs for a set time.

Richard

If it doesn’t exist already, accommodate for different timezone by allowing a developer to have a date & time match up world wide (i.e. schedule a feature to be deployed on December 25th 12am in every country)

Richard

Provide a function that will automatically create a break point or a significant marker such that the analytical data will be sectioned into sections so a user can check data/stats between areas of their code that they think are significant

Chris:

• oooh interesting, so automatically instrumenting how long it takes a feature to execute

• like would be good to allow consumers to use prometheus with the flagbase server-side sdk, to automatically instrument wrapped features

• also it depends on the nature of the feature

• like every time a user sees a feature, we get what time they evaluated that flag

Richard

Codifying flag set rules, segment, everything you can?

Chris:

• Yeah I think it’s work following HashiCorp’s philosophy of codifying infra structure related things. I think a feature flag configuration file that automatically gets parsed and is used provisions flags will give us a massive edge over others

• We can use the local targeting config as a fallback if the service is not reachable.

Oliver:

• Would also enable you to version control the rules nicely

Richard

Custom events or provide more events for your metrics?

Chis:

• Yes, I’ve thought about building an analytics pipeline, but that’s way down the track. Analytics is a key part of instrumentation (also a requirement for experimentation)

Richard

Seeing how you can have rules on what % of users will see which group - can you see more about which exact users were in each group? Why not have an option to alternate the features to a different group - for example I will first let it randomly allocate which of 4 features my 100 users will use. So 25 users (group 1) get feature 1, 25 users (group 2) get feature 2... etc. Why not allow a way for you to just allow it so I can easy switch feature 2 to group 1 and feature 1 to group 2?

Chris:

• That seems like a very advanced use-case of cohort flickering. Normally we try prevent cohort flickering. Like can’t think of any utility of having such feature

Richard

Change how flags/segments are grouped

If I have a group of users say group 1 who I want to deploy 2 new features to them, meaning 2 feature flags. I need to make 2 feature flags, make a segment to only target group 1 then go back to my 2 feature flags and have the flag target the users. Is this correct? IF THIS IS TRUE, I really want to be able to group my feature flags into a list and then be able to easy make it so my users group 1, will now be affected by everything in my feature flag list instead of manually having to go through it all. Like I might be thinking about it wrong and I am not the best at set theory but I feel like their way of grouping users based on rules then applying a feature flag to these groups could be done a better way?

Chris:

• Yes that flow seems correct. Yeh grouping flags based on segments might be useful, but I think it’ll just overcomplicate things. It might be better to just allow segment targeting within the flag creation process. So as soon as you create a flag, you can specify the flag to be targeted to a particular segment. But I like the idea - gonna create an ideas page (please add these suggestions on that page and I think after the MVP has been built, we’ll priorities the list of ideas / refine them and see what problem they are really trying to solve / if the problem even exists)

Richard

Allow more SDKs to support behaviour in multiple environments

Open

Chris:

• Yeah it can be applied to all sorts of applications

• Esp. server-side applications

• But I don’t think we should prioritise this feature yet

• I think we should make the interface very simple and if they want to access flags across evironments, they should just create another flagbase client instance with a new connection

Richard

When designing the system, process flow or for the layout for the codify system, it is worth checking out existing designs: Ansible, Chef Sofware, AWS CloudFormation

Richard

In addition to having a date for when the flag should be turned off, how about allowing a user to have a flag automatically turn off if its usage is below a set amount over a time period? (a way to address stale/forgotten feature flags)

For example:
I want my paypal_authentication flag to be turned off if its hit rate is below 40% over 1 a month period

Richard

Flags can be retired/archived and cannot be reverted back into production - This is so I can see the analytics from this previous flag

Richard

Adding onto Codifying, would it make sense to allow developers to make groups which would target specific sets of users. This could then help replace the current specific user targeting and flag constraints/targeting rules (userID > 1000), mean there is less code to write in your codified rule set + could help non-devs understand the code better:

For example:

Richard

A developer has the option to send a variable (key-value pair) in their feature flag configuration, allowing your features to use dynamic variables. This idea came from Optimizely: video reference & Optimizely Docs

Richard

A developer has greater control over the deployment of their feature flags, by outlining how the rollout breakdown over time should be defined (as per the picture). This idea came from AB Tasty’s Flagship: video reference

Open

Richard