diff --git a/Gemfile.lock b/Gemfile.lock
index d70902d0..3a85cec3 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,7 +1,7 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    activesupport (5.2.0)
+    activesupport (5.2.1)
       concurrent-ruby (~> 1.0, >= 1.0.2)
       i18n (>= 0.7, < 2)
       minitest (~> 5.1)
@@ -64,7 +64,7 @@ GEM
       jemoji (~> 0.8)
     jekyll-watch (2.0.0)
       listen (~> 3.0)
-    jemoji (0.10.0)
+    jemoji (0.10.1)
       gemoji (~> 3.0)
       html-pipeline (~> 2.2)
       jekyll (~> 3.0)
@@ -82,15 +82,15 @@ GEM
       mini_portile2 (~> 2.3.0)
     nokogiri (1.8.4-x64-mingw32)
       mini_portile2 (~> 2.3.0)
-    octokit (4.9.0)
+    octokit (4.11.0)
       sawyer (~> 0.8.0, >= 0.5.3)
     pathutil (0.16.1)
       forwardable-extended (~> 2.6)
-    public_suffix (3.0.2)
+    public_suffix (3.0.3)
     rb-fsevent (0.10.3)
     rb-inotify (0.9.10)
       ffi (>= 0.5.0, < 2)
-    rouge (3.1.1)
+    rouge (3.2.1)
     ruby_dep (1.5.0)
     safe_yaml (1.0.4)
     sass (3.5.7)
@@ -113,4 +113,4 @@ DEPENDENCIES
   jekyll-theme-so-simple
 
 BUNDLED WITH
-   1.16.1
+   1.16.3
diff --git a/_config.yml b/_config.yml
index 4689f44a..876d7f39 100644
--- a/_config.yml
+++ b/_config.yml
@@ -2,7 +2,7 @@
 
 title: Let's Treat Docs Like Code
 locale: en-US
-description: Read stories, learn through adventures, share with others.
+description: Read stories, learn through practice, share with others.
 logo: /images/treat-docs-like-code.png
 #url: http://127.0.0.1:4000
 url: https://www.docslikecode.com
@@ -25,9 +25,6 @@ footer_links:
 permalink:   /:categories/:title/
 markdown:    kramdown
 highlighter: rouge
-sass:
-  sass_dir: _sass
-  style: compressed
 plugins:
   - jekyll-sitemap
   - jekyll-gist
@@ -48,6 +45,31 @@ kramdown:
 
 mathjax: false
 
+# Collection for workshops and tutorials
+collections:
+  learn:
+    output: true
+    permalink: /:collection/:path/
+
+# Front Matter Defaults
+defaults:
+  # Post defaults
+  - scope:
+      path: "_posts"
+      type: posts
+    values:
+      layout: post
+      comments: false
+      share: true
+  # Workshop defaults
+  - scope:
+      path: "_learn"
+      type: learn
+    values:
+      layout: post
+      comments: true
+      share: true
+
 include: [".htaccess"]
 exclude: ["_drafts", "lib", "config.rb", "Capfile", "config", "log", "Rakefile", "Rakefile.rb", "tmp", ".less", "*.sublime-project", "*.sublime-workspace", "test", "spec", "Gruntfile.js", "package.json", "node_modules", "Gemfile", "Gemfile.lock", "LICENSE", "README.md", "vendor"]
 
diff --git a/_data/navigation.yml b/_data/navigation.yml
index aef8b96b..2405df51 100644
--- a/_data/navigation.yml
+++ b/_data/navigation.yml
@@ -9,6 +9,9 @@
 - title: Book
   url: /book/
 
+- title: Learn
+  url: /learn/
+
 - title: Search
   url: /search/
 
