diff --git a/docs/How-To-Open-a-Homebrew-Pull-Request.md b/docs/How-To-Open-a-Homebrew-Pull-Request.md
index 104fc28299aed0418890ae5323b07e1097e3809f..d3ee6539ecf47004ec5d6c66c91d7434c2fbe334 100644
--- a/docs/How-To-Open-a-Homebrew-Pull-Request.md
+++ b/docs/How-To-Open-a-Homebrew-Pull-Request.md
@@ -12,18 +12,18 @@ Depending on the change you want to make, you need to send the pull request to t
### Core `brew` code related pull request
1. [Fork the Homebrew/brew repository on GitHub](https://github.com/Homebrew/brew/fork).
- * This creates a personal remote repository that you can push to. This is needed because only Homebrew maintainers have push access to the main repositories.
+ * This creates a personal remote repository that you can push to. This is needed because only Homebrew maintainers have push access to the main repositories.
2. Change to the directory containing your Homebrew installation with `cd $(brew --repository)`.
3. Add your pushable forked repository with `git remote add <YOUR_USERNAME> https://github.com/<YOUR_USERNAME>/brew.git`.
- * `<YOUR_USERNAME>` is your GitHub username, not your local machine username.
+ * `<YOUR_USERNAME>` is your GitHub username, not your local machine username.
### Formulae related pull request
1. [Fork the Homebrew/homebrew-core repository on GitHub](https://github.com/Homebrew/homebrew-core/fork).
- * This creates a personal remote repository that you can push to. This is needed because only Homebrew maintainers have push access to the main repositories.
+ * This creates a personal remote repository that you can push to. This is needed because only Homebrew maintainers have push access to the main repositories.
2. Change to the directory containing Homebrew formulae with `cd $(brew --repository homebrew/core)`.
3. Add your pushable forked repository with `git remote add <YOUR_USERNAME> https://github.com/<YOUR_USERNAME>/homebrew-core.git`
- * `<YOUR_USERNAME>` is your GitHub username, not your local machine username.
+ * `<YOUR_USERNAME>` is your GitHub username, not your local machine username.
For formulae in central taps other than `homebrew/core`, such as `homebrew/science` or `homebrew/nginx`, substitute that tap's name for `homebrew/core` in each step, and alter the GitHub repository URLs as necessary.
@@ -35,18 +35,19 @@ To make a new branch and submit it for review, create a GitHub pull request with
2. Retrieve new changes to the `master` branch with `brew update`.
3. Create a new branch from the latest `master` branch with `git checkout -b <YOUR_BRANCH_NAME> origin/master`.
4. Make your changes. For formulae, use `brew edit` or your favorite text editor, following all the guidelines in the [Formula Cookbook](Formula-Cookbook.md).
- * If there's a `bottle do` block in the formula: don't remove or change it; we'll update it when we pull your PR.
+ * If there's a `bottle do` block in the formula: don't remove or change it; we'll update it when we pull your PR.
5. Test your changes by doing the following, and ensure they all pass without issue. For changed formulae, make sure you do the `brew audit` step while your changed formula is installed.
- 1. `brew tests`
- 2. `brew install --build-from-source <CHANGED_FORMULA>`
- 3. `brew test <CHANGED_FORMULA>`
- 4. `brew audit --strict <CHANGED_FORMULA>`
+ * `brew tests`
+ * `brew install --build-from-source <CHANGED_FORMULA>`
+ * `brew test <CHANGED_FORMULA>`
+ * `brew audit --strict <CHANGED_FORMULA>`
6. Make a separate commit for each changed formula with `git add` and `git commit`.
7. Upload your new commits to the branch on your fork with `git push --set-upstream <YOUR_USERNAME> <YOUR_BRANCH_NAME>`.
8. Go to the relevant repository (e.g. <https://github.com/Homebrew/brew>, <https://github.com/Homebrew/homebrew-core>, etc.) and create a pull request to request review and merging of the commits in your pushed branch. Explain why the change is needed and, if fixing a bug, how to reproduce the bug. Make sure you have done each step in the checklist that appears in your new PR.
- * Please note that our preferred commit message format for simple version updates is "`<FORMULA_NAME> <NEW_VERSION>`", e.g. "`source-highlight 3.1.8`". `devel` version updates should have the commit message suffixed with `(devel)`, e.g. "`nginx 1.9.1 (devel)`". If updating both stable and `devel`, the format should be a concatenation of these two forms, e.g. "`x264 r2699, r2705 (devel)`".
+ * Please note that our preferred commit message format for simple version updates is "`<FORMULA_NAME> <NEW_VERSION>`", e.g. "`source-highlight 3.1.8`". `devel` version updates should have the commit message suffixed with `(devel)`, e.g. "`nginx 1.9.1 (devel)`". If updating both stable and `devel`, the format should be a concatenation of these two forms, e.g. "`x264 r2699, r2705 (devel)`".
9. Await feedback or a merge from Homebrew's maintainers. We typically respond to all PRs within a couple days, but it may take up to a week, depending on the maintainers' workload.
-10. Thank you!
+
+Thank you!
## Following up
@@ -54,7 +55,7 @@ To respond well to feedback:
1. Ask for clarification of anything you don't understand and for help with anything you don't know how to do.
2. Post a comment on your pull request if you've provided all the requested changes/information and it hasn't been merged after a week. Post a comment on your pull request if you're stuck and need help.
- * A `needs response` label on a PR means that the Homebrew maintainers need you to respond to previous comments.
+ * A `needs response` label on a PR means that the Homebrew maintainers need you to respond to previous comments.
3. Keep discussion in the pull request unless requested otherwise (i.e. do not email maintainers privately).
4. Do not continue discussion in closed pull requests.
5. Do not argue with Homebrew maintainers. You may disagree but unless they change their mind, please implement what they request. Ultimately they control what is included in Homebrew, as they have to support any changes that are made.
diff --git a/docs/Prose-Style-Guidelines.md b/docs/Prose-Style-Guidelines.md
index 7da21d3551963859b63926a84212359644a05977..0291156994ef5e049fe99877e2cf6a59610cb333 100644
--- a/docs/Prose-Style-Guidelines.md
+++ b/docs/Prose-Style-Guidelines.md
@@ -28,7 +28,7 @@ We prefer:
* British/Commonwealth English over American English, in general
* "e.g." and "i.e.": Go ahead and use "e.g." or "i.e." instead of spelling them out. Don't worry about putting a comma after them.
- * "e.g." means "for example"; "i.e." means "that is"
+ * "e.g." means "for example"; "i.e." means "that is"
* Offset nontrivial subordinate clauses with commas
### Personal pronouns
@@ -45,36 +45,36 @@ We prefer:
* Capitalize all list items if you want, even if they're not complete sentences; just be consistent within each list, and preferably, throughout the whole page
* Use a subordinate list item instead of dropping a multi-sentence paragraph-long item into a list of sentence fragments
* Prefer Markdown over other markup formats unless their specific features are needed
- * GitHub Flavored Markdown. GitHub's implementation is the standard, period.
+ * GitHub Flavored Markdown. GitHub's implementation is the standard, period.
### Typographical conventions
* Literal text in commands and code is styled in `fixed width font`
* Placeholders inside code snippets are marked up with `<...>` brackets
- * e.g. `git remote add <my-user-name> https://github.com/<my-user-name>/homebrew-core.git`
+ * e.g. `git remote add <my-user-name> https://github.com/<my-user-name>/homebrew-core.git`
* Names of commands like `git` and `brew` are styled in `fixed width font`
* No "$" with environment variables mentioned outside code snippets
- * e.g. "Set `BLAH` to 5", not "Set `$BLAH` to 5"
+ * e.g. "Set `BLAH` to 5", not "Set `$BLAH` to 5"
* One space after periods, not two
* Capitalized proper nouns
* We do not defer to extensive nonstandard capitalization, typesetting, or other styling of brand names, aside from the normal capitalization of proper nouns and simple internal capitalization
* No "TM", ™, <sup>SM</sup>, ©, ®, or other explicit indicators of rights ownership or trademarks; we take these as understood when the brand name is mentioned
* Tap names like `homebrew/core` are styled in `fixed width font`. Repository names may be styled in either fixed width font like "`Homebrew/homebrew-core`", as links like "[Homebrew/homebrew-core](https://github.com/homebrew/homebrew-core)", or regular text like "Homebrew/homebrew-core", based on which looks best for a given use.
- * But be consistent within a single document
- * Capitalize repository names to match the user and repository names on GitHub. Keep tap names in lower case.
+ * But be consistent within a single document
+ * Capitalize repository names to match the user and repository names on GitHub. Keep tap names in lower case.
* Commas
- * No Oxford commas
- * Prefer a "loose" comma style: "when in doubt, leave it out" unless needed for clarity
+ * No Oxford commas
+ * Prefer a "loose" comma style: "when in doubt, leave it out" unless needed for clarity
### Terminology, words, and word styling
* "pull request", not "Pull Request"
* "check out" is the verb; "checkout" is the noun
* Spell out certain technical words
- * "repository", not "repo"
- * When abbreviating, introduce the abbreviation with the first usage in any document
+ * "repository", not "repo"
+ * When abbreviating, introduce the abbreviation with the first usage in any document
* Some abbreviations (near-universally understood among our user base) are fine, though.
- * "Mac" is fine; "Macintosh" isn't necessary
+ * "Mac" is fine; "Macintosh" isn't necessary
* "macOS" for all versions, "OS X" or "Mac OS X" when describing specific older versions
* "RuboCop", not "Rubocop"
* A pull request is made "on" a repository; that repository is "at" a URL
diff --git a/docs/css/screen.css b/docs/css/screen.css
index 76d1461c90f5ae27943f7a11ff9c7f97286d1ab5..2f1e84ce167259d0ef0681ba9c696b3a7f7f7aab 100644
--- a/docs/css/screen.css
+++ b/docs/css/screen.css
@@ -158,8 +158,12 @@ pre code {
box-shadow: 0 -1px 0 rgba(0,0,0,0.5);
}
+#home ol, #page ol, .postcontent ol {
+ list-style: decimal;
+}
+
#home ul, #page ul, .postcontent ul {
- list-style: inherit;
+ list-style: disc;
}
#home h1, #page h1 {