Proposal: Handling of issue priority? #6711

New Issue

2025-11-02T07:04:27-06:00

GiteaMirror commented

2025-11-02 07:04:27 -06:00

Originally created by @Kreyren on GitHub (Jan 18, 2021).

Proposing to implement issue priority handling such as:

Where the idea is to allow coordination in bigger groups so that instead of communicating about which issue to work on the maintainers could just set issue priority where higher the priority the more attention is the issue going to get.

Currently we can only set issue labels that get out of hand when the repository receives lots of issues per day.

Originally created by @Kreyren on GitHub (Jan 18, 2021). Proposing to implement issue priority handling such as: ![image](https://user-images.githubusercontent.com/11302521/104911175-bdd2cd80-598a-11eb-925b-9ae1068c1c0f.png) Where the idea is to allow coordination in bigger groups so that instead of communicating about which issue to work on the maintainers could just set issue priority where higher the priority the more attention is the issue going to get. Currently we can only set issue labels that get out of hand when the repository receives lots of issues per day.

GiteaMirror added the type/proposal label 2025-11-02 07:04:27 -06:00

GiteaMirror closed this issue

2025-11-02 07:04:27 -06:00

GiteaMirror commented

2025-11-02 07:04:28 -06:00

@delvh commented on GitHub (Jan 18, 2021):

Just wanted to create my own issue, good that I saw this beforehand. I have a few notes here:
I'd say, storing an uint8 should be enough to assign priorities in between, both to disable assigning astronomical priorities like 200000, and to reduce space consumption.

This would allow to sort issues according to their priority (same priority issues should be ordered using the creation time of the issues to encourage solving issues that have been open for a longer time - no one should have to navigate to page 265, just to see the specific issue he is looking for, unless this issue is not prioritized at all, seen from a developers view here, issues that far away are likely forgotten).

Another potential of using this system is that prior to creating a new issue, each user can assess a range of most likely priorities for his would-be issue (I'd say we do not assume that users are idiots), and in this range he can then more quickly navigate, if the issue he is proposing has already been filed, thus avoiding many duplicate issues. (Because to be honest, when opening this issue I myself had no interest to filter through about 30-40 pages of issues to see if it is already opened - thank god this issue was opened 30 Minutes ago).
Using this mechanism, it is likelier that highly requested issues will be quickly implemented.

I'd suggest giving the issue creator the option to specify the priority on issue creation (unless disabled).
Afterwards, the issue creator and system admins/ (collaborators?) should be able to manually change this issues priority.
We could even think of adding the option for users to react with a +1, that automatically increases the priority of the issue by one, automatically making this issue more requested (in that case, we do have to keep the maximum of the chosen datatype in our eyes, as we do not want that priority to be automatically set to the lowest value by data overflow).

Of course, If a user retracts his +1, it should be removed from the priority - two edge cases here:

Don't lower the priority if a issue is at minimal priority (obviously)
Don't lower the priority if it is at maximal priority - we have no idea, if an issue at max priority doesn't have more backers whose vote just couldn't be counted as the maximum was already reached. Also, if a issue is at maximum priority, it would probably be counterproductive to remove it from there just because someone un-"thumb up"-ed it.

One question that should be answered in advance is:
What order should priorities have (is 0 the highest or the lowest priority)?
No matter the answer, if the issue is not initialized, the lowest priority should be assigned to the issue as default (although it might be beneficial not to assign the lowest priority - any suggestions here?).

@delvh commented on GitHub (Jan 18, 2021): Just wanted to create my own issue, good that I saw this beforehand. I have a few notes here: I'd say, storing an `uint8` should be enough to assign priorities in between, both to disable assigning astronomical priorities like 200000, and to reduce space consumption. This would allow to sort issues according to their priority (same priority issues should be ordered using the creation time of the issues to encourage solving issues that have been open for a longer time - no one should have to navigate to page 265, just to see the specific issue he is looking for, unless this issue is not prioritized at all, seen from a developers view here, issues that far away are likely forgotten). Another potential of using this system is that prior to creating a new issue, each user can assess a range of most likely priorities for his would-be issue (I'd say we do not assume that users are idiots), and in this range he can then more quickly navigate, if the issue he is proposing has already been filed, thus avoiding many duplicate issues. (Because to be honest, when opening this issue I myself had no interest to filter through about 30-40 pages of issues to see if it is already opened - thank god this issue was opened 30 Minutes ago). Using this mechanism, it is likelier that highly requested issues will be quickly implemented. I'd suggest giving the issue creator the option to specify the priority on issue creation (unless disabled). Afterwards, the issue creator and system admins/ (collaborators?) should be able to manually change this issues priority. We could even think of adding the option for users to react with a `+1`, that automatically increases the priority of the issue by one, automatically making this issue more requested (in that case, we do have to keep the maximum of the chosen datatype in our eyes, as we do not want that priority to be automatically set to the lowest value by data overflow). Of course, If a user retracts his `+1`, it should be removed from the priority - two edge cases here: 1. Don't lower the priority if a issue is at minimal priority (obviously) 2. Don't lower the priority if it is at maximal priority - we have no idea, if an issue at max priority doesn't have more backers whose vote just couldn't be counted as the maximum was already reached. Also, if a issue is at maximum priority, it would probably be counterproductive to remove it from there just because someone un-"thumb up"-ed it. One question that should be answered in advance is: What order should priorities have (is 0 the highest or the lowest priority)? No matter the answer, if the issue is not initialized, the lowest priority should be assigned to the issue as default (although it might be beneficial not to assign the lowest priority - any suggestions here?).

GiteaMirror commented

2025-11-02 07:04:28 -06:00

@jolheiser commented on GitHub (Jan 18, 2021):

This is fairly duplicate of https://github.com/go-gitea/gitea/issues/2616 and the subsequent PR https://github.com/go-gitea/gitea/pull/4823.
Also somewhat similar to https://github.com/go-gitea/gitea/issues/9401 and PR https://github.com/go-gitea/gitea/pull/11669.

@jolheiser commented on GitHub (Jan 18, 2021): This is fairly duplicate of https://github.com/go-gitea/gitea/issues/2616 and the subsequent PR https://github.com/go-gitea/gitea/pull/4823. Also somewhat similar to https://github.com/go-gitea/gitea/issues/9401 and PR https://github.com/go-gitea/gitea/pull/11669.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#6711