The 2nd bug triage began with 285 bugs, which grow to around 310 bugs, since during the 4 months of the triage more bugs were reported.
So, I’m glad to announce the beginning of (my) 2nd openoffice.org bug triage. This triage targets 285 bugs out of 330 open oo.org bugs. The selected bug are ones which were reported against versions lower the 2.3.1 or have no version information at all.
At first, the triage advanced quickly with 21% of the bugs processed during the first 24 hours and 40% during the first 10 days. This left a long trail of bugs to handle manually.
The triage began for version 2.3.1, but was delayed to let version 2.4.0 to propagate into Lenny, as that was Rene’s preferable version to release with. When the triage resumed in late April, I had a 2.4.0 available in all of our repositories (sid, testing and backprots). Which meant that everyone could verify their bugs against the same oo.org version. Bug triaging heaven (:
Two thirds (66%) of the bugs were closed in this triage, most of them after a check from the submitter or myself and a few after the submitter was unresponsive and I couldn’t verify the bug myself.
Verifying the bugs myself is the most demanding part of the triage. Reading each report and understanding the problem takes a lot of time. Reproducing the problem usually takes less time than understand it. That’s way have test cases attached to bug reports are so important.
In several cases the instructions were so simple I could just open the file, check something and verify the bug. That was done in a robotic manner or in a monkey like one. These kind of attachments enables a lot of people to help with triaging, even if the lake the technical background of the program in subject.
So after closing 200 bugs and verifying around 100+, the oo.org bug count is set to 140 outstanding bugs, and 70 bug being forwarded to upstream. Except from about 10 bugs, all of the remaining 130 bugs are relevant for version 2.4.0. No need to wonder if the bug still occurs before reading the report…