Comment on page
Thanks for checking out this contibuting guide! We're excited to hear and learn from you. Your experiences will benefit others who read and use these guides.
We've put together the following guidelines to help you figure out where you can best be helpful.
There are many ways you can directly contribute to the guides (in descending order of need):
- Fix editorial inconsistencies or inaccuracies
- Add stories, examples, or anecdotes that help illustrate a point
- Revise language to be more approachable and friendly
Interested in making a contribution? Read on!
Before we get started, here are a few things we expect from you (and that you should expect from others):
- Be kind and thoughtful in your conversations around this project. We all come from different backgrounds and projects, which means we likely have different perspectives on "how open source is done." Try to listen to others rather than convince them that your way is correct.
- If you open a pull request, please ensure that your contribution passes all tests. If there are test failures, you will need to address them before we can merge your contribution.
- When adding content, please consider if it is widely valuable. Please don't add references or links to things you or your employer have created as others will do so if they appreciate it.
If you don't see your idea listed, and you think it fits into the goals of this guide, do one of the following:
- If your contribution is minor, such as a typo fix, open a pull request.
- If your contribution is major, such as a new guide, start by opening an issue first. That way, other people can weigh in on the discussion before you do any work.
Once you have that set up, run:
... and you are good to go on your local machine!
To submit a contribution for review, issue a pull request with comments introducing your contribution. The comment should include a brief overview, responses to checklist questions, and pointers to related information. The entire submittal should ideally be self contained so any additional documentation should be in the pull request as well. Maintaining team will handle the review request, comment on each question and reply to the pull request.
Whenever possible, do not take these conversations to private channels, including contacting the maintainers directly. Keeping communications public means everybody can benefit and learn from the conversations.