Browse files

Updating as per Hydra v6.0.0

[ci skip]
  • Loading branch information...
1 parent 1b0f678 commit 1d44e9d16dbcdb7e9e61acb60284fbee9d4f094d @jeremyf jeremyf committed Jul 17, 2013
Showing with 111 additions and 0 deletions.
  1. +111 −0
@@ -0,0 +1,111 @@
+# How to Contribute
+We want your help to make Project Hydra great.
+There are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things.
+## Hydra Project Intellectual Property Licensing and Ownership
+All code contributors must have an Individual Contributor License Agreement (iCLA) on file with the Hydra Project Steering Group.
+If the contributor works for an institution, the institution must have a Corporate Contributor License Agreement (cCLA) on file.
+You should also add yourself to the `` file in the root of the project.
+## Contribution Tasks
+* Reporting Issues
+* Making Changes
+* Submitting Changes
+* Merging Changes
+### Reporting Issues
+* Make sure you have a [GitHub account](
+* Submit a [Github issue](./issues) by:
+ * Clearly describing the issue
+ * Provide a descriptive summary
+ * Explain the expected behavior
+ * Explain the actual behavior
+ * Provide steps to reproduce the actual behavior
+### Making Changes
+* Fork the repository on GitHub
+* Create a topic branch from where you want to base your work.
+ * This is usually the master branch.
+ * To quickly create a topic branch based on master; `git branch fix/master/my_contribution master`
+ * Then checkout the new branch with `git checkout fix/master/my_contribution`.
+ * Please avoid working directly on the `master` branch.
+ * You may find the [hub suite of commands]( helpful
+* Make commits of logical units.
+ * Your commit should include a high level description of your work in HISTORY.textile
+* Check for unnecessary whitespace with `git diff --check` before committing.
+* Make sure your commit messages are [well formed](
+* If you created an issue, you can close it by including "Closes #issue" in your commit message. See [Github's blog post for more details](
+ Present tense short summary (50 characters or less)
+ More detailed description, if necessary. It should be wrapped to 72
+ characters. Try to be as descriptive as you can, even if you think that
+ the commit content is obvious, it may not be obvious to others. You
+ should add such description also if it's already present in bug tracker,
+ it should not be necessary to visit a webpage to check the history.
+ Include Closes #<issue-number> when relavent.
+ Description can have multiple paragraphs and you can use code examples
+ inside, just indent it with 4 spaces:
+ class PostsController
+ def index
+ respond_with Post.limit(10)
+ end
+ end
+ You can also add bullet points:
+ - you can use dashes or asterisks
+ - also, try to indent next line of a point for readability, if it's too
+ long to fit in 72 characters
+* Make sure you have added the necessary tests for your changes.
+* Run _all_ the tests to assure nothing else was accidentally broken.
+* When you are ready to submit a pull request
+### Submitting Changes
+* Read the article ["Using Pull Requests"]( on GitHub.
+* Make sure your branch is up to date with its parent branch (i.e. master)
+ * `git checkout master`
+ * `git pull --rebase`
+ * `git checkout <your-branch>`
+ * `git rebase master`
+ * It is likely a good idea to run your tests again.
+* Squash the commits for your branch into one commit
+ * `git rebase --interactive HEAD~<number-of-commits>` ([See Github help](
+ * To determine the number of commits on your branch: `git log master..<your-branch> --oneline | wc -l`
+ * Squashing your branch's changes into one commit is "good form" and helps the person merging your request to see everything that is going on.
+* Push your changes to a topic branch in your fork of the repository.
+* Submit a pull request from your fork to the project.
+### Merging Changes
+* It is considered "poor from" to merge your own request.
+* Please take the time to review the changes and get a sense of what is being changed. Things to consider:
+ * Does the commit message explain what is going on?
+ * Does the code changes have tests? _Not all changes need new tests, some changes are refactorings_
+ * Does the commit contain more than it should? Are two separate concerns being addressed in one commit?
+ * Did the Travis tests complete successfully?
+* If you are uncertain, bring other contributors into the conversation by creating a comment that includes their @username.
+* If you like the pull request, but want others to chime in, create a +1 comment and tag a user.
+# Additional Resources
+* [General GitHub documentation](
+* [GitHub pull request documentation](
+* [Pro Git]( is both a free and excellent book about Git.
+* [A Git Config for Contributing](

0 comments on commit 1d44e9d

Please sign in to comment.