• gov

OpenStack Governance Plans and Process

Overview

This document is designed to provide a high-level overview of the organizational structure, role and responsibility descriptions, and guidelines on how OpenStack plans to structure and manage its open source projects. It is the ultimate desire of OpenStack to have a shared, community-driven vision and direction. However, it is equally important to have a structured approach for interfacing with the open source community and integrating resulting contribution with the code base, to provide a framework for corporate and partner involvement, and to specify a mechanism to ensure the original vision and long-term goals of each open source project are preserved.

This document will be continually modified to meet the needs of the OpenStack project. As changes occur, the latest official revision of this document will be available at the project website.

OpenStack's Promises

• The community will be involved in the design process. You can help make this software meet your needs.

• The community will have representation on the technical board, which has the ability to override decisions by the project lead.

• This will always be truly free software. We will never purposefully limit the functionality or scalability of the software to try and sell you an "enterprise" version

• We will always try to be transparent. Important project meetings and communications will be held in public.

Organizational Structure

The diagram above presents an overview of the basic components of OpenStack's Governance.

Each box in the diagram represents a role and not necessarily an individual. As a project grows in size and scope, a role will become an individual or team as necessary to achieve the goals of the project.

OpenStack Advisory Board

The Advisory Board is comprised of Rackspace, Partners and others, whose primary function is to preserve and define the vision of the OpenStack. The Advisory Board includes representation from business, legal, and technical communities.

Advisory Board responsibilities include:

• Provide guidance on the direction of the OpenStack projects

• Advise on issues related to the development of the community
• Act as an advocate for the project externally

Project Lead

The Project Lead for is responsible for assembling the development roadmap and directing the overall direction of the entire project.. The Project Lead will be appointed by Rackspace. The Project Lead has veto rights on all matters that come before the Technical Board. The Project Lead's veto may be overridden by a 2/3 vote of the Technical Board.

The responsibilities of the Project Lead include:

• Define the development roadmap for the project
• Owns the overall vision of the project
• Appoints Component Leads
• Maintain the health of both the community and overall project

Project Technical Board

The Technical Board oversees, defines, and manages overall development practices, policies and processes for the project. The Technical Board will initially consist of seven board members, . Rackspace will appoint two members of the Technical Board

Technical Board responsibilities include:

• Define, direct, and enforce overall workflow guidelines (with flexibility for each component to define workflow specifics as needed)
• Define overall project architecture
• Review sponsor recommendations for substantial contributions as needed
• Review recommended appointments to the Core development team
• Override the veto of the Project Lead, if necessary for the health of the project

Release Manager

The Release Manager oversees the entire release process for major releases, including scheduling, task management, coordination, and reporting to the Technical Board.

The Release Manager has the following responsibilities:

• Manage, enforce, and maintain rules on the release process
• Defines and coordinates schedule and maintains goals for individual releases
• Enforces and manages publication of release notes for each release
• Keeps the Technical Board aware of all issues that affect the release schedule

Development Manager

The Development Manager is the authoritative source of architecture and development across components. Additionally, the Development Manager has the authority to define high-level workflow and manage the development environment across components.

The Development Manager has the following responsibilities:

• Establish and manage the high-level architecture for the project
• Enforces and manages publication of high-level architecture for the project
• Manage, enforce, and maintain rules for workflow and development environment with which the Component Leads must operate
• Keeps the Technical Board aware of all issues that affect the architecture and development processes

Community Manager

The Community Manager organizes and manages the community, performs outreach and recruiting activities to help grow the contributor base or increase general awareness of the project.

The Community Manager has the following responsibilities:

• Responsible for outreach and recruitment
• Responsible for managing dispute resolution
• Represents the developer community on the Technical Board
• Organizes and facilitates community meetings
• Assist in development community groups and structure within the community

Development Team

Development teams are organized around individual architectural components. Each Component is headed by a Component Lead and is made of developers that may or may not be exclusive to that component.

Component Lead

Each Component Lead is the authoritative source of architecture and development processes specific to that component. Additionally, the Component Lead has limited authority to define workflow and manage the development environment, as appropriate to the given component, within the guidelines defined by the Technical Board.

The Component Lead has the following responsibilities:

• Manage the workflow and development environment for the given component
• Ensure compliance with overall guidelines and workflow direction from the Project Lead and Technical Board
• Manage the release schedule for that specific component and ensure it is delivered according to the schedule agreed to by the release team
• Notify the release team of any delays or issues with the component

Core Developers

The Development team of a given component is comprised of Rackspace employees and interested community contributors alike and is directly answerable to the Component Lead. Rackspace employees and community contributors alike may be designated as Developers, as determined by the Technical Board. The basic functions of a Developer are identical to that of an interested contributing member, with one exception: Developers have authority to participate in code reviews.

Core Developer tasks include:

• Provide mentoring for and coordination with contributing members of the development team
• Participate in code reviews of contributions as needed
• Elevate significant contributions to the Component Lead for possible sponsorship and consideration by the Technical Board
• Recommend contributors (whether Rackspace or community contributors) for consideration as Core Developers

Contributors

Contributors comprise all individuals adding value (code, testing, documentation, etc.) to one or more components.

Becoming a Contributor

OpenStack does not require copyright assignment. You are the owner of code you write. It is necessary for us, however, to have you read and agree to a simple Contributor License agreement. This is a simple electronic form that is integrated into our workflow, and a prerequisite for contributing code to the projects Launchpad.net team.

• Fill out an Individual Contributor License agreement. If your contribution is happening on behalf of a company, you should sign a Corporate Contributor License Agreement (if you are covered by a Corporate Contributor License Agreement, you may not need an individual CLA, as long as your contributions flow through the corporation).

• We use Echosign to manage these agreements. After clicking on either agreement linked above, please fill out each required field and digitally sign by simply typing your name in the signature box.

• You'll know we've received it when a copy ends up in your email inbox. You will also appear on the Approved Contributors list

Business Partner

Rackspace business partners are significant and recognized participants in the Project. However, partnership does not confer any special privileges for the business or its employees. All contributors, regardless of their relationship to Rackspace, are held to the same standards and processes. It is critical that the project maintain a community focus and would treat Partner employees as any other member of the community.

Decision making process

In order to provide as open a forum for ideas and innovation as is reasonably and efficiently possible, the preferred decision making process is “lazy consensus”. That is, debate may continue for so long as it is constructive, does not threaten schedule, and appears to be moving toward convergence. Where this is not the case, alternative processes must be used.

On the Technical Board, the Project Lead acts as chair and arbiter, and has final authority for major release process and schedule decisions. Within a Component development team, the Component Lead should foster discussion and consensus, but ultimately has the final authority.