More README updates

CONTRIBUTING.md

@@ -6,6 +6,7 @@ This document outlines some of the conventions on development workflow.
 
 - Fork the repository on GitHub
 - Read the [README](README.md) for build and test instructions
+- Read the [STYLEGUIDE](STYLEGUIDE.md) for code conventions
 - Play with the project, submit bugs, submit patches!
 
 ## Contribution Flow
@@ -57,22 +58,18 @@ issue to its pull request and close the issue when the pull request merges.
 While we don't have automated tooling for JIRA issues, you should still include
 a link to the issue in the commit description to make it easy to get to the issue.
 
-### Pull Requests Against Other Branches
+### Backporting Fixes
 
-Pull requests opened against branches other than master should start the pull
-request title with the branch name in brackets like `[release-3.11]` to make it
-obvious. Include the bug as well when appropriate. For instance,
+Branches for previous releases follow the format `release-X.Y`, for example,
+`release-4.1`. Typically, bugs are fixed in the master branch first then
+backported to the appropriate release branches. Fixes backported to previous
+releases should have a Bugzilla bug for each version fixed.
 
-```
-[release-3.11] Bug 1643948: Fix crashlooping pods query
-```
-
-If you use the `/cherrypick` command, the bot will automatically append the
-branch to the pull request title. For instance, adding a comment to a PR like
+You can use the `/cherrypick` command to ask the bot to backport a fix.
 
 ```
-/cherrypick release-3.11
+/cherrypick release-4.1
 ```
 
-will create a new pull request against the release-3.11 branch when the current
+will create a new pull request against the release-4.1 branch when the current
 pull request merges as long as there are no merge conflicts.

README.md

@@ -18,12 +18,14 @@ The console is a more friendly `kubectl` in the form of a single page webapp.  I
 
 1. [node.js](https://nodejs.org/) >= 8 & [yarn](https://yarnpkg.com/en/docs/install) >= 1.3.2
 2. [go](https://golang.org/) >= 1.8 & [glide](https://glide.sh/) >= 0.12.0 (`go get github.com/Masterminds/glide`) & [glide-vc](https://github.com/sgotti/glide-vc)
-3. [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) and a k8s cluster
+3. [oc](https://mirror.openshift.com/pub/openshift-v4/clients/oc/4.1/) or [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) and an OpenShift or Kubernetes cluster
 4. `jq` (for `contrib/environment.sh`)
 5. Google Chrome/Chromium >= 60 (needs --headless flag) for integration tests
 
 ### Build everything:
 
+Clone the repository to `$GOPATH/src/github.com/openshift/console` and build with the command:
+
 ```
 ./build.sh
 ```
@@ -34,9 +36,9 @@ Backend binaries are output to `/bin`.
 ### Configure the application
 
 The following instructions assume you have an existing cluster you can connect
-to. OpenShift 4.0 clusters can be installed using the
-[OpenShift Installer](https://github.com/openshift/installer).
-You can also use [CodeReady Containers](https://github.com/code-ready/osp4)
+to. OpenShift 4.x clusters can be installed using the
+[OpenShift Installer](https://mirror.openshift.com/pub/openshift-v4/clients/ocp/latest/).
+You can also use [CodeReady Containers](https://github.com/code-ready/crc)
 for local installs. More information about installing OpenShift can be found at
 <https://try.openshift.com/>.
 
@@ -184,8 +186,6 @@ Run frontend tests:
 
 Integration tests are run in a headless Chrome driven by [protractor](http://www.protractortest.org/#/).  Requirements include Chrome, a working cluster, kubectl, and bridge itself (see building above).
 
-Note: If you are running integration tests against OpenShift, you should start bridge using [oc-environment.sh](#openshift-without-oauth) to skip the login page.
-
 Setup (or any time you change node_modules - `yarn add` or `yarn install`)
 ```
 cd frontend && yarn run webdriver-update

STYLEGUIDE.md

@@ -1,4 +1,4 @@
-# Tectonic Console Styleguide
+# OpenShift Console Styleguide
 
 ## Directory and File Names
 
@@ -22,8 +22,12 @@
 - All SCSS variables should be scoped within their component.
 - We use [BEM](http://getbem.com) naming conventions.
 
-## JavaScript
+## TypeScript and JavaScript
 
+- New code should be written in TypeScript, not JavaScript.
+- Prefer functional components to class-based components.
+- Use [React hooks](https://reactjs.org/docs/hooks-intro.html) with functional components if you need state.
+- Prefer [composition to inheritance](https://reactjs.org/docs/composition-vs-inheritance.html).
 - Run the linter and follow all rules defined in .eslintrc
 - Never use absolute paths in code. The app should be able to run behind a proxy under an arbitrary path.
 - TESTS: Should follow a similar "test tables" convention as used in Go where applicable.