On 02/02/2016 18:04, Anne van Kesteren wrote:
On Tue, Feb 2, 2016 at 6:50 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
But it gets worse. The typical lifetime of a bug goes like this. It gets
reported to somewhere like Firefox:Untriaged (I think we have a guided form
that automatically dumps things there or something?). Someone goes through
and triages it, moving it from there to some component. In a large fraction
of cases, it's the wrong component, because making sense of our components
is rocket science.
This we can improve though. And maybe reduce the number of components
in a couple of cases (I believe I managed to remove two around DOM at
some point, but I never made much of an effort). I forgot exactly
where to file the bugs, but if we think clearer descriptions and
better named components would help triage over the long term, perhaps
it's worth spending a day on.
Yes, we can improve it, but as someone who has also done a reasonable
amount of triage of Untriaged (and tried to get some improvements made
to our new bug flow) I don't know that we can eliminate the incredible
gap here.
Let's say that I am a user who's never seen bugzilla before, and I see
black boxes on some page, and I want to report that as a bug.
Where would that go? Graphics? DOM? ImageLib? Network? "Firefox ::
Theme" ? If the page is Facebook, should it go in "Firefox :: Social" ?
Those components are sensible distinctions for an engineer, but not for
someone with comparably little technical background who files a bug
about "Firefox not quite working right".
What's more, while with a bit of experience I can tell you that it's
likely a graphics bug (and could they try safe mode, does that fix it?
What does the 'graphics' section of about:support say? A while back, you
could ask if turning off OMTC helped, etc. etc.), in many cases bugs
aren't as clear-cut as this.
Today I helped triage something one of our employees was seeing in
rackspace's UI. Some part of the website was not displaying the right
text, but internal labels. No errors in the error console. Where does
that go?
Well, you don't really find out until you find the cause of the issue
(shoutout to mozregression!), which in this case seems to have been a
change in our JS parser (block functions) that triggered that page's JS
to be run differently, and now their localization scripts aren't working
correctly anymore. So you ping shu on the bug and ask if there's
anything we can do besides moving this to tech evangelism and contacting
rackspace to fix their site. I don't know - if we break 100 of these
websites, or if the bug is in a common library, maybe we need to back
out the change or turn it on for chrome only or whatever. But I have no
idea because I don't know the code in question.
Sorry, that was quite long. All I'm really saying is: as Boris' original
posts outlined, there are a lot of gaps between "someone files a bug"
and "we stop ourselves shipping brokenness on release". While some of
our components could certainly be clearer, I don't think that's enough
to close the gap between people filing bugs and engineers/relman who
have to decide if/how/when they're getting fixed.
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
