interop/doc/source/process/Lexicon.rst
Mark T. Voelker d8fb682a2b Change doc references to DefCore
At the Board of Directors meeting on April 24, 2016 the Board of
Directors indicated that as DefCore has evolved it's focus on
interoperability and it's working structure, it's name may be a source
of some confusion to those outside of the community or who are new to
the community.  The Board made an informal request that the DefCore
Committee consider changing it's name to more clearly reflect it's focus
and structure.

This patch is the first step in that process.  It updates references
in various documents to change the name "DefCore Committee" to
"Interop Working Group" as agreed at the summer 2016 DefCore Committee
Sprint [1].

It should be noted that this patch should be considered a work in
progress to generate discussion until the new name is approved by
the DefCore Committee and the Board of Directors.  Should we elect
to go forward with the new name, some other actions will also need
to be taken, including but not limited to:

1. We will need to consider updating references on the OpenStack wiki.
2. We will need to consider updating the name of our IRC channel,
   mailing list, Launchpad project, and git repository.  Most of these
   changes will need to be carefully coordinated with the OpenStack
   Infrastructure team.
3. We will need to take into account external resources that point to
   DefCore artifacts, such as Foundation-maintained websites (such as:
   http://www.openstack.org/interop ).
4. We will need to coordinate with RefStack to minimize impact.
5. We will need to clearly communicate the name change to the rest of the
   community.

Note also that I've intentionally left many historical documents that
have been superceded (such as the 2015A process docs, Guidelines that
are no longer used, etc) in tact.  There seemed little value in
spending time on them and cluttering the patch with them since they're
now obsolete.

[1] https://etherpad.openstack.org/p/DefCoreSummer2016Sprint

Change-Id: I79d337c193e75c54d49f1d847468f6347e2ef2b3
2017-01-23 21:25:05 -05:00

4.2 KiB
Raw Blame History

OpenStack Interop Working Group Lexicon

Licensing the OpenStack commercial-use marks requires passing tests of required capabilities, and including designated sections of code. There are multiple marks available for vendors depending on which capability groupings are passed.

TERMS:

Advisory

Capabilities that have been suggested for the next Guideline.

Capability

The functionality ensured by a set of tests collected into a group as defined by the Interop Working Group.

Certify or Accredit

The Interop Working Group does not do any of these things for OpenStack clouds. These actions would fall under the governance of the Foundation trademark policy.

Community

The universe of people and companies that are involved in the OpenStack project as active contributors, users, operators, vendors and enthusiasts. This is a very broad group with diverse interests, needs and participation levels. (see also Participant)

Component

A collection of functionality generally used together (e.g.: object, compute).

Contributor

Word to be avoided in this process due to confusion with other uses.

Core

Word to be avoided in this process due to confusion with other uses.

DefCore

The original name for the OpenStack board committee that managed commercial definition of OpenStack for trademark purposes. As the group evolved, it's name was eventually changed to the Interop Working Group.

Deprecated

Capabilities that will be removed in the next Guideline.

Designated Sections

Portions of the OpenStack codebase that must be used to provide required capabilities in a product wishing to use the OpenStack trademark. Designated sections fulfill one or more of the following criteria: they provide the project-external REST API, or are shared and provide common functionality for all options, or implement logic that is critical for cross-platform operation. Designated sections must exist in the OpenStack gerrit namespace and have corresponding tests. Code that meets the following criteria will not be considered designated: provides vendor-specific functionality, are explicitly intended by the project maintainers to be replaceable, extend the project REST API in a new or different way, or code that is being deprecated.

Flagged Test

A test that does not provide consistent results in the field and it not required for vendor self-test.

Guidelines

Output of the Interop Working Group process detailing which Designated Sections and Capabilities are required. Guidelines will be approved on a regular cadence and identified by the date of approval.

Interop Working Group Process

The process used by the Interop Working Group to score Capabilities and select Criteria.

OpenStack Mark

Right granted by the OpenStack Foundation to use the name and logo of OpenStack in a vendors product.

Participant

The subset of the Community that actively engages in creating components of OpenStack including, but not limited to, the code, documentation, training, product management and other materials. For Interop Working Group purposes, Participant is not limited to the community members identified as "ATC" as per http://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst#n132 (see also Technical Leadership)

Platform

The collection of components required to use the least restricted mark.

Removed

Capabilities that are no longer required and are not included in the current Guideline.

Required - Capabilities that are required to be exposed to end users to

satisfy the requirements of an Interoperability Guideline.

Self-test

Process by which a vendor runs tests against their product or service without 3rd party observation.

Technical Leadership

The subset of the Participants (see above) that are recognized by the community to guide the technical direction of the OpenStack project. These leaders include the Technical Committee (TC) and Project Technical Leads (PTL). See: http://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst

Test

Program that exercises functionality of a component to validate expected behavior and provides pass or fail judgement.