b7f45e2266
This change enacts the first steps of the TC's decision to remove the tags framework. [1] This change does not remove all the parts to avoid breaking the releases tooling as well as to preserve useful information as discussed under this change and during one of the TC meetings. [2] [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025554.html [2] https://meetings.opendev.org/meetings/tc/2022/tc.2022-01-20-15.00.log.html Change-Id: Iab4a136905a9c7a61530ff7576a216d229f717a0
196 lines
8.8 KiB
ReStructuredText
196 lines
8.8 KiB
ReStructuredText
=============================================
|
|
House rules for governance changes approval
|
|
=============================================
|
|
|
|
While most of the governance changes follow the rules described in the
|
|
:ref:`charter-motions-section` section (or :ref:`charter-amendment-section`
|
|
section) of the Charter and call for a formal discussion and vote by the
|
|
Technical Committee membership, we also have a number of exceptions to that
|
|
general rule, in order to speed up the processing of smaller changes. This
|
|
document lists those "house rules" for reference.
|
|
|
|
The goal of the TC is always to operate by consensus where possible. The best
|
|
decisions are always the ones where all TC members can commit to the outcome,
|
|
even if they voted against it. These guidelines and the ones in the charter are
|
|
designed to provide the chair with an objective standard for when they may
|
|
consider consensus to have been achieved. However, if it is clear to the chair
|
|
from other factors that consensus has not been achieved (for example because
|
|
there are multiple incompatible proposals with sufficient votes to merge), the
|
|
chair should use their discretion to keep debate open and seek rough consensus
|
|
by other means.
|
|
|
|
Typo fixes
|
|
----------
|
|
|
|
:Gerrit topic: ``typo-fix``
|
|
|
|
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
|
|
------------
|
|
|
|
:Gerrit topic: ``code-change``
|
|
|
|
The `openstack/governance` repository also contains code to build and publish
|
|
pages on the governance.openstack.org website. For those we 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.
|
|
|
|
Documentation changes
|
|
---------------------
|
|
|
|
:Gerrit topic: ``documentation-change``
|
|
|
|
The `openstack/governance` repository also contains documentation
|
|
related to internal operations of the TC but that does not represent
|
|
formal policy. Changes to these documents, as well as minor updates to
|
|
policies to improve the document without changing the policy itself
|
|
(formatting, extra headings, wording changes that are not substantive,
|
|
etc.), follow 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`).
|
|
|
|
Election Results
|
|
----------------
|
|
|
|
:Gerrit topic: ``election-results``
|
|
|
|
The results of elections are documented in the `openstack/governance`
|
|
repository, but are not subject to "review" or "approval" by the TC,
|
|
other than to confirm that they accurately reflect the outcome of the
|
|
election. Patches to update those results for TC and PTL elections
|
|
should be reviewed and confirmed by the election officials, and then
|
|
approved and merged following 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`).
|
|
|
|
Delegated metadata
|
|
------------------
|
|
|
|
:Gerrit topic: ``release-management``
|
|
|
|
The ``release-management`` setting for a deliverable is delegated to
|
|
the PTL of the Release Management team. When proposed or approved by
|
|
the PTL, changes can be directly approved by the chair.
|
|
|
|
Other project team updates
|
|
--------------------------
|
|
|
|
:Gerrit topic: ``project-update``
|
|
|
|
This topic is used for other changes within an existing project team, like
|
|
addition of a new git repository or retirement.
|
|
|
|
If there is no objection posted after the addition or retirement of a project
|
|
is proposed (assuming the correct retirement process has been followed), then
|
|
the change can be approved by the chair if it has at least two 2 roll call
|
|
votes (which can include the vote of the chair and excludes the change owner)
|
|
and a code review vote from the PTL of the project (or their delegate).
|
|
If the change is from the PTL or their delegate, this will count as an
|
|
acknowledgment code review vote.
|
|
|
|
One exception to this would be significant team mission statement changes,
|
|
which should be approved by a formal vote after discussion on the mailing list
|
|
or the gerrit change.
|
|
|
|
If a technical committee member disagrees with the addition or retirement of a
|
|
project, they can propose a revert which would then be discussed by our usual
|
|
``formal-vote`` rules.
|
|
|
|
Goal Updates from PTLs
|
|
----------------------
|
|
|
|
:Gerrit topic: ``goal-update``
|
|
|
|
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 bring it up on the mailing list and the change
|
|
should not be approved until after the discussion is completed.
|
|
|
|
Appointing Project Leaders/Liaisons
|
|
-----------------------------------
|
|
|
|
In a resolution regarding :ref:`leaderless programs`, the TC was granted
|
|
authority to appoint a Project Team Lead to any official project where the
|
|
`election`_ process failed to produce a leader. When this happens,
|
|
``reference/projects.yaml`` in the ``governance`` repository should be updated
|
|
to indicate the new PTL and their appointment by adding their name and contact
|
|
details and updating an ``appointed`` key with the cycle during which they will
|
|
be the PTL. If the ``appointed`` key is already present, add the cycle to the
|
|
list. If the key is not present, add it and set the cycle as a single member of
|
|
a list. This format is used for two reasons: to track all the cycles for which
|
|
there has been an appointment and to require a comprehensible change for review
|
|
by the TC. The ``appointed`` key should only be changed when the PTL was not
|
|
chosen by the election process.
|
|
|
|
In the case of a project using, or moving to, Distributed Project Leadership
|
|
model (see :doc:`/resolutions/20200803-distributed-project-leadership`), the
|
|
TC will make sure all the mandatory liaisons in the DPL model are assigned.
|
|
|
|
These changes are subject to the standard review and approval guidelines.
|
|
|
|
Rolling back fast-tracked changes
|
|
---------------------------------
|
|
|
|
As a safety net, if any member disagrees with any change that was fast-tracked
|
|
under one of those house rules, that member can propose a revert of the
|
|
change. Such revert should be directly approved by any TC member (who is not
|
|
the proposer) and the change be discussed on the mailing list or on the
|
|
re-proposed change in gerrit.
|
|
|
|
Voting on Changes in openstack/governance
|
|
-----------------------------------------
|
|
|
|
TC member should use their RollCall-Vote permissions on all
|
|
patches. Code-Review votes are ignored for the purposes of tallying
|
|
votes, regardless of the content of the patch.
|
|
|
|
In the course of evaluating alternatives for complex proposals, we
|
|
often ask one TC member to write several patches that might be
|
|
mutually exclusive so that the committee can compare them and select
|
|
one by voting on them independently. Because of this, we need to
|
|
ensure that it is clear which patch the author of the patches prefers,
|
|
and so we usually ask all TC members to cast a vote on all patches,
|
|
even those they write.
|
|
|
|
.. _election: https://docs.openstack.org/project-team-guide/open-community.html#technical-committee-and-ptl-elections
|