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
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:
- Correct: documentation should be accurate.
- Current: documentation should be up-to-date.
- Consistent: documentation should not conflict with itself.
- 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.
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.
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.
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.