Planning to work on governance-related features in Forgejo #396

wetneb commented 2025年10月01日 11:43:56 +02:00

I want to share that I'm planning to increase my contributions in Forgejo in the coming two years.
The context is that I'm applying for a research position which will be about studying and improving the governance of small FOSS projects. Note that it is not sure whether I will have the position or not - if not, I hope to still do some of this work, but it will have to be on my free time.

Background

My current take on it is that most small FOSS projects don't think a lot about their governance and that the forge platform they use shapes their de-facto governance quite a lot (by virtue of the default permission models, of the terminology used, of fork-and-PR model, and so on). This leads to all sorts of issues, also in bigger projects: the governance issues in Gitea that lead to the creation of Forgejo of course, but also the xz-utils or event-stream incidents, or the current conflict in the Ruby ecosystem.

So I think it's important to improve forges so that they encourage healthy governance, and I think Forgejo is the ideal forge for that. You can read more about my thoughts on this topic in this blog post.

Which governance-related features?

For now I am thinking about things like:

• making it possible to request joining a Forgejo organization, or even nominate someone else
• managing the members of an org in a git repository (in a "GitOps"-way), and possibly other organization settings (similarly to github-org-manager)
• developing usable workflows around the expiration of membership for inactive members
• making it possible to enforce that the membership to a given organization is always public
• encouraging the adoption of a governance model at repository creation
• creating a workflow for filing code of conduct reports to a project (not to the instance moderators)

But also things that aren't directly governance related but still have an impact on team health, such as:

• making it possible to contact a Forgejo user privately even if they don't disclose their email address
• advertising active forks of unmaintained repositories

The scope is intentionally broad and open minded, to adapt the project to the needs that I discover later.

How will you work on those features?

I'm expecting to do a lot of design work (including on their prioritization). I'm keen to have that happen in a way that enables others to participate, for instance within the forgejo/design repo. I don't have a lot of experience in UX research but I'm keen to try out new things.

If some ideas converge towards consensual features, I would love to implement them in Forgejo as well of course.
I'm also planning to increase my contributions to Forgejo as a whole, as a way to help out in other areas too, and to pay forward the reviewing effort that my proposals will generate. If there are particular tasks where you think help would be welcome, let me know.

My questions to the Forgejo community

• Do you think this work would be beneficial to Forgejo?
• Do you have suggestions of other improvements that could be in scope?
• Do you have interest in getting involved in any capacity?

I want to share that I'm planning to increase my contributions in Forgejo in the coming two years. The context is that I'm applying for a research position which will be about studying and improving the governance of small FOSS projects. Note that it is not sure whether I will have the position or not - if not, I hope to still do some of this work, but it will have to be on my free time. #### Background My current take on it is that most small FOSS projects don't think a lot about their governance and that the forge platform they use shapes their de-facto governance quite a lot (by virtue of the default permission models, of the terminology used, of fork-and-PR model, and so on). This leads to all sorts of issues, also in bigger projects: the governance issues in Gitea that lead to the creation of Forgejo of course, but also the xz-utils or event-stream incidents, or the current conflict in the Ruby ecosystem. So I think it's important to improve forges so that they encourage healthy governance, and I think Forgejo is the ideal forge for that. You can read more about my thoughts on this topic [in this blog post](https://antonin.delpeuch.eu/posts/off-the-shelf-governance-models-for-small-foss-projects/). #### Which governance-related features? For now I am thinking about things like: * making it possible to request joining a Forgejo organization, or even nominate someone else * managing the members of an org in a git repository (in a "GitOps"-way), and possibly other organization settings (similarly to [github-org-manager](https://github.com/OpenRailAssociation/github-org-manager)) * developing usable workflows around the expiration of membership for inactive members * making it possible to enforce that the membership to a given organization is always public * encouraging the adoption of a governance model at repository creation * creating a workflow for filing code of conduct reports to a project (not to the instance moderators) But also things that aren't directly governance related but still have an impact on team health, such as: * making it possible to contact a Forgejo user privately even if they don't disclose their email address * advertising active forks of unmaintained repositories The scope is intentionally broad and open minded, to adapt the project to the needs that I discover later. #### How will you work on those features? I'm expecting to do a lot of design work (including on their prioritization). I'm keen to have that happen in a way that enables others to participate, for instance within the [forgejo/design](https://codeberg.org/forgejo/design) repo. I don't have a lot of experience in UX research but I'm keen to try out new things. If some ideas converge towards consensual features, I would love to implement them in Forgejo as well of course. I'm also planning to increase my contributions to Forgejo as a whole, as a way to help out in other areas too, and to pay forward the reviewing effort that my proposals will generate. If there are particular tasks where you think help would be welcome, let me know. #### My questions to the Forgejo community * Do you think this work would be beneficial to Forgejo? * Do you have suggestions of other improvements that could be in scope? * Do you have interest in getting involved in any capacity?

