Removed instances of obvious, of course

RELEASES.md

@@ -93,7 +93,7 @@ is to upvote it by adding a "thumbs-up" reaction in Github. This way important
 bugs quickly bubble to the top [with a
 search](https://github.com/storybookjs/storybook/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20sort%3Areactions-%2B1-desc%20label%3Abug).
 
-And of course, the best way to make sure a bug gets addressed quickly is to fix
+The best way to make sure a bug gets addressed quickly is to fix
 it yourself and issue a PR. If the fix is good, we'll try to release it quickly
 in a patch release.
 

ROADMAP.md

@@ -41,7 +41,7 @@ We're interested in full customizability of our UI, though addons and options.
 ### Add a playground addon
 
 Many other styleguide-type projects have what's called a playground, where developers can change the code rendering the component inside the app.
-Storybook has, of course, a very tight connection with your editor, and it has a knobs addon.
+Storybook has a very tight connection with your editor, and it has a knobs addon.
 But we still see value in an addon that will allow the workflow of a playground.
 
 ### See multiple (or all) stories in 1 preview.

addons/docs/docs/docspage.md

@@ -239,7 +239,7 @@ The docs preset assumes this naming convention for its `source-loader` setup. If
 
 ## Inline stories vs. Iframe stories
 
-Due to the complex nature of writing a cross-framework utility like Storybook, the story blocks for most frameworks exist within an `<iframe>` element. This creates a clean separation of the context the code for each framework lives inside, but, of course, it isn't a perfect tradeoff. It does create a set of disadvantages--namely, you have to explicitly set the height of a story. It also causes some headaches for certain dev tools (Vue dev tools, for example, don't pick up components that exist in an iframe, without substantial jerry-rigging).
+Due to the complex nature of writing a cross-framework utility like Storybook, the story blocks for most frameworks exist within an `<iframe>` element. This creates a clean separation of the context the code for each framework lives inside, but it isn't a perfect tradeoff. It does create a set of disadvantages--namely, you have to explicitly set the height of a story. It also causes some headaches for certain dev tools (Vue dev tools, for example, don't pick up components that exist in an iframe, without substantial jerry-rigging).
 
 That being said, there is a system in place to remove the necessity of this tradeoff. The docs configuration contains two options, `inlineStories` and `prepareForInline` that can work together to integrate non-react stories seamlessly (or should I say "scroll-bar-less-ly") into DocsPage. Setting `inlineStories` to `true` is the easy part. It tells storybook to stop putting your stories into an iframe. The hard(er) part is providing the `prepareForInline` parameter. This parameter accepts a function that transforms story content in your given framework into something react can render. Any given framework will need to approach this in a different way. Angular, for example, might convert its story content into a custom element (you can read about that [here](https://angular.io/guide/elements)). We've actually taken the initiative and implemented Vue inline stories _for you_ in the default docs config for Vue, because we're such nice people. The following docs config block allows Vue components to be rendered inline through a simple effect hook provided by [@egoist/vue-to-react](https://github.com/egoist/vue-to-react):
 

addons/docs/docs/recipes.md

@@ -66,7 +66,7 @@ I can define a story with the function imported from CSF:
 
 <Story name="basic">{stories.basic}</Story>
 
-And of course I can also embed arbitrary markdown & JSX in this file.
+And I can also embed arbitrary markdown & JSX in this file.
 
 <SomeComponent prop1="val1" />
 ```
@@ -94,7 +94,7 @@ I can embed a story (but not define one, since this file should not contain a `M
 
 <Story id="some--id" />
 
-And of course I can also embed arbitrary markdown & JSX in this file.
+And I can also embed arbitrary markdown & JSX in this file.
 
 <SomeComponent prop1="val1" />
 ```

lib/cli/test/fixtures/react_scripts/README.md

@@ -742,7 +742,7 @@ You can avoid this by reading the global variable explicitly from the `window` o
 const $ = window.$;
 ```
 
-This makes it obvious you are using a global variable intentionally rather than because of a typo.
+This makes it more clear that you are using a global variable intentionally rather than because of a typo.
 
 Alternatively, you can force the linter to ignore any line by adding `// eslint-disable-line` after it.
 

lib/cli/test/fixtures/update_package_organisations/README.md

@@ -577,7 +577,7 @@ You can avoid this by reading the global variable explicitly from the `window` o
 const $ = window.$;
 ```
 
-This makes it obvious you are using a global variable intentionally rather than because of a typo.
+This makes it more clear that you are using a global variable intentionally rather than because of a typo.
 
 Alternatively, you can force the linter to ignore any line by adding `// eslint-disable-line` after it.