interop/doc/source/process/ProcessCycles.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.5 KiB

Process Cycles

Defining OpenStack Core is a long term process and we are doing the work in progressive cycles. For reference, we have named the cycles. This helps describe concrete deliverables for a cycle while allowing discussion of the broader long term issues. For example, we may say that "item X is important to interoperability but out of scope for Elephant." We have found that this approach to breaking down the problem is necessary to maintain community consensus because we are taking smaller bites of the larger challenge (aka eating the elephant).

Spider (Fall 2013)

Objectives

  • Find a consensus approach to moving forward on DefCore
  • Define process by which Core will be defined

Elephant (Spring 2014)

Objectives

  • If needed, change the bylaws to reflect the Spider Core Principles
  • Establish the "must-pass" tests, processes and tools
  • Define tests that will be used to determine core based on Spider cycle work
  • Lower the water in the discussion to expose broader issues
  • Clearly identity "elephants" that we are not ready to resolve in this cycle

Meetings

Lighthouse (Fall 2014)

Objectives

  • Complete Capabilities Score for Havana (Advisory), Icehouse and Juno
  • Recommend by-laws changes for winter voting
  • Launch refstack site for data collection and sharing

Meetings

Scale Cycle (Spring 2015)

Objectives

  • Capabilities for I & J
  • Process approved by TC & Board

Process Meetings

Capabilities Meetings

Flag Cycle (Spring - Summer 2015)

Objectives

  • Improve and clearly document the test flagging process.
  • Ensure that DefCore/RefStack can include tests that are not run via Tempest.
  • Determine a path forward for components with overlapping capabilities (such as networking).

Meetings

Meeting information for the Flag cycle will be archived here once the cycle is complete. During the cycle, please refer to the Interop WG wiki page.

Future

Names to be decided when we get there. Topics that are intentionally pushed into the future:

  • OpenStack API Mark