I’ve been playing with habitrpg, which gamifies habit-setting. You have a little character with experience points, hit points and gold pieces. You earn experience and gold for achieving your habit goals. You lose hit points for failing to achieve goals. (Aside: habitrpg is open source, so you can host your own server if you like.)
A character from habitrpg
This got me thinking about gamification as a whole, and what problems it could be usefully applied to. My thoughts turned to issue tracking systems. I think that a gamified issue tracker could be very helpful, especially for an open source software project.
But I Already Report Bugs
Gamification can be used to give users extra motivation to do certain tasks. For example, I might try to make my Stack Overflow question clear because I earn reputation points when people vote for my question.
But users want the product to work, so they already have motivation to report bugs—provided of course that think it probable that the developers will do something about their bug report. And users with ideas for improving a product already have motivation to pass their suggestions to the developers, though in some cases the obstacles for doing so make it not seem worth the effort. So what good would gamification be for an issue tracker?
Dealing With Old Tickets
The longer you leave a Todo in habitrpg, the more experience points and gold it becomes worth to complete that Todo. One of the biggest problems I’ve seen in the use of issue tracking systems (in every project I’ve ever been involved in) is the issue of old tickets. Invariably, some tickets seem like a lot of work for not much reward. In a business setting, these don’t get done because of perceived lack of return on investment. In an open source setting, developers are more likely to choose to work on easier or more exciting tasks. The end result is that every so often someone has to trawl through old tickets, half of which are no longer relevant, and decide what to do with them.
What if closing bug tickets became more worthwhile (in terms of game motivations) the longer the ticket remained open? That way developers would have the motivation to look at older tickets, and at the very least decide whether they should be closed as “won’t fix”. Naturally, you’d need to temper the motivation to just close every ticket, so an accountability system might be in order (perhaps one other developer reviewing the close, or perhaps multiple developers up- or down-voting the close).
Inviting New Developers
In many open source projects, there is a perceived barrier of entry to the community of developers. As with any new community, newcomers are uncertain what’s expected and appropriate. What if every ticket on the issue tracker was a “quest” that users could embark on? The quest page could include clear instructions for how to contribute code to the project. On your first adventure there could even be a side quest of subscribing to the mailing list or introducing yourself on the irc channel or whatever’s appropriate for your community. That way it’s not only clear to newcomers how to get involved, but they know that there’s a reward for involvement.
Communicating with Users
I have reported bugs for some products, and never seen a response from a developer. The only responses I’ve seen have been from other users saying “me too”. If no developer is assigned to the bug, we might rely on the mechanic introduced above where older tickets are worth more. But what if a developer accepts a bug ticket, and then becomes distracted with life and things? Everyone, including other developers, might assume that work is being done on the task, but as a user how do I tell?
In a gamified issue tracker, this could be dealt with by rewarding the ticket owner for posting regular updates, or perhaps even penalising them for not posting regular updates. Before accepting a quest, it could be made clear to the developer that this is a commitment, and in-game motivations could be introduced to make it more worthwhile for a developer to withdraw from a quest so that another developer can accept it than to keep a ticket assigned without working on it. And if things are getting done but the going is slow, at least the users would know about it.
Rating New Ideas
If users are suggesting new ideas on the issue tracker, why not get them to evaluate each other’s ideas? Give people motivation to say how they think other people’s ideas will add to or detract from the software. Let people vote for each other’s ideas and evaluations. That way the users are a part of the process, and they make your job of prioritisation just a little bit easier. The rewards for implementing these new ideas could then be set (probably manually, but perhaps automatically depending on your project) based on user reactions to the idea.
Sounds Good, Where Can I Download It?
This is only an idea. I haven’t implemented it and I probably won’t get a chance to even look at it for at least a few months. By then I may well have other interesting toy projects to fiddle with. If you’re interested in helping to make this a reality though, let me know! I’m more likely to work on projects which have others willing to play a part.
There are a few existing pieces of software that combine bug tracking with gamification. The two I can find information about are:
- RedCritter: non-free, and from the review it looks a bit clunky and not as community-oriented as I’d have made it
- JIRA Hero: adds badges and achievements to the non-free JIRA project tracker
Further Reading
In my search for existing products of this kind, I came across these two articles which both suggest use of gamification in issue trackers, this article which lists a few other gamified software tools, and this article about how gamification should be used and when it should not be.
