Contributing to vCloud Core
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.
Issues we know about are listed here. We have a
newcomer-friendly label for issues that we feel would be a good place to start, because they do not touch a lot of other vCloud Tools code and do not require an environment to work on. This label is just a suggestion.
A quick guide on how to contribute
Clone the repo:
git clone email@example.com:gds-operations/vcloud-core.git
bundleto get the required dependecies
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)
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.
Make sure all the tests pass, including the integration tests if possible.
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.
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.