Initial push

Signed-off-by: Mary Anthony <mary@docker.com>
This commit is contained in:
Mary Anthony
2015-06-08 14:55:46 -07:00
commit f70588593c
15 changed files with 838 additions and 0 deletions

9
docs/Dockerfile Normal file
View File

@@ -0,0 +1,9 @@
FROM docs-base:hugo-feature-work
MAINTAINER Mary Anthony <mary@docker.com> (@moxiegirl)
# to get the git info for this repo
COPY . /src
COPY . /docs/content/opensource/
RUN find /docs/content/opensource -type f -name "*.md" -exec sed -i.old -e '/^<!.*metadata]>/g' -e '/^<!.*end-metadata.*>/g' {} \;

55
docs/Makefile Normal file
View File

@@ -0,0 +1,55 @@
.PHONY: all binary build cross default docs docs-build docs-shell shell test test-unit test-integration test-integration-cli test-docker-py validate
# env vars passed through directly to Docker's build scripts
# to allow things like `make DOCKER_CLIENTONLY=1 binary` easily
# `docs/sources/contributing/devenvironment.md ` and `project/PACKAGERS.md` have some limited documentation of some of these
DOCKER_ENVS := \
-e BUILDFLAGS \
-e DOCKER_CLIENTONLY \
-e DOCKER_EXECDRIVER \
-e DOCKER_GRAPHDRIVER \
-e TESTDIRS \
-e TESTFLAGS \
-e TIMEOUT
# note: we _cannot_ add "-e DOCKER_BUILDTAGS" here because even if it's unset in the shell, that would shadow the "ENV DOCKER_BUILDTAGS" set in our Dockerfile, which is very important for our official builds
# to allow `make DOCSDIR=docs docs-shell` (to create a bind mount in docs)
DOCS_MOUNT := $(if $(DOCSDIR),-v $(CURDIR)/$(DOCSDIR):/$(DOCSDIR))
# to allow `make DOCSPORT=9000 docs`
DOCSPORT := 8000
# Get the IP ADDRESS
DOCKER_IP=$(shell python -c "import urlparse ; print urlparse.urlparse('$(DOCKER_HOST)').hostname or ''")
HUGO_BASE_URL=$(shell test -z "$(DOCKER_IP)" && echo localhost || echo "$(DOCKER_IP)")
HUGO_BIND_IP=0.0.0.0
GIT_BRANCH := $(shell git rev-parse --abbrev-ref HEAD 2>/dev/null)
DOCKER_IMAGE := docker$(if $(GIT_BRANCH),:$(GIT_BRANCH))
DOCKER_DOCS_IMAGE := docs-base$(if $(GIT_BRANCH),:$(GIT_BRANCH))
DOCKER_RUN_DOCS := docker run --rm -it $(DOCS_MOUNT) -e AWS_S3_BUCKET -e NOCACHE
# for some docs workarounds (see below in "docs-build" target)
GITCOMMIT := $(shell git rev-parse --short HEAD 2>/dev/null)
default: docs
docs: docs-build
$(DOCKER_RUN_DOCS) -p $(if $(DOCSPORT),$(DOCSPORT):)8000 -e DOCKERHOST "$(DOCKER_DOCS_IMAGE)" hugo server --port=$(DOCSPORT) --baseUrl=$(HUGO_BASE_URL) --bind=$(HUGO_BIND_IP)
docs-draft: docs-build
$(DOCKER_RUN_DOCS) -p $(if $(DOCSPORT),$(DOCSPORT):)8000 -e DOCKERHOST "$(DOCKER_DOCS_IMAGE)" hugo server --buildDrafts="true" --port=$(DOCSPORT) --baseUrl=$(HUGO_BASE_URL) --bind=$(HUGO_BIND_IP)
docs-shell: docs-build
$(DOCKER_RUN_DOCS) -p $(if $(DOCSPORT),$(DOCSPORT):)8000 "$(DOCKER_DOCS_IMAGE)" bash
docs-build:
# ( git remote | grep -v upstream ) || git diff --name-status upstream/release..upstream/docs ./ > ./changed-files
# echo "$(GIT_BRANCH)" > GIT_BRANCH
# echo "$(AWS_S3_BUCKET)" > AWS_S3_BUCKET
# echo "$(GITCOMMIT)" > GITCOMMIT
docker build -t "$(DOCKER_DOCS_IMAGE)" .

230
docs/code.md Normal file
View File

