Proposal: Add Forgejo Federation team #433

0xllx0 commented 2026年01月05日 11:03:11 +01:00

Motivation

Some discussion started around the existence of a "Federation Team" to be responsible for tasks related to forge federation.

Federation Team responsibilities

Examples of potential responsibilities:

• forgejo/forgejo federation pull requests + issues
• forgejo-contrib/federation pull requests + issues
• forgejo/sustainability federation pull requests + issues
  • correspondence with grant / funding organizations
• maintaining relevant code.forgejo.org/forgejo/end-to-end end-to-end tests
• upstream contributions to relevant specification repositories
  • ActivityPub
  • ForgeFed
• coordination with other projects implementing federation protocols
• recruiting/mentoring new federation contributors

Why is this team necessary?

@floss4good brought up concerns that adding a new "Federation Team" may not be necessary, especially since other sub-projects under the Forgejo umbrella don't have dedicated teams.

However, I think that federation is in a somewhat unique position. Similar to "devops", the "federation" team would cover a number of sub-projects across different repositories and forges (codeberg.org, code.forgejo.org, etc.). The "Federation Team" would also handle coordination with external projects / organizations, as well as internal Forgejo teams / contributors.

We have already come across an instance where it would be helpful to have contacts responsible for coordinating with external grant orgnanizations.

Creating a new "Federation Team" would also provide a central location for collecting relevant links, repositories, and documents related to ongoing federation work.

For example, adding a document for how to handle communication with outside projects / organizations, specifying how to represent ourselves as a sub-team / working group of the larger Forgejo project.

A number of the example responsibilities are already being handled informally by Forgejo contributors regularly involved in federation work. It would be beneficial to formally define the team for some additional structure.

## Motivation [Some discussion](https://codeberg.org/forgejo/sustainability/pulls/150#issuecomment-9209009) started around the existence of a "Federation Team" to be responsible for tasks related to forge federation. ## Federation Team responsibilities Examples of potential responsibilities: - `forgejo/forgejo` federation pull requests + issues - `forgejo-contrib/federation` pull requests + issues - `forgejo/sustainability` federation pull requests + issues - correspondence with grant / funding organizations - maintaining relevant `code.forgejo.org/forgejo/end-to-end` end-to-end tests - upstream contributions to relevant specification repositories - ActivityPub - ForgeFed - coordination with other projects implementing federation protocols - recruiting/mentoring new federation contributors ## Why is this team necessary? @floss4good brought up concerns that adding a new ["Federation Team" may not be necessary](https://codeberg.org/forgejo/sustainability/pulls/150#issuecomment-9306635), especially since other sub-projects under the Forgejo umbrella don't have dedicated teams. However, I think that federation is in a somewhat unique position. Similar to "devops", the "federation" team would cover a number of sub-projects across different repositories and forges (codeberg.org, code.forgejo.org, etc.). The "Federation Team" would also handle coordination with external projects / organizations, as well as internal Forgejo teams / contributors. We have already come across an instance where it would be helpful to have contacts responsible for coordinating with [external grant orgnanizations](https://codeberg.org/forgejo/sustainability/pulls/150). Creating a new "Federation Team" would also provide a central location for collecting relevant links, repositories, and documents related to ongoing federation work. For example, adding a document for how to handle communication with outside projects / organizations, specifying how to represent ourselves as a sub-team / working group of the larger Forgejo project. A number of the example responsibilities are already being handled informally by Forgejo contributors regularly involved in federation work. It would be beneficial to formally define the team for some additional structure.

Beowulf commented 2026年01月05日 12:36:42 +01:00

I'm unsure if such a team is really needed, the only usecase I see at the moment would be managing permissions of forgejo-contrib/federation, but this repo is in forgejo-contrib so it can be handled informelly.

Otherwise I need to say I don't understand some points or am opposed to them, but thanks for the creation of a discussion, to discuss this in the open with everyone who wants.

---

@0xllx0 wrote in #433 (comment):

Some discussion started around the existence of a "Federation Team" to be responsible for tasks related to forge federation.

It wasn't really intented in this way, but fine :D

@0xllx0 wrote in #433 (comment):

• forgejo/forgejo federation pull requests + issues
• forgejo/sustainability federation pull requests + issues
• maintaining relevant code.forgejo.org/forgejo/end-to-end end-to-end tests

I'm not sure how this is meant? There was never really a responsibility instead people took care about issues or PRs when they have time, energy and have the knowledge to do so.

@0xllx0 wrote in #433 (comment):

• forgejo-contrib/federation pull requests + issues

Yeah, there I could see it, even if I would say it can be handled informally, but there where some issues in the past, so this may could help here.

@0xllx0 wrote in #433 (comment):

• upstream contributions to relevant specification repositories

I'm not sure if/why this needs a special team?

@0xllx0 wrote in #433 (comment):

Creating a new "Federation Team" would also provide a central location for collecting relevant links, repositories, and documents related to ongoing federation work.

For example, adding a document for how to handle communication with outside projects / organizations, specifying how to represent ourselves as a sub-team / working group of the larger Forgejo project.

"central location for collecting" -> Don't know how this is meant? How is a team a location?
"adding a document for how to handle communication with outside projects / organizations" -> It could only be harsher then the general (transparency) rules by the forgejo org. So I don't know in which way this makes sense/is needed.

