Team Nesting

2024-05-17 by Pere Lev

The previous post was about project nesting. Most of what I said there probably applies to team nesting as well, and the implementation of team nesting reuses the same mechanism. The next step, connecting teams and projects, is going to be big. But today I'll talk about this in-between step: Team nesting.

As always, my task board is available!

Organizational Structure

Every organization has systems for how collaboration and communication works. Sometimes these are conscious systems, explicitly defined. And sometimes they're implicit. When these systems aren't defined and discussed, what probably often happens is that our old habits and cultural conditioning take the stage. So, whether we're aware of it or not, the systems are there.

Some of these systems are:

I was actually going to do a remote workshop on LibrePlanet about this :-) I guess they had more relevant candidates for the remote slots. Anyway, I'm inviting you to examine your software projects, and organizations you're in, through this lens of organizational systems! How do these things work in your team or project?

I have a dream, a fantasy: A sofware forge that provides effective tools and guidance for managing all these aspects, not just the plain usual code-issues-PRs structure. For example, enhance the typical stream-of-comments issue tracker to include a powerful decision-making tracker system. If you're up for the challenge of designing and implementing such things, I'm up for offering my guidance and consulting :-)

For now, the focus of ForgeFed is simply modeling the basic tools that developers usually expect from a forge, and that the popular forges offer. Therefore, "organizational structure" in ForgeFed is primarily within the resource flow department, specifically access control: The system that determines who has which access to which resources.

So, if your organization has 5 teams, all of them working on the same piece of software and all having the same full access to the code, there might be no need, in the ForgeFed sense, to create 5 Teams. Because the primary contribution of creating teams, I believe much like in the common centralized forges, is to define access control.

Team Nesting for Access Control

So how do we define access control using ForgeFed's team nesting? A previous blog post already discussed teams, so I'm focusing here on the new feature: The ability to nest teams, i.e. teams having subteams / child teams. Here's an example of what it might look like:

Example of organizational structure

So, Employees is a team that's going to have access to the common resources that everyone in the organization uses. Then there's some subteams, which:

  1. Have access to their own resources, which aren't avilable for the rest of the organization (e.g. perhaps the backend team has its own code repostories)
  2. Inherit the access that their parent teams have, e.g. people in the Backend team automatically gain access to whatever the Employees team has access to!
  3. Further pass both of these to their own subteams

Creating teams, and forming parent-child relationships, are separate actions in ForgeFed. In a federated network, there's no hierarchy with someone at the top who controls everything. So, cooperation between actors is based on mutual consent. From the ForgeFed perspective, Employees and Backend Team are just two independent self-contained Team actors, that have decided to form a parent-child link between them. Neither of them can force the other to cooperate: It works only as long as mutual consent exists.

However, representing hierarchical team structures with ForgeFed is entirely possible. Here are some ideas:

The mechanism for forming and removing team parent-child links is similar to the mechanism for projects:


Much of this was already implemented while working on project nesting. So what remained is to adapt the code from projects, and reuse the common pieces:


I really want to thank NLnet for funding this work, and much more to come! My grant has been extended, which allows me to continue :-)

Next Steps

I'm so excited about the next piece! The extended and updated grant from NLnet is allowing me to work on project-team links, and more generally team-resource links. In other words, much like Persons can be collaborators on resources, Teams will be able to be collaborators too. And that task, which is already in progress, will complete the OCAP system vision that's been forming for the past few years!

Some of the next challenges I see ahead:

See It in Action

I recorded a little demo of all this! Watch it on my PeerTube instance.

If you want to play with things yourself, you can create account(s) on the demo instances - fig, grape, walnut - and try the things I've mentioned and done in the video.

If you encounter any bugs, let me know! Or open an issue


Come chat with us on Matrix!

And we have an account for ForgeFed on the Fediverse:

Right after publishing this post, I'll make a toot there to announce the post, and you can comment there :)