In reply to @tejing:matrix.org
I'll also mention this tidbit here in case others find it a little useful: We talk about the relationship between how nix manages files and how programming languages deal with pointers, but for some reason when it comes to explaining why we avoid well-known paths, nobody seems to make the comparison to avoiding global variables

Could it be, to some extent, because Nix's current tooling relies fairly heavily on things like environment variables?

I'm reminded of nix-shell/nix develop

In reply to @bzzm3r:matrix.org

Maybe? Not sure. I can't help but think I lost the thread while writing that message, and therefore, readers would have too. But if I were to try again, much more succinctly:

1. Automation is useful, and important, especially given the context we are in. Nix has peculiarities which make it difficult to document semi-automatically. Should these peculiarities be addressed directly first? Or should we "accept reality as it is", and merely paper over Nix?

2. For a beginner (speaking as a beginner), learning Nix is especially difficult not because the Nix docs don't have good SEO, or because there isn't enough documentation. It's because there is a ton of noise; some of it quite purposeful/intentional.

In reply to @olafklingt:matrix.org
I think most of the noise is not intentional. The difficult part of improving the documentation is not to add content but to make it more concise. So i basically agree with your observations.

In reply to @olafklingt:matrix.org
I think most of the noise is not intentional. The difficult part of improving the documentation is not to add content but to make it more concise. So i basically agree with your observations.

In reply to @olafklingt:matrix.org
I think most of the noise is not intentional. The difficult part of improving the documentation is not to add content but to make it more concise. So i basically agree with your observations.

In reply to @bzzm3r:matrix.org

But there is enough of an effort to delegitimize the current official docs (because they do not cover flakes, and because they refer to flakes as experimental features), that most newcomers (myself included) did not realize that flakes were entirely optional

instead, we saw the docs as entirely outdated

I for myself decided to see it this not worth to deal with. It is something one has to live with in a world with multiple opinions and unequal distribution of power.

Obviously it's unfortunate.

In reply to @fricklerhandwerk:matrix.org
And the reason we're circling around these issues are embedded in bzm3r's long introduction that started this exchange: as a group of developers working on the ecosystem, we lack focus and direction, and this is in part because there are so many rabbit holes. There are more problems to solve than hours available, and each of them is large enough to get frustrated and switch to something else. Therefore everything is notoriously unfinished.

Suppose you were to put on an imaginary despot's hat. Where would you direct efforts?

Would it still be on documentation?

If yes, then in that case, I found this recently: https://github.com/orgs/NixOS/projects/15/views/1

How can I find someone willing to prioritize tasks for me by assigning them to me? Could you do so?

In reply to @bzzm3r:matrix.org
Oh, I just ran into this today: https://github.com/NixOS/nix/issues/7981

In reply to @bzzm3r:matrix.org
Or...should I just re-write the nix-build CLI? 🤔

In reply to @bzzm3r:matrix.org
Is the project board meant to be used, or was it just an experiment that has fallen out of favour?

It is meant to be used, but given the very limited amount of time we have, we usually prioritise group reviews to get things merged that have happened in between meetings.

We should probably have a formalised meeting agenda that gives the board a couple of minutes of attention.

In reply to @fricklerhandwerk:matrix.org
One practical problem I've observed in the Nix maintainer team, where we have a very formalised meeting structure and in fact curate the board very nicely, is that the process nudges us to delegate tasks we don't actually have time to follow through with. So the tail end of the pipeline is broken due to limited capacity and the challenges to estimate workload. The front end works fairly well though, because we do triaging to determine whether something fits current priorities and direction, or make design decisions to help produce sustainable solutions. Some contributors follow up, many don't, due to lack of time to actually finish tasks that very often blow up in size once you take a close look at them.

We have the exact same problem in documentation, except we stopped assigning tasks as we were all fully booked at some point. And since contributions tend to be either very small or very large, triaging doesn't seem to serve much of a purpose. We should probably try to find some middle ground, to really get an up-to-date grasp on who's currently working on what, how complex a given task is (and which rabbit holes it uncovers), which resources are available to finish it, etc. -- simply to know what to focus the effort on to get it over the finish line.

In reply to @fricklerhandwerk:matrix.org
One practical problem I've observed in the Nix maintainer team, where we have a very formalised meeting structure and in fact curate the board very nicely, is that the process nudges us to delegate tasks we don't actually have time to follow through with. So the tail end of the pipeline is broken due to limited capacity and the challenges to estimate workload. The front end works fairly well though, because we do triaging to determine whether something fits current priorities and direction, or make design decisions to help produce sustainable solutions. Some contributors follow up, many don't, due to lack of time to actually finish tasks that very often blow up in size once you take a close look at them.

We have the exact same problem in documentation, except we stopped assigning tasks as we were all fully booked at some point. And since contributions tend to be either very small or very large, triaging doesn't seem to serve much of a purpose. We should probably try to find some middle ground, to really get an up-to-date grasp on who's currently working on what, how complex a given task is (and which rabbit holes it uncovers), which resources are available to finish it, etc. -- simply to know what to focus the effort on to get it over the finish line.