Contributing

Please start a contribution by filing an issue. Doing so will help start communication, to ensure that the contribution is not already being worked on and that it will fit into the project.

1. Fork it ( https://github.com/vagrant-smartos/vagrant-smartos-zones/fork )
2. Create your feature branch (git checkout -b my-new-feature)
3. Commit your changes (git commit -am 'Add some feature')
4. Push to the branch (git push origin my-new-feature)
5. Create new Pull Request

Thank you!

You are a fantastic individual and you have done us a great favor by contributing new functionality.

Hopefully we will be able to merge your pull request post-haste. If none of us is available to do so, please accept our apologies, and feel free to remind us by commenting on issue after a week or two. If for some reason your pull request is not considered merge-able, we'll use the comments on the pull request to communicate why, and decide on the next course of action.

Versioning

Please do not increment the plugin version as a part of any contribution. Versioning will be done by one of the core project maintainers, after pull requests are merged.

Incrementing the version as a part of the pull request complicates the merging process, as your new version may conflict with other changes made before your contribution can be managed. In addition, the release schedule will be managed by the core project maintainers and is not directly tied to individual pull requests.

Merge commits vs Fast Forward

Pull requests should be able to be merged with a git fast-forward. What this means is that if new commits are made/merged into origin/master before you are able to submit a pull request, you should:

1. git rebase origin/master into your branch
2. git push --force your-fork your-branch

If the project maintainers are unable to address your PR in a timely manner (we all have very busy personal and professional lives), we will do our best to rebase your pull request in the event that other commits make their way onto master. We may ask you to rebase again, however.

Pull request vs committing to master

Individuals with read/write access to origin master should take it under their own advisement whether to commit to a branch and issue a pull request, or whether to commit directly on master.

Everything pushed to master should leave the project in a functioning state. If something is a work-in-progress, please either use a branch, or ensure that your commits don't break core functionality (optional code paths not executed by default, for instance).