Docker Governance Advisory Board: June 2015 version

Estimated reading time: 8 minutes

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
  2. Have employees as maintainers and/or make significant contributions to the code base
  3. 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.

chat icon Feedback? Suggestions? Can't find something in the docs?
Edit this page ● Request docs changes ● Get support
Rate this page: