* added documentation on proposed development process

* moved documentation on building to its own document

README.md

@@ -64,41 +64,14 @@ Key Features
  * Retrieval of images from different systems with different protocols via Image Loader plugin design
  * API support for changing viewport properties (e.g. ww/wc, zoom, pan, invert)
 
-Build System
-============
-
-This project uses grunt to build the software.
-
-Pre-requisites:
----------------
-
-NodeJs - [click to visit web site for installation instructions](http://nodejs.org).
-
-grunt-cli
-
-> npm install -g grunt-cli
-
-bower
-
-> npm install -g bower
-
-Common Tasks
-------------
-
-Update dependencies (after each pull):
-> npm install
-
-> bower install
-
-Running the build:
-> grunt
-
-Automatically running the build and unit tests after each source change:
-> grunt watch
 
 Links
 =====
 
+[Development Process](docs/developmentProcess.md)
+
+[Build System](docs/building.md)
+
 [View the wiki for documentation on the concepts and APIs](https://github.com/chafey/cornerstone/wiki)
 
 [View Roadmap](docs/roadmap.md)

docs/building.md

@@ -0,0 +1,31 @@
+Build System
+============
+
+This project uses grunt to build the software.
+
+Pre-requisites:
+---------------
+
+NodeJs - [click to visit web site for installation instructions](http://nodejs.org).
+
+grunt-cli
+
+> npm install -g grunt-cli
+
+bower
+
+> npm install -g bower
+
+Common Tasks
+------------
+
+Update dependencies (after each pull):
+> npm install
+
+> bower install
+
+Running the build:
+> grunt
+
+Automatically running the build and unit tests after each source change:
+> grunt watch

docs/developmentProcess.md

@@ -0,0 +1,52 @@
+Development Process
+===================
+
+NOTE: This document describes the proposed development process for cornerstone and related libraries (e.g. dicomParser).
+Please feel free to post your thoughts and contribute to it.
+
+Principles
+----------
+
+* the 'master' branch is always releasable
+
+* the 'master' branch should never degrade in functionality or quality
+
+Process
+-------
+
+To support the above principles, the following process is followed:
+
+* All work shall be done on feature branches.  A feature branch is a git branch based on the 'master' branch created
+  specifically for a given feature.
+
+* Pull request shall be made for feature branches only.  Pull requests for changes to 'master' or 'dev' branches
+  will be rejected.
+
+* Owners of feature branches are responsible for keeping their feature branch up to date (rebased) with the 'master'
+  branch.
+
+* Once a library maintainer determines a feature branch is of sufficient quality, they shall merge it into the
+  'dev' branch.
+
+* Once a library maintainer determines that the 'dev' branch is ready for testing, an announcement will be made
+  to the cornerstone platform google group asking for volunteers to help test it.
+
+* Once a library maintainer determines that the 'dev' branch has been suitably tested, they will merge it into
+  'master' and post a message on the cornerstone platform forum listing the changes.
+
+* If a regression in functionality or quality is observed in a new release, library maintainers shall work to
+  fix or revert the change as quickly as possible.
+
+
+Quality
+-------
+
+* Unit tests should be provided that exercise most (if not all) code paths
+
+* All unit tests must pass before release
+
+* Test data shall be provided to assist with functional testing
+
+* Code shall pass jshint without generating any warnings
+
+