Ensure canonical_url works correctly

_config.yml

@@ -29,6 +29,7 @@ plugins:
   - jekyll-sitemap
   - jekyll-gist
   - jekyll-feed
+  - jekyll-seo-tag
 google_fonts:
   - name: "Source Sans Pro"
     weights: "400,400i,700,700i"

_data/authors.yml

@@ -76,3 +76,10 @@ padraig_o_brien:
   github: //github.com/padraigobrien
   twitter: padraigobrien
   bio: "Director of engineering"
+
+radhikapc:
+  name: Radhika Puthiyetath
+  picture: https://docslikecode.com/images/radhika-sysdig.png
+  github: //github.com/radhikapc
+  twitter: radhikapc
+  bio: "Principal Technical Writer"

_posts/articles/2016-09-17-github-for-docs.md

@@ -4,7 +4,7 @@ title: The Vocabulary of GitHub for Documentation
 excerpt: "What would happen if we treated docs like code?"
 last_modified_at: Sat Sep 17 07:11:52 CDT 2016
 categories: articles
-tags: [github, git, definitions, repository, branch, fork, pull request]
+tags: GitHub, git, definitions, repository, branch, fork, pull request]
 image:
   path: /images/guarded-lightbulb-rob-sinclair.jpg
   caption: "[Flickr rob-sinclair](https://flic.kr/p/8J2gDY)"
@@ -21,31 +21,31 @@ Believe me, your fellow software builders are wondering, experimenting, or alrea
 ![git]({{ site.url }}/images/git-logo.png)
 {: .pull-right}
 
-I’ve found that the principles inherent to the social web for coding work extremely well for documentation. The social web, leads to social coding, leads to social documentation.
+I’ve found that the principles inherent to the social web for coding work extremely well for documentation. The social web leads to social coding, leads to social documentation.
 
 # What is GitHub?
 
 ![GitHub]({{ site.url }}/images/github-logo.png)
 {: .pull-left}
 
-Like many tools, git and GitHub were created by fire — through a pressing need for performant and efficient source control management for theLinux kernel. Read the history in the excellent [Pro Git Book](https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git).
+Like many tools, git and GitHub were created by fire — through a pressing need for performant and efficient source control management for the Linux kernel. Read the history in the excellent [Pro Git Book](https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git).
 
-GitHub is the web interface for `git` the command-line tool, that works well on Linux, Mac, or Windows. To work with others on a project (code or docs), you merge files. This model is the opposite of using  a “lock and checkout” model, where no one else can work on the piece at the same time as you. With GitHub, you can work separately and bring it all together later. Git has a non-linear branching model that can take some learning to get used to. That said, I've found git and GitHub for docs quite practical and even inspirational.
+GitHub is the web interface for `git` the command-line tool, that works well on Linux, Mac, or Windows. To work with others on a project (code or docs), you merge files. This model is the opposite of using a “lock and checkout” model, where no one else can work on the piece at the same time as you. With GitHub, you can work separately and bring it all together later. Git has a non-linear branching model that can take some learning to get used to. That said, I've found git and GitHub for docs quite practical and even inspirational.
 
-You can keep docs in a source code repository then the developers will review all your changes prior to merging them in. Unlike traditional source code management, branches are not full copies of entire code base so they are “cheap” and “fast.” The more Agile techniques are applied to documentation, the
-more treating docs like code makes sense.
+You can keep docs in a source code repository then the developers will review all your changes before merging them in. Unlike traditional source code management, branches are not full copies of the entire code base so they are “cheap” and “fast.” The more Agile techniques are applied to documentation, the
+more treating docs like code make sense.
 
 # GitHub definitions and parallels for information
 
 I hope I'm talking to people who care a lot about words. Let's start with some vocabulary and definitions to build upon.
 
