... a few days ago, I explicitly posted here asking if anyone wanted an extra pair of hands/eyes to help write/review anything. I didn't receive a response

Sincerely: my apologies for this. We are all tremendously busy, and frequently are not able to appropriately reply. We will always welcome extra help - please join the next team meeting at 15:00 UTC!

I was just confused about "why the thing people seem to be using the most" is not the thing we are also documenting.

Indeed this is a giant problem: the thing people are using the most is also the most broken. This is not really even my opinion, but a matter of technical fact. I even use flakes for my own system configurations, but this is still the case largely because I, like so many, adopted that workflow without any awareness of the problems lurking beneath the surface (also at the surface; flake.nix is not even a valid Nix file!)

For me at least, flakes are no more confusing than any other part of Nix

For me too! But this is really because the whole ecosystem generally has poor documentation.

... lack of discoverability through reading code alone, ... lack of a typing system, ... "magic features" that hide important connecting logic

Oh yes. You cannot possibly imagine how strongly I agree here. I think we'll be friends after all :)

... discussion (on news.ycombinator.com) about how flakes make Nix much easier to work with

Some parts, certainly! Flakes have a lot of good ideas, just sort of all crammed into the same space, unfortunately. They deserve much more love from dedicated contributors who can separate out the various concerns and make them into proper Nix features, rather than an unspecified informal soft fork living in the same codebase, like a sad vampire.

... put your efforts elsewhere (e.g. writing blog posts

I've deleted mine, actually. There are too many as it is.

... making a No-Flakes-Here Nix Wiki

nix.dev is almost this, but is really more a No-Flakes- Yet un-Wiki. This isn't a holy war; in fact you will likely find that some of the biggest detractors of flakes are also some of the most enthusiastic about the utility they (could, and were intended to) bring. We all want reproducibility and easy extension of Nix magic into new domains!

... forking Nix

I prefer to avoid making unilateral decisions like this (for example, by spending months moving PRs with the team instead of firing off blog posts solo every morning).

In reply to @proofconstruction:matrix.org

... the goal of teaching newcomers is an anti-goal for you

Teaching newcomers to contribute is my goal, at this point. You can convince yourself of this by checking my more recent (albeit some months ago due to significant life changes) contributions, particularly in the "packaging existing software" tutorial and the draft Nixpkgs contribution tutorial that follows (PR 696 could use your help!).

I agree that this is super important too, because it was definitely a struggle for me to figure this out. I would be very happy to have a look at PR 696 and leave a review.

I also benefited from using nix-init (just to check out what it generates in order to help me learn Nix packaging patterns, or to use what it generates as a template for further extension)...and was quite disappointed I discovered that rather indirectly (someone was nice enough to tell me about it here when I was struggling to package something).

So, when I see that mentioned by zmitchell as something you might consider inserting in #696, I heartily agree!

In reply to @proofconstruction:matrix.org

... the goal of teaching newcomers is an anti-goal for you

Teaching newcomers to contribute is my goal, at this point. You can convince yourself of this by checking my more recent (albeit some months ago due to significant life changes) contributions, particularly in the "packaging existing software" tutorial and the draft Nixpkgs contribution tutorial that follows (PR 696 could use your help!).

I agree that this is super important too, because it was definitely a struggle for me to figure this out. I would be very happy to have a look at PR 696 and leave a review (edit: I did just finish doing that!)

I also benefited from using nix-init (just to check out what it generates in order to help me learn Nix packaging patterns, or to use what it generates as a template for further extension)...and was quite disappointed I discovered that rather indirectly (someone was nice enough to tell me about it here when I was struggling to package something).

So, when I see that mentioned by zmitchell as something you might consider inserting in #696, I heartily agree!

In reply to @proofconstruction:matrix.org

... telling me to "fudge off"

Not at all, in fact I welcome any new energy to this corner of the project -- I would be thrilled for you to join and help us! Just, the unofficial wiki is precisely the place where one can make wiki-style contributions. Now speaking for others: we see no reason to duplicate that effort, and instead focus on producing what we believe to be higher quality (in particular, more narratively-consistent) materials, like today's nix.dev.

I am inspired to suggest an alternative to the whole wiki thing, after reading PR#696.

I guess I'm wondering: why don't we just hit the accept button on the decent suggestions made by infinisil and zmitchell, and then just merge the darn thing? It's really good enough as is! It shouldn't have stayed as long as it has in PR review mode...and I think that's what I crave the most when I ask for a wiki.

I know how much my perfectionism gets in the way of getting something completed (or even started), and recently circumstances in life have forced me to accept that "it feels better to just not care"...surprisingly, this made me more productive, not less...

Wiki has a culture that enables that, but maybe it's a silly excuse to want to wait for a wiki to solve our problem there, when we could just....merge things faster 😅

In reply to @infinisil:matrix.org
Speaking of which, I think https://github.com/NixOS/nix.dev/pull/645 is now ready to be merged (we agreed to merge it once the headers are updated), though CI fails, will fix

In reply to @proofconstruction:matrix.org

The goal is not to have users for the sake of having contribution. The goal is to allow newcomers to learn this tool, so that they too may improve their life through its use.

The trouble here is that non-contributing users (I was one for my first ~6 years using Nix!) are usually not also non- consuming, in the sense of requiring additional resources from teams that already don't have them. Hence the docs effort: well-designed (in particular, narratively-consistent) documentation can be a tremendous force multiplier for teaching, but the Nix ecosystem broadly does not have well-designed docs; famously so! We (again now speaking for others) do in fact want to improve lives by getting more people into effective Nix use, but this is in tension with Nix not actually being a very good tool: its edges are very sharp, and many cut themselves and wind up here looking for aid. That Nix works at all is very nearly a miracle. A chainsaw is useful too, but I don't want to leave one lying around for others to hurt themselves or others with, and right now the hard decision for many of us is between building a sheath for the saw and writing an instruction manual for it. Neither of these are reasonable approaches to the problem of new people running into trouble after picking up the cool saw.

I very much agree with you on this too. 100%.

I think what is special about Nix currently isn't its present day manifestation, but rather the fact that it exists at all, and even in this "sharp-edged" (broken) form, it is a proof of concept of how things could be, if we didn't take an ad hoc, cowboy attitude to everything.

(So it always surprises me that Nix-lang has the shape it does, especially given the intellectual culture it is a product of....)

When you mentioned this, I think I realized an implicit assumption I had made (and I am not sure why I made this, in hindsight!): that flakes/experimental stuff was about taking steps towards improving in Nix as a tool. I am now beginning to realize that they might actually be exactly more cowboy stuff on top of a foundation of cowboy stuff (i.e. no formal, written specification...sigh)

So yeah, overall, I do think we are in strong alignment.