From 85d1e5a5d6d4a192c46a22ad58dea758f0bc29a6 Mon Sep 17 00:00:00 2001 From: "Mark T. Voelker" Date: Mon, 30 Mar 2015 13:20:31 -0400 Subject: [PATCH] Clarify JSON vs RST authority During the initial drafting of the 2015A guidelines, we had a healthy discussion of whether the text (RST) or JSON version of the capabilities guidelines should be authoritative, and what the roles of the DefCore Committee and Board of Directors was intended to be.[1][2] Further iterations on the matter were deferred to a seperate patch in order to establish a base version of the 2015A process to iterate on before it moves from "Draft" status to "Approved" status. This patch adjusts the wording of a couple of sections of the 2015A spec in accordance to what I beleive was the outcome of those discussions. The patch clarifies that the Board approves an intended set of capabilities listed in the RST file, and the DefCore Committee is then tasked with managing the definitions of those capabilities in the JSON file (with some limitations to prevent dramatic changes since the Review period) without the need for Board re-approval. The patch also clarifies that after approval, the Committee has the ability to flag tests (presumably in response to vendor grievances) but can't add additional tests within the same guideline. [1] https://review.openstack.org/#/c/165216/4/process/2015A.rst [2] https://etherpad.openstack.org/p/DefCoreScale.9 Change-Id: I5381099fcb505ca6fb92f96f3a5d61c810f6a569 --- process/2015A.rst | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/process/2015A.rst b/process/2015A.rst index c6451a0d..db3642ee 100644 --- a/process/2015A.rst +++ b/process/2015A.rst @@ -71,6 +71,10 @@ A2. Community Groups Tests into Capabilities 3. Tests must have unique identifiers that are durable across releases and grouping changes to be considered. 4. Tests must be under OpenStack governance. + 5. The DefCore committee will provide the test groupings in JSON format + for automated scoring. + 6. The DefCore committee will provide a human-readable summary of + the guideline generated from the JSON test grouping. A3. PTLs Recommend Changes to Designated Sections @@ -205,15 +209,18 @@ D1. Board will review and approve DefCore Guideline from draft 1. Guidelines are set at the Platform, Component and Capability level only. - 2. Text guideline document is authorative over the JSON representation. - 3. DefCore will provide JSON representation for automated scoring + 2. The DefCore Committee will submit the human-readable summary of + capabilities (see section A2[6]) to the Board for approval. + 3. By voting to approve the summary, the Board delegates responsibility + for maintaining test groupings to the DefCore committee subject to + the limitations described in section D2. 4. Guidelines only apply to the identified releases (a.k.a. release tags). D2. DefCore Committee has authority on test categorization 1. Can add flagged tests before and after Guideline approval. - 2. Cannot change Test to Capability mappings after approval. + 2. Cannot add additional Tests to Capability mappings after approval. 3. Maintains the test to capability mappings in the JSON representation. D3. Designated sections only enforced for projects with required capabilities