diff --git a/jekyll-source/_data/sidebars/userguide_sidebar.yml b/jekyll-source/_data/sidebars/userguide_sidebar.yml
new file mode 100644
index 0000000..04c3266
--- /dev/null
+++ b/jekyll-source/_data/sidebars/userguide_sidebar.yml
@@ -0,0 +1,88 @@
+entries:
+- title: Sidebar
+  product: Gerrit Documentation
+  version: alpha
+  folders:
+
+  - title:
+    output: pdf
+    type: frontmatter
+    folderitems:
+    - title:
+      url: /titlepage.html
+      output: pdf
+      type: frontmatter
+
+    - title:
+      url: /tocpage.html
+      output: pdf
+      type: frontmatter
+
+  - title: Gerrit Code Review
+    output: web
+    folderitems:
+
+    - title: Product Overview
+      url: /alpha-intro-quick.html
+      output: web
+
+    - title: How Gerrit Works
+      url: /alpha-intro-how-gerrit-works.html
+      output: web
+
+    - title: Quickstart for Linux
+      url: /alpha-linux-quickstart.html
+      output: web
+
+  - title: How-to Guides
+    output: web
+    folderitems:
+
+    - title: All How-to Guides
+      url: /install-quick.html
+      output: web
+
+      subfolders:
+      - title: "Contributing Changes"
+        output: web
+        subfolderitems:
+
+        - title: Cloning a Gerrit Repository
+          url: /cloning-a-gerrit-repository.html
+          output: web
+        - title: Pushing a Commit
+          url: /pushing-a-commit.html
+          output: web
+        - title: Updating a Change
+          url: /updating-a-change.html
+          output: web
+        - title: Marking a Change as Private
+          url: /marking-a-change-as-private.html
+          output: web
+        - title: Marking a Change as a Work in Progress
+          url: /marking-a-change-as-a-wip.html
+          output: web
+
+  - title: Walkthroughs and Examples
+    output: web
+    folderitems:
+
+    - title: Basic Gerrit Walkthrough
+      url: /alpha-intro-gerrit-walkthrough.html
+      output: web
+
+  - title: Concepts
+    output: web
+    folderitems:
+
+    - title: Changes
+      output: web
+      url: /alpha-concept-changes.html
+
+    - title: The refs/for Namespace
+      output: web
+      url: /alpha-concept-refs-for-namespace.html
+
+    - title: Patchsets
+      output: web
+      url: /alpha-concept-patchsets.html
diff --git a/jekyll-source/_data/topnav.yml b/jekyll-source/_data/topnav.yml
index 664cfde..6c9fb35 100644
--- a/jekyll-source/_data/topnav.yml
+++ b/jekyll-source/_data/topnav.yml
@@ -21,8 +21,8 @@
           external_url: https://gerrit-review.googlesource.com/q/status:open+project:gerrit
     - title: Docs
       folderitems:
-        - title: Beta
-          url: /doc-index.html
+        - title: Alpha
+          url: /alpha-intro-quick.html
         - title: Latest
           external_url: https://gerrit-documentation.storage.googleapis.com/Documentation/2.14.5.1/index.html
         - title: Wiki
