Rivet 1 has been retired and will no longer receive updates. The v1 source code has been archived here. Please migrate to Rivet 2 as soon as possible.

Contributing

If you have created a component you think would be useful to others or would like to make a suggestion, let us know.

Github issues

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

Guidelines

Here are a few guidelines to follow when creating a new issue:

  1. Go to the Rivet source repository on GitHub.
  2. Choose the type of issue you would like to create.
  3. Fill out the provided issue template to the best of your ability. If you are submitting a design concept for a new or existing component please attach a screenshot, a link to a mockup, or feel free to link to example HTML/CSS/JavaScript (a link to a pen on Codepen would be great!). We’re looking for anything that will demonstrate your concept here. Don’t worry if it’s unstyled or lacks visual design.
  4. After you have filled out the issue template click the Submit new issue button to create your new issue.
  5. Once the issue is created it will move on to the review process.

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

Collaboration

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.

Content changes

If you are proposing a content change, please include a draft of the text content you’re focusing on.

Proposed Status

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.

Review criteria

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