Separate goal definition from goal selection

As discussed at the PTG in Denver, one issue of the current
goal selection process is that it conflates definition of the
goal (which is ideally an iterative process) with selection of
a specific goal for a series, in a single review.

This has made it hard to process goal reviews in the past,
especially considering we need to select the set of goals
(as collectively feasibale together in a single cycle), and
not select them individually.

This change proposed to set up a three phase process. Wishlist
goals that do not have a champion ready to drive them yet should
live in the backlog etherpad. Once goals have a champion, those can
iterate through goal definition in a specific "proposed" directory.
Finally, when time comes for us to select goals for a specific
series, we can propose a set of goals in a single review (by
proposing a set of moves from the proposed repository to the
selected/series repository).

This should hopefully address the review issues that have been
plaguing the goal definition and selection process in the past, as
well as let us vote on a selection of goals using Gerrit, rather
than try (and fail) to rely on out-of-band mechanisms.

Change-Id: I9e00a0d9c3eb91ec6b1048c773d84032d3ce9f0e

doc/source/_extra/.htaccess

@@ -1,3 +1,9 @@
 redirect 301 /tc/reference/top-5-help-wanted.html /tc/reference/upstream-investment-opportunities/2018/index.html
 redirect 301 /tc/reference/help-most-needed.html /tc/reference/upstream-investment-opportunities/2018/index.html
 redirect 301 /tc/resolutions/2018-03-19-sig-governance.html /tc/resolutions/20180319-sig-governance.html
+redirect 301 /tc/goals/ocata/ /tc/goals/selected/ocata/
+redirect 301 /tc/goals/pike/ /tc/goals/selected/pike/
+redirect 301 /tc/goals/queens/ /tc/goals/selected/queens/
+redirect 301 /tc/goals/rocky/ /tc/goals/selected/rocky/
+redirect 301 /tc/goals/stein/ /tc/goals/selected/stein/
+redirect 301 /tc/goals/train/ /tc/goals/selected/train/

doc/test/redirect-tests.txt

@@ -1,3 +1,9 @@
 /tc/reference/top-5-help-wanted.html 301 /tc/reference/upstream-investment-opportunities/2018/index.html
 /tc/reference/help-most-needed.html 301 /tc/reference/upstream-investment-opportunities/2018/index.html
 /tc/resolutions/2018-03-19-sig-governance.html 301 /tc/resolutions/20180319-sig-governance.html
+/tc/goals/ocata/ 301 /tc/goals/selected/ocata/
+/tc/goals/pike/ 301 /tc/goals/selected/pike/
+/tc/goals/queens/ 301 /tc/goals/selected/queens/
+/tc/goals/rocky/ 301 /tc/goals/selected/rocky/
+/tc/goals/stein/ 301 /tc/goals/selected/stein/
+/tc/goals/train/ 301 /tc/goals/selected/train/

goals/index.rst

@@ -36,38 +36,56 @@ Identifying Goals
 
 The goal process enables the community of OpenStack projects to
 surface common concerns and work out specific technical strategies for
-addressing these concerns. This community input enables the TC to
+addressing these concerns.
-select specific community-wide goals for all projects to achieve
-during a development cycle. We need to consider the timing, cycle
-length, priority, and feasibility of the goals selected.
 
-We will brainstorm goals before and at each summit, using feedback
+The first step in the process is to build a `backlog of potential goals`_.
-received from deployers, users, contributors, and PTLs. Those goals
+This helps us coalesce feedback received from deployers, users, contributors,
-will be discussed on the mailing list to collect feedback about
+and PTLs. It is the reference used as a base for goal discussion during
-whether each goal is achievable and described completely. The TC will
+Forum events. Finally, it serves as inspiration for prospective goal
-use that input to come to consensus and make the final decisions for
+champions.
-OpenStack-wide goals for each cycle in time to allow planning and
+
-other discussion at the PTG event at the start of the cycle.
+.. _`backlog of potential goals`: https://etherpad.openstack.org/p/community-goals
 
 Defining Goals
 --------------
 
 Goals are defined here in the governance documentation to ensure that
 we establish a common understanding of the expectations being set.
+
+Once champions have volunteered to propose and drive a specific goal, they
+should iterate through goal definition in the ``/goals/proposed/`` directory.
+This allows to keep the goal selection process separate from the goal
+definition process.
+
 Goal definitions should use the provided template so they are all
 formatted consistently.  The goal definition does not take the place
 of any blueprints, spec documents, or other planning tools used within
 a project to track its work, but can be referenced from those
 documents.
 
