Improving organization management in Forgejo
In January, I started a 2-year research project on the governance of FOSS projects. I do this as part of the ACES team at Télécom Paris, where I am hosted by Théo Zimmermann and Stefano Zacchiroli. The project is part of the CONGRATS area of the eNSEMBLE funding programme, which looks at the dynamics of online collaboration more broadly.
One part of my project consists in looking into the existing governance dynamics in those projects, trying to identify patterns that work better than others. This involves collecting data from large collections of FOSS projects (via the Software Heritage archive), interviewing people, and analyzing those results. I’ll write more about this later.
In this blog post I want to focus on another line of work I have been following in parallel: designing and implementing governance-related improvements in Forgejo, a forge platform used by a growing share of the FOSS ecosystem.
Why are forge platforms relevant to the governance of the projects they host?
Forge platforms (such as GitHub, GitLab or Forgejo) are popular solutions to coordinate the development of open source software. Beyond hosting files, they allow communication (through tickets or code review discussions) and permissions management, letting teams define various roles and assigning rights to them. The Continuous Integration (CI) systems often associated to forges also allows to define advanced rules and procedures tailored to the project.
Through my experiences in various FOSS projects, I have become convinced that the design of a forge platform has deep implications for the governance of the projects it hosts. In small projects in particular, the participants rarely dedicate much time to negotiate explicit agreements about how they want to function as a team. The consequence of that is simple: the rules of collaboration boil down to what the forge platform allows.
This state of affairs, which can also persist even in not-so-small projects, can lead to many issues. Some of them are well-documented, such as the Ruby Central crisis which started when maintainers of Ruby-related repositories were removed unilaterally without notice. The abandonment of the nvim-treesitter repository which I wrote about earlier is another example: a maintainer, upset by a comment made by a user, decides to unilaterally archive the repository. Because they can. They do so without coordinating with other contributors who might have been happy to continue the work. Beyond such crisis incidents, I believe that the design of the forge platform has many subtle implications on the participant’s mental representation of their rights and responsibilities in the project, how they are credited for their work, how permissions are granted and revoked, and probably much more. I find Nathan Schneider’s thoughts on the “implicit feudalism” that those platforms create particularly convincing on this matter.
How can we improve the governance of FOSS projects at large?
I see two ways:
- to encourage more projects to think about their governance and formalize it, distancing themselves from the default “who’s gonna stop me” model offered by the forge;
- to improve forge platforms so that the default governance they imply is healthier, for instance by preventing uncoordinated destructive actions by design.
Both of those are very ambitious. For the first approach, it’s unrealistic to expect that FOSS contributors would be able to dedicate significant efforts to maintaining governance structures in tiny projects: the effort needs to be proportionate to the size of the community and not overshadow the development and maintenance of the software itself. Beyond that, this first approach is about changing the culture of an entire movement, which cannot happen overnight. But if we switch to the second approach, it’s also unrealistic to expect forges to implement governance models fully. Seth Frey has an excellent blog post explaining why it might not even be desirable: What if governance technologies are the last thing we need?
Despite those difficulties, I think it’s still worth working in both of those complementary directions. On top of that, there is a third way I am interested in:
- to improve forge platforms so that they ease the use of explicit governance models in the projects they host.
With this third way, it’s not about expecting the forge platform to implement all of the governance mechanisms that a project could want to adopt. Instead, I only want the forge to provide a sensible substrate of governance features, making it easier for teams to follow the governance they have adopted. I “just” want the forge not to stand in the way of the agreements people have reached. The actual “implementation” of the governance would remain mostly manual, possibly augmented by external tooling (such as CI configuration or bots) when appropriate.
Why work on Forgejo?
Forgejo is a relatively young and agile open source project, with a project team that seems aligned with those goals. There is a steady stream of projects migrating to Forgejo, be it on Codeberg or by hosting their own Forgejo instance, such as Fedora or FFMPEG. I also have prior experience as a Forgejo contributor and have a deep appreciation for quite a few amazing team members.
What improvements am I looking at?
Before considering more ambitious improvements, I have been working on small fixes in the domain of member management in Forgejo organizations, which also serves as a warming-up exercise.
For instance, the workflow to add a new member to an organization was quite convoluted, so I designed and implemented a better UI for it. This improvement is already deployed on Codeberg. There were also issues with organizations with lots of members, as some lists weren’t properly paginated and user avatars were served at a high resolution, leading to long loading times and poor usability.
I am now working on design proposals for more ambitious features, and seek the feedback from the community on those. Here is an overview of the areas I have identified. I don’t expect to work on all of them: I want to see which proposals meet the most enthusiasm and go for those. I’m also open to shifting my attention to other improvements if they are deemed more promising.
Provenance tracking for memberships
When viewing the list of members of an organization or team, I am not given any information about how those people got their membership. Were they added by someone else? Did they create the organization? Were they added because they authenticated via OAuth from a certain provider? I am thinking of adding this information to the members list, similarly to what GitLab does.
Forgejo links: issue #12567
Visibility of team memberships
Many FOSS projects try to work in the open as much as possible and expect that the composition of their teams is publicly visible. Currently, as an outsider to a Forgejo organization, I can only see the members who explicitly chose to publicize their membership, and I cannot see which exact role they have in the project.
I am considering introducing new settings at the organization and team level enabling to publicize those memberships systematically. To make sure that members consent, I am working on making it possible to decline joining a team, instead of being added directly as is currently the case. In my opinion, this opportunity to decline an invitation would make it acceptable to enforce the visibility of all team members (as they have all consented to that by joining it).
Forgejo links: issue #862, design proposal
Git-based management of organization settings
Some projects store the list of their members (and their roles) in a Git repository. This list is then kept in sync either manually (for instance in xmonad or Mergiraf) or using some automation (in Guix or in Kubernetes). Doing so has the benefit of adding some transparency and offering a natural place to discuss membership changes as pull requests. That is particularly useful given the lack of native workflows for applying to a team, nominating someone for a position and discussing it, proposing the offboarding of inactive members, and so on.
Forgejo could potentially make it possible to create such a “magic repository”, whose contents would be kept in sync with the members of the organization. This could potentially be extended to cover other organization settings. Such a feature would avoid the need for setting up external tools (such as Peribolos, used in Kubernetes) as those require using API tokens with administrative rights and may run into rate-limiting issues, for instance.
Forgejo link: design proposal
Discussion space for membership changes
An alternative to the above would be to offer a native UI in the forge to propose and discuss membership changes. Think of them as discussions similar to pull requests, but associated to an organization instead of a repository, and covering a membership change (such as onboarding or offboarding from a team, which could potentially be proposed by anyone). Let’s call them “nominations”.
This would cater for a simpler UX, which wouldn’t require familiarity with a particular serialization format to represent lists of members in a git repository. It would also likely be safer and simpler to implement, to the cost of some flexibility (for instance, a given “nomination” would only be able to make changes to the membership status of one person at a time). It would likely be harder to extend the feature to cover other organization settings or actions, although there is interest for something along those lines.
Forgejo link: design proposal
Contacting users privately
While most conversations in FOSS projects should happen in public, there are cases where private communication is a better option. This is for instance the case when disclosing vulnerabilities, attempting to defuse a conflict, or coordinating an in-person meeting, for instance. Sarah Novotny makes this argument much better than I can in her blog post Open source needs private spaces.
It is not uncommon for forge users to carefully hide their identity, sometimes without leaving any way of contacting them. Forge platforms like Forgejo or GitHub don’t have any private messaging features (one convoluted way would be to create a private repository, invite the recipient to it, and then create an issue in that private repository).
Instead of implementing yet another private message system in a forge like Forgejo, one could take inspiration from the way MediaWiki offers this feature. This platforms offers an “Email this user” form, which lets any logged-in user send an email to another user through this form. This doesn’t disclose the email address of the recipient but that of the sender. The recipient is free to reply to the email, which lets the two users continue their conversation off-platform.
Forgejo link: design proposal
I want to hear from you!
Would any of this be helpful to you? Should I work on something else? Let me know!