Skip to content

Latest commit

 

History

History
69 lines (49 loc) · 2.95 KB

CONTRIBUTING.md

File metadata and controls

69 lines (49 loc) · 2.95 KB
Raw

Thank you for your interest in contributing to the CircleCI documentation.

As of March 2017, we are currently focusing on creating new documentation for CircleCI 2.0. Documentation for 1.0 will continue to be improved, but will go into maintenance mode in the coming months. If you're considering contributing a completely new article, we encourage you to contribute to the 2.0 documentation found at https://circleci.com/docs/2.0/ or in this repo in /jekyll/_cci2/.

CircleCI Documentation Values

There is never enough time to do everything we want to do. That's why we prioritize issues according to the following four categories, in decreasing importance:

  1. Correct: documentation should be accurate.
  2. Current: documentation should be up-to-date.
  3. Consistent: documentation should not conflict with itself.
  4. Clear: documentation should be clear.

These values apply to both new and existing documentation.

Contributing to CircleCI Docs

We welcome all contributions to CircleCI documentation. These contributions come in two forms: issues and pull requests.

Issues

If you spot anything that conflicts with our values, opening a GitHub Issue is a great way to give us specific feedback.

To make an issue, refer to the GitHub Issues Workflow wiki page.

Pull Requests

If you feel motivated, you can make documentation changes and submit a pull request.

For minor changes like typos, click "Suggest an edit to this page", located at the bottom of each document. This will take you to the source file on GitHub, where you can submit a pull request for your changes.

For larger edits or new documents, set up a local environment. When you are satisfied with your changes, create a pull request from your branch by following GitHub's guide.

Regardless of the size of your change, do read through our Style Guide.

Titles and Descriptions

Pull request titles should be descriptive enough for reviewers to understand what is being changed. Some ways of doing this are better than others:

Original Pull Request Title Better Title
Updating file.md Indicate support for environment variables in context paths
Sidebar changes Move Deployment to its own navigation section for better organization

Every pull request should have a description that explains why the change is being made. The description adds context that is critical for reviewers when giving feedback.

For more tips, see GitHub's blog entry on how to write the perfect pull request.