Skip to main content

Contributing

Thank you for your interest in making this project even better! Your contributions are highly welcomed

The Rootwire OpenDocs 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 and issues, or updating documentation. Most important is your patience and engagement. We are starting a significant journey in the open instead of behind closed doors. Join us and make something great!

Reporting Bugs​

Reporting bugs, issues and errors is one of the best ways to contribute. Before submitting a bug report, please check that an issue reporting the same problem doesn't already exist. If there is 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 where possible. The problem can be solved a lot faster if you do.

Features​

We have a lot of ideas and I'm sure you do too. Please use our issues list to suggest new features and documentation you would like to see added.

Once again, detail wins. Be clear and outcome oriented in your requests - it makes it easier for us to evaluate, prioritise, and get it right.

Contribute to the Repo​

If you could like to contribute either by fixing a bug or adding a feature, please make suer the code change is attached to a prior (or new) issue in the issue list

We will likely reach out to ask questions and discuss approaches. Please understand this is about ensuring that the repo stays easy for everyone to use.

Step 1. Create a fork​

Make a fork and then close the OpenDocs repository. If you need help, you can refer to the GitHub help page

Step 2. Make changes and commit them​

First, make sure git knows your name and email address:

git config --global user.name 'Rick Astley'
git config --global user.email 'Never.gonna@giveyouup.com'

Writing good commit messages is important. A commit message should describe what changed, why, and reference issues fixed. Follow these guidelines when writing one:

  • The first line should be 50 characters or less and contain a short description of the change prefixed with the name of the changed subsystem (e.g. "docs: fix typo in contributing.md").
  • Keep the second line blank.
  • Wrap all other lines at 72 columns.
  • If the change fixes an issue, leave a reference at the end of the commit message (e.g. "Fixes #1234", "Closes #1234", etc).

A good commit message can look like this:

explain commit in one line

Body of commit message is a few lines of text, explaining things
in more detail, possibly giving some background about the issue
being fixed, etc.

The body of the commit message can be several paragraphs, and
please do proper word-wrap and keep columns shorter than about
72 characters or so. That way, `git log` will show things
nicely even when it's indented.

Fixes #1234

Step 3. Test​

Bug fixes and features should have tests. Please validate documentation you submit by following your own instructions and checking that the result is as expected.

Step 4. Submit a Pull Request​

Push your changes to a topic branch in your fork of the repository. Submit a pull request to the OpenDocs repository. Make sure your PR has a clear description of the problem / outcome you are addressing and how you are approaching it.

For help, you can refer to submitting a pull request

Step 5: Connect​

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!