Skip to content

Latest commit

 

History

History
66 lines (44 loc) · 3.18 KB

CONTRIBUTING.md

File metadata and controls

66 lines (44 loc) · 3.18 KB
Raw

Contributing to vCloud Core

We really welcome contributions.

A quick guide on how to contribute

  1. Clone the repo:

     git clone [email protected]:gds-operations/vcloud-core.git

  2. Run bundle to get the required dependecies

  3. Run the tests. Pull requests that add features must include unit tests, so it is good to ensure you've got them passing to begin with.

     bundle exec rake

    If you have access to a live environment for testing, it would be great if you could run the integration tests too - for more details on the set-up for that, please see the [integration tests README] (https://github.com/gds-operations/vcloud-core/blob/master/spec/integration/README.md)

  4. Add your functionality or bug fix and a test for your change. Only refactoring and documentation changes do not require tests. If the functionality is at all complicated then it is likely that more than one test will be required. If you would like help with writing tests please do ask us.

  5. Make sure all the tests pass, including the integration tests if possible.

  6. Update the CHANGELOG with a short description of what the change is. This may be a feature, a bugfix, or an API change. If your change is documenation or refactoring, you do not need to add a line to the CHANGELOG.

  7. Fork the repo, push to your fork, and submit a pull request.

How soon will we respond?

We will comment on your pull request within two working days. However, we might not be able to review it immediately.

We may come back to you with comments and suggestions, and if we would like you to make changes, we will close the pull request as well as adding details of the changes we'd like you to make.

If you feel your pull request has been outstanding too long, please feel free to bump it by making a comment on it.

Guidelines for making a pull request

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119.

In order for a pull request to be accepted, it MUST

  • Include at least one test (unless it is documentation or refactoring). If you have any questions about how to write tests, please ask us, we will be happy to help
  • Follow our Git style guide
  • Include a clear summary in the pull request comments as to what the change is and why you are making it
  • Be readable - we might ask you to change unclear variable names or obscure syntactic sugar
  • Have good commit messages that explain the change being made in that commit. Don't be afraid to write a lot in the detail.

In order for a pull request to be accepted, it SHOULD