merge Development.md and Contributing.md

Author: colinta

Contributing.md

@@ -1,7 +1,30 @@
-# Community Continuity Guidelines v2.0.0
+# Community Contribution Guidelines v2.0.0
 
 As the creators, and maintainers of this project, we want to ensure that the project lives and continues to grow. Not blocked by any singular person's computer time. One of the simplest ways of doing this is by encouraging a larger set of shallow contributors. Through this, we hope to mitigate the problems of a project that needs updates but there's no-one who has the power to do so.
 
+#### Development Process
+
+We maintain two permanent, protected branches: `master` and `develop`.
+
+`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.
+
+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.
+
+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.
+
+#### Testing
+
+To run tests locally, you will need to download Moya's dependencies.
+To do so, run `carthage update --platform iOS` and take a nap, waiting for it to
+finish. 😴
+
+If you don't have Carthage installed, check the [installation instructions](https://github.com/Carthage/Carthage#installing-carthage).
+And, of course, don't forget to run `carthage update --platform iOS` after.
+
+Afer that, you can open `Moya.xcodeproj` and hit ⌘+U to start testing.
+
 #### Ownership
 
 If you get a merged Pull Request, regardless of content (typos, code, doc fixes), then you're eligible for push access to this organization. This is checked for on pull request merges and an invite to the organization is sent via GitHub.
@@ -18,18 +41,6 @@ As an organization contributor, you can merge other people's pull requests, or o
 
 This project is not continuously deployed, there is space for debate after review too. Offering everyone the chance to revert, or make an amending pull request. If it feels right, merge.
 
-#### Bug fixes and Release cycles
-
-We maintain two major branches: `master` and `develop`.
-
-`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.
-
-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.
-
-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.
-
 #### How can we help you get comfortable contributing?
 
 It's normal for a first pull request to be a potential fix for a problem, and moving on from there to helping the project's direction can be difficult. We try to help contributors cross that barrier by offering good first step issues. These issues can be fixed without feeling like you're stepping on toes. Ideally, these are non-critical issues that are well defined. They will be purposely avoided by mature contributors to the project, to make space for others.