… reorganize the feature bullet list to match decreasing order of importance. My suggestion: Portability, Trust, Mirror, Archival, Notification
Done!
Notification might be renamed to Reporting, in whatever form or manner (such as notifications).
I’m not sure I understand the rationale for this change, although I can imagine a few. Would you be so kind as to shortly clarify what you have in mind?
Analytics as mentioned by @realaravinth is a core feature that will be unlocked.
Added:
Analytics: data mining the contents of files is more practical than issuing a large number of queries to an API
Versatility can be added, indicating all the unexpected use cases.
Versatility: when published and updated as a FFF archive, a software project effectively is Open Data on which an unlimited range of applications can rely, even outside of the forge domain
You might split this list into “FFF key requirements” and “FFF use cases”. I would make such distinction.
Done.
“Pivot format”… I do not know what that is, or means. Either choose another word or explain.
Good catch! A “pivot format” is a format for which there is a a large number of conversions from and to other formats. So instead of implementing N² conversions it is enough to implement N+1 conversions. To convert to format A to format B you can always use format P as an intermediate format, to “pivot” between the two (A => P => B => P => A).
But there is no need to clarify this notion. It is important to reduce the complexity of maintaining and implementing FFF but it is a detail. I just removed the two instances of “pivot format”.
“Reference implementations in Go …”, I’d move that down a couple lines to just before “The reference implementation is modular…”
Done.
“Reference implementation is modular”, doesn’t that imply that FFF itself is modular, and this is another Key Requirement?
I’m not sure what would be best for the FFF specifications at this time and it is probably difficult to forsee. However, it is crystal clear that the reference implementations must be modular to be maintainable: there are so many tiny details that crowdsourcing the implementation is critical to its success. And crowdsourcing requires modularity so that implementors can focus on a specific area.
I chose to hint this with just “modular” in this context but maybe it is best to remove the word.
“Evolve into a stardardized format”, does indicate to me that Open Standard is another Key Requirement.
That should be in the tagline since it is what FFF is about. “Friendly Forge Format - an Open Standard to represent software projects”
Consistency might be mentioned with this Key Requirement, i.e. by providing a common language to use when talking about the domains that are covered by FFF. The consistency is guaranteed by the standardization.
Yes, added.
With Versatility, onboarding of contributors, gradual crowdsourcing, etc. I think Extensibility is another Key Requirement.
I’m not sure exactly what you mean by Extensibility. Is it something similar to FEP for ActivityPub?
“that encompasses a growing number of forges over time”, might reformulate “with broad adoption by forges and related development tools”. The “over time” isn’t needed as with “evolve” you already refer to a vision of the future.
Excellent, done.