From 4a3eb62282d90697d11bc156f9d99f32b16cdfb6 Mon Sep 17 00:00:00 2001
From: Titus Wormer <tituswormer@gmail.com>
Date: Tue, 1 Aug 2017 16:36:11 -0400
Subject: [PATCH 1/2] Update remark, retext

---
 test/package.json |  53 +++++++++++++++++-----
 test/prose        | 111 ++++++++++++++++++++++++++++++----------------
 2 files changed, 113 insertions(+), 51 deletions(-)

diff --git a/test/package.json b/test/package.json
index 63c9f969a83..29e2980d29f 100644
--- a/test/package.json
+++ b/test/package.json
@@ -10,23 +10,52 @@
     "js-yaml": "^3.6.1",
     "kindlegen": "^1.1.0",
     "mkdirp": "^0.5.1",
-    "remark-lint": "^5.0.0",
-    "remark-parse": "^2.0.0",
-    "remark-retext": "^2.0.0",
-    "remark-stringify": "^2.0.0",
-    "retext-english": "^2.0.0",
-    "retext-equality": "^2.3.2",
-    "retext-quotes": "^1.0.0",
-    "retext-readability": "^3.0.0",
+    "remark-frontmatter": "^1.1.0",
+    "remark-lint": "^6.0.0",
+    "remark-lint-blockquote-indentation": "^1.0.0",
+    "remark-lint-emphasis-marker": "^1.0.0",
+    "remark-lint-final-newline": "^1.0.0",
+    "remark-lint-first-heading-level": "^1.1.0",
+    "remark-lint-hard-break-spaces": "^1.0.1",
+    "remark-lint-heading-increment": "^1.0.0",
+    "remark-lint-heading-style": "^1.0.0",
+    "remark-lint-list-item-bullet-indent": "^1.0.0",
+    "remark-lint-list-item-content-indent": "^1.0.0",
+    "remark-lint-list-item-indent": "^1.0.0",
+    "remark-lint-maximum-heading-length": "^1.0.0",
+    "remark-lint-no-auto-link-without-protocol": "^1.0.0",
+    "remark-lint-no-blockquote-without-marker": "^2.0.0",
+    "remark-lint-no-consecutive-blank-lines": "^1.0.0",
+    "remark-lint-no-duplicate-definitions": "^1.0.0",
+    "remark-lint-no-duplicate-headings": "^1.0.0",
+    "remark-lint-no-heading-content-indent": "^1.0.0",
+    "remark-lint-no-inline-padding": "^1.0.0",
+    "remark-lint-no-literal-urls": "^1.0.0",
+    "remark-lint-no-missing-blank-lines": "^1.0.0",
+    "remark-lint-no-multiple-toplevel-headings": "^1.0.0",
+    "remark-lint-no-shortcut-reference-image": "^1.0.0",
+    "remark-lint-no-shortcut-reference-link": "^1.0.1",
+    "remark-lint-no-undefined-references": "^1.0.0",
+    "remark-lint-no-unused-definitions": "^1.0.0",
+    "remark-lint-ordered-list-marker-style": "^1.0.0",
+    "remark-lint-strong-marker": "^1.0.0",
+    "remark-lint-unordered-list-marker-style": "^1.0.0",
+    "remark-parse": "^4.0.0",
+    "remark-retext": "^3.0.0",
+    "remark-stringify": "^4.0.0",
+    "retext-english": "^3.0.0",
+    "retext-equality": "^3.1.0",
+    "retext-quotes": "^2.0.0",
+    "retext-readability": "^4.1.0",
     "retext-repeated-words": "^1.0.0",
-    "retext-sentence-spacing": "^1.0.0",
-    "retext-simplify": "^3.0.0",
+    "retext-sentence-spacing": "^2.0.0",
+    "retext-simplify": "^4.1.0",
     "retext-words": "bkeepers/retext-words",
     "slug": "^0.9.1",
     "to-vfile": "^2.1.0",
-    "unified": "^5.0.0",
+    "unified": "^6.1.0",
     "unist-util-visit": "^1.1.1",
-    "vfile-reporter": "^3.0.0",
+    "vfile-reporter": "^4.0.0",
     "vfile-statistics": "^1.0.0"
   }
 }
