From my outsider perspective, "mob programming" is the #1 issue, as I see it as the cause for many of the described symptoms (low efficiency, poor mentoring, poor contributor retention, lack of Nix expertise in group leaders)

I think this is fine, as long as someone in the mob is "knowledgeable" and able to course correct when needed. But having many people "learn by doing" at the same isn't the most productive. Generally, there's at least someone somewhat "knowledgeable" on a topic, so it's a chance for others to learn.

In other words, there should be at least one "mentor" in attendance, or reviewing the work output.

In reply to @piegames:matrix.org
From my outsider perspective, "mob programming" is the #1 issue, as I see it as the cause for many of the described symptoms (low efficiency, poor mentoring, poor contributor retention, lack of Nix expertise in group leaders)

As a person that was already engaged with Nix and Nixpkgs before SoN and after and a participant of SoN 2023 I'd say about your points:
- low efficiency (I can see why that could be thought, but i debatable and more related to the average expertise of the participants)
- poor mentoring (I felt this was a symptom of the lack of relevant people giving feedback to packages, so related to your last point)
- poor contributor retention (this is more a reflection of the actual feedback loop of nixpkgs contribution experience, not SoN experience imo)

Some extra comments:

- In the end this is an NLnet project, not a NixOS foundation project, so their own pressure on setting their own objectives has to be taken into account.

- Is the nixpkgs contributor set able to team up to do actual knowledge transfer? Will a consensus even be reached on what the acceptable quality of a nixpkgs package is? What to do when one thinks that a reviewer/gatekeeper is doing nitpicking? Where is the feedback of new contributor experience collected?

- The mob programming format at least helped people do some Nixing, due to the social aspect of it. People that would have not done any Nixing, where is that impact accounted for?

In reply to @delroth:delroth.net
do you think nlnet is properly aware of what they're getting out of SoN?

First of all to be fully transparent: I'm one of the facilitator for this year and thus have a financial tie to this project.

• In the end this is an NLnet project, not a NixOS foundation project, so their own pressure on setting their own objectives has to be taken into account.

that's not entirely true, since it's a project in colab with the nixos foundation and all the financial stuff and contracts are handled through the foundation.

In reply to @delroth:delroth.net
also, low efficiency isn't really debatable when you take groups of 5 participants and they end up having lower output (even after months of being in the program) than I'd expect a single nixpkgs committer would have in the same unit of time

In reply to @janik0:matrix.org

First of all to be fully transparent: I'm one of the facilitator for this year and thus have a financial tie to this project.

• In the end this is an NLnet project, not a NixOS foundation project, so their own pressure on setting their own objectives has to be taken into account.

that's not entirely true, since it's a project in colab with the nixos foundation and all the financial stuff and contracts are handled through the foundation.

In reply to @alejandrosame:matrix.org
So then why ngipkgs exists to begin with?

In reply to @alejandrosame:matrix.org
My comment of being debatable is more on the point of under which constraints are we talking about. Aka, I'm willing to talk specifics in detail to understand myself whenever I ran projects like this, but also I'm not a person with any decision making impact in any of this.

In reply to @alejandrosame:matrix.org
So then why ngipkgs exists to begin with?

Full disclosure: I was a SoN 2023 participant.

i think its pertinent to remember SoN is primarily about facilitating students. Low productivity, and low follow up aren't necessarily red flags even together imo. Lots of the packages in ngipkgs havent been packaged for nixpkgs precisely because of the difficulty in packaging them in nix, and that they landed in ngipkgs at all (flaws and all) by students speaks highly of the capabilities of mob programming.

In reply to @janik0:matrix.org
btw, most builds of ngipkgs just straight up fail and don't seem to be maintained while lots of the packages would not be mergeable to nixpkgs because of a low quality and in general things that would be catched in a nixpkgs review https://hydra.ngi0.nixos.org/jobset/ngipkgs/main

none of the packages has a vmtest or module from what I could tell in the ngipkgs repo which is also quiet sad, since vmtests are what (imho) differentiates good from very nix packages.

to be transparent, i participated as a group member in SON 2023 and also now a facilitator in 2024 and thus have a financial tie to the project.

i'd like to make two points from my perspective, both related to communication between NGI and nixpkgs efforts:

1. NGI funding packaging with nix is not funding of nixpkgs, but when they do there should be mutual expectations about finalizing that work
2. i think with those mutual expectations clarified, i fully agree probing how well the mob format performs is worth discussion.

first, i'd like to clarify some of the differences in scope between ngipkgs and nixpkgs: the packages under consideration, via the selection of NGI funding, are often not subject to the general OSS popularity marketplace and are often research-quality software.
(i'm a research engineer, this is not meant to be derogatory, there are simply different motivations involved in research efforts.)
while nixpkgs was encouraged as the end home for packages when possible, upstreaming required some level of indefinite commitment which can be a hard ask when members have no lasting personal vested interest in the NGI projects for themselves.
my 2023 SON group decided to collectively maintain our librecast work that currently exists upstreamed into nixpkgs, because we ended up finding it useful, for example.
some of the packages under ngipkgs's scope are not mature and ready for broad adoption in a high-quality well-maintained package set, however, that shouldn't be just some person's decision on a case-by-case basis, closing the conversation, which i think is kind of the problem here!

as an example of what i mean on the extreme research side, take this NGI project PR: https://github.com/ngi-nix/ngipkgs/pull/168
Libre-SOC is a large project in the libre hardware world, it requires many of its own bespoke tools to compile an ASIC.
the result/ is a (reproducible, cached, lengthy) build with an artifact not standard for packages or services distributed in nixpkgs (that I'm aware of.)
this involves tools based on python 2 (electrical engineers broadly do not care about supply chain security), lots of patching, and generally lack the polish of software intended for distribution.
in this case, the project had an initial pass of packaging by a SON 2021 participant and had since bitrotted, however from that starting work, it took me a relatively quick pass to revive that work to the current release and enable all of the verification suites.
that is to say, ending up in nixpkgs is not the be-all and end-all of the packaging work being funded; it is absolutely worth having as an independent repository with its own standards of inclusion (not unlike the NUR, i figure.)