diff --git a/source/community.html.haml b/source/community.html.haml
index 4114802..bd85451 100644
--- a/source/community.html.haml
+++ b/source/community.html.haml
@@ -48,11 +48,26 @@ layout: layout_1_column
%dl
%dt= link_to "Stable", "https://github.com/nex3/sass"
- %dd The stable branch is where we do development on the released version. The majority of bug fixes should go here. If you're just reporting a bug and note the version of Sass where you experienced the issue in your comment. If you have a some code to contribute, fork the stable branch and send us a pull request. We'll review your patch and either accept or decline with comments.
+ %dd
+ The stable branch is where we do development on the released version.
+ The majority of bug fixes should go here.
+ If you're just reporting a bug add an issue and
+ note the version of Sass where you experienced the issue in your comment.
+ If you have a some code to contribute, fork the stable branch and send us a pull request.
+ We'll review your patch and either accept or decline with comments.
+ All bug fixes must be thoroughly tested and the tests must pass
+ the build on all supported versions of ruby.
%dl
%dt= link_to "Master", "https://github.com/nex3/sass/tree/master"
- %dd The master branch is where we keep track of the next version of Sass. New feature requests should be made here. Similar to submitting patches, for the project and send us a pull request. We'll review your pull request and either accept or decline. If we decline we'll make a few comments in the pull request for changes or a reason the pull request was declined.
+ %dd
+ The master branch is where we keep track of the next version of Sass.
+ New feature requests should be made on the issue tracker
+ and discussed with the core team
+ before implementation begins to avoid wasted effort.
+ Pull requests for new features should be made against the master branch.
+ No change is allowed to break a stylesheet across sequential releases;
+ every breaking change to the language must first be deprecated.
%h2#PullRequests Pull Requests & Patches
%p Here are a few simple things you'll need to do when submitting a patch via pull request:
@@ -62,6 +77,9 @@ layout: layout_1_column
%li Contain any appropriate unit tests in your commit
%li Add your changes to the changelog for the correct branch. The changelog is in doc-src/SASS_CHANGELOG.md
%li If your change is user-facing, update the appropriate section in reference documentation.
+ %li Don't combine several features or bug fixes into the same pull request.
+ %li All code is given a thorough review and will likely require several iterations before being accepted.
+ %li All code changes must be thoroughly tested and the tests must pass the build on all supported versions of ruby.