First of all: Very well written, and that helps provide a lot of clarity! Here’s additional feedback on text formulation and content…
Textual review
-
As mentioned on chat reorganize the feature bullet list to match decreasing order of importance. My suggestion: Portability, Trust, Mirror, Archival, Notification
- Notification might be renamed to Reporting, in whatever form or manner (such as notifications).
- Analytics as mentioned by @realaravinth is a core feature that will be unlocked.
- Versatility can be added, indicating all the unexpected use cases.
-
You might split this list into “FFF key requirements” and “FFF use cases”. I would make such distinction.
- Then it is less tied to a forge, has a better split between FFF specific and stuff that can be done with it once you have it.
- Key requirements: Portability, Versatility, Trust
- Use cases: Analytics, Reporting, Archival, Mirror (of a forge)
-
“Pivot format”… I do not know what that is, or means. Either choose another word or explain.
-
“Reference implementations in Go …”, I’d move that down a couple lines to just before “The reference implementation is modular…”
-
“Reference implementation is modular”, doesn’t that imply that FFF itself is modular, and this is another Key Requirement?
-
“Evolve into a stardardized format”, does indicate to me that Open Standard is another Key Requirement.
- 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.
-
With Versatility, onboarding of contributors, gradual crowdsourcing, etc. I think Extensibility is another Key Requirement.
-
“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.
Balance technical and social → Sociotechnical
Why is it “Friendly”?
Here you have an opportunity to highlight more of the social aspects than you currently do. You mention forges being isolated. And having FFF data exchange enabling collaboration. But it goes deeper than that. As phrased here it is rather technical: “I provide you this serialization format, so you can be more social”.
But the creation of FFF itself is a social process. You mention “crowdsourcing”, that is one aspect. But really FFF should represent the “baby that is birthed” and loved by the collective of the forge ecosystem. The “onboarding” starts with people developing a passion for the idea, the concepts and vision that make FFF a worthwhile effort to contribute to.
Then in “Seamless contributor onboarding” you get to explain a mechanism to lower the barriers and friction to actually participate in the crowdsourcing. But here social aspects should be addressed as well. The term “sociotechnical” can be used in the text.
Positioning: forg.es
Given the social aspects, the ecosystem-level scope, I feel strongly that FFF project should be part of forg.es. It can help make this umbrella community meaningful, and it gives independence to the project, same as ForgeFed gives independence to forge federation.
This has additional benefits. I see forg.es as the home of an Ecosystem Alliance where all the sociotechnical ‘cross-cutting’ concerns of forging software (the craft and arts) can be addressed. If there is a crowdsourcing process, then it has to be defined only once. If there are multiple standardization processes, they can be based on the same reference material and improved over time.
Social coding
“Ecosystem Alliance” is a Social Coding best-practice defined by me that is part of the Social Coding FSDL. It is very interesting to elaborate the benefits such alliance can bring, and how it can be established. Note that FSDL is integral part of Social Coding Movement, and hence that it can be part of the Alliance around forges. It would be a great fit. forg.es can be member of the co-shared community (CC @realaravinth). I would love to discuss the ins and outs in more detail.
Process
Given FFF to evolve into a standardized format on the basis of crowdsourcing, a process that allows that must be defined. Creating the process, and organizing to set it in motion should imho be part of the application and time reserved for it.
Maybe you say: “I don’t intend to be involved with that, and anyone can pick up initiative, write a grant application, and organize themself”. Well, that in itself would be a process to clearly highlight in this application. As evaluator of the application I would frown a bit reading that, and matching it to other statements made in the text. So it should be very clear how that intended to work.
You might split into “Technical challenges” and “Organizational challenges”.