Merge pull request #11209 from moxiegirl/contribute-update

Contribute update to Project

docs/mkdocs.yml

@@ -169,8 +169,15 @@ pages:
 - ['terms/filesystem.md', '**HIDDEN**']
 - ['terms/image.md', '**HIDDEN**']
 
-# Contribute:
-- ['contributing/index.md', '**HIDDEN**']
-- ['contributing/contributing.md', 'Contribute', 'Contributing']
-- ['contributing/devenvironment.md', 'Contribute', 'Development environment']
-- ['contributing/docs_style-guide.md', 'Contribute', 'Documentation style guide']
+
+# Project:
+- ['project/index.md', '**HIDDEN**']
+- ['project/who-written-for.md', 'Project', 'README first']
+- ['project/set-up-prereqs.md', 'Project', 'Set up prerequisites'] 
+- ['project/set-up-dev-env.md', 'Project', 'Work with a development container'] 
+- ['project/test-and-docs.md', 'Project', 'Run tests and test documentation']
+- ['project/make-a-contribution.md', 'Project', 'Make a project contribution'] 
+- ['project/advanced-contributing.md', 'Project', 'Advanced contributing']
+- ['project/get-help.md', 'Project', 'Where to get help']
+- ['project/coding-style.md', 'Project', 'Coding style guide']
+- ['project/doc-style.md', 'Project', 'Documentation style guide']

docs/sources/contributing.md

@@ -1,7 +0,0 @@
-# Contributing
-
-## Contents:
-
- - [Contributing to Docker](contributing/)
- - [Setting Up a Dev Environment](devenvironment/)
-

docs/sources/contributing/contributing.md

@@ -1,24 +0,0 @@
-page_title: Contribution Guidelines
-page_description: Contribution guidelines: create issues, conventions, pull requests
-page_keywords: contributing, docker, documentation, help, guideline
-
-# Contributing to Docker
-
-Want to hack on Docker? Awesome!
-
-The repository includes [all the instructions you need to get started](
-https://github.com/docker/docker/blob/master/CONTRIBUTING.md).
-
-The [developer environment Dockerfile](
-https://github.com/docker/docker/blob/master/Dockerfile)
-specifies the tools and versions used to test and build Docker.
-
-If you're making changes to the documentation, see the [README.md](
-https://github.com/docker/docker/blob/master/docs/README.md).
-
-The [documentation environment Dockerfile](
-https://github.com/docker/docker/blob/master/docs/Dockerfile)
-specifies the tools and versions used to build the Documentation.
-
-Further interesting details can be found in the [Packaging hints](
-https://github.com/docker/docker/blob/master/project/PACKAGERS.md).

docs/sources/contributing/devenvironment.md

@@ -1,169 +0,0 @@
-page_title: Setting Up a Dev Environment
-page_description: Guides on how to contribute to docker
-page_keywords: Docker, documentation, developers, contributing, dev environment
-
-# Setting Up a Dev Environment
-
-To make it easier to contribute to Docker, we provide a standard
-development environment. It is important that the same environment be
-used for all tests, builds and releases. The standard development
-environment defines all build dependencies: system libraries and
-binaries, go environment, go dependencies, etc.
-
-**Things you need:**
-
- * Docker
- * git
- * make
-
-## Install Docker
-
-Docker's build environment itself is a Docker container, so the first
-step is to install Docker on your system.
-
-You can follow the [install instructions most relevant to your
-system](https://docs.docker.com/installation/). Make sure you
-have a working, up-to-date docker installation, then continue to the
-next step.
-
-## Install tools used for this tutorial
-
-Install `git`; honest, it's very good. You can use
-other ways to get the Docker source, but they're not anywhere near as
-easy.
-
-Install `make`. This tutorial uses our base Makefile
-to kick off the docker containers in a repeatable and consistent way.
-Again, you can do it in other ways but you need to do more work.
-
-## Check out the Source
-
-    $ git clone https://git@github.com/docker/docker
-    $ cd docker
-
-To checkout a different revision just use `git checkout`
-with the name of branch or revision number.
-
-## Build the Environment
-
-This following command builds a development environment using the
-`Dockerfile` in the current directory. Essentially, it installs all
-the build and runtime dependencies necessary to build and test Docker.
-Your first build will take some time to complete. On Linux systems and on Mac
-OS X from within the `boot2docker` shell:
-
-    $ make build
-    
-> **Note**:
-> On Mac OS X, the Docker make targets such as `build`, `binary`, and `test`
-> should **not** be built by the 'root' user. Therefore, you shouldn't use `sudo` when 
-> running these commands on OS X.
-> On Linux, we suggest you add your current user to the `docker` group via
-> [these
-> instructions](http://docs.docker.com/installation/ubuntulinux/#giving-non-root-access).
-
-If the build is successful, congratulations! You have produced a clean
-build of docker, neatly encapsulated in a standard build environment.
-
-
-## Build the Docker Binary
-
-To create the Docker binary, run this command:
-
-    $ make binary
-
-This will create the Docker binary in `./bundles/<version>-dev/binary/`. If you
-do not see files in the `./bundles` directory in your host, your `BIND_DIR`
-setting is not set quite right. You want to run the following command:
-
-    $ make BIND_DIR=. binary
-
-If you are on a non-Linux platform, e.g., OSX, you'll want to run `make cross`
-or `make BIND_DIR=. cross`.
-
-### Using your built Docker binary
-
-The binary is available outside the container in the directory
-`./bundles/<version>-dev/binary/`. You can swap your
-host docker executable with this binary for live testing - for example,
-on ubuntu:
-
-    $ sudo service docker stop ; sudo cp $(which docker) $(which docker)_ ; sudo cp ./bundles/<version>-dev/binary/docker-<version>-dev $(which docker);sudo service docker start
-
-> **Note**: 
-> Its safer to run the tests below before swapping your hosts docker binary.
-
-## Run the Tests
-
-To execute the test cases, run this command:
-
-    $ make test
-
-If the test are successful then the tail of the output should look
-something like this
-
-    --- PASS: TestWriteBroadcaster (0.00 seconds)
-    === RUN TestRaceWriteBroadcaster
-    --- PASS: TestRaceWriteBroadcaster (0.00 seconds)
-    === RUN TestTruncIndex
-    --- PASS: TestTruncIndex (0.00 seconds)
-    === RUN TestCompareKernelVersion
-    --- PASS: TestCompareKernelVersion (0.00 seconds)
-    === RUN TestHumanSize
-    --- PASS: TestHumanSize (0.00 seconds)
-    === RUN TestParseHost
-    --- PASS: TestParseHost (0.00 seconds)
-    === RUN TestParseRepositoryTag
-    --- PASS: TestParseRepositoryTag (0.00 seconds)
-    === RUN TestGetResolvConf
-    --- PASS: TestGetResolvConf (0.00 seconds)
-    === RUN TestParseRelease
-    --- PASS: TestParseRelease (0.00 seconds)
-    === RUN TestDependencyGraphCircular
-    --- PASS: TestDependencyGraphCircular (0.00 seconds)
-    === RUN TestDependencyGraph
-    --- PASS: TestDependencyGraph (0.00 seconds)
-    PASS
-    ok      github.com/docker/docker/utils        0.017s
-
-If `$TESTFLAGS` is set in the environment, it will pass extra arguments
-to `go test`. You can use this to select certain tests to run, e.g.,
-
-    $ TESTFLAGS='-test.run \^TestBuild\$' make test
-
-Only those test cases matching the regular expression inside quotation marks will be tested.
-
-If the output indicates "FAIL" and you see errors like this:
-
-    server.go:1302 Error: Insertion failed because database is full: database or disk is full
-
-    utils_test.go:179: Error copy: exit status 1 (cp: writing '/tmp/docker-testd5c9-[...]': No space left on device
-
-Then you likely don't have enough memory available the test suite. 2GB
-is recommended.
-
-## Use Docker
-
-You can run an interactive session in the newly built container:
-
-    $ make shell
-
-    # type 'exit' or Ctrl-D to exit
-
-## Build And View The Documentation
-
-If you want to read the documentation from a local website, or are
-making changes to it, you can build the documentation and then serve it
-by:
-
-    $ make docs
-    
-    # when its done, you can point your browser to http://yourdockerhost:8000
-    # type Ctrl-C to exit
-
-**Need More Help?**
-
-If you need more help then hop on to the [#docker-dev IRC
-channel](irc://chat.freenode.net#docker-dev) or post a message on the
-[Docker developer mailing
-list](https://groups.google.com/d/forum/docker-dev).

docs/sources/project.md

@@ -0,0 +1,13 @@
+# Project
+
+## Contents:
+
+- [README first](who-written-for)
+- [Set up prerequisites](set-up-prereqs/) 
+- [Work with a development container](set-up-dev-env/) 
+- [Run tests and test documentation](test-and-docs/)
+- [Make a project contribution](make-a-contribution/)
+- [Advanced contributing](advanced-contributing/)
+- [Where to get help](get-help/)
+- [Coding style guide](coding-style/)
+- [Documentation style guide](doc-style/)

docs/sources/project/advanced-contributing.md

@@ -0,0 +1,126 @@
+page_title: Advanced contributing
+page_description: Explains workflows for refactor and design proposals
+page_keywords: contribute, project, design, refactor, proposal
+
+# Advanced contributing
+
+In this section, you learn about the more advanced contributions you can make. They are advanced because they have a more involved workflow or require greater programming experience. Don't be scared off though, if you like to stretch and challenge yourself, this is the place for you.
+
+This section gives generalized instructions for advanced contributions. You'll read about the workflow but there are not specific descriptions of commands. Your goal should be to understand the processes described.
+
+At this point, you should have read and worked through the earlier parts of the project contributor guide. You should also have <a href="../make-a-contribution" target="_blank"> made at least one project contribution</a>.
+
+## Refactor or cleanup proposal
+
+A refactor or cleanup proposal changes Docker's internal structure without altering the external behavior. To make this type of proposal:
+
+1. Fork `docker/docker`.
+
+2. Make your changes in a feature branch.
+
+3. Sync and rebase with `master` as you work.
+
+3. Run the full test suite.
+
+4. Submit your code through a pull request (PR).
+
+	The PR's title should have the format:
+	
+	**Cleanup:** _short title_
+	
+	If your changes required logic changes, note that in your request.
+	
+5. Work through Docker's review process until merge.
+
+
+## Design proposal
+
+A design proposal solves a problem or adds a feature to the Docker software. The process for submitting design proposals requires two pull requests, one for the design and one for the implementation.
+
+![Simple process](/project/images/proposal.png)
+
+The important thing to notice is that both the design pull request and the implementation pull request go through a review. In other words, there is considerable time commitment in a design proposal; so, you might want to pair with someone on design work.
+
+The following provides greater detail on the process:
+
+1. Come up with an idea.
+
+	Ideas usually come from limitations users feel working with a product. So,
+	take some time to really use Docker. Try it on different platforms; explore
+	how it works with different web applications. Go to some community events
+	and find out what other users want.
+
+2. Review existing issues and proposals to make sure no other user is proposing a similar idea.
+
+    The design proposals are <a
+    href="https://github.com/docker/docker/pulls?q=is%3Aopen+is%3Apr+label%
+    3AProposal" target="_blank">all online in our GitHub pull requests</a>. 
+    
+3. Talk to the community about your idea.
+
+	We have lots of <a href="../get-help" target="_blank">community forums</a>
+	where you can get feedback on your idea. Float your idea in a forum or two
+	to get some commentary going on it.
+	
+4. Fork `docker/docker` and clone the repo to your local host.
+
+5. Create a new Markdown file in the area you wish to change.  
+
+	For example, if you want to redesign our daemon create a new file under the
+	`daemon/` folder. 
+
+6. Name the file descriptively, for example `redesign-daemon-proposal.md`.	
+	
+7. Write a proposal for your change into the file.
+
+	This is a markdown file that describes your idea. Your proposal
+	should include information like:
+	
+	* Why is this changed needed or what are the use cases?
+	* What are the requirements this change should meet?
+	* What are some ways to design/implement this feature?
+	* Which design/implementation do you think is best and why?
+	* What are the risks or limitations of your proposal?
+	
+	 This is your chance to convince people your idea is sound. 
+	  
+8. Submit your proposal in a pull request to `docker/docker`.
+
+	The title should have the format:
+	
+	**Proposal:** _short title_
+	
+	The body of the pull request should include a brief summary of your change
+	and then say something like "_See the file for a complete description_".
+	
+9. Refine your proposal through review.
+
+	The maintainers and the community review your proposal. You'll need to
+	answer questions and sometimes explain or defend your approach. This is
+	chance for everyone to both teach and learn.
+   
+10. Pull request accepted.
+
+	Your request may also be rejected. Not every idea is a good fit for Docker.
+	Let's assume though your proposal succeeded. 
+	
+11. Implement your idea.
+
+	Implementation uses all the standard practices of any contribution.
+	
+	 * fork `docker/docker`
+	 * create a feature branch
+	 * sync frequently back to master
+	 * test as you go and full test before a PR
+	 
+	 If you run into issues, the community is there to help.
+	 
+12. When you have a complete implementation, submit a pull request back to `docker/docker`.
+
+13. Review and iterate on your code.
+
+	If you are making a large code change, you can expect greater scrutiny
+	during this phase. 
+	
+14. Acceptance and merge!
+

docs/sources/project/coding-style.md

@@ -0,0 +1,76 @@
+page_title: Coding Style Checklist
+page_description: List of guidelines for coding Docker contributions
+page_keywords: change, commit, squash, request, pull request, test, unit test, integration tests, Go, gofmt, LGTM
+
+# Coding Style Checklist
+
+This checklist summarizes the material you experienced working through [make a code contribution](/project/make-a-contribution) and [advanced contributing](/project/advanced-contributing).  The checklist applies to code that is program code or code that is documentation code.
+
+## Change and commit code
+
+* Fork the `docker/docker` repository.
+
+* Make changes on your fork in a feature branch. Name your branch `XXXX-something` where `XXXX` is the issue number you are working on.
+
+* Run `gofmt -s -w file.go` on each changed file before
+committing your changes. Most editors have plug-ins that do this automatically.
+
+* Update the documentation when creating or modifying features. 
+
+* Commits that fix or close an issue should reference them in the commit message
+`Closes #XXXX` or `Fixes #XXXX`. Mentions help by automatically closing the
+issue on a merge.
+
+* After every commit, run the test suite and ensure it is passing.
+
+* Sync and rebase frequently as you code to keep up with `docker` master.
+
+* Set your `git` signature and make sure you sign each commit.
+
+* Do not add yourself to the `AUTHORS` file. This file is autogenerated from the Git history.
+
+## Tests and testing
+
+* Submit unit tests for your changes. 
+
+* Make use of the builtin Go test framework built. 
+
+* Use existing Docker test files (`name_test.go`) for inspiration. 
+
+* Run <a href="../test-and-docs" target="_blank">the full test suite</a> on your branch before submitting a pull request.
+
+* Run `make docs` to build the documentation and then check it locally.
+
+* Use an <a href="http://www.hemingwayapp.com" target="_blank">online grammar
+checker</a> or similar to test you documentation changes for clarity, concision,
+and correctness.
+
+## Pull requests
+
+* Sync and cleanly rebase on top of Docker's `master` without multiple branches
+mixed into the PR.
+
+* Before the pull request, squash your commits into logical units of work using `git rebase -i` and `git push -f`. 
+
+* Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
+
+* Reference each issue in your pull request description (`#XXXX`)
+
+## Respond to pull requests reviews 
+
+* Docker maintainers use LGTM (**l**ooks-**g**ood-**t**o-**m**e) in PR comments to indicate acceptance.
+
+* Code review comments may be added to your pull request. Discuss, then make the
+suggested modifications and push additional commits to your feature branch. 
+
+* Incorporate changes on your feature branch and push to your fork. This automatically updates your open pull request.
+
+* Post a comment after pushing to alert reviewers to PR changes; pushing a change does not send notifications.
+
+* A change requires LGTMs from an absolute majority maintainers of an affected component. For example, if you change `docs/` and `registry/` code, an absolute majority of the `docs/` and the `registry/` maintainers must approve your PR.
+
+## Merges after pull requests
+
+* After a merge, [a master build](https://master.dockerproject.com/) is available almost immediately. 
+
+* If you made a documentation change, you can see it at [docs.master.dockerproject.com](http://docs.master.dockerproject.com/). 

docs/sources/project/get-help.md

@@ -0,0 +1,119 @@
+page_title: Where to chat or get help
+page_description: Describes Docker's communication channels
+page_keywords: IRC, Google group, Twitter, blog, Stackoverflow
+
+# Where to chat or get help
+
+There are several communications channels you can use to chat with Docker community members and developers. 
+
+<style type="text/css">
+.tg  {border-collapse:collapse;border-spacing:0;text-align: left;}
+.tg td{font-family:Arial, sans-serif;font-size:14px;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;vertical-align:top;}
+.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
+</style>
+<table class="tg">
+  <col width="25%">
+  <col width="75%">
+  <tr>
+    <td class="tg-031e">Internet Relay Chat (IRC)</th>
+    <td class="tg-031e"><p>IRC a direct line to our most knowledgeable Docker users. The <code>#docker</code> and <code>#docker-dev</code> group  on <strong>irc.freenode.net</strong>. IRC was first created in 1988. So, it is a rich chat protocol but it can overwhelm new users. You can search <a href="https://botbot.me/freenode/docker/#" target="_blank">our chat archives</a>.</p>
+    Read our IRC quickstart guide below for an easy way to get started.</th>
+  </tr>
+  <tr>
+    <td class="tg-031e">Google Groups</td>
+    <td class="tg-031e">There are two groups. <a href="https://groups.google.com/forum/#!forum/docker-user" target="_blank">Docker-user</a> is for people using Docker containers. The <a href="https://groups.google.com/forum/#!forum/docker-dev" target="_blank">docker-dev</a> group is for contributors and other people contributing to the Docker project.</td>
+  </tr>
+  <tr>
+    <td class="tg-031e">Twitter</td>
+    <td class="tg-031e">You can follow <a href="https://twitter.com/docker/" target="_blank">Docker's twitter</a> to get updates on our products. You can also tweet us questions or just share blogs or stories.</td>
+  </tr>
+  <tr>
+    <td class="tg-031e">Stackoverflow</td>
+    <td class="tg-031e">Stackoverflow has over 7000K Docker questions listed. We regularly monitor <a href="http://stackoverflow.com/search?tab=newest&q=docker" target="_blank">Docker questions</a> and so do many other knowledgeable Docker users.</td>
+  </tr>
+</table>
+
+
+## IRC Quickstart
+
+IRC can also be overwhelming for new users. This quickstart shows you the easiest way to connect to IRC. 
+
+1. In your browser open <a href="http://webchat.freenode.net" target="_blank">http://webchat.freenode.net</a>
+
+	![Login screen](/project/images/irc_connect.png)
+
+
+2. Fill out the form.
+
+	<style type="text/css">
+.tg  {border-collapse:collapse;border-spacing:0;}
+.tg td{font-family:Arial, sans-serif;font-size:14px;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
+.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
+</style>
+<table class="tg">
+  <tr>
+    <th class="tg-031e"><b>Nickname</b></th>
+    <th class="tg-031e">The short name you want to be known as in IRC.</th>
+  </tr>
+  <tr>
+    <td class="tg-031e"><b>Channels</b></td>
+    <td class="tg-031e"><code>#docker</code></td>
+  </tr>
+  <tr>
+    <td class="tg-031e"><b>reCAPTCHA</b></td>
+    <td class="tg-031e">Use the value provided.</td>
+  </tr>
+</table>
+
+3. Click "Connect".
+
+	The system connects you to chat. You'll see a lot of text. At the bottom of
+	the display is a command line. Just above the command line the system asks 
+	you to register.
+	
+	![Login screen](/project/images/irc_after_login.png)
+
+
+4. In the command line, register your nickname.
+
+		/msg nickserv REGISTER password youremail@example.com
+		
+	![Login screen](/project/images/register_nic.png)
+	
+	The IRC system sends an email to the address you
+	enter. The email contains instructions for completing your registration.
+	
+5. Open your mail client and look for the email.
+	
+	![Login screen](/project/images/register_email.png)
+	
+6. Back in the browser, complete the registration according to the email.
+
+	 	/msg NickServ VERIFY REGISTER moxiegirl_ acljtppywjnr
+	
+7. Join the `#docker` group using the following command.
+
+		/j #docker
+		
+	You can also join the `#docker-dev` group.
+	
+		/j #docker-dev
+		
+8. To ask questions to the channel just type messages in the command line.
+
+	![Login screen](/project/images/irc_chat.png)
+
+9. To quit, close the browser window.
+
+
+### Tips and learning more about IRC
+
+Next time you return to log into chat, you'll need to re-enter your password on the command line using this command:
+
+	/msg NickServ identify <password>
+	
+If you forget or lose your password see <a
+href="https://freenode.net/faq.shtml#sendpass" target="_blank">the FAQ on
+freenode.net</a> to learn how to recover it.
+	
+This quickstart was meant to get you up and into IRC very quickly. If you find IRC useful there is a lot more to learn. Drupal, another open source project, actually has <a href="https://www.drupal.org/irc/setting-up" target="_blank">written a lot of good documentation about using IRC</a> for their project (thanks Drupal!).  

docs/sources/project/glossary.md

@@ -0,0 +1,7 @@
+page_title: Glossary
+page_description: tbd
+page_keywords: tbd
+
+## Glossary
+
+TBD

docs/sources/project/make-a-contribution.md

@@ -0,0 +1,453 @@
+page_title: Make a project contribution
+page_description: Basic workflow for Docker contributions
+page_keywords: contribute, pull request, review, workflow, white-belt, black-belt, squash, commit
+
+# Make a project contribution
+
+Contributing is a process where you work with Docker maintainers and the community to improve Docker. There is a formal process for contributing. We try to keep our contribution process simple so you want to come back.
+
+
+In this section, you will create a new branch and work on some Docker code that you choose. Before you work through this process, take a few minutes to read through the next section which explains our basic contribution workflow. 
+
+## The basic contribution workflow
+
+You are about to work through our basic contribution workflow by fixing a single *white-belt* issue in the `docker/docker` repository. The workflow for fixing simple issues looks like this:
+
+![Simple process](/project/images/existing_issue.png)
+
+All Docker repositories have code and documentation. This workflow works for either content type. For example, you can find and fix doc or code issues. Also, you can propose a new Docker feature or propose a new Docker tutorial. 
+
+Some workflow stages have slight differences for code or documentation contributions. When you reach that point in the flow, we make sure to tell you.
+
+## Find and claim an existing issue
+
+An existing issue is something reported by a Docker user. As issues come in, our maintainers triage them. Triage is its own topic. For now, it is important for you to know that triage includes ranking issues according to difficulty. 
+
+Triaged issues have either a **white-belt** or **black-belt** label.   A **white-belt** issue is considered an easier issue. Issues can have more than one the **white-belt** label, for example, **bug**, **improvement**, **/project/doc**, and so forth. These other labels are their for filtering purposes but you might also find them helpful.
+
+In the next procedure, you find and claim an open white-belt issue.
+
+
+1. Go to the `docker/docker` <a
+	href="https://github.com/docker/docker" target="_blank">repository</a>.
+
+2. Click on the "Issues" link.
+
+   	A list of the open issues appears. 
+		
+	![Open issues](/project/images/issue_list.png)
+
+3. Look for the **white-belt** items on the list.
+
+4. Click on the "Labels" dropdown and select  **white-belt**.
+
+	The system filters to show only open **white-belt** issues.
+
+5. Open an issue that interests you.
+
+	The comments on the issues can tell you both the problem and the potential 
+	solution.
+	
+6. Make sure that no other user has chosen to work on the issue.
+
+    We don't allow external contributors to assign issues to themselves, so you
+    need to read the comments to find if a user claimed an issue by saying:
+    
+    * "I'd love to give this a try~"
+    * "I'll work on this!"
+    * "I'll take this."
+    
+    The community is very good about claiming issues explicitly.
+
+7. When you find an open issue that both interests you and is unclaimed, claim it yourself by adding a comment.
+
+	![Easy issue](/project/images/easy_issue.png)
+
+	This example uses issue 11038. Your issue # will be different depending on
+	what you claimed.
+	
+8. Make a note of the issue number; you'll need it later.
+
+## Sync your fork and create a new branch
+
+If you have followed along in this guide, you forked the `docker/docker` repository. Maybe that was an hour ago or a few days ago. In any case, before you start working on your issue, sync your repository with the upstream `docker/docker` master. Syncing ensures your repository has the latest changes.
+
+To sync your repository:
+
+1. Open a terminal on your local host.
+
+2. Change directory to the `docker-fork` root.
+
+		$ cd ~/repos/docker-fork
+
+3. Checkout the master branch.
+
+		$ git checkout master
+		Switched to branch 'master'
+		Your branch is up-to-date with 'origin/master'.
+		
+	Recall that `origin/master` is a branch on your remote GitHub repository.
+
+4. Make sure you have the upstream remote `docker/docker` by listing them.
+
+		$ git remote -v
+		origin	https://github.com/moxiegirl/docker.git (fetch)
+		origin	https://github.com/moxiegirl/docker.git (push)
+		upstream	https://github.com/docker/docker.git (fetch)
+		upstream	https://github.com/docker/docker.git (
+	
+	If the `upstream` is missing, add it.
+	
+		$ git remote add upstream https://github.com/docker/docker.git
+
+5. Fetch all the changes from the `upstream/master` branch.
+
+		$ git fetch upstream/master
+		remote: Counting objects: 141, done.
+		remote: Compressing objects: 100% (29/29), done.
+		remote: Total 141 (delta 52), reused 46 (delta 46), pack-reused 66
+		Receiving objects: 100% (141/141), 112.43 KiB | 0 bytes/s, done.
+		Resolving deltas: 100% (79/79), done.
+		From github.com:docker/docker
+		   9ffdf1e..01d09e4  docs       -> upstream/docs
+		   05ba127..ac2521b  master     -> upstream/master
+		   
+	This command says get all the changes from the `master` branch belonging to
+	the `upstream` remote.
+		   
+7. Rebase your local master with the `upstream/master`.
+
+		$ git rebase upstream/master
+		First, rewinding head to replay your work on top of it...
+		Fast-forwarded master to upstream/master.
+		
+	This command writes all the commits from the upstream branch into your local
+	branch.
+		
+8.  Check the status of your local branch.
+
+		$ git status
+		On branch master
+		Your branch is ahead of 'origin/master' by 38 commits.
+		  (use "git push" to publish your local commits)
+		nothing to commit, working directory clean
+
+	Your local repository now has any changes from the `upstream` remote.  You
+	need to push the changes to your own remote fork which is `origin/master`.
+
+9. Push the rebased master to `origin/master`.
+
+		$ git push
+		Username for 'https://github.com': moxiegirl
+		Password for 'https://moxiegirl@github.com': 
+		Counting objects: 223, done.
+		Compressing objects: 100% (38/38), done.
+		Writing objects: 100% (69/69), 8.76 KiB | 0 bytes/s, done.
+		Total 69 (delta 53), reused 47 (delta 31)
+		To https://github.com/moxiegirl/docker.git
+		   8e107a9..5035fa1  master -> master
+
+	If you check 
+
+9. Create a new feature branch to work on your issue.
+
+	Your branch name should have the format `XXXX-descriptive` where `XXXX` is
+	the issue number you are working on. For example:
+
+		$ git checkout -b 11038-fix-rhel-link
+		Switched to a new branch '11038-fix-rhel-link'
+		
+	Your branch should be up-to-date with the upstream/master. Why? Because you
+	branched off a freshly synced master.  Let's check this anyway in the next
+	step.
+
+9. Rebase your branch from upstream/master.
+
+		$ git rebase upstream/master
+		Current branch 11038-fix-rhel-link is up to date.
+		
+	At this point, your local branch, your remote repository, and the Docker
+	repository all have identical code. You are ready to make changesfor your
+	issues.
+		
+## Work on your issue
+
+The work you do for your issue depends on the specific issue you picked. This section gives you a step-by-step workflow. Where appropriate, it provides command examples. However, this is a generalized workflow, depending on your issue you may you may repeat steps or even skip some. How much time it takes you depends on you --- you could spend days or 30 minutes of your time.
+
+Follow this workflow as you work:
+
+1. Review the appropriate style guide.
+
+	If you are changing code, review the <a href="../coding-style"
+	target="_blank">coding style guide</a>. Changing documentation? Review the
+	<a href="../doc-style" target="_blank">documentation style guide</a>. 
+	
+2. Make changes in your feature branch.
+
+	Your feature branch you created in the last section. Here you use the
+	development container. If you are making a code change, you can mount your
+	source into a development container and iterate that way. For documentation
+	alone, you can work on your local host. 
+	
+	Review <a href="../set-up-dev-env" target="_blank">if you forgot the details
+	of working with a container</a>.
+
+
+3. Test your changes as you work.
+
+	If you have followed along with the guide, you know the `make test` target
+	runs the entire test suite and `make docs` builds the documentation. If you
+	forgot the other test targets, see the documentation for <a
+	href="../test-and-docs" target="_blank">testing both code and
+	documentation</a>.  
+	
+4. For code changes, add unit tests if appropriate.
+
+	If you add new functionality or change existing functionality, you should
+	add a unit test also. Use the existing test files for inspiration. Aren't
+	sure if you need tests? Skip this step; you can add them later in the
+	process if necessary.
+	
+5. Format your source files correctly.
+
+	<style type="text/css">
+	.tg  {border-collapse:collapse;border-spacing:0;margin-bottom:15px;}
+	.tg td{font-family:Arial, sans-serif;font-size:14px;padding:5px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;vertical-align:top;}
+	.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:bold;padding:5px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;text-align:left;}
+	.tg .tg-e3zv{width:150px;}
+	</style>
+	<table class="tg">
+	  <tr>
+		<th class="tg-e3zv">File type</th>
+		<th class="tg-031e">How to format</th>
+	  </tr>
+	  <tr>
+		<td class="tg-e3zv"><code>.go</code></td>
+		<td class="tg-031e"><p>Format <code>.go</code> files using the <code>gofmt</code> command. For example, if you edited the `docker.go` file you would format the file
+		like this:
+		</p>
+		<p><code>$ gofmt -s -w file.go</code></p>
+		<p>	
+		Most file editors have a plugin to format for you. Check your editor's
+		documentation.
+		</p>
+		</td>
+	  </tr>
+	  <tr>
+		<td class="tg-e3zv"><code>.md</code> and non-<code>.go</code> files</td>
+		<td class="tg-031e">Wrap lines to 80 characters.</td>
+	  </tr>
+	</table>
+	
+
+6. List your changes.
+
+		$ git status
+		On branch 11038-fix-rhel-link
+		Changes not staged for commit:
+		  (use "git add <file>..." to update what will be committed)
+		  (use "git checkout -- <file>..." to discard changes in working directory)
+
+			modified:   docs/sources/installation/mac.md
+			modified:   docs/sources/installation/rhel.md
+			
+	The `status` command lists what changed in the repository. Make sure you see
+	the changes you expect.
+	
+7. Add your change to Git.
+
+		$ git add docs/sources/installation/mac.md
+		$ git add docs/sources/installation/rhel.md
+		
+		
+8. Commit your changes making sure you use the `-s` flag to sign your work.
+
+		$ git commit -s -m "Fixing RHEL link"
+	
+9. Push your change to your repository.
+		 
+		$ git push --set-upstream origin 11038-fix-rhel-link
+		Username for 'https://github.com': moxiegirl
+		Password for 'https://moxiegirl@github.com': 
+		Counting objects: 60, done.
+		Compressing objects: 100% (7/7), done.
+		Writing objects: 100% (7/7), 582 bytes | 0 bytes/s, done.
+		Total 7 (delta 6), reused 0 (delta 0)
+		To https://github.com/moxiegirl/docker.git
+		 * [new branch]      11038-fix-rhel-link -> 11038-fix-rhel-link
+		Branch 11038-fix-rhel-link set up to track remote branch 11038-fix-rhel-link from origin.
+		
+10. Open your fork on GitHub to see your change.
+
+## Create a pull request to docker/docker
+
+A pull request sends your code to the Docker maintainers for review. Your pull request goes from your forked repository to the `docker/docker` repository.  You can see <a href="https://github.com/docker/docker/pulls" target="_blank">the list of active pull requests to Docker</a> on GitHub. 
+
+To create a pull request for your change:
+
+1. In a terminal window, go to the root of your `docker-fork` repository. 
+
+		$ cd ~/repos/docker-fork
+
+2. Checkout your feature branch.
+
+		$ git checkout 11038-fix-rhel-link
+		Already on '11038-fix-rhel-link'
+
+3. Run the full test suite on your branch.
+
+		$ make test
+		
+	All the tests should pass. If they don't, find out why and correct the
+	situation. If you also modified the documentation,  run `make docs` and
+	check your work.
+	
+4.  Update your remote repository with any changes that result from your last minute checks.	
+
+	Use the `git add`, the `git commit -s`, and `git push` commands to do this.
+	
+4. Fetch any of the last minute changes from `docker/docker`.
+
+		$ git fetch upstream master
+		From github.com:docker/docker
+		 * branch            master     -> FETCH_HEAD
+
+5. Squash your individual separate commits into one by using Git’s interactive rebase:
+
+		$ git rebase -i upstream/master
+		
+	This commit will open up your favorite editor with all the comments from
+	all your latest commits.
+	
+		pick 1a79f55 Tweak some of the other text for grammar
+		pick 53e4983 Fix a link
+		pick 3ce07bb Add a new line about RHEL
+		
+6. Replace the `pick` keyword with `squash` on all but the first commit.
+	
+		pick 1a79f55 Tweak some of the other text for grammar
+		squash 53e4983 Fix a link
+		squash 3ce07bb Add a new line about RHEL	
+				
+	After closing the file, `git` opens your editor again to edit the commit
+	message. 
+	
+7. Save your commit message.
+
+
+8. Push any changes to your fork on GitHub.
+
+		$ git push origin 11038-fix-rhel-link
+		
+9. Open your browser to your fork on GitHub.
+
+	You should see the latest activity from your branch.
+	
+	![Latest commits](/project/images/latest_commits.png)
+
+	
+10. Click "Compare & pull request".
+
+	The system displays the pull request dialog. 
+	
+	![PR dialog](/project/images/to_from_pr.png)
+	
+	The pull request compares your changes to the `master` branch on the `docker/docker` repository.
+
+11. Edit the dialog's description and add a reference to the issue you are fixing.
+
+	GitHub helps you out by searching for the issue as you type.
+	
+	![Fixes issue](/project/images/fixes_num.png)
+
+12. Scroll down and verify the PR contains the commits and changes you expect.
+
+	For example, is the file count correct? Are the changes in the files what
+	you expect.
+	
+	![Commits](/project/images/commits_expected.png)
+
+13. Press "Create pull request".
+
+	The system creates the request and opens it for you in the `docker/docker`
+	repository.
+
+	![Pull request made](/project/images/pull_request_made.png)
+
+## Your pull request under review
+
+At this point, your pull request is reviewed. The first reviewer is Gordon. He might who might look slow in this picture: 
+
+![Gordon](/project/images/gordon.jpeg)
+
+He is actually pretty fast over a network. He checks your pull request (PR) for common problems like missing signatures. If Gordon finds a problem, he'll send  an email to your GitHub user.
+
+After Gordon, the core Docker maintainers look at your pull request and comment on it. The shortest comment you might see is `LGTM` which means **l**ooks-**g**ood-**t**o-**m**e. If you get an `LGTM`, that is a good thing, you passed that review. 
+
+For complex changes, maintainers may ask you questions or ask you to change something about your submission. All maintainer comments on a PR go to the email address associated with your GitHub account. Any GitHub user who "participates" in a PR receives an email to.  Participating means creating or commenting on a PR.
+
+Our maintainers are very experienced Docker users and open source contributors. So, they value your time and will try to work efficiently with you by keeping their comments specific and brief.  If they ask you to make a change, you'll need to update your pull request with additional changes.
+
+To update your existing pull request:
+
+1. Change one or more files in your local `docker-fork` repository.
+
+2. Commit the change with the `git commit --amend` command.
+
+		$ git commit --amend 
+		
+	Git opens an editor containing your last commit message.
+		
+3. Adjust your last comment to reflect this new change.
+
+		Added a new sentence per Anaud's suggestion	
+
+		Signed-off-by: Mary Anthony <mary@docker.com>
+
+		# Please enter the commit message for your changes. Lines starting
+		# with '#' will be ignored, and an empty message aborts the commit.
+		# On branch 11038-fix-rhel-link
+		# Your branch is up-to-date with 'origin/11038-fix-rhel-link'.
+		#
+		# Changes to be committed:
+		#		modified:   docs/sources/installation/mac.md
+		#		modified:   docs/sources/installation/rhel.md
+
+4. Push to your origin.
+
+		$ git push origin
+		
+5. Open your browser to your pull request on GitHub.
+
+	You should see your pull request now contains your newly pushed code.
+
+6. Add a comment to your pull request.
+	
+	GitHub only notifies PR participants when you comment. For example, you can
+	mention that you updated your PR. Your comment alerts the maintainers that
+	you made an update.
+	
+A change requires LGTMs from an absolute majority of an affected component's maintainers. For example, if you change `docs/` and `registry/` code, an absolute majority of the `docs/` and the `registry/` maintainers must approve your PR. Once you get approval, we merge your pull request into Docker's `master` cod branch. 
+
+## After the merge
+
+It can take time to see a merged pull request in Docker's official release. A master build is available almost immediately though. Docker builds and updates its development binaries after each merge to `master`. 
+
+1. Browse to <a href="https://master.dockerproject.com/" target="_blank">https://master.dockerproject.com/</a>.
+
+2. Look for the binary appropriate to your system.
+
+3. Download and run the binary.
+
+	You might want to run the binary in a container though. This
+	will keep your local host environment clean.
+
+4. View any documentation changes at <a href="http://docs.master.dockerproject.com/" target="_blank">docs.master.dockerproject.com</a>. 
+
+Once you've verified everything merged, feel free to delete your feature branch from your fork. For information on how to do this, <a href="https://help.github.com/articles/deleting-unused-branches/" target="_blank">see the GitHub help on deleting branches</a>.  
+
+## Where to go next
+
+At this point, you have completed all the basic tasks in our contributors guide. If you enjoyed contributing, let us know by completing another **white-belt** issue or two. We really appreciate the help. 
+
+If you are very experienced and want to make a major change, go onto [learn about advanced contributing](/project/advanced-contributing).

docs/sources/project/set-up-dev-env.md

@@ -0,0 +1,415 @@
+page_title: Work with a development container
+page_description: How to use Docker's development environment
+page_keywords: development, inception, container, image Dockerfile, dependencies, Go, artifacts
+
+# Work with a development container
+
+In this section, you learn to develop like a member of Docker's core team.
+The `docker` repository includes a `Dockerfile` at its root. This file defines
+Docker's development environment.  The `Dockerfile` lists the environment's
+dependencies: system libraries and binaries, go environment, go dependencies,
+etc. 
+
+Docker's development environment is itself, ultimately a Docker container.
+You use the `docker` repository and its `Dockerfile` to create a Docker image, run a Docker container, and develop code in the container. Docker itself builds, tests, and releases new Docker versions using this container.
+
+If you followed the procedures that <a href="../set-up-prereqs" target="_blank">set up the prerequisites</a>, you should have a fork of the
+`docker/docker` repository. You also created a branch called `dry-run-test`. In this section, you continue working with your fork on this branch. 
+
+
+##  Clean your host of Docker artifacts
+
+Docker developers run the latest stable release of the Docker software; Or Boot2docker and Docker if their machine is Mac OS X. They clean their local hosts of unnecessary Docker artifacts such as stopped containers or unused images. Cleaning unnecessary artifacts isn't strictly necessary but it is good practice, so it is included here.
+
+To remove unnecessary artifacts.
+
+1. Verify that you have no unnecessary containers running on your host.
+
+		$ docker ps
+		
+	You should see something similar to the following:
+		
+	<style type="text/css">
+	.tg  {border-collapse:collapse;border-spacing:0;} .tg td{font-family:monospace, serif;font-size:11px;padding:10px 5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;} .tg th{font-family:monospace, sans-serif;font-size:11px;font-weight:normal;padding:10px
+5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;}
+	</style>
+	<table class="tg">
+	  <tr>
+		<th class="tg-031e">CONTAINER ID</th>
+		<th class="tg-031e">IMAGE</th>
+		<th class="tg-031e">COMMAND</th>
+		<th class="tg-031e">CREATED</th>
+		<th class="tg-031e">STATUS</th>
+		<th class="tg-031e">PORTS</th>
+		<th class="tg-031e">NAMES</th>
+	  </tr>
+	</table>
+
+	There are no running containers on this host. If you have running but unused
+	containers, stop and then remove them with the `docker stop` and `docker rm`
+	commands.
+
+2. Verify that your host has no dangling images.
+
+		$ docker images
+		
+	You should see something similar to the following:
+		
+	<style type="text/css">
+	.tg  {border-collapse:collapse;border-spacing:0;} .tg td{font-family:monospace, serif;font-size:11px;padding:10px 5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;} .tg th{font-family:monospace, serif;font-size:11px;font-weight:normal;padding:10px
+5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;}
+	</style>
+	<table class="tg">
+	  <tr>
+		<th class="tg-031e">REPOSITORY</th>
+		<th class="tg-031e">TAG</th>
+		<th class="tg-031e">IMAGE ID</th>
+		<th class="tg-031e">CREATED</th>
+		<th class="tg-031e">VIRTUAL SIZE</th>
+	  </tr>
+	</table>
+
+	This host has no images. You may have one or more _dangling_ images. A
+	dangling image is not used by a running container and is not an ancestor of
+	another image on your system. A fast way to remove dangling containers is
+	the following:
+
+		$ docker rmi -f $(docker images -q -a -f dangling=true)
+		
+	This command uses `docker images` to lists all images (`-a` flag) by numeric
+	IDs (`-q` flag) and filter them to find dangling images (`-f
+	dangling=true`). Then, the `docker rmi` command forcibly (`-f` flag) removes
+	the resulting list. To remove just one image, use the `docker rmi ID`
+	command.
+
+	
+## Build an image
+
+If you followed the last procedure, your host is clean of unnecessary images and containers. In this section, you build an image from the Docker development environment.
+
+1. Open a terminal.
+
+	Mac users, use `boot2docker status` to make sure Boot2Docker is running. You
+	may need to run `$(boot2docker shellinit)` to initialize your shell
+	environment.
+
+3. Change into the root of your forked repository.
+
+		$ cd ~/repos/docker-fork 
+
+4. Ensure you are on your `dry-run-test` branch.
+
+		$ git checkout dry-run-test 
+
+5. Compile your development environment container into an image.
+
+		$ docker build -t dry-run-test .
+
+	The `docker build` command returns informational message as it runs. The
+	first build may take a few minutes to create an image. Using the
+	instructions in the `Dockerfile`, the build may need to download source and
+	other images. A successful build returns a final status message similar to
+	the following:
+
+		 Successfully built 676815d59283 
+
+6. List your Docker images again.
+
+		$ docker images
+
+	You should see something similar to this:
+		 <style type="text/css">
+	.tg  {border-collapse:collapse;border-spacing:0;} .tg td{font-family:monospace, serif;font-size:11px;padding:5px 5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;} .tg th{font-family:monospace, serif;font-size:11px;font-weight:normal;padding:5px
+5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;}
+	</style>
+	<table class="tg">
+	  <tr>
+		<th class="tg-031e">REPOSTITORY</th>
+		<th class="tg-031e">TAG</th>
+		<th class="tg-031e">IMAGE ID</th>
+		<th class="tg-031e">CREATED</th>
+		<th class="tg-031e">VIRTUAL SIZE</th>
+	  </tr>
+	  <tr>
+		<td class="tg-031e">dry-run-test</td>
+		<td class="tg-031e">latest</td>
+		<td class="tg-031e">663fbee70028</td>
+		<td class="tg-031e">About a minute ago</td>
+		<td class="tg-031e"></td>
+	  </tr>
+	  <tr>
+		<td class="tg-031e">ubuntu</td>
+		<td class="tg-031e">trusty</td>
+		<td class="tg-031e">2d24f826cb16</td>
+		<td class="tg-031e">2 days ago</td>
+		<td class="tg-031e">188.3 MB</td>
+	  </tr>
+	  <tr>
+		<td class="tg-031e">ubuntu</td>
+		<td class="tg-031e">trusty-20150218.1</td>
+		<td class="tg-031e">2d24f826cb16</td>
+		<td class="tg-031e">2 days ago</td>
+		<td class="tg-031e">188.3 MB</td>
+	  </tr>
+	  <tr>
+		<td class="tg-031e">ubuntu</td>
+		<td class="tg-031e">14.04</td>
+		<td class="tg-031e">2d24f826cb16</td>
+		<td class="tg-031e">2 days ago</td>
+		<td class="tg-031e">188.3 MB</td>
+	  </tr>
+	  <tr>
+		<td class="tg-031e">ubuntu</td>
+		<td class="tg-031e">14.04.2</td>
+		<td class="tg-031e">2d24f826cb16</td>
+		<td class="tg-031e">2 days ago</td>
+		<td class="tg-031e">188.3 MB</td>
+	  </tr>
+	  <tr>
+		<td class="tg-031e">ubuntu</td>
+		<td class="tg-031e">latest</td>
+		<td class="tg-031e">2d24f826cb16</td>
+		<td class="tg-031e">2 days ago</td>
+		<td class="tg-031e">188.3 MB</td>
+	  </tr>
+	</table>
+
+	Locate your new `dry-run-test` image in the list. You should also see a
+	number of `ubuntu` images. The build process creates these. They are the
+	ancestors of your new Docker development image. When you next rebuild your
+	image, the build process reuses these ancestors images if they exist. 
+	
+	Keeping the ancestor images improves the build performance. When you rebuild
+	the child image, the build process uses the local ancestors rather than
+	retrieving them from the Hub. The build process gets new ancestors only if
+	DockerHub has updated versions.
+
+## Start a container and run a test
+
+At this point, you have created a new Docker development environment image. Now,
+you'll use this image to create a Docker container to develop in. Then, you'll
+build and run a `docker` binary in your container.
+
+1. Open two additional terminals on your host.
+
+	At this point, you'll have about three terminals open.
+
+	![Multiple terminals](/project/images/three_terms.png)
+
+	Mac OSX users, make sure you run `$(boot2docker shellinit)` in any new 
+	terminals.
+	
+2. In a terminal, create a new container from your `dry-run-test` image.
+
+		$ docker run --privileged --rm -ti dry-run-test /bin/bash
+		root@5f8630b873fe:/go/src/github.com/docker/docker# 
+
+	The command creates a container from your `dry-run-test` image. It opens an
+	interactive terminal (`-ti`) running a `/bin/bash shell`.  The
+	`--privileged` flag gives the container access to kernel features and device
+	access. It is this flag that allows you to run a container in a container.
+	Finally, the `-rm` flag instructs Docker to remove the container when you
+	exit the `/bin/bash` shell.
+	
+	The container includes the source of your image repository in the
+	`/go/src/github.com/docker/docker` directory. Try listing the contents to
+	verify they are the same as that of your `docker-fork` repo.
+	
+	![List example](/project/images/list_example.png)
+
+
+3. Investigate your container bit. 
+
+	If you do a `go version` you'll find the `go` language is part of the
+	container. 
+	
+		root@31ed86e9ddcf:/go/src/github.com/docker/docker# go version
+		go version go1.4.2 linux/amd64
+	
+	Similarly, if you do a `docker version` you find the container
+	has no `docker` binary. 
+	
+		root@31ed86e9ddcf:/go/src/github.com/docker/docker# docker version
+		bash: docker: command not found
+	
+	You will create one in the next steps.
+	
+4. From the `/go/src/github.com/docker/docker` directory make a `docker` binary with the `make.sh` script.
+
+		root@5f8630b873fe:/go/src/github.com/docker/docker# project/make.sh binary
+    You only call `project/make.sh` to build a binary _inside_ a Docker
+	development container as you are now. On your host, you'll use `make`
+	commands (more about this later). 
+	
+	As it makes the binary, the `make.sh` script reports the build's progress.
+	When the command completes successfully, you should see the following
+	output:
+	
+		---> Making bundle: ubuntu (in bundles/1.5.0-dev/ubuntu)
+		Created package {:path=>"lxc-docker-1.5.0-dev_1.5.0~dev~git20150223.181106.0.1ab0d23_amd64.deb"}
+		Created package {:path=>"lxc-docker_1.5.0~dev~git20150223.181106.0.1ab0d23_amd64.deb"}
+
+	
+5. List all the contents of the `binary` directory.
+
+		root@5f8630b873fe:/go/src/github.com/docker/docker#  ls bundles/1.5.0-dev/binary/
+		docker  docker-1.5.0-dev  docker-1.5.0-dev.md5  docker-1.5.0-dev.sha256
+		
+	  You should see that `binary` directory, just as it sounds, contains the
+	  made binaries.
+
+
+6. Copy the `docker` binary to the `/usr/bin` of your container.
+
+		root@5f8630b873fe:/go/src/github.com/docker/docker#  cp bundles/1.5.0-dev/binary/docker /usr/bin
+		
+7. Inside your container, check your Docker version.
+
+	root@5f8630b873fe:/go/src/github.com/docker/docker# docker --version
+	Docker version 1.5.0-dev, build 6e728fb
+	
+	Inside the container you are running a development version. This is version
+	on the current branch it reflects the value of the `VERSION` file at the
+	root of your `docker-fork` repository.
+
+8. Start a `docker` daemon running inside your container.
+
+		root@5f8630b873fe:/go/src/github.com/docker/docker#  docker -dD
+		
+	The `-dD` flag starts the daemon in debug mode; You'll find this useful
+	when debugging your code.
+		
+9. Bring up one of the terminals on your local host.
+
+
+10. List your containers and look for the container running the `dry-run-test` image.
+
+		$ docker ps
+			
+	<style type="text/css">
+	.tg  {border-collapse:collapse;border-spacing:0;} .tg td{font-family:monospace, serif;font-size:11px;padding:5px 5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;} .tg th{font-family:monospace, sans-serif;font-size:11px;font-weight:normal;padding:5px
+5px;border-style:solid;border-width:0px;overflow:hidden;word-break:normal;}
+	</style>
+	<table class="tg">
+	  <tr>
+		<th class="tg-031e">CONTAINER ID</th>
+		<th class="tg-031e">IMAGE</th>
+		<th class="tg-031e">COMMAND</th>
+		<th class="tg-031e">CREATED</th>
+		<th class="tg-031e">STATUS</th>
+		<th class="tg-031e">PORTS</th>
+		<th class="tg-031e">NAMES</th>
+	  </tr>
+	  <tr>
+		<td class="tg-031e">474f07652525</td>
+		<td class="tg-031e">dry-run-test:latest</td>
+		<td class="tg-031e">"hack/dind /bin/bash</td>
+		<td class="tg-031e">14 minutes ago</td>
+		<td class="tg-031e">Up 14 minutes</td>
+		<td class="tg-031e"></td>
+		<td class="tg-031e">tender_shockley</td>
+	  </tr>
+	</table>
+		
+	In this example, the container's name is `tender_shockley`; yours will be
+	different.
+		
+11. From the terminal, start another shell on your Docker development container.
+
+		$ docker exec -it tender_shockley bash
+		
+	At this point, you have two terminals both with a shell open into your
+	development container. One terminal is running a debug session. The other
+	terminal is displaying a `bash` prompt.
+
+12. At the prompt, test the Docker client by running the `hello-world` container.	
+
+		root@9337c96e017a:/go/src/github.com/docker/docker#  docker run hello-world
+	
+	You should see the image load and return. Meanwhile, you
+	can see the calls made via the debug session in your other terminal.
+
+	![List example](/project/images/three_running.png)
+	
+	
+## Restart a container with your source
+
+At this point, you have experienced the "Docker inception" technique. That is, you have:
+
+* built a Docker image from the Docker repository
+* created and started a Docker development container from that image
+* built a Docker binary inside of your Docker development container
+* launched a `docker` daemon using your newly compiled binary
+* called the `docker` client to run a `hello-world` container inside your development container
+
+When you really get to developing code though, you'll want to iterate code
+changes and builds inside the container. For that you need to mount your local
+Docker repository source into your Docker container. Try that now.
+
+1. If you haven't already, exit out of BASH shells in your running Docker
+container.
+
+	If you have followed this guide exactly, exiting out your BASH shells stops
+	the running container. You can use the `docker ps` command to verify the
+	development container is stopped. All of your terminals should be at the
+	local host prompt.
+	
+2. Choose a terminal and make sure you are in your `docker-fork` repository.
+
+		$ pwd
+		/Users/mary/go/src/github.com/moxiegirl/docker-fork
+	
+	Your location will be different because it reflects your environment. 
+
+3. Create a container using `dry-run-test` but this time mount your repository onto the `/go` directory inside the container.
+
+	 	$  docker run --privileged --rm -ti -v `pwd`:/go/src/github.com/docker/docker dry-run-test /bin/bash
+
+	When you pass `pwd`, `docker` resolves it to your current directory.
+
+4. From inside the container, list your `binary` directory.
+
+		root@074626fc4b43:/go/src/github.com/docker/docker# ls bundles/1.5.0-dev/binary
+		ls: cannot access binary: No such file or directory
+	
+	Your `dry-run-test` image does not retain any of the changes you made inside
+	the container.  This is the expected behavior for a container. 
+	
+5. In a fresh terminal on your local host, change to the `docker-fork` root.
+
+	$ cd ~/repos/docker-fork/
+
+6. Create a fresh binary but this time use the `make` command.
+
+		$ make BINDDIR=. binary
+	
+	The `BINDDIR` flag is only necessary on Mac OS X but it won't hurt to pass
+	it on Linux command line. The `make` command, like the `make.sh` script
+	inside the container, reports its progress. When the make succeeds, it
+	returns the location of the new binary.
+	
+
+7. Back in the terminal running the container, list your `binary` directory.
+
+		root@074626fc4b43:/go/src/github.com/docker/docker# ls bundles/1.5.0-dev/binary
+		docker	docker-1.5.0-dev  docker-1.5.0-dev.md5	docker-1.5.0-dev.sha256 
+	
+	The compiled binaries created from your repository on your local host are
+	now available inside your running Docker development container.
+	
+8. Repeat the steps you ran in the previous procedure.
+
+	* copy the binary inside the development container using
+		`cp bundles/1.5.0-dev/binary/docker /usr/bin`
+	* start `docker -dD` to launch the Docker daemon inside the container
+	* run `docker ps` on local host to get the development container's name
+	* connect to your running container `docker exec -it container_name bash`
+	* use the `docker run hello-world` command to create and run a container inside your development container
+	
+	
+## Where to go next
+
+Congratulations, you have successfully achieved Docker inception. At this point, you've set up your development environment and verified almost all the essential processes you need to contribute. Of course, before you start contributing, [you'll need to learn one more piece of the development environment, the test framework](/project/test-and-docs/). 
+
+ 
+

docs/sources/project/set-up-prereqs.md

@@ -0,0 +1,298 @@
+page_title: Set up the prerequisites
+page_description: Describes how to set up your local machine and repository
+page_keywords: GitHub account, repository, clone, fork, branch, upstream, Git, Go, make, 
+
+# Set up the prerequisites
+
+Work through this page to set up the software and host environment you need to contribute. You'll find instructions for configuring your `git` repository and creating a fork you'll use later in the guide.
+
+## Get the Required Software
+
+Before you begin contributing you must have:
+
+*  a GitHub account
+* `git`
+* `make` 
+* `docker`
+
+You'll notice that `go`, the language that Docker is written in, is not listed. That's because you don't need it installed; Docker's development environment provides it for you. You'll learn more about the development environment later.
+
+### Get a GitHub account
+
+To contribute to the Docker project, you will need a <a
+href="https://github.com" target="_blank">GitHub account</a>. A free account is
+fine. All the Docker project repositories are public and visible to everyone.
+
+You should also have some experience using both the GitHub application and `git` on the command line. 
+
+### Install git
+
+Install `git` on your local system. You can check if `git` is on already on your
+system and properly installed with the following command:
+
+	$ git --version 
+
+
+This documentation is written using `git` version 2.2.2. Your version may be different depending on your OS.
+
+### Install make
+
+Install `make`. You can check if `make` is on your system with the following
+command:
+
+	$ make -v 
+
+This documentation is written using GNU Make 3.81. Your version may be different depending on your OS.
+
+### Install or upgrade Docker 
+
+If you haven't already, install the Docker software using the <a href="/installation" target="_blank">instructions for your operating system</a>. If you have an existing installation, check your version and make sure you have the latest Docker. 
+
+To check if `docker` is already installed on Linux:
+
+	$ docker --version
+	Docker version 1.5.0, build a8a31ef
+
+On Mac OS X or Windows, you should have installed Boot2Docker which includes
+Docker. You'll need to verify both Boot2Docker and then Docker. This
+documentation was written on OS X using the following versions.
+
+
+	$ boot2docker version
+	Boot2Docker-cli version: v1.5.0
+	Git commit: ccd9032
+
+	$ docker --version
+	Docker version 1.5.0, build a8a31ef
+
+## Linux users and sudo
+
+This guide assumes you have added your user to the `docker` group on your system. To check, list the group's contents:
+
+	$ getent group docker
+	docker:x:999:ubuntu
+
+If the command returns no matches, you have two choices. You can preface this guide's `docker` commands with `sudo` as you work. Alternatively, you can add your user to the `docker` group as follows:
+
+ 	$ sudo usermod -aG docker ubuntu
+
+You must log out and back in for this modification to take effect.
+
+
+## Fork and clone the Docker code
+
+When contributing, you first fork the Docker code repository. A fork copies
+a repository at a particular point in time. GitHub tracks for you where a fork originates.
+
+As you make contributions, you change your fork's code. When you are ready,
+you make a pull request back to the original Docker repository. If you aren't
+familiar with this workflow, don't worry, this guide walks you through all the
+steps. 
+
+To fork and clone Docker:
+
+1. Open a browser and log into GitHub with your account.
+
+2. Go to the <a href="https://github.com/docker/docker" target="_blank">docker/docker repository</a>.
+
+3. Click the "Fork" button in the upper right corner of the GitHub interface.
+
+	![Branch Signature](/project/images/fork_docker.png)
+
+	GitHub forks the repository to your GitHub account. The original
+	`docker/docker` repository becomes a new fork `YOUR_ACCOUNT/docker` under
+	your account.
+	
+4. Copy your fork's clone URL from GitHub.
+
+	GitHub allows you to use HTTPS or SSH protocols for clones. You can use the
+	`git` command line or clients like Subversion to clone a repository. 
+	
+	![Copy clone URL](/project/images/copy_url.png)
+	
+	This guide assume you are using the HTTPS protocol and the `git` command
+	line. If you are comfortable with SSH and some other tool, feel free to use
+	that instead. You'll need to convert what you see in the guide to what is
+	appropriate to your tool.
+		
+5. Open a terminal window on your local host and change to your home directory.
+
+		$ cd ~
+		
+6. Create a `repos` directory.
+
+		$ mkdir repos
+
+7. Change into your `repos` directory.
+
+		$ cd repos
+
+5. Clone the fork to your local host into a repository called `docker-fork`.	
+
+		$ git clone https://github.com/moxiegirl/docker.git docker-fork
+	
+	Naming your local repo `docker-fork` should help make these instructions
+	easier to follow; experienced coders don't typically change the name.
+		
+6. Change directory into your new `docker-fork` directory.
+
+		$ cd docker-fork
+	
+	Take a moment to familiarize yourself with the repository's contents. List
+	the contents. 
+	
+		
+##  Set your signature and an upstream remote
+
+When you contribute to Docker, you must certify you agree with the <a href="http://developercertificate.org/" target="_blank">Developer Certificate of Origin</a>. You indicate your agreement by signing your `git` commits like this:
+
+	Signed-off-by: Pat Smith <pat.smith@email.com>
+
+To create a signature, you configure your username and email address in Git. You can set these globally or locally on just your `docker-fork` repository.  You must sign with your real name. We don't accept anonymous contributions or contributions through pseudonyms.
+
+As you change code in your fork, you'll want to keep it in sync with the changes others make in the `docker/docker` repository.  To make syncing easier, you'll also add a _remote_ called `upstream` that points to `docker/docker`. A remote is just another a project version hosted on the internet or network.
+
+To configure your username, email, and add a remote:
+		
+1. Change to the root of your `docker-fork` repository.
+
+		$ cd docker-fork
+
+2. 	Set your `user.name` for the repository.
+
+		$ git config --local user.name "FirstName LastName"
+			
+3. Set your `user.email` for the repository.
+
+		$ git config --local user.email "emailname@mycompany.com"
+	
+4. Set your local repo to track changes upstream, on the `docker` repository. 
+
+		$ git remote add upstream https://github.com/docker/docker.git
+
+7. Check the result in your `git` configuration.
+
+		$ git config --local -l
+		core.repositoryformatversion=0
+		core.filemode=true
+		core.bare=false
+		core.logallrefupdates=true
+		remote.origin.url=https://github.com/moxiegirl/docker.git
+		remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
+		branch.master.remote=origin
+		branch.master.merge=refs/heads/master
+		user.name=Mary Anthony
+		user.email=mary@docker.com
+		remote.upstream.url=https://github.com/docker/docker.git
+		remote.upstream.fetch=+refs/heads/*:refs/remotes/upstream/*
+
+	To list just the remotes use:
+		
+		$ git remote -v		
+		origin	https://github.com/moxiegirl/docker.git (fetch)
+		origin	https://github.com/moxiegirl/docker.git (push)
+		upstream	https://github.com/docker/docker.git (fetch)
+		upstream	https://github.com/docker/docker.git (push)
+	
+	
+		
+## Create and push a branch
+
+As you change code in your fork, you make your changes on a repository branch. The branch name should reflect what you are working on. In this section, you create a branch, make a change, and push it up to your fork. 
+
+This branch is just for testing your config for this guide. The changes are part of a dry run so the branch name is going to be dry-run-test. To create an push the branch to your fork on GitHub:
+
+1. Open a terminal and go to the root of your `docker-fork`.
+
+		$ cd docker-fork
+
+2. Create a `dry-run-test` branch.
+
+		$ git checkout -b dry-run-test
+		
+	This command creates the branch and switches the repository to it.
+
+3. Verify you are in your new branch.
+
+		$ git branch
+		* dry-run-test
+  		  master
+  	
+  	The current branch has an * (asterisk) marker. So, these results shows you
+ 	are on the right branch. 
+	
+4. Create a `TEST.md` file in the repository's root.
+
+		$ touch TEST.md
+	
+5. Edit the file and add your email and location.
+
+	![Add your information](/project/images/contributor-edit.png)
+	
+	You can use any text editor you are comfortable with.
+
+6. Close and save the file.
+
+7. Check the status of your branch. 
+
+		$ git status
+		On branch dry-run-test
+		Untracked files:
+		  (use "git add <file>..." to include in what will be committed)
+
+			TEST.md
+
+		nothing added to commit but untracked files present (use "git add" to track)
+	
+	You've only changed the one file. It is untracked so far by git.
+	
+8. Add your file.
+
+		$ git add TEST.md
+		
+	That is the only _staged_ file. Stage is fancy word for work that Git is
+	tracking.
+
+9. Sign and commit your change.
+
+		$ git -s -m "Making a dry run test."
+		[dry-run-test 6e728fb] Making a dry run test
+		 1 file changed, 1 insertion(+)
+		 create mode 100644 TEST.md
+
+
+	Commit messages should have a short summary sentence of no more than 50
+	characters. Optionally, you can also include a more detailed explanation
+	after the summary. Separate the summary from any explanation with an empty
+	line.
+
+8. Push your changes to GitHub.
+
+   	 	$ git push --set-upstream origin dry-run-test
+		Username for 'https://github.com': moxiegirl
+		Password for 'https://moxiegirl@github.com': 
+		
+	Git prompts you for your GitHub username and password. Then, the command
+	returns a result.
+		
+		Counting objects: 13, done.
+		Compressing objects: 100% (2/2), done.
+		Writing objects: 100% (3/3), 320 bytes | 0 bytes/s, done.
+		Total 3 (delta 1), reused 0 (delta 0)
+		To https://github.com/moxiegirl/docker.git
+		 * [new branch]      dry-run-test -> dry-run-test
+		Branch dry-run-test set up to track remote branch dry-run-test from origin.
+   	 	
+   	 		
+9. Open your browser to Github.
+
+10. Navigate to your Docker fork.
+
+11. Make sure the `dry-run-test` branch exists, that it has your commit, and the commit is signed.
+
+	![Branch Signature](/project/images/branch-sig.png)
+
+	
+## Where to go next
+
+Congratulations, you have set up and validated the contributor requirements. In the next section you'll [learn how to set up and work in a Docker development container](/project/set-up-dev-env/).

docs/sources/project/test-and-docs.md

@@ -0,0 +1,262 @@
+page_title: Run tests and test documentation
+page_description: Describes Docker's testing infrastructure
+page_keywords: make test, make docs, Go tests, gofmt, contributing, running tests
+
+# Run tests and test documentation
+
+Contributing includes testing your changes. If you change the Docker code, you
+may need to add a new test or modify an existing one. Your contribution could
+even be adding tests to Docker. For this reason, you need to know a little
+about Docker's test infrastructure.
+
+Many contributors contribute documentation only. Or, a contributor makes a code contribution that changes how Docker behaves and that change needs documentation. For these reasons, you also need to know how to build, view, and test the Docker documentation.
+
+In this section, you run tests in the `dry-run-test` branch of your Docker fork. If you have followed along in this guide, you already have this branch. If you don't have this branch, you can create it or simply use another of your branches. 
+
+## Understand testing at Docker
+
+Docker tests use the Go language's test framework. In this framework, files
+whose names end in `_test.go` contain test code; you'll find test files like
+this throughout the Docker repo. Use these files for inspiration when writing
+your own tests. For information on Go's test framework, see <a
+href="http://golang.org/pkg/testing/" target="_blank">Go's testing package
+documentation</a> and the <a href="http://golang.org/cmd/go/#hdr-Test_packages"
+target="_blank">go test help</a>. 
+
+You are responsible for _unit testing_ your contribution when you add new or change existing Docker code. A unit test is a piece of code that invokes a single, small piece of code ( _unit of work_ ) to verify the unit works as expected. 
+
+Depending on your contribution, you may need to add _integration tests_. These are tests that combine two or more work units into one component. These work units each have unit tests and then, together, integration tests that test the interface between the components. The `integration` and `integration-cli` directories in the Docker repository contain integration test code.
+
+Testing is its own speciality. If you aren't familiar with testing techniques, there is a lot of information available to you on the Web. For now, you should understand that, the Docker maintainers may ask you to write a new test or change an existing one. 
+
+### Run tests on your local host
+
+Before submitting any code change, you should run the entire Docker test suite. The `Makefile` contains a target for the entire test suite. The target's name is simply `test`. The make file contains several targets for testing:
+
+<style type="text/css">
+.tg  {border-collapse:collapse;border-spacing:0;margin-bottom:15px;}
+.tg td{font-family:Arial, sans-serif;font-size:14px;padding:5px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
+.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:5px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;text-align:left;}
+.tg .tg-vyw9{font-family:"Courier New", Courier, monospace !important;}
+.tg .tg-e3zv{font-weight:bold}
+</style>
+<table class="tg">
+  <tr>
+    <th class="tg-e3zv">Target</th>
+    <th class="tg-e3zv">What this target does</th>
+  </tr>
+  <tr>
+    <td class="tg-vyw9">test</td>
+    <td class="tg-031e">Run all the tests.</td>
+  </tr>
+  <tr>
+    <td class="tg-vyw9">test-unit</td>
+    <td class="tg-031e">Run just the unit tests.</td>
+  </tr>
+  <tr>
+    <td class="tg-vyw9">test-integration</td>
+    <td class="tg-031e">Run just integration tests.</td>
+  </tr>
+  <tr>
+    <td class="tg-vyw9">test-integration-cli</td>
+    <td class="tg-031e">Run the test for the integration command line interface.</td>
+  </tr>
+  <tr>
+    <td class="tg-vyw9">test-docker-py</td>
+    <td class="tg-031e">Run the tests for Docker API client.</td>
+  </tr>
+  <tr>
+    <td class="tg-vyw9">docs-test</td>
+    <td class="tg-031e">Runs the documentation test build.</td>
+  </tr>
+</table>
+
+Run the entire test suite on your current repository:
+
+1. Open a terminal on your local host.
+
+2. Change to the root your Docker repository.
+
+		$ cd docker-fork
+
+3. Make sure you are in your development branch.
+
+		$ git checkout dry-run-test
+
+4. Run the `make test` command.
+
+		$ make test
+		
+	This command does several things, it creates a container temporarily for testing. Inside that container, the `make`:
+	
+	* creates a new binary
+	* cross-compiles all the binaries for the various operating systems
+	* runs the all the tests in the system
+	
+	It can take several minutes to run all the tests. When they complete
+	successfully, you see the output concludes with something like this:
+	
+		
+		[PASSED]: top - sleep process should be listed in privileged mode
+		[PASSED]: version - verify that it works and that the output is properly formatted
+		PASS
+		coverage: 70.8% of statements
+		---> Making bundle: test-docker-py (in bundles/1.5.0-dev/test-docker-py)
+		+++ exec docker --daemon --debug --host unix:///go/src/github.com/docker/docker/bundles/1.5.0-dev/test-docker-py/docker.sock --storage-driver vfs --exec-driver native --pidfile /go/src/github.com/docker/docker/bundles/1.5.0-dev/test-docker-py/docker.pid
+		.................................................................
+		----------------------------------------------------------------------
+		Ran 65 tests in 89.266s
+		 
+	
+### Run test targets inside the development container
+
+If you are working inside a Docker development container, you use the `project/make.sh` script to run tests. The `project/make.sh` script doesn't have a single target that runs all the tests. Instead, you provide a single commmand line with multiple targets that does the same thing.
+
+Try this now.
+
+1. Open a terminal and change to the `docker-fork` root.
+
+2. Start a Docker development image.
+
+	If you are following along with this guide, you should have a `dry-run-test` image. 
+
+		$ docker run --privileged --rm -ti -v `pwd`:/go/src/github.com/docker/docker dry-run-test /bin/bash
+
+3. Run the tests using the `project/make.sh` script.
+
+		root@5f8630b873fe:/go/src/github.com/docker/docker# project/make.sh dynbinary binary cross test-unit test-integration test-integration-cli test-docker-py
+		
+	The tests run just as they did within your local host.
+		
+Of course, you can also run a subset of these targets too. For example, to run just the unit tests:
+
+			root@5f8630b873fe:/go/src/github.com/docker/docker# project/make.sh dynbinary binary cross test-unit
+
+Most test targets require that you build these precursor targets first: `dynbinary binary cross`
+
+
+## Running individual or multiple named tests 
+
+You can use the `TESTFLAGS` environment variable to run a single test. The flag's value is passed as arguments to the `go test` command. For example, from your local host you can run the `TestBuild` test with this command:
+
+    	$ TESTFLAGS='-test.run \^TestBuild\$' make test
+    
+To run the same test inside your Docker development container, you do this:
+
+		root@5f8630b873fe:/go/src/github.com/docker/docker# TESTFLAGS='-run ^TestBuild$' project/make.sh
+
+## If test under Boot2Docker fail do to space errors
+
+Running the tests requires about 2GB of memory. If you are running your container on bare metal, that is you are not running with Boot2Docker, your Docker development container is able to take the memory it requires directly from your local host.
+
+If you are running Docker using Boot2Docker, the VM uses 2048MB by default. This means you can exceed the memory of your VM running tests in a Boot2Docker environment. When the test suite runs out of memory, it returns errors similar to the following:
+
+    server.go:1302 Error: Insertion failed because database is full: database or
+    disk is full
+
+    utils_test.go:179: Error copy: exit status 1 (cp: writing
+    '/tmp/docker-testd5c9-[...]': No space left on device
+
+To increase the memory on your VM, you need to reinitialize the Boot2Docker VM with new memory settings.
+
+1. Stop all running containers.
+
+2. View the current memory setting.
+
+		$ boot2docker info
+		{
+			"Name": "boot2docker-vm",
+			"UUID": "491736fd-4075-4be7-a6f5-1d4cdcf2cc74",
+			"Iso": "/Users/mary/.boot2docker/boot2docker.iso",
+			"State": "running",
+			"CPUs": 8,
+			"Memory": 2048,
+			"VRAM": 8,
+			"CfgFile": "/Users/mary/VirtualBox VMs/boot2docker-vm/boot2docker-vm.vbox",
+			"BaseFolder": "/Users/mary/VirtualBox VMs/boot2docker-vm",
+			"OSType": "",
+			"Flag": 0,
+			"BootOrder": null,
+			"DockerPort": 0,
+			"SSHPort": 2022,
+			"SerialFile": "/Users/mary/.boot2docker/boot2docker-vm.sock"
+		}
+
+
+3. Delete your existing `boot2docker` profile.
+
+		$ boot2docker delete
+
+4. Reinitialize `boot2docker` and specify a higher memory.
+
+		$ boot2docker init -m 5555
+
+5. Verify the memory was reset.
+
+		$ boot2docker info
+
+6. Restart your container and try your test again.
+
+
+## Build and test the documentation
+
+The Docker documentation source files are under `docs/sources`. The content is
+written using extended Markdown. We use the static generator <a
+href="http://www.mkdocs.org/" target="_blank">MkDocs</a> to build Docker's
+documentation. Of course, you don't need to install this generator
+to build the documentation, it is included with container.
+
+You should always check your documentation for grammar and spelling. The best way to do this is with <a href="http://www.hemingwayapp.com/" target="_blank">an online grammar checker</a>.
+
+When you change a documentation source file, you should test your change locally to make sure your content is there and any links work correctly. You can build the documentation from the local host.  The build starts a container and loads the documentation into a server. As long as this container runs, you can browse the docs.
+
+1. In a terminal, change to the root of your `docker-fork` repository.
+
+		$ cd ~/repos/dry-run-test
+
+2. Make sure you are in your feature branch.
+
+		$ git status
+		On branch dry-run-test
+		Your branch is up-to-date with 'origin/dry-run-test'.
+		nothing to commit, working directory clean
+				
+3. Build the documentation.
+
+		$ make docs
+		
+	When the build completes, you'll see a final output message similar to the
+	following:
+	
+		Successfully built ee7fe7553123
+		docker run --rm -it  -e AWS_S3_BUCKET -e NOCACHE -p 8000:8000 "docker-docs:dry-run-test" mkdocs serve
+		Running at: http://0.0.0.0:8000/
+		Live reload enabled.
+		Hold ctrl+c to quit.
+		
+4. Enter the URL in your browser.
+
+	If you are running Boot2Docker, replace the default localhost address
+	(0.0.0.0) with your DOCKERHOST value. You can get this value at any time by
+	entering `boot2docker ip` at the command line.
+	
+5. Once in the documentation, look for the red notice to verify you are seeing the correct build.
+
+	![Beta documentation](/project/images/red_notice.png)
+
+6. Navigate to your new or changed document.
+
+7. Review both the content and the links.
+
+8. Return to your terminal and exit out of the running documentation container.
+
+
+## Where to go next
+
+Congratulations, you have successfully completed the basics you need to understand the Docker test framework. In the next steps, you use what you have learned so far to [contribute to Docker by working on an issue](/project/make-a-contribution/).
+
+
+
+
+
+

docs/sources/project/who-written-for.md

@@ -0,0 +1,37 @@
+page_title: README first
+page_description: Introduction to project contribution at Docker
+page_keywords: Gordon, introduction, turtle, machine, libcontainer, how to
+
+# README first 
+
+This section of the documentation contains a guide for Docker users who want to
+contribute code or documentation to the Docker project. As a community, we
+share rules of behavior and interaction. Make sure you are familiar with the <a href="https://github.com/docker/docker/blob/master/CONTRIBUTING.md#docker-community-guidelines" target="_blank">community guidelines</a> before continuing.
+
+## Where and what you can contribute
+
+The Docker project consists of not just one but several repositories on GitHub. So, in addition to the `docker/docker` repository, there is the `docker/libcontainer` repo, the `docker/machine` repo, and several more. Contribute to any of these and you contribute to the Docker project.
+
+Not all Docker repositories use the Go language. Also, each repository has its own focus area. So, if you are an experienced contributor, think about contributing to a Docker repository that has a language or a focus area you are familiar with. 
+
+If you are new to the open source community, to Docker, or to formal programming, you should start out contributing to the `docker/docker` repository. Why? Because this guide is written for that repository specifically. 
+
+Finally, code or documentation isn't the only way to contribute. You can report an issue, add to discussions in our community channel, write a blog post, or take a usability test. You can even propose your own type of contribution. Right now we don't have a lot written about this yet, so just email <mailto:feedback@docker.com> if this type of contributing interests you.
+
+## A turtle is involved
+
+![Gordon](/project/images/gordon.jpeg)
+
+Enough said.
+
+## How to use this guide
+
+This is written for the distracted, the overworked, the sloppy reader with fair `git` skills and a failing memory for the GitHub GUI. The guide attempts to explain how to use the Docker environment as precisely, predictably, and procedurally as possible.
+
+Users who are new to the Docker development environment should start by setting up their environment. Then, they should try a simple code change. After that, you should find something to work on or propose at totally new change.
+
+If you are a programming prodigy, you still may find this documentation useful. Please feel free to skim past information you find obvious or boring.
+
+## How to get started
+
+Start by [setting up the prerequisites for contributing](/project/set-up-prereqs/).