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