-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prioritize issues #2616
Comments
Aren't labels enough? |
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. |
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 |
How can I second this? |
Found an interesting thing in Apparantly it was Unknown (
This means we could somehow add this with not too much effort 🤔 |
This comment has been minimized.
This comment has been minimized.
@rudineirk It seems that's another idea. Both two features maybe could be implemented. |
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 #2222 (comment) and see if we can reach some sort of consensus on how this should work.) |
) Prepare for Prioritize issues & update .gitignore for goland users. Target on the [Issue](go-gitea/gitea#2616) Signed-off-by: BetaCat0 <outman99@hotmail.com>
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. |
- run at your own risk -- has not been extensively tested, and has only been run manually from a command-line so far - current version generates a report that it stores in a persistent issue that we manage and update on each run - go-gitea/gitea#2616 would enable putting output into a db column instead
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. |
Any new on this? It would be much appreciated! |
I'm slowly working on it #11669 |
the kanban boards can be used to order issues |
To quote @lunny in #2175:
The text was updated successfully, but these errors were encountered: