Here’s an entertaining collection of bug reports:
A bug report is sometimes entertaining either because of the personalities involved or because of the bug itself. Here are a collection of links into public bug trackers; I learned about most of these in a recent Twitter thread.
GitHub blog brings us a piece of exciting news – now you can add more attachment types to comments. The list is no longer limited by images alone. Now you can attach Microsoft Word, Excel, and PowerPoint files, as well as plain text and PDF documents. This feature alone will make GitHub Issues into a much more viable bug tracking option for many projects and companies.
Phabricator – code review, browser, bug tracker, and wiki
Phabricator is an open source collection of web applications which makes it easier to scale software companies.
For those people who can’t afford GitHub, this should be a pretty good alternative. Developed at Facebook. All you’ll need to do is setup your git repositories.
P.S.: The best product descriptions ever (for parts of the Phabricator).
Holy Molly! Finally, one of the two things that I’ve been missing a lot from GitHub saw the light of day. From now on, GitHub issues can have attachments. So far, they are limited to only image types, but that’s enough for the majority of the situations. Because that’s what you need the most – a screenshot illustrating the problem.
Now, if only one could open up project issue tracker to general public without playing around with the API, GitHub would be complete and absolutely perfect. But something tells me that’s just a question of time. So, waiting …
Here is a quote from the Google Chrome 12 stable release blog post:
We’d also like to call particular attention to Sergey Glazunov’s $3133.7 reward. Although the linked bug is not of critical severity, it was accompanied by a beautiful chain of lesser severity bugs which demonstrated critical impact.
My focus here is not on the money that Sergey earned with his bug report, even though that is definitely an important and motivating factor. My focus is on the chain of the events. While this chain of events happens pretty much every time a bug is fixed, few people know about it. Maybe nobody, in fact, except for developers themselves.
The thing is that when a bug is discovered and fixed, pretty much every developer searches the code for problems similar to those brought up by the bug report. Be those issues typing mistakes, documentation inconsistencies, memory leaks, security issues, performance bottlenecks, or anything else – the code will be checked to make sure that the same problem doesn’t come up twice. From this perspective, I think that bug reports are so important not because of the specific bugs that they report, but because of those other bugs which aren’t yet fixed and probably aren’t yet reported.
Conclusion: every time you come across a bug in the application, don’t just work around it – take a few minutes of your time to report the problem properly to the developers. Chances are, they will fix some problems that you haven’t yet come across, but have pretty good chances to otherwise.