The "best" path for enabling core features based in part on device was pretty unclear for moderator tools when we wanted to enable preferences on mobile. We thought making a small change targeting a subset of mobile users to enable preferences on mobile would take a few weeks, but it took us months to sort through. I believe it would help teams make lower risk changes faster if there were a clear way to enable features based on criteria whether core itself understands them or not. Our choices seemed to be:
- implement a separate special preferences page in mobileFrontend, which was a non starter due to the technical debt it would create
- use config, which is where we started, but we received significant pushback and we reverted
- use hooks, which we ended up doing, but now I see the drawbacks to the design
- create our own feature management system, which we were not prepared to do
- try to ride the coattails of another team's feature management system, which were also not sure about
There is clearly a big gap between how users, product managers, and designers wish for us to target features "this thing is a problem on mobile, can we iterate on improvements there?" and how things are actually deployed "the form lives in core, but device awareness lives in an extension, etc." It would be great to reduce that gap so that developers could get features out there, get feedback, and revise faster. I'm sure there was a better way for us to go about this than we did, and I think some kind of standardization (such as what's being discussed in T242835) would have at least helped us get there faster.