diff --git a/_drafts/a-round-of-applause-semantic-release-for-the-clapper-component.markdown b/_drafts/a-round-of-applause-semantic-release-for-the-clapper-component.markdown
index de00e4a85..32054a84c 100644
--- a/_drafts/a-round-of-applause-semantic-release-for-the-clapper-component.markdown
+++ b/_drafts/a-round-of-applause-semantic-release-for-the-clapper-component.markdown
@@ -63,9 +63,9 @@ Take a look at [semantic-release's own release page for v23.0.0](https://github.
 
 ### Prepare
 
-This step is implemented by [npm plugin][npm-plugin] and [GitHub plugin][github-plugin], to prepare bundles for release - a tarball for the npm package, and zip and tarball of source code for the GitHub release. However, there are important differences in the bundles generated for the two.
+This step is implemented by [npm plugin][npm-plugin] and [GitHub plugin][github-plugin], to prepare bundles for release - a tarball for the npm package, and zip and tarball of source code for the GitHub release. However, there are important differences between the bundles generated for the two.
 
-It is [recommended not to increment version number](https://semantic-release.gitbook.io/semantic-release/support/faq#making-commits-during-the-release-process-adds-significant-complexity) in the GitHub repo during a release, as that adds a lot of complexity: the release process will need permissions to create and push a commit, which is likely to be restricted on the release branch. Instead, you will see in the [applause-button package.json](https://github.com/ColinEberhardt/applause-button/blob/master/package.json#L4) we have version set to "0.0.0-semantically-managed", to indicate we don't need to worry about version numbering during development. This is a key tenet of semantic versioning: let code changes determine release numbering, rather than working towards pre-determined releases.
+It is [recommended not to increment version number](https://semantic-release.gitbook.io/semantic-release/support/faq#making-commits-during-the-release-process-adds-significant-complexity) in the GitHub repo during a release, as that adds a lot of complexity: the release process will need permissions to create and push a commit, which is likely to be restricted on the release branch. Instead, you will see in the [applause-button package.json](https://github.com/ColinEberhardt/applause-button/blob/master/package.json#L4) we have version set to `0.0.0-semantically-managed`, to indicate we don't need to worry about version numbering during development. This is a key tenet of semantic versioning: let code changes determine release numbering, rather than working towards pre-determined releases.
 
 However, we do need our package in npm to have the correct version number, so the [npm plugin][npm-plugin] makes that change locally before creating the tarball, using the version number calculated in the Analyze Commits step. Additionally, we have an npm script (`prepack`) which runs the build before packaging, to generate  production-ready JavaScript and CSS files. Therefore the package tarball also contains a dist folder with these assets, which the GitHub source bundles do not have.