-
-
Notifications
You must be signed in to change notification settings - Fork 259
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Put "Best practices" parts where they belong #845
Comments
I'd very much support that. That's the sort of clean-up I always had in mind. Unfortunately I don't see "just move" happening because there are so many moving parts. There's barely a chance to not do rewriting simply to be able to fit things in. The Technically Correct but very expensive way to do it would be this (ordered roughly from most to least involved):
And on the way keep all URLs working by adding redirects appropriately, synchronising PRs across repos once the information has a new place. But maybe we can get this done piecemeal. |
We don't need to make a monolithic ticket for this. It's OK to move it and then create follow-up tickets for rewriting the relevant material. Small incremental improvements are easier to work with. |
Observations
diataxis.fr describes how-to guides as:
The "Best practices" section on nix.dev does not contain guides. They are neither a series of steps nor task-oriented.
Approaches
The best practices section should probably be included with the reference material, possibly merged into the relevant descriptions of the language features in the Nix manual (for URL syntax,
rec {}
,with
,<lookup paths>
, the//
merge operator, and reproducible paths) or the Nixpkgs manual (for "Reproducible Nixpkgs configuration").Willing to help?
Sure, as long as I can just move the documentation around. I don't want to submit a PR and then get told to rewrite the docs to make them better.
Priorities
Add 👍 to issues you find important.
The text was updated successfully, but these errors were encountered: