Blogs

Open source projects and products suffer from a unique problem when it comes to managing bug reports.  The open nature of the community means you'll get many more excellent bugs filed as compared to a proprietary, closed-source product.  But you'll also get:

• More poor reports (compared to closed source, proprietary products).  Poor bug reports are ones that are hard to understand, have no reproduction instructions, are improperly categorized, etc.
• More "drive-by" reports, where a reporter files a report, and then disappears, never to be seen again.  Requests for clarification go unanswered.
• Bugs that really were bugs in the past, but happen to be fixed in later releases as a side effect of some other work.
• Lots of duplicates.  Not everyone searches first :)
• More requests for help.  Some people like to file bugs instead of asking questions on forums, mailing lists, etc.

The effect this has is to obscure the true quality of the product, when these "bugs" are mixed in with "real" bugs.  It is a project manager's nightmare to be faced with a mountain of bugs and a looming ship date.  It is the fodder of disgruntled users (read the comments on Dana's Article) who point at it and say "look at all those bugs!".

We (the Liferay Community) have made great strides to improve the perceived and measurable quality of Liferay.  In the last several months many of you have read, classified, and tagged the mountain of tickets.  Some have been rejected (ideas that didn't make any sense), or closed (already implemented), and differentiated between bugs and improvements/enhancements.  New ideas are being placed into two queues: Product Backlog and Community Backlog (more on these buckets in a later post, but hopefully it will spur more community contributions!).

In an effort to further clean up bugs, and in conjunction with the recent major release of Liferay 6, we have been targeting bugs that we believe can be closed (for a variety of reasons, such as those above).  Many of them are old and I believe a large percentage of them no longer exist (or weren't bugs in the first place).  I'd like to get rid of these ASAP using the following process (please give your comments if any):

1. Create a new category ("Bug that probably won't be fixed")
2. Assign bug to that category along with a note about why
3. Timeout after 2 weeks, and close the bug, with a "if it can be reproduced in 6.x, please re-open".

This is based on a discussion many of you probably remember (or participated in).

In addition, I am working on some docs for "how to file a good bug report" which will be added to the JIRA system and hopefully ward off future bad bugs.  Getting rid of the last vestiges of these non-bugs will also encourage the entire community to maintain a tidy issue log.

In the future I would like to encourage other community members (not Liferay employees) to actively participate in issue management.  If everyone pitches in (for example, validate one bug per week against Liferay 6.x!), it is very easy to maintain a clean issue tracking system!