Add contributing guide

That was my recommendation - I would normally clone my fork, meaning origin points to my repo, but since go needs to keep the import paths consistent, I clone upstream and use the remotes upstream and origin (mine). 

> On Sep 4, 2014, at 5:48 PM, Clayton Coleman <notifications@github.com> wrote:
> 
> In CONTRIBUTING.adoc:
> 
> > +
> > +1. The Origin repo: https://github.com/openshift/origin[github.com/openshift/origin]
> > +2. The OpenShift Kubernetes fork: https://github.com/openshift/kubernetes[github.com/openshift/kubernetes]
> > +
> > +Here's a quick summary of what we're doing there:
> > +
> > +=== The Origin Repo
> > +The OpenShift team is developing tools that will optimize and extend Kubernetes to function as a next-generation https://www.youtube.com/watch?v=aZ40GobvA1c[Platform-as-a-Service] offering. This repo contains that instrumentation along with some script-based examples of the +openshift+ utility in action. Kubernetes is included as a set of dependencies for this code, meaning that _it is not necessary to download Kubernetes separately if you are only interested in Origin development_.
> > +
> > +*Hacking Origin:* +
> > +To get started, https://help.github.com/articles/fork-a-repo[fork] the https://help.github.com/articles/fork-a-repo[origin repo] and then set up a local copy:
> > +
> > +----
> > +$ go get github.com/openshift/origin
> > +$ cd $GOPATH/src/github.com/openshift/origin
> > +$ git remote rename origin upstream
> I'm saying that origin is what git does by default, and origin in 90% of the clone cases will mean "openshift origin master", so teaching people to change their origin does seem weird. It's just extra steps that I don't know add benefit to users.
> 
> —
> Reply to this email directly or view it on GitHub.