StigmergicWeb

Stephen commented on Quentin D’Souza’s post regarding building a wiki community (originally from Danny Horn of Muppet Wiki).

Wikipedia, he says, is not just a larger wiki with a larger contributor base than a small wiki with a group of 50 contributors (such as Muppet Wiki). Wikipedia can control content by having a large base of contributors/editors (about 43 000 according to Danny). Having such a large pool of eyeballs to keep watch on the content can spot and erase vandalism quite quickly. How can a smaller wiki prevent vandalism and spamming?

A small wiki is different from a big wiki, not just in amount of content or number of contributors. The relationship between the contributors is also different. The contributors of Wikipedia probably don’t know much about each other - 43 000 is way way bigger than Dunbar’s number. In a smaller wiki, contributors have the chance to know of all the other contributors. Muppet Wiki has a policy (community value?) that contributing members must have a user name. Enforcing a user name might seem contrary to the wiki way, but it serves its purpose within a small wiki:

The User Name policy helps to weed out vandals and creeps — and it also helps to build communication and trust. Having a stable identity makes communication possible. Contributors with user names build a record of contributions, and a reputation. If the community as a whole knows that a particular contributor is trustworthy, then that can influence how conflicts get resolved. You need a stable identity to earn people’s trust. Allowing people to sign in with a random string of numbers breaks down the community’s sense of trust and common goals. You can’t build a strong team of trustworthy colleagues that also includes shadowy, faceless strangers.

One word that keeps appearing in that description is trust. Rick Schwier has done some research on online communities, and one of his findings is that the most important element by far in an online community is trust. Trust is the glue that holds any community together. It is especially important in online communities because it is the key form of social capital. Trust is what Muppet Wiki has that Wikipedia does not, at least not in the same degree.

In something the scale of Wikipedia where there are thousands of contributors, the degree of trust between contributors is going to be limited. It may be an effective model for managing a large corpus of content, but it cannot be truly described as a community. Muppet Wiki is much smaller. There is trust between the contributors. Membership is limited so that those whose behaviour is contrary to the policy of the wiki will not be allowed to join the group. Muppet Wiki is a true community. In a smaller wiki, the quality of the content is maintained not by the overwhelming numbers of contributors. It is maintained by the trust that contributors - the members of the community - have for the community goal (information about Muppets - I can definitely respect that as being a worthy goal) and for each other.

It is now all finished. The project is complete, even after some major setbacks. The paper that accompanies the project is done. And the presentation was this morning.

Done, done and done. I still have one more class before I can add more letters after my name, but the big hurdle is finished.

One of the tidbits of information I included in my paper and in the presentation was my list of lessons learned. I want to pass these along to anyone who might need them:

• Back up your data. Often. In multiple locations. If you are lucky, you will consider this to be a waste of time.
• Get out for a walk. Stretch. Taking breaks occasionally will actually save you time in the long run (as long as they are breaks from the work and not an end to the work).
• Have reasonable expectations. More than likely any one project or thesis will not revolutionize your field of study. Add a good solid contribution to the corpus of knowledge and you will be doing an important job.
• When designing instructional resources, think long and hard about your target learner group and your content/learning objectives before picking a medium of delivery. Its fun to work on something with a lot of techno-cool bells and whistles because, to be honest, we (instructional designers) tend to be somewhat of a geekish lot. But the bells and whistles might not be the best way to deliver the instruction to the learners. Make the method and medium of delivery as simple as possible and not one bit more complex than is absolutely necessary! I found that I ended up creating the resource in a much simpler and straight-forward manner than I originally planned because I was bedazzled by the delivery method (”ooooh - a cool and sexy looking website with lots of embedded Flash multimedia that show off what a slick designer I am“). Consequently I ended up spending a lot of time exploring quite a few paths that didn’t go where I needed them to.

I pass these words of wisdom on to you that you don’t need to repeat my mistakes. Find some original mistakes instead! ;^) Yet somehow, I don’t feel like everything is done. I’ve spent a lot of time putting this project together, and I’m not ready to let it die. One of the ideas that occurred to me as I was finishing up the editing was that this project would have made a dandy CD or podcast. An overwhelming amount of the video footage is me talking. If I’m going to be revising/tweaking the project, that’s how I’ll do it.

At the last minute, I also thought it would be a good idea to have some links to appropriate resource materials for anyone who is interested. To that end, I’ve set up a Digital Audio Guide wiki. It is quite sparse right now, but I will be adding to it quickly since I put the address for it in the credits of my DVD. If you are interested, you can find it at digitalaudioguide.wikispaces.com. If you can think of anything I should add, give me some comments right here or send me an e-mail at robwall@gmail.com

The EdTech Posse Podcast 2.5 is out. Heather Ross and I had a great conversation about wikipedia and stupidity (not implying any connection, but you can draw your own conclusions).

Google has acquired JotSpot

Fear the Google-plex. They know all, they search all.

But I’m still keeping my Gmail account. And I’ll probably use the wiki when it is available. I’ve always liked JotSpot but didn’t feel it was worth paying for with so many other free wiki spaces available (like wikispaces or pbwiki). Now I’ll have to give it some deeper consideration. My preference is still to host my own wiki when available, but when I make recommendations to teachers they need something quick, easy and accessible for free. Do we see the outlines of Google Office starting to take shape here?

Just saw this via Brian Lamb:

Stewart Mader has published a book Using Wiki in Education, which has some interesting sounding (I haven’t actually read the book yet, so this is one of those Read The Fine Article reviews) case studies of wikis being integrated into a variety of settings. Stewart’s publishing model is an interesting mix of traditional publishing and open content. Intially, two chapters (of ten) are free then every month a new chapter is made free. For $19, you get access to the entire book, the ability to download chapters as PDFs and access to edit the tenth chapter. If you just want the content online, it’ll be free in 8 months. If you want the whole book now, you want access to the PDFs or you want to be able to participate in the content of the book, you fork up the $19 (which is not a bad price for a good book). I’ll probably pay the $19 just to support a great publishing model.

Watch for my book Turning Random Streams of Consciousness into Content soon.