Automatic confirmation
You report a bug. Someone clicks “This affects me too” or marks the bug as a duplicate of another bug report.
Both of those are confirmation of your bug, right?
That’s what we think and members of the Ubuntu community agree.
So, from now on, that’s what’ll happen with New Ubuntu and Launchpad project bugs.
To recap: Launchpad will mark Confirmed any Ubuntu or Launchpad bug that has the New status and affects more than one person or is marked as a dupe.
Oh, but it doesn’t count if you mark your own bug as a dupe of another bug you reported.
We’re considering rolling this out for all projects in Launchpad. If your project uses Launchpad as its bug tracker, let us know what you think.
Photo by Seth Anderson. Licence: CC-BY-SA
July 21st, 2011 at 5:09 pm
I know for Bazaar we use New to make sure that all bugs are triaged, but I guess you can use the “unknown” status for that. I don’t think the UI makes it obvious to do that, vs driving the “New” count to 0.
July 21st, 2011 at 5:12 pm
I just checked. The count portlet does *not* show unknown importance count, but does show New count. If you take away New, it would be nice to have the quick reminder if whether you have any bugs that haven’t been triaged.
July 21st, 2011 at 5:49 pm
I beg to differ with your conclusion. Say a new Lp user without much knowledge filed a bug report that something is not behaving the same as in Windows, and another new Ubuntu user comes along anad says “me too!”. What I’m trying to say is, that this method will blindly confirm all bugs, I think if both the bug reporter and the “me too!” user can provide some meaningful info, only then should the bug be confirmed…
… or something…
July 21st, 2011 at 7:02 pm
In the Mahara project, we use the Triaged status to indicate that we have looked at a bug report and assigned a milestone / priority but that we haven’t tried reproducing it yet.
We then manually set it to Confirmed once the bug has been reproduced by developers or to Incomplete if we can’t reproduce it.
So we would need to change our workflow if bugs started to be automatically marked as Confirmed. (Suggestions welcome.)
July 21st, 2011 at 8:21 pm
Won’t this cause problems with generic bug reports like “my computer is slow”, which tend to accumulate lots of “me too” votes?
July 21st, 2011 at 11:29 pm
Actually won’t the bug report receiving the duplicate be the one that is changed to Confirmed?
July 22nd, 2011 at 9:07 am
Francois Marier’s Mahara example seems to be evidence for my long-standing hypothesis that “Triaged” is misleading and over-specific. The Launchpad developers who introduced “Triaged” imagined bug reports going from New to Confirmed to Triaged, but Francois describes them going from New to Triaged to Confirmed. Ideally, people could tell which bug reports have not yet been assigned a milestone/priority by actually filtering on Milestone and Importance — not by using a separate status that can easily get out of sync. http://launchpad.net/bugs/70709
TT and Ryan have an interesting point about what “Confirmed” means. In many (though not all) cases, it is a waste of engineer time for a bug report to be Confirmed without containing reliable steps to reproduce the problem. Auto-confirming based on “affects me too”, or duplicates, makes it more likely that a report will be Confirmed without containing those steps.
Another way to look at this: How can a defect analyst tell what is the best use of their time? One heuristic is to work on the oldest “New” bug reports, because reducing the average response time makes reporters happier. But another heuristic is to work on the “New” reports that most people have marked as affecting them, because that will help engineers work first on problems that affect more people. In that way, auto-confirming bug reports would be precisely counterproductive. Because a bug report that has been Confirmed will be *less* likely to be ready, for an engineer to work on, if it affects multiple people than if it affects one person!
July 22nd, 2011 at 11:56 am
@Brian: yes.
July 22nd, 2011 at 2:18 pm
“Another way to look at this: How can a defect analyst tell what is the best use of their time? One heuristic is to work on the oldest “New” bug reports, because reducing the average response time makes reporters happier. But another heuristic is to work on the “New” reports that most people have marked as affecting them, because that will help engineers work first on problems that affect more people. In that way, auto-confirming bug reports would be precisely counterproductive. Because a bug report that has been Confirmed will be *less* likely to be ready, for an engineer to work on, if it affects multiple people than if it affects one person!”
My thoughts precisely. As a defect analyst I do care about how long a bug stays New, so I can have an indicator of how triage is going, and I also prioritize which bugs should be first investigated (so then marked Confirmed if the case) according to how many people are affected and how long the bug is in the New state. We could check the bugs’ age, but I believe this adds more complexity to the process for something that wouldn’t pay. At least I can’t see how right now, maybe someone else could enlighten me. 🙂
July 22nd, 2011 at 9:38 pm
@Brian Murray
The duplicate bug also gets confirmed. (For example, see https://launchpad.net/bugs/730581.)
My question is: What happens if new bug Y is mistakenly marked as a duplicate of new bug X, and then un-marked as a duplicate when it’s determined to be a mistake? Do the bugs’ statuses revert back to New? If so, then what happens if, after Y was marked a duplicate of X, a user affected by Y had indicated they were affected by X (but this was based on incorrectly being told they were the same bug). Does that keep X in a Confirmed state after Y is no longer a duplicate?
Also: What if Invalid bug Y is marked as a duplicate of New bug X — does that confirm X? If not, what if anything happens if Y’s status is changed from Invalid to New or Confirmed after it becomes a duplicate of X? What if (in either of those two situations) Y is Incomplete rather than Invalid? What if it’s Expired? And are bugs that are automatically confirmed due to being affected by two users or having a duplicate by another user automatically de-confirmed if there is no other action confirming the bug and those two user accounts are subsequently merged (indicating that they belong to the same person)?
August 6th, 2011 at 2:48 am
I think the best way to implement automatic confirmation is to have it as an option in the ui for those projects that want it, but keep it disabled by default for the projects that do not. Also, custom workflows should be investigated further.
September 4th, 2011 at 1:19 pm
A bit over a month later, this is just starting to get irritating. People are reporting things that they reasonably think are suboptimal with the design of Ubuntu Software Center, in the form of bug reports. That’s fine, that’s the best place for them. But then Launchpad is automatically marking them “Confirmed” merely because someone clicked “Yes, it affects me”, when we haven’t decided whether changing the design is a good idea. That would be okay if it was obvious that “Confirmed” did *not* mean “ready for an engineer to work on”, but most engineers reasonably assume that it does mean that.
So now not only does Ubuntu have 29000 bug reports marked “New” that are in reality over a year old, 3000 marked “Incomplete” where the reporter has answered (or tried to answer) the questions asked, and 663 marked “Triaged” that haven’t been triaged — it now also has an unknown number of bug reports marked “Confirmed” that no-one has confirmed. It might now be easier to understand Launchpad’s bug statuses if you don’t know English at all, so that you’re not confused by the plain meaning of those words.