earl-warren commented 2025年10月01日 12:20:03 +02:00

This is one of the most difficult problem in the Free Software ecosystem and I'm very happy that you decided to spend significant time trying to make progress. There has been zillions of efforts to both understand and solve some of the problems you hint. But they all have one thing in common: underestimating the magnitude and the difficult of the task at hand 😁 I sincerely hope you get to spend two years trying to tackle that: you would be the first (well there has been people doing their social science master thesis on that topic but they also had to learn pretty much everything about software, development and Free Software so the reality is that they had little time left to even begin to figure out where the problems are).

Do you think this work would be beneficial to Forgejo?

Yes.

Do you have suggestions of other improvements that could be in scope?

Not right now. The list you have is nice in the sense that it looks like it looks possible to addressed each item independently. And even slice each of them is increments that have their individual merits in addition to fitting together.

Do you have interest in getting involved in any capacity?

I stand ready to participate in the design process as soon you get started (minus 2026).

I'm also planning to increase my contributions to Forgejo as a whole, as a way to help out in other areas too, and to pay forward the reviewing effort that my proposals will generate. If there are particular tasks where you think help would be welcome, let me know.

There is an immense pressure on feature requests at the moment. The time you can spend on triaging, aggregating, closing existing feature requests will greatly improve the odds that your own feature requests get the attention they deserve. I think (gut feeling) that reviewing the oldest 500 feature requests and organizing them in the design repository has the potential of being rewarding for the people who discussed about them because it shows they are making progress and also allow hundred of them to move out of the main forgejo repository where they are currently lost in the huge pile.

I'm sure there are other ways to answer your question, this is just my 2cts 😁

This is one of the most difficult problem in the Free Software ecosystem and I'm very happy that you decided to spend significant time trying to make progress. There has been zillions of efforts to both understand and solve some of the problems you hint. But they all have one thing in common: underestimating the magnitude and the difficult of the task at hand 😁 I sincerely hope you get to spend two years trying to tackle that: you would be the first (well there has been people doing their social science master thesis on that topic but they also had to learn pretty much everything about software, development and Free Software so the reality is that they had little time left to even begin to figure out where the problems are). > Do you think this work would be beneficial to Forgejo? Yes. > Do you have suggestions of other improvements that could be in scope? Not right now. The list you have is nice in the sense that it looks like it looks possible to addressed each item independently. And even slice each of them is increments that have their individual merits in addition to fitting together. > Do you have interest in getting involved in any capacity? I stand ready to participate in the design process as soon you get started (minus 2026). > I'm also planning to increase my contributions to Forgejo as a whole, as a way to help out in other areas too, and to pay forward the reviewing effort that my proposals will generate. If there are particular tasks where you think help would be welcome, let me know. There is an immense pressure on feature requests at the moment. The time you can spend on triaging, aggregating, closing existing feature requests will greatly improve the odds that your own feature requests get the attention they deserve. I think (gut feeling) that reviewing the oldest 500 feature requests and organizing them in the design repository has the potential of being rewarding for the people who discussed about them because it shows they are making progress and also allow hundred of them to move out of the main forgejo repository where they are currently lost in the huge pile. I'm sure there are other ways to answer your question, this is just my 2cts 😁

mfenniak commented 2025年10月01日 21:43:40 +02:00

I think this is a brilliant effort. I've had a few Open Source projects that have gained mild user communities that have exceeded my capability to support them, and with the lack of any governance thoughts they've ended up as a fork mess over time.

Do you think this work would be beneficial to Forgejo?

I think so. It is a big challenge for a project to be focused on needs that are aligned with its vision and to be able to effectively say "no" to features that add more maintenance drain then they add value. What you've described in terms of specific features seem like they fit within that window to me.

Do you have suggestions of other improvements that could be in scope?

One item mentioned in your blog post is that "To be able to add co-owners, one needs to create an organization and transfer the ownership...". This seems like a pretty arbitrary rule to me, and might stand in the way of someone opening up a project for collaboration -- I didn't start it in an org, so, I'll never move it. Some of the capabilities of an org could be extended to a repo so that this barrier doesn't exist, such as creating teams within a repo.