diff --git a/test/prose b/test/prose
index ab1893fcca0..e531a1ed588 100755
--- a/test/prose
+++ b/test/prose
@@ -5,9 +5,38 @@ var unified = require('unified');
 
 // Remark stuff (markdown)
 var parse = require('remark-parse');
-var lint = require('remark-lint');
 var remark2retext = require('remark-retext');
 var stringify = require('remark-stringify');
+var frontmatter = require('remark-frontmatter');
+var lint = require('remark-lint');
+var headingStyle = require('remark-lint-heading-style');
+var firstHeadingLevel = require('remark-lint-first-heading-level');
+var headingIncrement = require('remark-lint-heading-increment');
+var maximumHeadingLength = require('remark-lint-maximum-heading-length');
+var noDuplicateHeadings = require('remark-lint-no-duplicate-headings');
+var noMultipleToplevelHeadings = require('remark-lint-no-multiple-toplevel-headings');
+var listItemIndent = require('remark-lint-list-item-indent');
+var listItemBulletIndent = require('remark-lint-list-item-bullet-indent');
+var listItemContentIndent = require('remark-lint-list-item-content-indent');
+var unorderedListMarkerStyle = require('remark-lint-unordered-list-marker-style');
+var orderedListMarkerStyle = require('remark-lint-ordered-list-marker-style');
+var emphasisMarker = require('remark-lint-emphasis-marker');
+var strongMarker = require('remark-lint-strong-marker');
+var blockquoteIndentation = require('remark-lint-blockquote-indentation');
+var noMissingBlankLines = require('remark-lint-no-missing-blank-lines');
+var noConsecutiveBlankLines = require('remark-lint-no-consecutive-blank-lines');
+var finalNewline = require('remark-lint-final-newline');
+var noAutoLinkWithoutProtocol = require('remark-lint-no-auto-link-without-protocol');
+var noBlockquoteWithoutMarker = require('remark-lint-no-blockquote-without-marker');
+var noLiteralUrls = require('remark-lint-no-literal-urls');
+var hardBreakSpaces = require('remark-lint-hard-break-spaces');
+var noDuplicateDefinitions = require('remark-lint-no-duplicate-definitions');
+var noHeadingContentIndent = require('remark-lint-no-heading-content-indent');
+var noInlinePadding = require('remark-lint-no-inline-padding');
+var noShortcutReferenceImage = require('remark-lint-no-shortcut-reference-image');
+var noShortcutReferenceLink = require('remark-lint-no-shortcut-reference-link');
+var noUndefinedReferences = require('remark-lint-no-undefined-references');
+var noUnusedDefinitions = require('remark-lint-no-unused-definitions');
 
 // Retext stuff (prose)
 var english = require('retext-english');
