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.
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…
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.
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.
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.
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?
There should be a procedure for updating a finalized FEP if changes are not substantial (e.g. fixing typos or dead links).
For substantial changes, I agree that a new proposal should be created (with appropriate metadata tags such as replaces and replacedBy).
Regarding the two cases of FEP’s which have gone through this process and are marked as “final”, the question I have is “What would have needed to have happened for them not to have become FINAL”?
In the case of FEP-8fcf (Followers collection synchronization), there was a lot of discussion up until May 21, 2021. Then there was a 8 months gap and on Jan 24, 2022, the proposer asked for it to be finalized. 14 days later it was declared FINAL, with no intervening comments. From the discussion, there was no consensus at all. If consensus had emerged, it must have been out-of-band, because it certainly wasn’t reflected in the discussion in this forum.
In the case of FEP-400e (Publicly appendable collections), the proposer asked for it to be finalized on Jan 21, 2022. This was in the middle of debate of a particular point, which continued for a few more days, with no resolution. This followed previous discussions on many other points, many/most of which did not arrive at a consensus resolution. On Feb 5, 14 days after the request, the FEP was finalized. As in the other case, there was no consensus, at least none apparent from the discussion in this forum.
In both cases, the requests for “finalization” seemed to come out of the blue with no apparent consensus having emerged, and in both cases, someone decided to just declare the FEPs final.
So, I am wondering in both those cases, what would we have needed to be seeing in this forum if those FEP’s were not going to be finalized?
While the FEP process was started to improve the situation around standardization of additional mechanisms and formats on top of the official specs, it is far from ideal in its realization. You might say it is in the same sorry state as any organized activity for the evolution of the Fediverse. That said, there are many ways to improve things.
But there is a chicken-egg. With the FEP process not running smoothly it is not taken seriously and mostly ignored, but in order for it to become a well-oiled mechanism to extend upon the specs the involvement of the developer community is needed.
As you can see I created this topic 1.5 years ago and there’s a gap of 10 months where no one responded. I have also brought up in various places on this forum an organization structure for standardization (consisting of 3 levels with different amount of formality to them), where there was no real response. Without community involvement any form of organization is doomed to fail.
Since I posted this topic both me, @weex and @pukkamustard have volunteered to be editors of the FEP, and we have moved the FEP repository from @cjs repository to Codeberg, where it can be better maintained. But we have but little time to spend, and I am afraid are later than the 7 days to react to the latest FEP proposed by @Claire (sorry for that, I will create a tracking issue after this post). Here I must mention (talking for myself) that it is also not motivating to be editor, without having the community to do it for. This is part of the chicken-egg.
The process will gain support from the community if it results in high-quality FEPs. Some of the hallmarks of quality are (1) evident community consensus, and (2) multiple interoperating implementations.
There is no rush to push out FEPs which don’t have those two things, and indeed, that is counterproductive.
It isn’t a good sign that there are only two final FEPs, and already it is an issue as to how to correct, extend, or supercede them – before there is even a second implementation of them, as far as I can tell.
The process is open for anyone to involve themselves and make improvements along the way. That includes amending / superceding the final FEP’s with successors that have broad consensus
I agree that finalization requirements can be changed to include metrics such as number of implementations, but the finalization procedure is defined in FEP-a4ed, which itself has FINAL status. So in order to improve the procedure we need to decide how to correct, extend or supercede a FEP, anyway.
I don’t really even know what “FINAL” means. Standards with a lot more institutional weight behind them than FEPs are rarely “final”. Every “standard” I am familiar with can be:
(1) superceded by other recommendations/standards (such as standards track RFC’s); or
(2) go through versions or revisions; or even
(3) be explicitly “living documents” which go through “continuous” evolution.
At the moment, given that an FEP can become “final” without consensus and with only one implementation (and that even seems optional), I have decided to think of FEPs as basically like Internet Drafts, or maybe “Informational”/“Experimental” RFCs. It is a way for somebody to put something “out there” for comments.
I can implement an FEP if I need to do so because big players adopt it, in which case it will be helpful to have a document to reference (assuming that “adopting” it means implementing what is in the FEP). I can implement those that seem like reasonable solutions to problems – better than starting from scratch. Otherwise it seems safe to ignore them. If I have gotten the point of FEPs, then nobody has to do anything. If they are supposed to be like “standards”, maybe the process needs work.
This is how I see FEPs as well, as informational documents (though I wasn’t there when it all started). They make coordination between developers easier, but can not be enforced.
I think the answer to “how this started” is the thought of “Let’s at least have something in place, and refine along the way”. So any suggestions to improvement are most welcome. @bmottershead I’d say propose a different system, advocate, get agreement to change, and then @weex and I can merge PR’s to the FEP repo. Anything is possible and whatever works best should be a go
Thanks @bmottershead for delving into this and providing a great summary and to @aschrijver for always being here even when others of us have other interests pull us away. When I came upon the FEP project, there was only one final standard (the “FEP FEP”) so I focused my efforts on solving the immediate problems I saw which was a few stalled FEPs plus hosting problems and volunteered as an editor to help jumpstart the project for a time. As @aschrijver mentioned, we’ve migrated to Codeberg and then as you saw 2/3 of the FEPs were finalized.
All the while I’ve tried to operate by the rules laid out before me, just to move the ball down the field so to speak, so your comments make sense as a natural extension. When I looked into other standards efforts I saw large libraries of RFCs and other documents, some of which saw uptake in the market and others that did not. We have no way of knowing which ones will be broadly successful. We just have a defined process and can do our best to operate it.
The vast majority of all fediverse activity being volunteer means we have problems whenever any kind of synchronization is required. You saw it in the finalization of FEPs that were in a shadow of former interest. The only reason I could see for not finalizing them is if someone pointed out concrete ways in which they violated what’s said in the FEP FEP.
I understand there is interest in others becoming editors which is great. I look forward to this project moving forward in the best way possible.
Though SocialHub and later the FEP process exist for quite some time, there’s confusion about purpose and role of the FEP initiative. I created an issue on the repo:
But other than that, if there’s interest, the FEP process might get further formalization of various aspects. (SocialHub is a DoOcracy… so whomever is interested carry the ball forwards )
I’m proposing a new FEP status: STABLE. This status will mark the stage in FEP process between active discussion (DRAFT) and finalization (FINAL). See this issue for details: #90 - Lifecycle of a proposal - fep - Codeberg.org.
)