First pass at Contribution Guidelines

Started on some contribution guidelines

CONTRIBUTING.md

@@ -0,0 +1,27 @@
+# How to contribute
+
+We welcome contributions to the NuGet Gallery! However, we do have a few suggestions for making sure we can integrate your code in the cleanest possible way. Also, please remember that we will be maintaining the code you contribute, so there may be cases where we have to decline a feature because it doesn't make much sense in the main code. You are more than welcome to maintain a custom fork of the code for your use cases.
+
+## Getting Started
+1. Make sure there is an issue in the (Issue Tracker)[https://github.com/NuGet/NuGetGallery/issues] for the feature or bug you want to fix. If not, create one!
+1. Create a fork in GitHub
+1. Create a branch off of the 'dev-start' branch. Name it something which easily links it back to the issue. For example: "Bug-1234".
+1. Make your changes
+1. Send a Pull Request!
+
+## Some tips
+* Please follow the code style of the rest of the gallery. When you can't figure out what the style for a particular aspect is, please bring that up in your PR and we'd be happy to advise you.
+* Please don't surprise us with big Pull Requests. If you have a feature you want to work on, file an Issue so we can discuss it.
+* Please DO grab things from the Unscheduled milestone! Some of those things are small things we just don't have time to get to, but we'd be happy to take contributions. Think of it as a great way to get your feet wet :)
+* However, don't feel obligated to stick to Unscheduled. We're happy to accept well-written, maintainable, PRs for any Issue in the Backlog.
+* We have to dedicate resources to integrate and test your code, so it may take a while for us to integrate it. Feel free to ping the PR and nag us to take a look :)
+* All contributions must include Unit Tests. We're also building out our Functional Tests, so the more of those you provide, the more excited we'll be to accept your change :).
+* Contributed code must be free of compilation warnings, FxCop errors/warnings and Unit or Functional Test failures.
+
+## Specific code style notes:
+1. We use Allman style braces (the VS default)
+1. We avoid "this." unless absolutely necessary
+1. We use "_camelCase" private members and use "readonly" where possible
+1. Our tests use the (Arrange/Act/Assert)[http://c2.com/cgi/wiki?ArrangeActAssert] pattern
+1. Namespace Imports should be specified at the top of the file, OUTSIDE of "namespace" declarations.
+1. Namespace Imports should be sorted alphabetically, with 'System.' namespaces at the top (there is a VS setting to do this)