Add badges and some code review details

Add to the main README - however note that since we only have PR based
tests right now, if a PR fails, our badges will go red which isn't
really fair to us or the submitter - but we can improve this in #52.

Added a go report card link too - looks like our linting could use some
improvement but we should see how #19 goes (maybe switching out
kubebuilder) before we start following up on all of these.

Also adding some details about code reviews after taking with @tejal29
and @aaron-prindle, specifically leaving the reviews up for a bit longer
than we have been to try to give more folks a chance to comment. Also
added a link to some useful Go coding standards.

Fixed a couple typos too.

CONTRIBUTING.md

@@ -10,7 +10,7 @@ In this file you'll find info on:
 
 * [Principles](#principles)
 * [The pull request process](#pull-request-process)
-* [Commit message requirements](#commit-messages)
+* [Standards](#standards) around [commit messages](#commit-messages) and [code](#coding-standards)
 * [The roadmap and contributions wanted](#roadmap-and-contributions-wanted)
 * [Contacting other contributors](#contact)
 
@@ -22,7 +22,7 @@ When possbile, try to practice:
 
 * **Documentation driven development** - Before implementing anything, write docs to explain
   how it will work
-* **Test drivent development** - Before implementing anything, write tests to cover it
+* **Test driven development** - Before implementing anything, write tests to cover it
 
 Minimize the number of integration tests written and maximize the unit tests! Unit test
 coverage should increase or stay the same with every PR.
@@ -52,7 +52,16 @@ Any changes will cause the `/lgtm` label to be removed and it will need to be re
 
 _See also [Knative docs on reviewing](https://github.com/knative/docs/blob/master/community/REVIEWING.md)._
 
-## Commit Messages
+### Review turnaround
+
+Pull requests opened by [maintainers](./OWNERS) should be left open, when possible, for at least a day in order
+to provide other maintainers a chance to review.
+
+## Standards
+
+This section describes the standards we will try to maintain in this repo.
+
+### Commit Messages
 
 All commit messages should follow [these best practices](https://chris.beams.io/posts/git-commit/),
 specifically:
@@ -69,6 +78,12 @@ Not sure what to put? Include:
 * What side effects will this approach have?
 * What future work remains to be done?
 
+### Coding standards
+
+The code in this repo should follow best practices, specifically:
+
+* [Go code review comments](https://github.com/golang/go/wiki/CodeReviewComments)
+
 ## Roadmap and contributions wanted
 
 As of Sept 2018, our roadmap for the next few months is to:

README.md

@@ -1,8 +1,12 @@
 # Pipeline CRD
 
+[![Prow unit test results](https://prow.knative.dev/badge.svg?jobs=pull-knative-build-pipeline-unit-tests)](https://prow.knative.dev/?job=pull-knative-build-pipeline-unit-tests)
+[![Prow build results](https://prow.knative.dev/badge.svg?jobs=pull-knative-build-pipeline-build-tests)](https://prow.knative.dev/?job=pull-knative-build-pipeline-build-tests)
+[![Go Report Card](https://goreportcard.com/badge/knative/build-pipeline)](https://goreportcard.com/report/knative/build-pipeline)
+
 This repo contains the API definition of the Pipeline CRD and an on cluster implementation of that API.
 The goal of the Pipeline CRD is to provide k8s-style resources that allow the
-declaration of CI/CD-style pipelines, which can be backed by any arbitrary impelmentation.
+declaration of CI/CD-style pipelines, which can be backed by any arbitrary implementation.
 
 Features the Pipeline CRD will support include: