Repo config (#46)

* Create CONTRIBUTING.md

* Create CODE-OF-CONDUCT.md

* Create ISSUE_TEMPLATE

* Review feedback

.github/ISSUE_TEMPLATE

@@ -0,0 +1,17 @@
+<short description>
+
+<version of the grpc-dart packages used; see your `pubspec.lock` file>
+
+## Repro steps
+
+1. step1
+1. step2
+1. step3
+
+Expected result: <describe what should have happened>
+
+Actual result: <describe what actually happened>
+
+## Details
+
+<Include any other relevant details, logs, etc.>

CODE-OF-CONDUCT.md

@@ -0,0 +1,12 @@
+We expect contributors to act professionally and respectfully, and we
+expect our social spaces to be safe and dignified environments.
+
+Specifically:
+
+* Respect people, their identities, their culture, and their work.
+
+* Be kind. Be courteous. Be welcoming.
+
+* Listen. Consider and acknowledge people’s points before responding.
+
+We will not tolerate harrasment from anyone in our community.

CONTRIBUTING.md

@@ -0,0 +1,65 @@
+# How to contribute
+
+We definitely welcome your patches and contributions to gRPC!
+
+If you are new to github, please start by reading [Pull Request
+howto](https://help.github.com/articles/about-pull-requests/)
+
+## Legal requirements
+
+In order to protect both you and ourselves, you will need to sign the
+[Contributor License
+Agreement](https://identity.linuxfoundation.org/projects/cncf).
+
+## Code style
+
+We follow the [Effective
+Dart](https://www.dartlang.org/guides/language/effective-dart/style) code style.
+We rely on auto-formatting all whitespace -- this avoids having to discuss
+formatting during reviews. To format your code, run `dartfmt` from the root, or
+use the similar action in your [favorite Dart
+editor](https://www.dartlang.org/tools).
+
+All code must pass Dart analysis. If you are using an IDE or Dart-enabled editor
+it should raise analysis issues as you edit; alternatively validate from the
+Terminal:
+
+```
+dartanalyzer lib test
+```
+
+All analysis warnings and errors must be fixed; hints should be considered.
+
+## Running tests
+
+```
+pub get
+pub run test
+```
+
+## Guidelines for Pull Requests
+
+How to get your contributions merged smoothly and quickly.
+ 
+- Create **small PRs** that are narrowly focused on **addressing a single
+concern**. 
+
+- For speculative changes, consider opening an issue and discussing it first.
+ 
+- Provide a good **PR description** as a record of **what** change is being made
+and **why** it was made. Link to a github issue if it exists.
+ 
+- Unless your PR is trivial, you should expect there will be review comments
+that you'll need to address before merging. We expect you to be reasonably
+responsive to those comments, otherwise the PR will be closed after 2-3 weeks of
+inactivity.
+
+- Keep your PR up to date with upstream/master (if there are merge conflicts, we
+can't really merge your change).
+
+- **All tests need to be passing** before your change can be merged. We
+recommend you **run tests locally** before creating your PR to catch breakages
+early on.
+ 
+- Exceptions to the rules can be made if there's a compelling reason for doing
+so.