This information is gathered from our public bug system- Mantis – so none of it should be considered private or sensitive.
For almost a year now, I've been making it a weekly task to review the dotProject bug tracking system for any new items, reviewing each of them, and taking a snapshot of the overall counts. It has quite literally had its ups and downs but I wanted to share some preliminary numbers here (click image for full size):
So what do these numbers mean? What is the significance?
First some explanation: The black line (top) is the total number of Open Issues in the system. This includes anything that is submitted and not a) resolved or b) a duplicate. This includes feature requests – regardless of their feasibility – and issues with Add On modules which are not part of Core. The red line (bottom) is the total number of what can be considered "Bugs". This includes any unresolved issue where a particular piece of functionality is not working as designed regardless of whether it is what the user was expecting and regardless of which module it is in.
There are a few things to be gleaned from this data.
First, it shows we have an engaged user community. The vast majority of these issues were submitted by regular users. The more interesting aspect is that most of these users have submitted multiple bugs. This makes it unlikely that they downloaded dotProject, played around with it for twenty minutes, and went on their way. Odds are that these are people using dotProject on a regular basis and have an interest in seeing the system get better.
Second, it shos an active development community. Unfortunately, taking a simple count hides the fact that some issues were resolved and new ones were submitted to replace them. A steady stream of newly discovered issues demonstrates that the previous ones are becoming both less relevant and less prevalent and more complex and subtle issues are being discovered… though we do have a few that keep creeping up.
Third, it shows which of the modules are most troublesome. We have a handful of modules which have been around since the v1.x development and are showing their age. In addition, we have some newer modules which were under heavy active development and then quietly dissolved when their maintainers moved on. Neither of these are necessarily bad but they do cause problems within the community. By grouping all of these specific issues together, anyone devling into the affected modules can see the issues they're likely to face and/or what the overall status is. This serves as a powerful sign to the community on where to spend their time and effort.
Finally, and most importantly, with a bit of digging into the actual reports, you can see more and more of the issues are being accompanied by screenshots of the issue described, an idea on how it could be fixed, or – when we're really lucky – an actual diff of the fix applied to the file. Some of this has come about because myself and the other developers have been rigorous about requiring exact error messages, steps to reproduce the error, etc, but a user attaching a specific fix… This is a completely different class of users which we have worked and will continue to encourage, include, and foster their growth within the community. Yes, this requires a bit more in terms of people management but the benefits are at least 20x greater… they move the community farther, provide assistance to core and external developers, and a few could end up being the next core developers.
How does this stack up to other projects? Honestly, I couldn't tell you… but it would be interesting to see their data and know their trends.