chore: make documentation clearer (#9450)

.github/CONTRIBUTING.md

@@ -1,6 +1,6 @@
 # Vue.js Contributing Guide
 
-Hi! I’m really excited that you are interested in contributing to Vue.js. Before submitting your contribution though, please make sure to take a moment and read through the following guidelines.
+Hi! I'm really excited that you are interested in contributing to Vue.js. Before submitting your contribution, please make sure to take a moment and read through the following guidelines:
 
 - [Code of Conduct](https://github.com/vuejs/vue/blob/dev/.github/CODE_OF_CONDUCT.md)
 - [Issue Reporting Guidelines](#issue-reporting-guidelines)
@@ -14,28 +14,28 @@ Hi! I’m really excited that you are interested in contributing to Vue.js. Befo
 
 ## Pull Request Guidelines
 
-- The `master` branch is basically just a snapshot of the latest stable release. All development should be done in dedicated branches. **Do not submit PRs against the `master` branch.**
+- The `master` branch is just a snapshot of the latest stable release. All development should be done in dedicated branches. **Do not submit PRs against the `master` branch.**
 
 - Checkout a topic branch from the relevant branch, e.g. `dev`, and merge back against that branch.
 
 - Work in the `src` folder and **DO NOT** checkin `dist` in the commits.
 
-- It's OK to have multiple small commits as you work on the PR - we will let GitHub automatically squash it before merging.
+- It's OK to have multiple small commits as you work on the PR - GitHub will automatically squash it before merging.
 
 - Make sure `npm test` passes. (see [development setup](#development-setup))
 
 - If adding new feature:
   - Add accompanying test case.
-  - Provide convincing reason to add this feature. Ideally you should open a suggestion issue first and have it greenlighted before working on it.
+  - Provide convincing reason to add this feature. Ideally, you should open a suggestion issue first and have it approved before working on it.
 
-- If fixing a bug:
-  - If you are resolving a special issue, add `(fix #xxxx[,#xxx])` (#xxxx is the issue id) in your PR title for a better release log, e.g. `update entities encoding/decoding (fix #3899)`.
+- If fixing bug:
+  - If you are resolving a special issue, add `(fix #xxxx[,#xxxx])` (#xxxx is the issue id) in your PR title for a better release log, e.g. `update entities encoding/decoding (fix #3899)`.
   - Provide detailed description of the bug in the PR. Live demo preferred.
   - Add appropriate test coverage if applicable.
 
 ## Development Setup
 
-You will need [Node.js](http://nodejs.org) **version 6+** and [Java Runtime Environment](http://www.oracle.com/technetwork/java/javase/downloads/index.html) (needed for running Selenium server during e2e tests).
+You will need [Node.js](http://nodejs.org) **version 6+** and [Java Runtime Environment](http://www.oracle.com/technetwork/java/javase/downloads/index.html) (for running Selenium server during e2e tests).
 
 After cloning the repo, run:
 
@@ -65,11 +65,11 @@ $ npm test
 
 There are some other scripts available in the `scripts` section of the `package.json` file.
 
-The default test script will do the following: lint with ESLint -> type check with Flow -> unit tests with coverage -> e2e tests. **Please make sure to have this pass successfully before submitting a PR.** Although the same tests will be run against your PR on the CI server, it is better to have it working locally beforehand.
+The default test script will do the following: lint with ESLint -> type check with Flow -> unit tests with coverage -> e2e tests. **Please make sure to have this pass successfully before submitting a PR.** Although the same tests will be run against your PR on the CI server, it is better to have it working locally.
 
 ## Project Structure
 
-- **`scripts`**: contains build-related scripts and configuration files. In most cases you don't need to touch them. However, it would be helpful to familiarize yourself with the following files:
+- **`scripts`**: contains build-related scripts and configuration files. Usually, you don't need to touch them. However, it would be helpful to familiarize yourself with the following files:
 
   - `scripts/alias.js`: module import aliases used across all source code and tests.
 
@@ -85,51 +85,51 @@ The default test script will do the following: lint with ESLint -> type check wi
 
 - **`test`**: contains all tests. The unit tests are written with [Jasmine](http://jasmine.github.io/2.3/introduction.html) and run with [Karma](http://karma-runner.github.io/0.13/index.html). The e2e tests are written for and run with [Nightwatch.js](http://nightwatchjs.org/).
 
-- **`src`**: contains the source code, obviously. The codebase is written in ES2015 with [Flow](https://flowtype.org/) type annotations.
+- **`src`**: contains the source code. The codebase is written in ES2015 with [Flow](https://flowtype.org/) type annotations.
 
   - **`compiler`**: contains code for the template-to-render-function compiler.
 
-    The compiler consists of a parser (converts template strings to element ASTs), an optimizer (detects static trees for vdom render optimization), and a code generator (generate render function code from element ASTs). Note the codegen directly generates code strings from the element AST - it's done this way for smaller code size because the compiler is shipped to the browser in the standalone build.
+    The compiler consists of a parser (converts template strings to element ASTs), an optimizer (detects static trees for vdom render optimization), and a code generator (generate render function code from element ASTs). Note that codegen directly generates code strings from the element AST - it's done this way for smaller code size because the compiler is shipped to the browser in the standalone build.
 
   - **`core`**: contains universal, platform-agnostic runtime code.
 
-    The Vue 2.0 core is platform-agnostic - which means code inside `core` should be able to run in any JavaScript environment, be it the browser, Node.js, or an embedded JavaScript runtime in native applications.
+    The Vue 2.0 core is platform-agnostic. That is, code inside `core` is able to be run in any JavaScript environment, be it the browser, Node.js, or an embedded JavaScript runtime in native applications.
 
     - **`observer`**: contains code related to the reactivity system.
 
     - **`vdom`**: contains code related to vdom element creation and patching.
 
     - **`instance`**: contains Vue instance constructor and prototype methods.
 
-    - **`global-api`**: as the name suggests.
+    - **`global-api`**: contains Vue global api.
 
-    - **`components`**: universal abstract components. Currently `keep-alive` is the only one.
+    - **`components`**: contains universal abstract components.
 
   - **`server`**: contains code related to server-side rendering.
 
   - **`platforms`**: contains platform-specific code.
 
     Entry files for dist builds are located in their respective platform directory.
 
-    Each platform module contains three parts: `compiler`, `runtime` and `server`, corresponding to the three directories above. Each part contains platform-specific modules/utilities which are then imported and injected to the core counterparts in platform-specific entry files. For example, the code implementing the logic behind `v-bind:class` is in `platforms/web/runtime/modules/class.js` - which is imported in `entries/web-runtime.js` and used to create the browser-specific vdom patching function.
+    Each platform module contains three parts: `compiler`, `runtime` and `server`, corresponding to the three directories above. Each part contains platform-specific modules/utilities which are imported and injected to the core counterparts in platform-specific entry files. For example, the code implementing the logic behind `v-bind:class` is in `platforms/web/runtime/modules/class.js` - which is imported in `entries/web-runtime.js` and used to create the browser-specific vdom patching function.
 
   - **`sfc`**: contains single-file component (`*.vue` files) parsing logic. This is used in the `vue-template-compiler` package.
 
   - **`shared`**: contains utilities shared across the entire codebase.
 
   - **`types`**: contains TypeScript type definitions
 
-    - **`test`**: type definitions tests
+    - **`test`**: contains type definitions tests
 
 
 ## Financial Contribution
 
-As a pure community-driven project without major corporate backing, we also welcome financial contributions via Patreon or OpenCollective.
+As a pure community-driven project without major corporate backing, we also welcome financial contributions via Patreon and OpenCollective.
 
 - [Become a backer or sponsor on Patreon](https://www.patreon.com/evanyou)
 - [Become a backer or sponsor on OpenCollective](https://opencollective.com/vuejs)
 
-### What's the difference between Patreon and OpenCollective?
+### What's the difference between Patreon and OpenCollective funding?
 
 Funds donated via Patreon go directly to support Evan You's full-time work on Vue.js. Funds donated via OpenCollective are managed with transparent expenses and will be used for compensating work and expenses for core team members or sponsoring community events. Your name/logo will receive proper recognition and exposure by donating on either platform.