merge lbaasv2, portsbinding, volumes v2; remove 'rackspace' refs; update docs
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 2cf355b..b2713f5 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -182,15 +182,9 @@
## Style guide
+See [here](/STYLEGUIDE.md)
-
-We follow the standard formatting recommendations and language idioms set out
-in the [Effective Go](https://golang.org/doc/effective_go.html) guide. It's
-definitely worth reading - but the relevant sections are
-[formatting](https://golang.org/doc/effective_go.html#formatting)
-and [names](https://golang.org/doc/effective_go.html#names).
-
-## 5 ways to get involved
+## 3 ways to get involved
There are five main ways you can get involved in our open-source project, and
each is described briefly below. Once you've made up your mind and decided on
@@ -201,23 +195,7 @@
2. checkout a [new branch](https://github.com/Kunena/Kunena-Forum/wiki/Create-a-new-branch-with-git-and-manage-branches)
3. submit your branch as a [pull request](https://help.github.com/articles/creating-a-pull-request/)
-### 1. Providing feedback
-
-On of the easiest ways to get readily involved in our project is to let us know
-about your experiences using our SDK. Feedback like this is incredibly useful
-to us, because it allows us to refine and change features based on what our
-users want and expect of us. There are a bunch of ways to get in contact! You
-can [ping us](https://developer.rackspace.com/support/) via e-mail, talk to us on irc
-(#rackspace-dev on freenode), [tweet us](https://twitter.com/rackspace), or
-submit an issue on our [bug tracker](/issues). Things you might like to tell us
-are:
-
-* how easy was it to start using our SDK?
-* did it meet your expectations? If not, why not?
-* did our documentation help or hinder you?
-* what could we improve in general?
-
-### 2. Fixing bugs
+### 1. Fixing bugs
If you want to start fixing open bugs, we'd really appreciate that! Bug fixing
is central to any project. The best way to get started is by heading to our
@@ -226,41 +204,16 @@
thread to see the current state of the issue and if anybody has made any
breakthroughs on it so far.
-### 3. Improving documentation
-
-We have three forms of documentation:
-
-* short README documents that briefly introduce a topic
-* reference documentation on [godoc.org](http://godoc.org) that is automatically
-generated from source code comments
-* user documentation on our [homepage](http://gophercloud.io) that includes
-getting started guides, installation guides and code samples
+### 2. Improving documentation
+The best source of documentation is on [godoc.org](http://godoc.org). It is
+automatically generated from the source code.
If you feel that a certain section could be improved - whether it's to clarify
ambiguity, correct a technical mistake, or to fix a grammatical error - please
feel entitled to do so! We welcome doc pull requests with the same childlike
enthusiasm as any other contribution!
-### 4. Optimizing existing features
-
-If you would like to improve or optimize an existing feature, please be aware
-that we adhere to [semantic versioning](http://semver.org) - which means that
-we cannot introduce breaking changes to the API without a major version change
-(v1.x -> v2.x). Making that leap is a big step, so we encourage contributors to
-refactor rather than rewrite. Running tests will prevent regression and avoid
-the possibility of breaking somebody's current implementation.
-
-Another tip is to keep the focus of your work as small as possible - try not to
-introduce a change that affects lots and lots of files because it introduces
-added risk and increases the cognitive load on the reviewers checking your
-work. Change-sets which are easily understood and will not negatively impact
-users are more likely to be integrated quickly.
-
-Lastly, if you're seeking to optimize a particular operation, you should try to
-demonstrate a negative performance impact - perhaps using Go's inbuilt
-[benchmark capabilities](http://dave.cheney.net/2013/06/30/how-to-write-benchmarks-in-go).
-
-### 5. Working on a new feature
+###3. Working on a new feature
If you've found something we've left out, definitely feel free to start work on
introducing that feature. It's always useful to open an issue or submit a pull