Improve FEP process: How to correct, extend or supercede a FEP that is FINAL?

Standards Fediverse Enhancement Proposals
#1

Feedback AFTER the FEP-a4ed became FINAL …

A particular FEP has become FINAL and the FEP process states …

A proposal with status FINAL can not be changed or updated.

Now suppose I would like to change it. What’s the procedure? Should one write another FEP that suppercedes the current one if it becomes FINAL. If so, how do we document that so it is clear to everyone? Or should FEP’s be Versioned instead?

The change I am thinking about is following:

  • While in DRAFT mode there should not be a Timer that is ticking (the 60 day period). This is the stage where you prepare your proposal before it is ready for the world.
  • Add an additional workflow step PROPOSED where the 60-day review period starts.

The workflow then looks as follows:

                                                          +-------+
                                                +-------> | FINAL | 
                                                |         +-------+
         +-------+          +----------+        |
-------->| DRAFT | -------->| PROPOSED |--------+
         +-------+          +----------+        |
             ^                                  |         +-----------+
             |                                  +-------> | WITHDRAWN |
             |                                            +-----------+
             |                                                  |
             +--------------------------------------------------+

Why extend?

  • So all drafts being prepared are in one place.
  • So you can work with others to hone it together before actually proposing.

For the case where a new FEP supercedes another this may be reflected in its state, plus a reference to the superceding FEP is added to the old one. Maybe a better state name is in order e.g. ARCHIVED or even (maybe) DEPRECATED in some cases…

                                                          +-------+                +------------+
                                                +-------> | FINAL |--[other-FEP]-->| SUPERCEDED |
                                                |         +-------+                +------------+
         +-------+          +----------+        |
-------->| DRAFT | -------->| PROPOSED |--------+
         +-------+          +----------+        |
             ^                                  |         +-----------+
             |                                  +-------> | WITHDRAWN |
             |                                            +-----------+
             |                                                  |
             +--------------------------------------------------+

CC @pukkamustard @cjs

1 Like
Social CG Issue Trackers
How to solve our engagement problem, foster more cross-pollination?
FEP-a4ed: The Fediverse Enhancement Proposal Process
Can't create a topic in FEP category
Brainstorming on v2 FEP Process
#2

I wonder if we need a new state, an update mechanism, or just RFC-style later-ones-just-supercede.

It is possible an older item isn’t 100% superceded, just parts of it, so I am hesitant to add a new state – this would imply a whole thing is obsolete.

1 Like
#3

FEP process

Yes, that’s true, but in that case you’d have metadata on the other FEP which make it effectively not-FINAL-anymore. Like you have “this version” and “latest version”. I am assuming that any significant update must undergo the entire review process. Once the update becomes FINAL, then a warning on the old one must be shown “This is not the latest FINAL version” or something, similar to what you see at W3C.

If an update is underway in the process, does it have the same title + ID? That might be confusing. Alternatively an update could be part of the same document, i.e. it contains all versions, but that’d be confusing too.

Note that it gets complicated pretty quick. A W3C spec is designed to be something self-contained, whereas a FEP is an enchancement and not necessarily be ‘atomic’ i.e. it may need to be adapted to comply with other FEP’s as they are finalized. There are relationships.

Talking W3C… we may reuse the exact same mechanism. I figure it takes care of most of this. We want the FEP’s to be practical, least ceremonial, but they should also be useful and a sprawl of FEP’s - once the process gets traction - may go against that.

#4

It seems like replacement makes sense as an addon, based on what came before FEP. Being final doesn’t mean uneditable from a metadata/linking perspective. It just means that the standards content inside shouldn’t be changed and create confusion for implementations.

From the Bittorrent BEPs:

BEPs can also be replaced by a different BEP, rendering the original obsolete. This is intended for Informational BEPs, where version 2 of an API can replace version 1.

This opens the possibility of replacement as a natural follow-on process. Ideally we have good enough proof-reading that typos don’t make it through but I think that mainly comes through community involvement.

From Scheme Requests For Implementation:

It must list related standards and SRFIs, including dependencies, conflicts, and replacements.

This says that the original document can be modified in the metadata section to mention replacement. So we could add something like:

dateReplaced: 2022-02-05
replacedBy: FEP-1234

There are other standards processes out there as well but the above feels sufficient to me.

2 Likes
#5

I agree. Keep it small and simple.

Yet a replacement should go through the process cycle and be DRAFT before it becomes FINAL. Should this be indicated in the status of the original, e.g. with DEPRECATED and then REPLACED once the replacement becomes final?

1 Like