@0xllx0 wrote in #433 (comment):

• correspondence with grant / funding organizations

We have already come across an instance where it would be helpful to have contacts responsible for coordinating with external grant orgnanizations.

I'm highly against this (if I understand it correctly). Such a team is not intended to get around the otherwise common transparency (discussions etc). And that is my current feeling of the situation. The STA fund is currently causing knee-jerk reactions to solve the problem from the back, even though the problems lie elsewhere.
(Off topic: I have to say that I'm not really happy with the whole STA fund situation at the moment and think that a very cautious and considered approach is needed to ensure that it doesn't drift in the wrong direction.)
There is no other team (I would know of) which handles correspondences by there own in the name of/representing Forgejo (except the moderation team if you would count them).

I'm unsure if such a team is really needed, the only usecase I see at the moment would be managing permissions of `forgejo-contrib/federation`, but this repo is in `forgejo-contrib` so it can be handled informelly. Otherwise I need to say I don't understand some points or am opposed to them, but thanks for the creation of a discussion, to discuss this in the open with everyone who wants. *** @0xllx0 wrote in https://codeberg.org/forgejo/discussions/issues/433#issue-3111269: > [Some discussion](https://codeberg.org/forgejo/sustainability/pulls/150#issuecomment-9209009) started around the existence of a "Federation Team" to be responsible for tasks related to forge federation. It wasn't really intented in this way, but fine :D @0xllx0 wrote in https://codeberg.org/forgejo/discussions/issues/433#issue-3111269: > * `forgejo/forgejo` federation pull requests + issues > * `forgejo/sustainability` federation pull requests + issues > * maintaining relevant `code.forgejo.org/forgejo/end-to-end` end-to-end tests I'm not sure how this is meant? There was never really a responsibility instead people took care about issues or PRs when they have time, energy and have the knowledge to do so. @0xllx0 wrote in https://codeberg.org/forgejo/discussions/issues/433#issue-3111269: > * `forgejo-contrib/federation` pull requests + issues Yeah, there I could see it, even if I would say it can be handled informally, but there where some issues in the past, so this may could help here. @0xllx0 wrote in https://codeberg.org/forgejo/discussions/issues/433#issue-3111269: > * upstream contributions to relevant specification repositories I'm not sure if/why this needs a special team? @0xllx0 wrote in https://codeberg.org/forgejo/discussions/issues/433#issue-3111269: > Creating a new "Federation Team" would also provide a central location for collecting relevant links, repositories, and documents related to ongoing federation work. > > For example, adding a document for how to handle communication with outside projects / organizations, specifying how to represent ourselves as a sub-team / working group of the larger Forgejo project. "central location for collecting" -> Don't know how this is meant? How is a team a location? "adding a document for how to handle communication with outside projects / organizations" -> It could only be harsher then the general (transparency) rules by the forgejo org. So I don't know in which way this makes sense/is needed. @0xllx0 wrote in https://codeberg.org/forgejo/discussions/issues/433#issue-3111269: > * correspondence with grant / funding organizations > > We have already come across an instance where it would be helpful to have contacts responsible for coordinating with external grant orgnanizations. I'm highly against this (if I understand it correctly). Such a team is **not intended to get around the otherwise common transparency** (discussions etc). And that is my current feeling of the situation. The STA fund is currently causing knee-jerk reactions to solve the problem from the back, even though the problems lie elsewhere. _(Off topic: I have to say that I'm not really happy with the whole STA fund situation at the moment and think that a very cautious and considered approach is needed to ensure that it doesn't drift in the wrong direction.)_ There is no other team (I would know of) which handles correspondences by there own in the name of/representing Forgejo (except the moderation team if you would count them).

0xllx0 commented 2026年01月05日 18:46:55 +01:00

@Beowulf wrote in #433 (comment):

@0xllx0 wrote in #433 (comment):

• forgejo/forgejo federation pull requests + issues

I'm not sure how this is meant? There was never really a responsibility instead people took care about issues or PRs when they have time, energy and have the knowledge to do so.

It's meant in the same way as the CODEOWNERS document is, a list of maintainers familiar with federation parts of the codebase. Maybe the CODEOWNER document is enough to cover this part.

@0xllx0 wrote in #433 (comment):

• forgejo-contrib/federation pull requests + issues
• forgejo/sustainability federation pull requests + issues
• maintaining relevant code.forgejo.org/forgejo/end-to-end end-to-end tests

Yeah, there I could see it, even if I would say it can be handled informally, but there where some issues in the past, so this may could help here.

:) I'm good with either one, though I'm still a little unclear on when an informal working group (the current list of contributors who maintain federation code) is at a point where it makes sense to formalize the working group into a Forgejo team.

@0xllx0 wrote in #433 (comment):

• upstream contributions to relevant specification repositories

I'm not sure if/why this needs a special team?

On it's own, it probably doesn't, however it would be one of the responsibilities covered by a "Federation Team". I was just trying to list as much as I could think of regarding what the "Federation Team" would cover. Though, it's definitely not an exhaustive list.

@0xllx0 wrote in #433 (comment):

