If you have created a component you think would be useful to others or would like to make a suggestion, let us know.
We’ll be using Github issues to keep track of new component submissions, bugs, design feedback, and any other suggestions related to the design system. To help us understand the kind of contribution you want to make, we ask that you first submit an issue on GitHub.Create an issue
Here are a few guidelines to follow when creating a new issue:
- Go to the Rivet source repository on GitHub.
- Click the “New Issue” button.
- After you have filled out the issue template click the Submit new issue button to create your new issue.
- Once the issue is created it will move on to the review process.
Creating an issue is just a way to start a conversation that is visible to the whole team. Anyone should feel free to create a new issue, but before a new submission moves on to a formal review process we’ll ask that each one includes:
- a fairly short descriptive title
- what will be gained by adding this design and will be lost if we don’t?
- a description of the design problem this component solves
- at least one of the following: screenshots/images of your rendered design, wireframes, design mockups, links to Codepen, jsFiddle, etc., Axure mockups, iPhone photo of a napkin sketch.
- NOTE: If applicable, this should include a documented interaction flow, eg. states (hover, focus, click, drag…), error and success messages, etc.
- any other document, links, research you would like to include
- context (screenshots, links) if you have a specific use case for a proposed solution
If you are a developer and want help with your submission from a designer, make sure to mention that when creating your issue and someone from the review team will help pair you up with a designer. Same goes for designers that want help from a developer.
If you are proposing a content change, please include a draft of the text content you’re focusing on.
After the Github issue is created and the submission has enough information and supporting materials (i.e., the issue template is completely filled out), someone from the team will mark the issue as Proposed. Otherwise, someone from the team will ask the submitter for further information/documentation and mark the issue as needs more info.
Once they have enough info, the team will do a review of the proposed design based on the following criteria:
- Usability — Is the interaction flow clearly documented? Is the pattern responsive? Does it follow commonly accepted best practices?
- Flexibility — Does the component meet the greatest number of use cases possible? In other words, is this a common pattern that occurs in lots of applications, or it solving a particular problem in one application?
- Accessibility — Is the pattern accessible to all intended audiences?
- Visual design — Is the contribution consistent with our visual style?
- Content — Does the pattern have plain language, correct spelling, and grammar? Does the author clearly describe actions?
If the team decides to not move forward with the design submission, the issue will be marked as archived with an explanation of why.
On this page