Adding branch description to Contributing (#2256)

* Adding branch description

* Adding spaces

* Adding timeline

Author: josenavas

CONTRIBUTING.md

@@ -1,10 +1,10 @@
-#Contributing to Qiita
+# Contributing to Qiita
 
 Qiita is an open source software package, and we welcome community contributions. You can find the source code and test code for Qiita under public revision control in the Qiita git repository on [GitHub](http://github.com/biocore/qiita). We very much welcome contributions.
 
 This document covers what you should do to get started with contributing to Qiita. You should read this whole document before considering submitting code to Qiita. This will save time for both you and the Qiita developers.
 
-#General Notes on Development
+# General Notes on Development
 
 Adding source code to Qiita, can take place in three different modules:
 
@@ -17,7 +17,15 @@ always take into consideration how these new features affect users and whether
 or not adding a new section or document to the documentation (found under the
 `doc` folder) would be useful.
 
-###The Qiita development rules
+### Repository branch structure
+
+The Qiita repository contains three branches:
+
+* `master`: This branch reflects the code deployed in our [main Qiita server](http://qiita.microbio.me).
+* `dev`: This branch is the active development branch. All new Pull Requests should be performed against this branch.
+* `release-candidate`: This branch is used to freeze the code from the `dev` branch, so we can deploy in our test servers and exercise the code extensively before deploying in our main system. Code freezes typically occur one week before the scheduled deployment. Check our [milestones page](https://github.com/biocore/qiita/milestones) to see the scheduled deployments.
+
+### The Qiita development rules
 
 Since Qiita is a package that is continuously growing, we found ourselves in a position where development rules needed to be established so we can reduce both development and reviewer time. These rules are:
 
@@ -46,7 +54,7 @@ Since Qiita is a package that is continuously growing, we found ourselves in a p
 9. Last but not least, you are working as part of a team and you should try to help others when possible.
 
 
-###Configuration file
+### Configuration file
 
 The Qiita configuration file determines how the package interacts with your system’s resources (redis, postgres and the IPython cluster). Thus you should review the documentation detailed [here](https://docs.google.com/document/d/1u7kwLP31NM513-8xwpwvLbSQxYu0ehI6Jau1APR13e0/edit#), but especially bear in mind the following points:
 
@@ -55,21 +63,21 @@ The Qiita configuration file determines how the package interacts with your syst
 
 **A note on data accumulation**: Qiita keeps data in the `BASE_DATA_DIR` as the system gets used. When you drop a Qiita environment and create a fresh testing environment, the “old” data that was generated from the previous environment should be **manually** deleted (or, at least, removed from the data directories in the `BASE_DATA_DIR`).
 
-###Unit tests
+### Unit tests
 
 Unit tests in Qiita are located inside the tests/test folder of every sub-module, for example `qiita_db/test/test_metadata_template.py`. These can be executed on a per-file basis or using `nosetests` from the base directory.
 
 During test creation make sure the test class is decorated with `@qiita_test_checker()` if database modifications are done during tests. This will automatically drop and rebuild the qiita schema after the entire test class has been executed. This requires to all the tests in a single class be independent of each other, so stochastic failures do not occur due to different test order execution.
 
 Coverage testing is in effect, so run tests using `nosetests --with-coverage [test_file.py]` to check what lines of new code in your pull request are not tested.
 
-###Documentation
+### Documentation
 
 The documentation for Qiita is maintained as part of this repository, under the
 `qiita_pet/support_files/doc` folder, for more information, see the README.md
 file in `qiita_pet/support_files/doc/README.md`.
 
-###Scripts
+### Scripts
 
 Scripts in Qiita are located inside the scripts directory, their actions will rely on the settings described in the Qiita config file, for example if you are dropping a database, the database that will be dropped is the one described by the `DATABASE` setting. The following is a list of the most commonly used commands during development:
 
@@ -79,16 +87,16 @@ Scripts in Qiita are located inside the scripts directory, their actions will re
 * `qiita-env stop_cluster qiita-general`, terminates a cluster named ‘qiita-general’.
 * `qiita pet webserver start`, will start the Qiita web-application running on port 21174, you can change this using the `--port` flag, for example `--port=7532`.
 
-##Making Database Changes
+## Making Database Changes
 After the initial production release of Qiita, changes to the database schema will require patches; the database can no longer be dropped and recreated using the most recent schema because all the data would be lost! Therefore, patches must be applied instead.
 
-###Approach
+### Approach
 
 1. We keep "unpatched" versions of the SQL and DBS files in the repository
 2. We keep fully patched versions of the DBS and HTML files in the repository
 3. We keep a patch file for each patch as required in the `qiita_db/support_files/patches` directory. Note that **the patches will be applied in order based on the natural sort order of their filename** (e.g., `2.sql` will be applied before `10.sql`, and `10.sql` will be applied before `a.sql`)
 
-###Developer Workflow
+### Developer Workflow
 
 1. Load the fully patched DBS file (e.g., `qiita-db.dbs`) in [DBSchema](http://www.dbschema.com/)
 2. Make desired changes
@@ -101,17 +109,17 @@ After the initial production release of Qiita, changes to the database schema wi
 
 One drawback is that developers will need to have [DBSchema](http://www.dbschema.com/) to develop for this project.
 
-###Data Patches
+### Data Patches
 
 If you need to submit a patch that changes only data but does not alter the schema, you should still create a patch file with the next name (e.g., `2.sql`) with your changes. Note that a patch should *not* be created if the modifications do not apply to Qiita databases in general; data patches are only necessary in some cases, e.g., if the terms in an ontology change.
 
-###Python Patches
+### Python Patches
 
 Occasionally, SQL alone cannot effect the desired changes, and a corresponding python script must be run after the SQL patch is applied. If this is the case, a python file should be created in the `patches/python_patches` directory, and it should have the same basename as the SQL file. For example, if there is a patch `4.sql` in the `patches` directory, and this patch requires a python script be run after the SQL is applied, then the python file should be placed at `patches/python_patches/4.py`. Note that not every SQL patch will have a corresponding python patch, but every python patch will have a corresponding SQL patch.
 
 If in the future we discover a use-case where a python patch must be applied for which there *is no corresponding SQL patch*, then a blank SQL patch file will still need to be created.
 
-##SQL coding guidelines
+## SQL coding guidelines
 Since the `qiita_db` code contains a mixture of python code and SQL code, here are some coding guidelines to add SQL code to Qiita:
 
 1. Any SQL keyword should be written uppercased: