Digested

A user/packager/developer/sycophant finds a bug, needs to communicate with a developer to alert them of the issue. The information goes into a huge, unwieldy database that only the most intrepid and dedicated read, probably to rot. And we wonder if adding another field would solve the problem.

This is a social communication issue. How many patches have languished in bugzilla for months? The system encourages the gathering of useless information, and actively prevents access to useful data.

Maybe the whole paradigm is borked. I'm sure there is a wealth of useful data in bugzilla. Just like there is in the box of papers I hauled to the dump the other day. Anything really important will show up again anyways. Bad news always comes back.

First off, developers know what are bugs and what are just unfinished features. Unfinished features are on a list somewhere and don't need to clutter a public database.

Anything over two weeks old automatically drops to /dev/null unless it is marked as valid by the developer. Important stuff will show up again. Without the necessity of handling everything, important stuff will be handled.

Some apps that are at the stage where large numbers of bug reports are just noise (see unfinished features), refuse bug reports. The developer probably has the 10 or 20 users that he/she listens to anyways. Once things have matured, open bug reporting to catch the odd corner case.

Force the reporter to make a commitment; don't open a bug until it is confirmed a second time by the user, with more explanation. An automatic email asking for confirmation and more information a few days after the initial report will confirm whether there is really a problem, and if there is, the user will have more data to supply.

Attached patches generate emails to 30-50 developers picked at random from those who have committed recently to svn in a similar module. IOW, patches will be picked up and handled. Derek and Sam stop selecting commits that refer to bug numbers, which probably has encouraged the insanity :)

Developers get a private email address that they give to packagers and those working with them as testers to report directly. When the traffic gets too high, get another email address.

After feature freeze, at some suitable time, open a channel for bug reports such as a mailing list. The flood of emails will probably give a good idea of the state of the release. And a side benefit of focussing attention on bug fixing without forcing developers to wade through mounds of marginal information in bugzilla.

Nurture a category of users; Testers. Recognize these individuals that are available for testing, capable of maintaining a build system and willing to submit bug reports directly to the developer. Developers at the unfinished features stage could then easily find testers to help bring the software to maturity. This doesn't mean closing the development process, rather is a means of providing a resource, and encouraging the communication and collaboration that actually works. And more than likely many of these testers will eventually graduate to development.

Use the coming scripting and unit testing capabilities to allow testers to define correctness. Essentially recruiting regression test writers.

Would KDE developers know what wasn't working without the Total: 9838 bugs and 9141 wishes that are now open? Absolutely. How many developers would rather make an appointment for a root canal than wade through bugzilla? There has to be a better way. Aaron is right. We wonks love deterministic solutions. This isn't a deterministic problem.