Understanding Fog Bugz Discussion Groups

There are many, many software packages out there that support discussion groups. So why does FogBugz have its own? There are two good reasons for this. First, coupling discussion groups to the case-tracking system gives you a really easy way to find customer complaints and ideas and move them into the system where you can act on them. Second, the folks at Fog Creek had some particular ideas about how a discussion group should be run, and they wanted a product to implement those ideas.

The result is that FogBugz discussion groups act like other discussion packages in some ways, but are unique in others. Although you can always hack around in the FogBugz source code to change the way that discussion groups behave, it's worth understanding some of the design decisions here before you do so. You might find, on reflection, that you like things just the way they are. As you read through the rest of this chapter, keep in mind the primary axiom of online communities:

Small software implementation details result in big differences in the way the community develops, behaves, and feels.

One thing you'll notice is that the discussion groups are very easy to use. Once you master reading a topic, creating a topic, and replying to a topic, that's about it. You don't need to go through any registration procedure or use a particular browser to participate. The result is that there are no artificial barriers to participation, and everyone is encouraged to participate (so are spammers, but as you've already seen, FogBugz implements a defense-in-depth against spammers).

On the other hand, there are two features that are present in many discussion groups that FogBugz doesn't implement: e-mail notification and branching conversations. Both of these are deliberate omissions. If you allow people to subscribe to a conversation via e-mail (usually implemented with a checkbox that says something like "e-mail me if people reply to this post"), you've just removed the incentive people might have to come back to the discussion group. The result is that conversations will peter out quickly, and you'll have a hard (or impossible) time building any community. Eliminating this one little checkbox encourages (OK, forces) people to come back. While they're back, they might read a few more posts and contribute a few more of their own.

Branching conversations seem reasonable to programmers; let people reply to any post in a discussion and start a new thread of discussion from there. But if you implement branching, you'll find two things. First, it's incredibly hard to come up with a user interface that makes multiply branched conversations easy to follow. Second, the same idiots will branch every discussion in the same idiotic directions. Without branching, discussions tend to stay on a single track, which makes them much easier to follow.

Even such a simple decision as page arrangement can have major consequences. FogBugz, for example, always keeps topics sorted in the same order: the topic that was started most recently remains at the top of the list. Many other packages sort in order of most recent reply instead. With the FogBugz system, topics automatically age off the home page, rather than hanging around forever. This prevents perennial arguments from hijacking your forum, spawning discussions that run hundreds of replies, and scaring new users away.

Locating the Reply and New Topic links at the bottom of the lists is also a deliberate decision. This is a way to at least try to encourage people to read the discussion before replying. At the very least they have to scroll past it, and perhaps they'll notice that someone else has already made their point.

FogBugz doesn't show you the discussion thread while you're writing a reply. This is to encourage you to actually compose your own reply, rather than quoting what went before. Quoting may seem like a fine idea when you're writing a reply, but think about the next person to come along: do you really want to sentence them to read everything twice? I didn't think so.

A final note: none of these technical decisions will do the whole job of turning a discussion group into a useful, friendly, and energetic community. More and more companies these days are turning to having evangelists (or customer support representatives, or transparency managers, or whatever the heck they want to call them) whose job it is to promote community. If you're planning on using discussion groups as an important part of your public face, it's worth making sure that someone in your organization is passionate about community, and that they have promoting community as part of their official, paid job description.

0 0

Post a comment