The problem is you always have to cut features somewhere to remain clean.

Look at bugzilla: So many fields most people don't need. Who needs to separate "Resolved" and "Closed" for example? Who cares about the OP's platform when you're building a web app? And why is "importance" different than "priority"? Why is there a keywords field, a tags field AND a whiteboard field? Wtf.

But all these are actually useful to some people out there. The problem is the end result is a mess. I find github issues to be good enough for 99% of non-massive/non-corporate projects out there. People can just go check out your project and add 3-4 bugs/suggestions as easily as they would comment on a blog post.

Personally what I miss is being able to flag a bug as a dupe of another. But again, do most projects need that is the question.

Prioritisation is something I see in every other tracker. If items are dispatched/fixed/closed from the tracker faster than they come in then it doesn't matter, but that is rarely the case. The moment there is more available issues than can be worked on right now, prioritisation needs to be done. The are many criteria that could be used, but "priority" is a pretty established one. The problem with github issues is there seems to be no viable way to get that.

I agree about having lots of different fields. I once worked somewhere where after a series of acquisitions 11 different bug tracking systems were collapsed into one! Having arbitrary labels mitigates most of those. IIRC Google Code also lets add as many different states as you want so that works too, letting projects be as simple or complicated as suits them.

This os why Django uses Trac. Github issues can't handle that much traffic, triage as a simple Trac installation with a couple of pkugins.

Less important thing that can be done in two hours may have higher priority then more important thing that requires twelve man-moths of development. Or higher then one we have no idea how to do so far.

Priority is more about scheduling and importance ignores planning/managerial issues.

We used "Resolved" and "Closed" for two different things in work too. I was missing those distinctions on afterwards.

You're telling me things I already know. The problem is that, realistically, there are no differences in most project. And if there are differences, odds are high you either have grown too big for github issues or you have a bureaucratical mess of metawork in your tracker.

Remember, always remember: A tracker is supposed to help you develop your software faster and better. Meta-work should never get in the way.

It was zero additional work. Importance was filled by analyst and priority when planning. It was very neatly managed project, one of the best I worked on. If it is kept neat, those things help a lot.

Github labeling way of prioritizing and what not is actually harder to keep then fixed fields. You can live with that, but it requires more effort and attention to be useful.

Anyway, the problems the parent complained about are not in priority/importance category. The inability to do prioritization more practical then labels or milestones is a big thing. It is standing in a way, because you have to spend too much time in issues list and essentially re-prioritize in head again every time you are looking for something to do.

I love the way you can star issues on Google Code. Sorting by stars shows the feature most people want. Github could really use this.