deleted file mode 100644

@@ -1,159 +0,0 @@

-<!--[metadata]>

-+++

-title = "Advanced contributing"

-description = "Explains workflows for refactor and design proposals"

-keywords = ["contribute, project, design, refactor,  proposal"]

-[menu.main]

-parent = "smn_contribute"

-weight=6

-+++

-<![end-metadata]-->

-

-# 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](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%

-    3Akind%2Fproposal" 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 change 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!

-

-## About the advanced process

-

-Docker is a large project. Our core team gets a great many design proposals.

-Design proposal discussions can span days, weeks, and longer. The number of comments can reach the 100s.

-In that situation, following the discussion flow and the decisions reached is crucial.

-

-Making a pull request with a design proposal simplifies this process:

-* you can leave comments on specific design proposal line

-* replies around line are easy to track

-* as a proposal changes and is updated, pages reset as line items resolve

-* GitHub maintains the entire history

-

-While proposals in pull requests do not end up merged into a master repository, they provide a convenient tool for managing the design process.

deleted file mode 100644

@@ -1,103 +0,0 @@

-<!--[metadata]>

-+++

-title = "Coding style checklist"

-description = "List of guidelines for coding Docker contributions"

-keywords = ["change, commit, squash, request, pull request, test, unit test, integration tests, Go, gofmt,  LGTM"]

-[menu.main]

-parent = "smn_contribute"

-weight=7

-+++

-<![end-metadata]-->

-

-# Coding style checklist

-

-This checklist summarizes the material you experienced working through [make a

-code contribution](make-a-contribution.md) and [advanced

-contributing](advanced-contributing.md). The checklist applies to both 

-program code and 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.

-

-* Run `golint` on each changed file before

-  committing your changes.

-

-* 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.org/) is

-  available almost immediately.

-

-* If you made a documentation change, you can see it at

-  [docs.master.dockerproject.org](http://docs.master.dockerproject.org/).

deleted file mode 100644

@@ -1,138 +0,0 @@

-<!--[metadata]>

-+++

-title = "Create a pull request (PR)"

-description = "Basic workflow for Docker contributions"

-keywords = ["contribute, pull request, review, workflow, beginner, squash,  commit"]

-[menu.main]

-parent = "smn_contribute"

-weight=4

-+++

-<![end-metadata]-->

-

-# Create a pull request (PR)

-

-A pull request (PR) sends your changes to the Docker maintainers for review. You

-create a pull request on GitHub. A pull request "pulls" changes from your forked

-repository into 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.

-

-## Check your work

-

-Before you create a pull request, check your work.

-

-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

-        Switched to branch '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. 

-    

-4. Optionally, if modified the documentation, build the documentation:

-

-		$ make docs

-

-5. Commit and push any changes that result from your checks.

-

-## Rebase your branch

-

-Always rebase and squash your commits before making a pull request. 

-

-1. Checkout your feature branch in your local `docker-fork` repository.

-

-    This is the branch associated with your request.

-

-2. Fetch any last minute changes from `docker/docker`.

-

-        $ git fetch upstream master

-        From github.com:docker/docker

-         * branch            master     -> FETCH_HEAD

-

-3. Start an interactive rebase.

-

-        $ git rebase -i upstream/master

-

-4. Rebase opens an editor with a list of commits.

-

-        pick 1a79f55 Tweak some of the other text for grammar

-        pick 53e4983 Fix a link

-        pick 3ce07bb Add a new line about RHEL

-

-5. 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 you save the changes and quit from the editor, git starts

-    the rebase, reporting the progress along the way. Sometimes

-    your changes can conflict with the work of others. If git

-    encounters a conflict, it stops the rebase, and prints guidance

-    for how to correct the conflict.

-

-6. Edit and save your commit message.

-

-        $ git commit -s

-

-    Make sure your message includes <a href="../set-up-git" target="_blank">your signature</a>.

-

-7. Force push any changes to your fork on GitHub.

-

-        $ git push -f origin 11038-fix-rhel-link

-        

-## Create a PR on GitHub

-

-You create and manage PRs on GitHub:

-

-1. Open your browser to your fork on GitHub.

-

-    You should see the latest activity from your branch.

-

-    ![Latest commits](images/latest_commits.png)

-

-

-2. Click "Compare & pull request."

-

-    The system displays the pull request dialog. 

-

-    ![PR dialog](images/to_from_pr.png)

-

-    The pull request compares your changes to the `master` branch on the

-    `docker/docker` repository.

-

-3. 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](images/fixes_num.png)

