Citizendium

[ciphergoth]

Citizendum is Larry Sanger's new project to improve on Wikipedia by explicitly giving more weight to the voices of experts.

I'd like to write a celebrated, widely-linked blog entry that changes the direction of the project, but I'm too lazy to put that much work in, so I'm just going to write a few bullet points here.

• Sanger is right that there's a problem. I am an expert, and for the most part I can't be bothered to contribute my expertise to Wikipedia any more for precisely the reasons he outlines: I want to contribute but I don't want to fight, and on Wikipedia you have to fight all the time.
• He is also right that the solution is to have more hierarchy, to explicitly identify experts and give them more control. And he's right to start with a progressive fork of Wikipedia.
• However, he's dead wrong to try to use the existing, unaltered MediaWiki software to do it, because...
• The thing that will make it possible to maintain a progressive fork, and to allow all to edit without causing disruption, is explicit support for forking and merging in the page history.
• Anonymous users should be able to create new revisions freely, but these revisions would be on "branches" of the page, and not on the "trunk". Editors would be able to use powerful tools of their own choosing to identify and "cherry-pick" the useful revisions, merging the changes together into a single entry.
• It's a bad sign that he's started by creating a pile of moderated mailing lists. Start with one unmoderated mailing list, and introduce moderation, extra lists and so on as the need arises.

I wrote about this before in the trustmetrics journal, but I'm not advocating the full "giant leap" here - just that the tools that we rely on for software development be made available to the creation of a better encyclopaedia.

Comments

[brad.livejournal.com]

Funny timing.... I started researching/work on a Subversion-backed wiki last weekend. I totally agree about the need to fork sometimes.

[ciphergoth.livejournal.com]

Why Subversion rather than one of the true DVCSs like monotone, bzr, git/cogito, darcs, or Mercurial? A DVCS gives you disconnected operation and a lot more power - anyone can create a fork of the wiki.

Though actually neither Subversion nor any of the above are a perfect fit. They all version entire trees, which is the Right Thing for source code, but actually a poor fit for a wiki. If I change page A and you change page B, there's no need for those changes to be merged. And the history of each page is independent from the history of the other pages.

The one big win that tree versioning gives you for a wiki is versioning of renames, but I think there's a more wiki-like way to achieve that. I've been thinking about how to write a bug tracking system based on a wiki, and this idea comes from that: give each page a number, and make the title of the page something you specify inside the page with markup. If two pages specify the same title, then when you go to the URL for that title you get a synthesized disambiguation page. Then page moves are just the same as any other edit of the page text.

The other nice thing about explicit forking and merging is that it gives you a friendly way to enforce policy. With every Wiki I know of, the privilege to edit a page is binary - either you have it or you don't. That means that if there's anything that not all editors should be allowed to do (eg vprotect a page) then you can't represent it as a tag in the page body, because anyone can put those there - you have to put it in metadata. Now you're versioning two things about the page - the body and the metadata - and life is less convenient.

You could change that by vetting edits when people try to save them. "You can't save this edit, it adds the vprotect tag which you're not allowed to add". But not allowing people to save their pages would be pretty unfriendly. With explicit forking and merging, everyone can save their work at any time, but it will only become part of the "trunk" of versions if it complies with policy checks.

Git's actually pretty dumb...

[pengshui-master.livejournal.com]

But in a good way.

AIUI git (no cogito - git itself) is just a content addressable filestore, It provide to operation give me the file with the MD5 (I think it uses md5 not another hash) cksum x.

It's cogito which give it it's tree usual VCS characteristics. Iiirc, it uses a file with a map of filenames to cksums.

So it should be possible to to wiki like stuff in custom version of git, where even renames are localised to a branch etc.

[reddragdiva]

"Though actually neither Subversion nor any of the above are a perfect fit. They all version entire trees, which is the Right Thing for source code, but actually a poor fit for a wiki. If I change page A and you change page B, there's no need for those changes to be merged. And the history of each page is independent from the history of the other pages."

I think you're dead wrong on this one. Much as the key insight of git is that the unit is the project rather than the individual source file, to a large extent the unit is the Wikipedia rather than the articles. In day to day editing, stuff gets refactored between articles all the time. I would like to see attributable "responsibility" (sounds nicer than "blame") on the sentence or even phrase level.

[ciphergoth.livejournal.com]

It's true that stuff gets refactored between articles. However, the unit of the atomic transaction on Wikipedia is the article. When people refactor between articles they do it as multiple transactions, so the information isn't there for a smart revision control system to make use of. So you might as well track each article separately, which makes it much easier to process edits in parallel.

If it were possible to represent these refactors in a single transaction things become a lot more interesting, but I'm trying to imagine the UI. I'm having a hard enough time imagining the UI for my branching-merging-Wiki...

That's not an insight of Git's, by the way - PRCS worked that way ten years earlier.

[reddragdiva]

Yeah ... a wiki interface (web page, text edit box) doesn't really give a feel for what's actually happened in a text move, or that it is a text move. Wikipedia nuts'n'bolts editors already talk about "cut'n'paste page moves" as undesirable compared to hitting "move page", as if the first wasn't the obvious thing to do given the interface.

My new nascent theory is that worse is better operates at the interface level. e.g. you'll never get a web board system as good as Usenet or really feasible to gateway both ways with an NNTP server. Even though I've mooted a web-based newsreader (as a project when I've learned AJAX) myself.

I should read up more on the history of version control systems. I'd be quite surprised if Wikipedia wasn't the best place to do so, and if it isn't then it almost certainly links to the best place. And I can say that without even looking.

[reddragdiva]

Svnwiki or something else?