From fcc9b0e8a3bb8971abec7b78057929df7c544cf8 Mon Sep 17 00:00:00 2001 From: Doug Hellmann Date: Wed, 17 Aug 2016 16:36:42 -0400 Subject: [PATCH] propose approval policy for goal responses Change-Id: Ifb6cf2cd87621f6b043031013d7aec8bbf524ac6 Signed-off-by: Doug Hellmann --- README.rst | 4 ++++ reference/house-rules.rst | 23 +++++++++++++++++++++++ 2 files changed, 27 insertions(+) diff --git a/README.rst b/README.rst index 7224de9ec..2c9f18968 100644 --- a/README.rst +++ b/README.rst @@ -11,5 +11,9 @@ Directory structure: can be expressed as a resolution. Those must be named YYYYMMDD-short-name with YYYYMMDD being the proposal date in order to allow basic sorting. + goals/ + Documentation for OpenStack community-wide goals, organized by + release cycle. These pages will be updated with project status + info over time, and if goals are revised. See https://wiki.openstack.org/wiki/Governance/TechnicalCommittee for details. diff --git a/reference/house-rules.rst b/reference/house-rules.rst index 7a6e3b2eb..fa09ce324 100644 --- a/reference/house-rules.rst +++ b/reference/house-rules.rst @@ -47,6 +47,29 @@ In corner cases where the change is time-sensitive (like a deliverable reorganization which blocks a release request), the chair may fast-track the change, but should report on that exception at the next TC meeting. +Goal Updates from PTLs +---------------------- + +PTLs will acknowledge community-wide goals at the start of each cycle +by providing links to artifacts for tracking the work, or an +explanation of why work is not going to be done. They will also +provide references to completion artifacts at the end of each cycle +for goals where work was needed. These patches should be reviewed by +TC members for completeness and clarity (is enough information +provided for interested parties to track the work, or is the +justification for not doing work clear enough). + +The patches to add team acknowledgments, planning artifacts, and +completion artifacts to the goal document do not need to go through +the formal vote process, and so lazy consensus rules will be used. If +there is no objection posted one week after the most recent version of +a change is proposed, then the change can be approved by the chair. + +If a TC member feels that one of these responses needs to be discussed +by the entire TC, they should place it on the agenda for an upcoming +meeting and the change should not be approved until after the +discussion is completed. + Rolling back fast-tracked changes ---------------------------------