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
This commit is contained in:
Thierry Carrez 2019-06-27 15:58:44 +02:00
parent 99dbb8529d
commit dc88521cf1
24 changed files with 84 additions and 30 deletions

View File

@ -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/

View File

@ -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/

View File

@ -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
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.
addressing these concerns.
We will brainstorm goals before and at each summit, using feedback
received from deployers, users, contributors, and PTLs. Those goals
will be discussed on the mailing list to collect feedback about
whether each goal is achievable and described completely. The TC will
use that input to come to consensus and make the final decisions for
OpenStack-wide goals for each cycle in time to allow planning and
other discussion at the PTG event at the start of the cycle.
The first step in the process is to build a `backlog of potential goals`_.
This helps us coalesce feedback received from deployers, users, contributors,
and PTLs. It is the reference used as a base for goal discussion during
Forum events. Finally, it serves as inspiration for prospective goal
champions.
.. _`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
series directory in one patch, and then in follow-up patches TC
members can propose specific goals. This separates the discussion for
each goal onto its own review.
This separates the discussion for each goal, and allows authors to gradually
refine and improve their proposal through multiple incremental changes.
Goals should be discussed on the mailing list to collect feedback on their
feasibility, and consensus on whether they have been completely and clearly
described.
The actual goals shouldn't be completely new proposals (things no one
else in the community has seen before) because there will have been
discussion in the course of reaching consensus.
Selecting goals for a cycle
---------------------------
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: 2
:maxdepth: 3
*/index
selected/index
proposed/index

8
goals/proposed/index.rst Normal file
View File

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

View File

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

9
goals/selected/index.rst Normal file
View File

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

View File

@ -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
Train cycle to ensure unit testing is in place for all of the
:doc:`../../reference/runtimes/train`.
:doc:`../../../resolutions/20181024-python-update-process` TC resolution, for
the Train cycle to ensure unit testing is in place for all of the
: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:`../../reference/runtimes/train`
* :doc:`../../../resolutions/20181024-python-update-process`
* :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
==================================