@@ -0,0 +1,230 @@
<!--[metadata]>
+++
title = "Contribute code"
description = "Contribute code"
keywords = ["governance, board, members, profiles"]
[menu.main]
parent="mn_opensource"
weight=4
+++
<![end-metadata]-->
# Contribute code
If you'd like to improve the code of any of Docker's projects, we would love to
have your contributions. All of our projects' code repositories are on GitHub:
<table class="tg" >
<col width="20%">
<col width="80%">
<tr>
<td class="tg-031e"><a href="https://github.com/docker/docker" target="_blank">docker/docker</a></td>
<td class="tg-031e">Docker the open-source application container engine</td>
</tr>
<tr>
<td class="tg-031e"><a href="https://github.com/docker/machine" target="_blank">docker/machine</a></td>
<td class="tg-031e">Software for the easy and quick creation of Docker hosts on your computer, on cloud providers, and inside your own data center.</td>
</tr>
<tr>
<td class="tg-031e"><a href="https://github.com/kitematic/kitematic" target="_blank">kitematic/kitematic</a></td>
<td class="tg-031e">Kitematic is a simple application for managing Docker containers on Mac OS X.</td>
</tr>
</td>
</tr>
<tr>
<td class="tg-031e"><a href="https://github.com/docker/swarm" target="_blank">docker/swarm</a></td>
<td class="tg-031e">Native clustering for Docker; manage several Docker hosts as a single, virtual host.</td>
</tr>
<tr>
<td class="tg-031e"><a href="https://github.com/docker/compose" target="_blank">docker/compose</a></td>
<td class="tg-031e">Define and run complex applications using one or many interlinked containers.</td>
</tr>
</table>
See <a href="https://github.com/docker" target="_blank">the complete list of
Docker repositories</a> on GitHub.
If you want to contribute to the `docker/docker` repository you should be
familiar with or a invested in learning Go or the Markdown language. If you
know other languages, investigate our
other repositories&mdash;not all of them run on Go.
# Code contribution workflow
Below is the general workflow for contributing Docker code or documentation.
If you are an experienced open source contributor you may be familiar with this
workflow. If you are new or just need reminders, the steps below link to more
detailed documentation in Docker's project contributors guide.
1. <a href="http://docs.docker.com/project/software-required/"
target="_blank">Get the software</a> you need.
This explains how to install a couple of tools used in our development
environment. What you need (or don't need) might surprise you.
2. <a href="http://docs.docker.com/project/set-up-git/"
target="_blank">Configure Git and fork the repo</a>.
Your Git configuration can make it easier for you to contribute.
Configuration is especially key if are new to contributing or to Docker.
3. <a href="http://docs.docker.com/project/set-up-dev-env/"
target="_blank">Learn to work with the Docker development container</a>.
Docker developers run `docker` in `docker`. If you are a geek,
this is a pretty cool experience.
4. <a href="http://docs.docker.com/project/find-an-issue/"
target="_blank">Claim an issue</a> to work on.
We created a filter listing <a href="http://goo.gl/Hsp2mk" target="_blank">all open
and unclaimed issues</a> for Docker.
5. <a
href="http://docs.docker.com/project/work-issue/" target="_blank">Work on the
issue</a>.
If you change or add code or docs to a project, you should test your changes
as you work. This page explains <a
href="http://docs.docker.com/project/test-and-docs/" target="_blank">how to
test in our development environment</a>.
Also, remember to always **sign your commits** as you work! To sign your
commits, include the `-s` flag in your commit like this:
$ git commit -s -m "Add commit with signature example"
If you don't sign <a href="https://twitter.com/gordontheturtle"
target="_blank">Gordon</a> will get you!
6. <a href="http://docs.docker.com/project/create-pr/" target="_blank">Create a
pull request</a>.
If you make a change to fix an issue, add reference to the issue in the pull
request. Here is an example of a perfect pull request with a good description,
issue reference, and signature in the commit:
![Sign commits and issues](/images/bonus.png)
We have also have checklist that describes [what each pull request
needs](#what-is-the-pre-pull-request-checklist).
7. <a href="http://docs.docker.com/project/review-pr/"
target="_blank">Participate in the pull request review</a> till a successful
merge.
## FAQ and troubleshooting tips for coders
This section contains some frequently asked questions and tips for
troubleshooting problems in your code contribution.
- [How do I set my signature?](#how-do-i-set-my-signature:cb7f612e17aad7eb26c06709ef92a867)
- [How do I track changes from the docker repo upstream?](#how-do-i-track-changes-from-the-docker-repo-upstream:cb7f612e17aad7eb26c06709ef92a867)
- [How do I format my Go code?](#how-do-i-format-my-go-code:cb7f612e17aad7eb26c06709ef92a867)
- [What is the pre-pull request checklist?](#what-is-the-pre-pull-request-checklist:cb7f612e17aad7eb26c06709ef92a867)
- [How should I comment my code?](#how-should-i-comment-my-code:cb7f612e17aad7eb26c06709ef92a867)
- [How do I rebase my feature branch?](#how-do-i-rebase-my-feature-branch:cb7f612e17aad7eb26c06709ef92a867)
### How do I set my signature {#how-do-i-set-my-signature}
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"
### How do I track changes from the docker repo upstream
Set your local repo to track changes upstream, on the `docker` repository.
1. Change to the root of your Docker repository.
$ cd docker-fork
2. Add a remote called `upstream` that points to `docker/docker`
$ git remote add upstream https://github.com/docker/docker.git
### How do I format my Go code
Run `gofmt -s -w filename.go` on each changed file before committing your changes.
Most editors have plug-ins that do the formatting automatically.
### What is the pre-pull request checklist
* Sync and cleanly rebase on top of Docker's `master`; do not mix multiple branches
in the pull request.
* Squash your commits into logical units of work using
`git rebase -i` and `git push -f`.
* If your code requires a change to tests or documentation, include code,test,
and documentation changes in the same commit as your code; this ensures a
revert would remove all traces of the feature or fix.
* Reference each issue in your pull request description (`#XXXX`).
### How should I comment my code?
The Go blog wrote about code comments, it is <a href="http://goo.gl/fXCRu"
target="_blank">a single page explanation</a>. A summary follows:
- Comments begin with two forward `//` slashes.
- To document a type, variable, constant, function, or even a package, write a
regular comment directly preceding the elements declaration, with no intervening blank
line.
- Comments on package declarations should provide general package documentation.
- For packages that need large amounts of introductory documentation: the
package comment is placed in its own file.
- Subsequent lines of text are considered part of the same paragraph; you must
leave a blank line to separate paragraphs.
- Indent pre-formatted text relative to the surrounding comment text (see gob's doc.go for an example).
- URLs are converted to HTML links; no special markup is necessary.
### How do I rebase my feature branch?
Always rebase and squash your commits before making a pull request.
1. Fetch any of the last minute changes from `docker/docker`.
$ git fetch upstream master
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 images
pick 3ce07bb Add a new line
If you run into trouble, `git --rebase abort` removes any changes and gets you
back to where you started.
4. Squash the `pick` keyword with `squash` on all but the first commit.
pick 1a79f55 Tweak some of images
squash 3ce07bb Add a new line
After closing the file, `git` opens your editor again to edit the commit
message.
5. Edit and save your commit message.
$ git commit -s
Make sure your message includes your signature.
8. Push any changes to your fork on GitHub.
$ git push origin my-keen-feature

63
docs/community.md Normal file
View File

@@ -0,0 +1,63 @@
<!--[metadata]>
+++
title = "Support the community"
description = "Support the community"
keywords = ["support, community, users, irc"]
[menu.main]
parent="mn_opensource"
weight=1
+++
<![end-metadata]-->
# Support the community
With millions of Docker users all over the world, there's always someone who
needs a helping hand. Like many open source projects, the Docker project relies
on community support channels like forums, IRC, and StackOverflow. You should
contribute mentoring if you have good knowledge of:
* how open source projects run
* using Docker in some particular domain (for example, testing or deployment)
* using Git, Go, GitHub, IRC, or other common tools
Also, choose mentoring if you like to be happy. Studies show that <a
href="http://goo.gl/HSz8UT" target="_blank">helping others</a> is a great way to
boost your own well being.
# Where to help
If you are reading this at a Docker birthday event, look around you. Is there
someone who looks puzzled or frustrated? Smile at this person and say *"Hey, can
I help you with something?"* The next few sections list some other places to help.
## Docker users
Docker users are people using Docker in their daily work. For example, a user
might be deploying a Postgres database in a container. To help Docker users, visit:
* the <a href="https://groups.google.com/forum/#!forum/docker-user"
target="_blank">Docker-user</a> Google group
* the `#docker` channel on Freenode IRC
* <a href="http://stackoverflow.com/search?tab=newest&q=docker"
target="_blank">StackOverflow</a>
You can also check the <a href="http://goo.gl/Kv8EdU" target="_blank">list of
open user questions</a> on the Docker project.
## Docker contributors
Docker contributors are people like you contributing to Docker open source.
Contributors may need help with IRC, Go programming, Markdown, or with other
aspects of contributing. To help Docker contributors:
* the <a href="https://gitter.im/docker/docker" target="_blank">Docker Gitter IM
</a> room
* the <a href="https://groups.google.com/forum/#!forum/docker-dev"
target="_blank">docker-dev</a> Google group
* the <a href="https://dev.dockerproject.com"
target="_blank">dev.dockerproject.com</a> on Discourse
* the `#docker-dev` channel on Freenode IRC

View File

@@ -0,0 +1,14 @@
<!--[metadata]>
+++
title = "Board member profiles"
description = "Board member profiles"
keywords = ["governance, board, members, profiles"]
[menu.main]
parent="smn_governance"
weight=1
+++
<![end-metadata]-->
# Board member profiles
TBD

View File

@@ -0,0 +1,14 @@
<!--[metadata]>
+++
title = "Code of conduct"
description = "Explains Docker's code of conduct"
keywords = ["Docker, conduct, code"]
[menu.main]
parent="smn_governance"
weight=2
+++
<![end-metadata]-->
# Code of conduct
TBD

View File

@@ -0,0 +1,114 @@
<!--[metadata]>
+++
title = "Docker Governance Advisory Board"
description = "Docker Governance Advisory Board"
keywords = ["governance, board, members, explained"]
[menu.main]
parent="smn_governance"
+++
<![end-metadata]-->
# Docker Governance Advisory Board: June 2014 Version
An initial version of this proposal was posted for comments on April 30th, 2014. This version reflects all comments received prior to announcing the initial members/nominees for the board on June 10th. A subsequent version will be released following the first meeting of the board.
## 1.0 Background
The Docker project is experiencing incredible momentum in project growth, adoption, and contribution. As of June 9, 2014, there are over 460 contributors, 95% of whom do not work for the projects commercial sponsor. Large numbers of projects are being built on top of or incorporating Docker (over 7,000 projects with “Docker” in the title on GitHub), and there is a large and growing community of users. The project was designed from the outset to have a very open structure, including open design, open contribution, and consistent use of tools across the project. Maintainers include both Docker, Inc. and non-Docker Inc. employees. Given the large numbers of contributors, users, and companies with a stake in the future of the project, the project leadership is looking to supplement the current governance and contribution mechanisms with an advisory board, as part of its long term commitment to open governance.
## 2.0 Purpose
The primary purpose of the Docker Governance Advisory Board (DGAB) is to advise the Docker project leadership (Leadership) on matters related to supporting the long term governance, structure, and roadmap of the Docker project. The following main areas are included in this charter:
* Provide a forum for individuals, users, and companies to discuss the issues under the DGAB purview (SCOPE)
* Provide guidance and input to Leadership, and where possible, present a consistent and consolidated opinion from the broader Docker community
* Produce a formal, twice yearly report to the Leadership and broader Docker community of the status of and progress made in all areas under the purview of the DGAB.
* Promote and support the use of Docker in manner consistent with Guiding *
### Principles of the project and the Core Criteria
The DGAB is not:
Intended to serve as a governance board. The DGAB advises, but does not manage, the Docker project leadership
Intended to replace existing mechanisms for community input, governance, or contribution
Intended to assume a formal, fiduciary role with respect to the project. The DGAB membership will not be asked to provide funds to the project, assume liabilities with respect to the project or their activities, or assume responsibility for enforcing either trademarks or DGAB recommendations
## 3.0 Scope
The DGAB is expected to provide input and formal recommendations regarding the following areas:
Docker project long term roadmap
Docker project policies and procedures around maintenance and contributions
Docker project policies and procedures around intellectual property, trademark, and licensing
Core Criteria for Docker-related project (c.f. section 7.0)
Docker project long term governance model
4.0 Meetings and Memberships
4.1 General
The DGAB will have 15 members
The Docker Chief Maintainer and architect: Solomon Hykes
2 seats for the top core maintainers
Up to 12 additional seats: 4 corporate seats, 4 individual or small business seats, 4 “user” seats
No fee or sponsorship is required for membership
The membership term will last 12 months. With the exception of the Chief Maintainer, all members can serve a maximum of two consecutive terms
The selection process is intended to be open, transparent, and guided by objective criteria for membership.
The DGAB shall elect a Chair and Vice Chair from amongst their members to serve a renewable 6 month term.
The Chair or Vice-Chair shall prepare an agenda for and preside over regular meetings of the DGAB. These meetings shall occur as frequently as the DGAB determines is in the projects best interest, but no less than quarterly
Docker, inc. shall appoint a temporary chair to set the agenda for the first meeting and preside until the election shall occur.
A member of the DGAB may be removed by a resolution of the DGAB supported by more than two thirds of its membership.
The DGAB may fill any vacancy arising by removal or resignation by a simple majority vote to fill the remainder of the term of the vacating member.
The rules of election and membership outlined in this section may be varied by a resolution of the DGAB supported by more than two thirds of its voting membership.
All project maintainers are welcome as participants and observers at DGAB meetings
## 4.2 Selection Process
Contributors: Four seats will be granted to the top contributors, as measured by non-trivial pull requests merged to master in the last 6 months. Trivial pull requests are typos, minor document corrections, or other items that do not require a DCO. These seats will be reserved for individual contributors who are neither employees of Docker, Inc. nor employees of companies that hold a corporate seat.
Corporate seats: Nomination is restricted to companies for whom all three of the following are true
Are in the top 8 companies in terms of non-trivial pull requests merged to master in the past six months as measured by contributions by all employees
Have employees as maintainers and/or make significant contributions to the code base
Have committed to integrate Docker into widely used products in a manner consistent with Core Criteria. (c.f. section 7.0)
Once nomination has been closed, selection of corporate seats will be made by a vote by eligible contributors. Eligible contributors are those who have had at least one non-trivial pull request merged to master in the past six months.
User seats: These seats are for organizations that are using Docker. To be nominated, an organization must be using Docker in production and have published a use case. Once nomination has been closed, selection will be made by a vote by eligible contributors. Eligible contributors are those who have had at least one non-trivial pull request merged to master in the past six months.
## 5.0 Operation
The DGAB is authorized to seek advice and counsel from other interested parties and invited experts as appropriate
Any outside party wishing to bring an issue before the DGAB may do so by emailing the DGAB mailing list
The DGAB shall provide transparent and timely reporting (through any mechanism it deems appropriate) to the Community at large on all of its activities, subject to the right of any individual to designate their comments and the ensuing discussion as "in confidence," in which case the public report shall contain only a note of the request and an agreed summary (if any) of the substance.
The DGAB is being formed at the discretion of the Leadership. The Leadership alone may decide to terminate the DGAB in its sole discretion; provided however, that the Leadership shall first consult the DGAB Chair.
The DGAB and its members shall abide by appropriate antitrust guidelines.
## 6.0 Open Governance Principles
The DGAB will formulate recommendations in conjunction with the following, open governance principles
Open participation: throughout the project,
anyone should be able to participate and contribute. All bugs and tasks will be tracked in a public tracker and all of the source code and all of the tools needed to build it will be available under an open license permitting unrestricted use
Open technical meritocracy: technical merit over pride of authorship. Code is contributed for the express purpose of advancing technologies relevant to the project, effectively separating technology advancement from individual or commercial intent.
Open design: Roadmaps are discussed in the open, and design receives input from all contributors and maintainers
Influence through contribution: organizations and individuals gain influence over the project through contribution
IP Cleanliness: Steps are taken to ensure that all incoming code is legally contributed (DCOs terms-of-use etc.), that use of approved third party libraries does not create incompatible dependencies, and that all non-trivial commits have DCOs
Open Licensing: code should be licensed using approved, standard, open-source licenses. (Docker is currently licensed under Apache 2.0)
## 7.0 Core Criteria
The DGAB will formulate a set of Core Criteria for projects and commercial products that use the Docker trademarks
Core Criteria will generally cover such areas as: use of standard APIs, consistent behaviors expected of Docker containers, trademark guidelines, provenance, upstream contribution models, and alternative distributions
As Core Criteria will not be fully defined when the initial DGAB membership is formulated, it is understood that there is a possibility that certain members of the initial DGAB may not agree with the Core Criteria when they are fully defined or may have products/offerings that are not in compliance with the Core
Criteria at the time they are finalized. In this case, the corporate members will either agree to become compliant within a specified timeframe or else resign their DGAB position.
Please help us improve this draft by sending your comments and feedback to governance@docker.com)\.

14
docs/governance/faq.md Normal file
View File

@@ -0,0 +1,14 @@
<!--[metadata]>
+++
title = "Frequently asked questions"
description = "Frequently asked questions"
keywords = ["governance, board, members, FAQ"]
[menu.main]
parent="smn_governance"
weight=5
+++
<![end-metadata]-->
# Frequently asked questions (FAQ)
TBD

View File

@@ -0,0 +1,14 @@
<!--[metadata]>
+++
title = "How to join the Docker community"
description = "How to join the Docker community"
keywords = ["governance, board, members, join"]
[menu.main]
parent="smn_governance"
weight=4
+++
<![end-metadata]-->
# How to join the Docker community
TBD

Binary file not shown.

After

Width:  |  Height:  |  Size: 113 KiB

View File

@@ -0,0 +1,14 @@
<!--[metadata]>
+++
title = "Members of the DGAB"
description = "Members of the DGAB"
keywords = ["governance, members, dgab"]
[menu.main]
parent="smn_governance"
weight=3
+++
<![end-metadata]-->
# Members of the DGAB
TBD

74
docs/how-to-contribute.md Normal file
View File

@@ -0,0 +1,74 @@
<!--[metadata]>
+++
title = "Overview of contributing"
description = "Overview of contributing"
keywords = ["open, source, contributing, overview"]
[menu.main]
parent="mn_opensource"
+++
<![end-metadata]-->
# Overview of contributing
Contributing to the Docker project or to any open source project can be a
rewarding experience. You help yourself and you help the projects you work on.
You also help the countless number of other project participants.
Open source projects depend on a lot more than just code to be successful.
Proper documentation, testing, training, publicity, support and organization are
all critical.
# Filters for experienced contributors
If you are an experienced Docker contributor, we have pre-filtered for open
issues in the `docker/docker` repository.
* [Graphics](https://github.com/docker/docker/issues?q=is%3Aopen+is%3Aissue+label%3Akind%2Fgraphics+-label%3Astatus%2Fclaimed+-label%3Astatus%2Fassigned+no%3Aassignee)
* [Test](https://github.com/docker/docker/issues?q=is%3Aopen+is%3Aissue+label%3Akind%2Ftest+-label%3Astatus%2Fclaimed+-label%3Astatus%2Fassigned+no%3Aassignee)
* [Documentation](https://github.com/docker/docker/issues?q=is%3Aopen+is%3Aissue+label%3Akind%2Fwriting+-label%3Astatus%2Fclaimed+-label%3Astatus%2Fassigned+no%3Aassignee)
* [Questions](https://github.com/docker/docker/issues?q=is%3Aopen+is%3Aissue+label%3Akind%2Fquestion+-label%3Astatus%2Fclaimed+-label%3Astatus%2Fassigned+no%3Aassignee)
* [Bugs](https://github.com/docker/docker/issues?q=is%3Aopen+is%3Aissue+label%3Akind%2Fbug+-label%3Astatus%2Fclaimed+-label%3Astatus%2Fassigned+no%3Aassignee)
* [Features](https://github.com/docker/docker/issues?q=is%3Aopen+is%3Aissue+label%3Akind%2Ffeature+-label%3Astatus%2Fclaimed+-label%3Astatus%2Fassigned+no%3Aassignee)
* [Enhancements](https://github.com/docker/docker/issues?q=is%3Aopen+is%3Aissue+label%3Akind%2Fenhancement+-label%3Astatus%2Fclaimed+-label%3Astatus%2Fassigned+no%3Aassignee)
You might also want to check for open issues in our other Docker repositories:
<table class="tg">
<col width="20%">
<col width="80%">
<tr>
<td class="tg-031e"><a href="https://github.com/docker/machine/issues" >docker/machine</a></td>
<td class="tg-031e">Software for the easy and quick creation of Docker hosts on your computer, on cloud providers, and inside your own data center.</td>
</tr>
<tr>
<td class="tg-031e"><a href="https://github.com/docker/distribution/issues">docker/distribution</a></td>
<td class="tg-031e">Registry implementation for storing and distributing
docker images. Provides a secure tool chain for distributing content.</td>
</tr>
<tr>
<td class="tg-031e"><a href="https://github.com/docker-library/official-images/issues">docker-library/official-images</a></td>
<td class="tg-031e">This repository contains the images for our official repository.</td>
</tr>
<tr>
<td class="tg-031e"><a href="https://github.com/docker/distribution/issues">docker/distribution</a></td>
<td class="tg-031e">Registry implementation for storing and distributing
docker images. Provides a secure tool chain for distributing content.</td>
</tr>
<tr>
<td class="tg-031e"><a href="https://github.com/docker/swarm/issues">docker/swarm</a></td>
<td class="tg-031e">Native clustering for Docker; manage several Docker hosts as a single, virtual host.</td>
</tr>
<tr>
<td class="tg-031e"><a href="https://github.com/docker/compose/issues" >docker/compose</a></td>
<td class="tg-031e">Define and run complex applications using one or many interlinked containers.</td>
</tr>
</table>
# General resources and acknowledgements
Weve found [GitHub's guide on contributing
to open source](https://guides.github.com/overviews/os-contributing/) to
be a helpful guide to contributing in general.

94
docs/issues.md Normal file
View File

@@ -0,0 +1,94 @@
<!--[metadata]>
+++
title = "Organize our issues"
description = "Organize our issues"
keywords = ["governance, board, members, profiles"]
[menu.main]
parent="smn_registry_ref"
+++
<![end-metadata]-->
# Organize our issues
The Docker projects use GitHub issues to record issues and feature requests that
come in from contributors. Help us organize our work by triaging. Triage is the
process of reviewing incoming issue tickets, gathering more information about
the issue, and verifying whether or not the issue is valid.
You should triage if you want to discover which Docker features other contributors
think are important. Triage is a great choice if you have an interest
or experience in software product management or project management.
# What kind of issues can I triage?
Docker users and contributors create new issues if they want to:
* report a problem they had with Docker software
* request a new feature
* ask a question
# How do I triage?
Follow these steps:
1. Sign up for a <a href="https://github.com" target="_blank">Github account</a>.
2. Visit a Docker repository and press the **Watch** button.
This tells GitHub to notify you of new issues. Depending on your settings,
notification go to your GitHub or email inbox. Some of repositories you can watch are:
<table class="tg" >
<col width="20%">
<col width="80%">
<tr>
<td class="tg-031e"><a href="https://github.com/docker/docker" target="_blank">docker/docker</a></td>
<td class="tg-031e">Docker the open-source application container engine</td>
</tr>
<tr>
<td class="tg-031e"><a href="https://github.com/docker/machine" target="_blank">docker/machine</a></td>
<td class="tg-031e">Software for the easy and quick creation of Docker hosts on your computer, on cloud providers, and inside your own data center.</td>
</tr>
<tr>
<td class="tg-031e"><a href="https://github.com/kitematic/kitematic" target="_blank">kitematic/kitematic</a></td>
<td class="tg-031e">Kitematic is a simple application for managing Docker containers on Mac OS X.</td>
</tr>
</td>
</tr>
<tr>
<td class="tg-031e"><a href="https://github.com/docker/swarm" target="_blank">docker/swarm</a></td>
<td class="tg-031e">Native clustering for Docker; manage several Docker hosts as a single, virtual host.</td>
</tr>
<tr>
<td class="tg-031e"><a href="https://github.com/docker/compose" target="_blank">docker/compose</a></td>
<td class="tg-031e">Define and run complex applications using one or many interlinked containers.</td>
</tr>
</table>
See <a href="https://github.com/docker" target="_blank">the complete list of
Docker repositories</a> on GitHub.
3. Choose an issue from the <a
href="https://github.com/docker/docker/issues?q=is%3Aopen+is%3Aissue+-label%
3Akind%2Fproposal+-label%3Akind%2Fenhancement+-label%3Akind%2Fbug+-label%3Akind%
2Fcleanup+-label%3Akind%2Fgraphics+-label%3Akind%2Fwriting+-label%3Akind%
2Fsecurity+-label%3Akind%2Fquestion+-label%3Akind%2Fimprovement+-label%3Akind%
2Ffeature" target="_blank">list of untriaged issues</a>.
4. Follow the <a
href="https://github.com/docker/docker/blob/master/project/ISSUE-TRIAGE.md"
target="_blank">the triage process</a> to triage the issue.
The triage process asks you to add both a `kind/` and a `exp/` label to each
issue. Because you are not a Docker maintainer, you add these through comments.
Simply add a `+label` keyword to an issue comment:
![Example](/images/triage-label.png)
For example, the `+exp/beginner` and `+kind/writing` labels would triage an issue as
beginner writing task. For descriptions of valid labels, see the <a
href="https://github.com/docker/docker/blob/master/project/ISSUE-TRIAGE.md">the triage process</a>
5. Triage another issue.

56
docs/meetups.md Normal file
View File

@@ -0,0 +1,56 @@
<!--[metadata]>
+++
title = "Organize a Docker Meetup"
description = "Organize a Docker Meetup"
keywords = ["Docker, meetup, hosting, organizing"]
[menu.main]
parent="mn_opensource"
weight=2
+++
<![end-metadata]-->
# Organize a Docker Meetup
Anyone interested in Docker can become an active member of the Docker community by becoming co-organizer of a Docker Meetup group.
Meetup logo If a Meetup group does not already exist in your area and you are willing to start a new one, the best way to proceed is to contact us so that we can create it for you. We will always agree to create a new Docker Meetup group as long as it makes sense geographically speaking.
If you have already created a Docker Meetup group that is fine, we will simply ask you to add us as a co-organizer so that we can ensure a consistent support to the group in terms of community and Meetup management.
Before contacting us to create a new Docker Meetup Group, take a look at our Meetup Groups page to make sure a group does not already exist in the area.
## Get started putting on a Docker Meetup
Now that you are co-organizer of a Docker Meetup Group, here are a few tips and suggestions to help you get started:
* Attend similar DevOps or Developers Meetups to gain experience and gauge interest in Docker
* Contact other people interested in Docker to help you organize and promote future Meetups
* Research High-Tech companies in your area willing to host a Docker Meetup event
* Research what would be the best date(s) to schedule the Meetups based on availabilities with regard to competing events in the area and other calendar imperative
* Research what are the topic of interest to your audience prior to set an agenda for the meetup
* Pay attention to the Meetup page aesthetics, add logos and pictures, invite members to leave comments and reply to these comments
* Promote the event on social media and make sure that the list of keywords is well define if you have created the Docker Meetup Group on your own
## How Docker can help you organize
We can support the co-organizers of the Docker Meetup Groups based on their specific needs. For instance, we might / will be able to:
* Send you Docker T-shirts and stickers
* Put you in contact with other people interested in being a co-organizer of a Docker Meetup group, and which are in the same area
* Put you in contact with companies willing to host a Docker Meetup in your area
* Introduce you to people willing to give a lightning talk about Docker
Promote your Docker Group on Docker.com, Docker Weekly and Social Media
Hackday Picture
## Host a Docker meetup at your location
![Meetup](../images/hackday-600px.jpg)
## Want to host a Docker Meetup?
We are always looking for new office space to host Docker Meetups. If your company is willing to host a Docker Meetup, please contact us by email at meetup@docker.com. Previous Docker Meetups have been hosted by companies such as Rackspace, Twitter, MongoDB, BrightCove, DigitlOcean, Viadeo and Edmodo
### How many attendees?
The company hosting the event fixes the number of attendees depending on their office size and availability. This number usually varies between 30 and 200.
### How long is a Docker Meetup?
Once again, each company hosting the event decides when does the meetup start, and how long it lasts. Usual meetups tend to last 2 hours, and start between 4pm and 6pm.

73
docs/test.md Normal file
View File

@@ -0,0 +1,73 @@
<!--[metadata]>
+++
title = "Testing contributions"
description = "Testing contributions"
keywords = ["test, source, contributions, Docker"]
[menu.main]
parent="mn_opensource"
weight=3
+++
<![end-metadata]-->
# Testing contributions
Testing is about software quality, performance, reliability, or product usability. We develop and test Docker software before we release but we are human. So, we make mistakes, we get forgetful, or we just don't have enough time to do everything.
Choose to contribute testing if you want to improve Docker software and processes. Testing is a good choice for contributors that have experience software testing, usability testing, or who are otherwise great at spotting problems.
# What can you contribute to testing?
* Write a blog about <a href="http://www.appneta.com/blog/automated-testing-with-docker/" target="_blank">how your company uses Docker its test infrastructure</a>.
* Take <a href="http://ows.io/tj/w88v3siv" target="_blank">an online usability test</a> or create a usability test about Docker.
* Test one of<a href="https://github.com/docker-library/official-images/issues"> Docker's official images</a>
* Test the Docker documentation
# Test the Docker documentation
Testing documentation is relatively easy:
1. Find a page in <a href="http://docs.docker.com/" target="_blank">Docker's documentation</a> that contains a procedure or example you want to test.
You should choose something that _should work_ on your machine. For example,
<a href="http://docs.docker.com/articles/baseimages/" target="_blank">creating
a base image</a> is something anyone with Docker can do. While <a
href="https://kitematic.com/docs/managing-volumes/" target="_blank">changing
volume directories in Kitematic</a> requires a Mac and Docker's Kitematic
installed.
2. Try and follow the procedure or recreate the example.
What to look for:
* Are the steps clearly laid out and identifiable?
* Are the steps in the right order?
* Did you get the results the procedure or example said you would?
4. If you couldn't complete the procedure or example, file <a href="https://github.com/docker/docker/issues/new" target="_blank">an issue in the Docker repo</a>.
# Test code in the Docker
If you are interested in writing or fixing test code for the Docker project, learn about <a href="http://docs.docker.com/project/test-and-docs/" target="_blank">our test infrastructure</a>.
View <a href="http://goo.gl/EkyABb" target="_blank"> our open test issues</a> in Docker for something to work on. Or, create one of your own.