In reply to @yuki:backalley.club
This reads more like a How-to guide while the other one reads more like a tutorial

In reply to @yuki:backalley.club
I think a gradual progression from ad-hoc development environment -> declarative development environment -> reproducible and declarative development using the example project would be much better

In reply to @yuki:backalley.club
I think a gradual progression from ad-hoc development environment -> declarative development environment -> reproducible and declarative development using the example project would be much better

davidak: (in reply to your message on the Marketing channel) Yes the documentation team takes care of guides. I'm fully in favor of more guides, it's just that someone has to review them to make sure they are useful.

I proposed that right now we should focus on setting up a team of productive maintainers who can achieve that, and help people like you share their expertise effectively. So the following is really not to discourage you - I'd be really happy if we could have your ideas in there somehow - but I find it important to set expectations.

I don't see the documentation team working with you on your proposal any time soon. The main reason is that I think it covers a fairly niche use case, one that is not important for a majority of Nix beginners. We still have to more clearly define what those majority beginner use cases are, and that should be done after setting up the maintainer workflows.

The other reason is that I think it needs a lot of work, also on the reviewer side. Your sketch is just a piece of code, not a guide. It would at the very least least require linking to the reference documentation for specialisation. Here is another example which covers a valuable user story, but which I personally would not take into nix.dev as is. There is some more explanation about specialisations, but eventually the only thing presented is just another piece of code. A guide needs the steps how that piece of code is produced, and links to reference documentation for each individual part such that it becomes obvious to produce a piece of code that suits your specific problem.

The issue I have with these "here's a piece of code" solutions is that one has to fully understand it to derive the changes required to solve one's concrete problem instead of the one in the example. We cannot expect this from beginners. If the code would solve a generic problem, it may as well be in the library and kept invisible.

And while everyone is free to do as they please, I'd rather have everyone who wants to get involved focus on the low-hanging fruit first, and solve the bigger issues.

So, what about the following: Could you open an issue on nix.dev, collect some existing material there, and we observe the interest in this guide? (We're working on more firmly establishing a convention of people adding 👍️ to issues they want to have solved.)

In reply to @yuki:backalley.club
I remember someone at NixCon made a "Nixitionary" where it's essentially a pamphlet with a glossary of Nix* terminologies. I wonder if it's online somewhere.

In reply to @alex:tunstall.xyz
There's a glossary in the Nix manual: https://nixos.org/manual/nix/stable/glossary.html

In reply to @yuki:backalley.club
I remember someone at NixCon made a "Nixitionary" where it's essentially a pamphlet with a glossary of Nix* terminologies. I wonder if it's online somewhere.

Hi Tobbe. That's for two reasons:

1. nix.dev is for learning, the manuals for looking up facts. We expect new users to mostly learn, and experienced users to mostly look up facts. Also we can assume that most users are new.
2. There is always some degree of wishful thinking involved, otherwise we could not implement any change at all. We would like to eventually make nix.dev official.

Hi Tobbe. That's for two reasons:

1. nix.dev is for learning, the manuals for looking up facts. We expect new users to mostly learn, and experienced users to mostly look up facts. Also we can assume that most users are new.
2. There is always some degree of wishful thinking involved, otherwise we could not implement any significant change at all. We would like to eventually make nix.dev official.

Mic92 wiki pages to delete

• https://nixos.wiki/wiki/Nix_command/flake_clone
• https://nixos.wiki/wiki/Nix_command/to-base16
• https://nixos.wiki/wiki/Nix_command/flake_init
• https://nixos.wiki/wiki/Nix_command/flake_show
• https://nixos.wiki/wiki/Nix_command/flake_info

did the wiki experienced a rollback? 🤔

Mic92 wiki pages to delete if you can take the time for it 👍

• https://nixos.wiki/wiki/Nix_command/flake_clone
• https://nixos.wiki/wiki/Nix_command/to-base16
• https://nixos.wiki/wiki/Nix_command/flake_init
• https://nixos.wiki/wiki/Nix_command/flake_show
• https://nixos.wiki/wiki/Nix_command/flake_info

did the wiki experienced a rollback? 🤔