Skip to main content

Contribute

If you have created a component you think would be useful to others or would like to make a suggestion, we want to hear from you.

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 for Filing an Issue

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

  1. Go to the WVU Design System source repository on Github .
  2. Click the “Issues” tab.
  3. Click the “New Issue” button.
  4. Fill out the description to the best of your ability. If you are submitting a design concept for a new or existing component please attach a screenshot, 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.
  5. Under “Labels” select “enhancement.”
  6. Under “Assignees” select “Adam Glenn.”
  7. After you have filled out the issue form click the “Submit new issue” button to create your new issue.
  8. Once the issue is created it will move on to the review process.

Guidelines for Creating a Component

The easiest way is to create a component is by using utilities. This way the user can simply copy your HTML code and paste it into their project without having to integrate any Sass into their source files. If you want to make a cu stom pattern using name spaced classes, however, just include a Sass file that includes any custom mixins an d variables. We will include your component in the Components section of this website, including any Sass code.

If you have developed a corresponding CleanSlate partial, we will add it to the WVU Design System Components theme, which users can reference just like any other partial listed on this site (see how to use partials with a custom theme and the Super Theme). Please include any instructions you wish to be included. We recommend using the same variable names and custom data attributes used on other partials where appropriate in order to reduce redundant code. The partial name, along with any configuration options, will be displayed in the component’s implementation notes.

Note: You do not have to create a full-blown shared partial that functions like existing ones. All you need to do is submit the HTML and we will make it work with the system as a shared partial.

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.

Review criteria

Once we have enough info, the team will do a review of the proposed design based on the following criteria:

  • Usability — 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?

If the team decides to not move forward with the design submission, the issue will be marked as archived with an explanation of why.