Levitation

November 16, 2009

I usually do not write about stuff not related to KDE. But here is something I would like to share with you: The Levitation project is having a logo contest. If you do not know it yet, Levitation is an effort to rewrite MediaWiki on the basis of a Git repository, to allow for local branches and stuff. The project was started just two weeks ago in response to the controversy about notability criteria in the German Wikipedia. I wish the project all the best. After all, that’s something that, when it reaches production quality, could also be very interesting for the KDE documentation writers.

Advertisements

8 Responses to “Levitation”

  1. Tim Says:

    Using a closed source service for code hosting .. bad choice (and I like github)


  2. You could consider using Gitorious instead, it’s completely FOSS.

    • Stefan Majewsky Says:

      You understood me wrong: I have nothing to do with the project, except that I would like it to get some publicity.

  3. cargo Says:

    “Levitation is an effort to rewrite MediaWiki”

    If I’m not mistaken that’s not true. The project’s FAQ says:

    “Currently, Levitation has nothing to do with running MediaWiki at all. I seriously doubt it is worth the effort to adapt MediaWiki for a Git backend. Instead, a new frontend should be developed.”

    The aim is to import MediaWiki-dumps into git and write a new frontend to that.
    Correct me if I’m wrong.

    • Stefan Majewsky Says:

      You’re true, in principle. Officially, the Levitation devs don’t want to tear down and replace the existing Wikipedia infrastructure. But IMO, their project will only then really succeed if exactly that happens.

  4. Arnomane Says:

    I don’t want to be destructive but there are three major socio-technical flaws :
    * Branching with remerging is simply __way to__ complicated for $person-with-expert-kndowledge-in-some-non-techie-field. No sorry even with Git-sexiness you cannot remove this problem. So either you’d get a nerd-expert-knowledge-base or you get a mess of concurring article branches with different viewpoints.
    * Many years ago some people have started a branching capable fork of Wikipedia called Wikinfo -> http://www.wikinfo.org because they disliked the neutral-point-of-view paradigma. Any branching-capable fork of Wikipedia means that you leave the NPOV because there is no more a strong force for a synthesis of all aspects in ONE article per lemma. I personally don’t think that the “current” relevancy problem (in reality this is a debate as long as Wikipedia itself and I am really pissed of by random external people that now realized it and think they know better than all other how Wikipedians should work & think) can be solved by a forking capable software.
    * You will discover an n-factorial problem with distributed repositories. Git does NOT work for a loose group of people that don’t know each other. You always need to know where to pull from and whom to ask for pull-requests. So either you have a small group of people or you create a _huge_ hierarchy of submit paths (that way you can cut the factorial-problem) such as the Linux-Kernel-guys. Central repositories with low entrance barrier allow for flat hierarchies.

    So sorry although Git is sexy it does not work out for everything, escpecially not for wiki-style knowledge-gathering and I also would not recommend it for KDE documentation writers if you want documentation written as well by people who aren’t programmers (which I think is very important).

    • Stefan Majewsky Says:

      If you mean that branching is too difficult for “non-tech-geeks”, you underestimate the impact of an intuitive interface. Of course, in practice, nearly nobody will maintain its own Wikipedia clone. The server will ideally offer branching right in the web interface. In fact, people are starting branches even today, as subpages in the user namespace. Incidentally, this has the same disadvantages as SVN branches. For example, it’s very difficult to transfer the revision history to the original article when merging one’s work back to there. Also, such branches are hardly visible when looking at the actual article. With a Git-based Wikipedia, the webpage would display the article from the master branch, and allow to easily switch to other branches. This will in no way interfere with the NPOV, because the same community review process will apply to the master branch (and to the user branches, too, if they’re integrated into the interface correctly).

      • Arnomane Says:

        > […] you underestimate the impact of an intuitive interface

        No I don’t. Pleasant and intuitive interface are very important but you can’t transform a hammer into a screwdriver with a better interface. Both are perfect tools – for their job.

        Branching and merging (beside revision control) relies on a good diff algorithm. The current diff algorithm of usual source code management software relies on a lot of newlines. A typical encylopedia text has much less newlines and editing patterns of such a text often are more complex than source change patterns (as long as you don’t change source code formatting). Although MediaWiki itself uses (a fairly good) Diff, Diff is simply not well-suited for anything else but code. Something like in xdelta or rsync would be better, cause, e.g. a new newline just would be a new newline character and and not at least one entirely new line of text.

        But still even the diff view is something people have to learn and adopt first. That’s real life experience with people that e.g. have a lot of knowledge on animals and plants. Version conflicts are a very scary topic. And now imagine branches and merges…

        > The server will ideally offer branching right in the web interface […]

        That’s what WikInfo does _for years_. At first they used a (quite hostile as they didn’t respect the GPL) MediaWiki fork called GetWiki. Now they seem to do this more manually in order to be able using a current MediaWiki, see http://www.wikinfo.org/index.php/GetWiki. So please read a bit about these experiences.

        > the same community review process will apply to the master branch (and to the user branches, too, if they’re integrated into the interface correctly)

        This can mean everything but certainly not a flat hierarchy with direct results as currently in Wikipedia. Distributed repositories imply more hierarchy compared to one central repository. And hierarchies have very strong forces towards exclusionism…


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s