Managing any project with thousands of contributors is very hard - namely, duplicate bugs, low quality bug reports, bugs that are no longer valid given OS or ve

Managing any project with thousands of contributors is very hard - namely, duplicate bugs, low quality bug reports, bugs that are no longer valid given OS or version changes, etc. I can't imagine how hard it is to manage something on the scale of Android, where it's so consumer-oriented, half of everyone with a phone (roughly) potentially could be using the bug tracker. There may be some interesting room to build a bug tracker that can better semantically sort, and ensure better quality bug reports - templates for bug reports are a start, but there are very few if any good triage tools for the people on the other end of the system. In this case, yes, there should have been at least a canned template response such as "if this still affects you,..." etc, but even that is difficult - with 50 people replying to a bug report, it's a good way to get 50 duplicates. Ultimately, it's a sign where open source project management practices get increasingly hard the larger a project gets, and while it may be possible to keep up with the contributors, keeping up with userland can be an even larger feat. In some ways, proprietary software has a it a LOT easier, and I don't envy the task. While not every project can hire 15-30 extra people to manage and prune a gigantic issue tracker - Android probably can, and probably should, given the spirit of what it is. Longer term, I still think we can do a lot better with bug tracker technology to provide more semantic views into what's there and needs to be done - eliminating the need to keep things pruned in this way. But we are no where close yet.