Skip to content

Latest commit

 

History

History
77 lines (56 loc) · 4.98 KB

CONTRIBUTING.md

File metadata and controls

77 lines (56 loc) · 4.98 KB
Raw

Contributing to Draft U.S. Web Design Standards Documentation

We’re so glad you’re thinking about contributing to an 18F open source project! If you’re unsure about anything, just ask (or submit your issue or pull request anyway). The worst that can happen is we’ll politely ask you to change something. We appreciate all friendly contributions.

One of our goals is to ensure a welcoming environment for all contibutors to our projects. Our staff follows the 18F Code of Conduct, and all contributors should do the same.

We encourage you to read this project’s CONTRIBUTING policy (you are here), its LICENSE, README and its Workflow process.

If you have any questions or want to read more, check out the 18F Open Source Policy GitHub repository, or just shoot us an email.

Issues and labels

To help us get a better understanding of the issue you’re submitting, follow our ISSUE TEMPLATE and the guidelines it describes in the template.

Also, here are some definitions around the labels we use to help us organize our issues:

Category

  • Accessibility
  • Content Design
  • DevOps
  • Documentation
  • Engineering
  • Front end
  • User Experience
  • Visual Design

Work Status

  • Abandoned: Contributor no longer responsive in correspondence.
  • Accepted: Reviewed and approved by core teammate and included on product roadmap.
  • Backlog: A build up of work that’s been initially reviewed and correlating labels applied. It needs to be reviewed before moving to “Accepted”.
  • Blocked: Not able to move forward with work due to conflict.
  • Completed: Merged in and closed.
  • Help wanted: Contributors open to claiming and tackling. Description and acceptance criteria have been written.
  • Idea: New idea or request; team has yet to evaluate.
  • In progress: Work that has been assigned and is currently being worked on.
  • Need more info: There is not enough information in order to move forward. A team member may request more information from the submitter or do some research to find the necessary information.
  • On Hold: Work is currently paused (or not able to move forward) due to conflict.
  • Review needed: Pull request review needed.
  • Revisions needed: Requires corrections based on team feedback.

Priority

  • Blocker: Needs immediate attention. Prevents the product from working if it were released in that state. (For example: build failing, tests not passing)
  • Critical: A critical requirement without which it is unacceptable to stakeholders. Impacts the application’s functionality. (For example: feature not working in all browsers, content not accessible to screen readers)
  • Major: A necessary but deferrable requirement that makes the product less usable but still functional. Does not impact the application’s functionality. (For example: typos)
  • Minor: A nice feature to have if there are resources, but the product functions well without it. Also known as “could be betters.” (For example: feature requests, cosmetic enhancements)

Type

  • Bug: Error, failure, or flaw in the product.
  • Enhancement: Modification of product to enhance performance or correct faults for items that already exist.
  • Maintenance: Fixing product defects.
  • Question: An inquiry asking for more information.
  • New: A completely new, discrete unit added to the package.

Pull requests

Here are a few guidelines to follow when submitting a pull request:

  1. Create a GitHub account or sign in to your existing account.
  2. Fork this repo into your GitHub account (or just clone it if you’re an 18F team member). Read more about forking a repo here on GitHub: https://help.github.com/articles/fork-a-repo/
  3. Create a branch from staging that lightly defines what you’re working on (for example, add-styles).
  4. Once you’re ready to submit a pull request, fill out the PULL REQUEST TEMPLATE provided.
  5. Submit your pull request against the staging branch.

Have questions or need help with setup? Open an issue here https://github.com/18F/web-design-standards-docs/issues.

Coding guidelines

CSS

The purpose of the CSS coding styleguide is to create consistent CSS or preprocessor CSS code across 18F. The styleguide should be treated as a guide — rules can be modified according to project needs.

This project follows the 18F Front End Guide - CSS. Please use this guide for your reference, as well as running npm run lint to check for consistency.

JavaScript

This project follows the 18F Front End Guide - JavaScript. Please use this guide for your reference, as well as running npm run lint to check for consistency.