@@ -53,52 +82,56 @@ if(process.env.FULL_PROSE_CHECK) {
 
 // Markdown checking pipeline.
 var markdown = unified()
-  .use(parse)
+  .use(parse, {footnotes: true})
+  .use(stringify)
+  .use(frontmatter, 'yaml')
+
   // https://github.com/wooorm/remark-lint/blob/master/doc/rules.md
-  .use(lint, {
-    // Headings
-    headingStyle: 'atx',             // ## Headings
-    firstHeadingLevel: 2,            // Page title is h1, so start with h2
-    headingIncrement: true,
-    maximumHeadingLength: 80,        // FIXME: Eventually remove this
-    noDuplicateHeadings: true,
-    noMultipleToplevelHeadings: true,
+  .use(lint)
 
-    // Lists
-    listItemIndent: 'space',         // As the gods intended.
-    listItemBulletIndent: true,
-    listItemContentIndent: true,
-    unorderedListMarkerStyle: '*',
-    orderedListMarkerStyle: '.',
+  // Headings
+  .use(headingStyle, 'atx')       // ## Headings
+  .use(firstHeadingLevel, 2)      // Page title is h1, so start with h2
+  .use(headingIncrement)
+  .use(maximumHeadingLength, 80)  // FIXME: Eventually remove this
+  .use(noDuplicateHeadings)
+  .use(noMultipleToplevelHeadings)
 
-    // Misc
-    emphasisMarker: '_',
-    strongMarker: '*',
-    blockquoteIndentation: 2,
-    noMissingBlankLines: {exceptTightLists: true},
-    noConsecutiveBlankLines: true,
-    finalNewline: true,
-    noAutoLinkWithoutProtocol: true,
-    noBlockquoteWithoutCaret: true,
-    noLiteralUrls: true,
+  // Lists
+  .use(listItemIndent, 'space')    // As the gods intended.
+  .use(listItemBulletIndent)
+  .use(listItemContentIndent)
+  .use(unorderedListMarkerStyle, '*')
+  .use(orderedListMarkerStyle, '.')
 
-    // Mistakes
-    hardBreakSpaces: true,
-    noDuplicateDefinitions: true,
-    noHeadingContentIndent: true,
-    noInlinePadding: true,
-    noShortcutReferenceImage: true,
-    noShortcutReferenceLink: true,
-    noUndefinedReferences: true,
-    noUnusedDefinitions: true,
-  })
-  .use(remark2retext, prose)
-  .use(stringify);
+  // Misc
+  .use(emphasisMarker, '_')
+  .use(strongMarker, '*')
+  .use(blockquoteIndentation, 2)
+  .use(noMissingBlankLines, {exceptTightLists: true})
+  .use(noConsecutiveBlankLines)
+  .use(finalNewline)
+  .use(noAutoLinkWithoutProtocol)
+  .use(noBlockquoteWithoutMarker)
+  .use(noLiteralUrls)
+
+  // Mistakes
+  .use(hardBreakSpaces)
+  .use(noDuplicateDefinitions)
+  .use(noHeadingContentIndent)
+  .use(noInlinePadding)
+  .use(noShortcutReferenceImage)
+  .use(noShortcutReferenceLink)
+  .use(noUndefinedReferences)
+  .use(noUnusedDefinitions)
+
+  // Prose
+  .use(remark2retext, prose);
 
 async.map(ignore.filter(glob.sync('_articles/**/*.md')), function(filePath, callback) {
   vfile.read(filePath, function(err, file) {
     if(err) return callback(err);
-    markdown.process(file, {footnotes: true}, callback);
+    markdown.process(file, callback);
   });
 }, function (err, results) {
   console.log(report(results));

From 57d8576d79d85160fbcde28711b2809de1fa17dc Mon Sep 17 00:00:00 2001
From: Titus Wormer <tituswormer@gmail.com>
Date: Thu, 3 Aug 2017 13:17:46 -0400
Subject: [PATCH 2/2] Add spell checking for articles
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This commit adds spell checking to all the other prose and
markdown checks currently in place.
As spell checking is a pretty pedantic issue, often marking
jargon (like 501c3, BDFL, or grantmaking) and project and
product names (like Homebrew, Kubernetes, or WordPress),
a personal `dictionary.txt` is included in `test/` with
exceptions for the articles.

URLs, filepaths, @mentions, emoji, and text in block quotes
(as those are used for quotes in the articles) are excluded
from the spell checking.

The spell checking highlighted some cases that I changed:

*   All alt text of images is now properly cases if they
    start the paragraph
*   Typo `sizeable` > `sizable` (former is GB English, latter is
    US English)
*   Casing of `reddit` > `Reddit` (latter seems to be used more)
*   Casing of `pypa` > `PyPA` (latter seems to be used more)
*   Casing of `eslint` > `ESLint` (latter is the official casing)
*   Casing of `READMES` > `READMEs` (plural `s` is now cased just
    like `PRs` and `APIs`)
*   Casing of `ok` > `OK` (latter is the propper spelling)
*   Spelling of `PostgreSQL` > `Postgres` (both were used throughout,
    the latter seems simpler and is just as well known)
*   Hyphen in `tradeoffs` > `trade-offs` (both could probably be used,
    but the latter is more often used)
*   Latin `de minimis` > `minimal` (this section is about law, so the
    Latin makes sense, but it’s also a phrase I had to look up, so
    I’m guessing other people would have to as well)
*   Space in `pageviews` > `page views` (former is more about the
    metrics in Google Analytics I believe, latter is just as good?)
*   Space in `datasets` > `data sets` (both work, but latter is more
    common?)
---
 _articles/best-practices.md            |  2 +-
 _articles/building-community.md        | 10 +--
 _articles/finding-users.md             |  8 +--
 _articles/how-to-contribute.md         | 10 +--
 _articles/leadership-and-governance.md |  4 +-
 _articles/legal.md                     |  4 +-
 _articles/metrics.md                   | 10 +--
 _articles/starting-a-project.md        |  6 +-
 test/dictionary.txt                    | 87 ++++++++++++++++++++++++++
 test/package.json                      |  5 ++
 test/prose                             | 16 ++++-
 11 files changed, 134 insertions(+), 28 deletions(-)
 create mode 100644 test/dictionary.txt

diff --git a/_articles/best-practices.md b/_articles/best-practices.md
index 428b6f803b3..cbfc5c7ff56 100644
--- a/_articles/best-practices.md
+++ b/_articles/best-practices.md
@@ -119,7 +119,7 @@ If you don't want to accept a contribution:
 
 You shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383):
 
-![celery screenshot](/assets/images/best-practices/celery.png)
+![Celery screenshot](/assets/images/best-practices/celery.png)
 
 If the thought of saying no terrifies you, you're not alone. As @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/):
 
diff --git a/_articles/building-community.md b/_articles/building-community.md
index edb4790a106..307a1cc6fb1 100644
--- a/_articles/building-community.md
+++ b/_articles/building-community.md
@@ -20,7 +20,7 @@ A welcoming community is an investment into your project's future and reputation
 
 One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://speakerdeck.com/mikemcquaid/the-open-source-contributor-funnel):
 
-![contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
+![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png)
 
 As you build your community, consider how someone at the top of the funnel (a potential user) might theoretically make their way to the bottom (an active maintainer). Your goal is to reduce friction at each stage of the contributor experience. When people have easy wins, they will feel incentivized to do more.
 
@@ -80,7 +80,7 @@ Try to be responsive when someone files an issue, submits a pull request, or ask
 
 Even if you can't review the request immediately, acknowledging it early helps increase engagement. Here's how @tdreyno responded to a pull request on [Middleman](https://github.com/middleman/middleman/pull/1466):
 
-![middleman pull request](/assets/images/building-community/middleman_pr.png)
+![Middleman pull request](/assets/images/building-community/middleman_pr.png)
 
 [A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) contributors who received code reviews within 48 hours had a much higher rate of return and repeat contribution.
 
@@ -130,7 +130,7 @@ Good documentation only becomes more important as your community grows. Casual c
 
 In your CONTRIBUTING file, explicitly tell new contributors how to get started. You may even want to make a dedicated section for this purpose. [Django](https://github.com/django/django), for example, has a special landing page to welcome new contributors.
 
-![django new contributors page](/assets/images/building-community/django_new_contributors.png)
+![Django new contributors page](/assets/images/building-community/django_new_contributors.png)
 
 In your issue queue, label bugs that are suitable for different types of contributors: for example, [_"first timers only"_](https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.g1k01jy05), _"good first bug"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) make it easy for someone new to your project to quickly scan your issues and get started.
 
@@ -158,11 +158,11 @@ See if you can find ways to share ownership with your community as much as possi
 
 * **Resist fixing easy (non-critical) bugs.** Instead, use them as opportunities to recruit new contributors, or mentor someone who'd like to contribute. It may seem unnatural at first, but your investment will pay off over time. For example, @michaeljoseph asked a contributor to submit a pull request on a [Cookiecutter](https://github.com/audreyr/cookiecutter) issue below, rather than fix it himself.
 
-![cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
+![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png)
 
 * **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md) does.
 
-* If you've got a sizeable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples.
+* If you've got a sizable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples.
 
 * **Give every contributor commit access.** @felixge found that this made people [more excited to polish their patches](http://felixge.de/2013/03/11/the-pull-request-hack.html), and he even found new maintainers for projects that he hadn't worked on in awhile.
 
diff --git a/_articles/finding-users.md b/_articles/finding-users.md
index 63f51f986b5..200db3e1b55 100644
--- a/_articles/finding-users.md
+++ b/_articles/finding-users.md
@@ -27,7 +27,7 @@ Remember that people get involved as users, and eventually contributors, because
 
 For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful:
 
-![cartography readme](/assets/images/finding-users/cartography.jpg)
+![Cartography README](/assets/images/finding-users/cartography.jpg)
 
 For a deeper dive into messaging, check out Mozilla's ["Personas and Pathways"](http://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas.
 
@@ -60,7 +60,7 @@ If you don't wish to set up these channels for your project yet, promote your ow
 
 If your project is hosted on GitHub, you can use [GitHub Pages](https://pages.github.com/) to easily make a website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) are [a few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites.
 
-![vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
+![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png)
 
 Now that you have a message for your project, and an easy way for people to find your project, let's get out there and talk to your audience!
 
@@ -68,7 +68,7 @@ Now that you have a message for your project, and an easy way for people to find
 
 Online outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience.
 
-Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](http://stackoverflow.com/), [reddit](http://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work.
+Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](http://stackoverflow.com/), [Reddit](http://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars1.githubusercontent.com/u/169328?v=3&s=400" class="pquote-avatar" alt="avatar">
@@ -90,7 +90,7 @@ If nobody pays attention or responds to your initial outreach, don't get discour
 
 ## Go where your project's audience is (offline)
 
-![public speaking](/assets/images/finding-users/public_speaking.jpg)
+![Public speaking](/assets/images/finding-users/public_speaking.jpg)
 
 Offline events are a popular way to promote new projects. It's a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers.
 
diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md
index dc71105d637..dd6d434bdf4 100644
--- a/_articles/how-to-contribute.md
+++ b/_articles/how-to-contribute.md
@@ -97,7 +97,7 @@ Even if you like to write code, other types of contributions are a great way to
 * Write and improve the project's documentation
 * Curate a folder of examples showing how the project is used
 * Start a newsletter for the project, or curate highlights from the mailing list
-* Write tutorials for the project, [like pypa's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
+* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194)
 * Write a translation for the project's documentation
 
 <aside markdown="1" class="pquote">
@@ -111,7 +111,7 @@ Even if you like to write code, other types of contributions are a great way to
 ### Do you like organizing?
 
 * Link to duplicate issues, and suggest new issue labels, to keep things organized
-* Go through open issues and suggest closing old ones, [like @nzakas did for eslint](https://github.com/eslint/eslint/issues/6765)
+* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765)
 * Ask clarifying questions on recently opened issues to move the discussion forward
 
 ### Do you like to code?
@@ -123,7 +123,7 @@ Even if you like to write code, other types of contributions are a great way to
 
 ### Do you like helping people?
 
-* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](http://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or reddit
+* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](http://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit
 * Answer questions for people on open issues
 * Help moderate the discussion boards or conversation channels
 
@@ -181,7 +181,7 @@ A project also has documentation. These files are usually listed in the top leve
 
 * **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source.
 * **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
-* **CONTRIBUTING:** Whereas READMES help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
+* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
 * **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
 * **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects.
 
@@ -399,7 +399,7 @@ Before you open an issue or pull request, or ask a question in chat, keep these
 >
 > 😢 _"X is broken! Please fix it."_
 
-**Do your homework beforehand.** It's ok not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate when you demonstrate that you're trying to learn.
+**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate when you demonstrate that you're trying to learn.
 
 > 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_
 >
diff --git a/_articles/leadership-and-governance.md b/_articles/leadership-and-governance.md
index 61205a1a70a..08d44625ba9 100644
--- a/_articles/leadership-and-governance.md
+++ b/_articles/leadership-and-governance.md
@@ -60,7 +60,7 @@ Formalizing your leadership roles helps people feel ownership and tells other co
 
 For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file.
 
-For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [PostgreSQL](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor.
+For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor.
 
 If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (ex. security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them.
 
@@ -105,7 +105,7 @@ There are three common governance structures associated with open source project
 
 * **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://nodejs.org/en/foundation/) and [Rust](https://www.rust-lang.org/en-US/).
 
-Which one should you use? It's up to you! Every model has advantages and tradeoffs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates:
+Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates:
 
 * [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel)
 * [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel)
diff --git a/_articles/legal.md b/_articles/legal.md
index 52c56d332db..c054b27c8ab 100644
--- a/_articles/legal.md
+++ b/_articles/legal.md
@@ -34,7 +34,7 @@ Finally, your project may have dependencies with license requirements that you w
 
 When you [create a new project](https://help.github.com/articles/creating-a-new-repository/) on GitHub, you have the option to make the repository **private** or **public**.
 
-![create repository](/assets/images/legal/repo-create-name.png)
+![Create repository](/assets/images/legal/repo-create-name.png)
 
 **Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/articles/github-terms-of-service/#f-copyright-and-content-ownership), which allows others to view and fork your project, but your work otherwise comes with no permissions.
 
@@ -86,7 +86,7 @@ For example, as your project grows it adds dependencies or users, or your compan
 
 **Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses.
 
-**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made _de minimis_ contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
+**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software.
 
 Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change.
 
diff --git a/_articles/metrics.md b/_articles/metrics.md
index 3aae9b2426d..88e7fd22be7 100644
--- a/_articles/metrics.md
+++ b/_articles/metrics.md
@@ -37,17 +37,17 @@ If you _are_ interested in understanding your project on a deeper level, read on
 
 Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_
 
-![traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
+![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png)
 
 If your project is hosted on GitHub, [you can view](https://help.github.com/articles/about-repository-graphs/#traffic) how many people land on your project and where they come from. From your project's page, click "Graphs", then "Traffic". On this page, you can see:
 
-* **Total pageviews:** Tells you how many times your project was viewed
+* **Total page views:** Tells you how many times your project was viewed
 
 * **Total unique visitors:** Tells you how many people viewed your project
 
 * **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working.
 
-* **Popular content:** Tells you where visitors go on your project, broken down by pageviews and unique visitors.
+* **Popular content:** Tells you where visitors go on your project, broken down by page views and unique visitors.
 
 [GitHub stars](https://help.github.com/articles/about-stars/) can also help provide a baseline measure of popularity. While GitHub stars don't necessarily correlate to downloads and usage, they can tell you how many people are taking notice of your work.
 
@@ -63,7 +63,7 @@ Each package manager may use a slightly different definition of "download", and
 
 If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners.
 
-![clone graph](/assets/images/metrics/clone_graph.png)
+![Clone graph](/assets/images/metrics/clone_graph.png)
 
 If usage is low compared to the number of people discovering your project, there are two issues to consider. Either:
 
@@ -88,7 +88,7 @@ Examples of community metrics that you may want to regularly track include:
 
 * **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Graphs" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository.
 
-![contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png)
+![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png)
 
 * **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant.
 
diff --git a/_articles/starting-a-project.md b/_articles/starting-a-project.md
index 393208329a1..0519bc1e025 100644
--- a/_articles/starting-a-project.md
+++ b/_articles/starting-a-project.md
@@ -49,7 +49,7 @@ By comparison, a closed source process would be going to a restaurant and orderi
 
 * **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt).
 
-Open source isn't just for software, either. You can open source everything from datasets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
+Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source.
 
 ### Does open source mean "free of charge"?
 
@@ -134,7 +134,7 @@ Legal work is no fun. The good news is that you can copy and paste an existing l
 
 When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source.
 
-![pick a license](/assets/images/starting-a-project/repository-license-picker.png)
+![Pick a license](/assets/images/starting-a-project/repository-license-picker.png)
 
 If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/).
 
@@ -193,7 +193,7 @@ For more help with writing your CONTRIBUTING file, check out @nayafia's [contrib
 
 Link to your CONTRIBUTING file from your README, so more people see it. If you [place the CONTRIBUTING file in your project's repository](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub will automatically link to your file when a contributor creates an issue or opens a pull request.
 
-![contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
+![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg)
 
 ### Establishing a code of conduct
 
diff --git a/test/dictionary.txt b/test/dictionary.txt
new file mode 100644
index 00000000000..394834a4430
--- /dev/null
+++ b/test/dictionary.txt
@@ -0,0 +1,87 @@
+# Dictionary of some extra words that are not in the
+# default list. The stuff after the slash is a word
+# it’s modelled after.
+# More info:
+# <https://github.com/wooorm/nspell#personal-dictionary-documents>
+
+# Normal Words
+avoidant
+bundler
+caretaking
+funder
+funders
+fundraise
+grantmaking
+incentivized
+mentorship
+namespace
+roadmap
+sponsorships
+triaging
+walkthrough
+
+# Programming jargon
+AGPLv3
+APIs
+BDFL
+CLA
+CSS
+GPLv2
+GPLv3
+OSS
+PR
+PRs
+README
+READMEs
+cloners
+linters
+
+# Jargon etc.
+501c3
+CCing
+LLC
+discoverability
+pre-launch
+relicense
+relicensing
+
+# Products
+Analytics
+CocoaPods
+CodeTriage
+Cookiecutter
+Django
+Drupal
+ESLint
+Exercism
+FOSSmarks
+Gitter
+Homebrew
+Kickstarter
+Kubernetes
+MongoDB
+NodeSchool
+OpenCollective
+OpenMRS
+PageRank
+Patreon
+Postgres
+PyPA
+PyPI
+Quora
+Rackspace
+Reddit
+Redux
+Rubinius
+Shoutouts
+Sidekiq
+Vossibility
+Vue
+WIPO
+WordPress
+b2
+jQuery
+khmer
+kops
+npm
+webpack
diff --git a/test/package.json b/test/package.json
index 29e2980d29f..0783604644b 100644
--- a/test/package.json
+++ b/test/package.json
@@ -2,6 +2,7 @@
   "private": true,
   "devDependencies": {
     "async": "^2.0.0",
+    "dictionary-en-us": "^2.0.0",
     "download": "^5.0.3",
     "ebrew": "^0.1.1",
     "fastmatter": "^1.1.1",
@@ -43,6 +44,7 @@
     "remark-parse": "^4.0.0",
     "remark-retext": "^3.0.0",
     "remark-stringify": "^4.0.0",
+    "retext-emoji": "^4.0.0",
     "retext-english": "^3.0.0",
     "retext-equality": "^3.1.0",
     "retext-quotes": "^2.0.0",
@@ -50,6 +52,9 @@
     "retext-repeated-words": "^1.0.0",
     "retext-sentence-spacing": "^2.0.0",
     "retext-simplify": "^4.1.0",
+    "retext-spell": "^2.3.0",
+    "retext-syntax-mentions": "^1.1.0",
+    "retext-syntax-urls": "^1.0.0",
     "retext-words": "bkeepers/retext-words",
     "slug": "^0.9.1",
     "to-vfile": "^2.1.0",
diff --git a/test/prose b/test/prose
index e531a1ed588..81319c1fc86 100755
--- a/test/prose
+++ b/test/prose
@@ -44,6 +44,11 @@ var sentenceSpacing = require('retext-sentence-spacing');
 var quotes = require('retext-quotes');
 var words = require('retext-words');
 var repeated = require('retext-repeated-words');
+var emoji = require('retext-emoji');
+var syntaxMentions = require('retext-syntax-mentions');
+var syntaxURLs = require('retext-syntax-urls');
+var spell = require('retext-spell');
+var enUS = require('dictionary-en-us');
 
 // Util stuff
 var vfile = require('to-vfile');
@@ -51,14 +56,23 @@ var statistics = require('vfile-statistics');
 var report = require('vfile-reporter');
 var glob = require('glob');
 var fs = require('fs');
+var path = require('path');
 var async = require('async');
 var yaml = require('js-yaml');
 var jekyllConfig = yaml.safeLoad(fs.readFileSync('_config.yml'));
 var ignore = require('ignore')().add(jekyllConfig.exclude)
 
+var personal = fs
+  .readFileSync(path.join(__dirname, 'dictionary.txt'), 'utf8')
+  .replace(/#.+/gm, '');
+
 // Prose checking pipeline
 var prose = unified()
   .use(english)
+  .use(syntaxURLs)
+  .use(syntaxMentions)
+  .use(emoji)
+  .use(spell, {dictionary: enUS, personal: personal})
   .use(sentenceSpacing, {preferred: 1})
   .use(quotes, {preferred: 'straight'})
   .use(words, {
@@ -126,7 +140,7 @@ var markdown = unified()
   .use(noUnusedDefinitions)
 
   // Prose
-  .use(remark2retext, prose);
+  .use(remark2retext, prose, {ignore: ['blockquote']});
 
 async.map(ignore.filter(glob.sync('_articles/**/*.md')), function(filePath, callback) {
   vfile.read(filePath, function(err, file) {