Here are some ways you can contribute to the design system.
If you find a bug in the design system, please create a Github issue.
Have a proposal for a new component or enhancement to an existing component? Present your idea in our bi-weekly Design System meetup or create an issue that details your use case and attach designs or code.
There’s a lot of code that has been written, and there’s even more left to write. It’ll be satisfying to take a look at the final product and know that you made your mark on it. Help as big as new components or as small as a typo fix in the docs is helpful and wanted. Become familiar with our Contribute Code guide, and push some bits.
When you go to add code to the Design System, consider these few requirements first.
Follow pre-existing conventions. We want to make it easy to move between packages in the Design System, and following precedent will help packages feel similar. We value innovation to complete new tasks or advance the overall quality of the Design System.
Test your code. Extract important logic and use unit tests to exercise it. Use snapshot tests to record healthy UI states. Use the Design System Reference Site and/or a tool like Storybook to provide a quick-feedback visual environment for developing components.
Use the Design System to build the Design System where possible (ie, especially use Core when building Components).
For some specifics on coding new component, please see the Step-by-step Components doc.
PRs are the main mode of adding or changing code in the Design System. Use the Github pull request template when submitting a pull request. The template prompts for context and reasoning around the submission.
Every code submission requires a review by the Design System team. Be used to multiple iterations of feedback in a PR. We'll ask questions back and forth of each other. If you have other people with relevant insights from other teams, please invite them to review your code as well.
When a PR is submitted, we will insert its review into our pre-existing priority queue of work. We will notify you via Github when we intend to finish the review. We will complete the first review within a max of 7 days of your PR being submitted, usually less.
New designs are potentially reviewed by the entire design group. The PR must be merged by the Design System team. Any other people with helpful insight are welcome to offer their feedback in a review.
When your PR is merged, the Design System team will publish new versions of affected packages. Please use the new packages as soon as convenient, and try them out in real world situations. Stay in touch and work out adjustments that need to be made either through new PRs or requests for assistance.
It worked! Let’s do that again.