Creating a new "Federation Team" would also provide a central location for collecting relevant links, repositories, and documents related to ongoing federation work.
For example, adding a document for how to handle communication with outside projects / organizations, specifying how to represent ourselves as a sub-team / working group of the larger Forgejo project.

"central location for collecting" -> Don't know how this is meant? How is a team a location?

Not necessarily the team, but maybe a document/documentation folder the team would maintain for relevant links, practices, etc.

"adding a document for how to handle communication with outside projects / organizations" -> It could only be harsher then the general (transparency) rules by the forgejo org. So I don't know in which way this makes sense/is needed.

I was requested to take over the NLnet grant communications, and apparently made a mistake in how the communication was handled. Had I been given some form of onboarding, referencing existing transparency practices, I think things would have gone very differently.

It is not meant to circumvent existing practices, but to guide people on how to follow those practices. In addition, pointing out any additional practices that may be unique to the "Federation Team" (if they come up).

@0xllx0 wrote in #433 (comment):

• correspondence with grant / funding organizations

We have already come across an instance where it would be helpful to have contacts responsible for coordinating with external grant orgnanizations.

I'm highly against this (if I understand it correctly). Such a team is not intended to get around the otherwise common transparency (discussions etc). And that is my current feeling of the situation. The STA fund is currently causing knee-jerk reactions to solve the problem from the back, even though the problems lie elsewhere. (Off topic: I have to say that I'm not really happy with the whole STA fund situation at the moment and think that a very cautious and considered approach is needed to ensure that it doesn't drift in the wrong direction.) There is no other team (I would know of) which handles correspondences by there own in the name of/representing Forgejo (except the moderation team if you would count them).

It's not intended to side-step the transparency practices, my intention was exactly the opposite. To create and foster a team of contributors who are familiar with existing practices, and can help others who are newer to the project. Again, I would have appreciated such guidance rather than this trial by errors.

Regarding how the STF situation is handled, I'm very interested in your thoughts on how we (the contracted contributors + wider Forgejo community) can improve things.

@Beowulf wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9558680: > @0xllx0 wrote in #433 (comment): > > > * `forgejo/forgejo` federation pull requests + issues > > I'm not sure how this is meant? There was never really a responsibility instead people took care about issues or PRs when they have time, energy and have the knowledge to do so. It's meant in the same way as the `CODEOWNERS` document is, a list of maintainers familiar with federation parts of the codebase. Maybe the `CODEOWNER` document is enough to cover this part. > @0xllx0 wrote in #433 (comment): > > > * `forgejo-contrib/federation` pull requests + issues > > * `forgejo/sustainability` federation pull requests + issues > > * maintaining relevant `code.forgejo.org/forgejo/end-to-end` end-to-end tests > > Yeah, there I could see it, even if I would say it can be handled informally, but there where some issues in the past, so this may could help here. :) I'm good with either one, though I'm still a little unclear on when an informal working group (the current list of contributors who maintain federation code) is at a point where it makes sense to formalize the working group into a Forgejo team. > @0xllx0 wrote in #433 (comment): > > > * upstream contributions to relevant specification repositories > > I'm not sure if/why this needs a special team? On it's own, it probably doesn't, however it would be one of the responsibilities covered by a "Federation Team". I was just trying to list as much as I could think of regarding what the "Federation Team" would cover. Though, it's definitely not an exhaustive list. > @0xllx0 wrote in #433 (comment): > > > Creating a new "Federation Team" would also provide a central location for collecting relevant links, repositories, and documents related to ongoing federation work. > > For example, adding a document for how to handle communication with outside projects / organizations, specifying how to represent ourselves as a sub-team / working group of the larger Forgejo project. > > "central location for collecting" -> Don't know how this is meant? How is a team a location? Not necessarily the team, but maybe a document/documentation folder the team would maintain for relevant links, practices, etc. > "adding a document for how to handle communication with outside projects / organizations" -> It could only be harsher then the general (transparency) rules by the forgejo org. So I don't know in which way this makes sense/is needed. I was requested to take over the NLnet grant communications, and apparently made a mistake in how the communication was handled. Had I been given some form of onboarding, referencing existing transparency practices, I think things would have gone very differently. It is not meant to circumvent existing practices, but to guide people on how to follow those practices. In addition, pointing out any additional practices that may be unique to the "Federation Team" (if they come up). > @0xllx0 wrote in #433 (comment): > > > * correspondence with grant / funding organizations > > > > We have already come across an instance where it would be helpful to have contacts responsible for coordinating with external grant orgnanizations. > > I'm highly against this (if I understand it correctly). Such a team is **not intended to get around the otherwise common transparency** (discussions etc). And that is my current feeling of the situation. The STA fund is currently causing knee-jerk reactions to solve the problem from the back, even though the problems lie elsewhere. _(Off topic: I have to say that I'm not really happy with the whole STA fund situation at the moment and think that a very cautious and considered approach is needed to ensure that it doesn't drift in the wrong direction.)_ There is no other team (I would know of) which handles correspondences by there own in the name of/representing Forgejo (except the moderation team if you would count them). It's not intended to side-step the transparency practices, my intention was exactly the opposite. To create and foster a team of contributors who are familiar with existing practices, and can help others who are newer to the project. Again, I would have appreciated such guidance rather than this trial by errors. Regarding how the STF situation is handled, I'm very interested in your thoughts on how we (the contracted contributors + wider Forgejo community) can improve things.

