This is a term that I heard a few times. Generally related to when new teams are created in the ecosystem. The way I heard it implied that it was necessarily a bad thing.
So now I’m curious to dig a bit further. What do you mean by teamification? Are they always bad things? How does it work if there are no teams? What are the pros and cons of teams?
What I am looking for here is not to argue with each other, but to expand this field of understanding. What are new perspectives that I am missing?
I never heard of the term teamification before.
For me teams have the benefit of distributed responsibility, for the team-members there is also some benefits like helping one another, pushing each other, being able to vent and a bunch of other stuff, being able to take time of without the feeling of leaving something unmaintained or with people that might not be able to fix stuff in a reasonable amount of time.
The team doesn’t have to be “offical” or written down for this to work, and in many cases it just happens.
For myself 2-5 in a team is usually a good amount of people to work with, everything larger usually losses a lot of the benefits like responsibility inside the team becomes less clear, people will be less familiar with each other so they are less likely to approach another to ask questions.
I’m not terribly opinionated here, but one thing that worries me about a ~teamless ecosystem is that it can be hard to figure out what threads to pull on to advance a given idea/proposal/bug.
The community is large enough now that we don’t all know each other well enough to quickly develop a good map of where to start with something. Large enough that “broadcast loudly and hope the interested parties notice” lets a lot fall through the cracks.
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.
I think that we can draw examples from:
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:
In summary, I feel like having more team structures should be the answer to a well-identified problem. I can see two:
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.
I think it’s a bad thing if and only if it decouples authority from responsibility.
Ideally these two things should be proportional to each other, and be understood with respect to the same reasonably-well-defined portion of the codebase, and reviewing PRs is a big part of the responsibility. Here are three situations where this is already the case:
The Nix Team is a very good thing, with a somewhat-unfortunate name. They have responsibility for maintaining the reference implementation of the Nix Interpreter, and authority over the same. It might be less confusing if it was called the Reference Interpreter Team, but that’s much clumsier, and at this point I think we all know that “Nix Team means C++ Interpreter Team”.
The Documentation Team is another good example. To clarify their responsibilities we should probably work towards moving package-specific documentation into the relevant packages (like NixOS does so nicely for modules) – it’s not fair to expect the Doc Team to manage that stuff.
I think of each line of the CODEOWNERS file as a lightweight undeclared team.
I’ve added myself to that file for the parts of nixpkgs where I’ve performed major renovations (gcc, stdenv/{generic,cross} and lib/systems) and I take responsibility for reviewing, or at least commenting on, every PR opened against these files (unless the PR is Darwin-specific or being handled by another reviewer). If I ever failed to uphold this responsibility for a significant period of time I would expect to be removed from those lines. If I had trouble keeping up with the PR load I would try to talk other people into including themselves on one of those lines. So I suppose I treat each line of the CODEOWNERS as essentially a Team without a name or regularly-scheduled meetings.
There are a lot of github-specific problems and limitations with excessive use of the github CODEOWNERS mechanism, so it probably doesn’t scale well. If we had a simpler “auto-request review from person X when a PR touches file Y” mechanism that would be a good way of self-organizing future teams. For packages we have meta.maintainers but not everything is a package.
Clearly linking authority with responsibility makes it easier (but not easy) to decide when there are excessive structures: is a team failing its responsibilities? Then it needs to either accept new members or be disbanded. Does the team have little or no responsibility? Then it might be unnecessary, but since it consequently has little or no authority there is no rush to garbage-collect the team.
The terms “working group” and “interest group” are often used, in particular by the IETF, for teams which have no special authority. I think it’s a useful term. It might be a better term for certain teams, particularly those whose authority derives not from the team having any specific responsibility, but rather from the high esteem the community has for the individuals on the team.
Thanks for posting this. I feel it’s something we’ve been talking around a bit for a while, so it’s good to focus on it. I think I coined the term “teamification”, so I should probably write something here.
I think that teams are sometimes good, and sometimes not good.
The Nix team was a fantastic innovation that helped move Nix forward when it was getting a bit stuck. But I’m concerned that that success is leading people to think that everything needs to be teams.
The reason that the Nix team was good was that it expanded the set of people who could make decisions, so we weren’t entirely dependent on Eelco. But when teams are proposed for Nixpkgs, I think the balance is very different. Nixpkgs already has a development process that works pretty well, and when teams are talked about, I get the feeling it would have the opposite effect, of limiting whose input is required on decisions / restricting authority to team members, who may or may not be the people who’re actually doing the work.
Team membership often comes with an expectation to attend synchronous meetings, etc. which are otherwise atypical for working on Nixpkgs, and not something that works well for a contingent of our contributors. It also requires an ongoing commitment, which is not good for people who need for one reason or another to be able to drop in and out. It feels like a structure being imposed that isn’t justified in this context, just because it worked well in other places. Some things are run by teams, and now those teams only want to talk to other teams, and so there’s pressure to create teams where they’re not actually needed.
We basically have informal teams already, and those work well. We have lots of Matrix channels for specialised topics within Nixpkgs, where people working on those areas coordinate, and people who’re less familiar with those topics can come and ask questions of and seek input from experts. But there’s no list of members, and there are no synchronous meetings, there’s no explicit hierarchy, and despite that, we get things done effectively.
Edit with some more: when I say there’s pressure to create teams from existing teams, an example of that is that, when there’s e.g. a Matrix room where only team members are allowed to speak, that creates pressure from areas of the project that are team-centric for there to be teams in other areas that don’t need them, or contributors in those areas won’t have their work recognized and get a seat at the table. I’m only allowed to speak in that room because of the technicality that I’m on the moderation team. None of my work on Nixpkgs counts towards it, despite me being one of the most active contributors, just because the areas I work in work best without formal teams.
Thanks, this whole thread is great.
I like this distinction between Teams, that are imbued with role and responsibility, and Working Groups that are just an assembly of people with a shared interest. In that model, we would want to favour Working Groups over Teams generally. Unless we see the group would function better with some additional roles and responsibilities (and a WG could then be converted to a Team).
If we can agree on that, then a few things follow:
To encourage WGs, it should be low friction to create and disband them. Right now, this requires creating a Matrix channel and then getting it added to the roster. Or ask an admin to create a Discourse group or GitHub team. But documenting those steps would already be pretty good. Maybe you have some ideas in that area.
It would also make sense to go back to existing teams and see if the team roles and responsibilities are clearly outlined. Let me know if any team stands out to you.
It’s probably hard to do a good job being part of too many teams. I would favour setting a cap to 2 or 3 teams per member. This would also help make more room for participation.
I think the nixpkgs-architecture is a working group instead of a team?
I’m probably going a bit fast here.
The Nixpkgs Architecture Team depends on the RFC process to give authority to decisions. However it is rather authorative and responsible for implementing and maintaining those decisions (only “rather” because if we end up not properly maintaining those parts, other Nixpkgs committers might just do it instead).
Furthermore, a working group has the notion associated with it that they work towards a specific reachable goal, and then disband once that goal is achieved, without a permanent presence. This does not match the Nixpkgs Architecture Team.
Fully agreed from experience. It’s also hard to do a good job if the team or one’s role has a too broad scope. I’d always strongly recommend writing that down beforehand and checking regularly if it’s still realistic given available time.
I’m not sure about that. I can imagine having a cross compilation working group (it would be a much closer fit than a team for how it currently works), for example, and it’s not like we’re ever going to be done with cross compilation.
If the group is using the RFC process to gain authority, then isn’t it on the same level as other contributors?
My impression is that we just have a different definition of a Working Group. I don’t mind changing the name if that helps. To me, the difference between Working Groups and Teams is more a question of nature. It doesn’t say anything about lifetime and importance.
In fact, per the current discussion, Working Groups seem to be more desirable in general and nixpkgs architecture could be leading that transformation.
What would be nice is if we could agree on that terminology, because then it can be used consistently across the ecosystem, and make it easier for everyone to navigate it.
The term “working group” is generally used for temporary groups, e.g. citing the wiki article on IEFT:
Each working group is intended to complete work on its topic and then disband.
And the same can be understood from the article on ISO.
I don’t really mind changing names (other than it being a pain to do), but changing names doesn’t really do anything by itself. To get more team/group standardisation, somebody should propose and write down the standard, get consensus on it, and then teams can follow it.
I think it’s a bad thing if and only if it decouples authority from responsibility.
I completely agree with this sentiment @amjoseph. I’ve written about this before where having too much of one and not the other always leads to problems. Every time. Without fail. It can rip organizations apart if not addressed. What are the values that you see being expressed in the NixOS project? - #8 by tomberek
In fact, this is why i think this topic came up. The specific incident in question was about the auto-merge-bot and a discussion started. And while that seems to be resolved well, there was a group of people that didnt quite have a clear voice, but should have one. I’ve been thing of this as the “Nixpkgs Daily Operations” team - in contrast with the longer time horizon of the Nixpkgs Architecture Team. And while that set of people should have a voice, that authority also comes with responsibilities. I dont think it is too much to ask that spme formalization take place by the people who want to have a voice when such situations come up. The exact format can vary, but that is the associated responsibility.
To summarize: a team provides a way to give authority coupled with responsibility. Working groups provide organization to get a specific task done, but usually have less responsibilty/authority as a result, which suites that model well.
The next question is how to ensure teams don’t become silos or gatekeepers. This is a real risk. I think that risk should be mitigated by having the teams be responsible for things. Meeting notes; a regular status report; asking for, spending, and reporting a budget; establishing written goals; clarifying processes - these sorts of things keep the team easily accountable.
Next, you need a check/balance mechanism or two. One is the RFC process which can put pressure from a non-team source. The other is the Board. @zimbatm , the board should ensure the teams are healthy, productive, unblocked, and hold team leads accountable. And another is the the other teams; hence the value in some regular team lead sync session.
The final question is if the risks of more teams and more formalized structures outweigh the risks. In the case of the overall Nix project, i think it generally does. I propose that many of our weakest points are due to unclear authority/responsibility and poor accountability.
We did have a clear voice. There were a lot of obviously very active Nixpkgs contributors who all shared the same concerns about the bot.
This sounds like you’re saying that if the people who work on Nixpkgs every day want to have a voice about what happens to Nixpkgs, they need to do less work on Nixpkgs and instead do a bunch of busywork. This is pretty much guaranteed to team membership becoming out of sync with the group of active contributors they’re supposed to represent, because the people on the team are going to be busy running a team, and so the people who still have time for lots of Nixpkgs work (because they’re not wasting their time in meetings) are still not going to have that voice. We’d end up in a strictly worse situation, because it would look like there was a team consisting of those people, but there wouldn’t be.
Skimmed the thread so far, but here are my 0.5 NOK:
Teams have both pros and cons. The pros are shared responsibility, pooling of domain knowledge, and dedicated syncronous communication channels for coordination and as a known place for non team members to reach out to the team.
The primary cons IMO is that it is more common for no one to respond when @nixos/<team> handles are pinged compared to when single individuals are pinged, since no one on the team has been assigned the responsibility of responding to pings and delegating work.
To make forming many teams be worth it, we have to tip the scales such that the pros win out. To this end I propose:
team-list.nix, promtly
team-list.nix could even link to the relevant matrix channelA problem with the CODEOWNERs file is that only committers may be listed there, to my understanding. We could improve ofborg to consider any file touched within a by-name package to be under the perview of (callPackage package.nix).meta.maintainers. PRs that don’t touch package.nix or default.nix don’t cause a review request at the time of writing.
We did have a clear voice. There were a lot of obviously very active Nixpkgs contributors who all shared the same concerns about the bot.
Correct, and they all had to individually express that. And at first it could have been easily missed to check with or gather their opinion because there is not an easily identifiable group. Let’s say right now I have some idea, or some proposal that will impact the very active Nixpkgs contributors - I have to know who they are, I have to know where they communicate, there is no clear way to give that set a people a unified voice. What about situations where that set of people may disagree… how is that resolved? What if not everyone is comfortable expressing their opinions? Or is unavailable when decisions start to be made? In contrast, if I have some concern about security, at least I know who should be responsible or who I should initially reach out to, because there is a list, contact info, some processes written down, etc.
This sounds like you’re saying that if the people who work on Nixpkgs every day want to have a voice about what happens to Nixpkgs, they need to do less work on Nixpkgs and instead do a bunch of busywork.
Not a bunch of busywork, but enough to justify having a voice, yes. “Work on Nixpkgs” includes the coordination, this is stuff that is already happening, but it is difficult to see, difficult to track, difficult for newcomers to understand. Having clear contact points, a defined set of people to contact when things go wrong, a set of written policies, a set of responsibilities, a report about the problems/issues/proposals, requests of support from other teams… hrm… it’s starting to sound like a team. I hate busywork and meetings as much as anyone (sometime ask me why… and how it became a life-and-death situation where the paperwork only made things worse). I am keenly aware of that danger, but we are on the opposite side of that spectrum. We are not suffering from too much organization or cohesion, but too little. I’m NOT suggesting that all of those tasks need to be done or that there need to be mandatory weekly meetings, but that some subset should be, or the appropriate ones decided by the relevant people. “Team membership” (or working group, or community-of-interest… the exact label can vary) should reflect reality of the things that need to be done and not a waste of time. And yes, this does impose some responsibilities on people - that’s the cost of having some authority or a voice in decisions. Asking for a voice without responsibility is just as pathological as having responsibility without a voice.
We’d end up in a strictly worse situation, because it would look like there was a team consisting of those people, but there wouldn’t be.
This is a risk. Let’s be aware of this, mitigate it, monitor for it.
And yet the system worked. And it generally works. I think we’d need some actual examples of the system not working to justify such an invasive change.
If somebody is so removed from the community that they have no idea who the active Nixpkgs contributors are, no idea how to find out, and no idea how to get their attention, they’re probably not the right person at that point in time to be suggesting and driving major changes to how Nixpkgs works. Fortunately, in practice this is quite rare. It’s not necessary to have a complete idea of who needs to be consulted at the change at the start, because you can ask people and find out! And then you’re likely to get a much more accurate answer of who the right people are right now.
How does having a team help with any of this? People are still going to disagree, some people are still not going to feel comfortable expressing their opinions, and people with opinions are still going to be unavailable sometimes.
It might, depending on whether the contact info you look at is one of the bits that is up to date, or one of the bits that is not. Graham is the first person listed as a member of the security team, and yet he’s been inactive on it for months. (FWIW: I agree that having a formal team and written down stuff is important for security, because that’s something where people who’re not actively involved might are likely to still need to get in touch. I don’t think the same applies to large changes to Nixpkgs. But the fact that the security team has fallen into exactly this situation is demonstrative of a problem with teams in general.) If you asked around “Should I report security issues to Graham?”, there’s a good chance people would be passively aware that that’s not the best thing to do at the moment. And yet nobody has updated the team list. Maybe because removing somebody inactive from a team without explicit signoff from them feels rude or even impermissible, maybe because they feel it’s not something for them to do because they’re not a member of the team, or maybe just because they don’t know about the team list. Whatever the causes, they’ve come together to manifest a situation where the collective wisdom has been updated, but the written down stuff hasn’t been updated to reflect that. This sort of situation demonstrates that it’s a real trade-off when it’s best to have written stuff, and when it’s better to rely on people asking for up-to-date information. For large Nixpkgs changes, I think the benefits of the collective wisdom approach outweigh the downsides in a way that doesn’t apply to, say, the security team or the infrastructure team.
Why does the existing work that people do on Nixpkgs not justify having a voice? Of course, it’s great if volunteers want to try to work on making the coordination more visible, etc., but it’s not fair to force people who’re already putting a huge amount of their lives into this to do even more work if they want to have a say in decisions that mostly affect them.
Teams make things worse for newcomers in some ways as well. Often newcomers show up, send a small first PR, then trickle in a couple more, then a trickle becomes a flood as they start gaining expertise with a particular area of Nixpkgs. As time goes on, other people notice and recognise the work they’re doing, and start to treat them as an authority on that stuff. I’ve seen this happen constantly in the years I’ve been working on Nixpkgs. But that nice gradual, natural process doesn’t happen with teams, because there’s a cut-off of whether you’re on the team or not. And if there’s one thing new contributors are not good at, it’s having the self-confidence to ask to be part of some formal structure. People who should have been committers years ago often have to be strong-armed into asking, because they’re not confident enough in themselves or scared of rejection. A team can try to be proactive about recruiting, but then that’s yet another responsibility for the team, and it’s easy for it to fall by the wayside. Instead, we tend to see (less active, especially) teams ossifying, especially when newcomers are not actively asking to join.
Why aren’t we starting with the problems this causes, and discussing from there what to do about them, and considering multiple approaches? I feel like all the discussion about teams in Nixpkgs recently has started from teams as a solution because they’ve sometimes worked for other situations other groups of people have found themselves in, and then going backwards to identify problems that a team would solve, without considering whether there might be any other solution to those problems.
For the last few weeks I’ve spent about half of my working time on staging regressions, because I feel responsible for keeping certain parts of Nixpkgs working, and other people expect and rely on me to do that work. Lots of other active contributors similarly already have lots of responsibility to Nixpkgs, and they take it seriously and live up to the requirements. Why doesn’t that responsibility count?
Lots of other active contributors similarly already have lots of responsibility to Nixpkgs, and they take it seriously and live up to the requirements. Why doesn’t that responsibility count?
I probably monitor the Staging channel more than most people, but I had no idea you had taken on that work and commited to it. If I missed it, I’m sure most people have.
It should count. I would like it to. But because it is invisible and fleeting and informal, it is easily overlooked or ignored. It helps a lot for more people to know that you and others have volunteered to accept that sort of responsibility. It is not trivial at all, I understand that. So it would help if a few people wrote down what they are volunteering to be responsible for, what kind of time they are devoting to it and explain to others what areas don’t have enough help at the moment or are at risk because someone is burning out. Occasionally you’d probably want to give some updates about how things are going, how that work can be expected to change in coming months, set expectations. This is starting to sound a lot like a team. It doesn’t have to be super formal with exclusive membership being required to volunteer.
I’m advocating for this in particular because I want Nixpkgs maintenance to be more prominent and celebrated for its value. I want to write about this system works. I’ve answered questions about how Nixpkgs is maintained and people find it hard to navigate without being in the “in crowd”. I may just happen to know what might work for them, or the right contacts, but this doesn’t scale. I want to be able to get funding from various sources and describe what activities it will support and to whom it should go. I want people to be able to rely upon this ecosystem and to trust it.
I feel like this could possibly be addressed in a descriptive, rather than prescriptive way. A summary of “here’s all the work that’s been going on in Nixpkgs” would help with this, without requiring extra work or commitment from everybody doing the work. This would also avoid the problem of “who’s in the team”, etc. @matklad was talking in another thread about how summaries of discussions have worked well for the Rust project, where people were having trouble keeping up with long discussions spread across lots of different places. Maybe we need summaries of work done as well. These summaries would also be a good place to tell people how to get involved with a particular area, etc. I’m an avid reader of LWN, which is basically work summaries for kernel development, usually written by people who specialise in keeping up with the work and writing about it, rather than the people actually doing the work themselves, and I’d love something like that for Nixpkgs.
I’m good at programming, and keeping up with what’s going on, and I think I’m quite good at the human parts of finding solutions to (reasonably sized) technical problems. I’m not good at keeping a schedule, organising, or writing. I can’t commit to attending regular meetings. If those things become requirements for contributing to Nixpkgs at the level I currently do, I’m not going to be able to do it, and I know it’s not just me who’s in that situation. I feel like when teams get brought up, it’s often with the expectation that the people who work in whatever area will just start doing those things. If we were approaching all this with the idea of people with that second skillset supporting people with the first, that would be quite different to me. But the teams I’ve seen so far have not been that.
Taking making it easier to keep up with staging as an example, I could imagine something like the following working well:
Somebody (or a group) with good writing and organisational skills decides they want to become the Staging Chronicler. Every cycle, they outline the work that’s been going on on GitHub and Matrix. They only need to have a surface level understanding at this point of what that work has actually been, and then they look at who’s been involved with each bit, and they can talk to them to have it explained in more detail until they have a good understanding of whatever they need to understand, and then they can write it up. The end result would probably be much better than if a “Staging Team” consisting of the people most actively working on staging were forced to write this up for themselves, and it doesn’t force extra work onto those people, beyond answering questions about the work they were already doing. The chronicler would have made a huge contribution to making Nixpkgs better, and I’m sure they would be recognised as such for their contribution.