interop/doc/source/process/DesignatedSections.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

78 lines
2.1 KiB
ReStructuredText
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

===================
Designated Sections
===================
.. contents::
Designated Sections Illustration
================================
.. image:: ../images/Defcore_designated_sections.png
Designated Sections Selection Guidance
======================================
::
_Approved 2014 Dec 2_
The Interop Working Group identified 10 selection criteria. The first
seven are technical from the TC and last three allow the Board to resolve
issues without needing a technical judgement.
1. Designated if the code provides the project external REST API
2. Designated if the code is shared and provides common functionality for
all options
3. Designated if the code implements logic that is critical for
cross­platform operation
4. NOT Designated if project design explicitly intended this section to be
replaceable
5. NOT Designated if code extends the project external REST API in a new or
different way
6. NOT Designated if code is being deprecated
7. NOT Designated if code interfaces to vendor­specific functions
8. NOT Designated by Default
1. Unless code is designated, it is assumed to be undesignated.
2. This aligns with the Apache license.
3. We have a preference for smaller core.
9. Designated by Consensus
1. If the community cannot reach a consensus about designation then it
is considered undesignated.
2. Time to reach consensus will be short: days, not months
3. Except obvious trolling, this prevents endless wrangling.
4. If theres a difference of opinion then the safe choice is
UNdesignated.
10. Designated is Guidance
1. Loose descriptions of designated sections are acceptable.
2. The goal is guidance on where we want upstream contributions not a
code inspection police state. Guidance will be revised per release
as part of the Interop Working Group process.
Designated Sections
===================
Effective April 2015, approved Designated Sections are maintained
in the Board approved Interoperability Guidelines. The 2015.03 Guideline
was set to match the Board action of 2014 December 2.
Please see the current Guidelines to determine which Designated
Sections apply.