Layout complains about tables and images. Things I know about automatically as dupes are: anything involving shortcut keys. I have thought before it might be fruitful to hunt after (or ask someone for a lead to) closely related bugs and sort through them to see if any are obvious dupes. It may be a self perpetuating cycle though, to where we learn the most-duped ones, then dup more bugs to them. In theory the better we get (collectively) at duping bugs, the more useful the lists of most-duped bugs will be. So I still think the main Most Frequently Reported Bugs page is more useful you can change its query to limit it by product, or view it as a regular (sortable) bug list. The product dashboard doesn’t let you limit by time though. The one I have been looking at a lot recently is the most duped list for Core::Layout bugs. There is not only a Most Frequently Reported Bugs list, there is also now a whole dashboard which can show most duped bugs by product. There is good advice in Screening duplicate bugs article on MDN. DUPing them is a good way to establish connections and direct the original bug reporter to where the action or discussion is. Some reports just sound like they must have been reported before. I catch a few, but more often someone more experienced notices the duplicates after I do something else with them, which sends bugmail or puts a report into a new product or component. Then I’ll pick a new little project!Īnd now a digression about duplicate bugs.Ī few bugs from FFUNtriaged end up being marked as duplicates.
Pretty soon we will have it down to something reasonable, like under 30, and actually recent bugs instead of cruft from a year ago. The FFUNtriaged bugs project has been fairly satisfying just to watch the number come down over time. Resolving it seems ok to me, since that doesn’t erase any history: the bug report is still findable if it comes up again. It doesn’t seem important enough to anyone to pin down exactly what fixed it. If I can’t tell what was going on, and the reporter doesn’t answer my “needinfo” query, I can resolve the bug INCOMPLETE since there was never enough information to tell if it was really a bug or not.Ī few of these long-untriaged Firefox bugs ended up in the RESOLVED WORKSFORME status, which I think of as: when the bug was reported, no one was able to reproduce it, I can’t reproduce it now, and maybe also the original reporter can’t reproduce it. I resolve them INVALID if they are reallky support questions because they aren’t and weren’t bugs in Firefox. Of the bugs that I end up closing, a bunch of them probably should have been support questions in the first place. The older, 2012 bugs are mostly obsolete at this point, but I have caught a few that are still valid, and that are now categorized in a product and component that brought them to the notice of the developers who may already be working on similar issues. I answer some from the front of the queue and some from the tail end, which right now goes back to February 2012. When I started putting half an hour to an hour a day into this, the count was well over 500 bugs. I have it on my todo list as “FFUntriaged”, so I think of it that way.
That is to bring down a specific number, the bugs filed for Firefox that are in the “Untriaged” component, where the last comment was by the person who reported the bug.
Lately I’ve been working on a fairly arbitrary goal. Many people in QA and various engineering teams also keep watch over the incoming bugs so that problems are caught quickly, escalated appropriately, and stuff gets fixed and released as soon as possible.īut the incoming are just one thing among many. I keep an eye on the incoming bugs, which are still around 350-550 for any 24 hour period and peck away at those. As some of you may know we have over 900,000 thousand bug reports in these days.
0 kommentar(er)
