Prioritize issues #1101

@ptman commented on GitHub (Sep 28, 2017):

Aren't labels enough?

@ptman commented on GitHub (Sep 28, 2017): Aren't labels enough?

GiteaMirror commented

@kolaente commented on GitHub (Sep 28, 2017):

You cannot order by priorty if you make them with labels only. Thats why I (we) want to do it this way.

It's more like giving weight to an issue.

@kolaente commented on GitHub (Sep 28, 2017): You cannot order by priorty if you make them with labels only. Thats why I (we) want to do it this way. It's more like giving weight to an issue.

GiteaMirror commented

@lafriks commented on GitHub (Sep 28, 2017):

Probably better it would be for labels to add field priority. That would not take new space in issue left side and could be sorted by using max priority from all added labels to issue

@lafriks commented on GitHub (Sep 28, 2017): Probably better it would be for labels to add field priority. That would not take new space in issue left side and could be sorted by using max priority from all added labels to issue

GiteaMirror commented

@tomposmiko commented on GitHub (Nov 22, 2017):

How can I second this?
In my opinion it also would be brilliant, if issues could be sorted with pulling them up and down with mouse.

@tomposmiko commented on GitHub (Nov 22, 2017): How can I second this? In my opinion it also would be **brilliant**, if issues could be sorted with pulling them up and down with mouse.

GiteaMirror commented

@kolaente commented on GitHub (Mar 22, 2018):

