Indifference to process leads to Mozilla contributor departing

Tyler Downer announced he was no longer contributing to Mozilla because the Mozilla bug triaging process was being sacrificed on the altar of “rapid release”. Tyler likes the idea of the Rapid Release, but rather the tools to handle bug reports are failing under the new 6-week release cycle.

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.

Tyler then points out that:

In Spring 2010, we hit roughly 13,000 UNCO bugs in the Firefox product on BMO. 13,000!!! We currently have 5934. 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.[italics mine]

Mozilla behavior toward this ancient feature request is illustrative:

• The request was filed in 1999 (12 years ago)!
• Numerous offered patches,
• A plugin to workaround this issue,
• Accounts that offered patches are labeled as “Please Ignore This Troll (Account Disabled)”

Wow nothing says Go Away quite so effectively as being labeled a troll or being ignored.

---

Questions

1. How many reported issues are latent security problems?
2. How can Mozilla bug fixing keep up with the community’s bug reporting? The community is vastly larger than the Mozilla development team.
3. How can Mozilla truly leverage the community? And avoid having responsive, assertive community members being labeled as trolls?
4. How can anyone feel good about closing 1 bug out of 13000, especially if the incoming rate is greater than the fix rate?

Thoughts

This is something that every company or open-source project hopes to have: a community that overwhelms the product with love. Mozilla is doing the wrong thing if the love is unrequited.

With so many bugs churning in, developers are faced with a sisyphean task. The bugs represent community love, the developers have to view the love as not burdensome.

These thoughts really apply to every company, product and project:

Developer Bug Tool

A developer-facing bug database must only hold bugs (broken code that must be fixed),

1. NO Feature Requests
2. NO Project Plans
3. NO “technical debt removal” wishes,
4. NO minor bugs

Developers like all humans need to feel the progress, and accomplishment. Fixing one bug out of 13000 does nothing, fixing one bug out of 100 feels meaningful.

Feature requests and refactoring or changes for the future belong in a project planning tool.

Any bug, that cannot or will not be fixed immediately, must be documented in the code:

• TODO flag
• Date ( a TODO that is 10 years old not that useful – with a few exceptions )
• Person who added this comment (not necessarily a full-time developer)
• HACK flag if the code should not be an example of “how to do” things. This tells future developers to not use this bad code as a template to create more bad code.
• Discussions can happen in the code same as they would in a separate bug database

Documenting in the code not the bug database gives these benefits:

• Developers tracing a different bugs or adding new features are proactively notified without searching that:
  • the code is questionable
  • the code may be the source of the bug he is tracing
  • he may be able to immediately fix the bug documented in the issue
• If the questionable code is deleted as part of a later refactoring feature change, the bug report is also deleted.
• The bug database is not polluted with minor items that bury the truly critical issues.

Use Git

Get away from the Open-source Cathedral where only a few are blessed committers.

Avoid frustrating people who want to patch the product. Let them patch the product and share their patch. If the main official release doesn’t include the patch, at least the person reporting the problem can fix the problem for themselves and move on.

Prefilter bug reports

• Incorrectly formatted html: IE choose to format it one way, Firefox made a different guess. Just because FF made a different choice doesn’t make FF wrong, but that will not stop a bug report. FF should have a clear indicator that:
  

  The page in question has bad html and that it may not be displayed correctly. Click here to send a note to the webmaster about this page.

  Point the finger of blame at the webmaster so that FF does not get blamed (and avoiding the bogus resultant bug reports).

• Bad scripts: If the javascript is not functioning correctly announce it. Its not FF’s problem that the script sucks, don’t let Firefox get the blame.

Make it easy to report issues

• Built-in feedback tool
• Built-in screen capture (with redaction ability)
• Do not require registration in a bug database
• Do the bug reporting within Firefox don’t make people navigate.
• Ask if the last report by this person is related.
• Do the bug database duplication search for the user and ask if any of the other reports look similar.

Final Question

How can your product or service empower the community to self-help?