5 files changed, 107 insertions, 0 deletions
diff --git a/doc/development/NEW_FEATURES.md b/doc/development/NEW_FEATURES.md
new file mode 100644
index 00000000..9688ef8a
--- /dev/null
+++ b/doc/development/NEW_FEATURES.md
@@ -0,0 +1,10 @@
+# Adding New Features
+
+If you would like to add a new feature to Bundler, please follow these steps:
+
+  1. [Create an issue](https://github.com/bundler/bundler/issues/new) with the [`feature-request` label](https://github.com/bundler/bundler/labels/type:%20feature-request) to discuss your feature.
+  2. Base your commits on the master branch, since we follow [SemVer](http://semver.org) and don't add new features to old releases.
+  3. Commit the code and at least one test covering your changes to a feature branch in your fork.
+  4. Send us a [pull request](PULL_REQUESTS.md) from your feature branch.
+
+If you don't hear back immediately, don’t get discouraged! We all have day jobs, but we respond to most tickets within a day or two.
diff --git a/doc/development/PULL_REQUESTS.md b/doc/development/PULL_REQUESTS.md
new file mode 100644
index 00000000..37129f8e
--- /dev/null
+++ b/doc/development/PULL_REQUESTS.md
@@ -0,0 +1,40 @@
+# Submitting Pull Requests
+
+Before you submit a pull request, please remember to do the following:
+
+1. Check your code format and style
+2. Run the test suite
+3. Use a meaningful commit message without tags
+
+## Code formatting
+
+Make sure the code formatting and styling adheres to the guidelines. We use Rubocop for this. Lack of formatting adherence will result in automatic Travis build failures.
+
+      $ bin/rubocop -a
+
+## Tests
+
+Prior to submitting your PR, please run the test suite:
+
+      $ bin/rspec
+
+If you are unable to run the entire test suite, please run the unit test suite and at least the integration specs related to the command or domain of Bundler that your code changes relate to.
+
+Ex. For a pull request that changes something with `bundle update`, you might run:
+
+      $ bin/rspec spec/bundler
+      $ bin/rspec spec/commands/update_spec.rb
+
+## Commit messages
+
+Please ensure that the commit messages included in the pull request __do not__ have the following:
+  - `@tag` Github user or team references (ex. `@indirect` or `@bundler/core`)
+  - `#id` references to issues or pull requests (ex. `#43` or `bundler/bundler-site#12`)
+
+If you want to use these mechanisms, please instead include them in the pull request description. This prevents multiple notifications or references being created on commit rebases or pull request/branch force pushes.
+
+Additionally, do not use `[ci skip]` or `[skip ci]` mechanisms in your pull request titles/descriptions or commit messages. Every potential commit and pull request should run through Bundler's CI system. This applies to all changes/commits (ex. even a change to just documentation or the removal of a comment).
+
+## CHANGELOG.md
+
+Don't forget to add your changes into the CHANGELOG! If you're submitting documentation, note the changes under the "Documentation" heading.
diff --git a/doc/development/README.md b/doc/development/README.md
new file mode 100644
index 00000000..3d100624
--- /dev/null
+++ b/doc/development/README.md
@@ -0,0 +1,19 @@
+# Development
+
+So, you're ready to start contributing to Bundler! You've come to the right place. Here you'll find an overview of how to work on Bundler locally and a description of the process from code to release.
+
+##[Development setup](development/SETUP.md)
+
+Guidelines for setting up your local development environment.
+
+##[Submitting pull requests](development/PULL_REQUESTS.md)
+
+An overview of our preferred PR process, including how to run the test suite and what to expect when you submit code for review.
+
+##[Adding new features](development/NEW_FEATURES.md)
+
+Guidelines for proposing and writing new features for Bundler.
+
+##[Releasing Bundler](development/RELEASING.md)
+
+A broad-strokes overview of the release process adhered to by the Bundler core team.
diff --git a/doc/development/RELEASING.md b/doc/development/RELEASING.md
new file mode 100644
index 00000000..eb496470
--- /dev/null
+++ b/doc/development/RELEASING.md
@@ -0,0 +1,9 @@
+# Releasing
+
+_Release process documentation is in progress, see [PR 5252](https://github.com/bundler/bundler/pull/5252)._
+
+## Beta testing
+
+Early releases require heavy testing, especially across various system setups. We :heart: testers, and are big fans of anyone who can run `gem install bundler --pre` and try out upcoming releases in their development and staging environments.
+
+There may not always be prereleases or beta versions of Bundler. The Bundler team will tweet from the [@bundlerio account](http://twitter.com/bundlerio) when a prerelease or beta version becomes available. You are also always welcome to try checking out master and building a gem yourself if you want to try out the latest changes.
diff --git a/doc/development/SETUP.md b/doc/development/SETUP.md
new file mode 100644
index 00000000..10f8dd30
--- /dev/null
+++ b/doc/development/SETUP.md
@@ -0,0 +1,29 @@
+# Development setup
+
+Bundler doesn't use a Gemfile to list development dependencies, because when we tried it we couldn't tell if we were awake or it was just another level of dreams. To work on Bundler, you'll probably want to do a couple of things.
+
+1. Install `groff-base` and `graphviz` packages using your package manager, e.g for ubuntu
+
+      $ sudo apt-get install graphviz groff-base -y
+
+   and for OS X (with brew installed)
+
+      $ brew install graphviz homebrew/dupes/groff
+
+2. Install Bundler's development dependencies
+
+      $ bin/rake spec:deps
+
+3. Run the test suite, to make sure things are working
+
+      $ bin/rake spec
+
+4. Set up a shell alias to run Bundler from your clone, e.g. a Bash alias:
+
+      $ alias dbundle='BUNDLE_TRAMPOLINE_DISABLE=1 ruby -I /path/to/bundler/lib /path/to/bundler/exe/bundle'
+
+   The `BUNDLE_TRAMPOLINE_DISABLE` environment variable ensures that the version of Bundler in `/path/to/bundler/lib` will be used. Without that environment setting, Bundler will automatically download, install, and run the version of Bundler listed in `Gemfile.lock`. With that set up, you can test changes you've made to Bundler by running `dbundle`, without interfering with the regular `bundle` command.
+
+## Debugging with `pry`
+
+To dive into the code with Pry: `RUBYOPT=-rpry dbundle` to require pry and then run commands.