Background #

One of the biggest shortcomings of home grown RFC management tools is that it's too easy for someone to modify an RFC after it has been accepted and after implementations have begun. One of the core pillars of RFC Hub is to prevent this from happening.

That said, some orgs might not be ready for such strict management of RFCs.

Proposal #

This RFC proposes that orgs have an option to configure their org in one of two ways:

• Strict Mode: Published RFCs can't have content changes or have status changed back to review/draft
• Loose Mode: Published RFCs can have content changes and any status change

Strict Mode #

Here's the state flow diagram for RFCs in a strict-mode org:

stateDiagram-v2
    [*] --> Draft
    Draft --> Review
    Draft --> Deleted
    Review --> Published
    Review --> Deleted
    Review --> Draft
    Published --> Obsolete
    Published --> Deleted
    Published --> Review
    Obsolete --> Deleted
    Obsolete: Obsolete 🔒
    Deleted: Deleted 🔒
    Published: Published 🔒

States with a lock icon (🔒) cannot have new content versions created and cannot have the active content version changed. Other metadata is allowed to change, like reviewers, watchers, links, visibility, etc.

Loose Mode #

Essentially an RFC can move between any state and there are no checks. An RFC can have new content versions made as well.

Alternatives #

One alternative is to have a system that is entirely dynamic and configurable either by declarative or iterative code. For example, the Gerrit code review tool allows approval configuration via Prolog. One could imagine any such system allowing for definitions of state changes and state change requirements to implement this. Orgs could even define more or less than the default 5 states.

However, this would take a lot of effort to implement and would likely have security considerations. It's not necessarily something a lot of orgs would want to implement. If we ever take this approach it would probably be far in the future.