Gitea: Prioritize issues

[kolaente]

To quote @lunny in #2175:

@daviian Yes. I mean, we only need to add one column priority to implement it. We can add an order SQL before all other order

order by `priority` desc,  ...

When you pin an issue, we will set the issue's priority as max priority + 10 , and when you unpin it, we could set priority = 0

[ptman]

Aren't labels enough?

[kolaente]

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.

[lafriks]

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

[tomposmiko]

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.

[kolaente]

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:

[alexandr85]

UP

[rudineirk]

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

[lunny]

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

[stevegt]

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.)

[NotAFile]

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.

[stevegt]

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.