I wish it were. Unfortunately, not all projects are blessed with such lovely and helpful maintainers like Sam, Brad, Tim (for Backbone), and Nami-Doc, Michael, and Demian (for CoffeeScript), just to mention a few.
In practice, you'll rarely find a jQuery ticket (for example) that doesn't have to be read in the end by Dave, and you'll rarely find a Bootstrap ticket that doesn't have to be read by Mark:
I upvoted the original submission because I think this is an interesting and important problem for maintainers of large OSS projects.
It would be nice for Github to provide some administrative tools or interface changes to make maintainers' lives easier. However, I am tentatively in agreement with the posters who suggest that this is largely a management problem.
I've read the examples you linked, Jeremy, but I don't see why those issues (and the majority of issues on large-scale projects) require review by the head maintainer/BDFL. Most of these issues are chaff - either they're not reproducible, poorly explained, or requesting features which have already been discussed and dismissed. It shouldn't need Mark's or your time to say "nope, works for us" or "already decided we're not doing that".
At Coffeescript/Backbone/Bootstrap/etc levels of activity, you have a huge, vibrant community. Out of all those thousands of developers, surely there are a couple of active contributors who can't commit to the project at the "core dev" level but who have to skill and time to take on the role of "issue maintainer"?
This is more of a problem with the current workflow of the current implementation of GitHub Issues, for large projects -- it's absolutely something that can be solved.
Maybe a kinda "Flag for close" button on the github interface would help with this. Than the community would be able to flag issues and the core devs could de-prioritize the flagged ones or if there are flags from enough members they can just close it without reading it assuming that many member is probably right?
But for simple issues, is it necessary for Mark or Dave to go through the tickets themselves? The examples you gave didn't have to be personally closed by Mark.
If people are willing to contribute, wouldn't they also be willing to help you out with all the gruntwork? Is it just a matter of setting it up with Github, which may or may not support that level of granularity?
In practice, you'll rarely find a jQuery ticket (for example) that doesn't have to be read in the end by Dave, and you'll rarely find a Bootstrap ticket that doesn't have to be read by Mark:
https://github.com/twitter/bootstrap/issues/7334
https://github.com/twitter/bootstrap/issues/7333
https://github.com/twitter/bootstrap/issues/7325
https://github.com/twitter/bootstrap/issues/7320
https://github.com/twitter/bootstrap/issues/7324
https://github.com/twitter/bootstrap/issues/7312
https://github.com/twitter/bootstrap/issues/7302
https://github.com/twitter/bootstrap/issues/7296
https://github.com/twitter/bootstrap/issues/7290
https://github.com/twitter/bootstrap/issues/7282
https://github.com/twitter/bootstrap/issues/7279
https://github.com/twitter/bootstrap/issues/7265
... and those are just a random smattering from the past week!