Move Governance/CoreCriteria into gerrit

At the April 8, 2015 DefCore Scale.11 meeting, the DefCore committee
decided to migrate some existing wiki artifacts into
gerrit.  This patch represents one such migration.  This patch
reproduces content previously housed at the following URL in RST
so that it can be placed more easily in source control:

https://wiki.openstack.org/wiki/Governance/CoreCriteria

One trivial formatting change has been made to best accommodate the new
RST format: the page title has been changed from the old wiki-enforced
heading "Governance/CoreCriteria" to the more plain-English equivalent
"Core Criteria".  Aside from this change, the text of the document is
completely unaltered from it's state in the wiki on the day this patch
was submitted.

Change-Id: I60b679e909d961c0c66de0035d7bd010abdb36ad

CoreCriteria.rst

@@ -0,0 +1,94 @@
+=============
+Core Criteria
+=============
+
+.. contents::
+
+General
+=======
+
+This is a subcomponent of the larger `Core Definition
+<./CoreDefinition.rst>`_ documentation.
+
+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
+
+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.
+While we strive to make the DefCore process objective and quantitive, we
+must recognize that these choices drive community behavior.
+
+.. figure:: images/Defcore_capabilities_criteria.png
+
+   Graphic showing Capabilities Seleciton Criteria
+
+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:
+
+SHOWS PROVEN USAGE
+------------------
+
+* "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
+  included if supported by common tools (RightScale, Scalr, CloudForms,
+  ...)
+
+* "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
+  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.
+
+* "Complete" Where the code being tested has a designated area of alternate
+  implementation (extension framework) as per the Core 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.
+
+PLAYS WELL WITH OTHERS
+----------------------
+
+* "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.
+  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
+
+TAKES A SYSTEM VIEW
+-------------------
+
+* "Foundation" Test capabilities that are required by other must-pass tests
+  and/or depended on by many other capabilities
+
+* "Atomic" Capabilities is unique and cannot be build out of other
+  must-pass 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.
+
+Note: The original 13th "non-admin" criteria has been removed because Admin
+APIs cannot be used for interoperability and cannot be considered Core.