5118d12464
One of the outcomes of the discussion at the leadership training session earlier this year was the idea that the TC should set some community-wide goals for accomplishing specific technical tasks to get the projects synced up and moving in the same direction. This patch includes the proposed process for managing those goals, a template for describing a goal, the placeholder for goals for the Ocata cycle, and a tool for mechanically generating part of the documents. I had help with reviews and drafts of some portions of this text from a bunch of other folks including jroll, dtroyer, johnthetubaguy, spamaps, mordred, ttx, notmorgan, thingee, and amrith. Change-Id: I46cc66eafe9dbcfda94fb6a1a8c66c2ca77de45a Signed-off-by: Doug Hellmann <doug@doughellmann.com>
87 lines
4.0 KiB
ReStructuredText
87 lines
4.0 KiB
ReStructuredText
======================================================
|
|
Requirements for new OpenStack Projects applications
|
|
======================================================
|
|
|
|
Teams in OpenStack can be created as-needed and grow organically.
|
|
By becoming an official OpenStack Project, they place
|
|
themselves under the authority of the OpenStack Technical Committee. In return,
|
|
their contributors get to vote in the Technical Committee election.
|
|
|
|
When considering new projects for addition, the TC will check that:
|
|
|
|
* The project aligns with the OpenStack Mission:
|
|
The project must have a clear and defined scope. It should help further
|
|
the OpenStack mission, by providing a cloud infrastructure service, or
|
|
directly building on an existing OpenStack infrastructure service.
|
|
|
|
* The project follows the OpenStack way ("the 4 opens"):
|
|
|
|
* Open Source:
|
|
|
|
* The proposed project uses an open source license (preferably the Apache
|
|
v2.0 license, since it is necessary if the project wants to be used in
|
|
an OpenStack trademark program)
|
|
* Project must have no library dependencies which effectively restrict
|
|
how the project may be distributed or deployed
|
|
|
|
* Open Community:
|
|
|
|
* The leadership is chosen by the contributors to the project
|
|
* The project has regular public meetings on IRC and those meetings are
|
|
logged and published (moving to official OpenStack meeting channels once
|
|
the project's application is accepted, if they're not held there already)
|
|
* The project shall provide a level and open collaboration playing field
|
|
for all contributors. The project shall not benefit a single vendor, or
|
|
a single vendors product offerings; nor advantage contributors from a
|
|
single vendor organization due to access to source code, hardware,
|
|
resources or other proprietary technology available only to those
|
|
contributors.
|
|
|
|
* Open Development:
|
|
|
|
* The project uses public code reviews on the OpenStack infrastructure
|
|
* The project has core reviewers and adopts a test-driven gate in the
|
|
OpenStack infrastructure for changes
|
|
* The project provides liaisons that serve as contacts for the work of
|
|
cross-project teams in OpenStack
|
|
* Where it makes sense, the project cooperates with existing projects
|
|
rather than gratuitously competing or reinventing the wheel
|
|
* Where appropriate, the project adopts technology and patterns
|
|
used by existing OpenStack projects
|
|
|
|
* Open Design:
|
|
|
|
* The project direction is discussed at the Design Summit and/or on
|
|
public forums
|
|
* The project uses the openstack-dev ML to discuss issues
|
|
|
|
* The project ensures basic interoperability with the rest of OpenStack:
|
|
User-facing API services should support Keystone for discovery and
|
|
authentication.
|
|
|
|
* The project should have an active team of one or more contributors
|
|
|
|
* The project participates in any goals specified by the TC, as
|
|
defined by :ref:`release-cycle-goals`. Any existing goals that are
|
|
not met should be prioritized and completed within the first year of
|
|
a team joining.
|
|
|
|
* The project meets any policies that the TC requires all projects to
|
|
meet. For instance, the :doc:`project-testing-interface`
|
|
|
|
In order to do an evaluation against this criteria, the TC expects the project
|
|
to be set up and have some history to evaluate. A few months of operating and
|
|
following these project requirements is a rough guideline for how long
|
|
to wait before applying to be approved by the TC.
|
|
|
|
Once a project has joined OpenStack, it may create additional source code
|
|
repositories as needed at the discretion of its Project Team Lead (PTL) without
|
|
prior approval from the TC as long as the additional source code repositories
|
|
fall within the scope of the approved project mission statement.
|
|
|
|
Official project teams are expected to participate in all `elections`_ held
|
|
after the team is accepted as official, regardless of how recently the team
|
|
leadership may have been established.
|
|
|
|
.. _elections: http://docs.openstack.org/project-team-guide/open-community.html#technical-committee-and-ptl-elections
|