Testing descriptions for bug status and importance
Launchpad beta testers will now see the descriptions of bug status and importance when making updates to the bug page. Launchpad pickers can now show the descriptions of the options you can choose.
Launchpad’s rules for defining a list of options you can choose have always required descriptions, but the only places you could see them were in some forms where they were listed as radio buttons. Bug status and importance where never shown as radio buttons, so their description were only know to people who read Launchpad’s source code. Users need to see the descriptions so that there is a common understanding of terms that allows us to collaborate. The original bug importance descriptions were written in 2006 and only made sense for Ubuntu bugs. We revised the descriptions for the improved picker.
There has been a lot of confusion and disagreement about the meaning of bug statuses. Since users could not see the descriptions, we posted the definition on help.launchpad.net. Separating the status description from the status title did not end the confusion. We revised the descriptions for the improved picker, but I think we need to make more changes before showing this to everyone. The picker appears to rely on colour to separate the choice title from description. Not all choices will have a special colour, and in the case of bug status there are two choices that appear to be the same grey as the description text:
The picker enhancements were made for the disclosure feature. We are changing the presentation of bug and branch privacy to work with the forthcoming project sharing enhancements. Early testing revealed that users need to know who will be permitted to see the private information when the bug is changed. This issue was similar to the long standing problem with bug status and importance. We decided to create a new picker that solved the old problem, that we could then reuse to solve the new problem.
Tags: announcement, bugs, enhancement, front-page, ui
May 9th, 2012 at 6:02 pm
Looks great! However, I can see how with the given wording that someone might mistakenly mark a bug that simply has a patch attached that hasn’t been accepted yet as Fix Committed. Still, I think this would be a huge improvement and would clear up a lot of confusion among new Launchpad users.
May 9th, 2012 at 8:45 pm
Many of these descriptions could be shortened by removing the words “this bug”. For example:
– Has not yet been confirmed.
– Has been reviewed and confirmed by someone other than the reporter.
– Is being worked on by the person assigned.
– A fix has been merged into the code, but not yet included in a release.
And for “Incomplete”, it would be useful to clarify that it doesn’t have to be the reporter who provides the information:
– Can’t be worked on until someone experiencing the bug provides more information.
May 10th, 2012 at 1:42 pm
Thank you Matthew. I am putting your suggestions into a bug to track the issue.
May 17th, 2012 at 12:00 am
I like the idea of doing this for the statuses, with the text shortened as mpt suggests.
I think doing it for importance may lead to more time being wasted on debates about how important a bug is. Many people feel that particular bugs are important to them, and “should”, “must”, or “ought” to be fixed immediately. There are more such bugs than actually can or will be fixed immediately. I think you can reduce the chance of such arguments by just speaking about what actually will happen not what ought to happen.
I think suggesting that ‘wishlist’ might be a feature or enhancement is perpetuating a confusion about being an enhancement vs being a low priority. Features are not inherently unimportant.
If they simply form a scale plus “null” perhaps there’s no point using so many words to say so. Explaining the levels is more interesting if they have quantized behaviour: eg if critical bugs will block a release; or preempt other work; if there’s a cap on the number of High bugs; if paid developers will only work on >=High bugs. But that’s usually project specific.
You’re assuming work is ‘scheduled’ and for most projects it is not. It is just a work queue.