diff --git a/_learn/01-sphinx-python-rtd.md b/_learn/01-sphinx-python-rtd.md
new file mode 100644
index 00000000..2dbccdb7
--- /dev/null
+++ b/_learn/01-sphinx-python-rtd.md
@@ -0,0 +1,160 @@
+---
+title: "Set Up Sphinx with Python"
+image:
+  path: /images/learn/sphinx-docs-page.png
+  thumbnail: /images/learn/python-logo400x200.png
+  caption: "Screenshot from Read the Docs theme"
+---
+
+Sphinx works with either major versions of Python active today, Python 2 and Python 3. Python 3 is the current and recommended version. Sphinx is a documentation tool that creates HTML, CSS, and JavaScript files from [ReStructured](http://docutils.sourceforge.net/rst.html) text files.
+
+In case you need both versions, this tutorial walks through both on a Mac. Refer to the [Downloads on the Python site](https://www.python.org/downloads/windows/) for Windows.
+
+#### Installing Python 2.7.x on Mac
+
+1. Open a terminal and use `brew` to install Python 2.7.x.
+
+    ```
+    brew install python@2
+    ```
+
+#### Installing Python 3.x
+
+You also want the latest version of Python 3 available.
+
+1. Open a terminal and use brew to install the latest Python 3.x (currently 3.7).
+
+    ```
+    brew install python
+    ```
+
+#### Verifying Python 2 and Python 3
+
+1. Open a terminal.
+1. Verify that Python 2 is correctly installed.
+
+    ```
+    python2.7 -V
+    ```
+    Expected output for August 2018:
+    ```
+    Python 2.7.15
+    ```
+1. Verify that Python 3 is correctly installed.
+
+    ```
+    python3.7 -V
+    ```
+    Expected output for August 2018:
+    ```
+    Python 3.7.0
+    ```
+
+1. Check the version set as the default version, the version of Python that is executed when you simply enter `python`.  The default version of Python remains a Python 2.7 version.
+
+    ```
+    python -V
+    ```
+    Expected output for August 2018:
+    ```
+    Python 2.7.15
+    ```
+## Set Up Virtual Environment
+
+Let's ensure that you know how to create Python Virtual Environments for each version of Python. These [Python Virtual Environments](https://docs.python.org/3/tutorial/venv.html) provide a method of creating isolated "environments" where you can work with specific versions of Python along with independent sets of libraries and dependencies.
+
+Most people use Virtual Environments because it's a recommended practice when working in Python to ensure a known starting point or state.
+
+**Python 3**
+
+1. First create a Python 3 virtual environment using the `venv` module included with Python 3. Notice the example uses `python3.7` to be clear which version of Python you want.
+
+    ```
+    python3.6 -m venv py3-sphinx
+    ```
+
+1. Now "activate" the environment. Look for the name of the virtual environment enclosed in parenthesis after activation.
+
+    ```
+    source py3-sphinx/bin/activate
+    ```
+
+    ```
+    # Expected Output
+    (py3-sphinx) $
+    ```
+
+1. Now verify that `python` is now linked to Python 3.
+
+    ```
+    (py3-sphinx) $ python -V
+    ```
+
+    ```
+    (py3-sphinx) $ Python 3.7.0
+    ```
+
+## Install Sphinx in the Virtual Environment
+
+1. With the virtual environment activated, install Sphinx.
+
+   ```
+   (py3-sphinx) $ pip install sphinx
+   ```
+
+1. To verify that sphinx is installed, run the `sphinx-build` command with the `--help` parameter.
+
+   ```
+   (py3-sphinx) $ sphinx-build --help
+   ```
+
+## Create a Basic Sphinx Project
+
+You can also get familiar with [ReStructured text](http://docutils.sourceforge.net/docs/user/rst/quickstart.html), a plain text markup syntax system that you use to write content in Sphinx documentation. Sphinx can also accept [Markdown](https://commonmark.org/help/) files.
+
+1. Create a new directory for your project:
+  ```
+  (py3-sphinx) $ mkdir do-docs-as-code
+  ```
+1. With the virtual environment still activated, run `sphinx-quickstart`, which creates a starting project for a Sphinx documentation project.
+  ```
+  $ sphinx-quickstart
+  ```
+1. Answer all the questions from the prompts.
+  You can choose enter to pick all the defaults and get a working project in the current directory (`.`).
+
+  Some notes for the context of this tutorial:
+  * You can either use a directory named `_build` within the root path, or have separate `source` and `build` directories, which is the default.
+  * Note that you can choose "githubpages set to yes" to create a `.nojekyll` file to publish the document on GitHub pages. In our case, though, our example builds to Read the Docs, so you can use the defaults throughout.
+1. Once you have the basics answered, the script creates the necessary files and you can edit those to your liking.
+1. Create a couple of `.rst` files and add skeleton information for starters.
+  ```
+  $ touch source/prerequisites.rst
+  $ touch source/about.rst
+  ```
+1. Edit those new `.rst` files in your favorite text editor.
+1. Now, you can build the docs to see the changes locally:
+  ```
+  $ make html
+  ```
+1. In your browser, open the `build/html/index.html` file to take a look at your Sphinx site locally. You can also look at `build/html/prerequisites.html` and `build/html/about.html` though they won't be linked to the main page until you add them as a link or in a table of contents entry.
+1. Edit the `source/index.rst` file to include links to the additional pages. Here is an example:
+  ```
+  .. toctree::
+     :maxdepth: 2
+     :caption: Contents:
+
+     about.rst
+     prerequisites.rst
+  ```
+1. Build again to see these changes locally:
+  ```
+  $ make html
+  ```
+1. In your browser, refresh the `build/html/index.html` page to see the new Contents with two entries linked.
+1. Make sure you commit your changes to the Git repository by following the steps in [Working with content in GitHub repositories](https://docslikecode.com/learn/04-add-content-workflow/).
+
+## Additional resources
+
+[Sphinx Python Documentation Generator](http://www.sphinx-doc.org/en/stable/)
+[ReStructured text documentation](http://docutils.sourceforge.net/rst.html)
diff --git a/_learn/02-jekyll-ruby-gh-pages.md b/_learn/02-jekyll-ruby-gh-pages.md
new file mode 100644
index 00000000..08138f40
--- /dev/null
+++ b/_learn/02-jekyll-ruby-gh-pages.md
@@ -0,0 +1,180 @@
+---
+title: "Set Up Ruby with Jekyll"
+image:
+  path: /images/learn/jekyll-docs-page.png
+  thumbnail: /images/learn/ruby-logo400x200.png
+  caption: "Screenshot using Minimal Mistakes theme"
+---
+
+Jekyll is a Static Site Generator that typically accepts [Markdown](http://commonmark.org/help/) for authoring. [Jekyll](https://jekyllrb.com/) has its own documentation site and a [Quickstart](https://jekyllrb.com/docs/). To prepare your environment to build Jekyll sites locally, follow the instructions for either Windows or MacOS.
+
+## Set up Ruby and Jekyll on Windows with Docker
+
+On Windows, first install [Docker](https://docs.docker.com/docker-for-windows/) and [Git Bash](https://gitforwindows.org/), so that you are able to use Linux-based Docker images and commands. Then follow these steps to set up Jekyll and Ruby.
+
+1. Open Git Bash.
+1. Make sure that Docker commands run in Git Bash by checking the version value:
+```
+$ docker --version
+```
+1. Next, get a copy of the Jekyll Docker image that has all the gems for GitHub Pages deployment with this command:
+```
+$ docker pull jekyll/jekyll:pages
+```
+1. Now, you can run Jekyll with Ruby within the Docker image with one command, aliased and run in Git Bash.
+
+Let's make an alias though so you can follow the rest of the commands in this instruction set. Open Git Bash and then set up Notepad as your default editor by typing:
+
+```
+$ git config core.editor notepad
+```
+The, you can type this in Git Bash to edit the `.bash_profile` file in Notepad:
+```
+$ notepad .bash_profile
+```
+
+Or, open `.bash_profile` in the Vim editor if you prefer to remain in Git Bash:
+```
+$ vim .bash_profile
+```
+1. Next, copy these two commands into the `.bash_profile` file:
+```
+alias jekyll="docker run --rm --volume=$(pwd):/srv/jekyll -p 4000:4000  jekyll/jekyll:pages jekyll"
+alias jekyll-serve="docker run --rm --volume=$(pwd):/srv/jekyll -p 4000:4000  jekyll/jekyll:pages jekyll serve --watch --incremental --force_polling"
+```
+1. Save the `.bash_profile` file and close the editor. On Vim, you save and close by entering command by pressing the **esc** key and then typing **colon*** + **w** + **q**, `:wq`, and then pressing **enter**.
+
+When you start Git Bash the next time, the `.bash_profile` is automatically run and then the two commands, `jekyll` and `jekyll-serve` become available in Git Bash, run in Docker.
+
+## Set up Ruby and Jekyll on MacOS
+
+1. Install Homebrew. See the [Homebrew site](https://brew.sh) for instructions.
+1. Use Homebrew to install a Ruby version manager.
+
+   ```
+   $ brew install rbenv ruby-build
+   ```
+
+1. Add rbenv to bash so that it loads every time you open a terminal.
+
+   ```
+   $ echo 'if which rbenv > /dev/null; then eval "$(rbenv init -)"; fi' >> ~/.bash_profile
+   ```
+
+1. Source your `.bash_profile` file.
+
+   ```
+   $ source ~/.bash_profile
+   ```
+
+1. Install a specific version of Ruby.
+
+   ```
+   $ rbenv install 2.3.1
+   $ rbenv global 2.3.1
+   $ ruby -v
+   ```
+
+## Starting a Jekyll site
+
+This [help page from GitHub](https://help.github.com/articles/setting-up-your-github-pages-site-locally-with-jekyll/) provides a great starting point for building a Jekyll site. In our case, we have a specific theme, minimal-mistakes, that we want to use, so these instructions offer exact steps.
+
+1. Install the Bundler gem, which helps with Ruby dependencies.
+
+   ```
+   $ gem install bundler
+   ```
+1. In the folder where you want to create the project, start with a new Jekyll build and use the `jekyll new` command. Use `.` to indicate you want it created in the current directory.
+   ```
+   $ jekyll new .
+   ```
+1. Take a look at the files created in the directory with an `ls` command:
+
+```
+$ ls -A
+.gitignore	Gemfile		_config.yml	about.md
+404.html	Gemfile.lock	_posts		index.md
+```
+1. Edit `_config.yml` in any text editor you like. Add these lines to ensure you use the Minimal Mistakes theme, and choose a color collection for the theme:
+
+```
+# Theme Settings
+#
+# Review documentation to determine if you should use `theme` or `remote_theme`
+# https://mmistakes.github.io/minimal-mistakes/docs/quick-start-guide/#installing-the-theme
+
+theme                  : "minimal-mistakes-jekyll"
+# remote_theme           : "mmistakes/minimal-mistakes"
+minimal_mistakes_skin    : "default" # "air", "aqua", "contrast", "dark", "dirt", "neon", "mint", "plum", "sunrise"
+
+```
+1. Also in the `_config.yml` file, edit the following:
+
+* `title: "Site Title"`: Enter the title you want for the site that appears in the `<title>` tag.
+* `name: "Your Name"`: Enter the name for the authorship and ownership of the site. Could be a company name or team name.
+* `description: "An amazing website."`: Write a one-line description of the site and its purpose.
+
+You can work on the rest of the settings as you continue to build out the site.
+1. Move the root `index.md` file to `index.html` to work best with the Minimal Mistakes theme.
+```
+$ mv index.md index.html
+```
+1. Write any text you want to appear on the landing page, below the front matter, which indicates to the theme how to build the file.
+
+```
+---
+layout: home
+author_profile: true
+---
+
+Welcome to our site! Please take a look around at the content available.
+```
+
+1. In the `Gemfile` in the root directory, replace gem "jekyll" with:
+```
+gem "github-pages", group: :jekyll_plugins
+```
+
+1. Run `bundle update` and verify that all gems install properly.
+```
+$ bundle update
+```
+If you see an error, copy the error and enter it into Google to search for solutions to the error message.
+
+> Note: If you are working on an already-set-up Jekyll site, run `bundle install` the first time you are in a Jekyll docs directory or when you need to pick up theme changes locally.
+
+## Build a Jekyll site locally
+
+Once you've prepared your environment, you can build locally and review the site in your browser.
+
+1. Run the serve command.
+
+   ```
+   $ bundle exec jekyll serve
+   Configuration file: /path/to/configuration/file/project-name/_config.yml
+   Configuration file: /path/to/configuration/file/project-name/_config.yml
+               Source: /path/to/configuration/file/project-name
+          Destination: /path/to/configuration/file/project-name/_site
+    Incremental build: disabled. Enable with --incremental
+         Generating...
+                       done in 22.964 seconds.
+    Auto-regeneration: enabled for '/path/to/configuration/file/project-name'
+   Configuration file: /path/to/configuration/file/project-name/_config.yml
+       Server address: http://127.0.0.1:4000/
+     Server running... press ctrl-c to stop.
+   ```
+
+1. Use the **Server address** URL  `http://127.0.0.1:4000/latest/` in a browser to preview the content.
+
+1. Press `Ctrl+C` in the serve terminal to stop the server.
+    > ***TIP***
+    > Leave the serve terminal open and running. Every time you save changes to a file, it automatically regenerates the site so you can test the output as you write. That said, if you change the `_config.yml` file, you must stop (ctrl-c) and then re-run the serve command to see changes.
+
+1. Don't forget to add the files to a commit and then commit the changes so that you can track the changes and work with others on GitHub. Refer to [Working with content in GitHub repositories](https://docslikecode.com/learn/04-add-content-workflow/).
+
+## Additional resources
+
+[Markdown reference](http://commonmark.org/help/)
+[Documentation Theme for Jekyll](https://idratherbewriting.com/documentation-theme-jekyll/)
+[Lynda.com Web foundations, GitHub Pages](https://www.lynda.com/Web-Development-tutorials/GitHub-pages/609031/654613-4.html)
+[Jekyll documentation about GitHub Pages](https://jekyllrb.com/docs/github-pages/)
diff --git a/_learn/03-hugo-go-netlify.md b/_learn/03-hugo-go-netlify.md
new file mode 100644
index 00000000..1d07cb89
--- /dev/null
+++ b/_learn/03-hugo-go-netlify.md
@@ -0,0 +1,131 @@
+---
+title: "Set Up Go with Hugo"
+image:
+  path: /images/learn/hugo-docs-page.png
+  thumbnail: /images/learn/go-logo400x200.png
+  caption: "Screenshot using Gravatar theme"
+---
+
+To build Hugo sites locally, install Homebrew and Hugo. You do not need to install Go to use Hugo as your static site generator. These instructions are for a Mac or Linux system, but you can also read the Windows installation instructions on the [gohugo.io](https://gohugo.io/getting-started/installing#windows) site.
+
+Since Hugo is built on Go, you can use the binary for your operating system. No need to maintain a development environment. Upgrades are easy too, get a new binary and install it and you're upgraded.
+
+## Set up Hugo on Windows with Git Bash and Docker
+
+You can also set up Docker and then use this [Docker image](https://hub.docker.com/r/jguyomard/hugo-builder/), and set up alias commands for `hugo` running in Docker, but using the same `hugo` commands in Git Bash on Windows.
+
+## Set up Hugo on MacOS
+1. Install Homebrew. See the [Homebrew site](https://brew.sh) for instructions.
+1. Use Homebrew to install Hugo.
+
+   ```
+   $ brew install hugo
+   ```
+
+1. Verify the `hugo` installation by checking the version value.
+
+   ```
+   $ hugo version
+   Hugo Static Site Generator v0.42.1 darwin/amd64
+   ```
+
+## Starting a Hugo site
+
+For a Hugo static site, you can choose your specific theme after you create the source files. The theme we'll use in this tutorial is [hugo-theme-learn](https://themes.gohugo.io/hugo-theme-learn/). To start a new site in the current folder, run:
+
+   ```
+   $ hugo new site docs-as-code
+   ```
+
+1. Take a look at the files created in the directory with an `ls` command:
+  ```
+  $ ls -A
+  archetypes	content		layouts		themes
+  config.toml	data		static
+  ```
+1. Edit `config.toml` in any text editor you like to get started. Choose a title for your site and the theme, in our case, `hugo-theme-learn`. The theme name in your configuration file must match the name of the specific theme directory inside the `/themes` directory, so we will add those files in the next step.
+  ```
+  baseURL = "http://example.org/"
+  languageCode = "en-us"
+  title = "Learning Hugo Site"
+  theme = "hugo-theme-learn"
+  ```
+1. To get the theme files in the `/themes` directory, change to the themes directory, and then use a `git clone` command to get the required theme files.
+  ```
+  $ cd themes
+  $ git clone https://github.com/matcornic/hugo-theme-learn.git
+  ```
+1. For Hugo, the `content` folder contains the site source content. For your home page, make an `_index.md` document in the `content` folder and write it with Markdown content. Switch back up one level since you just cloned the theme files.
+  ```
+  $ cd ..
+  $ hugo new _index.md
+  ```
+1. Next, add a new page using the `hugo` command, `hugo new`:
+  ```
+  $ hugo new prerequisites.md
+  /Users/agentle/src/hugo-example/doc-machine/content/prerequisites.md created
+  ```
+1. You can keep adding files with the `hugo new` command so that the Markdown files are pre-populated with the front matter:
+  ```
+  ---
+  title: "Prerequisites"
+  date: 2018-06-16T10:38:19-05:00
+  draft: true
+  ---
+  ```
+
+## Build a Hugo site locally
+
+Once you've prepared your local system, you can build locally and review the site in your browser.
+
+For Hugo, it's important to know that draft pages are only served when using the `-D` parameter.
+
+1. Run the `hugo server` command with the `-D` parameter.
+
+   ```
+   $ hugo server -D
+
+                         | EN
+      +------------------+----+
+        Pages            | 12
+        Paginator pages  |  0
+        Non-page files   |  0
+        Static files     | 67
+        Processed images |  0
+        Aliases          |  0
+        Sitemaps         |  1
+        Cleaned          |  0
+
+      Total in 48 ms
+      Watching for changes in /Users/agentle/src/hugo-example/doc-machine/{content,data,layouts,static,themes}
+      Watching for config changes in /Users/agentle/src/hugo-example/doc-machine/config.toml
+      Serving pages from memory
+      Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
+      Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
+      Press Ctrl+C to stop
+   ```
+
+1. Open the **Web Server** URL, `http://localhost:1313/` in your local browser to view the site.
+
+1. Press `Ctrl+C` in the server terminal to stop the Hugo server.
+1. You can add your files to a Git commit. Refer to [Working with content in GitHub repositories](https://docslikecode.com/learn/04-add-content-workflow/) for a documentation workflow with your Hugo site.
+
+## Modify the Hugo theme
+
+By default, the Hugo Theme "Learn" has a purple sidebar. How about changing the color and logo displayed in the sidebar? Here's how. While we're at it, let's make sure to configure the search tool that works best with this theme.
+
+1. Edit the `config.toml` file and add these lines to the `config.toml` file. This example shows setting the `themeVariant` to `green`.
+```
+[params]
+themeVariant = "green"
+```
+1. You can make sure that the theme works with the `lunr.js` [JavaScript search engine](https://lunrjs.com/) by adding these lines to the `config.toml` file.
+```
+[outputs]
+home = [ "HTML", "RSS", "JSON"]
+```
+
+## Additional resources
+
+[Hugo Quickstart](https://gohugo.io/getting-started/quick-start/)
+[Hugo Themes web site](https://themes.gohugo.io/)
diff --git a/_learn/04-add-content-workflow.md b/_learn/04-add-content-workflow.md
new file mode 100644
index 00000000..0e250521
--- /dev/null
+++ b/_learn/04-add-content-workflow.md
@@ -0,0 +1,140 @@
+---
+title: "Working with content in GitHub repositories"
+image:
+  path: /images/learn/octocat.png
+  thumbnail: /images/learn/octocat-github-logo400x200.png
+  caption: "Logo from [GitHub](https://github.com)"
+---
+
+This section goes through the workflow for adding content, editing pages, and generally working on a docs site in a GitHub repo.
+
+## Add content to the site
+
+Once you have created files required by your static site generator, you can start writing. Begin with the index, or home page.
+
+For Sphinx, you can write in either Restructured Text (`.rst`) or Markdown (`.md`). For Jekyll and Hugo, you write your source files in Markdown.
+
+Introduce your documentation and what you intend for the reader to find on the docs site. Explain some background, and feel free to add more pages with the `.rst` or `.md` file extension.
+
+You can organize your source documentation files in folders, and those folder names become part of the URL for the documentation page.
+
+A simple starter set of files could look like this for Sphinx:
+```
+source/index.rst
+source/prerequisites.rst
+source/how-to-create-a-project.rst
+source/reference-list.rst
+```
+
+Or this for Jekyll:
+```
+index.html
+_pages/prerequisites.md
+_pages/how-to-create-a-project.md
+_pages/reference-list.md
+```
+Or this for Hugo:
+```
+content/_index.md
+content/prerequisites.md
+content/how-to-create-a-project.md
+content/reference-list.md
+```
+
+Once you have your starter files, you want to create a new branch and add them to another commit.
+```
+$ git checkout -b new-branch
+Switched to a new branch 'new-branch'
+$ git add .
+$ git commit -a -m "Adds initial set of doc files"
+[new-branch b5ce0d9] Adds initial set of doc files
+ 3 files changed, 3 insertions(+)
+ create mode 100644 how-to-create-a-project.rst
+ create mode 100644 prerequisites.rst
+ create mode 100644 reference-list.rst
+$ git push origin new-branch
+Counting objects: 5, done.
+Delta compression using up to 8 threads.
+Compressing objects: 100% (2/2), done.
+Writing objects: 100% (5/5), 573 bytes | 573.00 KiB/s, done.
+Total 5 (delta 0), reused 0 (delta 0)
+To github.com:annegentle/do-docs-as-code.git
+ * [new branch]      new-branch -> new-branch
+```
+
+## Creating a pull request for the new branch
+
+1. Next, go to the GitHub URL for the new repo, `do-docs-as-code`. For example, with a username, `annegentle`, the URL would be https://github.com/annegentle/do-docs-as-code. You should see a new yellow notifier on the **Code** tab:
+`Your recently pushed branches: new-branch (5 minutes ago)`
+1. Click the **Compare & pull request** button.
+1. On the Open a Pull Request window, observe that your commit message becomes filled in the web form, comparing your `new-branch` to the base `master` branch.
+1. Click **Create pull request**.
+1. Once GitHub checks for merge compatibility, you should see a green button and click it, **Merge pull request**.
+1. Click **Confirm merge** to merge your new-branch into the master branch on GitHub.
+1. Notice that your local copy of the master branch does not yet contain these changes. In your Terminal window, run these commands to update your master branch locally.
+
+```
+$ git checkout master
+$ git remote update
+$ git pull origin master
+```
+Now, your local environment is all ready for new changes.
+1. Repeat these steps each time you want to make a new branch, make a commit, make a PR, merge it, and then get your local all set up to begin again!
+
+## Editing the site with a branch and pull request workflow
+
+When you're the only person working in a repo, you can use a simple workflow, where you simply create a branch for whatever amount of work you want to do, and then merge that branch to the master branch when you want to publish. If you're on a small team, each team member can do the same, keeping the workflow simple, where the `master` branch is the one that is published each time. Here's a walkthrough for a branch and pull workflow.
+
+1. Every time you work in a folder that's a GitHub repo, run a `git status` command to figure out if you have any changes on the branch you're working within.
+  ```
+  $ git status
+  ```
+1. Once you know what changes you have on a local branch, decide whether to keep working in that branch, or start over with the current `master` branch. To start again with a new copy of master from the remote, run these commands to update your master branch locally.
+  ```
+  $ git checkout master
+  $ git remote update
+  $ git pull origin master
+  ```
+1. Next, create a new branch to make new changes in:
+  ```
+  $ git checkout -b new-branch
+  ```
+1. Make your edits in the files, and add new files if needed.
+1. Double-check that the changes are what you expect, by building locally.
+
+    These are the basic build commands on the three SSGs:
+    **Sphinx**:
+    ```
+    $ make html
+    ```
+    Open `build/html/index.html` in your browser.
+
+    **Jekyll**:
+    ```
+    $ bundle exec jekyll serve
+    ```
+    Open http://127.0.0.1:4000 in your browser.
+    **Hugo**:
+    ```
+    $ hugo server
+    ```
+    Open http://127.0.0.1:1313 in your browser.
+
+    Repeat the editing and building steps to your satisfaction.
+
+1. Once you have the changes you need, commit to the branch:
+  ```
+  $ git commit -a -m "These are my changes, such as edits"
+  ```
+1. Now, push your changes to the remote so that you can create a pull request.
+  ```
+  $ git push origin new-branch
+  ```
+1. Open the GitHub.com repository URL to open the Pull Request, comparing `new-branch` to `master`.
+1. On the Pull Request in GitHub, make sure that your continuous integration tests pass.
+1. Once you are satisfied with all the changes, merge the changes to the `master` branch by clicking the Merge button on GitHub.
+1. Now, look for the continuous deployment site online on readthedocs.org, GitHub Pages, or Netlify.
+1. Don't forget to reset your local branch to the `master` branch that is now available in the newly-merged master on GitHub! This is the same as in step 2 above, but uses semi-colons so you can run the commands all in one line.
+  ```
+  $ git checkout master; git remote update; git pull origin master
+  ```
diff --git a/_learn/05-cd-for-docs.md b/_learn/05-cd-for-docs.md
new file mode 100644
index 00000000..6ed77ce8
--- /dev/null
+++ b/_learn/05-cd-for-docs.md
@@ -0,0 +1,108 @@
+---
+title: "Continuous Deployment (CD) for Documentation Sites"
+image:
+  path: /images/learn/netlify-logo400x200.png
+  thumbnail: /images/learn/netlify-logo400x200.png
+  caption: "[Netlify logo](https://netlify.com)"
+---
+
+Continuous deployment lets you build the docs on another system and then place the files where the web server can serve them. CD can include both the building of the HTML files as well as deploying them to a host.
+
+Continuous deployment is game-changing for documentation sites. You can get free or super inexpensive hosting, make sure that all your pull requests build correctly, and make gorgeous web sites, all with automated builds. Until you have used automation for docs it's hard to describe how freeing it can be. You don't have to take the time to build the site locally and then FTP the files to a remote host. You don't have to fiddle with the HTTPS certificates or make sure that the web server itself is configured "just so."
+
+Webhooks are a mechanism for triggering an event based on a change in the repository. You can choose from different services that provide webhooks to build your site automatically. Some examples include:
+
+* [Read the Docs](https://readthedocs.org/)
+* [Netlify](https://www.netlify.com/)
+* [GitHub Pages](https://pages.github.com)
+
+Let's walk through some examples of CI/CD for websites so you can automate your documentation workflow.
+
+## Build Python Sphinx project to Read the Docs
+
+Once you have a simple set of pages, you can set up continuous deployment on the Read the Docs website, where open source projects can choose to build for free while supporting the site with ethical ads, or by paying a small fee. Follow these steps to get started.
+
+1. Go to https://readthedocs.org/ and sign up for an account.
+1. Once you've logged in, go to **Settings** and then choose **Connected Services**.
+1. Click the prompts to connect your GitHub account, giving Read the Docs permissions for the repository you want to build docs from, to read the repo and clone the repo.
+1. Once you have a connected account, go to your profile on readthedocs.org and click **My Projects** to see a list of your repositories that Read the Docs service can access.
+1. To import your new project, click the **+** import icon next to the repository name. Click **Import Manually** if you do not see the repository listed after refreshing your accounts.
+
+### Next: Deploy a Sphinx project to readthedocs.org
+
+When you have a local project you want to deploy to a web site, you can set up the configuration for Continuous Deployment (CD) on readthedocs.org.
+
+You can complete this setup online at readthedocs.org through an account, or you can [manually add the webhook](https://docs.readthedocs.io/en/latest/webhooks.html#webhook-creation) to your repository in GitHub, GitLab, or Bitbucket.
+
+Since this lesson is intended to be prescriptive, let's go through the manual settings in GitHub so that you see how webhooks work.
+
+1. Log into GitHub.
+1. Go to the **Settings** page for your project that contains the Sphinx project.
+1. Click **Webhooks** and then click **Add webhook**.
+1. For the Payload URL, use the URL of the integration on Read the Docs, found in the **Dashboard** > **Admin** > **Integrations** settings. For example, use https://readthedocs.org/api/v2/webhook/rockthedocs-demo/40722/ for a generic webhook. However, while RTD gives you a "token" that is intended for the **Secret** field, the tooling is not yet complete to respect that token. The example URL for the project Integration page is this URL: https://readthedocs.org/dashboard/rockthedocs-demo/integrations/40708/.
+1. For Content type, you can use either `application/json` or `application/x-www-form-urlencoded`.
+1. Select **Just the push event**.
+1. Finish by clicking **Add webhook**.
+1. You can verify if the webhook is working at the bottom of the GitHub page under **Recent Deliveries**. If you see a `Response 200`, then the webhook is correctly configured.
+
+>Note: You can configure a Sphinx project to use Markdown as source files. You update your `conf.py` file with this line when you want to use Markdown (`.md`) rather than ReStructured Text (`.rst`) files. Here's an example:
+   ```
+   # The suffix(es) of source filenames.
+   # You can specify multiple suffix as a list of string:
+   source_suffix = ['.rst', '.md']
+   source_parsers = {
+      '.md': 'recommonmark.parser.CommonMarkParser',
+   }
+   ```
+
+## Deploy a Jekyll Project using GitHub Pages
+
+[GitHub Pages](https://pages.github.com/) is a hosted offering from GitHub itself so you can make web sites by building from GitHub repositories. For your GitHub account, you get one site and with an organization account you get another site, plus you can have unlimited project sites.
+
+Because GitHub Pages supports building sites using a gem-based theme, you can add a line to your `Gemfile` in your repo and then deploy using GitHub Pages from the branch of your choosing in your repository settings.
+
+1. In your local files, edit the `Gemfile` to make sure it contains the line `gem "github-pages", group: :jekyll_plugins` -- replacing the `gem "jekyll"` line:
+
+```
+source "https://rubygems.org"
+
+gem "github-pages", group: :jekyll_plugins
+gem "minimal-mistakes-jekyll"
+```
+1. Run `bundle install` locally to make sure your local builds are being build with that `Gemfile`.
+1. Open your local `_config.yml` file. Remove any existing `theme:` entries and replace with this entry:
+```
+remote_theme: "mmistakes/minimal-mistakes"
+```
+
+By default, you are specifying the `master` branch of the Minimal Mistakes theme with this configuration. You can also "pin" to a specific release by using `"mmistakes/minimal-mistakes@4.9.0"` instead of `"mmistakes/minimal-mistakes"`. I'd recommend using a specific release if you have an active docs site because it helps you with troubleshooting output. Your output remains stable when you pin to a release value and you can test first before a theme upgrade.
+1. Create a commit and push these changes to your GitHub repository. Once merged to the branch configured in your repo, the changes show up in a few seconds at username.github.io/project-name.
+
+## Deploy a Hugo Project using Netlify
+
+Once you have a Hugo site working locally, you can set up continuous deployment on Netlify with a free account.
+
+1. [Sign up for free first](https://app.netlify.com/signup).
+1. Next, go to https://app.netlify.com/.
+1. Click **New site from Git**. One great feature of Netlify is that it can deploy from GitHub, GitLab, or BitBucket, no small feat!
+1. Click **GitHub** for this tutorial, but definitely feel free to explore other options later.
+1. Grant access by clicking **Authorize Netlify**.
+1. Enter your GitHub password to grant access.
+1. In the next window, choose the repository that you want to deploy. Of course, you want to choose the one that has Hugo-based documentation source files.
+1. In the Netlify window, choose which branch to deploy from (such as `master`), the command to use (Hugo, which by default uses version 0.17), and the directory the deployed files are in (`public` by default).
+   > Note: If you want to use Hugo 0.20 or a later specific version, you should later enter it in a `netlify.toml` file in your repository. Or, click **Advanced** and then **New variable** if you want to use the `HUGO_VERSION=0.47` variable in the `[context.deploy-preview.environment]` and `[context.production.environment]` sections.
+1. Click **Deploy site**.
+
+## Alternative CI/CD options for deploying and hosting docs sites
+
+You can also deploy documentation sites using free hosting options as alternatives to GitHub Pages.
+
+* [GitLab](https://gitlab.com) also offers GitLab Pages, read more [about how to set it up to learn how](https://about.gitlab.com/2016/04/07/gitlab-pages-setup/).
+
+*  [Netlify](https://www.netlify.com) provides the same capability as GitHub and GitLab with the Ruby gem configuration described in [this tutorial](https://www.netlify.com/blog/2015/10/28/a-step-by-step-guide-jekyll-3.0-on-netlify/) and in the [Minimal Mistakes theme documentation](https://mmistakes.github.io/minimal-mistakes/docs/quick-start-guide/#ruby-gem-method).
+
+## Additional resources
+
+[TravisCI Core Concepts for Beginners](https://docs.travis-ci.com/user/for-beginners)
+
+[Convert AsciiDoc to HTML/PDF & publish to GitHub Pages with Travis CI and Asciidoctor Docker containers](http://mgreau.com/posts/2016/03/28/asciidoc-to-gh-pages-with-travis-ci-docker-asciidoctor.html)
diff --git a/_learn/06-test-docs-as-code.md b/_learn/06-test-docs-as-code.md
new file mode 100644
index 00000000..a4659b5e
--- /dev/null
+++ b/_learn/06-test-docs-as-code.md
@@ -0,0 +1,140 @@
+---
+title: "Set Up Automated Tests for Docs"
+image:
+  path: /images/learn/travis-ci-logo400x200.png
+  thumbnail: /images/learn/travis-ci-logo400x200.png
+  caption: "Logo from [Travis CI](https://travis-ci.org)"
+---
+
+You have choices for continuous integration systems that can run documentation tests. For this exercise, let's make a set of minimal tests: build the docs, and check the links and image references.
+
+Bonus tasks for advanced users, think about how you could run a doc linter such as `write-good`, using the basics outlined here.
+
+## Link tests
+
+For all the continuous integration tools, you can create scripts that you store in the repo itself and tell the CI tool to run the script on each pull request as a trigger to run the script. Having CI tests in place means that you or other contributing writers can get information on tests results from each pull request to find out if it passes tests.
+
+For Sphinx, you can run a `sphinx-build` command with parameters that only checks links, both external and internal. You and your contributors can then run this script locally prior to submitting a pull request. Here is an example script, where $BUILD_DIR and $DIRECTORY are the build location and source location:
+
+```
+!/usr/bin/env bash
+# halt script on error
+set -e
+# Build locally, and then check links
+sphinx-build -E -W -b linkcheck source build
+```
+
+For Jekyll, the `html-proofer` gem lets you build and then test links on the built site, both external and internal. You can write a small script to build the site and then check it and then run that script with your CI tool. Jekyll builds the output to a `_site` directory by default. Here's an example script:
+
+```
+#!/usr/bin/env bash
+# halt script on error
+set -e
+# clean by deleting any existing output
+rm -rf _site
+# Build locally, then check links in built output
+bundle exec jekyll build
+# The url-ignore is optional depending on the links you have in the site
+bundle exec htmlproofer ./_site --url-ignore "#"
+```
+
+For Hugo, you can use this `htmltest` tool, built for Go, at https://github.com/wjdp/htmltest. For local use, install it and run it locally.
+
+For continuous integration use, you can install it in the CI system and then configure with a YAML file. Hugo automatically puts the built files into a directory named `public` or `static`. See [Using with Hugo](https://github.com/wjdp/htmltest/wiki/Using-With-Hugo).
+
+You can store an `.htmltest.yml` file in the root of the project to configure `htmltest` for the location of the built files, `public`. That file contains a line like this example:
+
+```
+DirectoryPath: public
+```
+
+## Test with Travis CI
+
+ First you must set up a Travis CI account at https://travis-ci.org by connecting to your GitHub account.
+
+ Open source and public repositories are free to use with Travis CI. Read more about plans and pricing at https://travis-ci.com/plans if you need to build docs in private repos.
+
+ Next, configure your docs repository to use Travis to run your test scripts, such as the link checker.
+
+### Enable Travis builds for your GitHub repository
+
+ 1. Log in to https://travis-ci.com and go to your profile.
+ 1. Look for the repository in the list that you want to enable doc builds.
+ 1. Toggle the switch for that repository.
+ 1. Next, make sure you have scripts available to run as tests for each pull request.
+
+### Create automation scripts in your repository
+
+For Sphinx, let's set up a script that only checks links, both external and internal.
+
+1. In your file editor, create a `linkcheck.sh` file in a `scripts` directory.
+1. Edit the file so that it contains the following bash commands to make the script:
+  ```
+  !/usr/bin/env bash
+  # halt script on error
+  set -e
+  # Build locally, deleting any existing doctrees, and then check links
+  sphinx-build -E -W -b linkcheck source build
+  ```
+1. Save the `linkcheck.sh` file in a `scripts` directory.
+
+### Configure the Travis build with a .travis.yml file
+
+At the most basic level, Travis CI builds run two steps on its infrastructure, install and build. The `install` step in the `.travis.yml` config file makes sure the environment is set up with any dependencies needed for the build to run. The `script` step does the work of building.
+
+For your Sphinx link checker, create and edit a `.travis.yml` file that contains the environment setup and the script you want run:
+
+```
+language: python
+python:
+  - '3.5'
+  - '3.4'
+  - '2.7'
+  script: ./scripts/linkcheck.sh
+```
+
+For Jekyll, follow the steps in this Jekyll documentation page, [Travis Ci](https://jekyllrb.com/docs/continuous-integration/travis-ci/).
+
+To see a working example of Jekyll with TravisCI, look at the [versions-jekyll](https://github.com/justwriteclick/versions-jekyll/) repository. Here's the `.travis.yml` file:
+```
+language: ruby
+rvm:
+- 2.2.5
+
+script: ./script/build-travis.sh
+
+env:
+  global:
+  - NOKOGIRI_USE_SYSTEM_LIBRARIES=true # speeds up installation of html-proofer
+
+sudo: false # routes build to container-based infrastructure for a faster build
+```
+
+The `/script/build-travis.sh` file contains these lines. Notice that the script passes in the `_config.yml` file.
+```
+#!/usr/bin/env bash
+set -e # halt script on error
+
+bundle exec jekyll build --config _config.yml
+```
+
+If you wanted to check links instead, you could make a link checking script like so:
+```
+#!/usr/bin/env bash
+set -e # halt script on error
+
+bundle exec jekyll build
+bundle exec htmlproofer ./_site
+```
+
+Look for more inspiration beyond link checking in the additional resources section. Enjoy higher-quality doc builds with some quality tests up front!
+
+## Additional resources
+
+[Test the Docs](https://testthedocs.org/)
+
+Pantheon docs examples
+* [Merge conflict test](https://github.com/pantheon-systems/documentation/blob/master/scripts/merge_conflicts.sh)
+* [CircleCI example configuration](https://github.com/pantheon-systems/documentation/blob/master/circle.yml)
+
+[How we spotted--and fixed--11 errors in our docs with our new markdown proofer](https://circleci.com/blog/markdown-proofer/)
diff --git a/_posts/00-github-for-docs-files.md b/_posts/00-github-for-docs-files.md
new file mode 100644
index 00000000..28703599
--- /dev/null
+++ b/_posts/00-github-for-docs-files.md
@@ -0,0 +1,258 @@
+---
+title: "GitHub for documentation sites"
+image:
+  path: /images/learn/mikecogh-trains.jpg
+  thumbnail: /images/learn/github-logo400x200.png
+  caption: "Photo from [Flickr:mikecogh](https://flic.kr/p/pEn3RB)"
+---
+
+Learning GitHub or any source control system backed by `git` for documentation sites takes some time and practice. This set of lessons uses the Terminal rather than the desktop application or the web site UI, though both are valid ways to do a GitHub workflow.
+
+## Create a GitHub account
+
+You can learn how to sign up for a GitHub account and pricing plans on [help.github.com](https://help.github.com/articles/signing-up-for-a-new-github-account/).
+
+You can do all these docs-as-code tutorials with a free GitHub account.
+
+## Learn basic Terminal and Git Bash commands
+
+One great aspect of these developer workflows and tools means you have a lot of freedom to choose how you work. That said, for this choose-your-adventure series, we tend to think you already have Terminal commands memorized or you understand them. Whether you're on a Mac, Linux, or Windows, these come in handy.
+
+Knowing the basics should help. Here's a short list:
+
+* `ls` - List directory contents, `dir` is the equivalent in Windows.
+* `pwd` - Show working directory name, `cd ,` is the equivalent command in Windows.
+* `cd path/to/directory/` - Change to another directory. In Git Bash on Windows you can use `cd  /c/project/`. If you need to change to a directory with spaces in the name, you must surround the path with double quote marks, such as `cd "C:\My Project\"`.
+* `cd ..` - Go up one directory.
+* `git status` - Shows the changes pending or shows if changes are already committed.
+* `git branch` - Lists all the local branches and indicates the current branch with an asterisk (`*`).
+* `git config -l` - Lists all the configuration for the local repo when it contains a Git repository.
+* `git init` - Sets up all the files for Git to be able to track a project as a repository. Init stands for initialize.
+
+## More resources for learning Git and GitHub
+
+As with any complex system, you want to practice using Git commands to learn the system well and also how to troubleshoot. Here's a great list of resources for both hands-on practice and reference.
+
+* [GitHub Learning Lab](https://lab.github.com/) "Get the skills you need without leaving GitHub. GitHub Learning Lab takes you through a series of fun and practical projects, sharing helpful feedback along the way."
+* [GitHub Guides](https://guides.github.com/) - Guided tutorials about 3-10 minutes in duration.
+* [Git and GitHub learning resources](https://help.github.com/articles/git-and-github-learning-resources/)
+* [Five basic Git commands every beginner needs to know](https://www.theserverside.com/tutorial/Five-basic-Git-commands-every-beginner-needs-to-know)
+* [Troubleshooting connectivity problems](https://help.github.com/articles/troubleshooting-connectivity-problems/)
+
+## Learn GitHub vocabulary
+
+The terms sound confusing at first. Here's a list of vocabulary words to help you get through the initial learning curve.
+
+<dl>
+  <dt>branch</dt>
+  <dd>
+    <p>
+      A parallel version of a repo within the repo that does not affect the primary or <code>master</code> branch. You can work freely in a branch without affecting the <i>live</i> version. After you make changes, you can merge your branch into the <code>master</code> branch to publish your changes.
+    </p>
+    <p>
+      New contributors can confuse named directories, such as a cloned fork that is named after the original repo, and Git branches.
+    </p>
+    <p>
+      You can instruct Git to base your branch on the <code>master</code> branch in upstream, origin, or another remote. For example, this command bases a new branch on the <code>master</code> branch in the <code>upstream</code> remote:
+    </p>
+    <pre class="small">$ git checkout upstream/master -b &lt;branch&gt;</pre>
+  </dd>
+  <dt>clone</dt>
+  <dd>
+    <p>
+      A copy of a repo that lives on your computer instead of on a website's server.
+    </p>
+  </dd>
+  <dt>commit</dt>
+  <dd>
+    <p>
+      A point-in-time snapshot of a repo. Commits let you see the differences between changes. A commit is an individual change to a file or set of files. Every time that you save a file or a set of files, Git creates a unique ID, also known as the <i>SHA</i> or <i>hash</i>, that tracks the changes. Commits usually contain a commit message, which is a brief description of what changes were made.
+    </p>
+  </dd>
+  <dt>downstream</dt>
+  <dd>
+    <p>
+      A label for a remote URL, where a remote represents a place where code is stored. A downstream remote indicates an opposite of an upstream, or original, repo.
+    </p>
+  </dd>
+  <dt>fork (noun)</dt>
+  <dd>
+    <p>
+      A copy of the repo that is entirely yours in your namespace. A fork gives you a way to both contribute openly and get credit for your contributions.
+    </p>
+  </dd>
+  <dt>fork (verb)</dt>
+  <dd>
+    <p>
+      The act of making a forked copy of the repo.
+    </p>
+  </dd>
+  <dt>issue</dt>
+  <dd>
+    <p>
+      A way to submit a suggested improvement, defect, task, or feature request to a repo. In a public repo, anyone can create an issue. Each issue contains its own discussion forum. You can label an issue and assign it to a user.
+    </p>
+  </dd>
+  <dt>organization</dt>
+  <dd>
+    <p>
+      A collection of group-owned repositories.
+    </p>
+  </dd>
+  <dt>pull request</dt>
+  <dd>
+    <p>
+      A method of submitting edits that compares your changes with the original. Teams can view the comparison to decide whether they want to accept the changes.
+    </p>
+  </dd>
+  <dt>push</dt>
+  <dd>
+    <p>
+      Move your local committed changes to a remote location, such as <a href="http://www.github.com">GitHub.com</a>, so that other people can access them.
+    </p>
+  </dd>
+  <dt>remote</dt>
+  <dd>
+    <p>
+      A version of your project that is hosted on the Internet or on a network. The remote is usually connected to local clones so that you can sync changes.
+    </p>
+  </dd>
+  <dt>repo</dt>
+  <dd>
+    <p>
+      A collection of stored code or docs.
+    </p>
+  </dd>
+  <dt>review</dt>
+  <dd>
+    <p>
+      Perform a line-by-line comparison of a change and comment on improvements or suggest changes, much like a copy editor does for a newspaper article.
+    </p>
+  </dd>
+  <dt>upstream</dt>
+  <dd>
+    <p>
+      The primary label for the remote URL indicating the original repo where changes are merged. The branch, or fork, where you do your work is called <i>downstream</i>.
+    </p>
+  </dd>
+</dl>
+
+
+## Set up prompts (Terminal on MacOS or Linux)
+
+While you're working in your Terminal window, it's great to always know which branch you're on by modifying your prompt to show the current `git` branch. To do so, put this snippet of code in your `~/.bash_profile` file:
+
+```
+# Git branch in prompt.
+parse_git_branch() {
+    git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/'
+}
+#export PS1="$ "
+export PS1="\u\ \W\[\033[32m\]\$(parse_git_branch)\[\033[00m\] $ "
+```
+
+As an example, with this code in my `~/.bash_profile` file, my prompt looks like this while I'm working in a branch named `initial-content`:
+
+```
+agentle\ choose-adventure-workshop (initial-content) $
+```
+
+## Set up prompts (Git Bash on Windows)
+
+Git Bash on Windows displays your current branch on the prompt for you.
+
+One concept to remember here is that Git Bash uses Linux-like commands but the directory listings use forward slash (`/`) instead of back slash (`\`). You can change directories with commands like `cd  /c/project/` where `/c/` represents your `C:/` drive on Windows.
+
+## Set up your GitHub account for SSH access
+
+To avoid entering your password every time you perform `git clone` or `git push` commands (it does get tedious), then set up an SSH key for your credentials on GitHub, and then always use the SSH reference rather than the HTTPS reference when you do a `git clone` command. You set up references with an SSH key as your identifier, and then you do not need to enter a password from the command line to authenticate to the GitHub site. The GitHub instructions for [Connecting to GitHub with SSH](https://help.github.com/articles/connecting-to-github-with-ssh/) work great for this setup, and I highly recommend it.
+
+## Create a new repository on GitHub
+
+Before you get too far writing content for the site, get the directory set up for version control in a Git repo, and make some incremental commits.
+
+1. Go to https://github.com and log in.
+1. In your browser, create a new repository in your user space or organization.
+1. In the browser, copy the SSH or HTTPS reference for the repo, such as: `git@github.com:annegentle/do-docs-as-code.git`.
+1. In the root directory, create a quick README file that contains only a header. For example:
+```
+$ echo "# do-docs-as-code" >> README
+```
+1. In the root directory, initialize the Git repo.
+  ```bash
+  $ git init
+  ```
+1. Next, add all the files you want to have in the repo, as indicated with the period `.`.
+  ```bash
+  $ git add .
+  ```
+1. Create a commit, or a point in time for the state of the current files in the directory.
+  ```bash
+  $ git commit -a -m "Adds initial docs-as-code project"
+  ```
+1. In the Terminal window, type git commands to add a "remote" named "origin" and then paste in the SSH or HTTPS reference, such as `git@github.com:annegentle/do-docs-as-code.git`.
+  ```bash
+  $ git remote add origin <paste the reference>
+  ```
+1. In the Terminal window, set the newly added remote as the upstream branch and push the initial commit to this new remote named origin.
+```
+$ git push --set-upstream origin master
+```
+
+## Ignoring operating system files or generated files
+
+In GitHub repos, you can place a `.gitignore` file that contains the file extensions or folder names that you want to keep out of source control. When a file extension or folder is in the `.gitignore` file, even when you use the `git add .` command, those files and folders are not added to the commit.
+
+This exclusion is useful so that you do not have a lot of difficult merges on output HTML files or operating system tracking files.
+
+For Sphinx, you want to ignore these files and folders to avoid merge conflicts:
+
+```
+build
+.DS_Store
+```
+
+For Jekyll, you want to ignore these files and folders:
+
+```
+_site
+.DS_Store
+```
+
+For Hugo, you want to ignore these files and folders. The `static` folder could be named `public`, depending on your configuration
+```
+static
+.DS_Store
+```
+
+## Ignoring operating system files or generated files
+
+In GitHub repos, you can place a `.gitignore` file that contains the file extensions or folder names that you want to keep out of source control. When a file extension or folder is in the `.gitignore` file, even when you use the `git add .` command, those files and folders are not added to the commit.
+
+This exclusion is useful so that you do not have a lot of difficult merges on output HTML files or operating system tracking files.
+
+For Sphinx, you want to ignore these files and folders to avoid merge conflicts:
+
+```
+build
+.DS_Store
+```
+
+For Jekyll, you want to ignore these files and folders:
+
+```
+_site
+.DS_Store
+```
+
+For Hugo, you want to ignore these files and folders. The `static` folder could be named `public`, depending on your configuration.
+```
+static
+public # depends on configuration
+.DS_Store
+```
+
+## Additional resources
+[Learning Git and GitHub resources on help.github.com](https://help.github.com/articles/git-and-github-learning-resources/)
+[GitHub Guides](https://guides.github.com/)
+[Pro Git](https://git-scm.com/book/en/v2)
diff --git a/_posts/08-templating.md b/_posts/08-templating.md
new file mode 100644
index 00000000..deefe80c
--- /dev/null
+++ b/_posts/08-templating.md
@@ -0,0 +1,20 @@
+---
+title: "Templating and data-based layouts"
+image:
+  path: /images/so-simple-sample-image-4.jpg
+  thumbnail: /images/site-logo.png
+---
+
+Templates within static site generators enable you to use variables or metadata values from other files in the source files that create HTML. Maybe you want to keep the product version value in a metadata file. Or you want to access the domain name the site is built upon, reliably and repeatedly. Template engines integrated with the underlying programming language give access to loops, variables, or functions so that you can enhance your website output.
+
+* Jekyll uses the [Liquid templating engine](https://shopify.github.io/liquid/), originally built by Shopify, written in Ruby.
+* Hugo has a packaged templating engine similar to liquid, but Go-based. Read more in [Introduction to Hugo Templating](https://gohugo.io/templates/introduction/).
+* Sphinx uses Python for any extensibility you need. I find it helpful to browse through the [Read the Docs Theme](https://github.com/rtfd/sphinx_rtd_theme) to find examples of templating.
+
+When using a templating engine like Liquid in Jekyll, you can access the version value from a data file. Read more in the Liquid documentation about [Iteration](https://shopify.github.io/liquid/tags/iteration/).
+
+The Read the Docs theme for Sphinx uses Python variables to indicate the version, using values from the `conf.py` file for the project and a definition list rather than an unordered list.
+
+## Additional resources
+
+[Learning Liquid](https://www.shopify.com/partners/blog/topics/learning-liquid)
diff --git a/_posts/10-evaluating-ssg-themes.md b/_posts/10-evaluating-ssg-themes.md
new file mode 100644
index 00000000..bb77203e
--- /dev/null
+++ b/_posts/10-evaluating-ssg-themes.md
@@ -0,0 +1,49 @@
+---
+title: "Evaluating Static Site Generator themes"
+image:
+  path: /images/so-simple-sample-image-4.jpg
+  thumbnail: /images/site-logo.png
+---
+
+Themes for static site generators often provide the advanced user experience features such as search. You also analyze the theme to make decisions on the authoring side, such as a table format for large data tables. What about printed outputs, such as PDF? Or versions for the output and the source? Any performance gains you can make with the builds themselves? Themes are one part of this analysis.
+
+Here's a short list of questions you may want to ask about the theme you use for a static site generator.
+
+## Admonitions or notes
+Are there designs for output of levels of admonition, such as warning, information, and note?
+
+## Code syntax and highlighting
+For code examples, can you set the exact highlight you want to use, such as JavaScript or Python or Bash? Does the code snippet have a copy icon for copying only the code and not copying a prompt?
+
+## Comment engines
+Which comment engines are supported and do they work with what other organizations use in your company or group?
+
+## Customization
+How straightforward is it to add your logo or a header that's common to multiple web sites? Can you learn how to maintain the theme's customizations yourself or will you need to rely on a web developer for maintenance and any enhancements such as adding a version drop-down list? For example, the Jekyll theme "Minimal Mistakes" is "skinnable," meaning you can [configure various color variations](https://mmistakes.github.io/minimal-mistakes/docs/configuration/) for that theme.
+
+## Images
+Are images automatically resized when looking at them on a mobile browser or resized browser window? Are alt tags and captions considered in the design?
+
+## Localization and translation support
+When translations are available, are they simple to get to? Does the theme itself have the ability to be localized, such as for the search form or navigation elements, can the labels used in the theme be localized?
+
+## Navigation and configuration possibilities
+Does the theme have a sidebar, breadcrumbs, and an in-page table of contents? Can you turn on or off each based on the page layout or page template or whether the person is using a mobile browser or tablet?
+
+## Responsive and mobile design
+Does the theme use thoughtful navigation and search when on a small screen?
+
+## Search
+Is the search form in a prominent location and if needed, can you move the search form on the page? Does the search work on mobile devices with readable results? Can the result list also be styled?
+
+## Social media support
+If you want Twitter cards for your documentation pages, are they available through the theme? Which social media sites can you link to from each documentation page?
+
+## Tables
+Do tables work on different browsers? If PDF or epub is another output option, do the tables still work on a particular page size or do you need to adjust how tables are made in the source file itself for good results in the output?
+
+## Theme Updates
+How easy is it to upgrade the theme files? Can you make regular updates through a version-control system and know exactly which theme you have in use?
+
+## Versions
+Many themes do not have a version picker by default. You might want a drop-down list or navigation that could include version. The Sphinx Read the Docs theme does have one and it works great. For Jekyll, look at the [versions-jekyll repository](https://github.com/justwriteclick/versions-jekyll) to see a couple of implementation ideas.
diff --git a/_posts/11-evaluating-table-layouts.md b/_posts/11-evaluating-table-layouts.md
new file mode 100644
index 00000000..0c079be9
--- /dev/null
+++ b/_posts/11-evaluating-table-layouts.md
@@ -0,0 +1,46 @@
+---
+title: "Evaluating table layouts and formatting"
+image:
+  path: /images/so-simple-sample-image-4.jpg
+  thumbnail: /images/site-logo.png
+---
+
+One of the most helpful tools when creating tables for Markdown or RST is the Tables Generator at https://www.tablesgenerator.com/markdown_tables. You can draw tables or paste table data and then render the ASCII-based output for pasting into your document source file.
+
+For example, here is an empty five-column table in Markdown, ready for you to insert cell data and spaces.
+
+```
+|  |  |  |  |  |
+|:-|:-|:-|:-|:-|
+|  |  |  |  |  |
+|  |  |  |  |  |
+|  |  |  |  |  |
+```
+
+When using Markdown for tables, you do not have access to block-level formatting. If you need a second paragraph, you can use `<br>` inside of a Markdown table. For more complex tables, many people use HTML inside of Markdown files.
+
+For RST, there are several options for table markup that is super simple while still allowing for nice table output.
+
+Simple tables can be made with dashes and plus signs and pipe symbols. Use spaces to indicate the size of cells. However these can be difficult to hand-type and maintain with changes over time. So, look for other table syntax ideas to make it easier to maintain the tables.
+
+The [RST documentation](https://thomas-cokelaer.info/tutorials/sphinx/rest_syntax.html#tables) has several table syntax examples. Over time I have found that the most useful way to maintain table data in columns and rows is the `csv-table` directive. Indicate header rows and labels in the cells, along with the widths of each column. Then enter the data in a CSV-like stye. Here's an example:
+
+```
+.. csv-table:: a title
+   :header: "name", "firstname", "age"
+   :widths: 20, 20, 10
+
+   "Smith", "John", 40
+   "Smith", "John, Junior", 20
+```
+
+If you also output PDF using LaTeX with Sphinx, be aware that there's a column specification for tabular data. Then you can use centimeters for width like so:
+
+```
+.. tabularcolumns:: |l|c|p{5cm}|
++--------------+---+-----------+
+|  simple text | 2 | 3         |
++--------------+---+-----------+
+```
+
+Your editor may also have helpful tools for managing tables, such as the [Markdown Table Editor in Atom](https://atom.io/packages/markdown-table-editor), which can resize all rows and columns while you type. Plus, it enables keybindings that you can use to navigate between cells and rows.
diff --git a/_posts/12-print-pdf-epub-output.md b/_posts/12-print-pdf-epub-output.md
new file mode 100644
index 00000000..2c6cdc72
--- /dev/null
+++ b/_posts/12-print-pdf-epub-output.md
@@ -0,0 +1,20 @@
+---
+title: "Print, PDF, or epub output"
+image:
+  path: /images/so-simple-sample-image-4.jpg
+  thumbnail: /images/site-logo.png
+---
+
+How difficult or straightforward is it to create a print or PDF format? You may want to investigate and test solutions beyond this article, as requirements and print tolerances can vary widely.
+
+### Jekyll PDF options
+
+In the Jekyll Documentation Theme site, Tom Johnson suggests buying a license for Prince XML ($500) in order to create print-ready PDF files with the Jekyll Documentation Theme. The PDF layout and styles are set using CSS. Considering that the only gem solution, [jekyll-pdf](https://github.com/abeMedia/jekyll-pdf), makes PDF files of single pages rather than a collection, the third-party solution is probably the way to go.
+
+### Sphinx PDF output
+
+When you use Read the Docs builds for deployment, you automatically get versioned documentation based on releases, as well as PDF output for the entire site. The PDF formatting is based on [LaTex](https://www.latex-project.org/), an open source typesetting system. It has page numbering, linking, and footnotes.
+
+### Hugo PDF output
+
+Hugo supports many [custom output formats through templates](https://gohugo.io/templates/output-formats/), but as of right now no one has written a series of templates for PDF, based on the discussions in various Issues. ([#1360 Generate concatenated document for Kindle/PDF generation](https://github.com/gohugoio/hugo/issues/1360)) ([#3530 Add alternative rendering format for LaTeX](https://github.com/gohugoio/hugo/issues/3530)). You could also use Prince XML as a solution here, similar to Jekyll.
diff --git a/_posts/13-ssg-performance.md b/_posts/13-ssg-performance.md
new file mode 100644
index 00000000..fbb3aa14
--- /dev/null
+++ b/_posts/13-ssg-performance.md
@@ -0,0 +1,37 @@
+---
+title: "Static Site Generator performance considerations"
+image:
+  path: /images/so-simple-sample-image-4.jpg
+  thumbnail: /images/site-logo.png
+---
+
+When you start building large documentation sites, or gluing together multiple documentation sets, you might look for performance gains in the build time. Having smaller doc sites helps with this, so that you can build with your static site generator systems in parallel, but also look for incremental builds or ways to measure build times to look for areas where the build is slowed down and then find a root cause for the slower performance.
+
+### Sphinx build performance options
+
+Sphinx has a couple of possibilities for decreasing build times and increasing efficiency of builds.
+
+Sphinx is configured by default to rebuild only new and changed files, rather than building the entire site over again. Use the `-a` flag on the `sphinx-build` command to always write all output files. This setting may help you measure benchmark values for build times.
+
+Trying to keep your number of individual RST files to build to hundreds rather than thousands will naturally make the builds take less time. If you do need thousands of documents, then also be careful with the number of `toctree` directives in use as that overhead can slow down builds.
+
+One option for large doc sets is to let Sphinx use multiple processes, adjusting on its own with the `sphinx-build -j auto` setting, available since the 1.7 release. The `auto` value causes Sphinx to use the number of CPUs for the number of parallel builds.
+
+### Jekyll build time improvements
+
+Jekyll can build only changed files with the incremental build feature, but it is considered experimental in the Jekyll 3.0 release. Use the `-I` or `--incremental` flag on your `jekyll build` or `jekyll serve` commands any time you want to re-build only posts and pages with changes.
+
+```
+$ jekyll build --incremental
+```
+
+For sites with about a hundred pages, there's less need for performance helpers, but when the site grows to 1,000 pages or more, you should consider only building changed files with the `--incremental` flag.
+
+### Hugo build performance metrics
+
+For Hugo, often the build is so fast you don't have to worry about building incremental changes. That said, Hugo does provide ways to benchmark the site build and to look for metrics for the templates themselves, because it is possible to slow down the build with inefficient template executions. When you run a `hugo` command, you can also use these flags to learn more about build performance:
+    * `--stepAnalysis` - Display memory and timing of different steps of the program.
+    * `--templateMetrics` - Display metrics about template executions.
+    * `--templateMetricsHints` - Calculate some improvement hints when combined with --templateMetrics.
+
+There's also the benchmark command, documented on the [gohugo.io site](https://gohugo.io/commands/hugo_benchmark/). The command builds the site multiple times with various flags set, and analyzes the running process to provide a benchmark for comparison either over time or with various flags set, such as including expired content.
diff --git a/_posts/14-ssg-search-implementations.md b/_posts/14-ssg-search-implementations.md
new file mode 100644
index 00000000..e5926119
--- /dev/null
+++ b/_posts/14-ssg-search-implementations.md
@@ -0,0 +1,26 @@
+---
+title: "Static Site Generator search options"
+image:
+  path: /images/so-simple-sample-image-4.jpg
+  thumbnail: /images/site-logo.png
+---
+
+Most static site generators provide a browser-side search capability, where the list of indexed keywords for search are built at the same time as the output. Learn more about considerations for each SSG in the following sections.
+
+### Jekyll implementation for search within the site
+
+For Jekyll and the [Minimal Mistakes theme](https://mmistakes.github.io/minimal-mistakes/), the theme author has implemented Lunr.js as a browser-side search tool. The search works fast, and when a user types in a search term, it pre-fills with suggestions in the search form. The JSON file used for the search terms should be generated each time the site is re-built.
+
+### Sphinx search implementation
+
+For Sphinx, the default search engine creates a `searchindex.js` file that depends on cached doctree files being built each time the site is built. The build implementation goes through each document and pulls out words for search. Then, the theme uses a web form that calls the `searchindex.js` file when a user fills out the form. Currently the system does not have a way to substitute another browser-side search implementation, but the developers are considering it in a future Sphinx release based on [discussion in this GitHub Issue](https://github.com/sphinx-doc/sphinx/issues/3812).
+
+### Hugo search options
+
+For Hugo, the search engine included with the "Learn" theme can be configured for Lunr.js. To configure the theme to use the `lunr.js` [JavaScript search engine](https://lunrjs.com/), add these lines to the `config.toml` file and rebuild.
+```
+[outputs]
+home = [ "HTML", "RSS", "JSON"]
+```
+
+You can also configure Algolia, a software-as-a-service (SaaS) search solution, in Hugo, according to this [blog post](https://forestry.io/blog/search-with-algolia-in-hugo/).
diff --git a/about/index.md b/about/index.md
index 4a0cbc22..40cde28b 100644
--- a/about/index.md
+++ b/about/index.md
@@ -20,6 +20,16 @@ Looking for a way to invigorate your documentation team and grow that team to in
 * Trusting team members to value documentation, respect end-users needs, and advocate for the best deliverables for consumers of the documentation.
 * Automating and integrating documentation builds so you and your teams can focus on content.
 
+## Choose your docs-as-code adventure
+
+In a choose your own adventure series, you first pick the look for the site, then discover the developer language that pairs with the static site generator and then the CICD integration follows. We walk through setting up the development environment, and then show how to automate using docs CICD pipelines including Read the Docs, GitHub Pages, and Netlify.
+
+You may also test the docs by with Continuous Integration (CI) systems like TravisCI or CircleCI. If you need to work within existing CI systems, choose a tool that other teams use within your organization, and your choice of output is not limited by the CI system. In other words, the test frameworks in TravisCI or CircleCI do not dictate your deployment system.
+
+Here are three example documentation sites you can write and build using an SSG with CICD.
+
+Choose your adventure and start one of these sites - and learn ways to treat docs like code along the journey.
+
 ## Ready to learn more?
 
 {% include sign-up.html %}
diff --git a/images/learn/Go-Logo_Black.png b/images/learn/Go-Logo_Black.png
new file mode 100644
index 00000000..f68a065d
Binary files /dev/null and b/images/learn/Go-Logo_Black.png differ
diff --git a/images/learn/cogfog-pebbles-400x267.jpeg b/images/learn/cogfog-pebbles-400x267.jpeg
new file mode 100644
index 00000000..7e16dfa3
Binary files /dev/null and b/images/learn/cogfog-pebbles-400x267.jpeg differ
diff --git a/images/learn/cogfog-pebbles.jpg b/images/learn/cogfog-pebbles.jpg
new file mode 100644
index 00000000..25b6be56
Binary files /dev/null and b/images/learn/cogfog-pebbles.jpg differ
diff --git a/images/learn/github-logo400x200.png b/images/learn/github-logo400x200.png
new file mode 100644
index 00000000..91f6be6e
Binary files /dev/null and b/images/learn/github-logo400x200.png differ
diff --git a/images/learn/go-logo400x200.png b/images/learn/go-logo400x200.png
new file mode 100644
index 00000000..f2098e6d
Binary files /dev/null and b/images/learn/go-logo400x200.png differ
diff --git a/images/learn/hugo-docs-page-400x335.png b/images/learn/hugo-docs-page-400x335.png
new file mode 100644
index 00000000..2550f4cd
Binary files /dev/null and b/images/learn/hugo-docs-page-400x335.png differ
diff --git a/images/learn/hugo-docs-page.png b/images/learn/hugo-docs-page.png
new file mode 100644
index 00000000..72a17cfd
Binary files /dev/null and b/images/learn/hugo-docs-page.png differ
diff --git a/images/learn/jekyll-docs-pag-400x335.png b/images/learn/jekyll-docs-pag-400x335.png
new file mode 100644
index 00000000..3721c8fa
Binary files /dev/null and b/images/learn/jekyll-docs-pag-400x335.png differ
diff --git a/images/learn/jekyll-docs-page.png b/images/learn/jekyll-docs-page.png
new file mode 100644
index 00000000..72f8c044
Binary files /dev/null and b/images/learn/jekyll-docs-page.png differ
diff --git a/images/learn/mikecogh-trains-400x300.jpeg b/images/learn/mikecogh-trains-400x300.jpeg
new file mode 100644
index 00000000..59442add
Binary files /dev/null and b/images/learn/mikecogh-trains-400x300.jpeg differ
diff --git a/images/learn/mikecogh-trains.jpg b/images/learn/mikecogh-trains.jpg
new file mode 100644
index 00000000..c5f7efe1
Binary files /dev/null and b/images/learn/mikecogh-trains.jpg differ
diff --git a/images/learn/msanseve-flowers-400x273.jpeg b/images/learn/msanseve-flowers-400x273.jpeg
new file mode 100644
index 00000000..378d488b
Binary files /dev/null and b/images/learn/msanseve-flowers-400x273.jpeg differ
diff --git a/images/learn/msanseve-flowers.jpg b/images/learn/msanseve-flowers.jpg
new file mode 100644
index 00000000..014f9c05
Binary files /dev/null and b/images/learn/msanseve-flowers.jpg differ
diff --git a/images/learn/netlify-logo400x200.png b/images/learn/netlify-logo400x200.png
new file mode 100644
index 00000000..7d3e1a7c
Binary files /dev/null and b/images/learn/netlify-logo400x200.png differ
diff --git a/images/learn/octocat-400x333.png b/images/learn/octocat-400x333.png
new file mode 100644
index 00000000..74bdbc0d
Binary files /dev/null and b/images/learn/octocat-400x333.png differ
diff --git a/images/learn/octocat-github-logo400x200.png b/images/learn/octocat-github-logo400x200.png
new file mode 100644
index 00000000..8ab7a1db
Binary files /dev/null and b/images/learn/octocat-github-logo400x200.png differ
diff --git a/images/learn/octocat.png b/images/learn/octocat.png
new file mode 100644
index 00000000..91057da4
Binary files /dev/null and b/images/learn/octocat.png differ
diff --git a/images/learn/python-logo-master-v3-TM-flattened.png b/images/learn/python-logo-master-v3-TM-flattened.png
new file mode 100644
index 00000000..738f6ed4
Binary files /dev/null and b/images/learn/python-logo-master-v3-TM-flattened.png differ
diff --git a/images/learn/python-logo400x200.png b/images/learn/python-logo400x200.png
new file mode 100644
index 00000000..d49ca622
Binary files /dev/null and b/images/learn/python-logo400x200.png differ
diff --git a/images/learn/ruby-logo400x200.png b/images/learn/ruby-logo400x200.png
new file mode 100644
index 00000000..c1695d7e
Binary files /dev/null and b/images/learn/ruby-logo400x200.png differ
diff --git a/images/learn/ruby.png b/images/learn/ruby.png
new file mode 100644
index 00000000..797167a7
Binary files /dev/null and b/images/learn/ruby.png differ
diff --git a/images/learn/sphinx-docs-page.png b/images/learn/sphinx-docs-page.png
new file mode 100644
index 00000000..faa01119
Binary files /dev/null and b/images/learn/sphinx-docs-page.png differ
diff --git a/images/learn/spinx-docs-page-400x335.png b/images/learn/spinx-docs-page-400x335.png
new file mode 100644
index 00000000..6a1d9212
Binary files /dev/null and b/images/learn/spinx-docs-page-400x335.png differ
diff --git a/images/learn/travis-ci-logo400x200.png b/images/learn/travis-ci-logo400x200.png
new file mode 100644
index 00000000..cdf96727
Binary files /dev/null and b/images/learn/travis-ci-logo400x200.png differ
diff --git a/index.html b/index.html
index d8d22fbb..faa85de6 100644
--- a/index.html
+++ b/index.html
@@ -7,6 +7,13 @@
 
 {% include sign-up.html %}
 
+<div>
+<h1>Learn with practice</h1>
+
+<p><a href="http://www.lulu.com/spotlight/justwriteclick" class="btn btn--inverse"><i class='fa fa-graduation-cap'></i> Learn an SSG</a></p>
+
+<p>Learning GitHub or any source control system backed by `git` for documentation sites takes some time and practice. Try some lessons with three different static site generators and three different deployment systems as well as how to test docs as code.</p>
+</div>
 <div>
 <a href="http://www.lulu.com/spotlight/justwriteclick"><img src="images/docs-like-code-book.jpg" alt="Docs Like Code Book" align="left" hspace="20" vspace="20" height="100" width="159"></a>
 
diff --git a/learn/index.md b/learn/index.md
new file mode 100644
index 00000000..0d1d6c64
--- /dev/null
+++ b/learn/index.md
@@ -0,0 +1,11 @@
+---
+layout: collection
+permalink: /learn/
+collection: learn
+entries_layout: grid
+last_modified_at: Sat Jul 28 10:56:38 CDT 2018
+---
+
+Sphinx, Jekyll, and Hugo, all are static site generators that teams use for web sites and documentation sites. Let's go through setting up a static site generator and a common CICD system with it.
+
+{% include sign-up.html %}
diff --git a/search/index.md b/search/index.md
index 6aab2efd..f05d4217 100644
--- a/search/index.md
+++ b/search/index.md
@@ -6,3 +6,6 @@ image:
 search: false
 sitemap: false
 ---
+
+
+{% include sign-up.html %}