4 ms·

I'm still confused by the inability to do prioritisation. Why does Github so stubbornly not have a way of doing that including sorting on it? I am aware you c

I'm still confused by the inability to do prioritisation. Why does Github so stubbornly not have a way of doing that including sorting on it? I am aware you can create arbitrary labels, but that doesn't help with sorting. We long ago gave up on Github issues because of this, and use Trello instead where priority is simple drag and drop. The other problem is that you can't easily copy/move/link issues between repositories. This becomes necessary when you have different repos (eg a server one, an android one and a web one) and something is reported against the "wrong" repo. Not the reporters fault, and very tedious to correct. This is all one area where Google Code does things so much better (yes you can prioritise and sort). Each project can have any number of repositories and they all share the same wiki and issue tracker. That is a lot easier to deal with. Of course refusing to take money, and apparently losing interest means it can't be used.

scrollaway 12y ago
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.
- watwut 12y ago
  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.
  - scrollaway 12y ago
    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.
    - watwut 12y ago
      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.
- rogerbinns 12y ago
  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.
  - Walkman 12y ago
    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.
phloxicon 12y ago
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.

scrollaway 12y ago

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.

watwut 12y ago
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.
- scrollaway 12y ago
  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.
  - watwut 12y ago
    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.
rogerbinns 12y ago
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.
- Walkman 12y ago
  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.

phloxicon 12y ago

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.