[Nix-dev] Wiki is dead

[Marcus Brinkmann]

I feel like contributing a few points in a Wiki's defense, given the
general negativity towards it, but I am not on a crusade :)

In general, Wikipedia/MediaWiki works because it scales massively and
provides excellent tools to detect and cope with vandalism.  The git
workflow should scale very well, too, but under heavy parallel writes
(at a Wikipedia level, not something I would expect for NixOS), the
interactive nature of conflict resolution is going to be smoother than a
git pull/push scenario (think about multiple users pounding on a page
within seconds).

The NixOS project is simply too small to have a well-maintained wiki at
this point, which needs a certain critical mass.  But I think eventually
things will tip in favor of the wiki, and NixOS' wiki will be as great
as Arch and Gentoo (also an excellent wiki, and a much smaller community
than Arch).  I also think that thematically NixOS will have much in
common with these two wikis (the issues in maintaining these systems are
similar).  So, I would look at Arch and Gentoo Wikis not as contrasting
examples, but as a projection of the NixOS wiki in the future.  If you
like the Wiki there, you would move away from that goal by not having a
wiki.  I think that if you look at the early versions of those wikis,
you will find them to be similar to what NixOS wiki looks today.

A causal user, and even most developers, will not bother checking out a
whole git repository to fix an issue in a single wiki page.  Wikis are
optimized for low barrier of entry.

Also, a MediaWiki installation will be easier to adapt, exetend and
integrate with other tools in NixOS rather than for example the
suggested github pages, which will always be limited by what github
provides.

I think that book-like manuals serve different purposes from a wiki.  I
think both are needed.  Github pages may very well be suited to provide
a good book-experience.


On 02/15/2016 05:33 PM, Michael Alan Dorman wrote:
>> Several people have made various initiatives to help improving the wiki,
>> but curiously enough none of those initiatives actually improved the
>> *contents*. Nix contributors clearly enjoy making the wiki prettier,
>> writing fancy CSS configurations, rendering the stuff in sophisticated
>> web development environments from various markup languages, etc., but
>> still despite all that effort put into the presentation and management
>> of the content, the content itself invariably remains the same.
>>
>> Therefore, it is my perception that those initiatives will ultimately
>> not result in a better wiki because changing the wiki infrastructure
>> will not address the problem that we lack people who enjoy working on
>> the contents.
> 
> I wonder if people focus on the aesthetics simply because the platform
> makes trying to effect change in those areas relatively achievable?
> 
> I can only speak for myself, obviously, but I find MediaWiki to be
> cumbersome to work with---I find the formatting to be far less intuitive
> than most of the alternatives (off the top of your head, is bold two
> apostrophes or three?)---and having to create and edit (much less
> reorganize and refactor) content via a web interface seems like so much
> overhead that, ultimately, even small edits feel like too much effort.
> 
> This exact situation crops in my $DAYJOB as well, where we use MediaWiki
> to try and organize internal documentation---and most of it gets put up
> (which is, compared to everything else, relatively low cost), but then
> the cost of modifying in all but trivial ways is high enough that people
> would rather start over than do significant edits...and then the high
> cost of reorganizing and refactoring means that we end up with duplicate
> content, etc.
> 
> It makes me sad just to think about.  Honestly, I cannot comprehend how
> Wikipedia even works, given the relatively horribleness of the tools
> MediaWiki provides.
> 
> Would I contribute more (AKA: at all) to what amounts to a github pages
> sort of thing?  Certainly there's no guarantees, but it would make it
> far more probable, because the cost would be more in line with, say,
> cleaning up a nix expression or some such: oh, I see an issue, let me
> update my clone, make my edit, fire off a PR.  That's a workflow that I
> manage quite happily and easily.
> 
> Mike.
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>