We, at Kaleyra Designs, currently follow Ship-Show-AskShip-Show-Ask
Ship/Show/Ask is a branching strategy that combines the features of Pull Requests with the option to continue shipping changes. There are three categories of changes in this method. They are Ship ... format for Design System Branching. We keep Decision Documentation for CommunicationDecision Documentation for Communication
For long term projects, without customer level 'release', (Eg While Implimenting a design System) it is good to have a time based change log. Figma version control is not that efficient It ..., and use Changelog as a consistent communication toolChangelog as a consistent communication tool
Changelogs are a great way of effective communication. It provides a clear idea on what is done, and why it's done. Also, it communicates to the user about the value the new feature adds / problem ....
For Ship, designer directly merge it to design system, and take care of feedbacks. If it's more complicated, the change will be added (and show) as a variant, and will clean up as we have more clarity. If the sophistication and impacts are high, we save it a s a new component, and discuss it in our bi-weekly 'Ask' meetings.
Source
- Ship-Show-AskShip-Show-Ask
Ship/Show/Ask is a branching strategy that combines the features of Pull Requests with the option to continue shipping changes. There are three categories of changes in this method. They are Ship ...