docker/docs
1
0
Fork 0
mirror of https://github.com/docker/docs.git synced 2026-11-06 12:54:24 +03:00
Code Activity

Adding first draft of open source content

Browse Source
This commit is contained in:
spf13
2015-06-12 14:37:28 -04:00
parent e2babdb045
commit e568f0cdb0
8 changed files with 329 additions and 142 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
docs/community.md
View File

@@ -25,16 +25,9 @@ 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:
Docker users are people using Docker in their daily work. To help Docker users, visit:
* the <a href="https://groups.google.com/forum/#!forum/docker-user"
target="_blank">Docker-user</a> Google group
@@ -45,7 +38,7 @@ 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.

61
docs/governance/board-profiles.md
View File

@@ -9,6 +9,63 @@ weight=1
+++
<![end-metadata]-->
# Board member profiles
TBD
# Project Leadership
The Docker Project is led by three individuals who are responsible for the direction, operations, quality and community of the project as a whole.
### Chief Architect : Solomon Hykes
The chief architect is responsible for the general direction of the project,
defining it’s design principles, and preserving the integrity of it’s overall
architecture as the platform grows and matures.
### Chief Maintainer : Michael Crosby
The chief maintainer is responsible for all aspects of quality for the project
including code reviews, usability, stability, security and performance.
### Chief Operator : Steve Francia
The chief operator is responsible for the day-to-day operations of the project
including: facilitating communications amongst all the contributors; tracking
release schedules; managing the relationship with downstream distributions and
upstream dependencies; and helping new contributors to get involved and become
successful contributors and maintainers. The role is also responsible for
managing and measuring the success of the overall project and ensuring it is
governed properly working in concert with the Docker Governance Advisory Board
(DGAB).
# Members of the 2014 DGAB
The DGAB is made up of 15 individual who represent the ecosystem, contributors
and community of the Docker Project.
## Docker
* Solomon Hykes
* Victor Vieux
* Michael Crosby
## Contributor
* Andrew Tianon Page
* Brandon Phillips
* Jonathan Rudenberg
* David Calavera
## Corporate
* Eric Brewer (Google)
* Dave Ing (IBM)
* Van Lindberg (Rackspace)
* Dan Walsh (RedHat)
## User
* Nicola Paolucci (Atlassian)
* Rohan Singh (Spotify)
* Meghdoot Bhattacharya (PayPal)
* Borja Burgos (Tutum)

40
docs/governance/conduct-code.md
View File

@@ -11,4 +11,42 @@ weight=2
# Code of conduct
TBD
The Docker project has not currently adopted a Code of Conduct though there is work being done in this regard.
There is an official [DockerCon code of conduct](http://www.dockercon.com/code-of-conduct).
Without a formal Code of Conduct being adopted by the project, it is
anticipated that participants and contributors follow the generic [contributor
covenant](http://contributor-covenant.org) until a formal code of conduct is
adopted.
# Contributor Covenant
As contributors and maintainers of this project, we pledge to respect all
people who contribute through reporting issues, posting feature requests,
updating documentation, submitting pull requests or patches, and other
activities.
We are committed to making participation in this project a harassment-free
experience for everyone, regardless of level of experience, gender, gender
identity and expression, sexual orientation, disability, personal appearance,
body size, race, ethnicity, age, or religion.
Examples of unacceptable behavior by participants include the use of sexual
language or imagery, derogatory comments or personal attacks, trolling, public
or private harassment, insults, or other unprofessional conduct.
Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct. Project maintainers who do not
follow the Code of Conduct may be removed from the project team.
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by opening an issue or contacting one or more of the project
maintainers.
This Code of Conduct is adapted from the [Contributor
Covenant](http:contributor-covenant.org), version 1.0.0, available at
[http://contributor-covenant.org/version/1/0/0/](http://contributor-covenant.org/version/1/0/0/)

193
docs/governance/dgab-info.md
View File

@@ -10,105 +10,188 @@ parent="smn_governance"
# 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.
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 project’s 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.
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 project’s 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.
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
* 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
* 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 project’s 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
* 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
## 4.2 Selection Process
* 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 project’s 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
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.
### 4.2 Selection Process
Corporate seats: Nomination is restricted to companies for whom all three of the following are true
#### Contributors:
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
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.
Have committed to integrate Docker into widely used products in a manner consistent with Core Criteria. (c.f. section 7.0)
#### Corporate seats:
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.
Nomination is restricted to companies for whom all three of
the following are true
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.
1. 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
1. Have employees as maintainers and/or make significant contributions to the
code base
1. 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
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
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 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 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 participation:
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.
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 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
### Open technical meritocracy:
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
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 Licensing: code should be licensed using approved, standard, open-source licenses. (Docker is currently licensed under Apache 2.0)
### 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
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
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.
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)\.
Please help us improve this draft by sending your comments and feedback to
governance@docker.com)\.

14
docs/how-to-contribute.md
View File

@@ -41,19 +41,18 @@ You might also want to check for open issues in our other Docker repositories:
<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>
<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>
<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>
</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>
<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>
@@ -68,7 +67,6 @@ You might also want to check for open issues in our other Docker repositories:
# General resources and acknowledgements
We’ve found [GitHub's guide on contributing
to open source](https://guides.github.com/overviews/os-contributing/) to
We’ve 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.

77
docs/issues.md
View File

@@ -36,38 +36,37 @@ Follow these steps:
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>
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>
</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.
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%
@@ -80,14 +79,14 @@ href="https://github.com/docker/docker/issues?q=is%3Aopen+is%3Aissue+-label%
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
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.

33
docs/meetups.md
View File

@@ -11,17 +11,25 @@ weight=2
# 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.
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 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.
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.
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:
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
@@ -47,10 +55,19 @@ Hackday Picture
![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
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.
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.
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.

42
docs/test.md
View File

@@ -11,9 +11,15 @@ weight=3
# 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.
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.
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?
@@ -27,24 +33,24 @@ Choose to contribute testing if you want to improve Docker software and processe
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.
## Step 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.
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.
## Step 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?
What to look for:
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>.
* 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?
## Step 3. 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
@@ -54,10 +60,6 @@ View <a href="http://goo.gl/EkyABb" target="_blank"> our open test issues</a> in