4 ms·

Isn't this just a failure in the art of delegation? Having every maintainer read every ticket clearly doesn't scale...

• jashkenas 14y ago
  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/7334 https://github.com/twitter/bootstrap/issues/7333 https://github.com/twitter/bootstrap/issues/7333 https://github.com/twitter/bootstrap/issues/7325 https://github.com/twitter/bootstrap/issues/7325 https://github.com/twitter/bootstrap/issues/7320 https://github.com/twitter/bootstrap/issues/7320 https://github.com/twitter/bootstrap/issues/7324 https://github.com/twitter/bootstrap/issues/7324 https://github.com/twitter/bootstrap/issues/7312 https://github.com/twitter/bootstrap/issues/7312 https://github.com/twitter/bootstrap/issues/7302 https://github.com/twitter/bootstrap/issues/7302 https://github.com/twitter/bootstrap/issues/7296 https://github.com/twitter/bootstrap/issues/7296 https://github.com/twitter/bootstrap/issues/7290 https://github.com/twitter/bootstrap/issues/7290 https://github.com/twitter/bootstrap/issues/7282 https://github.com/twitter/bootstrap/issues/7282 https://github.com/twitter/bootstrap/issues/7279 https://github.com/twitter/bootstrap/issues/7279 https://github.com/twitter/bootstrap/issues/7265 https://github.com/twitter/bootstrap/issues/7265 ... and those are just a random smattering from the past week!
  • shurane 14y ago
    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.
  • knite 14y ago
    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"?
    • jashkenas 14y ago
      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.
      • gregmolnar 14y ago
        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?