[pmwiki-users] Why WikiGroups?

[Patrick R. Michaud]

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