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:
parent
99dbb8529d
commit
dc88521cf1
|
@ -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/
|
||||
|
|
|
@ -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/
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -0,0 +1,8 @@
|
|||
==============
|
||||
Proposed goals
|
||||
==============
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
|
||||
*
|
|
@ -0,0 +1,6 @@
|
|||
=============
|
||||
Placeholder
|
||||
=============
|
||||
|
||||
This file is a placeholder for the build and should be removed after
|
||||
the first real goal is approved.
|
|
@ -0,0 +1,9 @@
|
|||
==============
|
||||
Selected goals
|
||||
==============
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
:maxdepth: 2
|
||||
|
||||
*/index
|
|
@ -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
|
||||
==================================
|
Loading…
Reference in New Issue