I wanted give a bit of input to an idea I have started to hear tossed around which I find quite intriguing. Shutting down BMO for a week or so, and devoting ALL Mozilla’s resources (devs, QA, the community, everyone) to cleaning up BMO. With 5868 UNCO bugs, and 7191 NEW bugs in Firefox alone, we obviously have a bit of need for cleaning up. Then throw in Toolkit (UNCO bugs, NEW Bugs), Thunderbird (UNCO bugs, NEW bugs), Core (UNCO bugs, NEW bugs), and so many other components and products, and really, we do have a mess on our hands.
The solution isn’t as simple as it sounds. If we just shut BMO down now, we will be using resources ineffectively, and without a long-term solution we will be right back at square 1 within a year or two. I whole-heartedly approve of shutting BMO down for a week or so, but I also know we need a multi-pronged approach. If you read my series on why we need to radically change triage, you can read most of my points there, and they are ones I have been saying repeatedly for the past year. I’ll quickly summarize them here though.
- Create a separate product for UNCO bugs and triage. There is a new Input Tool in the works right now, and it will be using this idea in a more constrained form. I have had some discussions with the people working on it, and hopefully we can get this UNCO product rolled out to cover all bugs submitted for Firefox/Toolkit/Thunderbird/etc. I do see promise of progress here, so this is good news. Once we get this fully implemented, I feel all UNCO and abandoned NEW bugs should be moved into the product.
- Create a way for Triagers to tell how far a bug is in the triage process, using multi-state flags. This idea was proposed at the Summit 2010 by tmyoung. Unfortunately, a lot of devs didn’t want to have their bugs cluttered up with more flags (which is understandable). By implementing the flags only in the UNCO product, they will serve triagers, and once a bug is moved out of the product, they will be no longer be needed and removed. Hopefully this way we can make both sides happy.
- We desperately need a way to mark Support and Extension bugs as such. Having a RESOLVED>Support status and a way to automagically open a support issue for the bug will go far to help users feel that we care about them and their issues. The same goes for extensions.
- We need Bug Triage Guidelines. Something along the lines of what I threw onto the wiki a few months ago (obviously a lot more fleshed out). But something the community, especially new members, can reference.
- I think that if we implement a lot of the ideas that David Eaves has proposed, we can go far in improving both triage, and BMO in general. I know a few of his suggestions have already been put into production, but I don’t see any of them that would harm the community, and I think they should be thought about again.
- I’m not sure how practical this is, but perhaps we can create some sort of bot to automatically ping a triager when a bug has gone a certain amount of time without a comment, and to ping reporters when they have not replied to their bug after a certain amount of time. This would eliminate much of the time that is spent “cleaning up”, freeing more time for “real” triage.
- Hire several official Traigers. To do several things (most of which I’ve already discussed, so I give it in brief here). Organize the community, help new community members, communicate with Devs, do full-time triage work, be advocates for the community in Mozilla.
- Having a yearly intense cleaning like Mike proposed would also be great, because even with the best of efforts, some bugs will slip through the cracks. The first one I think we should set a week aside for, but subsequent BMO cleaning could probably only be done in 3-4 days.
So I know this is a fairly short summary, but these are by far my most important changes to BMO, and the Triage process that I think need to be made. Some progress is happening, so I look forward to seeing what is done in the near future.
