House rules for governance changes approval

While most of the governance changes follow the rules described in the charter-motions-section section 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.

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.

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 tags

Gerrit topic: the name of the tag being applied (stable:follows-policy, vulnerability:managed)

Some tags are delegated to a specific team, like tag-stable:follows-policy or tag-vulnerability:managed. Those need to get approved by the corresponding team PTL, and can be directly approved by the chair once this approval is given.

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

For other changes within an existing project team, like addition of a new git repository or self-assertion of a tag, we use lazy consensus. If there is no objection posted one week after the change is proposed (or a significant new revision of the change is posted), then the change can be approved by the chair.

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.

In corner cases where the change is time-sensitive (like a deliverable reorganization which blocks a release request), the chair may fast-track the change, but should report on that exception in the TC update.

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 PTLs

In a resolution regarding 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.

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.

7.1 KiB Raw Blame History