I could also imagine some improved mechanisms to support collaborative decision-making. For example, "vote by emoji reaction" (#366 (comment)) is an OK approach to polling for alignment, but... how about putting a poll into a markdown comment? A poll with "allow multiple selection" or "allow one selection", and, "public access" or "limited to team".

Do you have interest in getting involved in any capacity?

I'm interested, but unwilling to make a solid commitment. I'm happy to share my experiences in user research. If actionable dev items arrive, I could easily be convinced to pick up moderate-sized items for implementation.

I think this is a brilliant effort. I've had a few Open Source projects that have gained mild user communities that have exceeded my capability to support them, and with the lack of any governance thoughts they've ended up as a fork mess over time. > Do you think this work would be beneficial to Forgejo? I think so. It is a big challenge for a project to be focused on needs that are aligned with its vision and to be able to effectively say "no" to features that add more maintenance drain then they add value. What you've described in terms of specific features seem like they fit within that window to me. > Do you have suggestions of other improvements that could be in scope? One item mentioned in your blog post is that "To be able to add co-owners, one needs to create an organization and transfer the ownership...". This seems like a pretty arbitrary rule to me, and might stand in the way of someone opening up a project for collaboration -- I didn't start it in an org, so, I'll never move it. Some of the capabilities of an org could be extended to a repo so that this barrier doesn't exist, such as creating teams within a repo. I could also imagine some improved mechanisms to support collaborative decision-making. For example, "vote by emoji reaction" (https://codeberg.org/forgejo/discussions/issues/366#issuecomment-6014572) is an OK approach to polling for alignment, but... how about putting a poll into a markdown comment? A poll with "allow multiple selection" or "allow one selection", and, "public access" or "limited to *team*". > Do you have interest in getting involved in any capacity? I'm interested, but unwilling to make a solid commitment. I'm happy to share my experiences in user research. If actionable dev items arrive, I could easily be convinced to pick up moderate-sized items for implementation.

earl-warren commented 2025年10月02日 09:50:07 +02:00

Do you have suggestions of other improvements that could be in scope?

Decision making tooling. For consensus based decisions (strong consensus, all concerns have to be addressed), it would help to be guided by tools. Although it is not a problem at the moment in Forgejo, it only works because of how past decisions were made and how current contributor understand the process.

Decision making is tricky and there are many ways to make it too complicated. The current decision making process of Forgejo has many steps and cases that made sense when designed. But they are not used in practice and it could be simplified. Doing so in Forgejo would take time and discussions: it is doable and I believe it will happen in the future. If, however, this decision making process was supported by software that had to be changed, it would be a lot more complicated.

Finding a balance between tooling that help with the decision process and does not over complicate things is difficult.

> Do you have suggestions of other improvements that could be in scope? Decision making tooling. For consensus based decisions (strong consensus, all concerns have to be addressed), it would help to be guided by tools. Although it is not a problem at the moment in Forgejo, it only works because of how past decisions were made and how current contributor understand the process. Decision making is tricky and there are many ways to make it too complicated. The current decision making process of Forgejo has many steps and cases that made sense when designed. But they are not used in practice and it could be simplified. Doing so in Forgejo would take time and discussions: it is doable and I believe it will happen in the future. If, however, this decision making process was supported by software that had to be changed, it would be a lot more complicated. Finding a balance between tooling that help with the decision process and does not over complicate things is difficult.

wetneb commented 2025年11月25日 22:54:58 +01:00

Update: the position has been confirmed and will start in January. Looking forward to spending more time on Forgejo!

Update: the position has been confirmed and will start in January. Looking forward to spending more time on Forgejo!

earl-warren commented 2025年11月26日 09:22:10 +01:00

This is excellent news.

This is excellent news.

wetneb commented 2026年05月19日 16:52:42 +02:00

I have published a blog post which gives an update on this effort, with links to various Forgejo design proposals.

It doesn't include proposals around decision making and voting systems, because I haven't got a good enough overview of the sorts of voting systems people use in FOSS projects yet. But I have it on my radar :)

I have published a blog post which [gives an update on this effort](https://antonin.delpeuch.eu/posts/improving-organization-management-in-forgejo/), with links to various Forgejo design proposals. It doesn't include proposals around decision making and voting systems, because I haven't got a good enough overview of the sorts of voting systems people use in FOSS projects yet. But I have it on my radar :)