-* Branch: Indicator of divergence from base without changing the main line (or "trunk" if you like to visualize organic tree-structures to remember this term).
-* Commit: Point-in-time snapshot of repository with changes.
-* Fork (noun): Copy of the repository that is entirely yours in your namespace. In GitHub-land, forking does not have a negative connotation that it can in other contexts (such as taking an open source project in a new direction in a huff to get different contributors). Rather, it is a way to contribute openly and publicly with your account attributed.
+* Branch: Indicator of divergence from the base without changing the main line (or "trunk" if you like to visualize organic tree structures to remember this term).
+* Commit: Point-in-time snapshot of the repository with changes.
+* Fork (noun): A copy of the repository that is entirely yours in your namespace. In GitHub-land, forking does not have a negative connotation that it can in other contexts (such as taking an open-source project in a new direction in a huff to get different contributors). Rather, it is a way to contribute openly and publicly with your account attributed.
 * Fork (verb): Making a copy of the repository.
 * Issue: Defects, tasks, or feature requests.
 * Organization: Collection of group-owned repositories.
-* Pull Request: Comparison of edits to see if team wants to accept changes.
+* Pull Request: Comparison of edits to see if the team wants to accept changes.
 * Push: Move changes branch-to-branch. When you type `man git` at a Terminal prompt to read the [manual page for Git](https://www.kernel.org/pub/software/scm/git/docs/git.html), you see "Update remote refs along with associated objects," but that's more technical than we need here.
 * Repository: Collection of stored code or documentation that is written and built like code.
 * Review: Do a line-by-line comparison of a change, much like an editor would for documentation, and comment on improvements or changes.

_posts/articles/2016-09-18-github-collaborators.md

@@ -4,17 +4,17 @@ title: Collaborating on GitHub for Documentation
 excerpt: "When you work with others, your deliverables win."
 last_modified_at: Sat Sep 17 07:11:52 CDT 2016
 categories: articles
-tags: [collaboration, developers, github, git, writers]
+tags: [collaboration, developers, GitHub, git, writers]
 image:
   path: /images/stockholmlibrary-marcus_hansson.jpg
   caption: "[Flickr marcus_hansson](https://flic.kr/p/8Lrfg)"
 comments: false
 share: true
 ---
 
-Let's admit it. Writing in isolation sucks. No one to bounce ideas off of, to tell you when you're flat-out wrong or a terrible typist. Happens in organizations all the time: assignments thrown over a wall, deliverables that are project-centric instead of user-centric. The hardest can be when deadlines set by development, not docs or quality assurance, so those deliverables are always squeezed for time at the end. Less context, less empathy, less collaboration. What to do?
+Let's admit it. Writing in isolation sucks. No one to bounce ideas off of, to tell you when you're flat-out wrong or a terrible typist. Happens in organizations all the time: assignments thrown over a wall, deliverables that are project-centric instead of user-centric. The hardest can be when development set deadlines, not docs or quality assurance, so those deliverables are always squeezed for time in the end. Less context, less empathy, less collaboration. What to do?
 
-All these downfalls can be avoided when you collaborate where your readers and makers live—on GitHub. I say, go beyond content curation and curate the audience itself! Write with and for the audience. Have a developer write for her fellow developers. Make sure users have a way to share tips with each other through the documentation.
+All these downfalls can be avoided when you collaborate where your readers and makers live—on GitHub. I say, go beyond content curation and curate the audience itself! Write with and for the audience. Have a developer write for her fellow developers. Make sure users have a way to share tips through the documentation.
 
 As Andy Oram said so well in "Educating computer users: the need for community/author collaboration," "...the *value* in educational content lies in *context* (what immediate problem the reader is trying to solve) and *timeliness* (what’s true today will be outdated tomorrow)."
 
@@ -29,7 +29,7 @@ When you write with people beyond your immediate team, ensure that those contrib
 * Produce effective, time-saving, user support.
 * Build a reputation, recruiting.
 
-Harnessing these needs being met is not about gaining free labor. Contributors should be highly, highly valued, and rewarded. It's about creating opportunity to shine, and curating jobs. Because contributor graphs are available on GitHub, and because the contribution data can be mined to see that reputation being built one pull request at a time, GitHub gives rewards in a new way.
+Harnessing these needs being met is not about gaining free labor. Contributors should be highly, highly valued, and rewarded. It's about creating opportunities to shine, and curating jobs. Because contributor graphs are available on GitHub, and because the contribution data can be mined to see that reputation being built one pull request at a time, GitHub gives rewards in a new way.
 
 If you think this all sounds nice but impractical, I encourage you to sign up for the newsletter to learn how to practice these techniques like you would a musical instrument. You need hands-on experience and time to play to get better and better.
 

_posts/articles/2016-09-23-doc-issues-tracking.md

@@ -4,7 +4,7 @@ title: Quality Tracking with GitHub for Docs
 excerpt: "What do you do when people say, 'The Docs Suck.'?"
 last_modified_at: Fri Sep 23 21:03:14 CDT 2016
 categories: articles
-tags: [developers, github, git, improvement, quality, testing, writers]
+tags: [developers, GitHub, git, improvement, quality, testing, writers]
 image:
   path: /images/stacked-logs-mtischendorf.jpg
   caption: "[Flickr mtischendorf](https://flic.kr/p/aAb4s8)"
@@ -39,7 +39,6 @@ To take it a step further, you can also add a link to edit the source doc file i
 
 In traditional enterprise doc systems, writers can go weeks without getting reviews or input. Even when asking and nagging multiple times, sometimes the documentation systems are so separate from code systems that technical reviews are through email. GASP. Put those days behind you and go where the technically knowledgeable people are.
 
-Working in the same collaboration tools as technical people gives better reviews. We can merge as many as 50 patches per day, though in reality it's about a dozen a day. We are running up to four automated doc tests per patch and requiring two humans to check the patch and click in order to publish. Each reviewer who can publish must adhere to our review rules, and people follow the rules really well.
-
+Working with the same collaboration tools as technical people gives better reviews. We can merge as many as 50 patches per day, though, in reality, it's about a dozen a day. We are running up to four automated doc tests per patch and requiring two humans to check the patch and click to publish. Each reviewer who can publish must adhere to our review rules, and people follow the rules well.
 
 {% include sign-up.html %}

_posts/articles/2016-09-24-what-docs-like-code-looks-like.md

@@ -4,7 +4,7 @@ title: Building Docs Like Code
 excerpt: "Let's look at a live example."
 last_modified_at: Sun Sep 25 15:35:08 CDT 2016
 categories: articles
-tags: [developers, github, git, improvement, quality, testing, writers]
+tags: [developers, GitHub, git, improvement, quality, testing, writers]
 image:
   path: /images/threeblackdots-playground.jpg
   caption: "[Flickr threeblackdots](https://flic.kr/p/8tQAGQ)"
@@ -13,7 +13,7 @@ comments: false
 share: true
 ---
 
-Let's take a look at what docs like code looks like in practice.
+Let's take a look at what docs as code looks like in practice.
 
 The basic steps on a Mac are:
 
@@ -24,11 +24,10 @@ The basic steps on a Mac are:
 1. Run `bundle exec jekyll serve` to serve the content from a local web server.
 1. Copy and paste the `http://127.0.0.1:4000/` URL into your web browser.
 
-This video shows you how to clone a GitHub repo with an existing Jekyll theme, and build it locally.
+This video shows you how to clone a GitHub repo with an existing Jekyll theme and build it locally.
 
 ### How it's made
 
 <iframe width="560" height="315" src="https://www.youtube.com/embed/{{ include.id }}" frameborder="0" allowfullscreen></iframe>
 
-
 {% include sign-up.html %}

_posts/articles/2016-11-26-remodel-your-docs.md

@@ -4,23 +4,23 @@ title: Remodeling documentation
 excerpt: "Make sure you have a punch list of doc bugs to get higher quality results."
 last_modified_at: Sat May 13 18:34:40 CDT 2017
 categories: articles
-tags: [issues, bugs, technical debt, github, git, backlog]
+tags: [issues, bugs, technical debt, GitHub, git, backlog]
 image:
   path: /images/mtischendorf-logpile.jpg
   caption: "[Flickr mtischendorf](https://flic.kr/p/aAb4s8)"
 comments: false
 share: true
 ---
 
-A few years ago we went house-hunting in Austin, Texas. One house was so popular during the first showing, there were six back-to-back appointments. We waited in the driveway while another couple toured it. Once they left, we could quickly go through it while another prospective buyer waited on the front walkway.
+A few years ago we went house-hunting in Austin, Texas. One house was so popular during the first showing, that there were six back-to-back appointments. We waited in the driveway while another couple toured it. Once they left, we could quickly go through it while another prospective buyer waited on the front walkway.
 
-This house was awful. Every single surface was ugly, out-dated, and circa 1973. There was a giant hole in dirt by the front porch, likely dug by an animal. But you know what? I loved it. I wanted to bring it back to a vibrant family home, taking it back from the rogue porch-dwelling raccoons — or was it dirt-digging armadillos? We may never know.
+This house was awful. Every single surface was ugly, outdated, and circa 1973. There was a giant hole in the dirt by the front porch, likely dug by an animal. But you know what? I loved it. I wanted to bring it back to a vibrant family home, taking it back from the rogue porch-dwelling raccoons. (Or was it dirt-digging armadillos? We may never know.)
 
 ![Raccoon visiting](../../images/trikersticks-raccoon.jpg "Raccoon visiting")
 
 Let’s look at your code base and your doc base as a great house with a good layout and foundational “bones.” You still need that “punch list” to hand to your contractor. When you move towards more docs like code techniques, make sure you treat your doc base like a code base, and track defects. Get that “punch list” done.
 
-With a code base, you know how much remodeling you need to do. The same thinking can work well for docs. How dated have your docs become? How accurate are the docs compared to the rest of the code base? How can you make the site livable and vibrant again?
+With a code base, you know how much remodeling you need to do. The same thinking can work well for documentation. How dated have your docs become? How accurate are the docs compared to the rest of the code base? How can you make the site livable and vibrant again?
 
 Let’s give your readers the chance to do those quality checks for you as easily as possible: by reporting the bug on the page where they found it.
 
@@ -32,9 +32,9 @@ This technique works well when:
 * You want your docs to be more trustworthy by chipping away at a bug backlog.
 * You have a private GitHub repo for documentation, but you want to enable public bug reports with tracking back to your docs repo.
 
-Your quick win is to look at your current docs site, any given page. Is there a way to report a bug publicly, to add to the “punch list?”
+Your quick win is to look at your current docs site, on any given page. Is there a way to report a bug publicly, to add to the “punch list?”
 
-1. Bare minimum starter level would be an email address link from every page.
+1. A bare minimum starter level would be an email address link from every page.
 1. Level up by adding a link to your GitHub source repo Issues page so readers can report bugs.
 1. Better yet, write a quick bit of code to embed on every output doc page so that the issue is pre-filled with relevant information.
 
@@ -44,5 +44,4 @@ Here are some resources to get your first punch in that punch list:
 * Using a private repo for docs, but want to track bugs publicly? Use [Issues-only Access Permissions](https://help.github.com/articles/issues-only-access-permissions/).
 * Want to add a bit of code to pre-create Issues to use as comments on every page? Free yourself from Disqus comments. Try this [set of tips and sample code in a blog post](https://zpbappi.com/jekyll-with-tags-archive-and-comments-in-github-pages/).
 
-
 {% include sign-up.html %}

_posts/articles/2016-12-29-coming-soon-writing-docs-like-code.md

@@ -4,7 +4,7 @@ title: Coming Soon - Write Docs Like Code Ebook
 excerpt: "What do you want to know about these techniques?"
 last_modified_at: Thu Dec 29 20:07:26 CST 2016
 categories: articles
-tags: [ebook, epub, gitbook, book, github, docs, repos]
+tags: [ebook, epub, gitbook, book, GitHub, docs, repos]
 image:
   path: /images/seabamirum-common-redpoll.jpg
   caption: "[Flickr seabamirum](https://flic.kr/p/dFow3k)"