Starting this month, an update of what happens in the F3 project will be published monthly. It is a high level view of the project activities that is useful to follow its progress from a distance.
Summary
There were plans to engage into user research in 2023 before attempting to define the format and start with a reference implementation. It is best to do that early because it can deeply redefine the goals of a project.
In the past months a full refactor of the first iteration of the reference implementation began. It is not complete yet and now is the perfect time to start with user research. It however reached a point where the second version of the schemas should be considered stable and version 2 was published and the documentation updated.
Tasks
Schemas
The version 2 of the F3 Schema was tagged and a new branch cut. It is the new stable version of the schema. It is the result of changes required by the gof3 refactor. It will not be modified significantly until the refactor is complete and usable.
When the idea of F3 emerged in 2022, it was heavily influenced by the Gitea implementation of the export / import functions. That showed in how the schemas were designed in the first version and turned out to be lacking in a few important aspects while working on the gof3 implementation.
- attachments are not limited to releases or issues comments, they need to be generalized to be objects that are content addressable, also fit for storing the content of packages (OCI images for instance)
- CI was not formalized because it seemed impossible to convert the format of one CI into another. But there is no need to as long as a given CI is able to run another CI for data portability purposes. For instance the Forgejo CI can run the GitLab CI as well as GitLab. This kind of recursion, running a forge in a forge, is possible when they are Free Software. In the case of GitHub, although the runner is Free Software, the server is not and this option is not available. However, Forgejo implements an internal CI that has a syntax that is partly compatible with GitHub Actions and has been successfully used to re-use a number of actions from the marketplace.
- identifiers are strings and not numbers: this is the most impactful change of the v2 version. In v1 numbers were created by hashing strings when a resource (such as an object) does not already have a numerical unique identifier. Another problem with this requirement was making F3 paths difficult to read for humans. For instance
/forge/users/234/projects/433although unambiguous is harder to read than/forge/users/myself/projects/myproject.
User Research
- Create the spaces dedicated to user research (forum and repository)
- Choose a user research methodology
- Write down an intercept interview script and an invitation email
- Reach out to potential interviewees
gof3 refactor
In October a full refactor of the gof3 implementation began to address the architectural shortcomings of the current version. It is not complete yet but reached a stage where it is good enough. The new foundations will now be used to adapt the existing drivers (GitLab, Forgejo, Gitea) to the new architecture.
Wikidata Forge project
The Forge project is updated regularly to cover all existing forges and is used to update the forge software comparison matrix. It grows as more properties and qualifiers are defined in the Forge project and the FLOSS project.
The supporting library has been updated to extract licensing information and distinguish between Free Software forges and proprietary forges. It is sometime difficult to tell the two apart when a forge is Open Core as it presents itself as Free Software and it is not immediately clear that there also exists a proprietary side of it. In one case it was even discovered that the code repository was withdrawn silently from the project.
Plans for the next month
- Conduct the interviews
- Continue with the gof3 refactor