Beowulf commented 2026年01月05日 18:52:16 +01:00

@0xllx0 wrote in #433 (comment):

Maybe the CODEOWNER document is enough to cover this part.

Yes, I think so.

@0xllx0 wrote in #433 (comment):

:) I'm good with either one, though I'm still a little unclear on when an informal working group (the current list of contributors who maintain federation code) is at a point where it makes sense to formalize the working group into a Forgejo team.

Sry I only wanted to quote the contrib repo in this case. The other two repos should have been part of the previous quote.

@0xllx0 wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9566618: > Maybe the `CODEOWNER` document is enough to cover this part. Yes, I think so. @0xllx0 wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9566618: > :) I'm good with either one, though I'm still a little unclear on when an informal working group (the current list of contributors who maintain federation code) is at a point where it makes sense to formalize the working group into a Forgejo team. Sry I only wanted to quote the contrib repo in this case. The other two repos should have been part of the previous quote.

Beowulf commented 2026年01月05日 18:53:29 +01:00

@0xllx0 wrote in #433 (comment):

I was requested to take over the NLnet grant communications, and apparently made a mistake in how the communication was handled. Had I been given some form of onboarding, referencing existing transparency practices, I think things would have gone very differently.

Ok, this is good to know. But I think in this case the general onboarding/documentation should be improved 😃

@0xllx0 wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9566618: > I was requested to take over the NLnet grant communications, and apparently made a mistake in how the communication was handled. Had I been given some form of onboarding, referencing existing transparency practices, I think things would have gone very differently. Ok, this is good to know. But I think in this case the general onboarding/documentation should be improved 😃

Beowulf commented 2026年01月05日 18:57:28 +01:00

@0xllx0 wrote in #433 (comment):

Again, I would have appreciated such guidance rather than this trial by errors.

Sorry. And yes, I also think the governance repo needs a bit of love, but it needs time and energy and I think nearly everyone is busy with a lot of different things, so this falls a bit behind. :/
I also have notes since month about thinks I want to improve there...

@0xllx0 wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9566618: > Again, I would have appreciated such guidance rather than this trial by errors. Sorry. And yes, I also think the governance repo needs a bit of love, but it needs time and energy and I think nearly everyone is busy with a lot of different things, so this falls a bit behind. :/ I also have notes since month about thinks I want to improve there...

Beowulf commented 2026年01月05日 18:58:45 +01:00

@0xllx0 wrote in #433 (comment):

Regarding how the STF situation is handled, I'm very interested in your thoughts on how we (the contracted contributors + wider Forgejo community) can improve things.

I think a big issue is that most of it/all is secret and that it is not only externally (esp now due to the NLnet thing) 🤷

@0xllx0 wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9566618: > Regarding how the STF situation is handled, I'm very interested in your thoughts on how we (the contracted contributors + wider Forgejo community) can improve things. I think a big issue is that most of it/all is secret and that it is not only externally (esp now due to the NLnet thing) 🤷

0xllx0 commented 2026年01月05日 19:09:42 +01:00

@Beowulf wrote in #433 (comment):

@0xllx0 wrote in #433 (comment):

Regarding how the STF situation is handled, I'm very interested in your thoughts on how we (the contracted contributors + wider Forgejo community) can improve things.

I think a big issue is that most of it/all is secret and that it is not only externally (esp now due to the NLnet thing) 🤷

Right, and I have added my thoughts on how we should go about removing that "secrecy". For example, there is already precedence with the FreeBSD Foundation.

If we could get a rough consensus on what the Forgejo community would like to be made public, I'm sure that would help those of us covered by the NDA make a request in that direction.

@Beowulf wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9566864: > @0xllx0 wrote in #433 (comment): > > > Regarding how the STF situation is handled, I'm very interested in your thoughts on how we (the contracted contributors + wider Forgejo community) can improve things. > > I think a big issue is that most of it/all is secret and that it is not only externally (esp now due to the NLnet thing) :shrug: Right, and I have added my thoughts on how we should go about removing that "secrecy". For example, there is already precedence with the FreeBSD Foundation. If we could get a rough consensus on what the Forgejo community would like to be made public, I'm sure that would help those of us covered by the NDA make a request in that direction.

0xllx0 commented 2026年01月08日 14:54:00 +01:00

@Beowulf wrote in #433 (comment):

I think a big issue is that most of it/all is secret

It is most definitely not "all secret". In fact, the majority of the details of the contract are public. All of our work is public (submitted as PRs to the various Forgejo repos), the work scope is captured in forgejo-contrib/federation milestones, and the majority of our discussions happen in public channels (outside sync-up discussions over the Meissa Jitsi).

So, this continued use of the term "secrecy"/"secret" is very misleading. The NDA is a privacy contract, which requires consulting with STA representatives before publishing information covered by the NDA. Which is why I keep asking Forgejo community members to submit what information they would like to be made public, so that we can request permission to publish it.

So, what information would you like published that is not already public?

