This is testable: So one can write a CI script ensuring that only FEPs satisfying the above can be merged.
This allows us to standardize the implementations section enabling building tooling. This means that one can actually provide a count of implementations (according to the FEP) and thus separate FEPs with wide adoption from unused ones.
Further Steps
One can also imagine a testable type corresponding to a Test Suite section.
This is roughly the idea I had when I proposed the implementation type (category).
Proposals with this type are supposed to have the āImplementationsā section. This is not a requirement yet, but we can add it to FEP-a4ed.
type == implementation and count(implementations) > 0 would be equivalent to type == implemented
Works for me. The following 24 FEPs currently have an implementation section. Not all contain a list of implementations ā¦ so one would need to work a bit to standardize this. However, separating out these + the meta FEPs would probably make the FEP index more readable.
Lists are easy to parse. We can count lines starting with - and * and ignore other lines. āNone so farā and other comments wonāt be counted.
We could also introduce a metadata field like implementationCount, but people will often forget to update it. I think itās important to make counting automatic.
FEP-f1d5 is not included in the current list of counts. Iād be surprised if the actual count isnāt more like 50+.
FEP-67ff is missing implementations (this will be a common problem for implementation counting in general) and includes some non-Fediverse implementations like Disaspora and Matrix.
I think this is a problematic goal for several reasons. What is āwide adoptionā? Number of implementations (including those that are abandoned and/or unused)? Number of users on instances of those implementations? Something else?
In general, it will be difficult to know if an FEP is unused. An FEP author may neglect to add the required section title to their FEP (like in FEP-f1d5) and implementors will not always notify an FEP author to update their FEP content (or maybe the author is no longer interested in updating it).
Putting emphasis on a noisy and possibly inaccurate implementation count metric may give the impression that innovative new FEPs with no implementations (yet) have been effectively rejected by the developer community.
I think itās can be useful, for general information, to know which implementations have implemented an FEP. However, Iād be concerned if they are officially used to generate āadoptionā metrics or to organize the FEPs into categories.
Although it doesnāt fix some of the issues Iāve raised, hereās another potential approach for implementation tracking.
Maintain implementation metadata separately from the FEP content.
Have projects register their project metadata (an FEP repo file (or files) with project metadata, like the name, nodeinfo identifier (if any), repository URL, maintainer emails, ā¦).
These projects would be required to have a FEDERATION.md file.
Use a periodic repo action to retrieve the FEDERATION.md files and parse the Supported FEP section to update the implementation metadata file.
The benefit of this approach is that it is mostly automated and self-maintaining (other than merging new project metadata). The side-benefit is that it serves as a kind of FEP-related project registry that can be used for a wide variety of purposes (HTML generation, metric calculation, etc.).
Number of implementations is the best metric. It shows that independent developers not only agreed with the idea, but also put effort into implementing it. Abandoned and unused implementations also matter, for this reason.
Number of users is also interesting, but harder to do, and they all might be on a single implementation.
Implementation counting will motivate authors to monitor implementations.
Authors could do the first implementation, increasing the count from 0 to 1.
If no one wants to implement the FEP (even the author), this is a good sign that proposal is low quality.
As there are currently seven final feps, I donāt think investing further time into organizing them is necessary. we can revisit the question when we have like 20 final feps.
So the focus should be on what we want this page to look like.
See: As there are currently seven final feps, I donāt think investing further time into organizing them is necessary. we can revisit the question when we have like 20 final feps.
I think our focus should be on encouraging FEPs to become FINAL.
use material for mkdocs to do the markdown ā html transformation
remove discussions when equal tracking issue
add sortable rows
remove unused columns / change names as suggested above
One can probably use material for mkdocs to build an equivalent rendering to codeberg for markdown.
Remaining tasks; Contributions welcome
Render FEPs. This requires configuring mkdocs to material to be feature equivalent to the codeberg renderer. This is probably complicated. So making progress and identifying problems is a big contribution.
Add miscellaneous pages, e.g. āHow to submit a FEPā
Maybe somebody could create a markdown feature test page? E.g. a diagram of Alice talking to Bob and other features you like. A suggested Markdown usage for FEP would make a good meta FEP.
I donāt find the asterism a strong symbol for this purpose. On first impression I see snowflakes, and if I remind myself that the asterisks represent people (or nodes, instances, actors?) then I see 3 individuals.
The current logo of the FEP repo is most commonly accepted still to represent the Fediverse. It is a strong brand for that. But it is arguably not the best fit for the FEP repo. Yes, FEPās relate to Fediverse, but they enhance the ActivityPub et al protocol suite. Also āFediverseā is a more fluffy, vague concept than the AS/AP open standards are.
Hence maybe using the ActivityPub logo is more appropriate. This would also show the affiliation to SocialHub as custodian of the FEP process, as well as the liaison to the W3C where the official specs are evolved.
Note that the purpose of the logo change should be that it provides strongest brand image for the FEP process, in order to in turn increase awareness of the FEP as an official party in the 3-stage bottom-up standardization process, and to gain any kind of adoption for new functionality one requires. That does not necessarily correspond to what fedizens in general find the most appealing logo wrt this thing called āFediverseā.
Hubzilla already supports Markdown, although it does not support certain things like mermaid
sequenceDiagram. (Although it could if someone wanted to add it.)
Here is an example of an FEP rendered in Hubzilla using Markdown. We can change the theme or alter the CSS, if desired.
We can also create an addon that renders the FEPs instead of using the native Webpages or Wiki functionality like the example above.
If we create an addon, one way to do it is to clone the FEP repo on a Hubzilla server, and then just have the Hubzilla addon fetch the md files and render it. Any time you want to update the website, we just get the current copy from the repo, which could be automated.
This is how I planned on doing it before I found out you all had the same idea.
No, FEPs are Fediverse Enhancement Proposals. Not all of them are about enhancing ActivityPub, some are about extending NodeInfo and WebFinger, others are related to Zot/Nomad networks.
Maybe a little bit, but almost everyone knows what it means. There were attempts to associate certain centralized silos with Fediverse in the past, but they failed. I donāt think re-branding is necessary.
FEP is not a party in any standardization process. I remember that you discussed the idea of using FEPs as inputs for other processes, but this is not happening yet, and even if happens in the future, that wonāt change anything about the FEP process, because it is independent from other efforts.
