If you try to use a wiki for issue tracking, you'll find that it works well in some ways, and badly in others. Now, issue tracking may seem esoteric, but most projects end up needing it. Today I'll explain why that is, why it does not scale, and how to do this properly using Wikidot.
If you read this blog regularly you'll see that many people use it to report problems. Of course that's a good thing: we want to know when things are broken so that we can fix them. This is the same in any living project. If I'm writing an article and someone spots an error, they tell me about it, and I fix it. With the magic of wiki, we can go further and just co-edit the article directly.
But more often there is a workflow: person A produces a work; person B finds and error and reports it; A fixes the error; B confirms the fix. It is hard for several people to collaborate as co-editors on the core design of a thing. A book with two authors tends to get confused. So it's usual that each A handles fixes to things they're responsible for.
If a handful of people cooperate on a project, they don't need much of a workflow. It's a cloud of activity. But when five thousand people (or as with Wikidot) 350,000 people could be playing the part of B we get a problem of scale.
What happens then?
- We lose track of reports. If we don't handle them immediately, we forget about them. This is fine when fixes are small, but as soon as there are two or more large fixes to do, we're in trouble.
- There is no record of what happened. People start to report the same problem twice, and when a problem is actually a question, people ask the same question over and over.
- There is no organization. Either all discussions are grouped together in a single place, or they are spread out in an unpredictable fashion.
With Wikidot's notification system we can follow many sites, so if someone asks a question about, say, one of my themes here on the blog, or on the themes site, it's much the same. But how about a second person asking the same question?
One solution is to have lots of people playing the part of A. Then we get something like the Community site, where no question remains unanswered for long. This also works when no-one is really responsible for specific works. The Wikidot Handbook is a different kind of beast, with a few editors handling all issues.
So we see several kinds of organization:
- Small clouds of people who make things, and can keep all the process in their heads.
- Large clouds of people who do not need a process because they're not making things, just discussing.
- Small clouds who make things, talking to large clouds who report issues on those things.
And a successful project tends to fall into the last case. Here we have the Handbook, the Themes site, the Iron Giant templates, and Wikidot itself.
The best approach we know for these larger projects is:
- to create an explicit space for each project's issues.
- to use tags to separate open and closed issues.
- to use ListPages summaries to show open and closed issues separately.
Being able to tag threads as "open" and "closed" is important, and it's why we're not using the built-in forum feature for the new forum template. It uses categories, pages, parent pages, tags, and ListPages summaries instead.
Now for the practical exercise. This week we'll be gradually rolling out the Iron Giant template sites. For that, we need a place to discuss the templates, report issues, and track those issues. This week, we'll be taking the forum template and using it to construct the new forum project.
My proposal for issue tracking categories (each covering announcements, issues, and use of) in this new forum is: