Changes per @Hypnosphi and @ndelangen's comments. Setting up dev env …

…contents still WIP

docs-v2/content/contributing/issue-triage.md

@@ -27,11 +27,11 @@ If an issue is a `bug`, and it doesn't have a clear reproduction that you have p
 ## Closing issues
 
 -   Duplicate issues should be closed with a link to the original.
--   Unreproducible issues should be closed if it's not possible to reproduce them (if the reporter drops offline, 
+-   Unreproducible issues should be closed if it's not possible to reproduce them (if the reporter drops offline,
     it is reasonable to wait 2 weeks before closing).
 -   `bug`s should be labelled `merged` when merged, and be closed when the issue is fixed and released.
--   `feature`s, `maintenance`s, `greenkeeper`s should be labelled `merged` when merged, 
+-   `feature`s, `maintenance`s, `greenkeeper`s should be labelled `merged` when merged,
     and closed when released or if the feature is deemed not appropriate.
--   `question / support`s should be closed when the question has been answered. 
+-   `question / support`s should be closed when the question has been answered.
     If the questioner drops offline, a reasonable period to wait is two weeks.
 -   `discussion`s should be closed at a maintainer's discretion.

docs-v2/content/contributing/maintainers-avoiding-burnout.md

@@ -46,4 +46,4 @@ work to be done.
 
 * * *
 
-This document has been taken **_mostly_** from [HomeBrew](https://github.com/Storybook/brew/blob/76955b47bd2ae3eba1b041430d7e1aeab246de0d/docs/Maintainers-Avoiding-Burnout.md).  Thanks HomeBrew!
+This document has been taken **_mostly_** from [HomeBrew](https://github.com/Homebrew/brew/blob/76955b47bd2ae3eba1b041430d7e1aeab246de0d/docs/Maintainers-Avoiding-Burnout.md).  Thanks HomeBrew!

docs-v2/content/contributing/release-guide.md

@@ -1,57 +1,71 @@
 # Release Guide
 
-This section is for Storybook maintainers who will be creating releases.
-
 ## Releases Overview
 
-Each release is described by:
+This section is for Storybook maintainers who will be creating releases. It assumes:
+
+-   yarn >= 1.0.0 (otherwise you should pass a -- before command arguments)
+-   you've yarn linked `pr-log` from <https://github.com/storybooks/pr-log/pull/2>
 
--   A version
--   A list of merged pull requests
--   Optionally, a short hand-written description
+The current manual release sequence is as follows:
 
-Thus, the current release sequence is as follows:
+-   Generate a changelog and verify the release by hand
+-   Push the changelog to master or the release branch
+-   Clean, build, and publish the release
+-   Cut and paste the changelog to the github release page, and mark it as a (pre-) release
+
+This sequence applies to both releases and pre-releases, but differs slightly between the two.
 
 **NOTE: This is a work in progress. Don't try this unless you know what you're doing. We hope to automate this in CI, so this process is designed with that in mind.**
 
-First, build the release:
+## Prerelease:
 
 ```sh
 # make sure you current with origin/master.
-git checkout master
+git checkout release/X.Y
 git status
 
-# clean out extra files & build all the packages
-# WARNING: destructive if you have extra files lying around!
-yarn bootstrap --reset --all
-```
+# generate changelog and edit as appropriate
+# generates a Next section
+yarn changelog Next
 
-From here there are different procedures for prerelease (e.g. alpha/beta/rc) and proper release.
+# Edit the changelog/PRs as needed, then commit
+git commit -m "Updated changelog for vX.Y"
 
-> **NOTE:** the very first time you publish a scoped package (`@storybook/x`) you need to publish it by hand because the default for scoped packages is private, and we need to make our packages public. If you try to publish a package for the first time using our `lerna` publish script, `lerna` will crash halfway through and you'll be in a world of pain.
+# clean build
+yarn bootstrap --reset --core
+```
 
-## For prerelease (no CHANGELOG):
+> **NOTE:** the very first time you publish a scoped package (`@storybook/x`) you need to publish it by hand because the default for scoped packages is private, and we need to make our packages public. If you try to publish a package for the first time using our `lerna` publish script, `lerna` will crash halfway through and you'll be in a world of pain.
 
 ```sh
 # publish and tag the release
-yarn run publish --concurrency 1 --npm-tag=alpha
+npm run publish -- --concurrency 1 --npm-tag=alpha
 
-# push the tags
-git push --tags
+# update the release page
+open https://github.com/storybooks/storybook/releases
 ```
 
-## For full release (with CHANGELOG):
+## Full release:
 
 ```sh
-# publish but don't commit to git
-yarn run publish --concurrency 1 --skip-git
+# make sure you current with origin/master.
+git checkout master
+git status
+
+# generate changelog and edit as appropriate
+# generates a vNext section
+yarn changelog X.Y
 
-# Update `CHANGELOG.md`
-# - Edit PR titles/labels on github until output is good
-# - Optionally, edit a handwritten description in `CHANGELOG.md`
-yarn changelog
+# Edit the changelog/PRs as needed, then commit
+git commit -m "Changelog for vX.Y"
+
+# clean build
+yarn bootstrap --reset --core
+
+# publish and tag the release
+npm run publish -- --concurrency 1
 
-# tag the release and push `CHANGELOG.md` and tags
-# FIXME: not end-to-end tested!
-yarn github-release
+# update the release page
+open https://github.com/storybooks/storybook/releases
 ```

docs-v2/content/guides/why.md

@@ -45,8 +45,6 @@ Your app (most likely) has its own CSS, as does Storybook. By rendering your com
 
 ## Decorators
 
-> Currently React only
-
 Storybook has been built to be extensible a lots of ways.
 You can write stories is a variety of ways and this already provides a lot of freedom. 
 But it can become a little verbose sometimes, like when you want to wrap all your stories in a Redux State Provider, or a Router.

docs-v2/pages/guides/why.js

@@ -9,11 +9,9 @@ import { Content } from '../../components/Content';
 import * as Markdown from '../../components/Markdown';
 import content from '../../content/guides/why.md';
 
-export default generator('GuidesIndex', ({ path, query }) =>
+export default generator('GuidesIndex', ({ path, query }) => (
   <Page>
     <TopNav {...{ path }} />
-    <Content {...{ path, query }}>
-      {content}
-    </Content>
+    <Content {...{ path, query }}>{content}</Content>
   </Page>
-);
+));