Thank you for your interest in making this project even better and more awesome. Your contributions are highly welcomed.
The Sauce Labs
sauce-docs repo is an Open Source project. We are excited to engage with you
and the community.
Contribution can come in many forms; writing examples, making suggestions, pointing out bugs, or updating docs. Most important is your patience and engagement. We are starting a significant journey in the open instead of behind closed doors. Join us to make something great.
Reporting bugs is one of the best ways to contribute. Before creating a bug report, please check that an issue reporting the same problem does not already exist. If there is an such an issue, you may add your information as a comment.
Feel free to start here. Please fill out the required information, be clear, specific, and add working examples of the problems you are seeing. The problem will be resolved a lot faster if you do
We have a lot of ideas and I'm sure you do too. Please use our issues list to suggest new features that you would like to see added.
Once again, detail wins. Be clear and outcome oriented in your requests - it just makes it easier for us to evaluate and prioritize.
If you would like to contribute either by fixing a bug or adding a feature, please make sure it the code change is attached to a prior (or new) issue in the issues list.
We will likely reach out to you to ask questions and discuss approaches. Please understand this is about ensuring that the repo stays easy for everyone to use.
First make sure git knows your name and email address:
Writing good commit messages is important. A commit message should describe what changed, why, and reference issues fixed (if any). Follow these guidelines when writing one:
- The first line should be around 50 characters or less and contain a short description of the change.
- Keep the second line blank.
- Wrap all other lines at 72 columns.
Fixes #N, where N is the issue number the commit fixes, if any.
A good commit message can look like this:
The first line must be meaningful as it's what people see when they
git shortlog or
git log --oneline.
Bug fixes and features should have tests. Look at other tests to see how they should be structured.
Commit your changes to your fork and then create and submit a PR to
Make sure your PR has a clear description of the problem/outcome you are addressing
and how you are approaching it. There is a template that simplifies this procss.
For help, you can refer to submitting a pull request.
We will reach out to ask any questions or make suggestions. Once done, we will merge the change and... congratulations! You've contributed to improving digital confidence!
Have fun and enjoy hacking!