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.
