> It has become really difficult for us to manage the feature requests
> and bug reports being filed against the MDN. I spend a lot of my time
> just keeping Bugzilla under control, when I think my time could be
> better spent managing our process at a higher level.
We need to group bugs by theme rather than to prioritize them individually.
Two-level approach (meta + bug)
I think we should adopt a two-level approach: a first level where we
give priority to broad areas, like we did in Toronto. A second with the
In Toronto we identified big areas that need love. If I recall well:
- File attachments
- l10n dashboards
- Live Samples
- Find & Replace Tool (at least Find)
We can add:
- RSS feeds
- Edition improvements
- Editor dashboards
- Admin dashboards
We could create a meta bug for each of these (I already did it for SEO
and perf). So each time we get a new idea, we can link it to the meta
bug where we already see the history of what has been fixed.
Then for each sprint, one can put priorities to each of this categories
and pick a (more or less) proportional amount of bugs for the sprint
from each bucket. E.g. we already did a lot of work for SEO, but not
much on l10n dashboards, so we should take more bugs in the next sprint
from this bucket than from the SEO (except my pet bug of course :-P)
I like meta bugs as they have several advantages:
1) We easily see already fixed bugs. It is a simple but imperfect
2) We can check if a similar bug has already been submitted, as it is
likely listed there.
3) We see our new bug in context: related bugs are one click away.
4) We don't need to put a precise priority to each individual bugs. (At
least not until the beginning of a doc sprint)
Also a bug may be linked to several meta bugs. (Some performance bug are
also edition improvements).
Finally I noticed that meta bugs just get forgotten once most of the
feature is there, even if never closed or if minor bugs are still open.A
kind of natural 80%-20% rule!
To see them in action, the two meta bugs that I'm using a lot:
(We fixed about 60% of the SEO-related bugs since Toronto, on the four
remaining: one is another meta bug, one has seen progress lately, one is
my pet bug and the last one is low priority)
(Loading time: about 50%, but no bug related to the first loading time
has been filled as it will be done with the theme redesign that is
planned for next year)
The meta bugs are more useful for improvements to an existing feature
than for brand new features.
The pet bug
This is another system to prevent heavy users (like us) to be frustrated
by small things, while keeping focused on the big bugs too.
Each of us can propose one unique non-meta bug (at the bi-weekly IRC
meeting for example). A bug that blocks him/her or annoys him/her. Each
2 weeks, he/she is allowed to change it of course, but only one single
pet bug per person is considered for each sprint.
Beside big priorities, only these bugs will be considered at the next
planning meeting (where only a few people attend, so we prevent people
attending to defend their pet bugs).
Having his/her pet bugs fixed (not at every sprint, but once in a while)
lead to an impression of progress (and solve practical problems). Also
this prevent numerous of secondary bugs to get in front of the big
tasks: only 5-6, deemed annoying, of them may be nominated for each
sprint (and not necessarily fixed at once). This help in keeping the
focus without neglecting small but annoying details.
Note: the pet bug is biased towards editors (and power editors even). I
think somebody should be the user voice here.
Note2: there is no guarantee that a pet bug will be fixed in the next
sprint. Only that it will be looked at at the planning meeting.
Note3: this work with a relatively small number of people submitting pet
bugs (< 10)