openstack/governance
Code Issues Proposed changes

Loosen voting for community goal proposals

Browse Source 
Community goal proposals are intended to be an iterative process
according to the goal process documentation [1].  Goals should be
committed to the goals/proposed/ directory and then the committed goals
should later, as a separate action, be evaluated and the ones selected
as cycle goals should be moved to goals/selected/.

This change clarifies the wording in the goals process and house rules
to indicate that normal voting criteria should hold for proposed goals,
and full formal-vote criteria should hold for the selection of goals.
Presently formal-vote is used for all.

By loosening the criteria for voting it is hoped that the goals section
will be more like the ideas repository, a less constrained forum for
ideas to be proposed, debated, and refined.  Goals would still need at
least two TC members to merge as proposed, so there would still be
validation of the goals.  I believe this is the model that the goals
process refinement was hoping for.

Without this change, the formal-vote criteria for proposed goals voids
the iterative nature of goal development specified in the goal process
document.  Functionally it means that TC members hold off on voting
until goal selection.  This means that goals are not merged to the
goals/proposed/ directory, and there is no reason for it directory to
exist.  I believe this is a suboptimal result.

for more background, see the discussion on #openstack-tc on 28 April
2020 [2].

[1] https://governance.openstack.org/tc/goals/index.html#process-details
[2] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2020-04-28.log.html#t2020-04-28T16:44:49

Change-Id: Ifa077520468e2caf218e5265f1ce4432ac3848ee
This commit is contained in:
Nate Johnston
2020-04-28 15:35:42 -04:00
parent fe8c3da347
commit 45068a135e
2 changed files with 24 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
goals/index.rst
View File

@@ -55,7 +55,10 @@ 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.
definition process. Goal proposals should have the ``goal-proposal`` gerrit
topic, whose voting rules are specified in the `house rules`_.
.. _`house rules`: https://governance.openstack.org/tc/reference/house-rules.html
Goal definitions should use the provided template so they are all
formatted consistently. The goal definition does not take the place

20
reference/house-rules.rst
View File

@@ -28,6 +28,26 @@ When the change fixes content that is obviously wrong (updates a PTL email
address, fixes a typo...) then any TC member (who is not the proposer) can
directly approve them.
Community-wide goal proposals
-----------------------------
:Gerrit topic: ``goal-proposal``
The `process for choosing community goals`_ has two stages relevant to Gerrit
changes: defining goal proposals and selecting goals for a cycle. For changes
that propose a new goal, or that iterate on an existing proposal, apply the
normal code review rules (with RollCall votes being considered +-2): change will
be approved once 2 `RollCall+1` (other than the change owner) are posted (and no
`RollCall-1`). Any TC member (who is not the proposer) can approve them at this
point.
Selecting community wide goals for a cycle should be proposed as a single change
that moves selected goals from `goals/proposed/` to `goals/selected/`. This way
the collective feasibility of the goals can be clearly evaluated. Such a change
requires a formal-vote.
.. _`process for choosing community goals`: https://governance.openstack.org/tc/goals/index.html#process-details
Code changes
------------