From 6b6e78a54428141da45d580cdf0ffe6a532d2d0d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Inayaili=20de=20Le=C3=B3n=20Persson?= Date: Thu, 12 Oct 2017 09:32:22 +0100 Subject: [PATCH] Created UI Toolkit: making and proposing changes (markdown) --- UI-Toolkit:-making-and-proposing-changes.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 UI-Toolkit:-making-and-proposing-changes.md diff --git a/UI-Toolkit:-making-and-proposing-changes.md b/UI-Toolkit:-making-and-proposing-changes.md new file mode 100644 index 0000000..6c61483 --- /dev/null +++ b/UI-Toolkit:-making-and-proposing-changes.md @@ -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.