Two things I always want, which I'm amazed aren't commonplace yet: 1. One of the fundamental operations, for all of software development, is taking a big task

Two things I always want, which I'm amazed aren't commonplace yet: 1. One of the fundamental operations, for all of software development, is taking a big task and dividing it into smaller tasks. The smaller tasks should inherit the relevant fields (e.g., assignee, and target milestone) from the original one, and the original issue should aggregate the relevant fields (e.g., sum the time estimates, and let me see one mega-diff of all the constituent changesets) of all of its sub-issues. Of course, sub-issues in turn need to be able to be broken down further. Most bug trackers are able to create dependencies between issues, so it's possible to create such a thing out of a dependency tree, but I've never used a system that made it easy. 2. It should be Git-based. The state of the issue tracker is just data, and I should be able to work on that without a special web-only interface that requires me to be online (though it should still have a web UI). I want to use my own tools -- I would have saved a ton of time over the years if I could have just grepped the whole issue database for what I was looking for. This would also make it easy to write programs to operate on the issue data -- I don't want to learn your issue tracker's special API. Or do the same thing to 20 issues by having to click 200 times. On GitHub, everything is a repo (source code, project wikis) except the issue tracker. So close! It's almost like they were intentionally trying to make this one type of data difficult to work with.