Jump to: navigation, search

Difference between revisions of "Governance/InteropWG"

m
(Add lighthouse)
Line 1: Line 1:
 
This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.
 
This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.
 +
 +
''DefCore sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''
  
 
Our mission is to define "OpenStack Core" as chartered by the by-laws and guided by [[Governance/CoreDefinition]]
 
Our mission is to define "OpenStack Core" as chartered by the by-laws and guided by [[Governance/CoreDefinition]]
 +
 +
== Important Artifacts ==
 +
# Terms Definition: [[Governance/DefCoreLexicon]]
 +
# 10 Core Principles: [[Governance/CoreDefinition]]
 +
# 12 Scoring Criteria: [[Governance/CoreCriteria]]
  
 
== Objective / Scope ==
 
== Objective / Scope ==
Line 87: Line 94:
 
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 DefCore 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).  
 
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 DefCore 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 (previous, Fall 2013) ===
+
=== Spider (Fall 2013) ===
 
Objectives
 
Objectives
 
# Find a consensus approach to moving forward on DefCore
 
# Find a consensus approach to moving forward on DefCore
 
# Define process by which Core will be defined
 
# Define process by which Core will be defined
  
=== Elephant (current, Spring 2014) ===
+
=== Elephant (Spring 2014) ===
 
Objectives:
 
Objectives:
 
# If needed, change the bylaws to reflect the Spider Core Principles  
 
# If needed, change the bylaws to reflect the Spider Core Principles  
Line 99: Line 106:
 
# Lower the water in the discussion to expose broader issues
 
# Lower the water in the discussion to expose broader issues
 
## Clearly identity "elephants" that we are not ready to resolve in this cycle
 
## Clearly identity "elephants" that we are not ready to resolve in this cycle
==== Elephant Etherpads ====
+
 
https://etherpad.openstack.org/p/DefCoreElephant.2<br/>
+
# https://etherpad.openstack.org/p/DefCoreElephant.2<br/>
https://etherpad.openstack.org/p/DefCoreElephant.3<br/>
+
# https://etherpad.openstack.org/p/DefCoreElephant.3<br/>
https://etherpad.openstack.org/p/DefCoreElephant.4<br />
+
# https://etherpad.openstack.org/p/DefCoreElephant.4<br />
https://etherpad.openstack.org/p/DefCoreElephant.5<br/>
+
# https://etherpad.openstack.org/p/DefCoreElephant.5<br/>
 +
 
 +
=== Lighthouse (Fall 2014) ===
 +
Objectives:
 +
# Complete Capabilities Score for Havana (Advisory), Ice House and Juno
 +
# Recommend by-laws changes for winter voting
 +
# Launch refstack site for data collection and sharing
  
 
=== Future ===
 
=== Future ===
 
Names to be decided when we get there.
 
Names to be decided when we get there.
Topics ("Elephants") that are intentionally pushed into the future:
+
Topics that are intentionally pushed into the future:
* OpenStack Compatible Mark
+
* OpenStack API Mark
* ... Committee Chairs will add to this ...
 
 
 
== Meetings/Agenda Schedule ==
 
 
 
* 11/20 [[Governance/CoreDefinition/Meeting20131120]]
 
* 12/03 [[Governance/CoreDefinition/Meeting20131203]]
 
* 12/10 Criteria Subcommittee
 
* 12/17 1:30 PST [[Governance/CoreDefinition/Meeting20131217]]
 
** OIN impacts from Core/Commons definition
 
** How to figure out where we have gaps in Tempest coverage
 
** Program vs Project Definition Discussion
 
** Define a process by which programs are nominated for use with the mark by which tests certified for use with the mark test list is vetted and approved by the board
 
* 12/30 1:30 PST Criteria Subcommittee Meeting
 

Revision as of 02:36, 20 May 2014

This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.

DefCore sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."

Our mission is to define "OpenStack Core" as chartered by the by-laws and guided by Governance/CoreDefinition

Important Artifacts

  1. Terms Definition: Governance/DefCoreLexicon
  2. 10 Core Principles: Governance/CoreDefinition
  3. 12 Scoring Criteria: Governance/CoreCriteria

Objective / Scope

The DefCore charter is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.

There are three ways in which the community uses the OpenStack brand including referring to projects.

  1. General community use of the mark
  2. Project-specific use associated with development activity
  3. DefCore-governed commercial use

While the top two of these uses are out of scope for DefCore, the committee has a need to participate in the discussion to ensure consistent and clear use.

Current Committee Participants

Defcore committee (board members)

  • Rob H. (Co-chair)
  • Josh M. (Co-chair)
  • Alan Clark
  • Sean Roberts
  • Troy Toman
  • Randy Bias
  • Eileen Evans
  • Lew Tucker
  • Mark McLoughlin
  • Van Lindberg
  • John Zannos


Defcore participants (non-board member)

  • Anne Gentle
  • Jonathan Bryce
  • Mark Radcliffe
  • Mark Collier
  • Michael Still
  • Rochelle Grober


Criteria Subcommittee

  • Rob H.
  • Josh M.
  • John Zannos
  • Rochelle Grober
  • Troy Toman


Legal subcommittee

  • Eileen Evans
  • Mark Radcliffe


Former / Inactive committee participants / member

  • Nicolas Barcet
  • Monty Taylor
  • Russell Bryant
  • Simon Anderson
  • Todd Moore


How to Engage?

  • Read the (pending) white paper and (pending) watch the video about DefCore.
  • Join the [defcore-committee] list
  • Join #refstack on Freenode IRC
  • Follow PlanetOpenStack DefCore Tag (instructions pending)
  • Follow the code at https://github.com/stackforge/refstack
  • Register your user and then upload your test results to RefStack.org (instructions pending)

RefStack

RefStack is a way of collecting and comparing test results that support the core definition process.

Details on using RefStack

Governance Process

  • Meetings will be interactive using Google Hangouts (we will already stream for non-committee members)
  • Members are expected to to their homework. We will _not_ be rehashing due to time limits.
  • Meetings will work from resolutions that are proposed in advance with +/- voting (cochairs are +/-2)
    • as per Board of Directors policy, we welcome broad engagement but cannot allow proxies on resolutions
    • resolution +/- could be asserted before the meeting (but may have to be overruled based on discussion)

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 DefCore 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

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

Elephant (Spring 2014)

Objectives:

  1. If needed, change the bylaws to reflect the Spider Core Principles
  2. Establish the "must-pass" tests, processes and tools
    1. Define tests that will be used to determine core based on Spider cycle work
  3. Lower the water in the discussion to expose broader issues
    1. Clearly identity "elephants" that we are not ready to resolve in this cycle
  1. https://etherpad.openstack.org/p/DefCoreElephant.2
  2. https://etherpad.openstack.org/p/DefCoreElephant.3
  3. https://etherpad.openstack.org/p/DefCoreElephant.4
  4. https://etherpad.openstack.org/p/DefCoreElephant.5

Lighthouse (Fall 2014)

Objectives:

  1. Complete Capabilities Score for Havana (Advisory), Ice House and Juno
  2. Recommend by-laws changes for winter voting
  3. Launch refstack site for data collection and sharing

Future

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

  • OpenStack API Mark