#### Past community consultation and User Research

The Free Software community at large has been aware that centralized software forges is a problem for the entire corpus of FLOSS for over two decades:

- 2001 [SourceForge drifting](https://blog.dachary.org/page/39/)
- 2010 [Free Software Needs Free Tools](https://mako.cc/writing/hill-free_tools.html)
- 2022 [State of the Forge Federation](https://forgefriends.org/blog/2022/06/30/2022-06-state-forge-federation/)
- 2023 [State of the Forge Federation](https://forgefriends.org/blog/2023/06/21/2023-06-state-forge-federation/)

In 2021 User Research was conducted to identify the need. It has never been done before and involved software forge developers, system administrators and Free Software developers. The result was published in June 2021 [in a report](https://lab.forgefriends.org/fedeproxy/ux/-/wikis/2021-06-user-research-report). They expressed the need for communication between software forges. They explained, by providing concrete examples from their personal experience, the practical problems that arise because such communication does not exist.

The communities referenced in the State of the Forge Federation (2023 & 2023 were consulted and reviewed the document which explains F3 in context. They include software forge developers (Forgejo and Gitea), software forge system administrators (Codeberg) and Free Software developers.

#### Future User Research and UX design

User Research will be conducted to identify the need of three personae using F3:

* Free Software developers who are unlikely to read the F3 specifications but likely to use the reference implementation API
* Software forge devops who will face challenges on behalf of the Free Software developers using their forges when F3 is involved in export/import or to mirror software projects, either automatically or manually
* Software forge developers who will depend on the F3 specifications to natively implement F3, either from scratch or by using the reference implementation

The User Research report will influence the content of the specifications on each release, the backward compatibility process, the community engagement etc. It will also set priorities for the APIs of the reference implementation, either via the command line or programmatically.

The adoption of F3 is expected to be significantly improved with the answers collected by user research for questions such as:

* Is the quality of the documentation important?
* How much work is required from users when the release of a format is not backward compatible?
* What format transformations are used most?
* etc.

#### Internationalization and accessibility

Free Software developers all read English because most of the documentation they need for their work is only available in English, which lowers the requirement for internationalization. But not all of them are fluent and when the documentation is not available in their native language it makes it significantly more difficult to understand. Internationalization is therefore useful to:

* Lower the barrier of entry for F3 users
* Reduce the risk of incorrect interpretation of the specifications

The specifications will be translated in French and the project submitted to LocalizationLab to foster a community of translators for other languages.

The reference implementation will be internationalized and a workflow similar to the [one in place for the SecureDrop project](https://developers.securedrop.org/en/latest/i18n.html) documented.

A self-hosted Weblate instance will be used to host both localization efforts (specifications and reference implementations).

Since the reference implementation has no user interface other than the command line and the programmatic API, internationalization is the only accessibility requirement.