| 2 Jan 2024 |
 asymmetric | https://jvns.ca/blog/2024/01/01/some-notes-on-nixos/ | 11:19:49 |
| asymmetric | i always find it useful to see what other people use to learn (how to do things with) nix, that's why i post it here | 11:25:57 |
| asymmetric | it would be good to track how many new articles use nix.dev instead of the wiki. this uses the wiki | 11:26:55 |
| asymmetric | but for something that i'm not sure we should be maintaining ourselves? it seems like for things like "nixos friendly hosters", a wiki provides less friction | 11:27:48 |
| asymmetric | * but for something that i'm not sure we should be maintaining ourselves? it seems like for low-stakes (?) things like "nixos friendly hosters", a wiki provides less friction | 11:27:57 |
| asymmetric | * but for something that i'm not sure we should be maintaining ourselves? it seems like for low-stakes (?) things like "nixos friendly hosters", a wiki provides less friction for users and takes off some work from the docs team | 11:28:18 |
| asymmetric | or is the idea that everything that's now in nix.wiki + nixlang.wiki should eventually be absorbed by nix.dev? | 11:28:52 |
| asymmetric | * but for something that i'm not sure we should be maintaining ourselves? it seems like for low-stakes (?) things like "nixos friendly hosters", a wiki provides less friction for users and takes off some work from the docs team's plate | 11:29:10 |
| asymmetric | * but for something that i'm not sure we should be maintaining ourselves? it seems like for low-stakes (?) things like "nixos friendly hosters", a wiki provides less friction for users and takes some work off the docs team's plate | 11:29:18 |
 fricklerhandwerk | In reply to @asymmetric:matrix.dapp.org.uk
or is the idea that everything that's now in nix.wiki + nixlang.wiki should eventually be absorbed by nix.dev? Absolutely not. We certainly need a place for a class of crowd-maintained information, everything else is not manageable. | 14:03:47 |
| asymmetric | In reply to @fricklerhandwerk:matrix.org
Absolutely not. We certainly need a place for a class of crowd-maintained information, everything else is not manageable. do we have some rough principle of what should not go into nix.dev? i can think of "anything that doesn't fit diàtaxis", but that seems a bit unsatisfying | 14:37:08 |
| fricklerhandwerk | A few unstructured thoughts:
-
instructions for specific software
This is currently covered by the wiki to some extent, by NixOS/Home
Manager/… option documentation, and upstream
-
reference documentation
That should be in the manual for the respective component. There are a few violations of that at the moment
Conversely, what should go into nix.dev are things that don’t fit anywhere else: cross-cutting concerns that aren’t specific to any ecosystem component or don’t have a better place to live. Ideally that would be very little. | 15:26:34 |
| asymmetric | but we've just moved the nix ref manual to nix.dev? | 15:30:59 |
| fricklerhandwerk | In reply to @asymmetric:matrix.dapp.org.uk
but we've just moved the nix ref manual to nix.dev? This just where it’s hosted. I read your question as “which content should be part of the nix.dev source” | 15:56:55 |
| asymmetric | yeah good point | 15:57:44 |
| 3 Jan 2024 |
 @jade_:matrix.org | imo: our module system docs are faulty, in that you can't write guide level stuff in them | 12:49:01 |
| @jade_:matrix.org | which is a symptom of "services.jellyfin" or whatever not being a distinct entity in the module system and thus you can't attach docs to it | 12:49:29 |
| @jade_:matrix.org | it would be sick if we could attach docs to such things | 12:49:42 |
 @qyriad:matrix.org | Oh that would be fantastic | 12:54:06 |
 raitobezarius | Same for changelogs in practice | 14:03:11 |
|  nikstur changed their display name from nikstur (DECT 5643) to nikstur. | 15:33:23 |
 Chris McDonough | i'm going to try to join the the nix documentation meeting tomorrow; can someone acknowledge that they see this message | 19:49:52 |
| Chris McDonough | ty! | 20:06:39 |
 @johannes.kirschbauer:scs.ems.host | I'll join the meeting as well. I could need some help with migration of the nixpkgs manual rendering. (nixos-render-docs)
There are a lot of questionmarks in my head when it comes to section ids.
I'd like to discuss the future of that tooling after rfc145 was merged. Who has the ownership about this? @pennae or fricklerhandwerk ?
| 20:52:25 |
| @johannes.kirschbauer:scs.ems.host | * I'll join the meeting as well. I could need some help with migration of the nixpkgs manual rendering. (nixos-render-docs)
There are a lot of questionmarks in my head
I'd like to discuss the future of that tooling after rfc145 was merged. Who has the ownership about this? @pennae or fricklerhandwerk ?
| 20:52:39 |
| fricklerhandwerk | In reply to @johannes.kirschbauer:scs.ems.host
I'll join the meeting as well. I could need some help with migration of the nixpkgs manual rendering. (nixos-render-docs)
There are a lot of questionmarks in my head
I'd like to discuss the future of that tooling after rfc145 was merged. Who has the ownership about this? @pennae or fricklerhandwerk ?
@pennae wrote all of it, I have only cursory knowledge of that code | 23:44:11 |
| fricklerhandwerk | Also I won’t be able to participate in meetings in the next two months or so | 23:44:53 |
| 4 Jan 2024 |
 infinisil | Johannes Kirschbauer @hsjobeki: I'll be there in the meeting, we could also take a look at the nixdoc PR | 01:39:44 |
 danielsidhion | infinisil: PR to document the conventions as discussed in the meeting: https://github.com/NixOS/nixpkgs/pull/278762
I've been adding this documentation-reviewers team on my PRs because it seems more appropriate than adding the documentation team. Is this appropriate, or should I just stick to adding the documentation team instead? | 20:05:59 |
| infinisil | danielsidhion: No that's perfect :) | 20:06:38 |