Found an interesting thing in [issue.go](https://github.com/go-gitea/gitea/blob/master/models/issue.go#L39), apparently someone added Priority in a basic form. But this is never used in any way.

Apparantly it was Unknown (git blame -L 43 -- issue.go):

6f9a95f830 (Unknwon                 2016-08-16 10:19:09 -0700   43)     Priority        int

This means we could somehow add this with not too much effort 🤔

@kolaente commented on GitHub (Mar 22, 2018): Found an interesting thing in `[issue.go](https://github.com/go-gitea/gitea/blob/master/models/issue.go#L39)`, apparently someone added `Priority` in a basic form. But this is _never_ used in any way. Apparantly it was Unknown (`git blame -L 43 -- issue.go`): ``` 6f9a95f830 (Unknwon 2016-08-16 10:19:09 -0700 43) Priority int ``` This means we could somehow add this with not too much effort :thinking:

GiteaMirror commented

@alexandr85 commented on GitHub (Jun 5, 2018):

UP

@alexandr85 commented on GitHub (Jun 5, 2018): UP

GiteaMirror commented

@rudineirk commented on GitHub (Jun 7, 2018):

For reference, gitlab does it like this:

On the label list page, you can mark a label as a priority label, that can later be used to sort issues. The order of the labels priority is done by drag and drop on the labels marked as prioritized

@rudineirk commented on GitHub (Jun 7, 2018): For reference, gitlab does it like this: ![labels-priority](https://user-images.githubusercontent.com/5260987/41112162-9882c8d2-6a54-11e8-8573-a75da0aa3fdb.png) On the label list page, you can mark a label as a priority label, that can later be used to sort issues. The order of the labels priority is done by drag and drop on the labels marked as prioritized

GiteaMirror commented

@lunny commented on GitHub (Jun 8, 2018):

@rudineirk It seems that's another idea. Both two features maybe could be implemented.

@lunny commented on GitHub (Jun 8, 2018): @rudineirk It seems that's another idea. Both two features maybe could be implemented.

GiteaMirror commented

@stevegt commented on GitHub (Jul 9, 2018):

I'm at the point of needing a numerical (integer) priority field now. Has anyone else has a chance to look at or work on this more?

(As an aside, I also could use the ability to add other sortable fields, including calculated values. It would be best to implement these sorts of things as a plugin, but we have no plugin system yet. If this is interesting to you, go weigh in at https://github.com/go-gitea/gitea/issues/2222#issuecomment-403336319 and see if we can reach some sort of consensus on how this should work.)

@stevegt commented on GitHub (Jul 9, 2018): I'm at the point of needing a numerical (integer) priority field now. Has anyone else has a chance to look at or work on this more? (As an aside, I also could use the ability to add other sortable fields, including calculated values. It would be best to implement these sorts of things as a plugin, but we have no plugin system yet. If this is interesting to you, go weigh in at https://github.com/go-gitea/gitea/issues/2222#issuecomment-403336319 and see if we can reach some sort of consensus on how this should work.)

GiteaMirror commented

@NotAFile commented on GitHub (Nov 26, 2018):

I think giving labels priority is the best way. This means that you don't need to add a new mechanic to add/set/display priority, you can just reuse the labels.

@NotAFile commented on GitHub (Nov 26, 2018): I think giving labels priority is the best way. This means that you don't need to add a new mechanic to add/set/display priority, you can just reuse the labels.

GiteaMirror commented

@stevegt commented on GitHub (Mar 5, 2019):

The reason for an integer or floating-point priority field is to be able to use risk/reward, internal rate of return (IRR), or decision-tree math to more objectively prioritize issues.

This helps avoid the "everything's a sev 2" problem. In enterprises that still use the old IBM-style system of four or five severity or priority levels, this often collapses into a political exercise, with the vast majority of bugs getting assigned an unsorted priority of 2.

A time-consuming workaround is to have periodic project management meetings, which again get political but are where due dates get assigned for some of the sev 2's, giving you more granularity than the four priority levels. With #6206 merged we can now sort by due dates, but again that's a workaround for when you don't have something like IRR.

In our own case locally, we already have a python script that does the IRR math. It uses the API to mine issue comments for IRR inputs and generates a report sorted accordingly, but right now that report has to be stored as the text of a managed issue for lack of any better place. It probably should be putting its output into a db column instead.

I'm not suggesting that the math for IRR etc. be included in core gitea; just that we allow for an integer or floating point priority field to enable API plugins like this one. I think this would encourage more enterprise adoption (and possibly some funding).

A more generic solution would be to support user-defined columns, but that gets into the plugin discussion (#2222), and I don't yet know enough about gitea's internals to know which approach makes more sense.

@stevegt commented on GitHub (Mar 5, 2019): The reason for an integer or floating-point priority field is to be able to use risk/reward, [internal rate of return (IRR)](https://www.google.com/search?q=internal+rate+of+return+project+management), or [decision-tree](https://www.google.com/search?tbm=isch&sa=1&q=real+options+decision+tree+project+management) math to more objectively prioritize issues. This helps avoid the "everything's a sev 2" problem. In enterprises that still use the old IBM-style system of four or five severity or priority levels, this often collapses into a political exercise, with the vast majority of bugs getting assigned an unsorted priority of 2. A time-consuming workaround is to have periodic project management meetings, which again get political but are where due dates get assigned for some of the sev 2's, giving you more granularity than the four priority levels. With #6206 merged we can now sort by due dates, but again that's a workaround for when you don't have something like IRR. In our own case locally, we already have a [python script](https://github.com/stevegt/gitea-issuebot) that does the IRR math. It uses the API to mine issue comments for IRR inputs and generates a report sorted accordingly, but right now that report has to be stored as the text of a managed issue for lack of any better place. It probably should be putting its output into a db column instead. I'm not suggesting that the math for IRR etc. be included in core gitea; just that we allow for an integer or floating point priority field to enable API plugins like this one. I think this would encourage more enterprise adoption (and possibly some funding). A more generic solution would be to support user-defined columns, but that gets into the plugin discussion (#2222), and I don't yet know enough about gitea's internals to know which approach makes more sense.

GiteaMirror commented

@baselab commented on GitHub (Mar 23, 2022):

Any new on this? It would be much appreciated!

@baselab commented on GitHub (Mar 23, 2022): Any new on this? It would be much appreciated!

GiteaMirror commented

@lafriks commented on GitHub (Mar 23, 2022):

I'm slowly working on it https://github.com/go-gitea/gitea/pull/11669

@lafriks commented on GitHub (Mar 23, 2022): I'm slowly working on it https://github.com/go-gitea/gitea/pull/11669

GiteaMirror commented