title: TPA-RFC-9: "proposed" status and small process changes

Summary: add a proposed state to the TPA-RFC process, clarify the modification workflow, the obsolete state, and state changes.

Background

The TPA-RFC-1 policy established a workflow to bring proposals inside the team, but doesn't clearly distinguish between a proposal that's currently being written (a draft) and a proposal that's actually been proposed (also a draft right now).

Also, it's not clear how existing proposal can be easily changed without having too many "standards" that pile up on top of each other. For example, this proposal is technically necessary to change TPA-RFC-1, yet if the old process was followed, it would remain "standard" forever. A more logical state would be "obsolete" as soon as it is adopted, and the relevant changes be made directly in the original proposal.

The original idea of this process was to keep the text of the original RFC static and never-changing. In practice, this is really annoying: it means duplicating the RFCs and changing identifiers all the time. Back when the original RFC process was established by the IETF, that made sense: there was no version control and duplicating proposal made sense. But now it seems like a better idea to allow a bit more flexibility in that regard.

Proposal

  1. introduce a new proposed state into TPA-RFC-1, which is the next state after draft. a RFC gets into the proposed state when it is officially communicated to other team members, with a deadline
  2. allow previous RFCs to be modified explicitly, and make the status of the modifying RFC be "obsolete" as soon as it is adopted
  3. make a nice graph of the state transitions
  4. be more generous with the obsolete state: implemented decisions might be marked as obsolete when it's no longer relevant to keep them as a running policy

Scope

This only affects workflow of proposals inside TPA and obsessive-compulsive process nerds.

Actual proposed diff

modified   policy/tpa-rfc-1-policy.md
@@ -70,12 +70,12 @@ and a unique, incremental number. This proposal, for example, is

 ## Process

-When the proposal is first written and the notification is sent, the
-proposal is considered a `draft`. It then enters a discussion period
-during which changes can be proposed and objections can be
-raised. That period ranges from 2 business days and two weeks and is
-picked in good faith by the proposer based on the urgency of the
-changes proposed.
+When the proposal is first written, the proposal is considered a
+`draft`. When a notification is sent, the proposal is in the
+`proposed` state and then enters a discussion period during which
+changes can be proposed and objections can be raised. That period
+ranges from 2 business days and two weeks and is picked in good faith
+by the proposer based on the urgency of the changes proposed.

 Objections must be formulated constructively and justified with
 reasonable technical or social explanations. The goal of this step is
@@ -91,26 +91,38 @@ mitigate those problems.
 A proposal is in any of the following states:

  1. `draft`
+ 2. `proposed`
  2. `standard`
  3. `rejected`
  4. `obsolete`

+Here is a graph of the possible state transitions:
+
+![workflow.png](workflow.png)
+
 Once the discussion period has passed and no objection is raised, the
-`draft` is adopted and becomes a `standard`.
+`proposed` RFC is adopted and becomes a `standard`.

 If objections are raised and no solution is found, the proposal is
 `rejected`.

 Some policies can be completely overriden using the current policy
 process, including this policy, in which case the old policy because
-`obsolete`.
-
-Note that a policy can be modified by later proposals. The older
-policy is modified only when the new one becomes `standard`. For
-example, say `TPA-RFC-X` proposes changes to a previous `TPA-RFC-N`
-proposal. In that case, the text of `TPA-RFC-N` would be modified when
-and only if `TPA-RFC-X` becomes a `standard`. The older `TPA-RFC-N`
-would also stay a `standard`.
+`obsolete`. Old, one-time decisions can also be marked as `obsolete`
+when it's clear they do not need to be listed in the main policy
+standards.
+
+A policy can also be **modified** (instead of **overridden** by later
+proposals or decisions taking in meetings, in which case it stays a
+`standard`.
+
+For TPA-RFC process changes, the older policy is modified only when
+the new one becomes `standard`. For example, say `TPA-RFC-X` proposes
+changes to a previous `TPA-RFC-N` proposal. In that case, the text of
+`TPA-RFC-N` would be modified when and only if `TPA-RFC-X` is adopted
+as a `standard`. The older `TPA-RFC-N` would also stay a `standard`,
+although the *newer* `TPA-RFC-X` would actually become `obsolete` as
+soon as the older `TPA-RFC-N` is modified.

 # Examples

@@ -134,6 +146,12 @@ Counter examples:
  * picking a different hardware configuration for the new ganeti node
    (process wasn't documented explicitely, we accept honest mistakes)

+Examples of obsolete proposals:
+
+ * [TPA-RFC-4: prometheus disk](tpa-rfc-4-prometheus-disk) was marked as obsolete a while
+   after the change was implemented.
+
+
 # Deadline

 Considering that the proposal was discussed and informally approved at

Workflow graph

The following graph will also be attached to TPA-RFC-1:

workflow.png

Examples

Examples:

  • TPA-RFC-4: prometheus disk was marked as obsolete when the change was implemented.
  • this proposal will be marked as obsolete as soon as the changes are implemented in TPA-RFC-1
  • this proposal would be in the proposed state if it was already adopted

Deadline

December 17th.

Status

This proposal is currently in the obsolete state.

References

See policy/tpa-rfc-1-policy.