Feature Flags: Notify consumers of available flags

[tay1orjones]

When consumers use a component or feature that has been improved or replaced via a feature flag, we should notify them of the change.

Justification

Notifying consumers of changes to the system in their development environment has many benefits:

• Early access to enhancements, providing their users with a better experience sooner rather than later
• Reduced technical debt, encouraging a controlled, phased transition without the pressure of last minute changes when a flag is turned on by default
• Input on the system, ensuring new features are more tailored to specific needs of consumers' teams and end users
• Lower friction during breaking changes, giving more time and flexibility to test and implement changes before they become mandatory
• Opportunity to innovate, allowing teams to experiment with new capabilities to better solve their product and end user's needs. This encourages a culture of innovation within the ecosystem by leveraging the latest tools before they're fully rolled out.
• Competitive advantage, as features behind flags improve the visual design, accessibility, performance, etc. This ultimately allows teams to give their end users a better experience compared to their competitors.
• Overall alignment with the future of the system, reducing friction and helping teams make more informed choices about their user experience to ensure future compatibility.

Being notified will give teams the knowledge to take advantage of faster iteration, smoother upgrades, and more control over their adoption timeline. Without these messages we risk declining overall product quality by leaving enhancements on the table with little adoption.

Risks

• Notifications will very easily be seen as too noisy. We should really nail down how to not be a nuisance.
• ...