Some Clarification and Musings
As many of you know, I have officially ended my contributions to Mozilla for the time being. Since I published that post, I have been asked by several people why I left, and ways that I think Mozilla could change to be more friendly to Triage. So, I thought I would give a blog post to try to explain a few things, and just maybe spark a bit of discussion on Why triage needs to be improved.
Update: Please read this post in conjunction with this one.
Non Reasons:
First off, I did not leave because of rapid release. I love the idea of rapid release, and I think the recent spurt of posts to the planet on how Rapid Release will be beneficial in the long run does a great job of explaining it. Rapid Release is going to be awesome if done properly. I have always been so frustrated by the continual late releases that hold back awesome new features from the web. I think Rapid Release should have been planned out better before it was put into effect (figuring out a plan for the Enterprise, making the update process smoother BEFORE jumping into it, could have been explained better). But I think that excellent progress is being made on all these fronts, and hopefully by the end of the year, many of the quirks of the system will be ironed out. I wish it had been done earlier, but that is neither here nor there.
Nor did I leave because of a recent conversation concerning the removal of version numbers, at least it was not the main reason I left. I feel that the whole conversation could have been handled much better on both sides of the board (For those who were calling for murders over a SOFTWARE change, you seriously need to get a life. Put down the computer, go camping for a weekend, then come back when you can act reasonably. Even though I firmly believe in Mozilla’s mission, software is not that important to be threatening people’s lives, and frankly, acting like a spoiled 2-year old.) But, it was not the determining factor in my decision. It would be silly to leave a project that I have contributed to for 3+ years over a misunderstanding.
Why I Left
I left because of a general lack of interest in doing anything substantial to improve the Triage process on BMO outside the QA community and a few others. Triage as we know it today is NOT ready to handle the Rapid Release process. While Releng, Devs, QA, SUMO, etc. have been able to transition to the new process relatively smoothly, Triage was caught off guard. And not through a lack of trying. I have pushed for change, and I know others have as well. Change has been made. But it is not enough. I understand that change takes time, and there is always a delay between planning a change, and the implementation. But with Triage, time is our enemy. We currently have 2598 UNCO bugs in Firefox that haven’t been touched in 150 days. That is almost 2600 bugs that have not been touched since Firefox 4 was released. And how many more bugs have been touched, but not really triaged or worked on? Every day this number grows. 27 UNCO bugs have been filed in Firefox alone in the last 24 hours, and that over a weekend.
Triage is Broken. Period.
With the old model of releasing a new major version once a year, triage had a bit more time to go through a massive pile of bugs, to find regressions and issues, and there was a pretty good chance that most bugs would get caught, just because we had time on our side, and we could afford to miss a bug for 6 weeks, because we would most likely get around to it. Or so went the theory. Even this process failed us.
Organization, Community, Politeness and Professionalism
In Spring 2010, we hit roughly 13,000 UNCO bugs in the Firefox product on BMO. 13,000!!! We currently have 5934. While this is an improvement, that is 6000 bugs in Firefox that could be shipping today, and enhancements that could be making the web better (of course it isn’t that high, but the potential is there). This is several thousand contributors that we have told “Thank you for filing a bug report with us. We don’t really care about it, and we are going to let it sit for 6 months and just ask you to retest when you know it isn’t fixed, but thank you anyway. Oh, and Mozilla is run by the community.” Even though nobody means this, that is what we tell an end-user who just submitted their first bug and is ignored. We can’t do this. We just can’t. Now, I realize that it is impossible to touch every bug immediately, but, to those who have gone the extra mile to create a BMO account, file out the bug report form, and navigate BMO emails just to report something they feel is important, don’t we owe at least a little common courtesy?
Perhaps, if a bug isn’t replied to immediately, an automated email could be sent to say “hey, we haven’t forgotten you, we appreciate the bug report. All the Triagers are busy, but here are some steps you can take to test if this bug goes away:” or something along those lines. Building a friendly relationship with our community not only gives them confidence that their report will be taken care of, but it also helps them want to come back.
We also need more coordination as a community so we can touch all these bugs in an effective and professional manner. Having better tools for the Triage community to find bugs that haven’t been replied to within a certain time period. Having better communication between developers and triagers, and between triagers themselves. I want a developer to be comfortable asking the triage group “I have this list of 200 bugs I would like triaged in this way. Thanks”, and it to be done, without a bug day. And I want there to be developers who when they are pinged on a bug by a triager, to reply and assist with the process as needed. Along these lines, THIS IS AWESOME! More of this, lots lots lots more please! I also want the triage group to have an easy way to be able to say “Hey, I noticed that Bug XXXXXX seems to have lots of dupes, let’s keep an eye on it.” Or “I think it is about time that we go through and clean up some old bugs.” With multiple eyes looking at the same list, we can help keep bug numbers down.
I realize that triagers are volunteers, and thus may not be held to the same standards as a Mozilla employee. But I see no reason that they shouldn’t be. As a Triager, I have unique opportunity. I get to be the person that most people will associate with Mozilla, at least at first. This is incredible, and terrifying. Everything I do, and how I treat people’s bugs, is going to influence their perception of Mozilla for a long time. Giving one sentence replies, being rude and thinned skinned gets you nowhere. I have learned this the hard way many times. We need to have a set guideline of how to treat specific bugs, and how to treat their reporters, and somehow ensure that Triagers are following these guidelines. While there are spammers, and people who are just trying to cause problems, the vast majority of BMO bug creators are just trying to make the software they use a little bit better.
We need the Right Tool
Even if we create all the best tools in the world, if we are disorganized, it isn’t going to do any good. We might have 5000 UNCO bugs instead of 6000, but that isn’t an improvement. On the other hand, we can be organized, but if we don’t have good tools, we are going to be trying to cut down a tree with a pocket knife.
Right now, there is no real way to triage except “Here is a list of 1700 bugs. Start at the top and work your way down.” We need a way to mark bugs that need triage (Like Getting Bugs Done and Triage Flags). But we also need to remember, BMO is being used for things it never was created for. BMO is either an end-user bug submission forum, or a developer bug submission database. It can’t be both, but that is what it is trying to do. It worked when it was small, it kinda worked when we took a year or two to release a new versions, it doesn’t work with Rapid Release.
This is why I have envisioned a separate BMO product of UNCO bugs. That way, we can separate End-user bug submission from the development process, at least in the beginning stage. We can make a simplified interface for those who are just starting out with Mozilla. We can add flags to bugs, that while useless for developers, are incredibly useful for Triagers. We can have a different set of rules for the UNCO product than we do for the Developers. While there is no perfect answer, while we can never make everyone happy, we can do what is better for the community as a whole.
I also strongly feel that Mozilla needs at least 1-3 people to just handle Triage on an Official Full-Time capacity. Pretty much all the community Triagers I know have jobs, families, lives outside of Mozilla. Mozilla is just one of their hobbies. While they are passionate about what they do, they don’t have the time it takes to full-time triage. And with Rapid Release, this is what we need. Plus, a Mozilla Employee has a lot more weight at getting changes done, organizing and revitalizing the community, and helping continually improve Triage.
Conclusion
I know this was a long and rambling blog post, and I covered a lot of things with little cohesion. I felt it was important to get my thoughts out in one final attempt to maybe get some traction going on fixing Triage for the good of Mozilla. Without long-term changes, I feel that triage is going to be facing a larger and larger pile of bugs that doesn’t go down, and eventually may just go away out of frustration. And this has nothing to do with the community. When I see what triagers have to go through to do a good job, and they still stick with it, I know that if Triage goes away, it won’t be the fault of the community. It is the only thing keeping it together in fact. I hope to see some sort of improvement in Triage, and when I do, I will jump right back in. But as it is, I see no use in contributing to a project that seems to have gained little attention from Mozilla. No, there is no glamor in Triage. But neither is there any glamor in 20,000 UNCO bugs.
I am not looking for zero bugs, I am not even looking for less than a thousand. I am looking for timely responses to all or nearly all bugs reported, and better tools and organization in the triage community.
I should also say, for the past two weeks I have been in discussions with several Mozilla Employees and Contributors on how Triage can be improved. I simply wanted to be fair to those in the community that were not aware of all my concerns with Triage, and perhaps to get more feedback. So, this is my in-depth explanation of last week’s post.
(These are my personal opinions, and are not meant in any way to attack Mozilla or any Employee of Mozilla or Contributor. It is simply my frustrations, and personal opinions of what can be done to improve triage. I am not saying my ideas are perfect, but I want them more to serve as a catalyst of HOW to improve triage for the long-term. Please, feel free to contact me for further discussions.)
The life and adventures of Tyler 
I also strongly feel that Mozilla needs at least 1-3 people to just handle Triage on an Official Full-Time capacity.
What about Josh “timeless” Soref? He may already be doing alone a task fit for three people, in which case, please pardon my cluessness: I don’t even know if he is a volunteer or an employee, but I have noticed (and been astounded by) the fact that he gets bugmail on every single bug AFAICT, and the few times that he commented on bugs which I had reported or triaged, what he said was never to be dismissed out of hand, and almost always contributed to solving the problem at hand.
Yes, there are lots of community members that do ALOT of work for their respective fields in Mozilla. I’m not sure about Timeless (I know I haven’t seen him around much lately, https://bugzilla.mozilla.org/page.cgi?id=user_activity.html&action=run&who=timeless%40bemail.org&from=2011-06-01&to=2011-08-27). But I do know that he works very hard at everything he does. But that doesn’t take away the fact that there needs to be more manpower (it can’t fix everything, but it helps), because we can’t clone timeless, unfortunately.
First, sad to see you go.
Second, I haven’t been offered a job at Mozilla and recently started a job at RIM. As such, I don’t have time to help out (I need to make my new employer happy). This is also why I’m not filing bugs — I don’t want to be accused of doing too much for other groups on company time (and I’m going to try to start a real life here in Toronto).
Third, I generally agree with Tyler, we need a way to split `developer work items` from `end user reports`. I’ve talked about this to people informally, and drafted a general proposal:
http://timeless.justdave.net/blog/77/
http://timeless.justdave.net/blog/78/
— But I never actively pushed for it, and I’m not even sure who would need to be poked in order to make it work.
Fourth, I definitely agree with Tyler that one paid person isn’t sufficient (three does sound like a good start).
Twice in three months? Hm, that’s less than I would have expected. I can only offer two explanations: (a) maybe he’s on holiday (does he have a family?), and (b) ISTR that he has other bugzilla-addresses-of-record… I think I remember one out the top o’ my head… @myrealbox.com, no luck… @gmail.com, no luck… Sorry, no pay dirt. Let’s hope we hear from him again, because there are too few people like that.
I’m doing triage for several years and my motivation changed over the time.
In the beginning i thought that we should try to manage every incoming bug report but i realized later that this isn’t possible. It’s not possible because mozilla is a huge project with millions of users and the target to get all UNCO Firefox bug reports to zero will never happen.
An example:
a reporter gets a firefox freeze every day because his RAM is broken or the CPU gets too hot or the system contains malware that injects itself into the firefox process.
Another example is some stupid third party tool that modifies our sqlite files to delete some cookies and it does it wrong.
In many of those cases you will never find the reason for the reported problems.
The whole job of bugzilla is to manage “real” bugs for our developers and the main job as triager is to identify real bugs in all that “junk” reports and try to gather the information that our developers need.
I move the bugs out oi the junk product “Firefox” to Core/toolkit if I have the feeling that this is a real bug and I often get attention from a developer that watch those components (thanks Boris !).
I’m not the best person for that job because of my limited knowledge of html/JS , c/c++ and the english language (sorry timeless who had to read all my mistakes) but I do my best. Sometimes i think that “my best” isn’t good enough and i get frustrated but the other day I get a good feeling when I helped to identify a bug and that bug gets fixed by a developer.
Yes, I do a lot of support in bugzilla but bugzilla isn’t intended for that.
I do that if I’m not sure if it’s a real bug or only something that the safemode/new profile thing fixes. In that case I make a user happier with providing a solution for his problem. You did the same, make reporters happier with providing feedback/solutions but I’m sure that this leads to a burn-out. That the reason why i adore the SUMO guys, i couldn’t or doesn’t want to do the job.
I thought already in whistler that I should discuss with you about the benefits of trying to bring the product FF to zarro but I didn’t do that – my spoken english sucks even more than my written english and I hate me now for not doing it.
Yes, I agree, we wil never be able to have zero UNCO bugs, we will probably never even be able to have UNCO bugs in the hundreds. However, 13,000 and even 6,000 is simply too high. I think that 1,000-1,500 is something workable, if it goes over that, we are probably doing something wrong.
What is more important to me is how fast it takes us to respond to an UNCO bug, not how many we have. The time response would be an interesting metric to research and try to improve.
Exactly. Thus why I think having a separate product to do triage in would be helpful. We will be able to leave the junk bugs in that product, and developers would know that any bugs moved out of that product are “real” bugs.
I love that feeling 🙂
This is something that Bug 444302 would help with. We would be able to still help reporters, and make them happy, but be able to move them over to SUMO where they actually should be at, without causing alot of heart ache. I’m not against providing support on BMO, I do it all the time, but, again, the main focus is on triage.
I actually think your written English is very good, and your spoken English was quite understandable. I wish we had more time to talk last year as well, and I think that Triage is so broad and there are so many areas to discuss, we could have talked for hours.
Timeless took a new job at RIM and hasn’t been deeply involved in Mozilla stuff since.
Ah, that explains a few things then.
Which actually reinforces my point of why Mozilla needs an official Triager. There may be a community member with the time it takes to handle Triage, but if their life changes, nothing is tying them to Mozilla, and so they will be forced to just leave without a successor.
I just want to say thanks for this blog post. Thoughtful criticism is a valuable contribution too, and I hope this will be heard and understood by the right people.
It is; we’re working on fixing this with Tyler’s help actually.
I also agree that BMO needs a little less rudeness when dealing with some people, especially if they do go through all the trouble to figure out how to use Bugzilla just to report something. They want to help – we shouldn’t be denying them.
Tyler!
Thank you for this blogpost! I absolutely share your opinion about the current ineffectiveness of BMO. Actually, I’d like to pour some gas on the fire.
I have no coding skills, but I use Nightly, I catch the bugs and I do file them. I do it carefully, providing all the needed information.
I don’t like the way my bugs are treated: in most cases they stay out of anyone’s attention and stay UNCO for years, but that’s not the worst part. I understand that Mozilla has not enough people to cover all the bugs in bugzilla, that’s a thing we can nothing to do with.
Most of all I hate 2 things in how mozdevs work.
1. There is absolutely no respect to the elders. And I don’t mean people, ha-ha. I mean bugs.
I sooo hate that no one at mozilla gives a shit about 12 years old bugs, like this one: https://bugzilla.mozilla.org/show_bug.cgi?id=18808. They prefer to forge and fix new bugs, when the old bugs are still damn alive. The time passes, but these bugs don’t become less important for users, but for some reason they become less prioritized to the mozdevs. THIS NEEDS TO BE CHANGED.
2. There is absolutely no dialogue between users and mozilla. No, seriously. Once I’ve said that on irc forums at #developers and I got a squall of criticism that there are plenty of all those half useful projects like “today firefox made me sad/happy because…”. That’s not a dialogue, those messages don’t get any replies, no one answers you if you write there. Your problem will stay unsolved and ignored, this project is just made to gather statistics about the percent of dissatisfied users. In BMO you at least may sometimes get a bit of attention and even may get answered. But in most cases it’s still not a dialogue, in best case it’s interrogation, when you get questioned something about the bug specifics. But, as there is no other place to contact the developers then on BMO (don’t even say a word about “newsgroups” which are full of spam and where there is still no dialogue [my comment is ignored, like always]), most of interaction between users and mozdevs (or with triagers, who yes, still do associate with the whole mozilla in my mind, and that’s a correct association, btw) happens there. And the worst part is how you get treated. I know that Mozilla is a non-profit organization, I know that most of contributors are volunteers, but I love Firefox so much, that I just can’t stay uninvolved! And yes, I want some attention. There is a spy inside of Mozilla, named Asa Dotzler, whom I talked to on irc forums and I just fled in horror after our conversation, as from his words I understood that he’s going to remove a lot of functions (like it is already done to some of them), just because he “likes to simplify the user’s interaction with the browser” and there is no way to affect the situation, to change his decision, but he’s a real demolisher (he’ll destroy much, mark my words). Users have no voice. On BMO my accounts were banned 10+ times, when I got angry after hearing the phrase from some mozdev (or was it beltznebuth?) that “VOTES MEAN NOTHING”. At that time I was stunned and shocked by that fact that came out from the mozdev’s mouth! I am not proud for how I reacted, but actually there obviously WAS a reason for it.
There are plenty of points where users are against some decision to change/remove something, and the bug in BMO gets helluva ton of praises to not remove the lovely feature (remember the comment wars inside the bugs of RSS indicator removal and statusbar degradation to the toolbar without page load state and hovered links’ URLs) and it still gets removed and won’t be backed out.
There are plenty of examples for such micro-wars between users and mozdevs (my bug was closed 3 times (and 3 times I reopened it) until Dietrich Ayala in newsgroup changed the mozilla’s position about the need of the change I proposed), that’s not good at all.
There should be some kind of official dialogue between users and mozilla developers with voting system, blackjack and hookers.
Mozilla has to learn to LISTEN to the voice of users. But now it remains deaf.
Sorry for all my welter, mistakes and emotions, but I just can’t stay silent anymore.
Well, I think that there is alot of confusion about exactly WHAT BMO is, and the proper behavior on it. Again, by having a more simplified section of BMO designated for end-user bugs as a staging area, we may be able to alleviate some of that pain. And unfortunately, votes do mean nothing with the current BMO. BMO isn’t designed to be used by end-users, so there is alot of confusion that stems from “why does this mean X, but is used as Y?”
Some bugs may stay UNCO for a long time but what does that mean ?
It often means that this is an edge case that nobody else reported or it gets fixed in another bug that got more attention.
A very old bug report means that the bug is either very difficult to fix or it costs too much time to fix a minor thing. Complaining in those bugs is the wrong way, attaching a patch and get reviews is the right one.
For the other part:
BMO isn’t there to discuss things like the release cycle or UI decision.
Those bugs are often spammed by multiple people and those spam comments are unwanted and doesn’t belong into bugzilla.
BMO is only there to help our developers, it’s no support or feedback forum and finally there is https://bugzilla.mozilla.org/page.cgi?id=etiquette.html (point 1.2 and 2.2)
> A very old bug report means that the bug is either very difficult to fix
There is already an extension that fixes the bug. I pointed at it and no one cares.
> or it costs too much time to fix a minor thing
the bug is alive for 12 years, there are TENS of duplicates and tens of votes and tons of whining users, who ask for a fix. Such a wanted-by-everyone bug can’t be minor at all.
Sorry, but you come across as a whiny pain in the ass. You fail to grasp your insignificance in the larger scheme of things. Firefox has ~300 million users. When developers aren’t “scratching their own itches” and are figuring out what will most benefit those millions, they need to look past b.m.o comments/votes/ranting and newsgroups which represents a tiny fraction of the userbase. Don’t like it? Then learn to code instead/as well as being a vocal jerk about the state of things.
(I’m also a long-term user and bug filer, but without your irritating sense of entitlement.)
Yes, mozdevs are as deaf as you are. I’m talking about tens of people who want the same bug to get fixed for years and you are talking like I’m alone and insignificant. No I’m not alone, and if there are ~300 million of users it does actually mean that there are thousands of people who want the same bug to get fixed, they just don’t get involved into the development process.
So it’s not me, who’s insignificant. It’s the system where no one cares about what users actually want and where devs fix the bugs they personally are interested in fixing.
Drugoy, if you used this same attitude on bugs, then I can understand why you got banned. Attacking “mozdevs”, cursing and shouting are not what gets things done on BMO. It is not like Youtube comments. There is a difference between professional conversations, and having to listen to shouting people. There are things that are broken, but insults are never the way to get things fixed.
This skirmish is exactly why I won’t be involved with Firefox, Mozilla or any other open sore (sic) production: Here’s a place to vent, a user vents, and is dumped on. Have you checked his submissions? Are they whiney? No? Hmm.
Tyler, when the problem of how to treat volunteers is resolved, you could look forward to more help from the middle of the road crowd. until then, those of us with more sense than time will stay the heck away.
Mozilla aggressively entitle users, as it did you. That is what drives mozilla. No one can knock someone down because they feel a sense of entitlement. Then when they get angry, you criticize their manners? What a sure way to piss someone off.
Drugoy may be “whiny” and “unprofessional”, but Skierpage is hateful. If mozilla can’t recognize how detrimental such an attitude is, there is no hope. It is shocking.
A solution would be to take every one of these conflicts as examples, and to design a system that doesn’t require people to get along for bugs to get fixed. Take the issue away from values. Move it to bugs getting fixed/processed. Of course, Mozilla isn’t helping by making everything about values, but maybe it can make an exception here, and implement some open-mindedness in the name of getting things done.
Open source cannot be done with closed minds, and without a little forgiveness. If you want to choose who contributes, close your doors. Otherwise forgive or look away, and move on.
Tyler, I don’t curse/shout at/attack mozdevs. I just try to defend my own bugs, which sometimes get WONTFIX without any reasonable explanation. And the mentioned bug, that was WONTFIXed 3 times – is now “NEW”. That just proves that I was right, and the WONTFIXer was wrong. He ignored my questions (without any shouting, any curses, just plain questions) and silently WONTFIXed my bug again and again. And now my new account is banned again. For no reasons.
So who is attacking whom now?
Just greetings from the fellow bug triager from bugzilla.redhat.com. Yeah, I could write something very similar about my experience (except, I am paid to work on bug triage, which makes it much better experience for me).
Also, just to say, that our friends at Chromium (http://code.google.com/p/chromium/issues/list?can=2&q=status%3AUntriaged) or for example Gnome (https://bugzilla.gnome.org/buglist.cgi?query_format=advanced;order=Importance;bug_status=UNCONFIRMED) are not doing that much better.
Which is not to say that the situation is hopeless, more that the underestimation of the value of bugs management is very common, and I don’t think any proposed solutions on level of tools will resolve it (not that our tools are adequate — I wouldn’t be writing https://fedorahosted.org/bugzilla-triage-scripts/ FF extension if they were).
Thanks for the links, I was wondering how Chromium would fair (I didn’t really expect them to do better, but it’s good to have a point of reference since they’re using a different bug tracker). The Gnome link is technically unfair (it’s 28,037 bugs as of now, and took ages for the query to finish) since that’s the entire gnome.org project whereas I’m pretty sure that Tyler is only talking about Core+Toolkit+Firefox as opposed to all of mozilla.org.
This is probably a better link for Gnome (it grew by a bug before this query ran…):
https://bugzilla.gnome.org/report.cgi?y_axis_field=classification&query_format=report-table&bug_status=UNCONFIRMED&format=table&action=wrap
— that’s IF you can make something out of their classifications, if you can’t,
https://bugzilla.gnome.org/report.cgi?y_axis_field=product&query_format=report-table&bug_status=UNCONFIRMED&format=table&action=wrap
and the equivalent mozilla.org link:
https://bugzilla.mozilla.org/report.cgi?y_axis_field=product&query_format=report-table&bug_status=UNCONFIRMED&format=table&action=wrap
Aside from including all the gnome products probably being a bad choice (Other is things hosted on gnome.org but not part of the desktop itself), not all of them treat unconfirmed and new any differently.
For a number of them (including the one I used to maintain), the unconfirmed/new split is purely down to whether the creator had permission bit that lets their bug start as New.
As a end user with a great interest in all things Firefox I must say that your comments is rather refreshing and not that different from my perceived understanding of the current situation.
Firefox as an open source community project is suffering from the same problem that a lot of open software projects are suffering from. The part of the community that contribute program code is the ones in the pound seats. Just listen to some of the responses and comments from developers.
It is rather madding. I understand why people are switching away from Firefox. I even want to do it and I am am very close. But the truly sad part is that Mozilla the organisation has failed its community. They are in the unique position to have more paid developers than most open source projects. Yet they don’t act differently than pure community based projects.
They don’t use their financial resources to focus the energy of the community, or guide the contributions. How many great technologies are in Firefox? How many of those would be 10x better for an end user, if someone sat down and mapped it out properly before a single line of code was written?
Take Apptabs. You make a tab an Apptab, go to bookmarks and open a bookmark. It opens in a new tab, protecting the Apptab. Now do the same, but open a submenu and select “open all tabs”. why the difference in behaviour? Why not map it properly and implement it properly. Then alphas and betas mean something.
You look at IE9 and you read the developer blogs. You have one clear message. They thought things through. They made decisions on user experience rather than ease of code. They tweak where needed and listen to feedback.
There should be bugs, things that are actually broken in the code that needs a fix, driven by technical people for developers to focus on to fix. Then there should be feedback and request for future features that drives design and future development. These are two different things.
Until the Mozilla realise that you can only change the web if you have a user base that sticks with you and you will only keep that user base with a well rounded application that is a pleasure to use, we will have more people like the writer leaving and stop caring…
As someone tasked with handling just the releng portion of triage, I can commiserate/sympathize. It’s hard to keep a handle on even our small subset of bugs without dedicated effort, which I often can’t sustain.
As the recently hired “bugmaster” for the Jetpack team, my job is partially to act as a first-pass triager for recently filed bugs. I’m also trying to keep the number of stale bugs (bugs that haven’t been touched in XX days/weeks/months/etc) down to a minimum. The Bugmaster is also supposed to be an intermediary between bug filers and Mozilla developers.
I had written a little extension that pulls bug data from Bugzilla’s REST API and sorted them all out based on how stale they were, marking recently filed bugs with green text, bugs that hadn’t been touched in a month in red, bugs untouched for two months in bold red text, and bugs that haven’t been touched in 6 months in bold red text wrapped in a tag.
I then rewrote the extension as just a plain webpage, which doesn’t yet support the staleness categorization, as I changed the backend of the page to use a javascript library to handle visualization of the data coming in. http://kwierso.github.com/Jetpack-Bugzilla-Organizer/
It works okay for the Jetpack product in Bugzilla, since it doesn’t have a whole lot of bugs in the system yet, but the REST API chokes on getting a lot of bug data for larger products, so it would need a different way of pulling in all of the bugs. (I think I could have it give a list of all bug IDs and then request bug information for each ID individually, although that’d be a lot of requests…)
As I understand it, my 3-month contract as Bugmaster is not just a trial run for me as Bugmaster in Jetpack, but could also be considered a trial run for “bugmaster” as a position for other parts of Mozilla.
So I guess the pressure’s on me to do a good job so more people get hired for this position throughout the company…
As someone who’s reported 26 different bugs in 6 years and never had a single one resolved as a result of the reporting I applaud you for your stance.
One problem with measuring response times is that it may steer responses to become more meaningless in the hopes of being faster. Compare to all the millions of “help desks” of big corporations: when you call them with a problem, it is obvious that their main concern is to get rid of you as quickly as possible so that they can mark the case closed, so it will look good in their stats (“hey looky here, see how quick my averages are”), instead of actually focusing on solving the problem.
If you start measuring response times, it would be important to come up with a way to ensure the response quality doesn’t decrease. After all, what good is a useless response, no matter how quickly you get it?
By response times I don’t mean bug closure. I mean, how quickly can we get a triager on the bug, asking for more information, getting the reporter involved, and gathering all the information needed. I don’t think that closing a bug quickly in itself is a bad thing, but I more don’t want a bug to sit around with no comments on it for a year.
13000 down to 6000? That’s pretty frickin’ awesome. Thanks!
I don’t think most of us developers know much about triage. I know I don’t. I occasionally think “man, that’s a really hard problem. I wonder how we deal with it?” and that’s about it. I just have a vague notion that magic or temporal manipulation is somehow involved. I’d love to hear more about what actually goes on in triage, and I suspect others would be interested as well.
As a developer, I have an instinctive fear of getting sucked into triage because I know it has an insatiable appetite for time. I’d bet many devs would be willing to help with the overall triage process. But if there’s a hint that it means we have to jump on every vague bug report that a triager forwards to us and work on it until it’s good and dead, we’ll run away and hide under the nearest potted plant. It is hard enough to stay focused on development priorities without an added source of interrupts.
That’s why it seems to me to be most valuable to raise general awareness of what triage involves and what the pain points are, so that we can collectively brainstorm about how we could contribute in “smarter not harder” ways. This may seem horribly selfish, but being in reactive mode all the time is neither optimal nor pleasant.
Things I’d be interested in knowing: how big is the incoming flood of bug reports? What percent are pure junk, what percent can be usefully handled by support, what percent are easy to categorize, what percent could be diagnosed trivially by the right developer, if there is a real bug involved how many duplicate-ish bugs tend to be filed as a result, what do triagers spend their time on, would it help if a triager could gather a list of bugs & their relevant information for a given area and submit it so that a dev could scan it and answer some question in a batch mode (“which of these are going to be useful, and which will require detailed information?”), how many bugs require additional info and how often is it provided when someone asks for it, what support tools would make life easier for triagers (I’m thinking of tools for gathering more information from users, not bmo interfaces or whatever), …
I just feel like there’s a conversation that needs to be happening between triagers and developers, and it isn’t, for the most part.
would it help if a triager could gather a list of bugs & their relevant information for a given area and submit it so that a dev could scan it and answer some question in a batch mode
Sounds interesting but not necessarily easy. Maybe a useful took in that direction would be some way to make up a bugzilla list of bugs so that you could see (maybe at mouseover over the one-line entry for each bug) not just the Summary but the whole Description. Not perfect though; sometimes a triager needs to, (what’s the English expression? French “tirer les vers du nez”, wfw “pull the worms out of the nose” ie. repeatedly ask many questions) of the reporter before an idea can form of what the perceived problem is.
Ah, that explains a few things then.