CONTRIBUTING.md

Contributing to vCloud Edge Gateway

We now consider vCloud Tools feature complete for our purposes. We'd be happy to consider pull requests for new features but please discuss them with us in the issues first so we can let you know if it's something we'd be likely to merge. We will continue to make maintenance and bug fixes.

A quick guide on how to contribute

1. Clone the repo:

    git clone git@github.com:gds-operations/vcloud-edge_gateway.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-edge_gateway/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 issue as soon as we can. If you feel your issue is important, please feel free to bump it by making a comment on it or raise your issue on the mailing list.

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

• Include a line in the CHANGELOG unless it is a refactoring or documentation change
• If it is code, follow our Ruby style guide
• If it is documentation, follow the GDS content style guide