diff --git a/jekyll-source/pages/gerrit/alpha-clone-a-gerrit-repository.md b/jekyll-source/pages/gerrit/alpha-clone-a-gerrit-repository.md
new file mode 100644
index 0000000..b7fc080
--- /dev/null
+++ b/jekyll-source/pages/gerrit/alpha-clone-a-gerrit-repository.md
@@ -0,0 +1,59 @@
+---
+title: " Cloning a Gerrit Repository"
+sidebar: userguide_sidebar
+permalink: cloning-a-gerrit-repository.html
+---
+{% include important.html content="This content is currently in <b>alpha</b>. It
+is still under review." %}
+
+As you start contributing to a Gerrit repository, your first step is to clone
+the project to a local repository. To clone a Gerrit repository, you use the
+same `git clone` command used for standard Git repositories. However, it is
+recommended to clone the repository with a commit-msg hook. This hook
+automatically adds the Change-Id that Gerrit uses to track iterations of a
+commit as it goes through review.
+
+## Before you begin
+
++ Verify that you are authorized to contribute changes to the repositories that
+  want to clone.
+
+## Cloning a repository with the commit-msg hook
+
+1. Navigate to the Gerrit site for your project. For example, the URL for the
+   Gerrit project is `gerrit-review.googlesource.com`.
+1. If you have not already done so, sign in using the icon in the upper right
+   corner.
+1. From the main menu bar, click **Browse**.
+   A list of available repositories opens.
+1. Click the name of the repository you want to clone.
+   A Downloads screen opens. This screen includes several commands that you can
+   copy and use on your local machine.
+1. Copy the contents of the **Clone with commit-msg hook** text box.
+   By default, this command uses the HTTP protocol. Gerrit also supports SSO
+   and RPC. To use one of these options, click either the **SSO** or **RPC**
+   link.
+1. From a terminal window on  your local machine, paste the command and run it.
+
+You now have a clone of the repository on your local machine. In addition, any
+commits you push to the remote repository automatically include a **Change-Id**.
+
+## Cloning directly
+
+If you want to clone a repository directly, you can do so by following the same
+steps in the [previous section](cloning_a_repository_with_the_commit-msg_hook.html).
+However, instead of using the command from the **Clone with commit-msg hook**
+text box, copy the command from the **Clone** text box.
+
+Warning: CLoning this command means that your commits do not automatically
+include a Change-Id.
+
+## What's Next
+
++ Understand how to push a change to a repository
++ Read the overview of how to contribute changes to Gerrit
++ Learn more aobu tthe commit-msg hook
++ Learn more about Change-Ids
+
+
+
diff --git a/jekyll-source/pages/gerrit/alpha-concept-changes.md b/jekyll-source/pages/gerrit/alpha-concept-changes.md
new file mode 100644
index 0000000..2225376
--- /dev/null
+++ b/jekyll-source/pages/gerrit/alpha-concept-changes.md
@@ -0,0 +1,217 @@
+---
+title: " Changes"
+sidebar: userguide_sidebar
+permalink: alpha-concept-changes.html
+---
+{% include important.html content="This content is currently in <b>alpha</b>. It
+is still under review." %}
+
+A change represents a single commit under review. Each change is
+identified by a [Change-Id](#change-id).
+
+Multiple git commits can share the same Change-Id, allowing you to
+update a change as you receive feedback through the code review process.
+In Gerrit, commits that share the same Change-Id are referred to as
+*patch sets*. When a change is approved, only the latest version of a
+commit is submitted to the repository.
+
+You can view a specific change using Gerrit’s Review screen. This screen
+provides the following information for each change:
+
++ Current and previous patch sets
++ Change properties, such as owner, project, and target branch
++ Comments
++ Votes on Review Labels
++ The Change-Id
+
+## Change properties
+
+When you open a change in Gerrit, the Review screen displays a number of
+properties about that change.
+
+<table>
+<caption>Change Properties</caption>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<tbody>
+<tr class="odd">
+<td><p>Property</p></td>
+<td><p>Description</p></td>
+</tr>
+<tr class="even">
+<td><p>Updated</p></td>
+<td><p>The date on which the change was last updated.</p></td>
+</tr>
+<tr class="odd">
+<td><p>Owner</p></td>
+<td><p>The contributor who created the change.</p></td>
+</tr>
+<tr class="even">
+<td><p>Assignee</p></td>
+<td><p>The contributor responsible for the change. Often used when a change has mulitple reviewers to identify the individual responsible for final approval.</p></td>
+</tr>
+<tr class="odd">
+<td><p>Reviewers</p></td>
+<td><p>A list of one or more contributors responsible for reviewing the change.</p></td>
+</tr>
+<tr class="even">
+<td><p>CC</p></td>
+<td><p>A list of one or more contributors who are kept informed about the change, but are not required to review it.</p></td>
+</tr>
+<tr class="odd">
+<td><p>Project</p></td>
+<td><p>The name of the Gerrit project.</p></td>
+</tr>
+<tr class="even">
+<td><p>Branch</p></td>
+<td><p>The branch on which the change was made.</p></td>
+</tr>
+<tr class="odd">
+<td><p>Topic</p></td>
+<td><p>An optional topic.</p></td>
+</tr>
+<tr class="even">
+<td><p>Strategy</p></td>
+<td><p>The submit strategy for the change.</p></td>
+</tr>
+<tr class="odd">
+<td><p>Code Review</p></td>
+<td><p>Displays the Code Review status for the change.</p></td>
+</tr>
+</tbody>
+</table>
+
+In addition, Gerrit displays the status of any additional labels, such
+as the Verified label, that have been configured for the server. See
+[Review Labels](config-labels.html) for more information.
+
+## Change Message
+
+Next to the list of change properties is the change message. This
+message contains user-supplied information regarding what the change
+does. To modify the change message, click the **Edit** link.
+
+By default, the change message contains the Change-Id. This ID contains
+a permanent link to a search for that Change-Id in Gerrit.
+
+## Related Changes
+
+In some cases, a change may be dependent on another change. These
+changes are listed next to the change message. These related changes are
+grouped together in several categories, including:
+
+  - Relation Chain. These changes are related by parent-child
+    relationships, regardless of topics.
+
+  - Merge Conflicts. These are changes in which there is a merge
+    conflict with the current change.
+
+  - Submitted Together. These are changes that share the same
+    topics.
+
+An arrow indicates the change you are currently viewing.
+
+## Topics
+
+Changes can be grouped by topics. Topics make it easier to find related
+changes by using the topic search operator. Changes with the same topic
+also appear in the **Relation Chain** section of the Review screen.
+
+Grouping changes by topics can be helpful when you have several changes
+that, when combined, implement a feature.
+
+Assigning a topic to a change can be done in the change screen or
+through a `git
+push` command.
+
+## Submit strategies
+
+Each project in Gerrit can employ a specific submit strategy. This
+strategy is listed in the change properties section of the Review
+screen.
+
+The following table lists the supported submit strategies.
+
+<table>
+<caption>Submit Strategies</caption>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<tbody>
+<tr class="odd">
+<td><p>Strategy</p></td>
+<td><p>Description</p></td>
+</tr>
+<tr class="even">
+<td><p>Fast Forward Only</p></td>
+<td><p>No merge commits are produced. All merges must be handled on the client, before submitting the change.</p>
+<p>To submit a change, the change must be a strict superset of the destination branch.</p></td>
+</tr>
+<tr class="odd">
+<td><p>Merge If Necessary</p></td>
+<td><p>The default submit strategy. If the change being submitted is a strict superset of the destination branch, then the branch is fast-forwarded to the change. If not, a merge commit is automatically created at submit time. This is identical to the <code>git merge --ff</code> command.</p></td>
+</tr>
+<tr class="even">
+<td><p>Always Merge</p></td>
+<td><p>Always produce a merge commit, even if the change is a strict superset of the destination branch. This is identical to the <code>git merge --no-ff</code> command. It is often used when users of the project want to be able to read the history of submits by running the <code>git log --first-parent</code> command.</p></td>
+</tr>
+<tr class="odd">
+<td><p>Cherry Pick</p></td>
+<td><p>Always cherry pick the patch set, ignoring the parent lineage and instead creating a new commit on top of the current branch.</p>
+<p>When cherry picking a change, Gerrit automatically appends a short summary of the change’s approvals and a link back to the change. The committer header is also set to the submitter, while the author header retains the original patch set author.</p>
+<p>NOTE: Gerrit ignores dependencies between changes when using this submit type unless <code>change.submitWholeTopic</code> is enabled and depending changes share the same topic. This means submitters must remember to submit changes in the right order when using this submit type.</p></td>
+</tr>
+<tr class="even">
+<td><p>Rebase if Necessary</p></td>
+<td><p>If the change being submitted is a strict superset of the destination branch, the branch is fast-forwarded to the change. If not, the change is automatically rebased and the branch is fast-forwarded to the change.</p></td>
+</tr>
+<tr class="odd">
+<td><p>Rebase Always</p></td>
+<td><p>Similar to Rebase If Necessary, but creates a new patch set even if fast forward is possible. This strategy is also similar to Cherry Pick; however, Rebase Always does not ignore dependencies.</p></td>
+</tr>
+</tbody>
+</table>
+
+Any project owner can use the Project screen to modify the method Gerrit
+uses to submit a change.
+
+## Change-Id
+
+Gerrit uses a Change-Id to identify which patch sets belong to the same
+review. For example, you make a change to a project. A reviewer supplies
+some feedback, which you address in a second commit. By assigning the
+same Change-Id to both commits, Gerrit can attach those commits to the
+same change.
+
+Change-Ids are appended to the end of a commit message, and resemble the
+following:
+
+    commit 29a6bb1a059aef021ac39d342499191278518d1d
+    Author: A. U. Thor <author@example.com>
+    Date: Thu Aug 20 12:46:50 2009 -0700
+    
+        Improve foo widget by attaching a bar.
+    
+        We want a bar, because it improves the foo by providing more
+        wizbangery to the dowhatimeanery.
+    
+        Bug: #42
+        Change-Id: Ic8aaa0728a43936cd4c6e1ed590e01ba8f0fbf5b
+        Signed-off-by: A. U. Thor <author@example.com>
+        CC: R. E. Viewer <reviewer@example.com>
+
+Gerrit requires that the Change-Id is in the footer (last paragraph) of
+a commit message. It can be combined with a Signed-off-by, CC, or other
+lines. For instance, the previous example has a Change-Id, along with a
+Signed-off-by and CC line.
+
+Notice that the Change-Id is similar to the commit id. To avoid
+confusing the two, a Change-Id typically begins with an `I`.
+
+While there are several ways you can add a Change-Id, the standard
+method uses git’s [commit-msg hook](cmd-hook-commit-msg.html) to
+automatically add the Change-Id to each new commit.
+
diff --git a/jekyll-source/pages/gerrit/alpha-concept-patchsets.md b/jekyll-source/pages/gerrit/alpha-concept-patchsets.md
new file mode 100644
index 0000000..6762d00
--- /dev/null
+++ b/jekyll-source/pages/gerrit/alpha-concept-patchsets.md
@@ -0,0 +1,128 @@
+---
+title: " Patch Sets"
+sidebar: userguide_sidebar
+permalink: alpha-concept-patchsets.html
+---
+{% include important.html content="This content is currently in <b>alpha</b>. It
+is still under review." %}
+
+As described in [Changes](concept-changes.html), a change represents a
+single commit under review. Each change is assigned a
+[Change-Id](concept-changes.html#change-id).
+
+It is very common to amend a commit during the code review process.
+Gerrit uses the Change-Id to associate each iteration of the commit with
+the same change. These iterations of a commit are referred to as *patch
+sets*. When a change is approved, only the latest version of a commit is
+submitted to the repository.
+
+> **Note**
+> 
+> It is also possible to copy a Change-Id to a completely new commit.
+> This is useful in situations where you want to keep the discussion
+> around a change, but also need to completely modify your approach.
+
+## File List
+
+When you open a change in Gerrit, a list of affected files appears in
+the file list, located in the middle of the Review screen. This table
+displays the following information for each file:
+
+  - A checkbox, indicating the file has been reviewed
+
+  - The type of modification
+
+  - The path and name of the file
+
+  - The number of added lines and or deleted lines
+
+## File modifications
+
+Each file in a patch set has a letter next to it, indicating the type of
+modification for that file. The following table lists the types of
+modifications.
+
+<table>
+<caption>Types of file modifications</caption>
+<colgroup>
+<col width="33%" />
+<col width="33%" />
+<col width="33%" />
+</colgroup>
+<tbody>
+<tr class="odd">
+<td><p>Letter</p></td>
+<td><p>Modification Type</p></td>
+<td><p>Definition</p></td>
+</tr>
+<tr class="even">
+<td><p>M</p></td>
+<td><p>Modification</p></td>
+<td><p>The file existed before this change and is modified.</p></td>
+</tr>
+<tr class="odd">
+<td><p>A</p></td>
+<td><p>Added</p></td>
+<td><p>The file is newly added.</p></td>
+</tr>
+<tr class="even">
+<td><p>D</p></td>
+<td><p>Deleted</p></td>
+<td><p>The file is deleted.</p></td>
+</tr>
+<tr class="odd">
+<td><p>R</p></td>
+<td><p>Renamed</p></td>
+<td><p>The file is renamed.</p></td>
+</tr>
+<tr class="even">
+<td><p>C</p></td>
+<td><p>Copied</p></td>
+<td><p>The file is new and is copied from an existing file.</p></td>
+</tr>
+</tbody>
+</table>
+
+If the status is **R** (Renamed) or **C** (Copied), the file list also
+displays the original name of the file below the patch set file.
+
+## Views
+
+By default, Gerrit displays the latest patch set for a given change. You
+can view previous versions of a patch set by selecting from the **Patch
+Set** drop-down list.
+
+## Diffs
+
+Clicking a file in the file list opens the Diff screen. By default, this
+screen displays a diff between the latest patch set’s version of a file
+and the current version of that file in the repository. You can also
+open a diff within the Review screen by clicking the blue triangle
+located in the same row as the file. To show the diffs of all files in
+the Review screen, click the **Show Diffs** link, located at the top of
+the file list.
+
+You can diff between other patch sets by selecting a patch set number
+from the **Diff Against** drop-down list.
+
+## Description
+
+Each change in Gerrit must have a change description. This change
+description comes from the commit message and becomes part of the
+history of the project.
+
+In addition to the change description, you can add a description for a
+specific patch set. This description is intended to help guide reviewers
+as a change evolves, such as "Added more unit tests." Unlike the change
+description, a patch set description does not become a part of the
+project’s history.
+
+To add a patch set description, click **Add a patch set description**,
+located in the file list.
+
+## GERRIT
+
+Part of [Gerrit Code Review](index.html)
+
+## SEARCHBOX
+
diff --git a/jekyll-source/pages/gerrit/alpha-concept-refs-for-namespace.md b/jekyll-source/pages/gerrit/alpha-concept-refs-for-namespace.md
new file mode 100644
index 0000000..d5e4ae0
--- /dev/null
+++ b/jekyll-source/pages/gerrit/alpha-concept-refs-for-namespace.md
@@ -0,0 +1,66 @@
+---
+title: " The refs/for namespace"
+sidebar: userguide_sidebar
+permalink: alpha-concept-refs-for-namespace.html
+---
+{% include important.html content="This content is currently in <b>alpha</b>. It
+is still under review." %}
+
+When pushing a new or updated commit to Gerrit, you push that commit
+using a
+[reference](https://www.kernel.org/pub/software/scm/git/docs/gitglossary.html#def_ref),
+in the `refs/for` namespace. This reference must also define the target
+branch, such as `refs/for/[BRANCH_NAME]`.
+
+For example, to create a new change on the master branch, you would use
+the following command:
+
+    git push origin HEAD:refs/for/master
+
+The `refs/for/[BRANCH_NAME]` syntax allows Gerrit to differentiate
+between commits that are pushed for review and commits that are pushed
+directly into the repository.
+
+Gerrit supports using either the full name or the short name for a
+branch. For instance, this command:
+
+    git commit
+    git push origin HEAD:refs/for/master
+
+is the same as:
+
+    git commit
+    git push origin HEAD:refs/for/refs/heads/master
+
+Gerrit uses the `refs/for/` prefix to map the concept of "Pushing for
+Review" to the git protocol. For the git client, it looks like every
+push goes to the same branch, such as `refs/for/master`. In fact, for
+each commit pushed to this ref, Gerrit creates a new ref under a
+`refs/changes/` namespace, which Gerrit uses to track these commits.
+These references use the following format:
+
+    refs/changes/[CD]/[ABCD]/[EF]
+
+Where:
+
+  - \[CD\] is the last two digits of the change number
+
+  - \[ABCD\] is the change number
+
+  - \[EF\] is the patch set number
+
+For example:
+
+    refs/changes/20/884120/1
+
+You can use the change reference to fetch its corresponding
+    commit:
+
+    git fetch https://[GERRIT_SERVER_URL]/[PROJECT] refs/changes/[XX]/[YYYY]/[ZZ] \
+    && git checkout FETCH_HEAD
+
+> **Note**
+> 
+> The fetch command can be copied from the [download
+> command](user-review-ui.html#download) in the Change screen.
+
diff --git a/jekyll-source/pages/gerrit/alpha-intro-gerrit-walkthrough.md b/jekyll-source/pages/gerrit/alpha-intro-gerrit-walkthrough.md
new file mode 100644
index 0000000..5415cee
--- /dev/null
+++ b/jekyll-source/pages/gerrit/alpha-intro-gerrit-walkthrough.md
@@ -0,0 +1,318 @@
+---
+title: " Working with Gerrit: An example"
+sidebar: userguide_sidebar
+permalink: alpha-intro-gerrit-walkthrough.html
+---
+{% include important.html content="This content is currently in <b>alpha</b>. It
+is still under review." %}
+
+To understand how Gerrit works, let’s follow a change through its entire
+life cycle. This example uses a Gerrit server configured as follows:
+
+  - **Hostname**: gerrithost
+
+  - **HTTP interface port**: 8080
+
+  - **SSH interface port**: 29418
+
+In this walkthrough, we’ll follow two developers, Max and Hannah, as
+they make and review a change to a `RecipeBook` project. We’ll follow
+the change through these stages:
+
+1.  Making the change.
+
+2.  Creating the review.
+
+3.  Reviewing the change.
+
+4.  Reworking the change.
+
+5.  Verifying the change.
+
+6.  Submitting the change.
+
+> **Note**
+> 
+> The project and commands used in this section are for demonstration
+> purposes only.
+
+## Making the Change
+
+Our first developer, Max, has decided to make a change to the
+`RecipeBook` project he works on. His first step is to get the source
+code that he wants to modify. To get this code, he runs the following
+`git clone` command:
+
+    clone ssh://gerrithost:29418/RecipeBook.git RecipeBook
+
+After he clones the repository, he runs a couple of commands to add a
+[Change-Id](user-changeid.html) to his commits. This ID allows Gerrit to
+link together different versions of the same change being reviewed.
+
+    scp -p -P 29418 gerrithost:hooks/commit-msg RecipeBook/.git/hooks/
+    chmod u+x .git/hooks/commit-msg
+
+> **Note**
+> 
+> To learn more about adding a change-id and the commit message hook,
+> see the [commit-msg Hook](cmd-hook-commit-msg.html) topic.
+
+## Creating the Review
+
+Max’s next step is to push his change to Gerrit so other contributors
+can review it. He does this using the `git push origin
+HEAD:refs/for/master` command, as follows:
+
+    $ <work>
+    $ git commit
+    [master 9651f22] Change to a proper, yeast based pizza dough.
+     1 files changed, 3 insertions(+), 2 deletions(-)
+    $ git push origin HEAD:refs/for/master
+    Counting objects: 5, done.
+    Delta compression using up to 8 threads.
+    Compressing objects: 100% (2/2), done.
+    Writing objects: 100% (3/3), 542 bytes, done.
+    Total 3 (delta 0), reused 0 (delta 0)
+    remote:
+    remote: New Changes:
+    remote:   http://gerrithost:8080/68
+    remote:
+    To ssh://gerrithost:29418/RecipeBook.git
+     * [new branch]      HEAD -> refs/for/master
+
+Notice the reference to a `refs/for/master` branch. Gerrit uses this
+branch to create reviews for the master branch. If Max opted to push to
+a different branch, he would have modified his command to `git push
+origin HEAD:refs/for/<branch_name>`. Gerrit accepts pushes to
+`refs/for/<branch_name>` for every branch that it tracks.
+
+The output of this command also contains a link to a web page Max can
+use to review this commit. Clicking on that link takes him to a screen
+similar to the following.
+
+![Gerrit Code Review Screen](/images/intro-quick-new-review.jpg "fig:")
+
+This is the Gerrit code review screen, where other contributors can
+review his change. Max can also perform tasks such as:
+
+  - Looking at the [diff](user-review-ui.html#diff-preferences) of his
+    change
+
+  - Writing [inline](user-review-ui.html#inline-comments) or
+    [summary](user-review-ui.html#reply) comments to ask reviewers for
+    advice on particular aspects of the change
+
+  - [Adding a list of people](intro-user.html#adding-reviewers) that
+    should review the change
+
+In this case, Max opts to manually add the senior developer on his team,
+Hannah, to review his change.
+
+## Reviewing the Change
+
+Let’s now switch to Hannah, the senior developer who will review Max’s
+change.
+
+As mentioned previously, Max chose to manually add Hannah as a reviewer.
+Gerrit offers other ways for reviewers to find changes, including:
+
+  - Using the [search](user-search.html) feature that to find changes
+
+  - Selecting **Open** from the **Changes** menu
+
+  - Setting up [email notifications](user-notify.html) to stay informed
+    of changes even if you are not added as a reviewer
+
+Because Max added Hannah as a reviewer, she receives an email telling
+her about his change. She opens up the Gerrit code review screen and
+selects Max’s change.
+
+![Gerrit Code Review Screen](/images/intro-quick-new-review.jpg "fig:")
+
+Notice the two "Need" lines:
+
+    * Need Verified
+    * Need Code-Review
+
+These two lines indicate what checks must be completed before the change
+is accepted. The default Gerrit workflow requires two checks:
+
+  - **Code-Review**. This check requires that someone look at the code
+    and ensures that it meets project guidelines, styles, and other
+    criteria.
+
+  - **Verified**. This check means that the code actually compiles,
+    passes any unit tests, and performs as expected.
+
+In general, the **Code-Review** check requires an individual to look at
+the code, while the **Verified** check is done by an automated build
+server, through a mechanism such as the [Gerrit Trigger Jenkins
+Plugin](https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger).
+
+> **Important**
+> 
+> The Code-Review and Verified checks require different permissions in
+> Gerrit. This requirement allows teams to separate these tasks. For
+> example, an automated process can have the rights to verify a change,
+> but not perform a code review.
+
+With the code review screen open, Hannah can begin to review Max’s
+change. She can choose one of two ways to review the change: unified or
+side-by-side. Both views allow her to perform tasks such as add
+[inline](user-review-ui.html#inline-comments) or
+[summary](user-review-ui.html#reply) comments.
+
+Hannah opts to view the change using Gerrit’s side-by-side view:
+
+![Side By Side Patch View](/images/intro-quick-review-line-comment.jpg
+"fig:")
+
+Hannah reviews the change and is ready to provide her feedback. She
+clicks the **Review** button on the change screen. This allows her to
+vote on the change.
+
+![Reviewing the Change](/images/intro-quick-reviewing-the-change.jpg
+"fig:")
+
+For Hannah and Max’s team, a code review vote is a numerical score
+between -2 and 2. The possible options are:
+
+  - `+2 Looks good to me, approved`
+
+  - `+1 Looks good to me, but someone else must approve`
+
+  - `0 No score`
+
+  - `-1 I would prefer that you didn't submit this`
+
+  - `-2 Do not submit`
+
+In addition, a change must have at least one `+2` vote and no `-2` votes
+before it can be submitted. These numerical values do not accumulate.
+Two `+1` votes do not equate to a `+2`.
+
+> **Note**
+> 
+> These settings are enabled by default. To learn about how to customize
+> them for your own workflow, see the [Project Configuration File
+> Format](config-project-config.html) topic.
+
+Hannah notices a possible issue with Max’s change, so she selects a `-1`
+vote. She uses the **Cover Message** text box to provide Max with some
+additional feedback. When she is satisfied with her review, Hannah
+clicks the **Publish Comments** button. At this point, her vote and
+cover message become visible to to all users.
+
+## Reworking the Change
+
+Later in the day, Max decides to check on his change and notices
+Hannah’s feedback. He opens up the source file and incorporates her
+feedback. Because Max’s change includes a change-id, all he has to is
+follow the typical git workflow for updating a commit:
+
+  - Check out the commit
+
+  - Amend the commit
+
+  - Push the commit to Gerrit
+
+<!-- end list -->
+
+    $ <checkout first commit>
+    $ <rework>
+    $ git commit --amend
+    $ git push origin HEAD:refs/for/master
+    Counting objects: 5, done.
+    Delta compression using up to 8 threads.
+    Compressing objects: 100% (2/2), done.
+    Writing objects: 100% (3/3), 546 bytes, done.
+    Total 3 (delta 0), reused 0 (delta 0)
+    remote: Processing changes: updated: 1, done
+    remote:
+    remote: Updated Changes:
+    remote:   http://gerrithost:8080/68
+    remote:
+    To ssh://gerrithost:29418/RecipeBook.git
+     * [new branch]      HEAD -> refs/for/master
+
+Notice that the output of this command is slightly different from Max’s
+first commit. This time, the output verifies that the change was
+updated.
+
+Having uploaded the reworked commit, Max can go back to the Gerrit web
+interface and look at his change.
+
+![Reviewing the Rework](/images/intro-quick-review-2-patches.jpg "fig:")
+
+Notice that there are now two patch sets associated with this change:
+the initial submission and the rework.
+
+When Hannah next looks at Max’s change, she sees that he incorporated
+her feedback. The change looks good to her, so she changes her vote to a
+`+2`.
+
+## Verifying the Change
+
+Hannah’s `+2` vote means that Max’s change satisfies the **Needs
+Review** check. It has to pass one more check before it can be accepted:
+the **Needs Verified** check.
+
+The Verified check means that the change was confirmed to work. This
+type of check typically involves tasks such as checking that the code
+compiles, unit tests pass, and other actions. You can configure a
+Verified check to consist of as many or as few tasks as needed.
+
+> **Note**
+> 
+> Remember that this walkthrough uses Gerrit’s default workflow.
+> Projects can add custom checks or even remove the Verified check
+> entirely.
+
+Verification is typically an automated process using the [Gerrit Trigger
+Jenkins
+Plugin](https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger) or a
+similar mechanism. However, there are still times when a change requires
+manual verification, or a reviewer needs to check how or if a change
+works. To accommodate these and other similar circumstances, Gerrit
+exposes each change as a git branch. The Gerrit UI includes a
+[**download**](user-review-us.html#download) link in the Gerrit Code
+Review Screen to make it easy for reviewers to fetch a branch for a
+specific change. To manually verify a change, a reviewer must have the
+[Verified](config-labels.html#label_Verified) permission. Then, the
+reviewer can fetch and checkout that branch from Gerrit. Hannah has this
+permission, so she is authorized to manually verify Max’s change.
+
+> **Note**
+> 
+> The Verifier can be the same person as the code reviewer or a
+> different person entirely.
+
+![Verifying the Change](/images/intro-quick-verifying.jpg "fig:")
+
+Unlike the code review check, the verify check is pass/fail. Hannah can
+provide a score of either `+1` or `-1`. A change must have at least one
+`+1` and no `-1`.
+
+Hannah selects a `+1` for her verified check. Max’s change is now ready
+to be submitted.
+
+## Submitting the Change
+
+Max is now ready to submit his change. He opens up the change in the
+Code Review screen and clicks the **Publish and Submit** button.
+
+At this point, Max’s change is merged into the repository’s master
+branch and becomes an accepted part of the project.
+
+## Next Steps
+
+This walkthrough provided a quick overview of how a change moves through
+the default Gerrit workflow. At this point, you can:
+
+  - Read the [Users guide](intro-user.html) to get a better sense of how
+    to make changes using Gerrit
+
+  - Review the [Project Owners guide](intro-project-owner.html) to learn
+    more about configuring projects in Gerrit, including setting user
+    permissions and configuring verification checks
+
diff --git a/jekyll-source/pages/gerrit/alpha-intro-how-gerrit-works.md b/jekyll-source/pages/gerrit/alpha-intro-how-gerrit-works.md
new file mode 100644
index 0000000..f689b4d
--- /dev/null
+++ b/jekyll-source/pages/gerrit/alpha-intro-how-gerrit-works.md
@@ -0,0 +1,37 @@
+---
+title: " How Gerrit Works"
+sidebar: userguide_sidebar
+permalink: alpha-intro-how-gerrit-works.html
+---
+{% include important.html content="This content is currently in <b>alpha</b>. It
+is still under review." %}
+
+To understand how Gerrit fits into and enhances the developer workflow,
+consider a typical project. This project has a central source
+repository, which serves as the authoritative copy of the project’s
+contents.
+
+![Central Source Repository](images/intro-quick-central-repo.png "fig:")
+
+Gerrit takes the place of this central repository and adds an additional
+concept: a *store of pending changes*.
+
+![Gerrit in place of Central
+Repository](images/intro-quick-central-gerrit.png "fig:")
+
+With Gerrit, when a developer makes a change, it is sent to this store
+of pending changes, where other developers can review, discuss and
+approve the change. After enough reviewers grant their approval, the
+change becomes an official part of the codebase.
+
+In addition to this store of pending changes, Gerrit captures notes and
+comments about each change. These features allow developers to review
+changes at their convenience, or when conversations about a change can’t
+happen face to face. They also help to create a record of the
+conversation around a given change, which can provide a history of when
+a change was made and why.
+
+Like any repository hosting solution, Gerrit has a powerful [access
+control model](access-control.html). This model allows you to fine-tune
+access to your repository.
+
diff --git a/jekyll-source/pages/gerrit/alpha-intro-quick.md b/jekyll-source/pages/gerrit/alpha-intro-quick.md
new file mode 100644
index 0000000..e93294b
--- /dev/null
+++ b/jekyll-source/pages/gerrit/alpha-intro-quick.md
@@ -0,0 +1,35 @@
+---
+title: " Gerrit Product Overview"
+sidebar: userguide_sidebar
+permalink: alpha-intro-quick.html
+---
+{% include important.html content="This content is currently in <b>alpha</b>. It
+is still under review." %}
+
+Gerrit is a web-based code review tool built on top of the [Git version
+control system](https://git-scm.com/). This introduction provides an
+overview of Gerrit and describes how Gerrit integrates into a typical
+development workflow. It also provides a brief tutorial that shows how
+to manage a change using Gerrit.
+
+## What is Gerrit?
+
+Gerrit makes code review easy by providing a lightweight framework for
+reviewing commits before they are accepted by the codebase. Gerrit works
+equally well for projects where approving changes is restricted to
+selected users, as is typical for Open Source software development, as
+well as projects where all contributors are trusted.
+
+## Learn About Gerrit
+
+If you’re new to Gerrit and want to know more about how it can improve
+your developer workflow, see the following topics:
+
+1.  [How Gerrit Works](alpha-intro-how-gerrit-works.html)
+
+2.  [Basic Gerrit Walkthrough](alpha-intro-gerrit-walkthrough.html)
+
+## Getting Started
+
+To get started with Gerrit, see the
+[Quickstart for Installing Gerrit on Linux](alpha-linux-quickstart.html).
diff --git a/jekyll-source/pages/gerrit/alpha-linux-quickstart.md b/jekyll-source/pages/gerrit/alpha-linux-quickstart.md
new file mode 100644
index 0000000..39f4ec7
--- /dev/null
+++ b/jekyll-source/pages/gerrit/alpha-linux-quickstart.md
@@ -0,0 +1,91 @@
+---
+title: " Quickstart for Installing Gerrit on Linux"
+sidebar: userguide_sidebar
+permalink: alpha-linux-quickstart.html
+---
+{% include important.html content="This content is currently in <b>alpha</b>. It
+is still under review." %}
+
+This quickstart shows you how to install Gerrit on a Linux machine.
+
+{{site.data.alerts.note}}
+<p>The installation steps provided in this quickstart are for
+demonstration purposes only. They are not intended for use in a
+production environment.</p>
+{{site.data.alerts.end}}
+
+## Before you begin
+
+To complete this quickstart, you need:
+
+1.  A Unix-based server such as any of the Linux flavors or BSD.
+
+2.  Java SE Runtime Environment version 1.8 or later.
+
+## Download Gerrit
+
+From the Linux machine on which you want to install Gerrit:
+
+1.  Open a terminal window.
+
+2.  Download the Gerrit archive. See
+    [Gerrit Code Review - Releases](https://gerrit-releases.storage.googleapis.com/index.html)
+    for a list of available archives.
+
+The steps in this quickstart used Gerrrit 2.14.2, which you can download
+using a command such as:
+
+    wget https://www.gerritcodereview.com/download/gerrit-2.14.2.war
+
+
+## Install and initialize Gerrit
+
+From the command line, type the following:
+
+    java -jar gerrit*.war init --batch --dev -d ~/gerrit_testsite
+
+The preceding command uses two parameters:
+
+  - `--batch`. This parameter assigns default values to a variety of
+    Gerrit configuration options. To learn more about these
+    configuration options, see [Configuration](config-gerrit.html).
+
+  - `--dev`. This parameter configures the server to use the
+    authentication option, `DEVELOPMENT_BECOME_ANY_ACCOUNT`. This
+    authentication type makes it easy for you to switch between
+    different users to explore how Gerrit works. To learn more about
+    setting up Gerrit for development, see [Developer
+    Setup](dev-readme.html).
+
+This command displays a number of messages in the terminal window. The
+following is an example of these messages:
+
+    Generating SSH host key ... rsa(simple)... done
+    Initialized /home/gerrit/gerrit_testsite
+    Executing /home/gerrit/gerrit_testsite/bin/gerrit.sh start
+    Starting Gerrit Code Review: OK
+
+The last message you should see is `Starting Gerrit Code Review: OK`.
+This message informs you that the Gerrit service is now running.
+
+## Update the listen URL
+
+Another recommended task is to change the URL that Gerrit listens to
+from `*` to `localhost`. This change helps prevent outside connections
+from contacting the instance.
+
+    git config --file gerrit_testsite/etc/gerrit.config httpd.listenUrl 'http://localhost:8080'
+
+## Restart the Gerrit service
+
+You must restart the Gerrit service for your authentication type and
+listen URL changes to take effect.
+
+    ~/gerrit_testsite/bin/gerrit.sh restart
+
+## Viewing Gerrit
+
+At this point, you have a basic installation of Gerrit. You can view
+this installation by opening a browser and entering the following URL:
+
+    http://localhost:8080
diff --git a/jekyll-source/pages/gerrit/alpha-mark-a-change-as-private.md b/jekyll-source/pages/gerrit/alpha-mark-a-change-as-private.md
new file mode 100644
index 0000000..07862eb
--- /dev/null
+++ b/jekyll-source/pages/gerrit/alpha-mark-a-change-as-private.md
@@ -0,0 +1,61 @@
+---
+title: "Marking a Change as Private"
+sidebar: userguide_sidebar
+permalink: marking-a-change-as-private.html
+---
+{% include important.html content="This content is currently in <b>alpha</b>. It
+is still under review." %}
+
+In most cases, you push commits to a remote repository to have other develoeprs
+review and provide feedback. However, on occasion you might want to mark your
+change as private. Private changes are visible only to you and any reviewers
+already assigned to the change.
+
+Some examples of when you might want to mark a change as private:
+
++ You want to check what the change looks like before formal review starts.
++ You want to use Gerrit to sync data between different devcies. By creating
+  a private change without reviewers, you can push from one device, and fetch
+  to another device.
++ You want to do code review on a change that has sensitive aspects.
+  By reviewing a security fix in a private change, outsiders can't discover the
+  fix before it is pushed out. Even after merging the change, the review can be
+  kept private.
+
+You can mark a change as private when you first push the commit, or while a
+change is under review.
+
+## Before you begin
+
++ Verify that you understand the steps in [Pushing a Change](/pushing-a-change.html)
+  to push a change to the remote repository.
+
+## Mark a change as private using the command line
+
+From the terminal window, mark the change as private by adding `%private` at
+the end of a `git push` command:
+
+```
+git push origin HEAD:refs/for/master%private
+```
+
+When you are ready for other contributors to review the change, you can unmark
+the change from the command line:
+
+```
+git push origin HEAD:refs/for/master%remove-private
+```
+
+## Mark a change as private using the user interface
+
+1. Navigate to the Gerrit site for your project. For example, the URL for the
+   Gerrit project is `gerrit-review.googlesource.com`.
+1. If you have not already done so, sign in using the icon in the upper right
+   corner.
+1. From the main menu bar, select **Changes** from the **Your** menu.
+1. Click the change you want to mark private.
+   The Change screen opens.
+1. From the **More** menu, select **Mark private**.
+
+To unmark the change as private, from the **More** menu, select
+**Unmark private**.
diff --git a/jekyll-source/pages/gerrit/alpha-mark-a-change-as-wip.md b/jekyll-source/pages/gerrit/alpha-mark-a-change-as-wip.md
new file mode 100644
index 0000000..5965330
--- /dev/null
+++ b/jekyll-source/pages/gerrit/alpha-mark-a-change-as-wip.md
@@ -0,0 +1,62 @@
+---
+title: "Marking a Change as a Work In Progress"
+sidebar: userguide_sidebar
+permalink: marking-a-change-as-a-wip.html
+---
+{% include important.html content="This content is currently in <b>alpha</b>. It
+is still under review." %}
+
+Usually, you push a commit when you want other contributors to review it. By
+default, all changes are public, which means any contributor can review the
+change. There are several situations in which you might want to push a commit
+but not have other contributors review it. In such cases, you can mark your
+change as a work in progress.
+
+{% include note.html content="Another option is to mark a change as private, so
+that only the reviewers you choose can access it." %}
+
+Some examples of when you might mark a change as a work in progress include:
+
++ You want to run tests on your change before you officially request for
+  feedback.
++ During a review, you decide you need to rework your change, and you want to
+  stop notifying reviewers until you complete your updates.
+
+You can mark a change as a work in progress using either the command line or
+the user interface.
+
+## Before you begin
+
++ Verify that you understand the steps in [Pushing a Commit](/pushing-a-commit.html)
+  to push a change to a remote repository.
+
+## Mark a change as work in progress using the command line
+
+From a terminal window, mark the change as a work in progress by adding `%wip`
+at the end of a `git push` command:
+
+```
+git push origin HEAD:refs/for/master%wip
+```
+
+When you're ready for other contributors to review your change, you can unmark
+the change using the following command:
+
+```
+git push origin HEAD:refs/for/master%ready
+```
+
+## Mark a change as a work in progress using the user interface
+
+1. Navigate to the Gerrit site for your project. For example, the URL for the
+   Gerrit project is `gerrit-review.googlesource.com`.
+1. If you have not already done so, sign in using the icon in the upper right
+   corner.
+1. From the main menu bar, select **Changes** from the **Your** menu.
+1. Click the change you want to mark as a work in progress.
+   The Change screen opens.
+1. From the **More** menu, select **Mark as work in progress**.
+
+To mark the change as ready for review, open the change and click
+**Start Review**.
+
diff --git a/jekyll-source/pages/gerrit/alpha-push-a-commit.md b/jekyll-source/pages/gerrit/alpha-push-a-commit.md
new file mode 100644
index 0000000..5c7af1d
--- /dev/null
+++ b/jekyll-source/pages/gerrit/alpha-push-a-commit.md
@@ -0,0 +1,80 @@
+---
+title: "Pushing a Commit"
+sidebar: userguide_sidebar
+permalink: pushing-a-commit.html
+---
+{% include important.html content="This content is currently in <b>alpha</b>. It
+is still under review." %}
+
+With typical Git repositories, you work on the files stored in a local
+repository. When your updates are ready, you push those changes from your local
+machine directly to the remote repository.
+
+{{site.data.alerts.note}}
+Note: Alternatively, if you are familiar with GitHub, you make a pull request.
+This request asks an authorized member of the repository to pull changes from
+your copy of the repository.
+{{site.data.alerts.end}}
+
+Gerrit follows the standard Git workflow pattern, in that you use the `git push`
+command to copy your files from your local machine to the remote repository.
+However, instead of your changes going directly into the repository, they go
+into a specific namespace. This namespace uses the following pattern:
+
+```
+refs/for/[NAME]
+```
+
+where `[NAME]` is the name of the branch to which you want to push your commit.
+To learn more about the refs/for namespace, see The refs/for namespace.
+
+## Before you begin
+
++ Verify that you are authorized to contribute changes to the repositories that
+  you want to clone.
++ Clone a repository with a commit-msg hook, as described in
+  [Cloning a Gerrit Repository](/cloning-a-gerrit-repository.html).
+
+## Adding files
+
+From a terminal window, use the `git add` command to inform Git that you want
+to includ your updates in the next commit.
+
+```
+git add [FILE_NAME]
+```
+
+## Committing files
+
+Use the `git commit` command to record your changes to the local repository.
+
+```
+git commit -m [MESSAGE]
+```
+
+where `[MESSAGE]` is a description of the changes in the commit.
+
+{% include note.html content="If you omit the `-m` flag, an editor opens in
+which you can type your commit message." %}
+
+## Pushing the commit
+
+From a terminal window, type the following command:
+
+```
+git push origin HEAD:refs/for/[BRANCH_NAME]
+```
+
+For example, to push to the master branch, type:
+
+```
+git push origin HEAD:refs/for/master
+```
+
+Your commit is now ready for review.
+
+## What's next?
+
++ Learn how to update a change
++ Read about how to mark a review as Work-in-Progress
++ Review how to mark a change as private
diff --git a/jekyll-source/pages/gerrit/alpha-update-a-change.md b/jekyll-source/pages/gerrit/alpha-update-a-change.md
new file mode 100644
index 0000000..d3073a7
--- /dev/null
+++ b/jekyll-source/pages/gerrit/alpha-update-a-change.md
@@ -0,0 +1,58 @@
+---
+title: "Updating a Change"
+sidebar: userguide_sidebar
+permalink: updating-a-change.html
+---
+{% include important.html content="This content is currently in <b>alpha</b>. It
+is still under review." %}
+
+One of the main benefits of code review is the ability to receive and
+incorporate feedback from other developers. With Gerrit, you incorporate these
+changes by amending the commit. Gerrit uses the CHange-Id to ensure that each
+iteration of the commit are stored together as patchsets.
+
+{% include note.html content="You can only amend the most recent commit." %}
+
+## Before you begin
+
++ Follow the steps in [Pushing a Change](/pushing-a-change.html) to push a
+  change to the remote repository.
+
+## Adding files
+
+From a terminal window, use the `git add` command to inform Git that you want
+to include your updates in the next commit.
+
+```
+git add [FILENAME]
+```
+
+## Amending the commit
+
+Use the `git commit --amend` command to update the most recent commit.
+
+```
+git commit --amend
+```
+
+## Pushing the amended commit
+
+From a terminal window, type the following command:
+
+```
+git push origin HEAD:refs/for/[BRANCH_NAME]
+```
+
+For example, to push to the master branch, type:
+
+```
+git push origin HEAD:refs/for/master
+```
+
+Gerrit updates the commit under review with your latest changes.
+
+## What's next?
+
++ Learn about patchsets
+
+
diff --git a/jekyll-source/pages/gerrit/contributing-changes-how-to-index.md b/jekyll-source/pages/gerrit/contributing-changes-how-to-index.md
new file mode 100644
index 0000000..a413027
--- /dev/null
+++ b/jekyll-source/pages/gerrit/contributing-changes-how-to-index.md
@@ -0,0 +1,8 @@
+---
+title: "Contributing Changes How-to Guides"
+sidebar: userguide_sidebar
+permalink: contributing-changes-how-to-index.html
+---
+
+TBA
+