On the importance of being a bug confirmer

The truth is rarely pure and never simple.

— Oscar Wilde, The Importance of Being Earnest

Two important things happened in LibreOffice QA this week. The first one has not gone unnoticed by a lot of users: Florian Reisinger closed a lot of old and idle bugs (no activity for more than six month) in state NEEDINFO on our friendly bugzilla. As you can see from this table we have bugs in all kinds of states:

• the “user/reporter states”: NEEDINFO, UNCONFIRMED
• the “bugwrangler states”: NEW, REOPENED
• the “developer states”: ASSIGNED, RESOLVED/WORKSFORME
• the “verifier state”: RESOLVED/FIXED
• the “janitor states”: VERIFIED, CLOSED, RESOLVED with resolutions INVALID, DUPLICATE, WONTFIX, NOTABUG, NOTOURBUG

The lifecycle of a bug ideally makes the bug go through the states UNCONFIRMED -> NEW -> ASSIGNED -> RESOLVED/FIXED -> VERIFIED -> CLOSED quickly. If it gets stuck somewhere, its up to the group named in the quotes to help this move on: For a bug in state NEEDINFO, it is expected from the user/reporter to come up with missing information. For a bug in state UNCONFIRMED, it is needed for somebody (best not the reporter, but a different user) to make sure that the bug is valid. This is not too hard, the details are described on the Bug Triage page on the wiki. LibreOffice is a community project and the best way to get your issues forward is to trade favours: Confirm the bugs of somebody else and let him confirm yours (of course, you should still check if the bugs of the other guy/gal are really valid!).

The bugwranglers then take care to make developers aware of the most important bugs in states NEW, REOPENED according to development capacities. If a bug sticks longer in here, it is usually not the bugwranglers to blame, but the fact that there are just more critical bugs to pipe to the developers at this point in time. However bugwranglers also need to make sure that a bug has all the important information on the bug before it gets to development. For example, when it is a regression: what was the first version that misbehaved, stacktraces, test case, test documents. If there are multiple bugs which are about the same severity to choose from to hint development at and one has all that information while others do not — QA will tend to go with the ones with most information on them.

The job of the bugwranglers is to find those bugs that stick out (Photo: Jessica Lucia, Creative Commons license)

The developers then crunch their heads on trying to solve these issues. And if they need a break and some cheering up, they will look at a WORKSFORME bug that seems to have been fixed to QA/users, but nobody claimed to have done that intentionally. If they can see that the bug was indeed solved, the bug can move to CLOSED/FIXED.  The latter is not a high priority task at all though.

If a bug is set to RESOLVED/FIXED by a developer, the fix can be verified by pretty much anyone on a daily build: while the developers are usually trustworthy folks, it does not hurt to check. A very good side effect of this is, once the daily build is installed, one can easily torture it a bit and see if the trustworthy folks of the last sentence recently broke something in a horrible way: If so they should get notice ASAP via a new bug report.

The janitor states are mostly dead: We then consider that bug finished. Now some bugs were reported more than a year ago, when the freedesktop bugzilla did not yet have a UNCONFIRMED default state — those were moved from NEW to NEEDINFO as they still needed confirmation. If no other user confirmed your bug since then and there was no activity on the bug for more than half a year, the bug would now have been moved to RESOLVED/INVALID with Florians cleanup. In such cases, find somebody to confirm that what you describe is indeed a bug and ask him to reopen that bug for you. Note you dont need to wear a QA uniform, QA hat and badges to do so, although you might earn them by doing Good Work(tm). The QA team is looking for more hands and you can best find us on the QA mailing list or on IRC and other means. Another good way to get started are the QA EasyHacks.

Oh, the second important thing happening in QA this week? Its still work in progress and this post was long enough, so I will do a post on its own about it. The buzzword will be: LibreOffice HardHacks.