-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
Label grouping #32762
base: main
Are you sure you want to change the base?
Label grouping #32762
Conversation
I just want to make one point. after this change, if organization has same label with repo, i will not be able to know which label is repo's label. currect order is repo labels then org labels, so i can know. i am not sure if this is a problem or not. Edit: Issue List still old order: This is what i mean: |
Yes! There's already an issue: #31898 |
Does it matter to user which labels are org and repo? Also, how duplicate labels are practically used? |
After reconsidered about this issue, I think we need to avoid creating duplicate labels, as this doesn't make sense. |
As I said, this should be human's job. Gitea only needs to display labels and it's groups right |
As original author I got pinged in #10814 (comment) for opinion. The claims of:
Really aren't true at all. The fact that they are separated is intentional and is what considers the issue of duplicate labels. The fact that this PR would re-introduces those issues suggests that maybe they weren't fully considered or understood here. As for the question of how "duplicate" labels are used, the main case was existing labels. Imagine you had 100 repos in an org that each had their own And then again, you'd need to change them a second time to the org label if you wanted to start using that. The current design allowed people to start using org labels without changing anything that was already there. People could optionally move to org labels if they wanted to at whatever pace. There is some merit to not allowing duplicate labels, but the opinion was it didn't outweigh the flexibility of allowing them for a brand new feature. Of course org label support was also added to the Gitea API at the time so any advanced user could automate most of that and wasn't stuck actually changing 100 labels by hand if they wanted to switch to a new org wide label. Smaller reasons included that some people want to have their repos bugs show up in a org wide So not saying the current design is perfect, but it was all intentional and considered. |
Labels are being passed to front-end dropdown as single list, meaning there was no intention to "group" or divide labels by org defined and repo defined.
In the UX it's looking weird why labels with same prefix are not grouped. This issue fixes that.
Screenshots
before
after