Update documentation and tests

1 files changed, 40 insertions, 6 deletions

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 30fa608..434ca45 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -21,7 +21,6 @@ requests](#pull-requests), but please respect the following restrictions:
   respect the opinions of others.
 
 
-<a name="bugs"></a>
 ## Bug reports
 
 A bug is a _demonstrable problem_ that is caused by the code in the repository.
@@ -64,7 +63,6 @@ Example:
 > merits).
 
 
-<a name="features"></a>
 ## Feature requests
 
 Feature requests are welcome. But take a moment to find out whether your idea
@@ -73,7 +71,6 @@ case to convince the project's developers of the merits of this feature. Please
 provide as much detail and context as possible.
 
 
-<a name="pull-requests"></a>
 ## Pull requests
 
 Good pull requests - patches, improvements, new features - are a fantastic
@@ -90,7 +87,7 @@ accurate comments, etc.) and any other requirements (such as test coverage).
 Follow this process if you'd like your work considered for inclusion in the
 project:
 
-1. [Fork](http://help.github.com/fork-a-repo/) the project, clone your fork,
+1. [Fork](https://help.github.com/articles/fork-a-repo/) the project, clone your fork,
    and configure the remotes:
 
    ```bash
@@ -122,9 +119,19 @@ project:
    [interactive rebase](https://help.github.com/articles/interactive-rebase)
    feature to tidy up your commits before making them public.
 
-   Make sure to add a test to the `test.html` file if appropriate, and test
+   Be sure to test the `normalize.css` file for style conformance.
+
+   ```bash
+   npm test
+   ```
+
+   Be sure to add a test to the `test.html` file if appropriate, and test
    your change in all supported browsers.
 
+   ```bash
+   git pull --rebase upstream master
+   ```
+
 5. Locally rebase the upstream development branch into your topic branch:
 
    ```bash
@@ -146,8 +153,24 @@ project:
 **IMPORTANT**: By submitting a patch, you agree to allow the project owner to
 license your work under the same license as that used by the project.
 
+### CSS Conventions
+
+Keep the CSS file as readable as possible by following these guidelines:
+
+- Comments are short and to the point.
+- Comments without a number reference the entire rule.
+- Comments describe the selector when the selector does not make the
+  normalization obvious.
+- Comments begin with “Correct the...” when they deal with less obvious side
+  effects.
+- Rules are sorted by cascade, specificity, and then alphabetic order.
+- Selectors are sorted by specificity and then alphabetic order.
+- `in browser` applies to all versions.
+- `in browser v-` applies to all versions up to and including the version.
+- `in browser v+` applies to all versions after and including the version.
+- `in browser v-v` applies to all versions including and between the versions.
+
 
-<a name="maintainers"></a>
 ## Maintainers
 
 If you have commit access, please follow this process for merging patches and
@@ -175,3 +198,14 @@ cutting new releases.
 4. Create an annotated tag for the version: `git tag -m "v0.0.0" 0.0.0`.
 5. Push the changes and tags to GitHub: `git push --tags origin master`
 6. Checkout the `gh-pages` branch and follow the instructions in the README.
+
+### Semver strategy
+
+[Semver](http://semver.org/) is a widely accepted method for deciding how
+version numbers are incremented in a project. Versions are written as
+MAJOR.MINOR.PATCH.
+
+Changes limited to fallback declarations for browsers which do not support
+newer features produce a PATCH release.
+
+Changes limited to normalizations for older browsers produce a MINOR release.