-To define goals for a release cycle, a TC member should set up the
+This separates the discussion for each goal, and allows authors to gradually
-series directory in one patch, and then in follow-up patches TC
+refine and improve their proposal through multiple incremental changes.
-members can propose specific goals. This separates the discussion for
+Goals should be discussed on the mailing list to collect feedback on their
-each goal onto its own review.
+feasibility, and consensus on whether they have been completely and clearly
+described.
 
-The actual goals shouldn't be completely new proposals (things no one
+Selecting goals for a cycle
-else in the community has seen before) because there will have been
+---------------------------
-discussion in the course of reaching consensus.
+
+The TC will consider proposed goals from the ``/goals/proposed/`` directory
+and select a set of OpenStack-wide goals for each cycle in time to allow
+planning and other discussion at the PTG event at the start of the cycle.
+
+To define goals for a release cycle, a TC member should first set up the
+new series-specific directory under ``/goals/selected/`` in one patch (for
+example, create a ``/goals/selected/unicorn`` subdirectory for the Unicorn
+release). Then a selection of goals can be proposed: a single subsequent
+patch moving a set of goals from the ``/goals/proposed/`` directory to the
+new ``/goals/selected/$series/`` subdirectory.
+
+This allows to consider the proposed series goals as a group, and take
+into account how feasible they are together, considering the timing and
+cycle length.
 
 Tracking Goal Progress
 ----------------------
@@ -153,11 +171,11 @@ such as how many projects completed the goal, reasons behind some projects
 that did not complete the goal, anything notable that came up during the goal
 implementation phase, and next steps if there are any.
 
-Release Cycles
+Community goals
-==============
+===============
 
 .. toctree::
-   :glob:
+   :maxdepth: 3
-   :maxdepth: 2
 
-   */index
+   selected/index
+   proposed/index

goals/proposed/index.rst

@@ -0,0 +1,8 @@
+==============
+Proposed goals
+==============
+
+.. toctree::
+   :glob:
+
+   *

goals/proposed/placeholder.rst

@@ -0,0 +1,6 @@
+=============
+ Placeholder
+=============
+
+This file is a placeholder for the build and should be removed after
+the first real goal is approved.

goals/selected/index.rst

@@ -0,0 +1,9 @@
+==============
+Selected goals
+==============
+
+.. toctree::
+   :glob:
+   :maxdepth: 2
+
+   */index

goals/selected/train/python3-updates.rst

@@ -5,9 +5,9 @@
 =========================================
 
 This goal is to implement the process set out in the
-:doc:`../../resolutions/20181024-python-update-process` TC resolution, for the
+:doc:`../../../resolutions/20181024-python-update-process` TC resolution, for
-Train cycle to ensure unit testing is in place for all of the
+the Train cycle to ensure unit testing is in place for all of the
-:doc:`../../reference/runtimes/train`.
+:doc:`../../../reference/runtimes/train`.
 
 In practice, this generally means adding unit tests for Python 3.7 and dropping
 unit tests for Python 3.5. Using the Zuul template for Train will ensure that
@@ -104,16 +104,17 @@ Python 2 testing remains unchanged. Repositories that unit test on Python 2
 should continue to do so using the ``openstack-python27-jobs`` Zuul template,
 and declare support for Python 2.7 in ``setup.cfg``. Testing of Python 2 must
 not be dropped before the U cycle, as detailed in the
-:doc:`../../resolutions/20180529-python2-deprecation-timeline` TC resolution.
+:doc:`../../../resolutions/20180529-python2-deprecation-timeline` TC
+resolution.
 
 References
 ==========
 
-* :doc:`../../resolutions/20181024-python-update-process`
+* :doc:`../../../resolutions/20181024-python-update-process`
-* :doc:`../../reference/runtimes/train`
+* :doc:`../../../reference/runtimes/train`
 * `Porting to Python 3.7
   <https://docs.python.org/3/whatsnew/3.7.html#porting-to-python-3-7>`_
-* :doc:`../../resolutions/20180529-python2-deprecation-timeline`
+* :doc:`../../../resolutions/20180529-python2-deprecation-timeline`
 
 Current State / Anticipated Impact
 ==================================