develop -> development

Author: sunshinejr

Contributing.md

@@ -4,15 +4,15 @@ As the creators, and maintainers of this project, we want to ensure that the pro
 
 #### Development Process
 
-We maintain two permanent, protected branches: `master` and `develop`.
+We maintain two permanent, protected branches: `master` and `development`.
 
 `master` is for working on the current release, so any bug fixes or documentation spelling fixes should be merged into this branch.
 
-`develop` is where we stage work for the *next* release, i.e. breaking API changes and related documentation updates. Contributors should gently encourage new pull-requests to point to the appropriate branch, and to rebase onto that branch if necessary.
+`development` is where we stage work for the *next* release, i.e. breaking API changes and related documentation updates. Contributors should gently encourage new pull-requests to point to the appropriate branch, and to rebase onto that branch if necessary.
 
-When a new version is ready to be released, please create a pull request to merge `develop` into `master`, named something like "Release 10.0". Then we can have some final discussion before we merge it into `master` and push the release out to the public.
+When a new version is ready to be released, please create a pull request to merge `development` into `master`, named something like "Release 10.0". Then we can have some final discussion before we merge it into `master` and push the release out to the public.
 
-Since `develop` is a *shared* branch, it is important not to ever rebase this branch onto `master`. If a bug fix is applied to `master` it can be merged into `develop` using good old simple `git checkout develop && git merge master`. Yes this will clutter the history a little bit, but it also provides important context to know how/when a patch was applied. Merge commits can be considered necessary historical data, not warts on an idealized history graph.
+Since `development` is a *shared* branch, it is important not to ever rebase this branch onto `master`. If a bug fix is applied to `master` it can be merged into `development` using good old simple `git checkout development && git merge master`. Yes this will clutter the history a little bit, but it also provides important context to know how/when a patch was applied. Merge commits can be considered necessary historical data, not warts on an idealized history graph.
 
 #### Testing