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

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.