Adjust definitions of clients and tools

Originally, the definitions we have for the "used by clients" and "used
by tools" Criteria were such that both dealt primarily with software
outside of the OpenStack community.  For example, the definition of
"clients" included mention of jClouds and Fog.  The definition of "tool"
mentions RightScale, Scalr, and CloudForms.  In practice what we've
found over the first few cycles in which adherance to DefCore Guidelines
is required is that we often find issues with Capabilities because
there is poor client support for a major API version within the
OpenStack community itself.  For example, the Keystone v3 API was
originally introduced in Grizzly [1] but python-neutronclient didn't
support v3 until version 2.3.7 in late 2014 (in the Juno timeframe). [2]
Nova still uses the Glance v1 API as of Kilo.  We therefore have an
interest in making it explicitly clear that acceptance of an API by
other OpenStack projects is a consideration for a Capability to become
part of a Guideline.  If an API hasn't achieved acceptance by other
OpenStack projects that will likely be used in the same deployment but
an older version of the API has, we should favor requiring the older
version.

We've also seen general sentiment that our audience tends to see the
distinction between our current definitions of "tools" and "clients" as
not terribly useful in that both definitions essentially state that the
Capability in question must be accepted by the world outside of
OpenStack itself.  Drawing a distinction between outside tools and
outside clients gives somewhat of a "double weight" to whether a
Capability has gained acceptance in the broader world, and these scores
almost inevitably end up being the same anyway.  A more useful
distinciton appears to be drawing the line at what's accepted by the
rest of the OpenStack projects and what's accepted by the world outside
of OpenStack.

This patch updates the two defintions to essentially do that.  It alters
the definition of "tools" to include software outside of OpenStack's
control, and the definiton of "clients" to include other OpenStack
projects (and add a note about API versioning for clarity).  These
changes essentially provide separate weighting for acceptance of a
capability inside of OpenStack and by the outside world.

These changes will be used starting with scoring activities for the
2016.07 Guideline.

[1]
https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly#OpenStack_Identity_.28Keystone.29
[2]
https://blueprints.launchpad.net/python-neutronclient/+spec/keystone-api-v3-support
[3]

Change-Id: I7aa9077be458e688cf4c417233fb7b7611e84cd9

doc/source/process/CoreCriteria.rst

@@ -41,12 +41,16 @@ SHOWS PROVEN USAGE
   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 Tools"** Candidates are widely used capabilities: Should be
+  included if supported by common tools outside of the OpenStack community
+  (RightScale, Scalr, CloudForms, jClouds, Fog, etc...)
 
 * **"Used by Clients"** Candidates are widely used capabilities: Should be
-  included if part of common libraries (Fog, Apache jclouds, etc)
+  included if called by common OpenStack clients (openstackclient,
+  neutronclient, novaclient, etc) if necessary.  This Criteria pertains
+  mostly to API versioning.  For example: if v2 of a given API is not used
+  by other OpenStack clients but v1 is, then v2 doesn't achieve the "used
+  by clients" Criteria.
 
 ALIGNS WITH TECHNICAL DIRECTION
 -------------------------------