I think the negative aspect of “teamification” is when it feels like it’s over-used and it results in excessive team structures in an open source project.
For me, the most striking problem are the effects on the accessibility and inclusivity of newcomers and volunteers.
- Complexity: Too many teams and sub-teams make the project’s structure complex which makes it difficult to understand how it all fits together — the absence of structure is yet another way to make it difficult to understand as people would expect structure where sometimes there is not.
- Fragmentation: Team structures that may end up working in isolation will block any cross-collaboration and sharing of knowledge if they were part of a immense unstructured group
- High requirements and expectations: Specialized teams might have high requirements and expectations for contributors. Newcomers or volunteers who don’t have the time or resources to meet these expectations may feel discouraged or excluded. Obviously, this is also the case without any team structure when it comes to some area of nixpkgs. I will address what I believe to be a solution to this problem later on.
- Decreased Diversity: High requirements and expectations can deter contributors from diverse backgrounds, who may not have the privilege to commit extensive time and resources to the project.
I think that we can draw examples from:
- Fedora with their SIG structure
- Linux kernel with rigorous hierarchical structure
Most projects end up fighting against this via mentorship, internship opportunities, etc.
I imagine that we could implement the same remedies first and see how many problems that could require a team are left after this.
I would be curious for example to measure how diverse are the SIG, what is the typology of the contributors in those groups, etc.
As for the Linux kernel, I will share the fresh 6.6 development statistics: https://lwn.net/SubscriberLink/948970/c6397e0621b39a81/ and let you draw your own conclusions.
For example, here are some ideas I am thinking of those last days:
- Clear onboarding and documentation for taking an active role in nixpkgs
- Lowering barriers via mentorship opportunities, maybe via Google Summer of Code/Outreachy
- Diverse leadership: promote more diversity within the leadership roles as having diverse voices in decision-making can lead to more inclusive practices (and the contrary… can be more problematic.)
In summary, I feel like having more team structures should be the answer to a well-identified problem. I can see two:
- one from newcomers/new volunteers trying to play a more active role in nixpkgs and understanding what is the path to being trusted to do X, to being maintainer of Y, becoming committer, etc. All of this is full of friction walls we introduced by leaving the breadcrumbs on how to get there and relying mostly on social mingling to explain the coherent paths based on our own experience.
- one from existing people working in the Nix project and particularly of people who are not working actively anymore in nixpkgs and does not recognize the existing folks working in some areas
For me, the first is challenging and needs to be addressed, I am not exactly sure team are the right answer for that, though I have read multiple times in Discourse that people would expect this to solve their problems.
The second would be solved by bringing and clarifying what are the proper venues to inquire / consult about a topic related to nixpkgs and letting people answer it, maybe by routing it to another person.
Overall, creating a team structure seems to be always striking a balance between organizational structure, inclusivity, simplifying the processes, making them more explicit and actively working towards lowering barriers for anyone in the project, while keeping the important properties to unblock and make current workflows non-disrupted, IMHO.