Update README

README.rst

@@ -44,8 +44,8 @@ look like the following.
   provider = CloudProviderFactory().create_provider(ProviderList.AWS, {})
   print(provider.security.key_pairs.list())
 
-In the example above, the AWS_ACCESS_KEY and AWS_SECRET_KEY environment variables
-must be set to your AWS credentials.
+In the example above, the AWS_ACCESS_KEY and AWS_SECRET_KEY environment
+variables must be set to your AWS credentials.
 
 
 Documentation
@@ -56,13 +56,27 @@ Documentation can be found at https://cloudbridge.readthedocs.org.
 Design Goals
 ~~~~~~~~~~~~
 
-1. Create a cloud abstraction layer which minimises or eliminates the need for cloud specific special casing (i.e., Not require clients to write ``if EC2 do x else if OPENSTACK do y``.)
+1. Create a cloud abstraction layer which minimises or eliminates the need for
+cloud specific special casing (i.e., Not require clients to write ``if EC2 do x
+else if OPENSTACK do y``.)
 
-2. Have a suite of conformance tests which are comprehensive enough that goal 1 can be achieved. This would also mean that clients need not manually test against each provider to make sure their application is compatible.
+2. Have a suite of conformance tests which are comprehensive enough that goal 1
+can be achieved. This would also mean that clients need not manually test
+against each provider to make sure their application is compatible.
 
-3. Opt for a minimum set of features that a cloud provider will support, instead of  a lowest common denominator approach. This means that reasonably mature clouds like Amazon and Openstack are used as the benchmark against which functionality & features are determined. Therefore, there is a definite expectation that the cloud infrastructure will support a compute service with support for images and snapshots and various machine sizes. The cloud infrastructure will very likely support block storage, although this is currently optional. It may optionally support object storage.
+3. Opt for a minimum set of features that a cloud provider will support, instead
+of  a lowest common denominator approach. This means that reasonably mature
+clouds like Amazon and OpenStack are used as the benchmark against which
+functionality & features are determined. Therefore, there is a definite
+expectation that the cloud infrastructure will support a compute service with
+support for images and snapshots and various machine sizes. The cloud
+infrastructure will very likely support block storage, although this is
+currently optional. It may optionally support object storage.
 
-4. Make the cloudbridge layer as thin as possible without compromising goal 1. By wrapping the cloud provider's native SDK and doing the minimal work necessary to adapt the interface, we can achieve greater development speed and reliability since the native provider SDK is most likely to have both properties.
+4. Make the cloudbridge layer as thin as possible without compromising goal 1.
+By wrapping the cloud provider's native SDK and doing the minimal work necessary
+to adapt the interface, we can achieve greater development speed and reliability
+since the native provider SDK is most likely to have both properties.
 
 
 Contributing
@@ -71,10 +85,13 @@ Community contributions for any part of the project are welcome. If you have
 a completely new idea or would like to bounce your idea before moving forward
 with the implementation, feel free to create an issue to start a discussion.
 
-Contributions should come in the form or a pull request. We strive for 100%
-test coverage so code will only be accepted if it comes with appropriate tests
-and it does not break existing functionality. Further, the code needs to be
-well documented and all methods have docstrings.
+Contributions should come in the form or a pull request. We strive for 100% test
+coverage so code will only be accepted if it comes with appropriate tests and it
+does not break existing functionality. Further, the code needs to be well
+documented and all methods have docstrings. We are largely adhering to the
+`PEP8 style guide`_ with 80 character lines, 4-space indentation (spaces
+instead of tabs), explicit, one-per-line imports among others. Please keep the
+style consistent with the rest of the project.
 
 Conceptually, the library is laid out such that there is a factory used to
 create a reference to a cloud provider. Each provider offers a set of services
@@ -82,7 +99,8 @@ and resources. Services typically perform actions while resources offer
 information (and can act on itself, when appropriate). The structure of each
 object is defined via an abstract interface (see
 ``cloudbridge/providers/interfaces``) and any object should implement the
-defined interface.
+defined interface. If adding a completely new provider, take a look at the
+`provider development page`_ in the documentation.
 
 Running tests
 ~~~~~~~~~~~~~
@@ -109,9 +127,20 @@ Testing philosophy
 Our testing goals are to:
 
 1. Write one set of tests that all provider implementations must pass.
-2. Make that set of tests a 'conformance' test suite, which validates that each implementation correctly implements the cloudbridge specification.
-3. Make the test suite comprehensive enough that a provider which passes all the tests can be used safely by an application with no additional testing. In other words, the cloudbridge specification and accompanying test suite must be comprehensive enough that no provider specific workarounds, code or testing is required.
-4. For development, mock providers may be used to speed up the feedback cycle, but providers must also pass the full suite of tests when run against actual cloud infrastructure to ensure that we are not testing against an idealised or imagined environment.
+2. Make that set of tests a 'conformance' test suite, which validates that each
+implementation correctly implements the cloudbridge specification.
+3. Make the test suite comprehensive enough that a provider which passes all the
+tests can be used safely by an application with no additional testing. In other
+words, the cloudbridge specification and accompanying test suite must be
+comprehensive enough that no provider specific workarounds, code or testing is
+required.
+4. For development, mock providers may be used to speed up the feedback cycle,
+but providers must also pass the full suite of tests when run against actual
+cloud infrastructure to ensure that we are not testing against an idealised or
+imagined environment.
 5. Aim for 100% code coverage.
 
 .. _`tox`: https://tox.readthedocs.org/en/latest/
+.. _`PEP8 style guide`: https://www.python.org/dev/peps/pep-0008/
+.. _`provider development page`: http://cloudbridge.readthedocs.org/en/latest/
+    topics/provider_development.html