docs/opensource/governance/dgab-info.md

---
description: Docker Governance Advisory Board
keywords: governance, board, members, explained
title: 'Docker Governance Advisory Board: June 2015 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. This document was
updated to reflect the new membership for 2015.

## 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.

## 2.0 Purpose

The primary purpose of the Docker Governance Advisory Board (DGAB) is to advise
the Docker project leadership (Leadership) on matters related to supporting the
long term governance, structure, and roadmap of the Docker project. The
following main areas are included in this charter:

* Provide a forum for individuals, users, and companies to discuss the issues
  under the DGAB purview (SCOPE)
* Provide guidance and input to Leadership, and where possible, present a
  consistent and consolidated opinion from the broader Docker community
* Produce a formal, twice yearly report to the Leadership and broader Docker
  community of the status of and progress made in all areas under the purview
  of the DGAB.
* Promote and support the use of Docker in manner consistent with Guiding *

### Principles of the project and the Core Criteria

The DGAB is not:

* Intended to serve as a governance board. The DGAB advises, but does not manage, the Docker project leadership
* Intended to replace existing mechanisms for community input, governance, or contribution
* Intended to assume a formal, fiduciary role with respect to the project. The DGAB membership will not be asked to provide funds to the project, assume liabilities with respect to the project or their activities, or assume responsibility for enforcing either trademarks or DGAB recommendations

## 3.0 Scope

The DGAB is expected to provide input and formal recommendations regarding the following areas:

* Docker project long term roadmap
* Docker project policies and procedures around maintenance and contributions
* Docker project policies and procedures around intellectual property, trademark, and licensing
* Core Criteria for Docker-related project (c.f. section 7.0)
* Docker project long term governance model

## 4.0 Meetings and Memberships

### 4.1 General

The DGAB will have 16 members

* The Docker Chief Maintainer: Michael Crosby
* The Docker Chief Operator: Steve Francia
* 2 seats for the top core maintainers (Docker)
* 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

### 4.2 Selection Process

#### Contributors:

Four seats will be granted to the top contributors, as measured
by non-trivial pull requests merged to master in the last 6 months. Trivial
pull requests are typos, minor document corrections, or other items that do not
require a DCO. These seats will be reserved for individual contributors who are
neither employees of Docker, Inc. nor employees of companies that hold a
corporate seat.

#### Corporate seats:

Nomination is restricted to companies for whom all three of
the following are true

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

Any outside party wishing to bring an issue before the DGAB may do so by
emailing the DGAB mailing list

The DGAB shall provide transparent and timely reporting (through any mechanism
it deems appropriate) to the Community at large on all of its activities,
subject to the right of any individual to designate their comments and the
ensuing discussion as "in confidence," in which case the public report shall
contain only a note of the request and an agreed summary (if any) of the
substance.

The DGAB is being formed at the discretion of the Leadership. The Leadership
alone may decide to terminate the DGAB in its sole discretion; provided
however, that the Leadership shall first consult the DGAB Chair.

The DGAB and its members shall abide by appropriate antitrust guidelines.

## 6.0 Open Governance Principles

The DGAB will formulate recommendations in conjunction with the following, open governance principles

### Open participation:

Throughout the project, anyone should be able to participate and contribute.
All bugs and tasks will be tracked in a public tracker and all of the source
code and all of the tools needed to build it will be available under an open
license permitting unrestricted use

### Open technical meritocracy:

Technical merit over pride of authorship. Code
is contributed for the express purpose of advancing technologies relevant to
the project, effectively separating technology advancement from individual or
commercial intent.

### Open design:

Roadmaps are discussed in the open, and design receives input from all
contributors and maintainers Influence through contribution: organizations and
individuals gain influence over the project through contribution

### IP Cleanliness:

Steps are taken to ensure that all incoming code is legally contributed (DCOs
terms-of-use etc.), that use of approved third party libraries does not create
incompatible dependencies, and that all non-trivial commits have DCOs

### Open Licensing:

Code should be licensed using approved, standard, open-source licenses. (Docker is currently licensed under Apache 2.0)

## 7.0 Core Criteria

The DGAB will formulate a set of Core Criteria for projects and commercial
products that use the Docker trademarks

Core Criteria will generally cover such areas as: use of standard APIs,
consistent behaviors expected of Docker containers, trademark guidelines,
provenance, upstream contribution models, and alternative distributions

As Core Criteria will not be fully defined when the initial DGAB membership is
formulated, it is understood that there is a possibility that certain members
of the initial DGAB may not agree with the Core Criteria when they are fully
defined or may have products/offerings that are not in compliance with the Core
Criteria at the time they are finalized. In this case, the corporate members
will either agree to become compliant within a specified timeframe or else
resign their DGAB position.

Please help us improve this draft by sending your comments and feedback to
[governance@docker.com](mailto:governance@docker.com).