Skip to content
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

Proposal: Handling of issue priority? #14377

Closed
Kreyren opened this issue Jan 18, 2021 · 2 comments
Closed

Proposal: Handling of issue priority? #14377

Kreyren opened this issue Jan 18, 2021 · 2 comments
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@Kreyren
Copy link
Contributor

Kreyren commented Jan 18, 2021

Proposing to implement issue priority handling such as:

image

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.

@noerw noerw added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Jan 18, 2021
@delvh
Copy link
Member

delvh commented 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?).

@jolheiser
Copy link
Member

This is fairly duplicate of #2616 and the subsequent PR #4823.
Also somewhat similar to #9401 and PR #11669.

@go-gitea go-gitea locked and limited conversation to collaborators Mar 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

No branches or pull requests

4 participants