Visit the forum instructions to learn how to post to the forum, enable email notifications, subscribe to a category to receive emails when there are new discussions (like a mailing list), bookmark discussions and to see other tips to get the most out of our forum!
Wikipedia and Google's Knol
  • Let's focus on a post by Eerik, in which he argues we should consider moving away from a wiki:

    Problem
    Though a wiki is great to get off the ground fast, I think it's inappropriate for the needs of OSE. The reason is that a wiki is designed so multiple people work on the same subjects, which seems reasonable at first for a development project, but in my experience running Solar Fire (I originally designed the first interactive version of the website to be similar to a wiki) the problem I encountered is that this didn't valorize the individual contributors and there was no reason to try to create consensus data in the first place, as every contribution/idea can be valuable and there's no reason to try to harmonize different approaches to the same subjects to one degree or another, as is intrinsic to an encyclopedia (likewise for a open source software project, all the code has to be harmonized, but not so for open hardware where each builder can put their own personality into it).

    Also, needing to harmonize data on monolithic pages creates a huge burden on the administration and creates the situation where the contributors feel they are all contributing on equal grounds and have the same exposure opportunity as the main site personalities. For instance when conversion to solarfire 2.0 is complete, if I don't post I won't featured on the main site. In my experience with the wiki what happened was, even though I created access for contributors, they simply emailed me their info and Eva and I were left trying to integrate it somewhere. The result was a huge sprawling archive with no regular contributors.

    Solution
    So the new design I've recently put in place organizes all the data in terms of who contributed it. Basically a large blogging system. On top of this blogging system each article can have one or multiple key words attached, which can be used to create a vertical navigation by subject, which I'm working on now. So, this way each person has their own folder where they can post what they want, and on the main page various lists of last contributions by subject will be able to roll automatically. Since each user can have the administration rights to their own folder, they can manage it completely autonomously, so the administration overhead is significantly reduced to just oversight; likewise, since they manage their own content autonomously they feel much more part of the site and also that the site serves their own needs of communicating on their activities. When I have time I'll be making the personal pages more customizable by the contributor, so they control what's on the sides as well as part of the banner at the top; exactly the same service they would have if they made their own blog, but now with added value to them of having their content appear on the information hub concerning the subject.


    It seems the first part (Problem) highlights the features of MediaWiki (which is the software both Wikipedia and Open Source Ecology use), while the second part (Solution) highlights the features of Google's Knol.

    See this article comparing Wikipedia and Knol.
    Excerpt:
    As I state in the article, the problem is that Wikipedia does not allow the visionary or individualistic type of knowledge to be developed, because Wikipedia does not allow original content. Wikipedia's focus is on being a reliable encyclopedia. Knol's focus is on building from original or individual thoughts. That is a capability not served by Wikipedia.

    I'd like to highlight the fact that we could get some of the benefits of Knol-style wiki content if we encourage the use of subpages. Each wiki user would create subpages with the content they want to contribute (like the subpage about PDS - the Peer Domain System).
     
  • 4 Comments sorted by
  • To some extent, calling Wikipedia a wiki is misleading. A wiki (as I understand it) is an application designed to encourage collaborative contributions to a project (or set of projects) organized hierarchically by topics, cross linking, and other navigational aids. In my experience (and I've been a leader of three major open source projects documented on wikis - mostly Confluence based), people are afraid to freely edit a wiki. They worry about stomping on other people's ideas, messing up existing structure, and even the exposure of expressing a thought on a topic that may have more powerful thinkers.

    Fortunately, I believe that a wiki can be adapted to both curated and free-form styles of contribution. Curation adds structure, cohesion, adherence to established practices, etc. It greatly improves (usually) access to information for a reader (as opposed to a contributor). The curator holds the vision of the project structure in his (or her) mind and fits new pieces of data into that view. Meanwhile, free-style and ad hoc contributions should be generally encouraged. If people are proud of their contributions, they should be encouraged to sign it or somehow associate their name with the contribution.

    Where is breaks down is in finding good curators. On my other wiki projects (Sakai, Kuali, and Digital Marketplace), I seriously tried to find curators for sub-projects, with very mixed success. The Kuali Project (open source finanical applications for higher education - see http://www.kualproject.org) was formally organized around sub-projects and generally the project managers became the curators of their sub-project. This was done to various degrees of competence, as you might expect. On the Sakai Project (open source course management, see http://www.sakaiproject.org), sub-projects were much more free-form and ad-hoc. After eight years, the projects still doesn't really have curation of their wiki. I gave up pushing that rock up the hill. Finally, the Digital Marketplace project (an ecommerce approach to lowering the cost of text books for students, see http://www.dmproject.org), I curate the entire site (for which I am paid, fortunately).

    We should keep our eyes open for possible curators and nurture them (like the kind of support I've been getting from Pepe (sky0saje) and Elifarley.

    - Mark
     
  • I think that a wiki alone may be weak because a wiki is designed to capitalize off of multiple small contributions, whereas we have need of several very large contributions. That said, a wiki is a powerful and necessary tool because it allows for those multiple small contributions and I think it will be most powerful in the long run.

    It is possible to have an interconnected network of wikis, which point to user pages as necessary?

    Regardless, if we plan on creating a project that creates an individual autonomy, versus a group autonomy, then I think there would need to be a mechanism in place to help people stick to our ideals/goals in design.
     

  • Eerik has created a page to explain his proposed organic architecture.
     
  • My view is that a wiki can be used to create organized, easily accessed material an still use it like a sandbox where everyone can throw in what ever they like.  Though curators and organization people are needed to manage it, I think you have this need regardless of the tools used.  The social network approach (MySpace, FaceBook, etc.) proposed by Eerik just shifts the problems around.  Information is scattered in a thousand different blogs.  Building structured documentation out of that (as he proposes) requires curators and organizers - just as you do in the wiki.

    I favor staying with MediaWiki.

    - Mark
     

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Login with Facebook Sign In with Google Sign In with OpenID Sign In with Twitter

In this Discussion

Tagged

Loading