Created UI Toolkit: making and proposing changes (markdown)
parent
6e1a35bd8c
commit
6b6e78a544
13
UI-Toolkit:-making-and-proposing-changes.md
Normal file
13
UI-Toolkit:-making-and-proposing-changes.md
Normal file
@ -0,0 +1,13 @@
|
||||
1. The source of truth for the UI toolkit components is the Joyent Figma team library.
|
||||
**Remember:** Some components might have been updated in the Figma library but not yet moved into the codebase.
|
||||
2. When creating new components, strive to be as modular as possible.
|
||||
3. New components should have a design spec before they are added to the codebase
|
||||
**Remember:** Do not add a new component directly to the codebase.
|
||||
4. Ideally, more than one team member agrees to that the component should be added to the toolkit.
|
||||
**Remember:** Not everything is a component. If a particular element is not yet proven to be useful in multiple places, it should live in the app where it was created.
|
||||
5. When a new component is added to the codebase, it should be added with the appropriate level of documentation. At a minimum, documentation should include all React props with their type and description. Ideally, also include usage guidelines and good practices.
|
||||
6. Variations of the same component should be displayed in different demos in the documentation.
|
||||
7. New and existing components should be reviewed by the team, ideally on a demo link for easier testing (for example, deployed to https://zeit.co/now). Testing should include code, visual and interaction review.
|
||||
8. Requests for new components should be submitted in a GitHub issue. Anyone can submit requests for new components.
|
||||
**Remember:** Both design and engineering work should be outlined in GitHub issues.
|
||||
9. Changes to, and bugs on, existing components should always be requested via, and outlined in, a GitHub issue.
|
Loading…
Reference in New Issue
Block a user