mirror of
https://github.com/docker/docs.git
synced 2026-03-27 22:38:54 +07:00
1800 lines
85 KiB
XML
1800 lines
85 KiB
XML
<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
|
||
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
|
||
<channel>
|
||
<title>Opensources on Docker Docs</title>
|
||
<link>http://localhost/opensource/</link>
|
||
<description>Recent content in Opensources on Docker Docs</description>
|
||
<generator>Hugo -- gohugo.io</generator>
|
||
<language>en-us</language>
|
||
<atom:link href="http://localhost/opensource/index.xml" rel="self" type="application/rss+xml" />
|
||
|
||
<item>
|
||
<title>Advanced contributing</title>
|
||
<link>http://localhost/opensource/workflow/advanced-contributing/</link>
|
||
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
||
|
||
<guid>http://localhost/opensource/workflow/advanced-contributing/</guid>
|
||
<description>
|
||
|
||
<h1 id="advanced-contributing">Advanced contributing</h1>
|
||
|
||
<p>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&rsquo;t be scared off though, if you like to stretch and
|
||
challenge yourself, this is the place for you.</p>
|
||
|
||
<p>This section gives generalized instructions for advanced contributions. You&rsquo;ll
|
||
read about the workflow but there are not specific descriptions of commands.
|
||
Your goal should be to understand the processes described.</p>
|
||
|
||
<p>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>.</p>
|
||
|
||
<h2 id="refactor-or-cleanup-proposal">Refactor or cleanup proposal</h2>
|
||
|
||
<p>A refactor or cleanup proposal changes Docker&rsquo;s internal structure without
|
||
altering the external behavior. To make this type of proposal:</p>
|
||
|
||
<ol>
|
||
<li><p>Fork <code>docker/docker</code>.</p></li>
|
||
|
||
<li><p>Make your changes in a feature branch.</p></li>
|
||
|
||
<li><p>Sync and rebase with <code>master</code> as you work.</p></li>
|
||
|
||
<li><p>Run the full test suite.</p></li>
|
||
|
||
<li><p>Submit your code through a pull request (PR).</p>
|
||
|
||
<p>The PR&rsquo;s title should have the format:</p>
|
||
|
||
<p><strong>Cleanup:</strong> <em>short title</em></p>
|
||
|
||
<p>If your changes required logic changes, note that in your request.</p></li>
|
||
|
||
<li><p>Work through Docker&rsquo;s review process until merge.</p></li>
|
||
</ol>
|
||
|
||
<h2 id="design-proposal">Design proposal</h2>
|
||
|
||
<p>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.</p>
|
||
|
||
<p><img src="../opensource/workflow/images/proposal.png" alt="Simple process" /></p>
|
||
|
||
<p>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.</p>
|
||
|
||
<p>The following provides greater detail on the process:</p>
|
||
|
||
<ol>
|
||
<li><p>Come up with an idea.</p>
|
||
|
||
<p>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.</p></li>
|
||
|
||
<li><p>Review existing issues and proposals to make sure no other user is proposing a similar idea.</p>
|
||
|
||
<p>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>.</p></li>
|
||
|
||
<li><p>Talk to the community about your idea.</p>
|
||
|
||
<p>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.</p></li>
|
||
|
||
<li><p>Fork <code>docker/docker</code> and clone the repo to your local host.</p></li>
|
||
|
||
<li><p>Create a new Markdown file in the area you wish to change.</p>
|
||
|
||
<p>For example, if you want to redesign our daemon create a new file under the
|
||
<code>daemon/</code> folder.</p></li>
|
||
|
||
<li><p>Name the file descriptively, for example <code>redesign-daemon-proposal.md</code>.</p></li>
|
||
|
||
<li><p>Write a proposal for your change into the file.</p>
|
||
|
||
<p>This is a Markdown file that describes your idea. Your proposal
|
||
should include information like:</p>
|
||
|
||
<ul>
|
||
<li>Why is this change needed or what are the use cases?</li>
|
||
<li>What are the requirements this change should meet?</li>
|
||
<li>What are some ways to design/implement this feature?</li>
|
||
<li>Which design/implementation do you think is best and why?</li>
|
||
<li>What are the risks or limitations of your proposal?</li>
|
||
</ul>
|
||
|
||
<p>This is your chance to convince people your idea is sound.</p></li>
|
||
|
||
<li><p>Submit your proposal in a pull request to <code>docker/docker</code>.</p>
|
||
|
||
<p>The title should have the format:</p>
|
||
|
||
<p><strong>Proposal:</strong> <em>short title</em></p>
|
||
|
||
<p>The body of the pull request should include a brief summary of your change
|
||
and then say something like &ldquo;<em>See the file for a complete description</em>&rdquo;.</p></li>
|
||
|
||
<li><p>Refine your proposal through review.</p>
|
||
|
||
<p>The maintainers and the community review your proposal. You&rsquo;ll need to
|
||
answer questions and sometimes explain or defend your approach. This is
|
||
chance for everyone to both teach and learn.</p></li>
|
||
|
||
<li><p>Pull request accepted.</p>
|
||
|
||
<p>Your request may also be rejected. Not every idea is a good fit for Docker.
|
||
Let&rsquo;s assume though your proposal succeeded.</p></li>
|
||
|
||
<li><p>Implement your idea.</p>
|
||
|
||
<p>Implementation uses all the standard practices of any contribution.</p>
|
||
|
||
<ul>
|
||
<li>fork <code>docker/docker</code></li>
|
||
<li>create a feature branch</li>
|
||
<li>sync frequently back to master</li>
|
||
<li>test as you go and full test before a PR</li>
|
||
</ul>
|
||
|
||
<p>If you run into issues, the community is there to help.</p></li>
|
||
|
||
<li><p>When you have a complete implementation, submit a pull request back to <code>docker/docker</code>.</p></li>
|
||
|
||
<li><p>Review and iterate on your code.</p>
|
||
|
||
<p>If you are making a large code change, you can expect greater scrutiny
|
||
during this phase.</p></li>
|
||
|
||
<li><p>Acceptance and merge!</p></li>
|
||
</ol>
|
||
|
||
<h2 id="about-the-advanced-process">About the advanced process</h2>
|
||
|
||
<p>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.</p>
|
||
|
||
<p>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</p>
|
||
|
||
<p>While proposals in pull requests do not end up merged into a master repository, they provide a convenient tool for managing the design process.</p>
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Board member profiles</title>
|
||
<link>http://localhost/opensource/governance/board-profiles/</link>
|
||
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
||
|
||
<guid>http://localhost/opensource/governance/board-profiles/</guid>
|
||
<description>
|
||
|
||
<h1 id="project-leadership">Project Leadership</h1>
|
||
|
||
<p>The Docker Project is led by three individuals who are responsible for the direction, operations, quality and community of the project as a whole.</p>
|
||
|
||
<h3 id="chief-architect-solomon-hykes">Chief Architect : Solomon Hykes</h3>
|
||
|
||
<p>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.</p>
|
||
|
||
<h3 id="chief-maintainer-michael-crosby">Chief Maintainer : Michael Crosby</h3>
|
||
|
||
<p>The chief maintainer is responsible for all aspects of quality for the project
|
||
including code reviews, usability, stability, security and performance.</p>
|
||
|
||
<h3 id="chief-operator-steve-francia">Chief Operator : Steve Francia</h3>
|
||
|
||
<p>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).</p>
|
||
|
||
<h1 id="members-of-the-2015-dgab">Members of the 2015 DGAB</h1>
|
||
|
||
<p>The DGAB is made up of 16 individual who represent the ecosystem, contributors
|
||
and community of the Docker Project.</p>
|
||
|
||
<h2 id="docker">Docker</h2>
|
||
|
||
<ul>
|
||
<li>Michael Crosby</li>
|
||
<li>Steve Francia</li>
|
||
<li>Stephen Day</li>
|
||
<li>Arnaud Poterie</li>
|
||
</ul>
|
||
|
||
<h2 id="individual-contributors">Individual Contributors</h2>
|
||
|
||
<ul>
|
||
<li>Andrew Tianon Page</li>
|
||
<li>Aleksa Sarai</li>
|
||
<li>Harald Albers</li>
|
||
<li>Darren Shepherd</li>
|
||
</ul>
|
||
|
||
<h2 id="corporate-contributors">Corporate Contributors</h2>
|
||
|
||
<ul>
|
||
<li>Jeff Borek (IBM)</li>
|
||
<li>Dan Walsh (RedHat)</li>
|
||
<li>Ahmet Alp Balkan (Microsoft)</li>
|
||
<li>Rohit Jnagal (Google)</li>
|
||
</ul>
|
||
|
||
<h2 id="user">User</h2>
|
||
|
||
<ul>
|
||
<li>Nicola Paolucci (Atlassian)</li>
|
||
<li>Burke Libbey (Shopify)</li>
|
||
<li>Meghdoot Bhattacharya (PayPal)</li>
|
||
<li>Tapabrata Pal (Capital One)</li>
|
||
</ul>
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Code of conduct</title>
|
||
<link>http://localhost/opensource/governance/conduct-code/</link>
|
||
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
||
|
||
<guid>http://localhost/opensource/governance/conduct-code/</guid>
|
||
<description>
|
||
|
||
<h1 id="code-of-conduct">Code of conduct</h1>
|
||
|
||
<p>The Docker project has not currently adopted a Code of Conduct though there is
|
||
work being done in this regard. Without a formal Code of Conduct being adopted
|
||
by the project, it is anticipated that participants and contributors follow the
|
||
generic <a href="http://contributor-covenant.org">contributor covenant</a> until a formal
|
||
code of conduct is adopted.</p>
|
||
|
||
<h1 id="contributor-covenant">Contributor Covenant</h1>
|
||
|
||
<p>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.</p>
|
||
|
||
<p>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.</p>
|
||
|
||
<p>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.</p>
|
||
|
||
<p>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.</p>
|
||
|
||
<p>Instances of abusive, harassing, or otherwise unacceptable behavior may be
|
||
reported by opening an issue or contacting one or more of the project
|
||
maintainers.</p>
|
||
|
||
<p>This Code of Conduct is adapted from the <a href="http://contributor-covenant.org">Contributor
|
||
Covenant</a>, version 1.0.0, available at
|
||
<a href="http://contributor-covenant.org/version/1/0/0/">http://contributor-covenant.org/version/1/0/0/</a></p>
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Coding style checklist</title>
|
||
<link>http://localhost/opensource/workflow/coding-style/</link>
|
||
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
||
|
||
<guid>http://localhost/opensource/workflow/coding-style/</guid>
|
||
<description>
|
||
|
||
<h1 id="coding-style-checklist">Coding style checklist</h1>
|
||
|
||
<p>This checklist summarizes the material you experienced working through <a href="../opensource/workflow/make-a-contribution/">make a
|
||
code contribution</a> and <a href="../opensource/workflow/advanced-contributing/">advanced
|
||
contributing</a>. The checklist applies to both
|
||
program code and documentation code.</p>
|
||
|
||
<h2 id="change-and-commit-code">Change and commit code</h2>
|
||
|
||
<ul>
|
||
<li><p>Fork the <code>docker/docker</code> repository.</p></li>
|
||
|
||
<li><p>Make changes on your fork in a feature branch. Name your branch <code>XXXX-something</code>
|
||
where <code>XXXX</code> is the issue number you are working on.</p></li>
|
||
|
||
<li><p>Run <code>gofmt -s -w file.go</code> on each changed file before
|
||
committing your changes. Most editors have plug-ins that do this automatically.</p></li>
|
||
|
||
<li><p>Run <code>golint</code> on each changed file before
|
||
committing your changes.</p></li>
|
||
|
||
<li><p>Update the documentation when creating or modifying features.</p></li>
|
||
|
||
<li><p>Commits that fix or close an issue should reference them in the commit message
|
||
<code>Closes #XXXX</code> or <code>Fixes #XXXX</code>. Mentions help by automatically closing the
|
||
issue on a merge.</p></li>
|
||
|
||
<li><p>After every commit, run the test suite and ensure it is passing.</p></li>
|
||
|
||
<li><p>Sync and rebase frequently as you code to keep up with <code>docker</code> master.</p></li>
|
||
|
||
<li><p>Set your <code>git</code> signature and make sure you sign each commit.</p></li>
|
||
|
||
<li><p>Do not add yourself to the <code>AUTHORS</code> file. This file is autogenerated from the
|
||
Git history.</p></li>
|
||
</ul>
|
||
|
||
<h2 id="tests-and-testing">Tests and testing</h2>
|
||
|
||
<ul>
|
||
<li><p>Submit unit tests for your changes.</p></li>
|
||
|
||
<li><p>Make use of the builtin Go test framework built.</p></li>
|
||
|
||
<li><p>Use existing Docker test files (<code>name_test.go</code>) for inspiration.</p></li>
|
||
|
||
<li><p>Run <a href="../test-and-docs/" target="_blank">the full test suite</a> on your
|
||
branch before submitting a pull request.</p></li>
|
||
|
||
<li><p>Run <code>make docs</code> to build the documentation and then check it locally.</p></li>
|
||
|
||
<li><p>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.</p></li>
|
||
</ul>
|
||
|
||
<h2 id="pull-requests">Pull requests</h2>
|
||
|
||
<ul>
|
||
<li><p>Sync and cleanly rebase on top of Docker&rsquo;s <code>master</code> without multiple branches
|
||
mixed into the PR.</p></li>
|
||
|
||
<li><p>Before the pull request, squash your commits into logical units of work using
|
||
<code>git rebase -i</code> and <code>git push -f</code>.</p></li>
|
||
|
||
<li><p>Include documentation changes in the same commit so that a revert would
|
||
remove all traces of the feature or fix.</p></li>
|
||
|
||
<li><p>Reference each issue in your pull request description (<code>#XXXX</code>)</p></li>
|
||
</ul>
|
||
|
||
<h2 id="respond-to-pull-requests-reviews">Respond to pull requests reviews</h2>
|
||
|
||
<ul>
|
||
<li><p>Docker maintainers use LGTM (<strong>l</strong>ooks-<strong>g</strong>ood-<strong>t</strong>o-<strong>m</strong>e) in PR comments
|
||
to indicate acceptance.</p></li>
|
||
|
||
<li><p>Code review comments may be added to your pull request. Discuss, then make
|
||
the suggested modifications and push additional commits to your feature
|
||
branch.</p></li>
|
||
|
||
<li><p>Incorporate changes on your feature branch and push to your fork. This
|
||
automatically updates your open pull request.</p></li>
|
||
|
||
<li><p>Post a comment after pushing to alert reviewers to PR changes; pushing a
|
||
change does not send notifications.</p></li>
|
||
|
||
<li><p>A change requires LGTMs from an absolute majority maintainers of an
|
||
affected component. For example, if you change <code>docs/</code> and <code>registry/</code> code,
|
||
an absolute majority of the <code>docs/</code> and the <code>registry/</code> maintainers must
|
||
approve your PR.</p></li>
|
||
</ul>
|
||
|
||
<h2 id="merges-after-pull-requests">Merges after pull requests</h2>
|
||
|
||
<ul>
|
||
<li><p>After a merge, <a href="https://master.dockerproject.org/">a master build</a> is
|
||
available almost immediately.</p></li>
|
||
|
||
<li><p>If you made a documentation change, you can see it at
|
||
<a href="http://docs.master.dockerproject.org/">docs.master.dockerproject.org</a>.</p></li>
|
||
</ul>
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Configure Git for contributing</title>
|
||
<link>http://localhost/opensource/project/set-up-git/</link>
|
||
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
||
|
||
<guid>http://localhost/opensource/project/set-up-git/</guid>
|
||
<description>
|
||
|
||
<h1 id="configure-git-for-contributing">Configure Git for contributing</h1>
|
||
|
||
<p>Work through this page to configure Git and a repository you&rsquo;ll use throughout
|
||
the Contributor Guide. The work you do further in the guide, depends on the work
|
||
you do here.</p>
|
||
|
||
<h2 id="fork-and-clone-the-docker-code">Fork and clone the Docker code</h2>
|
||
|
||
<p>Before contributing, you first fork the Docker code repository. A fork copies
|
||
a repository at a particular point in time. GitHub tracks for you where a fork
|
||
originates.</p>
|
||
|
||
<p>As you make contributions, you change your fork&rsquo;s code. When you are ready,
|
||
you make a pull request back to the original Docker repository. If you aren&rsquo;t
|
||
familiar with this workflow, don&rsquo;t worry, this guide walks you through all the
|
||
steps.</p>
|
||
|
||
<p>To fork and clone Docker:</p>
|
||
|
||
<ol>
|
||
<li><p>Open a browser and log into GitHub with your account.</p></li>
|
||
|
||
<li><p>Go to the <a href="https://github.com/docker/docker"
|
||
target="_blank">docker/docker repository</a>.</p></li>
|
||
|
||
<li><p>Click the &ldquo;Fork&rdquo; button in the upper right corner of the GitHub interface.</p>
|
||
|
||
<p><img src="../opensource/project/images/fork_docker.png" alt="Branch Signature" /></p>
|
||
|
||
<p>GitHub forks the repository to your GitHub account. The original
|
||
<code>docker/docker</code> repository becomes a new fork <code>YOUR_ACCOUNT/docker</code> under
|
||
your account.</p></li>
|
||
|
||
<li><p>Copy your fork&rsquo;s clone URL from GitHub.</p>
|
||
|
||
<p>GitHub allows you to use HTTPS or SSH protocols for clones. You can use the
|
||
<code>git</code> command line or clients like Subversion to clone a repository.</p>
|
||
|
||
<p><img src="../opensource/project/images/copy_url.png" alt="Copy clone URL" /></p>
|
||
|
||
<p>This guide assume you are using the HTTPS protocol and the <code>git</code> command
|
||
line. If you are comfortable with SSH and some other tool, feel free to use
|
||
that instead. You&rsquo;ll need to convert what you see in the guide to what is
|
||
appropriate to your tool.</p></li>
|
||
|
||
<li><p>Open a terminal window on your local host and change to your home directory.</p>
|
||
|
||
<pre><code>$ cd ~
|
||
</code></pre>
|
||
|
||
<p>In Windows, you&rsquo;ll work in your Docker Quickstart Terminal window instead of
|
||
Powershell or a <code>cmd</code> window.</p></li>
|
||
|
||
<li><p>Create a <code>repos</code> directory.</p>
|
||
|
||
<pre><code>$ mkdir repos
|
||
</code></pre></li>
|
||
|
||
<li><p>Change into your <code>repos</code> directory.</p>
|
||
|
||
<pre><code>$ cd repos
|
||
</code></pre></li>
|
||
|
||
<li><p>Clone the fork to your local host into a repository called <code>docker-fork</code>.</p>
|
||
|
||
<pre><code>$ git clone https://github.com/moxiegirl/docker.git docker-fork
|
||
</code></pre>
|
||
|
||
<p>Naming your local repo <code>docker-fork</code> should help make these instructions
|
||
easier to follow; experienced coders don&rsquo;t typically change the name.</p></li>
|
||
|
||
<li><p>Change directory into your new <code>docker-fork</code> directory.</p>
|
||
|
||
<pre><code>$ cd docker-fork
|
||
</code></pre>
|
||
|
||
<p>Take a moment to familiarize yourself with the repository&rsquo;s contents. List
|
||
the contents.</p></li>
|
||
</ol>
|
||
|
||
<h2 id="set-your-signature-and-an-upstream-remote">Set your signature and an upstream remote</h2>
|
||
|
||
<p>When you contribute to Docker, you must certify you agree with the
|
||
<a href="http://developercertificate.org/" target="_blank">Developer Certificate of Origin</a>.
|
||
You indicate your agreement by signing your <code>git</code> commits like this:</p>
|
||
|
||
<pre><code>Signed-off-by: Pat Smith &lt;pat.smith@email.com&gt;
|
||
</code></pre>
|
||
|
||
<p>To create a signature, you configure your username and email address in Git.
|
||
You can set these globally or locally on just your <code>docker-fork</code> repository.
|
||
You must sign with your real name. We don&rsquo;t accept anonymous contributions or
|
||
contributions through pseudonyms.</p>
|
||
|
||
<p>As you change code in your fork, you&rsquo;ll want to keep it in sync with the changes
|
||
others make in the <code>docker/docker</code> repository. To make syncing easier, you&rsquo;ll
|
||
also add a <em>remote</em> called <code>upstream</code> that points to <code>docker/docker</code>. A remote
|
||
is just another project version hosted on the internet or network.</p>
|
||
|
||
<p>To configure your username, email, and add a remote:</p>
|
||
|
||
<ol>
|
||
<li><p>Change to the root of your <code>docker-fork</code> repository.</p>
|
||
|
||
<pre><code>$ cd docker-fork
|
||
</code></pre></li>
|
||
|
||
<li><p>Set your <code>user.name</code> for the repository.</p>
|
||
|
||
<pre><code>$ git config --local user.name &quot;FirstName LastName&quot;
|
||
</code></pre></li>
|
||
|
||
<li><p>Set your <code>user.email</code> for the repository.</p>
|
||
|
||
<pre><code>$ git config --local user.email &quot;emailname@mycompany.com&quot;
|
||
</code></pre></li>
|
||
|
||
<li><p>Set your local repo to track changes upstream, on the <code>docker</code> repository.</p>
|
||
|
||
<pre><code>$ git remote add upstream https://github.com/docker/docker.git
|
||
</code></pre></li>
|
||
|
||
<li><p>Check the result in your <code>git</code> configuration.</p>
|
||
|
||
<pre><code>$ git config --local -l
|
||
core.repositoryformatversion=0
|
||
core.filemode=true
|
||
core.bare=false
|
||
core.logallrefupdates=true
|
||
remote.origin.url=https://github.com/moxiegirl/docker.git
|
||
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
|
||
branch.master.remote=origin
|
||
branch.master.merge=refs/heads/master
|
||
user.name=Mary Anthony
|
||
user.email=mary@docker.com
|
||
remote.upstream.url=https://github.com/docker/docker.git
|
||
remote.upstream.fetch=+refs/heads/*:refs/remotes/upstream/*
|
||
</code></pre>
|
||
|
||
<p>To list just the remotes use:</p>
|
||
|
||
<pre><code>$ 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)
|
||
</code></pre></li>
|
||
</ol>
|
||
|
||
<h2 id="create-and-push-a-branch">Create and push a branch</h2>
|
||
|
||
<p>As you change code in your fork, make your changes on a repository branch.
|
||
The branch name should reflect what you are working on. In this section, you
|
||
create a branch, make a change, and push it up to your fork.</p>
|
||
|
||
<p>This branch is just for testing your config for this guide. The changes are part
|
||
of a dry run, so the branch name will be dry-run-test. To create and push
|
||
the branch to your fork on GitHub:</p>
|
||
|
||
<ol>
|
||
<li><p>Open a terminal and go to the root of your <code>docker-fork</code>.</p>
|
||
|
||
<pre><code>$ cd docker-fork
|
||
</code></pre></li>
|
||
|
||
<li><p>Create a <code>dry-run-test</code> branch.</p>
|
||
|
||
<pre><code>$ git checkout -b dry-run-test
|
||
</code></pre>
|
||
|
||
<p>This command creates the branch and switches the repository to it.</p></li>
|
||
|
||
<li><p>Verify you are in your new branch.</p>
|
||
|
||
<pre><code>$ git branch
|
||
* dry-run-test
|
||
master
|
||
</code></pre>
|
||
|
||
<p>The current branch has an * (asterisk) marker. So, these results shows you
|
||
are on the right branch.</p></li>
|
||
|
||
<li><p>Create a <code>TEST.md</code> file in the repository&rsquo;s root.</p>
|
||
|
||
<pre><code>$ touch TEST.md
|
||
</code></pre></li>
|
||
|
||
<li><p>Edit the file and add your email and location.</p>
|
||
|
||
<p><img src="../opensource/project/images/contributor-edit.png" alt="Add your information" /></p>
|
||
|
||
<p>You can use any text editor you are comfortable with.</p></li>
|
||
|
||
<li><p>Save and close the file.</p></li>
|
||
|
||
<li><p>Check the status of your branch.</p>
|
||
|
||
<pre><code>$ git status
|
||
On branch dry-run-test
|
||
Untracked files:
|
||
(use &quot;git add &lt;file&gt;...&quot; to include in what will be committed)
|
||
|
||
|
||
TEST.md
|
||
|
||
|
||
nothing added to commit but untracked files present (use &quot;git add&quot; to track)
|
||
</code></pre>
|
||
|
||
<p>You&rsquo;ve only changed the one file. It is untracked so far by git.</p></li>
|
||
|
||
<li><p>Add your file.</p>
|
||
|
||
<pre><code>$ git add TEST.md
|
||
</code></pre>
|
||
|
||
<p>That is the only <em>staged</em> file. Stage is fancy word for work that Git is
|
||
tracking.</p></li>
|
||
|
||
<li><p>Sign and commit your change.</p>
|
||
|
||
<pre><code>$ git commit -s -m &quot;Making a dry run test.&quot;
|
||
[dry-run-test 6e728fb] Making a dry run test
|
||
1 file changed, 1 insertion(+)
|
||
create mode 100644 TEST.md
|
||
</code></pre>
|
||
|
||
<p>Commit messages should have a short summary sentence of no more than 50
|
||
characters. Optionally, you can also include a more detailed explanation
|
||
after the summary. Separate the summary from any explanation with an empty
|
||
line.</p></li>
|
||
|
||
<li><p>Push your changes to GitHub.</p>
|
||
|
||
<pre><code>$ git push --set-upstream origin dry-run-test
|
||
Username for 'https://github.com': moxiegirl
|
||
Password for 'https://moxiegirl@github.com':
|
||
</code></pre>
|
||
|
||
<p>Git prompts you for your GitHub username and password. Then, the command
|
||
returns a result.</p>
|
||
|
||
<pre><code>Counting objects: 13, done.
|
||
Compressing objects: 100% (2/2), done.
|
||
Writing objects: 100% (3/3), 320 bytes | 0 bytes/s, done.
|
||
Total 3 (delta 1), reused 0 (delta 0)
|
||
To https://github.com/moxiegirl/docker.git
|
||
* [new branch] dry-run-test -&gt; dry-run-test
|
||
Branch dry-run-test set up to track remote branch dry-run-test from origin.
|
||
</code></pre></li>
|
||
|
||
<li><p>Open your browser to GitHub.</p></li>
|
||
|
||
<li><p>Navigate to your Docker fork.</p></li>
|
||
|
||
<li><p>Make sure the <code>dry-run-test</code> branch exists, that it has your commit, and the
|
||
commit is signed.</p>
|
||
|
||
<p><img src="../opensource/project/images/branch-sig.png" alt="Branch Signature" /></p></li>
|
||
</ol>
|
||
|
||
<h2 id="where-to-go-next">Where to go next</h2>
|
||
|
||
<p>Congratulations, you have finished configuring both your local host environment
|
||
and Git for contributing. In the next section you&rsquo;ll <a href="../opensource/project/set-up-dev-env/">learn how to set up and
|
||
work in a Docker development container</a>.</p>
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Contribution workflow</title>
|
||
<link>http://localhost/opensource/workflow/</link>
|
||
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
||
|
||
<guid>http://localhost/opensource/workflow/</guid>
|
||
<description>
|
||
|
||
<h1 id="contribution-workflow">Contribution workflow</h1>
|
||
|
||
<ul>
|
||
<li><a href="../opensource/workflow/make-a-contribution/">Understand how to contribute</a><br /></li>
|
||
<li><a href="../opensource/workflow/find-an-issue/">Find and claim an issue</a><br /></li>
|
||
<li><a href="../opensource/workflow/work-issue/">Work on your issue</a></li>
|
||
<li><a href="../opensource/workflow/create-pr/">Create a pull request</a><br /></li>
|
||
<li><a href="../opensource/workflow/review-pr/">Participate in the PR review</a><br /></li>
|
||
<li><a href="../opensource/workflow/advanced-contributing/">Advanced contributing</a></li>
|
||
<li><a href="../opensource/workflow/coding-style/">Coding style checklist</a><br /></li>
|
||
</ul>
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Create a pull request (PR)</title>
|
||
<link>http://localhost/opensource/workflow/create-pr/</link>
|
||
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
||
|
||
<guid>http://localhost/opensource/workflow/create-pr/</guid>
|
||
<description>
|
||
|
||
<h1 id="create-a-pull-request-pr">Create a pull request (PR)</h1>
|
||
|
||
<p>A pull request (PR) sends your changes to the Docker maintainers for review. You
|
||
create a pull request on GitHub. A pull request &ldquo;pulls&rdquo; changes from your forked
|
||
repository into the <code>docker/docker</code> repository.</p>
|
||
|
||
<p>You can see <a href="https://github.com/docker/docker/pulls" target="_blank">the
|
||
list of active pull requests to Docker</a> on GitHub.</p>
|
||
|
||
<h2 id="check-your-work">Check your work</h2>
|
||
|
||
<p>Before you create a pull request, check your work.</p>
|
||
|
||
<ol>
|
||
<li><p>In a terminal window, go to the root of your <code>docker-fork</code> repository.</p>
|
||
|
||
<pre><code>$ cd ~/repos/docker-fork
|
||
</code></pre></li>
|
||
|
||
<li><p>Checkout your feature branch.</p>
|
||
|
||
<pre><code>$ git checkout 11038-fix-rhel-link
|
||
Switched to branch '11038-fix-rhel-link'
|
||
</code></pre></li>
|
||
|
||
<li><p>Run the full test suite on your branch.</p>
|
||
|
||
<pre><code>$ make test
|
||
</code></pre>
|
||
|
||
<p>All the tests should pass. If they don&rsquo;t, find out why and correct the
|
||
situation.</p></li>
|
||
|
||
<li><p>Optionally, if modified the documentation, build the documentation:</p>
|
||
|
||
<pre><code>$ make docs
|
||
</code></pre></li>
|
||
|
||
<li><p>Commit and push any changes that result from your checks.</p></li>
|
||
</ol>
|
||
|
||
<h2 id="rebase-your-branch">Rebase your branch</h2>
|
||
|
||
<p>Always rebase and squash your commits before making a pull request.</p>
|
||
|
||
<ol>
|
||
<li><p>Checkout your feature branch in your local <code>docker-fork</code> repository.</p>
|
||
|
||
<p>This is the branch associated with your request.</p></li>
|
||
|
||
<li><p>Fetch any last minute changes from <code>docker/docker</code>.</p>
|
||
|
||
<pre><code>$ git fetch upstream master
|
||
From github.com:docker/docker
|
||
* branch master -&gt; FETCH_HEAD
|
||
</code></pre></li>
|
||
|
||
<li><p>Start an interactive rebase.</p>
|
||
|
||
<pre><code>$ git rebase -i upstream/master
|
||
</code></pre></li>
|
||
|
||
<li><p>Rebase opens an editor with a list of commits.</p>
|
||
|
||
<pre><code>pick 1a79f55 Tweak some of the other text for grammar
|
||
pick 53e4983 Fix a link
|
||
pick 3ce07bb Add a new line about RHEL
|
||
</code></pre></li>
|
||
|
||
<li><p>Replace the <code>pick</code> keyword with <code>squash</code> on all but the first commit.</p>
|
||
|
||
<pre><code>pick 1a79f55 Tweak some of the other text for grammar
|
||
squash 53e4983 Fix a link
|
||
squash 3ce07bb Add a new line about RHEL
|
||
</code></pre>
|
||
|
||
<p>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.</p></li>
|
||
|
||
<li><p>Edit and save your commit message.</p>
|
||
|
||
<pre><code>$ git commit -s
|
||
</code></pre>
|
||
|
||
<p>Make sure your message includes <a href="../set-up-git" target="_blank">your signature</a>.</p></li>
|
||
|
||
<li><p>Force push any changes to your fork on GitHub.</p>
|
||
|
||
<pre><code>$ git push -f origin 11038-fix-rhel-link
|
||
</code></pre></li>
|
||
</ol>
|
||
|
||
<h2 id="create-a-pr-on-github">Create a PR on GitHub</h2>
|
||
|
||
<p>You create and manage PRs on GitHub:</p>
|
||
|
||
<ol>
|
||
<li><p>Open your browser to your fork on GitHub.</p>
|
||
|
||
<p>You should see the latest activity from your branch.</p>
|
||
|
||
<p><img src="../opensource/workflow/images/latest_commits.png" alt="Latest commits" /></p></li>
|
||
|
||
<li><p>Click &ldquo;Compare &amp; pull request.&rdquo;</p>
|
||
|
||
<p>The system displays the pull request dialog.</p>
|
||
|
||
<p><img src="../opensource/workflow/images/to_from_pr.png" alt="PR dialog" /></p>
|
||
|
||
<p>The pull request compares your changes to the <code>master</code> branch on the
|
||
<code>docker/docker</code> repository.</p></li>
|
||
|
||
<li><p>Edit the dialog&rsquo;s description and add a reference to the issue you are fixing.</p>
|
||
|
||
<p>GitHub helps you out by searching for the issue as you type.</p>
|
||
|
||
<p><img src="../opensource/workflow/images/fixes_num.png" alt="Fixes issue" /></p></li>
|
||
|
||
<li><p>Scroll down and verify the PR contains the commits and changes you expect.</p>
|
||
|
||
<p>For example, is the file count correct? Are the changes in the files what
|
||
you expect?</p>
|
||
|
||
<p><img src="../opensource/workflow/images/commits_expected.png" alt="Commits" /></p></li>
|
||
|
||
<li><p>Press &ldquo;Create pull request&rdquo;.</p>
|
||
|
||
<p>The system creates the request and opens it for you in the <code>docker/docker</code>
|
||
repository.</p>
|
||
|
||
<p><img src="../opensource/workflow/images/pull_request_made.png" alt="Pull request made" /></p></li>
|
||
</ol>
|
||
|
||
<h2 id="where-to-go-next">Where to go next</h2>
|
||
|
||
<p>Congratulations, you&rsquo;ve created your first pull request to Docker. The next
|
||
step is for you learn how to <a href="../opensource/workflow/review-pr/">participate in your PR&rsquo;s
|
||
review</a>.</p>
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Docker Governance Advisory Board</title>
|
||
<link>http://localhost/opensource/governance/dgab-info/</link>
|
||
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
||
|
||
<guid>http://localhost/opensource/governance/dgab-info/</guid>
|
||
<description>
|
||
|
||
<h1 id="docker-governance-advisory-board-june-2015-version">Docker Governance Advisory Board: June 2015 Version</h1>
|
||
|
||
<p>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. This document was
|
||
updated to reflect the new membership for 2015.</p>
|
||
|
||
<h2 id="1-0-background">1.0 Background</h2>
|
||
|
||
<p>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.</p>
|
||
|
||
<h2 id="2-0-purpose">2.0 Purpose</h2>
|
||
|
||
<p>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:</p>
|
||
|
||
<ul>
|
||
<li>Provide a forum for individuals, users, and companies to discuss the issues
|
||
under the DGAB purview (SCOPE)</li>
|
||
<li>Provide guidance and input to Leadership, and where possible, present a
|
||
consistent and consolidated opinion from the broader Docker community</li>
|
||
<li>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.</li>
|
||
<li>Promote and support the use of Docker in manner consistent with Guiding *</li>
|
||
</ul>
|
||
|
||
<h3 id="principles-of-the-project-and-the-core-criteria">Principles of the project and the Core Criteria</h3>
|
||
|
||
<p>The DGAB is not:</p>
|
||
|
||
<ul>
|
||
<li>Intended to serve as a governance board. The DGAB advises, but does not manage, the Docker project leadership</li>
|
||
<li>Intended to replace existing mechanisms for community input, governance, or contribution</li>
|
||
<li>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</li>
|
||
</ul>
|
||
|
||
<h2 id="3-0-scope">3.0 Scope</h2>
|
||
|
||
<p>The DGAB is expected to provide input and formal recommendations regarding the following areas:</p>
|
||
|
||
<ul>
|
||
<li>Docker project long term roadmap</li>
|
||
<li>Docker project policies and procedures around maintenance and contributions</li>
|
||
<li>Docker project policies and procedures around intellectual property, trademark, and licensing</li>
|
||
<li>Core Criteria for Docker-related project (c.f. section 7.0)</li>
|
||
<li>Docker project long term governance model</li>
|
||
</ul>
|
||
|
||
<h2 id="4-0-meetings-and-memberships">4.0 Meetings and Memberships</h2>
|
||
|
||
<h3 id="4-1-general">4.1 General</h3>
|
||
|
||
<p>The DGAB will have 16 members</p>
|
||
|
||
<ul>
|
||
<li>The Docker Chief Maintainer: Michael Crosby</li>
|
||
<li>The Docker Chief Operator: Steve Francia</li>
|
||
<li>2 seats for the top core maintainers (Docker)</li>
|
||
|
||
<li><p>Up to 12 additional seats: 4 corporate seats, 4 individual or small business seats, 4 “user” seats</p></li>
|
||
|
||
<li><p>No fee or sponsorship is required for membership</p></li>
|
||
|
||
<li><p>The membership term will last 12 months. With the exception of the Chief Maintainer, all members can serve a maximum of two consecutive terms</p></li>
|
||
|
||
<li><p>The selection process is intended to be open, transparent, and guided by objective criteria for membership.</p></li>
|
||
|
||
<li><p>The DGAB shall elect a Chair and Vice Chair from amongst their members to serve a renewable 6 month term.</p></li>
|
||
|
||
<li><p>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</p></li>
|
||
|
||
<li><p>Docker, inc. shall appoint a temporary chair to set the agenda for the first meeting and preside until the election shall occur.</p></li>
|
||
|
||
<li><p>A member of the DGAB may be removed by a resolution of the DGAB supported by more than two thirds of its membership.</p></li>
|
||
|
||
<li><p>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.</p></li>
|
||
|
||
<li><p>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.</p></li>
|
||
|
||
<li><p>All project maintainers are welcome as participants and observers at DGAB meetings</p></li>
|
||
</ul>
|
||
|
||
<h3 id="4-2-selection-process">4.2 Selection Process</h3>
|
||
|
||
<h4 id="contributors">Contributors:</h4>
|
||
|
||
<p>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.</p>
|
||
|
||
<h4 id="corporate-seats">Corporate seats:</h4>
|
||
|
||
<p>Nomination is restricted to companies for whom all three of
|
||
the following are true</p>
|
||
|
||
<ol>
|
||
<li>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</li>
|
||
<li>Have employees as maintainers and/or make significant contributions to the
|
||
code base</li>
|
||
<li>Have committed to integrate Docker into widely used products in a manner
|
||
consistent with Core Criteria. (c.f. section 7.0)</li>
|
||
</ol>
|
||
|
||
<p>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.</p>
|
||
|
||
<h4 id="user-seats">User seats:</h4>
|
||
|
||
<p>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.</p>
|
||
|
||
<h2 id="5-0-operation">5.0 Operation</h2>
|
||
|
||
<p>The DGAB is authorized to seek advice and counsel from other interested parties
|
||
and invited experts as appropriate</p>
|
||
|
||
<p>Any outside party wishing to bring an issue before the DGAB may do so by
|
||
emailing the DGAB mailing list</p>
|
||
|
||
<p>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 &ldquo;in confidence,&rdquo; in which case the public report shall
|
||
contain only a note of the request and an agreed summary (if any) of the
|
||
substance.</p>
|
||
|
||
<p>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.</p>
|
||
|
||
<p>The DGAB and its members shall abide by appropriate antitrust guidelines.</p>
|
||
|
||
<h2 id="6-0-open-governance-principles">6.0 Open Governance Principles</h2>
|
||
|
||
<p>The DGAB will formulate recommendations in conjunction with the following, open governance principles</p>
|
||
|
||
<h3 id="open-participation">Open participation:</h3>
|
||
|
||
<p>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</p>
|
||
|
||
<h3 id="open-technical-meritocracy">Open technical meritocracy:</h3>
|
||
|
||
<p>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.</p>
|
||
|
||
<h3 id="open-design">Open design:</h3>
|
||
|
||
<p>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</p>
|
||
|
||
<h3 id="ip-cleanliness">IP Cleanliness:</h3>
|
||
|
||
<p>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</p>
|
||
|
||
<h3 id="open-licensing">Open Licensing:</h3>
|
||
|
||
<p>Code should be licensed using approved, standard, open-source licenses. (Docker is currently licensed under Apache 2.0)</p>
|
||
|
||
<h2 id="7-0-core-criteria">7.0 Core Criteria</h2>
|
||
|
||
<p>The DGAB will formulate a set of Core Criteria for projects and commercial
|
||
products that use the Docker trademarks</p>
|
||
|
||
<p>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</p>
|
||
|
||
<p>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.</p>
|
||
|
||
<p>Please help us improve this draft by sending your comments and feedback to
|
||
governance@docker.com).</p>
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>FAQ for contributors</title>
|
||
<link>http://localhost/opensource/FAQ/</link>
|
||
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
||
|
||
<guid>http://localhost/opensource/FAQ/</guid>
|
||
<description>
|
||
|
||
<h1 id="faq-for-contributors">FAQ for contributors</h1>
|
||
|
||
<p>This section contains some frequently asked questions and tips for
|
||
troubleshooting problems in your code contribution.</p>
|
||
|
||
<ul>
|
||
<li><a href="#how-do-i-set-my-signature:cb7f612e17aad7eb26c06709ef92a867">How do I set my signature?</a></li>
|
||
<li><a href="#how-do-i-track-changes-from-the-docker-repo-upstream:cb7f612e17aad7eb26c06709ef92a867">How do I track changes from the docker repo upstream?</a></li>
|
||
<li><a href="#how-do-i-format-my-go-code:cb7f612e17aad7eb26c06709ef92a867">How do I format my Go code?</a></li>
|
||
<li><a href="#what-is-the-pre-pull-request-checklist:cb7f612e17aad7eb26c06709ef92a867">What is the pre-pull request checklist?</a></li>
|
||
<li><a href="#how-should-i-comment-my-code:cb7f612e17aad7eb26c06709ef92a867">How should I comment my code?</a></li>
|
||
<li><a href="#how-do-i-rebase-my-feature-branch:cb7f612e17aad7eb26c06709ef92a867">How do I rebase my feature branch?</a></li>
|
||
</ul>
|
||
|
||
<h2 id="how-do-i-set-my-signature">How do I set my signature</h2>
|
||
|
||
<ol>
|
||
<li><p>Change to the root of your <code>docker-fork</code> repository.</p>
|
||
|
||
<pre><code>$ cd docker-fork
|
||
</code></pre></li>
|
||
|
||
<li><p>Set your <code>user.name</code> for the repository.</p>
|
||
|
||
<pre><code>$ git config --local user.name &quot;FirstName LastName&quot;
|
||
</code></pre></li>
|
||
|
||
<li><p>Set your <code>user.email</code> for the repository.</p>
|
||
|
||
<pre><code>$ git config --local user.email &quot;emailname@mycompany.com&quot;
|
||
</code></pre></li>
|
||
</ol>
|
||
|
||
<h2 id="how-do-i-track-changes-from-the-docker-repo-upstream">How do I track changes from the docker repo upstream</h2>
|
||
|
||
<p>Set your local repo to track changes upstream, on the <code>docker</code> repository.</p>
|
||
|
||
<ol>
|
||
<li><p>Change to the root of your Docker repository.</p>
|
||
|
||
<pre><code>$ cd docker-fork
|
||
</code></pre></li>
|
||
|
||
<li><p>Add a remote called <code>upstream</code> that points to <code>docker/docker</code></p>
|
||
|
||
<pre><code>$ git remote add upstream https://github.com/docker/docker.git
|
||
</code></pre></li>
|
||
</ol>
|
||
|
||
<h2 id="how-do-i-format-my-go-code">How do I format my Go code</h2>
|
||
|
||
<p>Run <code>gofmt -s -w filename.go</code> on each changed file before committing your changes.
|
||
Most editors have plug-ins that do the formatting automatically.</p>
|
||
|
||
<h2 id="what-is-the-pre-pull-request-checklist">What is the pre-pull request checklist</h2>
|
||
|
||
<ul>
|
||
<li><p>Sync and cleanly rebase on top of Docker&rsquo;s <code>master</code>; do not mix multiple branches
|
||
in the pull request.</p></li>
|
||
|
||
<li><p>Squash your commits into logical units of work using
|
||
<code>git rebase -i</code> and <code>git push -f</code>.</p></li>
|
||
|
||
<li><p>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.</p></li>
|
||
|
||
<li><p>Reference each issue in your pull request description (<code>#XXXX</code>).</p></li>
|
||
</ul>
|
||
|
||
<h2 id="how-should-i-comment-my-code">How should I comment my code?</h2>
|
||
|
||
<p>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:</p>
|
||
|
||
<ul>
|
||
<li>Comments begin with two forward <code>//</code> slashes.</li>
|
||
<li>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.</li>
|
||
<li>Comments on package declarations should provide general package documentation.</li>
|
||
<li>For packages that need large amounts of introductory documentation: the
|
||
package comment is placed in its own file.</li>
|
||
<li>Subsequent lines of text are considered part of the same paragraph; you must
|
||
leave a blank line to separate paragraphs.</li>
|
||
<li>Indent pre-formatted text relative to the surrounding comment text (see gob&rsquo;s doc.go for an example).</li>
|
||
<li>URLs are converted to HTML links; no special markup is necessary.</li>
|
||
</ul>
|
||
|
||
<h2 id="how-do-i-rebase-my-feature-branch">How do I rebase my feature branch?</h2>
|
||
|
||
<p>Always rebase and squash your commits before making a pull request.</p>
|
||
|
||
<ol>
|
||
<li><p>Fetch any of the last minute changes from <code>docker/docker</code>.</p>
|
||
|
||
<pre><code>$ git fetch upstream master
|
||
</code></pre></li>
|
||
|
||
<li><p>Start an interactive rebase.</p>
|
||
|
||
<pre><code>$ git rebase -i upstream/master
|
||
</code></pre></li>
|
||
|
||
<li><p>Rebase opens an editor with a list of commits.</p>
|
||
|
||
<pre><code> pick 1a79f55 Tweak some of images
|
||
pick 3ce07bb Add a new line
|
||
</code></pre>
|
||
|
||
<p>If you run into trouble, <code>git --rebase abort</code> removes any changes and gets you
|
||
back to where you started.</p></li>
|
||
|
||
<li><p>Squash the <code>pick</code> keyword with <code>squash</code> on all but the first commit.</p>
|
||
|
||
<pre><code>pick 1a79f55 Tweak some of images
|
||
squash 3ce07bb Add a new line
|
||
</code></pre>
|
||
|
||
<p>After closing the file, <code>git</code> opens your editor again to edit the commit
|
||
message.</p></li>
|
||
|
||
<li><p>Edit and save your commit message.</p>
|
||
|
||
<pre><code>$ git commit -s
|
||
</code></pre>
|
||
|
||
<p>Make sure your message includes your signature.</p></li>
|
||
|
||
<li><p>Push any changes to your fork on GitHub, using the <code>-f</code> option to
|
||
force the previous change to be overwritten.</p>
|
||
|
||
<pre><code>$ git push -f origin my-keen-feature
|
||
</code></pre></li>
|
||
</ol>
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Find and claim an issue</title>
|
||
<link>http://localhost/opensource/workflow/find-an-issue/</link>
|
||
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
||
|
||
<guid>http://localhost/opensource/workflow/find-an-issue/</guid>
|
||
<description>
|
||
|
||
<p><style type="text/css"></p>
|
||
|
||
<p>.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; }</p>
|
||
|
||
<p></style></p>
|
||
|
||
<h1 id="find-and-claim-an-issue">Find and claim an issue</h1>
|
||
|
||
<p>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.</p>
|
||
|
||
<h2 id="understand-the-issue-types">Understand the issue types</h2>
|
||
|
||
<p>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.</p>
|
||
|
||
<p>Triaged issues have one of these labels:</p>
|
||
|
||
<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>
|
||
|
||
<p>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.</p>
|
||
|
||
<h2 id="claim-a-beginner-or-novice-issue">Claim a beginner or novice issue</h2>
|
||
|
||
<p>To claim an issue:</p>
|
||
|
||
<ol>
|
||
<li><p>Go to the <code>docker/docker</code> <a
|
||
href="https://github.com/docker/docker" target="_blank">repository</a>.</p></li>
|
||
|
||
<li><p>Click the &ldquo;Issues&rdquo; link.</p>
|
||
|
||
<p>A list of the open issues appears.</p>
|
||
|
||
<p><img src="../opensource/workflow/images/issue_list.png" alt="Open issues" /></p></li>
|
||
|
||
<li><p>From the &ldquo;Labels&rdquo; drop-down, select <strong class="gh-label beginner">exp/beginner</strong>.</p>
|
||
|
||
<p>The system filters to show only open <strong class="gh-label beginner">exp/beginner</strong> issues.</p></li>
|
||
|
||
<li><p>Open an issue that interests you.</p>
|
||
|
||
<p>The comments on the issues describe the problem and can provide information for a potential
|
||
solution.</p></li>
|
||
|
||
<li><p>When you find an open issue that both interests you and is unclaimed, add a
|
||
<code>#dibs</code> comment. Make sure that no other user has chosen to work on the issue.</p>
|
||
|
||
<p>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
|
||
<code>#dibs</code> comment on the issue.</p></li>
|
||
|
||
<li><p>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.</p>
|
||
|
||
<p><img src="../opensource/workflow/images/easy_issue.png" alt="Easy issue" /></p></li>
|
||
|
||
<li><p>Make a note of the issue number; you will need it for later.</p></li>
|
||
</ol>
|
||
|
||
<h2 id="sync-your-fork-and-create-a-new-branch">Sync your fork and create a new branch</h2>
|
||
|
||
<p>If you have followed along in this guide, you forked the <code>docker/docker</code>
|
||
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
|
||
<code>docker/docker</code> master. Syncing ensures your repository has the latest
|
||
changes.</p>
|
||
|
||
<p>To sync your repository:</p>
|
||
|
||
<ol>
|
||
<li><p>Open a terminal on your local host.</p></li>
|
||
|
||
<li><p>Change directory to the <code>docker-fork</code> root.</p>
|
||
|
||
<pre><code>$ cd ~/repos/docker-fork
|
||
</code></pre></li>
|
||
|
||
<li><p>Checkout the master branch.</p>
|
||
|
||
<pre><code>$ git checkout master
|
||
Switched to branch 'master'
|
||
Your branch is up-to-date with 'origin/master'.
|
||
</code></pre>
|
||
|
||
<p>Recall that <code>origin/master</code> is a branch on your remote GitHub repository.</p></li>
|
||
|
||
<li><p>Make sure you have the upstream remote <code>docker/docker</code> by listing them.</p>
|
||
|
||
<pre><code>$ 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)
|
||
</code></pre>
|
||
|
||
<p>If the <code>upstream</code> is missing, add it.</p>
|
||
|
||
<pre><code>$ git remote add upstream https://github.com/docker/docker.git
|
||
</code></pre></li>
|
||
|
||
<li><p>Fetch all the changes from the <code>upstream master</code> branch.</p>
|
||
|
||
<pre><code>$ git fetch upstream master
|
||
remote: Counting objects: 141, done.
|
||
remote: Compressing objects: 100% (29/29), done.
|
||
remote: Total 141 (delta 52), reused 46 (delta 46), pack-reused 66
|
||
Receiving objects: 100% (141/141), 112.43 KiB | 0 bytes/s, done.
|
||
Resolving deltas: 100% (79/79), done.
|
||
From github.com:docker/docker
|
||
* branch master -&gt; FETCH_HEAD
|
||
</code></pre>
|
||
|
||
<p>This command says get all the changes from the <code>master</code> branch belonging to
|
||
the <code>upstream</code> remote.</p></li>
|
||
|
||
<li><p>Rebase your local master with the <code>upstream/master</code>.</p>
|
||
|
||
<pre><code>$ git rebase upstream/master
|
||
First, rewinding head to replay your work on top of it...
|
||
Fast-forwarded master to upstream/master.
|
||
</code></pre>
|
||
|
||
<p>This command applies all the commits from the upstream master to your local
|
||
master.</p></li>
|
||
|
||
<li><p>Check the status of your local branch.</p>
|
||
|
||
<pre><code>$ git status
|
||
On branch master
|
||
Your branch is ahead of 'origin/master' by 38 commits.
|
||
(use &quot;git push&quot; to publish your local commits)
|
||
nothing to commit, working directory clean
|
||
</code></pre>
|
||
|
||
<p>Your local repository now has all the changes from the <code>upstream</code> remote. You
|
||
need to push the changes to your own remote fork which is <code>origin master</code>.</p></li>
|
||
|
||
<li><p>Push the rebased master to <code>origin master</code>.</p>
|
||
|
||
<pre><code>$ git push origin master
|
||
Username for 'https://github.com': moxiegirl
|
||
Password for 'https://moxiegirl@github.com':
|
||
Counting objects: 223, done.
|
||
Compressing objects: 100% (38/38), done.
|
||
Writing objects: 100% (69/69), 8.76 KiB | 0 bytes/s, done.
|
||
Total 69 (delta 53), reused 47 (delta 31)
|
||
To https://github.com/moxiegirl/docker.git
|
||
8e107a9..5035fa1 master -&gt; master
|
||
</code></pre></li>
|
||
|
||
<li><p>Create a new feature branch to work on your issue.</p>
|
||
|
||
<p>Your branch name should have the format <code>XXXX-descriptive</code> where <code>XXXX</code> is
|
||
the issue number you are working on. For example:</p>
|
||
|
||
<pre><code>$ git checkout -b 11038-fix-rhel-link
|
||
Switched to a new branch '11038-fix-rhel-link'
|
||
</code></pre>
|
||
|
||
<p>Your branch should be up-to-date with the <code>upstream/master</code>. Why? Because you
|
||
branched off a freshly synced master. Let&rsquo;s check this anyway in the next
|
||
step.</p></li>
|
||
|
||
<li><p>Rebase your branch from upstream/master.</p>
|
||
|
||
<pre><code>$ git rebase upstream/master
|
||
Current branch 11038-fix-rhel-link is up to date.
|
||
</code></pre>
|
||
|
||
<p>At this point, your local branch, your remote repository, and the Docker
|
||
repository all have identical code. You are ready to make changes for your
|
||
issue.</p></li>
|
||
</ol>
|
||
|
||
<h2 id="where-to-go-next">Where to go next</h2>
|
||
|
||
<p>At this point, you know what you want to work on and you have a branch to do
|
||
your work in. Go onto the next section to learn <a href="../opensource/workflow/work-issue/">how to work on your
|
||
changes</a>.</p>
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Get the required software</title>
|
||
<link>http://localhost/opensource/project/software-required/</link>
|
||
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
||
|
||
<guid>http://localhost/opensource/project/software-required/</guid>
|
||
<description>
|
||
|
||
<h1 id="get-the-required-software-for-linux-or-os-x">Get the required software for Linux or OS X</h1>
|
||
|
||
<p>This page explains how to get the software you need to use a Linux or OS X
|
||
machine for Docker development. Before you begin contributing you must have:</p>
|
||
|
||
<ul>
|
||
<li>a GitHub account</li>
|
||
<li><code>git</code></li>
|
||
<li><code>make</code></li>
|
||
<li><code>docker</code></li>
|
||
</ul>
|
||
|
||
<p>You&rsquo;ll notice that <code>go</code>, the language that Docker is written in, is not listed.
|
||
That&rsquo;s because you don&rsquo;t need it installed; Docker&rsquo;s development environment
|
||
provides it for you. You&rsquo;ll learn more about the development environment later.</p>
|
||
|
||
<h3 id="get-a-github-account">Get a GitHub account</h3>
|
||
|
||
<p>To contribute to the Docker project, you will need a <a
|
||
href="https://github.com" target="_blank">GitHub account</a>. A free account is
|
||
fine. All the Docker project repositories are public and visible to everyone.</p>
|
||
|
||
<p>You should also have some experience using both the GitHub application and <code>git</code>
|
||
on the command line.</p>
|
||
|
||
<h3 id="install-git">Install git</h3>
|
||
|
||
<p>Install <code>git</code> on your local system. You can check if <code>git</code> is on already on your
|
||
system and properly installed with the following command:</p>
|
||
|
||
<pre><code>$ git --version
|
||
</code></pre>
|
||
|
||
<p>This documentation is written using <code>git</code> version 2.2.2. Your version may be
|
||
different depending on your OS.</p>
|
||
|
||
<h3 id="install-make">Install make</h3>
|
||
|
||
<p>Install <code>make</code>. You can check if <code>make</code> is on your system with the following
|
||
command:</p>
|
||
|
||
<pre><code>$ make -v
|
||
</code></pre>
|
||
|
||
<p>This documentation is written using GNU Make 3.81. Your version may be different
|
||
depending on your OS.</p>
|
||
|
||
<h3 id="install-or-upgrade-docker">Install or upgrade Docker</h3>
|
||
|
||
<p>If you haven&rsquo;t already, install the Docker software using the
|
||
<a href="../engine/installation" target="_blank">instructions for your operating system</a>.
|
||
If you have an existing installation, check your version and make sure you have
|
||
the latest Docker.</p>
|
||
|
||
<p>To check if <code>docker</code> is already installed on Linux:</p>
|
||
|
||
<pre><code>$ docker --version
|
||
Docker version 1.5.0, build a8a31ef
|
||
</code></pre>
|
||
|
||
<p>On Mac OS X or Windows, you should have installed Docker Toolbox which includes
|
||
Docker. You&rsquo;ll need to verify both Docker Machine and Docker. This
|
||
documentation was written on OS X using the following versions.</p>
|
||
|
||
<pre><code>$ docker-machine --version
|
||
docker-machine version 0.3.0 (0a251fe)
|
||
|
||
$ docker --version
|
||
Docker version 1.7.0, build a8a31ef
|
||
</code></pre>
|
||
|
||
<h2 id="linux-users-and-sudo">Linux users and sudo</h2>
|
||
|
||
<p>This guide assumes you have added your user to the <code>docker</code> group on your system.
|
||
To check, list the group&rsquo;s contents:</p>
|
||
|
||
<pre><code>$ getent group docker
|
||
docker:x:999:ubuntu
|
||
</code></pre>
|
||
|
||
<p>If the command returns no matches, you have two choices. You can preface this
|
||
guide&rsquo;s <code>docker</code> commands with <code>sudo</code> as you work. Alternatively, you can add
|
||
your user to the <code>docker</code> group as follows:</p>
|
||
|
||
<pre><code>$ sudo usermod -aG docker ubuntu
|
||
</code></pre>
|
||
|
||
<p>You must log out and log back in for this modification to take effect.</p>
|
||
|
||
<h2 id="where-to-go-next">Where to go next</h2>
|
||
|
||
<p>In the next section, you&rsquo;ll <a href="../opensource/project/set-up-git/">learn how to set up and configure Git for
|
||
contributing to Docker</a>.</p>
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Governance</title>
|
||
<link>http://localhost/opensource/governance/</link>
|
||
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
||
|
||
<guid>http://localhost/opensource/governance/</guid>
|
||
<description>
|
||
|
||
<h1 id="governance">Governance</h1>
|
||
|
||
<ul>
|
||
<li><a href="../opensource/governance/dgab-info/">Docker Governance Advisory Board</a></li>
|
||
<li><a href="../opensource/governance/board-profiles/">Board member profiles</a></li>
|
||
<li><a href="../opensource/governance/conduct-code/">Code of conduct</a><br /></li>
|
||
</ul>
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Open Source at Docker</title>
|
||
<link>http://localhost/opensource/</link>
|
||
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
||
|
||
<guid>http://localhost/opensource/</guid>
|
||
<description>
|
||
|
||
<h1 id="open-source-at-docker">Open Source at Docker</h1>
|
||
|
||
<p>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.</p>
|
||
|
||
<ul>
|
||
<li><a href="../opensource/project/who-written-for/">Configure the development environment</a> explains how to setup an environment to contribute to Docker engine.</li>
|
||
<li><a href="../opensource/workflow/make-a-contribution/">Understand the contribution workflow </a> explains the workflow the team uses across most Docker projects.</li>
|
||
<li><a href="../opensource/ways/">Other ways to contribute</a> provides tips for contributing if you dont&rsquo; want to code.</li>
|
||
<li><a href="../opensource/governance/">Governance</a> describes the proper conduct and who defines it.</li>
|
||
</ul>
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Organize a Docker Meetup</title>
|
||
<link>http://localhost/opensource/ways/meetups/</link>
|
||
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
||
|
||
<guid>http://localhost/opensource/ways/meetups/</guid>
|
||
<description>
|
||
|
||
<h1 id="organize-a-docker-meetup">Organize a Docker Meetup</h1>
|
||
|
||
<p>Anyone interested in Docker can become an active member of the Docker community
|
||
by becoming co-organizer of a Docker Meetup group.</p>
|
||
|
||
<p>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.</p>
|
||
|
||
<p>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.</p>
|
||
|
||
<p>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.</p>
|
||
|
||
<h2 id="get-started-putting-on-a-docker-meetup">Get started putting on a Docker Meetup</h2>
|
||
|
||
<p>Now that you are co-organizer of a Docker Meetup Group, here are a few tips and
|
||
suggestions to help you get started:</p>
|
||
|
||
<ul>
|
||
<li>Attend similar DevOps or Developers Meetups to gain experience and gauge interest in Docker</li>
|
||
<li>Contact other people interested in Docker to help you organize and promote future Meetups</li>
|
||
<li>Research High-Tech companies in your area willing to host a Docker Meetup event</li>
|
||
<li>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</li>
|
||
<li>Research what are the topic of interest to your audience prior to set an agenda for the meetup</li>
|
||
<li>Pay attention to the Meetup page aesthetics, add logos and pictures, invite members to leave comments and reply to these comments</li>
|
||
<li>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</li>
|
||
</ul>
|
||
|
||
<h2 id="how-docker-can-help-you-organize">How Docker can help you organize</h2>
|
||
|
||
<p>We can support the co-organizers of the Docker Meetup Groups based on their specific needs. For instance, we might / will be able to:</p>
|
||
|
||
<ul>
|
||
<li>Send you Docker T-shirts and stickers</li>
|
||
<li>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</li>
|
||
<li>Put you in contact with companies willing to host a Docker Meetup in your area</li>
|
||
<li>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</li>
|
||
</ul>
|
||
|
||
<h2 id="host-a-docker-meetup-at-your-location">Host a Docker meetup at your location</h2>
|
||
|
||
<p><img src="../opensource/images/docker-friends.png" alt="Meetup" /></p>
|
||
|
||
<h2 id="want-to-host-a-docker-meetup">Want to host a Docker Meetup?</h2>
|
||
|
||
<p>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</p>
|
||
|
||
<h3 id="how-many-attendees">How many attendees?</h3>
|
||
|
||
<p>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.</p>
|
||
|
||
<h3 id="how-long-is-a-docker-meetup">How long is a Docker Meetup?</h3>
|
||
|
||
<p>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.</p>
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Organize our issues</title>
|
||
<link>http://localhost/opensource/ways/issues/</link>
|
||
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
||
|
||
<guid>http://localhost/opensource/ways/issues/</guid>
|
||
<description>
|
||
|
||
<h1 id="organize-our-issues">Organize our issues</h1>
|
||
|
||
<p>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.</p>
|
||
|
||
<p>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.</p>
|
||
|
||
<h1 id="what-kind-of-issues-can-i-triage">What kind of issues can I triage?</h1>
|
||
|
||
<p>Docker users and contributors create new issues if they want to:</p>
|
||
|
||
<ul>
|
||
<li>report a problem they had with Docker software</li>
|
||
<li>request a new feature</li>
|
||
<li>ask a question</li>
|
||
</ul>
|
||
|
||
<h1 id="how-do-i-triage">How do I triage?</h1>
|
||
|
||
<p>Follow these steps:</p>
|
||
|
||
<ol>
|
||
<li><p>Sign up for a <a href="https://github.com" target="_blank">Github account</a>.</p></li>
|
||
|
||
<li><p>Visit a Docker repository and press the <strong>Watch</strong> button.</p></li>
|
||
</ol>
|
||
|
||
<p>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></p>
|
||
|
||
<p>See <a href="https://github.com/docker" target="_blank">the complete list of
|
||
Docker repositories</a> on GitHub.</p>
|
||
|
||
<ol>
|
||
<li><p>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>.</p></li>
|
||
|
||
<li><p>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.</p></li>
|
||
</ol>
|
||
|
||
<p>The triage process asks you to add both a <code>kind/</code> and a <code>exp/</code> label to each
|
||
issue. Because you are not a Docker maintainer, you add these through comments.
|
||
Simply add a <code>+label</code> keyword to an issue comment:</p>
|
||
|
||
<p><img src="../opensource/images/triage-label.png" alt="Example" /></p>
|
||
|
||
<p>For example, the <code>+exp/beginner</code> and <code>+kind/writing</code> 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></p>
|
||
|
||
<ol>
|
||
<li>Triage another issue.</li>
|
||
</ol>
|
||
</description>
|
||
</item>
|
||
|
||
</channel>
|
||
</rss> |