-

-4. 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](images/commits_expected.png)

-

-5. Press "Create pull request".

-

-    The system creates the request and opens it for you in the `docker/docker`

-    repository.

-

-    ![Pull request made](images/pull_request_made.png)

-

-

-## Where to go next

-

-Congratulations, you've created your first pull request to Docker. The next

-step is for you learn how to [participate in your PR's

-review](review-pr.md).

deleted file mode 100644

@@ -1,283 +0,0 @@

-<!--[metadata]>

-+++

-title = "Style guide for Docker documentation"

-description = "Style guide for Docker documentation describing standards and conventions for contributors"

-keywords = ["style, guide, docker,  documentation"]

-[menu.main]

-parent = "mn_opensource"

-weight=100

-+++

-<![end-metadata]-->

-

-# Docker documentation: style & grammar conventions

-

-## Style standards

-

-Over time, different publishing communities have written standards for the style

-and grammar they prefer in their publications. These standards are called

-[style guides](http://en.wikipedia.org/wiki/Style_guide). Generally, Docker’s

-documentation uses the standards described in the

-[Associated Press's (AP) style guide](http://en.wikipedia.org/wiki/AP_Stylebook). 

-If a question about syntactical, grammatical, or lexical practice comes up,

-refer to the AP guide first. If you don’t have a copy of (or online subscription

-to) the AP guide, you can almost always find an answer to a specific question by

-searching the web. If you can’t find an answer, please ask a

-[maintainer](https://github.com/docker/docker/blob/master/MAINTAINERS) and

-we will find the answer.

-

-That said, please don't get too hung up on using correct style. We'd rather have

-you submit good information that doesn't conform to the guide than no

-information at all. Docker's tech writers are always happy to help you with the

-prose, and we promise not to judge or use a red pen!

-

-> **Note:**

-> The documentation is written with paragraphs wrapped at 80 column lines to

-> make it easier for terminal use. You can probably set up your favorite text

-> editor to do this automatically for you.

-

-### Prose style

-

-In general, try to write simple, declarative prose. We prefer short,

-single-clause sentences and brief three-to-five sentence paragraphs. Try to

-choose vocabulary that is straightforward and precise. Avoid creating new terms,

-using obscure terms or, in particular, using a lot of jargon. For example, use

-"use" instead of leveraging "leverage".

-

-That said, don’t feel like you have to write for localization or for

-English-as-a-second-language (ESL) speakers specifically. Assume you are writing

-for an ordinary speaker of English with a basic university education. If your

-prose is simple, clear, and straightforward it will translate readily.

-

-One way to think about this is to assume Docker’s users are generally university

-educated and read at at least a "16th" grade level (meaning they have a

-university degree). You can use a [readability

-tester](https://readability-score.com/) to help guide your judgement. For

-example, the readability score for the phrase "Containers should be ephemeral"

-is around the 13th grade level (first year at university), and so is acceptable.

-

-In all cases, we prefer clear, concise communication over stilted, formal

-language. Don't feel like you have to write documentation that "sounds like

-technical writing."

-

-### Metaphor and figurative language

-

-One exception to the "don’t write directly for ESL" rule is to avoid the use of

-metaphor or other

-[figurative language](http://en.wikipedia.org/wiki/Literal_and_figurative_language) to

-describe things. There are too many cultural and social issues that can prevent

-a reader from correctly interpreting a metaphor.

-

-## Specific conventions

-

-Below are some specific recommendations (and a few deviations) from AP style

-that we use in our docs.

-

-### Contractions

-

-As long as your prose does not become too slangy or informal, it's perfectly

-acceptable to use contractions in our documentation. Make sure to use

-apostrophes correctly.

-

-### Use of dashes in a sentence.

-

-Dashes refers to the en dash (–) and the em dash (—). Dashes can be used to

-separate parenthetical material.

-

-Usage Example: This is an example of a Docker client – which uses the Big Widget

-to run – and does x, y, and z.

-

-Use dashes cautiously and consider whether commas or parentheses would work just

-as well. We always emphasize short, succinct sentences.

-

-More info from the always handy [Grammar Girl site](http://www.quickanddirtytips.com/education/grammar/dashes-parentheses-and-commas).

-

-### Pronouns

-

-It's okay to use first and second person pronouns, especially if it lets you avoid a passive construction. Specifically, always use "we" to

-refer to Docker and "you" to refer to the user. For example, "We built the

-`exec` command so you can resize a TTY session." That said, in general, try to write simple, imperative sentences that avoid the use of pronouns altogether. Say "Now, enter your SSH key" rather than "You can now enter your SSH key."

-

-As much as possible, avoid using gendered pronouns ("he" and "she", etc.).

-Either recast the sentence so the pronoun is not needed or, less preferably,

-use "they" instead. If you absolutely can't get around using a gendered pronoun,

-pick one and stick to it. Which one you choose is up to you. One common

-convention is to use the pronoun of the author's gender, but if you prefer to

-default to "he" or "she", that's fine too.

-

-### Capitalization 

-

-#### In general

-

-Only proper nouns should be capitalized in body text. In general, strive to be

-as strict as possible in applying this rule. Avoid using capitals for emphasis

-or to denote "specialness".

-

-The word "Docker" should always be capitalized when referring to either the

-company or the technology. The only exception is when the term appears in a code

-sample.

-

-#### Starting sentences

-

-Because code samples should always be written exactly as they would appear

-on-screen, you should avoid starting sentences with a code sample.

-

-#### In headings

-

-Headings take sentence capitalization, meaning that only the first letter is

-capitalized (and words that would normally be capitalized in a sentence, e.g.,

-"Docker"). Do not use Title Case (i.e., capitalizing every word) for headings. Generally, we adhere to [AP style

-for titles](http://www.quickanddirtytips.com/education/grammar/capitalizing-titles).

-

-### Periods

-

-We prefer one space after a period at the end of a sentence, not two. 

-

-See [lists](#lists) below for how to punctuate list items.

-

-### Abbreviations and acronyms

-

-* Exempli gratia (e.g.) and id est ( i.e.): these should always have periods and

-are always followed by a comma.

-

-* Acronyms are pluralized by simply adding "s", e.g., PCs, OSs.

-

-* On first use on a given page, the complete term should be used, with the

-abbreviation or acronym in parentheses. E.g., Red Hat Enterprise Linux (RHEL).

-The exception is common, non-technical acronyms like AKA or ASAP. Note that

-acronyms other than i.e. and e.g. are capitalized.

-

-* Other than "e.g." and "i.e." (as discussed above), acronyms do not take

-periods, PC not P.C.

-

-

-### Lists

-

-When writing lists, keep the following in mind:

-

-Use bullets when the items being listed are independent of each other and the

-order of presentation is not important.

-

-Use numbers for steps that have to happen in order or if you have mentioned the

-list in introductory text. For example, if you wrote "There are three config

-settings available for SSL, as follows:", you would number each config setting

-in the subsequent list.

-

-In all lists, if an item is a complete sentence, it should end with a

-period. Otherwise, we prefer no terminal punctuation for list items.

-Each item in a list should start with a capital.

-

-### Numbers

-

-Write out numbers in body text and titles from one to ten. From 11 on, use numerals.

-

-### Notes

-

-Use notes sparingly and only to bring things to the reader's attention that are

-critical or otherwise deserving of being called out from the body text. Please

-format all notes as follows:

-

-    > **Note:**

-    > One line of note text

-    > another line of note text

-

-### Avoid excess use of "i.e."

-

-Minimize your use of "i.e.". It can add an unnecessary interpretive burden on

-the reader. Avoid writing "This is a thing, i.e., it is like this". Just

-say what it is: "This thing is …"

-

-### Preferred usages

-

-#### Login vs. log in. 

-

-A "login" is a noun (one word), as in "Enter your login". "Log in" is a compound

-verb (two words), as in "Log in to the terminal".

-

-### Oxford comma

-

-One way in which we differ from AP style is that Docker’s docs use the [Oxford

-comma](http://en.wikipedia.org/wiki/Serial_comma) in all cases. That’s our

-position on this controversial topic, we won't change our mind, and that’s that!

-

-### Code and UI text styling

-

-We require `code font` styling (monospace, sans-serif) for all text that refers

-to a command or other input or output from the CLI. This includes file paths

-(e.g., `/etc/hosts/docker.conf`). If you enclose text in backticks (`) markdown

-will style the text as code. 

-

-Text from a CLI should be quoted verbatim, even if it contains errors or its

-style contradicts this guide. You can add "(sic)" after the quote to indicate

-the errors are in the quote and are not errors in our docs.

-

-Text taken from a GUI (e.g., menu text or button text) should appear in "double

-quotes". The text should take the exact same capitalisation, etc. as appears in

-the GUI. E.g., Click "Continue" to save the settings.

-

-Text that refers to a keyboard command or hotkey is capitalized (e.g., Ctrl-D).

-

-When writing CLI examples, give the user hints by making the examples resemble

-exactly what they see in their shell: 

-

-* Indent shell examples by 4 spaces so they get rendered as code blocks.

-* Start typed commands with `$ ` (dollar space), so that they are easily

-  differentiated from program output.

-* Program output has no prefix.

-* Comments begin with # (hash space).

-* In-container shell commands, begin with `$$ ` (dollar dollar space).

-

-Please test all code samples to ensure that they are correct and functional so

-that users can successfully cut-and-paste samples directly into the CLI.

-

-## Pull requests

-

-The pull request (PR) process is in place so that we can ensure changes made to

-the docs are the best changes possible. A good PR will do some or all of the

-following:

-

-* Explain why the change is needed

-* Point out potential issues or questions

-* Ask for help from experts in the company or the community

-* Encourage feedback from core developers and others involved in creating the

-  software being documented.

-

-Writing a PR that is singular in focus and has clear objectives will encourage

-all of the above. Done correctly, the process allows reviewers (maintainers and

-community members) to validate the claims of the documentation and identify

-potential problems in communication or presentation. 

-

-### Commit messages

-

-In order to write clear, useful commit messages, please follow these

-[recommendations](http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message).

-

-## Links

-

-For accessibility and usability reasons, avoid using phrases such as "click

-here" for link text. Recast your sentence so that the link text describes the

-content of the link, as we did in the

-["Commit messages" section](#commit-messages) above.

-

-You can use relative links (../linkeditem) to link to other pages in Docker's

-documentation.

-

-## Graphics

-

-When you need to add a graphic, try to make the file-size as small as possible.

-If you need help reducing file-size of a high-resolution image, feel free to

-contact us for help.

-Usually, graphics should go in the same directory as the .md file that

-references them, or in a subdirectory for images if one already exists.

-

-The preferred file format for graphics is PNG, but GIF and JPG are also

-acceptable. 

-

-If you are referring to a specific part of the UI in an image, use

-call-outs (circles and arrows or lines) to highlight what you’re referring to.

-Line width for call-outs should not exceed five pixels. The preferred color for

-call-outs is red.

-

-Be sure to include descriptive alt-text for the graphic. This greatly helps

-users with accessibility issues.

-

-Lastly, be sure you have permission to use any included graphics.

\ No newline at end of file

deleted file mode 100644

@@ -1,237 +0,0 @@

-<!--[metadata]>

-+++

-title = "Find and claim an issue"

-description = "Basic workflow for Docker contributions"

-keywords = ["contribute, issue, review, workflow, beginner, expert, squash, commit"]

-[menu.main]

-parent = "smn_contribute"

-weight=2

-+++

-<![end-metadata]-->

-

-<style type="text/css">

-

-.gh-label {

-    display: inline-block;

-    padding: 3px 4px;

-    font-size: 12px;

-    font-weight: bold;

-    line-height: 1;

-    color: #fff;

-    border-radius: 2px;

-    box-shadow: inset 0 -1px 0 rgba(0,0,0,0.12);

-}

-.gh-label.beginner { background-color: #B5E0B5; color: #333333; }

-.gh-label.expert { background-color: #599898; color: #ffffff; }

-.gh-label.master { background-color: #306481; color: #ffffff; }

-.gh-label.novice { background-color: #D6F2AC; color: #333333; }

-.gh-label.proficient { background-color: #8DC7A9; color: #333333; }

-.gh-label.bug { background-color: #FF9DA4; color: #333333; }

-.gh-label.cleanup { background-color: #FFB7B3; color: #333333; }

-.gh-label.content { background-color: #CDD3C2; color: #333333; }

-.gh-label.feature { background-color: #B7BEB7; color: #333333; }

-.gh-label.graphics { background-color: #E1EFCB; color: #333333; }

-.gh-label.improvement { background-color: #EBD2BB; color: #333333; }

-.gh-label.proposal { background-color: #FFD9C0; color: #333333; }

-.gh-label.question { background-color: #EEF1D1; color: #333333; }

-.gh-label.usecase { background-color: #F0E4C2; color: #333333; }

-.gh-label.writing { background-color: #B5E9D5; color: #333333; }

-

-</style>

-

-

-# Find and claim an issue

-

-On this page, you choose the issue you want to work on. As a contributor, you can work

-on whatever you want. If you are new to contributing, you should start by

-working with our known issues.

-

-## Understand the issue types

-

-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 one of these labels:

-

-<table class="tg">

-  <thead>

-    <tr>

-      <td class="tg-031e">Label</td>

-      <td class="tg-031e">Experience level guideline</td>

-    </tr>

-  </thead>

-  <tbody>

-    <tr>

-      <td class="tg-031e"><strong class="gh-label beginner">exp/beginner</strong></td>

-      <td class="tg-031e">You have made less than ten contributions in your life time to any open source project.</td>

-    </tr>

-    <tr>

-      <td class="tg-031e"><strong class="gh-label novice">exp/novice</strong></td>

-      <td class="tg-031e">You have made more than ten contributions to an open source project or at least 5 contributions to Docker.  </td>

-    </tr>

-    <tr>

-      <td class="tg-031e"><strong class="gh-label proficient">exp/proficient</strong></td>

-      <td class="tg-031e">You have made more than five contributions to Docker which amount to at least 200 code lines or 1000 documentation lines. </td>

-    </tr>

-    <tr>

-      <td class="tg-031e"><strong class="gh-label expert">exp/expert</strong></td>

-      <td class="tg-031e">You have made less than 20 commits to Docker which amount to 500-1000 code lines or 1000-3000 documentation lines. </td>

-    </tr>

-    <tr>

-      <td class="tg-031e"><strong class="gh-label master">exp/master</strong></td>

-      <td class="tg-031e">You have made more than 20 commits to Docker and greater than 1000 code lines or 3000 documentation lines.</td>

-    </tr>

-  </tbody>

-</table>

-

-These labels are guidelines. You might have written a whole plugin for Docker in a personal 

-project and never contributed to Docker. With that kind of experience, you could take on an <strong

-class="gh-label expert">exp/expert</strong> or <strong class="gh-label

-master">exp/master</strong> level issue.

-

-## Claim a beginner or novice issue

-

-To claim an issue:

-

-1. Go to the `docker/docker` <a

-	href="https://github.com/docker/docker" target="_blank">repository</a>.

-

-2. Click the "Issues" link.

-

-    A list of the open issues appears. 

-

-    ![Open issues](images/issue_list.png)

-

-3. From the "Labels" drop-down, select <strong class="gh-label beginner">exp/beginner</strong>.

-

-    The system filters to show only open <strong class="gh-label beginner">exp/beginner</strong> issues.

-

-4. Open an issue that interests you.

-

-    The comments on the issues describe the problem and can provide information for a potential 

-    solution.

-

-5. When you find an open issue that both interests you and is unclaimed, add a

-`#dibs` comment. Make sure that no other user has chosen to work on the issue.

-

-    The project does not permit external contributors to assign issues to themselves. Read 

-    the comments to find if a user claimed the issue by leaving a

-    `#dibs` comment on the issue.

-

-7. Your issue # will be different depending on what you claimed. After a moment, Gordon the Docker 

-bot, changes the issue status to claimed. The following example shows issue #11038.

-

-    ![Easy issue](images/easy_issue.png)

-

-8. Make a note of the issue number; you will need it for 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 (push)

-

-    If the `upstream` is missing, add it.