^ we would also be keen to add some kind of rules/conditions around what can be set up by default, or perhaps e.g. some templates for how features should be set up

We are thinking about adding templates to experiment forms, how are you thinking this would work for features?

So to give a general overview, currently I have to give people a fair number of very strict "you must not do this or it might break things badly" etc instructions Even with those explained and documented in depth, it's still hard for people to consistently cover everything Just as a few examples: • when setting up a webflow redirect, you _must_: ◦ only select the webflow environment, deselect nonprod + prod ◦ select the redirects project ◦ use a string type ◦ ensure the default value & control variation are completely empty, incl no spaces ◦ add a targeting condition for which page to redirect from - or the entire site will break immediately ◦ A/B hashing attribute must be

mojo_device_vendor_id

• when setting up a feature for the CMS or app: ◦ env must be prod + nonprod, or just nonprod - never webflow, and never prod by itself ◦ ensure the default & control values are falsey/off ◦ must have a rollout rule targeting staff, above any A/B experiment rule (to exclude staff from analysis) ◦ if any user will be exposed to a given value, at least 20% of staff must also be exposed to it - ie you can't roll out a feature to 100% of staff and 50% of users (because the control might be broken/buggy, but we won't notice when testing) ◦ A/B hashing attribute must be

mojo_user_id

ok, interesting. I can discuss this with our team tomorrow,

I'd ideally have two templates - the first is prob pretty obvious The second, it'd be one rule targeting staff defaulting to 80%, another rule doing A/B testing for users defaulting to 50% With that, for 90% of our tests, probably only the feature name + values would need to be set - everything else would be correct already Ideally we'd flag specific fields as being required to set/update, or at least we'd default them as obviously-incorrect values like "[changeme]" etc

I know you said it's not a permission or trust issue but it seems like an approval step before publishing feature changes might help. Some of those requirements and checks seem pretty custom so not sure there's a good way to automate all of it. Only thing I can think of is to let you write custom JavaScript validation code.

imo that papers over the real issue

Yeah, feature templates make sense. I think a lot of the issues you have are a side effect of the redirect hack you're currently doing. I can see us adding first class support for those types of experiments in the future. So you could create a feature flag experiment, visual editor experiment, or redirect experiment.

Some carefully customised defaults would resolve the issue entirely

I was thinking about JSON schema, but it's not the best when it comes to enforcing order of array elements. So requiring a rollout rule before an experiment rule is hard to express.

hmm yeah

If we did custom JavaScript validation, you could throw exceptions and we would show the error message to users. And we would have a way for you to ignore the validation if needed for a specific feature.