It has been quite a whirlwind past year for me (and for Mozilla). I began as a Contractor working on Mozilla Marketplace support in February 2012. I got married to the love of my life in May. I made several trips to San Francisco for work weeks. I transitioned from Marketplace support to a full-time User Advocacy role. I’ve moved (and am preparing to move again). Mozilla has developed and announced Firefox OS. We’ve begun projects such as Squeaky, we’ve worked on growing and improving our tools. We’ve created a regular Firefox for Android reporting process. We’ve done so many things it’s hard to count. and get ready for an even more impressive 2013. 2012 was dominated by creating the User Advocacy team, and laying the ground work for it. This year User Advocacy can focus our whole potential on being the voice of the user for Firefox Desktop, Android, and soon FirefoxOS. I’m super excited to see what 2013 brings for me, User Advocacy, Mozilla, and the internet.

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.

Not all good things can last forever. I’ve seen over the past several months that as Mozilla has drifted further away from the company that it was in 2008, and further from my goals and vision, and that it is best that I depart from the Mozilla community. Rather than hash out all of my issues in a public blog post, I am just announcing that I will no longer be contributing in any way to the Mozilla Community. I will not be receiving anymore notifications on BMO. I will have the same email address, so if anyone ever wants to get in touch with me they can do so. Any patches that I have floating on BMO, feel free to use if there is anything of value (I doubt there is). My blog will be removed from the planet soon, but I will continue to post personal updates and posts on it (there is some big news coming up soon, so stay tuned).

I have many friends in the Mozilla community, and I want to tell you that this is not any grievance that I have with you, but more on the policies and direction that Mozilla is headed in the future, as well as the treatment of the community in recent months. I wish Mozilla luck, and I will continue to watch it. Sometime in the future, I may begin to contribute again. It is just better that after 3+ years, I pursue other, more productive and rewarding contributions with projects that truly appreciate their communities. Thank you Mozilla for a fun past 3 years, and my friends, peers, and mentors, thank you.

First, let me clarify a few things. By “End-User Bugzilla” and “Developer Bugzilla” I didn’t mean two totally separate Bugzilla installs. While that could be made to work, there are much easier ways to go about it that are much better. I will continue to call it “End-User Bugzilla” for lack of a better term however. The End-user Bugzilla could take the form of a product on BMO, a separate database on another website, a whole range of ideas, I’ll lay those out in a future post.

Current Bugzilla

While slightly out of date, this chart does give the basic idea of how every bug in Bugzilla goes through life. Developer bugs miss the UNCO state usually, but all end-user bugs follow this pretty much from beginning to end. In theory. In reality, end-user bugs sit in one of two states for years. UNCO and NEW. Very few become ASSIGNED or FIXED. The majority end up becoming INVALID, DUPLICATE or INCOMPLETE. Reducing that number, and raising the number of FIXED bugs is the challenge here.

Proposed Bug Process

For Developers, the bug process remains largely the same, a bug is reported, assigned (or resolved WONTFIX, etc.), then FIXED. For End-Users, the bug is put into a staging area. This staging area is where triage, QA and Support can all work together to improve bug reporting for out end-users. A user reports an issue (ticket, bug, whatever we want to call it). Triage jumps on it, ensures that the issue has all the information it needs, filters out spam, and if it is ready, sends it off to the proper “department”. Support questions go to SUMO, Extension bugs are tied into AMO somehow (feedback on an extension perhaps?), and legitimate bugs are sent to BMO, where they are then put into the proper product and component (this is all a one-step process, much like changing products on BMO today). Issues where the reporter never gets back are marked INCO within a certain period of time.

Why this is Better

For Developers, the excess wading through bugs submitted by end-users that may or may not be real bugs is avoided. BMO is devoted to only real bugs, and triage doesn’t have to worry about tripping over a developer and visa versa.

For End-users, this ensure more personal attention. Instead of having their bug ignored, marked INVALID (how uncaring does INVALID sound? It is a valid issue to them, or they wouldn’t have raised it) or some other confusing resolution. Instead of simply being brushed off (which, no matter how we mean it, it appears that way to the general public), users will now get their bug moved straight into the proper place. If they need support, they are happy because boom, there it is. If they did find a bug, it can be an entry into more bug reporting in the future because we move it straight into BMO. If it is another issue like an extension, then the information can be moved where it needs to be. Perhaps even feedback can be taken, then submitted to Hendrix as higher quality information.

A Clearing House

So in essence I envision the “End-User Bugzilla” as a central place for input and feedback from users. Taking the loose ends and pieces of Mozilla’s carious portals, and tying them all into an easy place for end-users to get help, report issues, and make a difference.