openinfra/interop
Code Issues Proposed changes

Fix typos and language (as discovered in DefCore midcycle)

Browse Source 
Cleaned up formatting and made use of test/core go away
in favor of capability/DefCore in this document.

Also removed must-pass in favor of required.

Change-Id: I2431ba0483e23b268c1d5533906aa500b8bc1901
This commit is contained in:
robhirschfeld 2015-07-30 11:17:05 -05:00 committed by Mark T. Voelker
parent 885620f185
commit dea7b57ae7
1 changed files with 33 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

62
doc/source/process/CoreCriteria.rst
View File

@ -13,13 +13,13 @@ This is a subcomponent of the larger `Core Definition
Core Capability Selection uses 12 criteria grouped into four primary
categories:
1. Usage: the capability is widely used (Refstack will collect data)
2. Direction: the capability advances OpenStack technically
3. Community: the capability builds the OpenStack community experience
4. System: the capability integrates with other parts of OpenStack
:Usage: the capability is widely used (Refstack will collect data)
:Direction: the capability advances OpenStack technically
:Community: the capability builds the OpenStack community experience
:System: the capability integrates with other parts of OpenStack
These categories summarize critical values that we want in OpenStack and so
make sense to be the primary factors used when we select core capabilities.
make sense to be the primary factors used when we select DefCore capabilities.
While we strive to make the DefCore process objective and quantitive, we
must recognize that these choices drive community behavior.
@ -30,35 +30,36 @@ must recognize that these choices drive community behavior.
Details
=======
With this perspective, let's review the selection criteria. To make it
easier to cross reference, we've given each criteria a shortened name:
With this perspective, here are the selection criteria.
*To make cross reference easier, criteria are given a shortened name.*
SHOWS PROVEN USAGE
------------------
* "Widely Deployed" Candidates are widely deployed capabilities. We favor
* **"Widely Deployed"** Candidates are widely deployed capabilities. We favor
capabilities that are supported by multiple public cloud providers and
private cloud products.
* "Used by Tools" Candidates are widely used capabilities:Should be
* **"Used by Tools"** Candidates are widely used capabilities:Should be
included if supported by common tools (RightScale, Scalr, CloudForms,
...)
* "Used by Clients" Candidates are widely used capabilities: Should be
* **"Used by Clients"** Candidates are widely used capabilities: Should be
included if part of common libraries (Fog, Apache jclouds, etc)
ALIGNS WITH TECHNICAL DIRECTION
-------------------------------
* "Future Direction" Should reflect future technical direction (from the
* **"Future Direction"** Should reflect future technical direction (from the
project technical teams and the TC) and help manage deprecated
capabilities.
* "Stable" Test is required stable for >2 releases because we don't want
core capabilities that do not have dependable APIs.
* **"Stable"** Capabilities are required to be stable for >2 releases because
we do not want DefCore capabilities that do not have dependable APIs.
* "Complete" Where the code being tested has a designated area of alternate
implementation (extension framework) as per the Core Principles, there
* **"Complete"** Where the code being tested has a designated area of alternate
implementation (extension framework) as per the DefCore Principles, there
should be parity in capability tested across extension implementations.
This also implies that the capability test is not configuration specific
or locked to non-open technology.
@ -66,29 +67,32 @@ ALIGNS WITH TECHNICAL DIRECTION
PLAYS WELL WITH OTHERS
----------------------
* "Discoverable" Capability being tested is Service Discoverable (can be
* **"Discoverable"** Capability being tested is Service Discoverable (can be
found in Keystone and via service introspection)
* "Doc'd" Should be well documented, particularly the expected behavior.
* **"Doc'd"** Should be well documented, particularly the expected behavior.
This can be a very subjective measure and we expect to refine this
definition over time.
* "Core in Last Release" A test that is a must-pass test should stay a
must-pass test. This make makes core capabilities sticky release per
release. Leaving Core is disruptive to the ecosystem
* **"DefCore in Last Release"** A required capability should stay a required
capability. This make makes DefCore capabilities sticky
release per release. Leaving DefCore is disruptive to the ecosystem
TAKES A SYSTEM VIEW
-------------------
* "Foundation" Test capabilities that are required by other must-pass tests
and/or depended on by many other capabilities
* **"Foundation"** Capabilities that are required by other required
capabilities and/or depended on by many other capabilities
* "Atomic" Capabilities is unique and cannot be build out of other
must-pass capabilities
* **"Atomic"** Capability is unique and cannot be built out of other
required capabilities
* "Proximity" (sometimes called a Test Cluster) selects for Capabilities
that are related to Core Capabilities. This helps ensure that related
capabilities are managed together.
* **"Proximity"** (sometimes called a Capability Cluster) selects for
capabilities that are related to DefCore capabilities. This helps ensure
that related capabilities are managed together.
Note: The original 13th "non-admin" criteria has been removed because Admin
APIs cannot be used for interoperability and cannot be considered Core.
NON-ADMIN
---------
The original 13th "non-admin" criteria has been removed because Admin
APIs cannot be used for interoperability and are not considered DefCore.