Settings for experimental features

[gnprice]

It would be useful to have feature flags to control enabling features that aren't yet complete. This is a common technique for making it possible to merge PRs that make partial progress toward a complex multi-PR feature: those working on the feature can have the feature flag enabled in order to see the current incomplete behavior, while for everyone else it remains disabled and so (barring bugs in the use of the flag itself) has no effect.

Specifically I think a good design for this for the Zulip mobile app would be to have a collection of local boolean settings on the device, with UI for them in a subsidiary settings screen, labeled like "Experimental features". Plus probably some text at the top of that screen stressing that these are half-developed features and may not work properly.

Example features where we would likely want to use this include:

• TeX in the message list #46

  (At a later stage this might get promoted to a normal setting, with the default flipped to being enabled, if we find that at launch time there remain some TeX constructs we don't yet support. Alternatively it might stop needing a setting if we're able to reliably detect when parsing a given math expression whether we're able to support it, and so fall back automatically.)

• Handle no-topic topic ("general chat") #1250

  Our current approach there has the feature enabled by a handful of "do not merge" commits that go at the tips of the PRs. A feature flag could provide a more easily accessible way to try out the partial support.

I expect there will be more examples in the future — these are just the two we're currently working on right now.

[gnprice]

BTW one important risk when using feature flags is that if they're allowed to accumulate, they can add more and more complexity to a codebase in the form of conditionals that are in practice always true, or always false (or sometimes worse: almost always true or almost always false). These make the code harder to understand because it's not obvious whether the flag is always one value; and the dead code on the never-used side of the conditional contributes to the maintenance burden of making changes.

This accumulation can happen when a feature gets finished, and the flag turned on for everyone, but the flag is never cleaned up from the code. It can also happen when work on a feature stalls, when it's tempting to keep the feature-flag-gated partial implementation around in the code out of hope that it'll get resumed and finished.

So once we have this system, we'll still want to be selective about using it. Most features won't ever use it, even those that take two or three PRs to implement. And when we do use it for a given feature, we'll want to make sure to drive that project to completion so the flag can be eliminated one way or another within a period of a few weeks or months.