• Anzeigen
• Bearbeiten
• Versionen
• Druckansicht
• Rückverweise

WikiGroupMotivation

Why WikiGroups?

Explanations about WikiGroups given by Patrick R. Michaud on the [pmwiki-users] mailing-list

''Over time people have asked for something that could contrast WikiFarms and WikiGroups, especially the advantages and disadvantages of each, and I agree such documentation is needed.'' But thus far I haven't been able to come up with a concise description, so lacking that I'll just tell the story, motivations, and conceptualization behind each, and perhaps we can all refine it into something that works well on a page. Or maybe the stories will suffice.

For this message I'll talk primarily about WikiGroups, and save WikiFarms for another message (since they came later in development). And I'll just present things as a narrative -- a history -- since this is still the example I work from when thinking of how WikiGroups can work. Apologies in advance for the length of the narrative -- if I knew a good way to shorten it we'd have our description. :-)

In September 2001, when I wrote the first version of PmWiki (pmwiki-0.1), my desire was that the various groups I worked with at the University and elsewhere could use "wiki" concepts to maintain web sites that were otherwise unmaintained. In general, the overarching theme was that each of these web sites had its own designated webmaster, but that web maintenance was only a small part of each webmasters' overall duties. What's more, the webmaster typically served as a bottleneck, in that even if there were several people willing to update page content, they had to coordinate or submit the changes to the webmaster for them to take effect. So, updates happened rarely, if at all, and the sites quickly became out of date. ("Page rot" is the common term.)

Since I was the webmaster for several of the sites, anything that I could do to empower others to update the site without involving me would be a Good Thing. This is a central theme behind PmWiki development -- make it possible for other people to do the work that I would have to otherwise be doing. :-)

So, I created the first version of PmWiki, and started using it to build and maintain web sites for the various projects and groups I was involved in. These included a research group, the computer science club, the college, my academic department, each of the various courses I was teaching, as well as my own personal pages. Initially I started out by installing separate copies of PmWiki for each "group" that wanted a set of pages.

Pretty soon, other people, departments, instructors, and organizations saw how I was using wiki to maintain my site, and they all wanted wikis of their own. So, I'd either get them to build pages in one of the wikis I had already set up, or install yet another copy of the software somewhere that they could use.

With only one level of page names, having independent groups try to share the same namespace didn't always work well. There could only be one page named "MyResume", and so authors had to "plan ahead" as far as what to name their links and pages.

Also, there wasn't a good mechanism to be able to protect a set of pages from being edited -- one could protect individual pages, but that got really tedious if there were several dozen pages to be protected (and every new page had to have a password added to it).

So, since the single flat namespace wasn't working out well, pretty soon I was fielding more requests for independent wikis. This involved installing a new copy of the software, coordinating software updates, and trying to keep track of all of the RecentChanges pages to make sure things were going well.

Of course, this went directly against my goal of getting others to do the work. :-) Of course, I could've just started handing people copies of the software and telling them to maintain it, or making it possible for people to create their own fields in a wikifarm, but that would require that others know the same things an administrator would need to know, and many of the people who wanted to create wiki spaces didn't even have a Unix account.

What I *really* wanted was for >>authors<< to be able to create their own "wiki spaces" without them having to become wiki administrators or ask me to set things up for them. And I wanted groups of people to be able to create and reorganize pages on a moment's notice. Thus, the concept of WikiGroups was born -- as a way for people (non-admins) to create their own spaces for wiki content without having to seek out or become an administrator to do it.

One of the key ideas behind WikiGroups was that it would be possible to make each group "appear" to authors as though it was separated from other groups on the wiki. Thus, each WikiGroup can have its own set of passwords, header, footer, and skin. Each WikiGroup could have its own "HomePage", "RecentChanges", etc., and to someone who didn't know anything about "WikiGroups" it all appeared to be its own wiki. But for those who did know what was going on -- and it didn't take long for people to figure it out -- they could share a common set of documentation, help files, tips for using the wiki, etc., and they could also easily link to related pages belonging to other groups (e.g. the CSClub could link to pages in the CSDepartment or to course notes in the COSC1435 group.)

From my perspective as an administrator, this was a much better scenario than the original one. First, whenever someone wanted a place for wiki pages, I didn't have to install anything, I would tell them "just create a page in a new group". Even better was when they stopped asking me even that -- since there were plenty of other people around (besides me) who could tell them how to do it. Soon people started sharing with others the details of setting group passwords, creating new pages, making "skins" using GroupHeader and GroupFooter, etc. My involvement became more along the lines of improving the software, updating a few installations, and helping out with the occasional problem or feature request.

Another advantage of the WikiGroup structure was that I could monitor a whole bunch of groups at once through the AllRecentChanges page.

The things that have happened since then with WikiGroups are really just extensions of that original concept -- i.e., make it possible for authors to create specialized sections of content without necessarily having to involve an admin to do it.

To show how well it works in practice, the student wiki at Texas A&M University- Corpus Christi currently has 5,372 WikiGroups. Yes, that's *groups* -- there are currently over 180,000 *pages* on that wiki. The instructors in the First Year Program all walk the students through the basics of creating a personal WikiGroup, editing pages in the group, and linking to other pages, and then the students use that throughout the academic year for various assignments, information, and collaborative projects with other students. The wiki administrators (all part-time) never have to deal with creating the groups, other than to handle the occasional issues with forgotten passwords or upgrading software. (And several of the instructors in the program have been given the site admin password so they can resolve password or content problems without having to contact the wikiadmin.)

So, that's the history and original motivation of WikiGroups. It's primary feature is that it allows creating new sections of related content without having to involve an admin, but still allows an "overview" picture to be formed from all of the groups.

More about WikiGroups versus WikiFarms in a later message.

Pm?