Comment by svieira
This is all excellent, and I'll add one more sub point to "Avoid becoming a bottleneck at all costs":
- Be backwards compatible. If you need to break backwards compatibility, advertise it widely and put your people towards the migration. Otherwise, only expand the abilities of components, never remove them and only require less, never require more. If you want to remove from what you give or ask for more than you currently require then make a new version of the component (e. g. `components/Button/v2`). Plan for this (e. g. don't ship `components/Button`, ship `components/Button/v1`). Rich Hickey's Spec-ulation talk goes into the principles in some more detail: https://www.youtube.com/watch?v=oyLBGkS5ICk
The reason for this is because your goal is to empower other teams to move faster. The minute that "keeping up to date with the UI library" requires any significant amount of attention you are draining any velocity you added. People will stop (either by not updating or by moving off the library).
> The minute that "keeping up to date with the UI library" requires any significant amount of attention you are draining any velocity you added.
Adding to this: consider that not everyone is reading your release notes weekly or even monthly, and might be coming back to work on something that's been shelved for months.
Having a "breaking changes" page in your docs is incredibly useful when someone is faced with upgrading a project that uses eg v1.1 when your current release is v3.5, as they can quickly find the things that need to change without having to read through 17 pages of release notes.
"Component X was removed in version 3.0, use y or z instead"
"v2.0 changed how configuration works. Instead of always reading the file config.json, there are now several ways to configure, see docs [here]. You can keep using the old file by adding the code: Config.ReadFile('config.json')."