Tag Archives: ticket-tracking

Listen To Your Customers

As I look at the statistics of SourceForge use, I think the one I find the most troubling is the daily opened vs. closed tickets count. The statistics are pretty clear – every day we have twice as many tickets opened as closed. That means that half of you aren’t listening to your customers.

Tracker Statistics

Now, I know what some of you are saying. This is Open Source. We don’t have customers. We write this stuff for our own amusement, and we don’t have to pay attention to the users. Of course, if that were actually the case, you wouldn’t be publishing this software on a public site like SourceForge, but would be keeping it to yourself. In the Open Source world, we tend to call the consumers of our products “users”, rather than customers. I prefer to use the term customers, because I think it creates a different attitude towards them, encouraging us to treat them with more respect and professionalism.


The easiest way to engage your user community is to listen to what they’re saying, and then respond to them. While that might strike you as an absurdly obvious thing to say, I encourage you to take a look at the open tickets against your project and see if you’re doing this. Identify the tickets that are duplicates, and merge them, informing the reporters that you’re doing this. This tells them that you care about the project, but also that you care about your customers. Also, identify the tickets that are invalid, and explain respectfully to the customer why they’re invalid, and close them. Perhaps the problem they’re experiencing has to do with some other piece of software, or some other condition outside of the control of your software. Or perhaps they just don’t know how to do something, which is explained in the documentation.

The harder task, of course, is addressing the legitimate tickets. One useful strategy for doing this is to use them as an opportunity to engage the developers in your community and give them a way to become more active participants on the project. For the simple ones, explicitly label them as simple, and perhaps even provide a short discussion of how you think it should be addressed. Encourage your community to have a try at fixing it. For the more complicated ones, I still encourage you to do the same thing. Add an explanation of how you would address the request, and possibly break it into smaller pieces. This exercise not only encourages participation from the community, but sets a roadmap for yourself, so that you can address things in stages, as you find time.

Using your ticket tracking system to map out your plans for your project also makes customers feel more connected, as well as less frustrated with your progress, since they know where their requests fit into the larger scheme of things.

Allura tickets

Also be sure to set your preferred support mechanism in your project admin. That’s set on Project Admin → Settings → Set Preferred Support Mechanism (on the right) for classic projects, and at Admin → Metadata for Allura projects.

Finally, an observation. I’ve noticed that a pretty significant number of projects don’t even have ticket tracking enabled. Not having any ticket tracking at all may be interpreted by your customers as a statement that you don’t care what they think. If you fall into this category, I strongly encourage you to enable ticket tracking, and start actively using it as a community-building tool.