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

[foibey.livejournal.com]

The points you're making here sound a lot like what saved indymedia to some degree (well, it's not great, but on at least a few of the indymedia sites, there's a "front page view" and an "all the articles view" and crank theories about zionist conspiracies are relegated outside of the main view so that it can actually be a useful space for activist news etc).

I think the idea of forking and having an editor/author divide sounds like a good idea at least for some subjects. On the other hand with some political topics where measuring expertise is far from a clear process and open debate about it is really important for impartiality in WP, organising that hierarchy between people with editorial rights and people without could be a big problem.

[aliza250.livejournal.com]

Do what the Open Directory (<http://dmoz.org/) does (where it can) -- balance out known sources of bias. Have a union organizer and a corporate lawyer, both known and trusted, co-edit the section on labor rights :-)

Then you need to put a lot of trust in the group of people who hand out those rights...

[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?

[http://users.livejournal.com/_lj_sucks_/]

On the other hand, who's going to bother spending time writing a bunch of content if it might just get thrown away because the guy with merge access doesn't like it or can't be bothered to merge it? I had a discouraging time having to pester people at length to get some documentation added to Ruby. If I had to do the same for Wikipedia changes, I just wouldn't bother.

My problem with Wikipedia isn't that I don't want to fight, it's that I don't want to spend time writing something only to have it thrown away. Your suggestion of "throw it away by default" makes Wikipedia's problems worse, from my point of view.

[ciphergoth.livejournal.com]

I suspect you could still be pretty free with merge access on non-controversial articles. I would use an invite system.

[reddragdiva]

Politics starts with two people; when you have a few thousand people in one place, you're going to get your skills at working with others tested to the utmost. I'm not at all convinced this is a problem for experts as much as it is a problem for people. Lots of people don't have the patience or stomach to be required to work productively with complete idiots, which is a non-optional skill on Wikipedia, and I wouldn't expect them to.

Wikipedia has lots of academic experts. You and I know lots of them. All the claims I've heard of Wikipedia being anti-expert fail to explain the present exper continued presence. Unless expert-neutral (which I think it more is) is taken to be the same as "anti-expert."

I predict Citizendium - if it ever gets past vapourware - will attract those experts who don't like playing well with others. I'm sure it'll be marvellous to watch.

(What I'd like to see is somewhere encouraging this variety of expert to put up quality text under a GFDL-compatible licence which Wikipedia could then use, or not. I'm not sure what would work, or how it would somehow attract less dickheads than Wikipedia presently attracts, or why qualified expert dickheads would somehow be better to volunteer to work with than regular dickheads.)

[emarkienna.livejournal.com]

It's annoying having to fight, though I find the problem often isn't that I doubt the other person's qualifications or expertise, rather it's issues such as how best to express the information, or whether something counts as unverifiable or original research. Though I guess many will be willing to argue when they don't fear the other person is a random 12 year old, and they can see what that person's qualifications are.

I would be curious to see what credentials are needed for the less academic subjects - what makes someone an expert of "goth" or "BDSM"?

Ultimately you have two competing concepts of "an article which can be contributed to by a large number of people" and "an author who wants to write on a subject matter without having to argue about it with other people". Perhaps your tree idea could be useful even for "experts", not just anonymous users, in that they are free to write their own version, leaving other people to do the debates of what should make it to the final article.

I've also come across http://www.scholarpedia.org - another one "written by experts", but each article seems to be written mostly by one author. (Also there appear to currently be very few articles, and when they call it "free", they only mean as in beer.)