http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=10869
In my experience, when you have around 10 known issues, you can
discuss the status of each of them in a 1 hour weekly meeting. You can
easily notice when two are duplicates of each other, and combine them.
You can keep track of which ones have been reproduced, and which
need further information in order to reproduce. You can keep track of
who is assigned to work each issue, and in what order they should work
them. You can remember from week to week what the issues are about,
without having to spend all your time coming up to speed again on each
issue. You can ask whether each issue presents an opportunity to
improve the documentation, or to improve the QA process. You can
ask to review in detail the proposed fix for each problem, until you are
satisfied that the fix actually solves the problem without creating other problems.
You can ask whether each problem was caused by a fault in the tools used,
or the process used, and if so, whether to make improvements in those.
You can notice when multiple problems relate to the same component,
and perhaps decide to redesign that component rather than continually
patch it. You can thoughtfully decide whether to deliver a fix as an urgent
update, or wait to deliver it in the next general release. You can develop
regression tests to prevent the same or similar problems from ever being
shipped again. And when a problem is fixed and the fix delivered, you
can move it off your agenda.
When you have about 100 known issues, it becomes much more
difficult to do the same tasks. You can try to prioritize and focus on
just the top 10, but then the others suffer. When you have about 1000
known issues, it becomes impossible to manage, and you will completely
lose track of which issues are duplicates of others, which are fixed, and
which are urgent. If you release a product update, you will have no idea
what to say in the release notes.
