Comment by jashkenas | Hacker News Reader

Comment by jashkenas | Hacker News Reader

Parent Full thread

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:

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!

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"?

That's entirely right.

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?

Man, that really sucks.

Reply on news.ycombinator.com