@Beowulf wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9566864: > I think a big issue is that most of it/all is secret It is most definitely not "all secret". In fact, the majority of the details of the contract are public. All of our work is public (submitted as PRs to the various Forgejo repos), the work scope is captured in [`forgejo-contrib/federation` milestones](https://codeberg.org/forgejo-contrib/federation/milestones), and the majority of our discussions happen in public channels (outside sync-up discussions over the Meissa Jitsi). So, this continued use of the term "secrecy"/"secret" is very misleading. The NDA is a privacy contract, which requires consulting with STA representatives before publishing information covered by the NDA. Which is why I keep asking Forgejo community members to submit what information they would like to be made public, so that we can request permission to publish it. So, what information would you like published that is not already public?

sclu1034 commented 2026年01月19日 17:00:46 +01:00

@0xllx0 wrote in #433 (comment):

Which is why I keep asking Forgejo community members to submit what information they would like to be made public, so that we can request permission to publish it.

So, what information would you like published that is not already public?

This is a catch-22. We don't know the contents covered by NDA, therefore we cannot name anything from it for you to publish.

@0xllx0 wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9647102: > Which is why I keep asking Forgejo community members to submit what information they would like to be made public, so that we can request permission to publish it. > > So, what information would you like published that is not already public? This is a catch-22. We don't know the contents covered by NDA, therefore we cannot name anything from it for you to publish.

0xllx0 commented 2026年01月19日 18:31:19 +01:00

@sclu1034 wrote in #433 (comment):

This is a catch-22. We don't know the contents covered by NDA, therefore we cannot name anything from it for you to publish.

I guess one could see it as a catch-22, or as a starting point: ask for disclosure of what items are covered by the NDA.

That doesn't require any knowledge of what is covered by the NDA, and it doesn't necessarily ask for the contents of the items covered by the NDA.

Another starting point could be looking at the list of items you would like to know more about. What are you concerned about? What information, that is not currently public, would you like to be made public?

@sclu1034 wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9988638: > This is a catch-22. We don't know the contents covered by NDA, therefore we cannot name anything from it for you to publish. I guess one could see it as a catch-22, or as a starting point: ask for disclosure of what items are covered by the NDA. That doesn't require any knowledge of what is covered by the NDA, and it doesn't necessarily ask for the contents of the items covered by the NDA. Another starting point could be looking at the list of items you would like to know more about. What are you concerned about? What information, that is not currently public, would you like to be made public?

mfenniak commented 2026年01月19日 18:36:28 +01:00

It seems to me that this has gone off-topic with respect to "Proposal: Add Forgejo Federation team".

It seems to me that this has gone off-topic with respect to "Proposal: Add Forgejo Federation team".

0xllx0 commented 2026年01月19日 18:51:33 +01:00

@mfenniak wrote in #433 (comment):

It seems to me that this has gone off-topic with respect to "Proposal: Add Forgejo Federation team".

Sure, we can refocus this issue on adding a federation team.

I think there are still enough reasons to create the team that aren't already handled by existing structures. For instance, both @famfo and myself are now in the CODEOWNERS file for federation-related code, but that only covers code in the forgejo/forgejo repository. @famfo is also working on code.forgejo.org/forgejo/end-to-end. I'm sure there will be plenty more work to do there as things progress.

I've also needed to make changes to the forgejo/docs#1672 repo.

There are a number of outside organizations and projects that we will need to coordinate with, like GoToSocial and Mastodon.

There are federation-specific RFCs, libraries, specifications, etc.

There are federation-specific concepts and design decisions. For example, how ForgeFed access control interacts with existing Forgejo access control.

We have an ongoing grant funded for federation-specific work, with another open proposal to fund federation-specific work.

At what threshold does an informal group of contributors merit forming into a formal Forgejo Team?

@mfenniak wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9990243: > It seems to me that this has gone off-topic with respect to "Proposal: Add Forgejo Federation team". Sure, we can refocus this issue on adding a federation team. I think there are still enough reasons to create the team that aren't already handled by existing structures. For instance, both @famfo and myself are now in the `CODEOWNERS` file for federation-related code, but that only covers code in the `forgejo/forgejo` repository. @famfo is also working on [code.forgejo.org/forgejo/end-to-end](https://code.forgejo.org/forgejo/end-to-end/pulls/1276). I'm sure there will be plenty more work to do there as things progress. I've also needed to make changes to the [forgejo/docs#1672](https://codeberg.org/forgejo/docs/pulls/1672) repo. There are a number of outside organizations and projects that we will need to coordinate with, like GoToSocial and Mastodon. There are federation-specific RFCs, libraries, specifications, etc. There are federation-specific concepts and design decisions. For example, how [ForgeFed access control interacts with existing Forgejo access control](https://codeberg.org/forgejo/forgejo/issues/9887). We have an ongoing grant funded for federation-specific work, with another open proposal to fund federation-specific work. At what threshold does an informal group of contributors merit forming into a formal Forgejo Team?

famfo commented 2026年01月19日 19:11:29 +01:00

Since I've been mentioned here, might as well leave an opinion:

I don't fully see the need for such a team, access control to contrib/federation can- and currently is handled ad-hoc for people who contribute architectural proposals for the federation code. In my opinion, this is enough, this is not like a mergers team for the rest of forgejo, I am happy with informally maintaining the code I've contributed to tests for example, be it federation related or not. At the end of the day the code should be documented and written well enough for someone who is not knee deep into ActivityPub to maintain.

If a team is created purely to handle document I would count myself out of it, that sounds like more of an administrative task which should be handled somewhere else. Personally, I do not have the motivation commit myself to handling this.

Since I've been mentioned here, might as well leave an opinion: I don't fully see the need for such a team, access control to contrib/federation can- and currently is handled ad-hoc for people who contribute architectural proposals for the federation code. In my opinion, this is enough, this is not like a mergers team for the rest of forgejo, I am happy with informally maintaining the code I've contributed to tests for example, be it federation related or not. At the end of the day the code should be documented and written well enough for someone who is not knee deep into ActivityPub to maintain. If a team is created purely to handle document I would count myself out of it, that sounds like more of an administrative task which should be handled somewhere else. Personally, I do not have the motivation commit myself to handling this.

0xllx0 commented 2026年01月19日 20:35:28 +01:00

@famfo wrote in #433 (comment):

Since I've been mentioned here, might as well leave an opinion:

I don't fully see the need for such a team, access control to contrib/federation can- and currently is handled ad-hoc for people who contribute architectural proposals for the federation code. In my opinion, this is enough, this is not like a mergers team for the rest of forgejo, I am happy with informally maintaining the code I've contributed to tests for example, be it federation related or not. At the end of the day the code should be documented and written well enough for someone who is not knee deep into ActivityPub to maintain.

Absolutely, I'm all for self-documenting code, and am trying to further that goal by documenting code that I write/edit.

However, there are contributors who are more familiar with federation related specifications and concepts. There are contributors who are more involved with implementing federation related code. This is currently organized on an ad-hoc basis. Maybe that's fine for the time-being, especially while federation is still being implemented (pre-alpha stage).

I think one of the more beneficial outcomes of this discussion would be at what point the ad-hoc organization becomes
a more formally defined "Forgejo Team".

If a team is created purely to handle document I would count myself out of it, that sounds like more of an administrative task which should be handled somewhere else. Personally, I do not have the motivation commit myself to handling this.

No, I don't see it as purely handling documentation, and that is an interesting interpretation of what I have written.

What I am asking is when does the current ad-hoc federation team cross a threshold of becoming a more formal "Forgejo Team".

In the sense that I'm sure at some point there was an ad-hoc group of contributors that handled dev-ops or security responsibilities, and at some point those became formal "Forgejo Teams".

@famfo wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9991101: > Since I've been mentioned here, might as well leave an opinion: > > I don't fully see the need for such a team, access control to contrib/federation can- and currently is handled ad-hoc for people who contribute architectural proposals for the federation code. In my opinion, this is enough, this is not like a mergers team for the rest of forgejo, I am happy with informally maintaining the code I've contributed to tests for example, be it federation related or not. At the end of the day the code should be documented and written well enough for someone who is not knee deep into ActivityPub to maintain. Absolutely, I'm all for self-documenting code, and am trying to further that goal by documenting code that I write/edit. However, there are contributors who are more familiar with federation related specifications and concepts. There are contributors who are more involved with implementing federation related code. This is currently organized on an ad-hoc basis. Maybe that's fine for the time-being, especially while federation is still being implemented (pre-alpha stage). I think one of the more beneficial outcomes of this discussion would be at what point the ad-hoc organization becomes a more formally defined "Forgejo Team". > If a team is created purely to handle document I would count myself out of it, that sounds like more of an administrative task which should be handled somewhere else. Personally, I do not have the motivation commit myself to handling this. No, I don't see it as purely handling documentation, and that is an interesting interpretation of what I have written. What I am asking is when does the current ad-hoc federation team cross a threshold of becoming a more formal "Forgejo Team". In the sense that I'm sure at some point there was an ad-hoc group of contributors that handled dev-ops or security responsibilities, and at some point those became formal "Forgejo Teams".

Beowulf commented 2026年01月19日 21:58:01 +01:00

@0xllx0 wrote in #433 (comment):

I think there are still enough reasons to create the team that aren't already handled by existing structures. For instance, both @famfo and myself are now in the CODEOWNERS file for federation-related code, but that only covers code in the forgejo/forgejo repository. @famfo is also working on code.forgejo.org/forgejo/end-to-end. I'm sure there will be plenty more work to do there as things progress.

I can only reference my above comment (#433 (comment)). I don't understand the reasons mentioned here. We also do not have documented Frontend, Backend, Git, etc teams. When people are active in code regions they are active in this region - I don't see a need to add a team around this? This just gives me a "we just need bureaucracy without benefit" vibes.

@famfo wrote in #433 (comment):

I don't fully see the need for such a team, access control to contrib/federation can- and currently is handled ad-hoc for people who contribute architectural proposals for the federation code. In my opinion, this is enough

Can only second this. 👇 There were only confusion sometime ago, but I think it got already resolved and a team would just be unnecessary work on top...

@Beowulf wrote in #433 (comment):

I'm unsure if such a team is really needed, the only usecase I see at the moment would be managing permissions of forgejo-contrib/federation, but this repo is in forgejo-contrib so it can be handled informelly.

@0xllx0 wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9990585: > I think there are still enough reasons to create the team that aren't already handled by existing structures. For instance, both @famfo and myself are now in the `CODEOWNERS` file for federation-related code, but that only covers code in the `forgejo/forgejo` repository. @famfo is also working on [code.forgejo.org/forgejo/end-to-end](https://code.forgejo.org/forgejo/end-to-end/pulls/1276). I'm sure there will be plenty more work to do there as things progress. I can only reference my above comment (https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9558680). I don't understand the reasons mentioned here. We also do not have documented Frontend, Backend, Git, etc teams. When people are active in code regions they are active in this region - I don't see a need to add a team around this? This just gives me a "we just need bureaucracy without benefit" vibes. @famfo wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9991101: > I don't fully see the need for such a team, access control to contrib/federation can- and currently is handled ad-hoc for people who contribute architectural proposals for the federation code. In my opinion, this is enough Can only second this. 👇 There were only confusion sometime ago, but I think it got already resolved and a team would just be unnecessary work on top... @Beowulf wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9558680: > I'm unsure if such a team is really needed, the only usecase I see at the moment would be managing permissions of `forgejo-contrib/federation`, but this repo is in `forgejo-contrib` so it can be handled informelly.

0xllx0 commented 2026年01月20日 00:18:12 +01:00

@Beowulf wrote in #433 (comment):

When people are active in code regions they are active in this region - I don't see a need to add a team around this? This just gives me a "we just need bureaucracy without benefit" vibes.

Fair enough, I'm not one to push for unnecessary bureaucracy.

Still leaves one question unanswered: at what point do ad-hoc groups of contributors become a "Forgejo Team"?

There were only confusion sometime ago, but I think it got already resolved and a team would just be unnecessary work on top.

For sure, glad we had this conversation to further clarify things.

@Beowulf wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9993441: > When people are active in code regions they are active in this region - I don't see a need to add a team around this? This just gives me a "we just need bureaucracy without benefit" vibes. Fair enough, I'm not one to push for unnecessary bureaucracy. Still leaves one question unanswered: at what point do ad-hoc groups of contributors become a "Forgejo Team"? > There were only confusion sometime ago, but I think it got already resolved and a team would just be unnecessary work on top. For sure, glad we had this conversation to further clarify things.

mahlzahn commented 2026年01月20日 00:36:57 +01:00

@0xllx0 wrote in #433 (comment):

Still leaves one question unanswered: at what point do ad-hoc groups of contributors become a "Forgejo Team"?

I think as soon as special permissions are required. (I currently don't foresee them for federation, but who knows). Federation can/will only work hand in hand with Forgejo general development.

@0xllx0 wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9995319: > Still leaves one question unanswered: at what point do ad-hoc groups of contributors become a "Forgejo Team"? I think as soon as special permissions are required. (I currently don't foresee them for federation, but who knows). Federation can/will only work hand in hand with Forgejo general development.

mfenniak commented 2026年01月20日 04:02:32 +01:00

@mahlzahn wrote in #433 (comment):

I think as soon as special permissions are required.

As a counter-point to that: I don't think the Accessibility, User Interface and User Research teams have specific permissions, but I could be mistaken.

I think I would've described a team more in terms of something that can be described with specific responsibilities, rather than specific permissions.

I've seen some discussion in one of the Matrix chat rooms which suggested to me that federation PRs going through one code review by contributors who are deeply involved in the federation project (more informed on ActivityPub, ForgeFed, current project status, future plans) and then a general code review by a merger (more concerned with aligning with Forgejo patterns and practices, and with a mindset removed from federation involvement). I'm not sure if I followed that correctly when it came up; it may have just been a proposal, or it may have been misunderstood.

If there was a specific process like that and the team served as a part of the process, I think that'd be a reasonable justification for a team. (@0xllx0 did start this thread with a set of example responsibilities. I think they're vague, but they were intended as examples to start a discussion. 🙂)

The security team recently received an external report of a small metadata leak in Forgejo related to a federation feature. I could see handling issues like this within the theoretical scope of a federation team; they'd be better equipped with specific knowledge than the security team, and security is stretched thin to work on vulnerabilities on a non-production-quality feature.

I'm neutral on the idea of a federation team overall. I'm not sure it's different enough than any other feature development team, but I can see a bit of a reason.

@mahlzahn wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9995469: > I think as soon as special permissions are required. As a counter-point to that: I don't think the Accessibility, User Interface and User Research teams have specific permissions, but I could be mistaken. I think I would've described a team more in terms of something that can be described with specific responsibilities, rather than specific permissions. I've seen some discussion in one of the Matrix chat rooms which suggested to me that federation PRs going through one code review by contributors who are deeply involved in the federation project (more informed on ActivityPub, ForgeFed, current project status, future plans) and then a general code review by a merger (more concerned with aligning with Forgejo patterns and practices, and with a mindset removed from federation involvement). I'm not sure if I followed that correctly when it came up; it may have just been a proposal, or it may have been misunderstood. If there was a specific process like that and the team served as a part of the process, I think that'd be a reasonable justification for a team. (@0xllx0 did start this thread with a set of example responsibilities. I think they're vague, but they were intended as examples to start a discussion. 🙂) The security team recently received an external report of a small metadata leak in Forgejo related to a federation feature. I could see handling issues like this within the theoretical scope of a federation team; they'd be better equipped with specific knowledge than the security team, and security is stretched thin to work on vulnerabilities on a non-production-quality feature. I'm neutral on the idea of a federation team overall. I'm not sure it's different enough than any other feature development team, but I can see a bit of a reason.

Beowulf commented 2026年01月20日 05:32:42 +01:00

@mfenniak wrote in #433 (comment):

As a counter-point to that: I don't think the Accessibility, User Interface and User Research teams have specific permissions, but I could be mistaken.

Yes, but I think it is a baseline in modt cases, when a team is needed.

@mfenniak wrote in #433 (comment):

I'm neutral on the idea of a federation team overall. I'm not sure it's different enough than any other feature development team

I'm also not against it (I'm just unsure if such a team is really needed), esp because I think the main points why a creation is now initiated are already handle through standard contributor handling.

But this could be reasons for me:

@mfenniak wrote in #433 (comment):

federation PRs going through one code review by contributors who are deeply involved in the federation project and then a general code review by a merger

---

Maybe the STA fund and the kinda mention above, which didn't gave me good vibes is why I'm not so "in favor" in general 🤔
And maybe that teams (agreements etc) are bureaucracy and if we look at e.g. the UI team - I think it is kinda a dead team and never fullfilled the target goal. Therefore I'm trying to find specific reasons, why this team will not be a dead team/a team just for "documentation purposes" in the future...

@mfenniak wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9997647: > As a counter-point to that: I don't think the Accessibility, User Interface and User Research teams have specific permissions, but I could be mistaken. Yes, but I think it is a baseline in modt cases, when a team is needed. @mfenniak wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9997647: > I'm neutral on the idea of a federation team overall. I'm not sure it's different enough than any other feature development team I'm also not against it (I'm just unsure if such a team is really needed), esp because I think the main points why a creation is now initiated are already handle through standard contributor handling. But this could be reasons for me: @mfenniak wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9997647: > federation PRs going through one code review by contributors who are deeply involved in the federation project and then a general code review by a merger *** Maybe the STA fund and the kinda mention above, which didn't gave me good vibes is why I'm not so "in favor" in general 🤔 And maybe that teams (agreements etc) are bureaucracy and if we look at e.g. the UI team - I think it is kinda a dead team and never fullfilled the target goal. Therefore I'm trying to find specific reasons, why this team will not be a dead team/a team just for "documentation purposes" in the future...

