"Opinion" bug status causes user confusion

Bug #772954 reported by Martin Pool on 2011-04-29
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Launchpad itself
High
Unassigned

Bug Description

I believe that "Opinion" is meant to be a terminal bugstatus essentially equivalent to "Wontfix" but less blunt. <http://blog.launchpad.net/bug-tracking/new-bugs-status-opinion>

However the vagueness seems to be causing some users to put bugs into that status incorrectly; <https://bugs.launchpad.net/bzr/+bug/772127> is about the third example I have seen in the last couple of weeks. I think these users would not be marking their own bugs 'invalid' or 'wontfix' because the meaning of those states are clear.

examples: bug 275938

Robert Collins (lifeless) wrote :

I believe jml has plans in this area.

Changed in launchpad:
importance: Low → High
Phillip Susi (psusi) wrote :

I thought that the purpose of Opinion was to be a state somewhere between Invalid/Wontfix and triaged; where the bug no longer shows in the list of bugs for the package/project/etc so developers looking over the list of bugs to work on aren't distracted by it, but users searching for a bug by text would still find it and could add to it. This however, does not seem to be the case, so instead it seems to just be a confusing alias for Invalid.

Jonathan Lange (jml) on 2011-05-17
tags: added: opinion-status
Martin Pool (mbp) on 2011-09-12
description: updated
Matthew Paul Thomas (mpt) wrote :

As I understand it, "Opinion" was introduced for, and is used mostly by, the Unity project. So I just did a quick survey of about 30 "Opinion" bug reports, and discovered that even Unity developers are conflicted about what "Opinion" means. Some do use it, as Martin suggested, as an alias for "Won't Fix": see for example bug 700023, bug 706458, bug 708653, bug 870414, bug 962697, bug 962372, or bug 963449. But more often, in the sample I saw, developers -- sometimes even the same developers! -- use it as an alias for "Confirmed": see for example bug 611008, bug 636668, bug 651417, bug 683741, bug 695313, bug 701989, bug 703251, bug 741699, bug 829706, or bug 883917. (And as for people who aren't Unity developers, they interpret it in still other creative ways: see for example bug 781329, which uses it as a synonym for "Incomplete".)

As a result, in other cases -- such as bug 605110, bug 605112, bug 605118, bug 703536, bug 707943, bug 709017, bug 729693, bug 730128, bug 730154, or bug 962698 -- it is genuinely not possible, even after reading the comments, to tell whether the maintainers regard the bug report as describing something that should be fixed. So for example, it is not possible for a potential contributor to tell whether it would be a good use of their time to contribute a prototype or fix. This is counterproductive.

(It's possible that a Unity developer or product strategist will parachute into this bug report and explain what "Opinion" is *supposed* to mean. But that wouldn't even fix the problem for existing Unity developers, let alone for potential developers. And confusion is not the only problem with the status, it's just the most obvious one.)

Therefore, I conclude not only that "Opinion" is more confusing than useful, but also that when it is removed, reports that are currently "Opinion" can't just migrate to "Won't Fix", because that would hide many reports that the developers considered to be valid. Instead, they'll have to migrate to "New" so that project maintainers can re-evaluate them. The migration script could, however, add a tag of the form "project-id.opinion" when it does this, to make the reports easier to find and tackle in one go.

Robert Collins (lifeless) wrote :

So, its the case whenever we remove/rearrange any existing data that some users will have used it differently to other users.

Sometimes few or even no users will use it the way the system expects it to be used, other times more users will have used it the way the system expects vs some other way.

Opinion, as far as the system is concerned, is equivalent to invalid or wontfix. It does not show in searches by default, it does not show in aggregates.

We can choose when we migrate whether to a) fold Opinion into one of invalid or wontfix or b) reopen all the bugs that are 'Opinion' at the moment.
a) will be consistent with LP's current behaviour except that folk won't be able to find those bugs. We could tag those bugs (and probably would) to make them findable.
b) would be different to LP's current behaviour and force every user that has marked a bug Opinion to have to repeat that work (whether they want the bug hidden as invalid, or hidden as 'future work' - they would still need to take immediate action).

-> a) is less disruptive, and doesn't prevent any workflow if we tag the bugs.

Matthew Paul Thomas (mpt) wrote :

What is least disruptive is whatever requires least work afterwards.

Usually, this is indeed whatever most closely matches the system's current behavior. Because usually, the system's current behavior has strongly influenced the data that needs migrating.

This is a highly unusual case where that hasn't happened. Where I could tell their intent at all, people have more often treated "Opinion" as if it were an open status than a closed one, *despite* Launchpad treating it as a closed one. (This may not have been obvious because I omitted several examples for brevity.)

So it doesn't actually matter what "Opinion" is equivalent to as far as the system is concerned. It would matter if people had most often used it that way, but they haven't. If it was retired tomorrow, there would be less work afterwards -- both for bug reporters and for developers -- if it was migrated to an open status than a closed one.

Having said that, my sample was just from Unity bug reports. A fairer guide would come from sampling "Opinion" reports across all of Launchpad, not just Unity. And the balance might shift if some people switch to treating it as a closed status before it is abolished.

Robert Collins (lifeless) wrote :

I disagree with this assertion: "What is least disruptive is whatever requires least work afterwards."

That is certainly one of the factors. But another one is when the work is required. Is it more disruptive for a busy group of people to have to re-triage some N bugs tomorrow, or for them to only have to re-triage them when they wish to?

Moving bugs out of a closed state into an open state will change bug statistics and force immediate action vs preserving the current behaviour and permitting action when the users want to take it.

Matthew Paul Thomas (mpt) wrote :

This bug has metastasized: at least one engineering manager is now using "Opinion" to mean "the bug does need fixing, but this project is the wrong place to fix it". :-]

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers