Kate Watson of the University of the Sunshine Coast is one of the RUBRIC project managers. She's writing a paper on wikis, and is collecting various perspectives on the wiki we use on the RUBRIC project.  We have a closed wiki for the RUBRIC central team at USQ and our network of partners, each of which instiution has a project manager.

With Kate's permission, I'm posting my answers here.

1. What are the group's needs for collaborative group knowledge creation?

The RUBRIC project is all about collaborative construction of knowledge, initially amongst partner institutions. At the end of the project we'll be publishing some reports and information kits that aim to help other institutions build institutional repository infrastructure.

There's an information lifecycle at work. The extended RUBRIC team uses highly interactive knowledge construction to come up with solutions that will then be packaged into a toolkit that can be used by others.

We need to keep track of a lot of technical documentation and software configuration as well as vast amounts of literature on the subject.

2. What tools are available to the group to enable collaborative group knowledge creation?

Knowledge resides in individuals, everyone has to construct it for themselves.

The tools and practices we use, in roughly decreasing order of interactivity:

• Face to face meetings.

• Teleconferences.

• Email, both one to one and via lists.

• Del.icio.us bookmarks, as described in a previous post.

• Job tickets in our Trac project management system.

• Wiki pages.

• Documents such as reports for publication on the website.

  RUBRIC central uses ICE for these, meaning we can get both HTML and PDF versions and compile book-length content easily.

3. Why a wiki?

The initial impetus for getting a Wiki was that it came as part of the Trac system. I first used Trac on the ICE project, where we picked it for its integration between Subversion version control and job-tickets.

On RUBRIC  we chose Trac for internal use. I did not try to push it to the broader RUBRIC team, partly because the 'official' USQ system is Microsoft Sharepoint (does nothing for me, particularly on a Mac).  We made the project managers aware of it. Gradually the RUBRIC partners adopted Trac and its wiki and the wiki has turned out to be useful for jointly constructed pages where interactivity is important.

So our use of the wiki evolved organically, it was not part of a pre-meditated project methodology. Having used it though, I think I would recommend it for future RUBRIC-like projects. This means we'd better document how we use it. (I think Kate's paper will do this).

4. Technical Information?

We use the open source Trac system running under Apache on Red Hat Linux on a virtual machine running on VMWare ESX running on Dell hardware, plugged in to a SAN.  User authentication is via LDAP. Backups are via ESX  ranger running on another (Windows) Dell machine. Backups go to hard disk, and then to tape, and the tapes are sent off site.

Trac has proven to be a stable, low maintenance piece of software.

Trac's wiki is perhaps more useful than a stand-alone wiki in that it is tightly integrated with a version management system, Subversion, and a job-ticket system.

We use some Trac macros developed at USQ by Sally Macfarlane to help with Task estimation. This is not an important part of RUBRIC's work, but it is useful in the ICE content management system. If you want them contact me.

5. How has the wiki supported collaborative group knowledge creation?

(Experience and Comments from an administrators point of view.)

I don't have a lot to say from an administrative point of view. Trac 'just works' once one has the users set up.

A wiki is like a garden. It needs pruning sometimes, and weeding, and the harvest needs to be gathered. The harvest in our case is material that is ready to move to published document form and go on our public website.

6. Administration issues

Trac has no major administrative issues, apart from the fact that it does not come with any user authentication – that has to be handled via the Apache web server.  For use in a large institution this is probably a good thing: it allows for the software to use existing service infrastructure, for smaller stand-alone projects it could be a problem. We had to set up our LDAP server but that was a useful learning experience.

Remember that our wiki is closed and we have a civilised project team so there are no issues with spam or vandalism.

7. Administrator opinion on Pros/Cons/Benefits/Limitations

The Trac wiki system has a few quirks, using some wiki formatting that is less than natural. Attachments to Wiki pages are also less than ideal – they are not version controlled as far as I know, but given that Trac included subversion they easily could be.

The Trac ticket system is a little bit clumsy, and for general project use, rather than on a development project, it could be better integrated into a Personal Information Manger (PIM) application, such as Microsoft Outlook.

I think other wiki systems might be good for RUBRIC style work, but Trac is adequate. It's more than adequate for development projects like ICE.

The biggest strenght of Trac is its integration with Subversion. I'd love to explore similar integration with ICE so that documents written in wiki format could migrate to a word processor and the other way round, one could edit word processing documents using a wiki syntax.