nixos.wiki is unofficial because we killed the official one so that documentation would be maintained along with code.
2 Likes
While editing a page, it shows
Please note that all contributions to NixOS Wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see NixOS Wiki:Copyrights for details).
Phew
2 Likes
Congrats, thank you for your contribution to Nix/NixOS documentation landscape.
Whatever is official or not, I only care that people can find even more content about this long step curve subject.
If Eelco cared about standards proliferation, I would still be using RPM/DEB.
Good luck on your teaching journey.
3 Likes
Whatâs the most charitable interpretation for a potential community-minded contributor? It may sound like joining a motte and baily (in the figurative as well as the rethorical sense).
In a broader community-governance context, it may seem a peculiar reactionary co-constituent of the effort, where, as people noted, we may desire, from a benevolent vantage point, more syntegrity than choice.
4 Likes
Proactive moderation.
World readable git repo with all files in markdown format so it can be forked.
4 Likes
Maybe there could be a section of nix.dev that is a kind of open wiki ?
This could be an opportunity to start giving some semi-controlled structure to freeforall wiki pages, with organic set of tags maybe?
This could be implemented as a folder with no CODEOWNERS, and a simple PR template.
A simple CI could check new links are all validâŚ
And the documentation team can incrementally add structure, links, baseline CI checksâŚ
So it would be ADD-friendly and potentially REFACTOR-friendly as well?
3 Likes
I mean if you want you can point wiki.nix.dev at proxy.nixlang.wiki and I can serve from there, and the git backup is already a no CODEOWNERS folder and all that, specially because it saves needing to do pull requests to add content, because you can do it through the web UI. However the backup method employed by wiki.js isnât CI friendly, but then again broken links are a great first PR to bring more people into a project.
I do remember discussing the idea of having a page for external links in nix.dev, which wouldnât have to go through the review process (other than a basic check for whether itâs useful at all). This way we would have a streamlined way to link to things like blogs, external wiki pages, gistâs, etc.
1 Like
Fully agree with this.
I donât want a Github account. The dependency of the Nix community on Github should not be enforced even more.
I can imagine an official wiki.nix.dev or wiki.nixorg.org where no (Github) account is required is preferred over having another another competing Nix related wiki.
1 Like
Again, we donât require a github account, you can signup with just email and password or not sign up at all and still edit.
3 Likes
We have so many âco-constituent of the effortsâ in other fronts, like Tvix, Nickel, âNix-Communityâ, âNURâ, âflakes vs niv in docsâ (there is also npins). Even nix.dev and nixos.wiki, started this way. It wouldnât be the first, and hopefully not the latest one.
Youâre using âgrowing cellsâ, should be more genetics, mutations and specialization geek than I to know how good is to have variations in a wild ecosystem. 
So how can we expect them feel comfortable to join, feeding their fear of joining with more âdonât do thatâ, if freedom, was the initial reason to âforkâ?
Or if we cannot even be kind, truly wishing them success, how can we convince them, we arenât an unwelcoming group, maybe the other reason to split?
3 Likes
I have this question of any wiki, including the current one: what motivation do knowledgeable people have to use the wiki? Because contributing to a wiki requires seeing the content often enough to notice an issue/gap and fix it.
Do you have any way to address this?
I think the âsyntegrityâ he mentioned is a real thing to strive for, in particular with nix and itâs current documentation landscape. The way you have to go from X to Y to Z to get a solution to a problem is not ideal from a newcomerâs perspective. Which is: from my perspective a little while ago. At least for me that had some frustrating moments.
Well knowledgeable people arenât always knowledgeable on all subjects. So you might really know systemd very well, but someone else might really know kubernetes very well. So when the kubernetes guy wants to run his bare metal kubernetes cluster he might need to look up how to do some systemd configurations he doesnât do all day and every day. So wouldnât it be nice if you had written a nice article for him how to use systemd on NixOS to do all the nice systemd things?
A wiki assumes that you like sharing your knowledge in return for getting the already shared communal knowledge. You might call it the inverse tragedy of the commons. Or the happy end for the commons. Because you are building a common resource together with but not directly coordinated with others.
And there are some really great examples. The Arch wiki was mentioned.
For the unofficial NixOS wiki right now, itâs also not that hard to find the gaps 
Edit: I should also add, given how stalled the current wiki is, the initiative announced here, if it gains traction, might very well end up being the âofficialâ unofficial one. In that case the âsyntegrityâ requirement would be ideally fulfilled. It is always hard to judge what sticks and what doesnât at the very beginning.
1 Like
APCodes had a great answer, but further I do think this is a really useful way to think about increasing the quality of the wiki.
Iâve kinda had some ideas, like Iâve seen that many people wish there was a way to keep track of whatâs âhappening in nixâ without having to constantly be plugged into discourse, matrix, and nix/nixpkgs issues and PRs, so having something like the english wikipediaâs âin the newsâ section would be a great way to get people to look at the wiki more often.
Another thing is that as the wiki grows more and more, it could potentially become a very valuable reference source, Iâve already found myself going back to articles that I wrote myself, just to check how something is done, and so if we manage to be the shortest path between remembering something then I can imagine weâd attract knowledgeable people. I mean, Iâve done disk partitioning an uncountable amount of times, but I still often go onto archwiki just to remind myself how whenever I need to do it, and getting to a similar place with nixlang.wiki is a major objective.
Ideally, we manage to become a shared notepad for the nix community, and if we can manage that Iâm sure weâll not have to worry about getting knowledgeable contributors.
3 Likes
Ideally, we manage to become a shared notepad for the nix community
That sounds like a really good idea. And if you manage to do the proactive moderation with the velvet glove of quality control, asking people to complete some things that are missing (this is a real issue right now on the existing wiki), while leaving out things that are unnecessary, technically or socio-politically, I think it might turn out very well. 
Iâve seen that many people wish there was a way to keep track of whatâs âhappening in nixâ without having to constantly be plugged into discourse, matrix, and nix/nixpkgs issues and PRs
Yes, count me in here. I think this is just a necessary point of friction in transitioning from a purely experimental project that runs on personal connections mainly, to one that is so big that it gets impersonal by default. At that point learning nix and NixOS can no longer depend on knowing someone who knows it already. I am not using it for that long, but I still switched before the current popularity boost, because someone else told me to try it. Maybe this is phasing out now.
2 Likes
Iâve just reworked the landing page a bit, and icluded a basic news section. Fleshing out some guidelines for what should and shouldnât go there however will probably be a process, but now that ball is also rolling.
Sorry, but allow me to dissect this.
Iâm not sure what you mean here, but to be clear, we have a code of conduct that will be enforced, specifically the contributors covenant code of conduct. It includes a mention of politics in examples of unacceptable behavior.
Trolling, insulting or derogatory comments, and personal or political attacks
However, I can imagine some people will find it political that I think our editorial view should be that of a community, not of companies, and that remaining somewhat independent of the large consulting and venture capital firms that have a rather large pressence in the nix project will ensure the quality of the content, even when it might come to highlight flaws in Nix and NixOS.
As someone that runs multiple FOSS projects, my efforts are inherently political, Free Software is inseparable from politics, and projects like nixlang.wiki are part of my praxis, in the sense that its my goal to make sure our primary knowledge source is a thriving FOSS platform, not a proprietary, or weakly licensed one.
Licenses will be strong copyleft, contributors will treat each other with respect, and minorities have to feel welcome to contribute to the wiki. I mention this because I know some people think itâs political to be inclusive, in which case I wanna make clear that then youâll think this is a political project.
Also, I would welcome pages that discuss the socio-politics of the nix project, I think having such insight into a project can be very helpful for newcomers.
I donât want a âminimalâ, streamlined wiki. Ideally, I want people to post long infodumps with everything I could possibly want to know, regardless of the quality, and then have readers slowly increase the quality as more eyeballs pass over the page.
Like wikipedia, quality isnât enforced at point of contribution, itâs created through iterations on the content that people upload. This is already a behavior Iâve noticed contributors have, where Iâve seen some cases of people that just fix typos, move things around, change the wording, which is great!
I very much lean âworse is betterâ over "the right thing"1 and I would attribute the existence of the wiki and itâs rapid iterations to this view. Itâs also a pattern I see in general in successful FOSS projects.
6 Likes
I suggest movement toward an official wiki is a good idea because the consequences of this decentralizing are showing itself clearly currently. Since now, we have 3 different competing wikis, and if there is no official wiki there is just going to be more fracturization, I propose that we should just take a page out of Archâs book and create an official wiki.
3 Likes
TL;DR: decentralization and being unofficial has worked well for me, and I remain convinced itâs the right approach, but Iâll happily accept the âofficialâ label, if itâs without any strings attached.
I disagree, we donât have 3 competing wikis. We have one wiki that was closed, one wiki with an awol maintainer, and https://nixlang.wiki.
Weâre willing to move nixlang towards the nixos foundation more, but not to relinquish control, because we think weâd be better at running it, at least for now.
Iâve literally been here before with eza, where waiting for some higher power to come and fix the problem just stalled developmentâ for several years. Instead of doing that and trying to build consensus about simple things such as code of conducts, I just forked it and told people they could contribute, and while there were initial detractors and people with a political axe to grind with inclusivity, eventually we became the default, and with the added bonus of having an actually great community.
Same story with https://rime.cx really, instead of waiting for flakehub to eventually, if ever, be made open source, we just went to work creating great alternative with the features we wanted (specially not being github only), with a strong copyleft license and no venture capital to steer the direction of development.
Iâd rather focus on quality, easy of use, accessibility, inclusivity, usefulness, all those things, and without having to wait for RFC processes and community consensus and endless concern trolling and bikeshedding.
Our goal is also to contextualize nix, and I think decentralization is imperative to fixing fundamental problems with nix documentation. The official documentation for nix, nixos, and nixpkgs are all excellent to me, yet many users find the nix documentation unapproachable. I think this is partially because there is a lack of usecase examples and workflows, and because there is a lack in diverse perspectives.
Rather than one-size-fits-all, documentation should be a constellation of sources, and part of nixlang.wikiâs job should be contextualizing and interconnecting these, as well as being a platform for easy creation and hosting of such sources.
I think this view owes back to very foundational ideas about the internet and hypertext and a longing for neocitis and userpages and personal blogs. Ultimately, if nixlang.wiki specifically should become official, whether de facto or de jur, it would be because it was the best alternative, I imagine, not because it was debated endlessly and finally approved as being official.
By making a wiki now, we are creating glue between these parts, by waiting for a solution weâre just bikeshedding. IF creating this wiki divides the community and the documentation, itâs a division between inaction and action.
8 Likes
Sorry, but allow me to dissect this.
This could be seen as an invitation to more and deeper dissections. However I am not going to go there this time.
Since you didnât see the point I was trying to make: I just see a tension in your approach between this statement:
to be clear, we have a code of conduct that will be enforced
and this statement
I very much lean âworse is betterâ over âthe right thingâ
On the one hand you have strong emphasis on enforcement upfront. Yet you combine this with another strong emphasis on iterative experimentation and incremental correction / improvement.
In my experience this is a target conflict.
My attempt was just to make you sensitive to the possibility of another style of proactive moderation that avoids this target conflict, or is at least less susceptible to it. The velvet glove instead of the iron fist, if you will, metaphorically. A style that is more in line with nudging people in a desired direction iteratively rather than with threatening strict enforcement preemptively.
I believe this doesnât necessarily compromise any of the explicit political goals you might have. It might actually help you integrate people to your political goals who, in an explicit political discussion upfront, would be in open conflict with you.
there is a lack in diverse perspectives
As relating to improving the documentation I am really curious what you would suggest as improvement here. I do relate very much to the lack of usecase examples and workflows. But the lack of diverse perspectives is much too abstract to me. I am not sure how to implement a change on that. What do you have in mind here?
Ohh well yes of course, the iron fist was just a tongue in cheek kinda thing 
There seems to be a core group of developers that produce a lot of the documentation (and well, really most of nix), and the few on-ramps that do exist are way too steep. Hopefully, by making the wiki easily available, even allowing anonymous contributions, weâll get contributions from those that are new to nix, as they are learning, and from those that might find official nix efforts too intimidating or hostile to contribute to.
3 Likes