What do you think of teamification?

[RaitoBezarius]

@qyliss

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 have been considering joining the marketing team to resume work on the newsletter but targeted to keeping informed the community about Nixpkgs events and I would like to try things to keep very simple, maybe, one-line summaries about things happening in Nixpkgs.

I have seen it for Rust newsletter and as a reader of LWN too, I also feel the need for that in Nixpkgs. I don’t know how far I will go alone on this and maybe other people will join me or help me to centralize the blurbs of what is going on, but I feel like I have a lot of stuff already as an active member and sometimes I have trouble to focus on writing code but I still hang around in those channels and still know what is going on.

(raboof: "@jakehamilton@hachyderm.io there was ( https://ni…" - Merveilles / You're invited to talk on Matrix)

[zimbatm]

I love this conversation because it brings up so many good perspectives.

@tomberek

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.

Another way might be to have a dedicated place to post these things in advance. But we have to be sure that the interested parties are subscribed to it. (please don’t say RFC :-p)

@qyliss

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.

The biggest issue I see is that it takes a lot of effort to make large-scale changes. Look at how much effort Infinisil put into getting pkgs/by-name passed. How long has it been going on, half a year and still going? And Infinisil is the best person I know to handle RFCs. This is for an idea that isn’t controversial.

I feel like we’re falling behind on a lot of large projects, and losing goodwill from contributors because of that friction.

Maybe the issue is that consensus gets exponentially harder with the number of participants. I don’t know if the answer is teams, but I know that with small groups of people, the rate of decision-making can be another order of magnitude faster.

@qyliss

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.

This is how it works in corporations or military structures. In that scenario, people get pressured to perform, or else they don’t get a promotion or get fired. I see that mode of thinking coming more from people who are employees themselves. This also goes with top-down thinking, requiring meetings and fixed resource allocations.

All of this is toxic to voluntary work on some level.

In voluntary work, you work on something because you’re interested in it (for whatever reason tickles you). You meet people because you like interacting with them. And you get people motivated by inspiring them. The incentive structure is reversed.

A good test of your own mindset is if you see the NixOS Foundation at the top of the community, or at the bottom. Should we be beholden to it, or should it be in service to us?

On some level, I feel like this discussion is representative of both of these modes.

[qyliss]

@zimbatm

The biggest issue I see is that it takes a lot of effort to make large-scale changes. Look at how much effort Infinisil put into getting pkgs/by-name passed. How long has it been going on, half a year and still going? And Infinisil is the best person I know to handle RFCs. This is for an idea that isn’t controversial.

I feel like we’re falling behind on a lot of large projects, and losing goodwill from contributors because of that friction.

Maybe the issue is that consensus gets exponentially harder with the number of participants. I don’t know if the answer is teams, but I know that with small groups of people, the rate of decision-making can be another order of magnitude faster.

I agree that this is an issue. Something I’ve noticed with RFCs is that there’s an expectation that every detail is going to be worked out before the RFC is accepted. For some things that’s important, but it feels to me like maybe we’re missing a way to get an idea approved in broad terms, without making people care about or review the implementation in more detail than they need to. For example, I personally don’t feel that the merge bot necessary needs to go through an RFC level of specification before it’s introduced, and would happily agree to something much shorter and looser as long as it addresses my concerns, like “We will have a bot that allows maintainers to merge PRs by r-ryantm”, without needing to have a whole big document with background, alternatives considered, detailed design, etc., and trust the people involved to come up with the specifics.

[nixinator]

I vote for nixification over anything else.

Seriously, this is a very interesting thread.

Having skimmed at lot of it, I see most of the sticking points being that of scale and scaling from 100’s to 10000’s of developers/contributors.

Scaling a company, service anything can be hard…

Even large mega corps have trouble organising and scaling things… and they have paid staff!

Nix is super inclusive, because it’s just a public git repo at the end of the day…

to get my changes into say , the linux kernel i got be a much closer part of the cabal :-).

When i see what were dealing with, and the growth in the last year, it’s mind boggling.

I do feel that a long drawn out RFC process can be demoralising and tarpitty… i’ve always thought the PR welcome’s culture , where you do extensive work for it to be denied. is tantamount to developer abuse , especially if it’s some complex and took a long time to write.

That’s true for every open source project i’ve ever seen.

Someone mentioned working groups, or Special interest groups, I think the IETF called them BOF sessions too… What I’ve seen of volunteer working groups is it allows those with a common interests or itches to scratch to get to know each other…

don’t under estimate the value of human connection and collaboration to get things done quickly.

Nix is probably the largest open source collaborative engineering project on earth right now… so it’s going to need new methods of working ! it’s much much bigger than the linux kernel.

I’ve seen people I’ve introduced to nix, go from newbie, to contributor in some way in a matter of months, not years …that truly is astounding to having the philosophy of nix into practise. This makes me smile that barrier to entry is low, really low.

It maybe just a tooling problem, not a human one, maybe githubs workflow, on how git works adds to the problem of organisation? A lot of large organisation don’t use git at all, (they are still on rcs/svn) lol!

exciting times. I’ll track this thread. in the meantime…stick with nixfication.

[7c6f434c]

@zimbatm

How long has it been going on, half a year and still going?

Don’t underestimate what this «still going» means, though. It is a large change. There are a lot of failure modes for it, there was work to avoid some of them during the RFC discussion, and there is work being done now to figure out and avoid some other ones.

And yeah, by now I think that having large changes be slow is a feature not a bug.

[asymmetric]

@qyliss

@tomberek

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.

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.

Just to give another datapoint: I am a full-fledged member of the Docs Team, but I often don’t have time/capacity to attend the video meetings (there are 2 a week). This means that I don’t get to voice my concerns on many issues in the synchronous, high-bandwidth medium of a group call, but I can still catch up via meeting notes and, if need be, make my voice heard asynchronously via chat.

When I do have the time, or a particularly pressing issue to discuss, I join the calls.

This seems to work fine for the rest of the team (but hey, if not, let me know ), and allows me to participate in a way that is not overly demanding of my time, but still has a level of commitment to a specific group of people.
What being an official team gives you (as @tomberek said in above) is basically a Schelling point, or interface, for things like funding, PR review assignments, and so on.

There are people who do make it to all of the meetings (bless them), and I don’t know if the team could function if everybody was as… flexible as I am, but what I wanted to show with this example is that not everybody has to be in-sync all of the time for a team to be succesful at both being productive, and being an interface.