Ubuntu

Bug #1 (liberation)
Comment #685

Comment 685 for bug 1

Revision history for this message

Nick_Hill (nick-nickhill) wrote on 2008-06-05:

#685

From discussing on IRC and between friends, it seems uncontroversial to suggest 8.04 has more bugs than we'd like. Far more than we'd like for an LTS. Many of them being regressions. Not to mention beta Firefox.

At the same time, there are perhaps millions using Ubuntu, and I often have opportunities to be the first bug reporter (sometimes for show stoppers), despite being busy, and not focusing on finding Ubuntu bugs.

10 friends are Ubuntu users. None file bugs unless shepherded by me, where I give them real-time directions on how to actually report bugs in Ubuntu.

I therefore propose a thought experiment; take 10 average half-computer-literate people who have encountered Ubuntu before, so already have a rough idea of how to launch an application, and know where to find the administration menu.

Point out to each in turn something which is clearly not functioning the way it should. Very few of them, unless previously primed will ask out loud, or ask themselves "How do we tell Ubuntu about this?". Therefore, users of Ubuntu must be primed to report bugs. This should be a clear part of the Ubuntu design; prime users to report bugs!

Stage two of the thought experiment: Ask each user in turn to inform Ubuntu about the bug. Maybe 10-30% will have found Launchpad before giving up. Probably from typing "Ubuntu bug" in google. 70-90% of these previously primed people will likely have completely lost their way before getting to the BTS.

For stage three, we need to imagine the original sample size was much larger. So we'll talk in terms of percentages. Of this 10% left, who found their way to Launchpad, who have already been primed from personal contact, many are likely to get lost in Launchpad, finding their way out of the Ubuntu page, searching projects on Launchpad, rather than searching bugs in Ubuntu. We are probably down to 3-5% of primed people by now even having successfully performed a search for their bug on Launchpad.

Stage 4. Of that 3-5%, if the bug has not already been filed, I estimate perhaps 0.5-1% will actually report a bug, and not be put off by 1) not being able to identify with a good degree of confidence, which package the bug is supposed to be filed against and 2) Having to register / have a valid email address etc.

I therefore suggest that with the current BTS arrangement, maybe half to one percent of 'ordinary computer users' personally primed, will successfully file any bug. If not primed, perhaps one in 1000 or 1 in 5,000. The number of bugs considered of good quality and as a basis of a fix will be much smaller still.

I would welcome a debate on how to make the Ubuntu bug tracking user interface, right away along the line from detecting a bug to triage, inclusive to 'ordinary computer users'.

I'll kick off by suggesting:
1) When a user account is created, by default, beg users to file bugs, and point them to the BTS
2) The Ubuntu bug tracking system should have only Ubuntu, Kubuntu, Edubuntu or other siblings which share the same packages - there should be no way for users to get lost in other projects on the same bug tracking system.
3) The root of the Ubuntu bug tracking system should actually be at an easy to remember URL such as http://bugs.ubuntu.com/ . (This URL does currently re-direct to https://launchpad.net/ubuntu/+bugs).
4) The hardest part - make it much easier for users to identify which package the bug is related to. I am an experienced user and find this step challenging. Maybe a clear decision tree, with unambiguous, easy questions, or some graphical system.
5) When a bug is marked as a duplicate, the title of the bug should remain searchable (at least for months) as a 'common user' may identify a bug using different words to those used by the developer.

10 friends are Ubuntu users. None file bugs unless shepherded by me, where I give them real-time directions on how to actually report bugs in Ubuntu.

Point out to each in turn something which is clearly not functioning the way it should. Very few of them, unless previously primed will ask out loud, or ask themselves "How do we tell Ubuntu about this?".  Therefore, users of Ubuntu must be primed to report bugs. This should be a clear part of the Ubuntu design; prime users to report bugs!

For stage three, we need to imagine the original sample size was much larger. So we'll talk in terms of percentages. Of this 10% left, who found their way  to Launchpad, who have already been primed from personal contact, many are likely to get lost in Launchpad, finding their way out of the Ubuntu page, searching projects on Launchpad, rather than searching bugs in Ubuntu. We are probably down to 3-5% of primed people by now even having successfully performed a search for their bug on Launchpad.

Stage 4. Of that 3-5%, if the bug has not already been filed, I estimate perhaps 0.5-1% will actually report a bug, and not be put off by  1) not being able to identify with a good degree of confidence, which package the bug is supposed to be filed against and 2) Having to register / have a valid email address etc.

I would welcome a debate on how to make the Ubuntu bug tracking user interface, right away along the line from detecting a bug to triage, inclusive to 'ordinary computer users'.

I'll kick off by suggesting:
1) When a user account is created, by default, beg users to file bugs, and point them to the BTS
2) The Ubuntu bug tracking system should have only Ubuntu, Kubuntu, Edubuntu or other siblings which share the same packages - there should be no way for users to get lost in other projects on the same bug tracking system. 
3) The root of the Ubuntu bug tracking system should actually be at an easy to remember URL such as http://bugs.ubuntu.com/ . (This URL does currently re-direct to https://launchpad.net/ubuntu/+bugs).
4) The hardest part - make it much easier for users to identify which package the bug is related to. I am an experienced user and find this step challenging. Maybe a clear decision tree, with unambiguous, easy questions, or some graphical system.
5) When a bug is marked as a duplicate, the title of the bug should remain searchable (at least for months) as a 'common user' may identify a bug using different words to those used by the developer.