I love Github, but they need to build out more serious features into their issue tracker for it to be useful as a software estimation tool. Specifically I need:
GRANNT Chart: A Grantt chart is a type of bar chart that illustrates a project schedule. Grantt charts illustrate the start and finish dates of the terminal elements and summary elements of a project, such that completion of the project qualifies the team for a research and development grant.
Serious answer: Issues are not--to my knowledge--a software estimation tool. I have worked for decades in estimation-oriented development environments, and in my (anecdotal) experience, it is a mistake to use the same tool for both estimation and delivery.
It is seductive for them to be the same thing, as you can feed actual times back into your project, but the conclusion I've drawn is that the estimate reflects a kind of "interface" visible to the outside world, while the issues reflect an "implementation" visible to the team.
When they are the same thing, you end up doing a lot of work fiddling with the estimate to keep it congruent with the internal tasks, even when that congruence is not relevant to the delivery date(s).
Personally, I disagree. Sure, first you get time estimation. Then you get task-based time tracking, then you get average resolution time per committer, then you get weekly spreadsheet generation and analysis meetings on thursday afternoons and there you go, now you're getting memos about adding coversheets to your TPS reports.
I hope they are very careful about adding features and would rather see them focus on trimming less useful features.
Honestly I think that, like version control, time estimation can be a very useful feature for people working on a project alone if they use something like Joel Spolsky's evidence-based scheduling[1]. It would be nice if GitHub provided a way to keep track of that. I agree with you that there's a point where there get to be too many features, but if they're building a project for teams to work on things time estimation seems too useful to pass up.
Serious answer: Issues are not--to my knowledge--a software estimation tool. I have worked for decades in estimation-oriented development environments, and in my (anecdotal) experience, it is a mistake to use the same tool for both estimation and delivery.
It is seductive for them to be the same thing, as you can feed actual times back into your project, but the conclusion I've drawn is that the estimate reflects a kind of "interface" visible to the outside world, while the issues reflect an "implementation" visible to the team.
When they are the same thing, you end up doing a lot of work fiddling with the estimate to keep it congruent with the internal tasks, even when that congruence is not relevant to the delivery date(s).
I realize that this is heterodoxy.