You are here

lxde

Wikis in Open Source Projects

Wikis are great to collect information and they work well, the more active users they actually have. With the growth of Wikipedia the number of people who understand how collaboration works in a Wiki increased dramatically (even though in fact many users of the Wikipedia still do not seem to know, that they can actually edit pages).

For smaller numbers of contributing users I found, that it is sometimes difficult to keep information up to date or delete spam, that appears even though Antispam modules and Captcha tools are set up.

For example in the English LXDE wiki, we have quite some hits on the wiki, but if we look closer, many pages have outdated information about releases and roadmaps. As the wiki is available in many languages, it gets even worse in other languages with less community members engaging. A reason why the LXDE wiki might not be so active is probably because the project is more a project of developers collaborating with other developers. Developers are already busy coding. My observation is, that they simply do not have time to keep Wikis up to date.

Another example is the lubuntu wiki. Over time different people contribute to the wiki. The wiki was originally modeled after wiki pages of other Ubuntu derivatives like Xubuntu.  We had the advantage to use a basic structure, that might have taken others years to achieve. A very important point was also that there is an established model to deal with different opinions in a wiki. The lubuntu wiki is set up within the Ubuntu wiki. When we started there were already a lot of people who we could cooperate with and there was a functioning administration and hosting model, that we did not have to take care of. The wiki developed into a good resource and brought in people who also took on the special help pages for lubuntu.

Freifunk Wiki

Finally the freifunk wiki of the free wireless community. The wiki is in German, but during recent years also other languages were included as people from across the world started to participate in freifunk. There have been steady contributions to the content from different kinds of people. While some local communities themselves have often more content, the wiki remains to be an important resource and basis especially for new communities. The wiki is managed and maintained completely by the community. As we have many capable developers and IT experts in this project, it should be easy to maintain the wiki system and perform upgrades. The fact is though, that the activity level of people, including my own engagement, ranges vastly. This makes it very difficult to administer a wiki. And for newbies it is difficult to support a group as well. The most difficult part is to get into the group of admins. You need to get access and often root access to infrastructure. It is difficult to establish a level of trust with newcomers. Longterm members start families, might not show up at offline meetings and might not always be available. In a community there is usually also a previous experience with newcomers that disappear after some time or people who could be perceived as trolls. So, the result is often an attitude of a wait and see approach. In return newcomers, who want to push ahead with new cool stuff, get frustrated with this attitude. I have not seen a perfect approach to resolve this issue, but I find that real world meet ups that bring contributors together can help to solve this. In Germany many local communities have local meet ups. There are also bigger community events like the Wireless Community Weekend and even International get togethers like the Battle of the Mesh.

So, whatever you do, try to meet some people face to face and you will see how it also becomes more fun to work in the project.

Kategorien: 

What works well for community projects – wikis, blogs, forums, cms, IRC

I guess in any project – open software, hardware, content –  there are established working models and processes, that develop over time and help everyone involved to get things done.  Those processes need to be explained and communicated to newbies taking time and adding overhead to volunteer projects. Tasks not everyone is interested in as experience also shows that not all newbies stick with projects. So, what to do? 

A way to reduce overhead explaining newbies how to involve is to stick to established channels, standard collaboration tools and work processes. Forums, wikis, content management systems, IRC channels, mailing lists are all great tools, but when does a wiki make sense for a project? When do forums, IRC and mailing lists all make sense?

Generally saying my experience is that projects that are more focused on technology and with lots of developers tend to do good with mailing lists, IRC and sometimes forums. Wikis and website documentation works much better, if you have people who can actually invest time in creating and updating content. Documentation is a weak point of many software projects as it is not always fun and takes time. For most developers it is much cooler to develop a new feature, than to write a document about it, but if you have people who would like to support other areas, but cannot code, then go for it. Maybe even start a documentation team.

Project blogs work well if the project team is not too big, as people seem to be somehow feel attached to a project to blog. It works well for projects with real “core people” and are small or midsized. On the other hand if the project is very big, the question arises who has the right to write on the blog? Or, who will actually write something, if the community is diverse and dispersed?

Of course there could be projects where things are different, but the above is how it works in my experience.

Kategorien: 
Subscribe to RSS - lxde