0xllx0 commented 2026年01月20日 21:59:18 +01:00

@mfenniak wrote in #433 (comment):

I'm neutral on the idea of a federation team overall. I'm not sure it's different enough than any other feature development team, but I can see a bit of a reason.

Even if it becomes a sub-team (do those exist?), or just remains an ad-hoc group of contributors, I think this discussion has already been productive.

For the moment, I don't think there is a lot of pressure to formalize the group of contributors working on federation-related code + infrastructure. When/if federation becomes a proper, production-ready feature in a Forgejo release, a decision on a "Federation Team" may be more important.

@Beowulf wrote in #433 (comment):

Therefore I'm trying to find specific reasons, why this team will not be a dead team/a team just for "documentation purposes" in the future...

That's a good point that I didn't have the context for before you mentioned it. I'd very much like for the opposite to happen, where we get more people involved in Forgejo development in general, and Forgejo Federation development specifically.

If the best way to achieve those goals is to keep the current group of federation contributors ad-hoc, then I'm fine with that.

One goal of this issue was to flesh out the details for when it makes sense to create a "Federation Team", if ever.

@mfenniak wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9997647: > I'm neutral on the idea of a federation team overall. I'm not sure it's different enough than any other feature development team, but I can see a bit of a reason. Even if it becomes a sub-team (do those exist?), or just remains an ad-hoc group of contributors, I think this discussion has already been productive. For the moment, I don't think there is a lot of pressure to formalize the group of contributors working on federation-related code + infrastructure. When/if federation becomes a proper, production-ready feature in a Forgejo release, a decision on a "Federation Team" may be more important. @Beowulf wrote in https://codeberg.org/forgejo/discussions/issues/433#issuecomment-9998289: > Therefore I'm trying to find specific reasons, why this team will not be a dead team/a team just for "documentation purposes" in the future... That's a good point that I didn't have the context for before you mentioned it. I'd very much like for the opposite to happen, where we get more people involved in Forgejo development in general, and Forgejo Federation development specifically. If the best way to achieve those goals is to keep the current group of federation contributors ad-hoc, then I'm fine with that. One goal of this issue was to flesh out the details for when it makes sense to create a "Federation Team", if ever.

jerger commented 2026年01月22日 10:39:44 +01:00

Hmmm ... just to drop my 2 cents here.

It might be nice to have a common agreed name of the group contributing around federation.

By always listing names I always fear to miss someone who has contributed or is just interested in. Having a name and listed members would make this easier.

But as there is no other function / authorization is bound to such a team, I would not vote to create a federation team here.

Maybe it is good enough to collect names somewhere in https://codeberg.org/forgejo-contrib/federation ?

Hmmm ... just to drop my 2 cents here. It might be nice to have a common agreed name of the group contributing around federation. By always listing names I always fear to miss someone who has contributed or is just interested in. Having a name and listed members would make this easier. But as there is no other function / authorization is bound to such a team, I would not vote to create a federation team here. Maybe it is good enough to collect names somewhere in https://codeberg.org/forgejo-contrib/federation ?