Add build instructions (#130)

BUILDING.md

@@ -0,0 +1,21 @@
+# Building gRPC-Kotlin
+
+Building should only be necessary if you are making changes to gRPC-Kotlin, or if
+you'd like to use or test a version of gRPC-Kotlin that hasn't been released
+yet.
+
+Use the following gradle command to build gRPC-Kotlin:
+
+```console
+$ ./gradlew build
+```
+
+Install the built artifacts into your local Maven repository so that you can use
+them in your projects:
+
+```console
+$ ./gradlew publishToMavenLocal
+```
+
+Ensure that you configure your project build to use the local version of
+gRPC-Kotlin.

CONTRIBUTING.md

@@ -18,29 +18,30 @@ Agreement](https://identity.linuxfoundation.org/projects/cncf).
 Before starting any development work you will need a local copy of the gRPC repository.
 
 ## 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**.  We often times receive PRs that are trying to fix several things
   at a time, but only one fix is considered acceptable, nothing gets merged and
   both author's & review's time is wasted.  Create more PRs to address different
   concerns and everyone will be happy.
- 
+
 - For speculative changes, consider opening an issue and discussing it first.
   If you are suggesting a behavioral or API change, consider starting with a
   [gRFC proposal](https://github.com/grpc/proposal).
- 
+
 - 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.
- 
+
 - Don't fix code style and formatting unless you are already changing that line
   to address an issue.  PRs with irrelevant changes won't be merged.  If you do
   want to fix formatting or style, do that in a separate PR.
 
 - If you are adding a new file, make sure it has the copyright message template
   at the top as a comment. You can copy over the message from an existing file
   and update the year.
- 
+
 - Unless your PR is trivial, you should expect there will be reviewer 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
@@ -51,27 +52,31 @@ How to get your contributions merged smoothly and quickly.
   Use `rebase -i upstream/master` to curate your commit history and/or to
   bring in latest changes from master (but avoid rebasing in the middle of
   a code review).
- 
+
 - 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 (see `src/test`)
- 
+
 - Exceptions to the rules can be made if there's a compelling reason for doing
   so.
 
 ## Obtaining Commit Access
+
 We grant Commit Access to contributors based on the following criteria:
+
 * Sustained contribution to the gRPC project.
-* Deep understanding of the areas contributed to, and good consideration of various reliability, usability and performance tradeoffs. 
-* Contributions demonstrate that obtaining Commit Access will significantly reduce friction for the contributors or others. 
+* Deep understanding of the areas contributed to, and good consideration of various reliability, usability and performance tradeoffs.
+* Contributions demonstrate that obtaining Commit Access will significantly reduce friction for the contributors or others.
 
 In addition to submitting PRs, a Contributor with Commit Access can:
+
 * Review PRs and merge once other checks and criteria pass.
-* Triage bugs and PRs and assign appropriate labels and reviewers. 
+* Triage bugs and PRs and assign appropriate labels and reviewers.
+
+### Obtaining Commit Access without Code Contributions
 
-### Obtaining Commit Access without Code Contributions 
-The [gRPC organization](https://github.com/grpc) is comprised of multiple repositories and commit access is usually restricted to one or more of these repositories. Some repositories such as the [grpc.github.io](https://github.com/grpc/grpc.github.io/) do not have code, but the same principle of sustained, high quality contributions, with a good understanding of the fundamentals, apply. 
+The [gRPC organization](https://github.com/grpc) is comprised of multiple repositories and commit access is usually restricted to one or more of these repositories. Some repositories such as the [grpc.github.io](https://github.com/grpc/grpc.github.io/) do not have code, but the same principle of sustained, high quality contributions, with a good understanding of the fundamentals, apply.
 

README.md

@@ -33,6 +33,13 @@ For more information, see the following [Kotlin pages from grpc.io][]:
 - [gRPC Basics - Kotlin/JVM][] tutorial
 - [API Reference][]
 
+How-to pages from this repo:
+
+- [Contributing](CONTRIBUTING.md)
+- [Building gRPC-Kotlin](BUILDING.md)
+
+Note that [official releases][] are [published to Maven Central][].
+
 [API Reference]: https://grpc.io/docs/languages/kotlin/api
 [Gradle Build Status]: https://github.com/grpc/grpc-kotlin/workflows/Gradle%20Build/badge.svg
 [Bazel Build Status]: https://github.com/grpc/grpc-kotlin/workflows/Bazel%20Build/badge.svg
@@ -46,5 +53,7 @@ For more information, see the following [Kotlin pages from grpc.io][]:
 [maven:plugin]: https://search.maven.org/search?q=g:%22io.grpc%22%20AND%20a:%22protoc-gen-grpc-kotlin%22
 [maven:stub]: https://search.maven.org/search?q=g:%22io.grpc%22%20AND%20a:%22grpc-kotlin-stub%22
 [maven:stub-lite]: https://search.maven.org/search?q=g:%22io.grpc%22%20AND%20a:%22grpc-kotlin-stub-lite%22
+[official releases]: https://github.com/grpc/grpc-kotlin/releases
 [protoc]: https://github.com/protocolbuffers/protobuf#protocol-compiler-installation
 [protocolbuffers/protobuf#3742]: https://github.com/protocolbuffers/protobuf/issues/3742
+[published to Maven Central]: https://search.maven.org/search?q=g:io.grpc%20AND%20grpc-kotlin