Being proactive with bugs - search, not categorise.
I like to search for bugs, not so much wait for them to be reported in one specific way. Here's a story to illustrate what I mean.
As part of a new pygame release we've been improving the pygame bug reporting, and fixing system.
The old(and current) system used the mailing list as a bug reporting system. We still use this system, but have added a few other methods. People simply report bugs and patches to the mailing list. Then developers search through the mailing list, and noted when they were fixed, on the mailing list. Because the pygame mailing list is quite large often a lot of people would view, review and fix the bugs. It also informs people how to report a bug - because people on the mailing list see it happening every now and then.
Having bugs in the mailing list is nice, because I can type BUG into my mail programs search function to find bugs. Or I can type PATCH to find patches. Or I can have my program filter emails with bug, patch from specific mailing lists to bug, and patch folders. When a bug is fixed, or people want to discuss it, you can just tell them in the email.
Some times people also email me directly about bugs - which is pretty easy if they don't want to join the mailing list, or put it into a bug tracker. People also leave bug reports in our web based documentation commenting system - and not only documentation bugs.
However bugs often got reported in all sorts of other weird places. People talk about bugs in OS distribution bugzillas, random blogs, and also random forums. As well as people talk about bugs on irc. There are also SDL specific bugs reported in their bugzilla (pygame depends on the Simple DirectMedia Layer).
So rather than waiting for people to submit their bugs in a particular way - we now go and search for them too. On the pygame bug page, I have collected together a selection of links to different OS specific bug trackers. So it's easy to see how the OS distribution specific bugs are going. (ps freebsd, and gentoo have been the best updating their packages of pygame to version 1.8 so far).
Searching for bugs, rather than waiting for people to report them, and categorise them is the way to go. Luckily we have search engines which can search the internet for bugs easily.
So now, rather than typing BUG into my mail program, I can type it into a general search engine. Since mailing lists, bugzillas, forums, and blogs are all mostly indexed - my searches for bugs and patches work just fine.
We also have a web based bug tracker - a pygame bugzilla - for those who like to file bugs away in a database. Since some people prefer to submit, and track bugs that way.
update: This World of Reuse blog post asks if this proactive approach to bugs is scalable for larger more widely used projects like firefox. I commented on the blog how it could be added to any sized project, but the comment is still in the moderation queue. I found the world of reuse blog post with my "pygame bug" searching.
As part of a new pygame release we've been improving the pygame bug reporting, and fixing system.
The old(and current) system used the mailing list as a bug reporting system. We still use this system, but have added a few other methods. People simply report bugs and patches to the mailing list. Then developers search through the mailing list, and noted when they were fixed, on the mailing list. Because the pygame mailing list is quite large often a lot of people would view, review and fix the bugs. It also informs people how to report a bug - because people on the mailing list see it happening every now and then.
Having bugs in the mailing list is nice, because I can type BUG into my mail programs search function to find bugs. Or I can type PATCH to find patches. Or I can have my program filter emails with bug, patch from specific mailing lists to bug, and patch folders. When a bug is fixed, or people want to discuss it, you can just tell them in the email.
Some times people also email me directly about bugs - which is pretty easy if they don't want to join the mailing list, or put it into a bug tracker. People also leave bug reports in our web based documentation commenting system - and not only documentation bugs.
However bugs often got reported in all sorts of other weird places. People talk about bugs in OS distribution bugzillas, random blogs, and also random forums. As well as people talk about bugs on irc. There are also SDL specific bugs reported in their bugzilla (pygame depends on the Simple DirectMedia Layer).
So rather than waiting for people to submit their bugs in a particular way - we now go and search for them too. On the pygame bug page, I have collected together a selection of links to different OS specific bug trackers. So it's easy to see how the OS distribution specific bugs are going. (ps freebsd, and gentoo have been the best updating their packages of pygame to version 1.8 so far).
Searching for bugs, rather than waiting for people to report them, and categorise them is the way to go. Luckily we have search engines which can search the internet for bugs easily.
So now, rather than typing BUG into my mail program, I can type it into a general search engine. Since mailing lists, bugzillas, forums, and blogs are all mostly indexed - my searches for bugs and patches work just fine.
We also have a web based bug tracker - a pygame bugzilla - for those who like to file bugs away in a database. Since some people prefer to submit, and track bugs that way.
update: This World of Reuse blog post asks if this proactive approach to bugs is scalable for larger more widely used projects like firefox. I commented on the blog how it could be added to any sized project, but the comment is still in the moderation queue. I found the world of reuse blog post with my "pygame bug" searching.
Comments
Yeah, i agree with you in the sense that a bigger project also includes more bug finders/fixers, which enables your proactive bug search technique.
Cheers.