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

Label grouping #32762

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

stuzer05
Copy link
Contributor

@stuzer05 stuzer05 commented Dec 8, 2024

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
image
after
image

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Dec 8, 2024
@pull-request-size pull-request-size bot added the size/S Denotes a PR that changes 10-29 lines, ignoring generated files. label Dec 8, 2024
@github-actions github-actions bot added modifies/go Pull requests that update Go code modifies/templates This PR modifies the template files labels Dec 8, 2024
@GiteaBot GiteaBot added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels Dec 8, 2024
@metiftikci
Copy link
Contributor

metiftikci commented Dec 8, 2024

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.

⚠️ The real problem is: This is gonna break exclusive labels

Edit:

Issue List still old order:

image

This is what i mean:

image

This was referenced Dec 9, 2024
@yp05327
Copy link
Contributor

yp05327 commented Dec 9, 2024

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.

Yes! There's already an issue: #31898

@stuzer05
Copy link
Contributor Author

stuzer05 commented Dec 9, 2024

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.

Does it matter to user which labels are org and repo? Also, how duplicate labels are practically used?

@yp05327
Copy link
Contributor

yp05327 commented Dec 9, 2024

After reconsidered about this issue, I think we need to avoid creating duplicate labels, as this doesn't make sense.
I guess the implementation of org labels was just copy-paste, didn't consider about the duplicate labels.

@stuzer05
Copy link
Contributor Author

stuzer05 commented Dec 9, 2024

After reconsidered about this issue, I think we need to avoid creating duplicate labels, as this doesn't make sense. I guess the implementation of org labels was just copy-paste, didn't consider about the duplicate labels.

As I said, this should be human's job. Gitea only needs to display labels and it's groups right

@a1012112796
Copy link
Member

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.

maybe we can add a apecial prefix to make the org label be different on ui
image

@stuzer05
Copy link
Contributor Author

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.

maybe we can add a apecial prefix to make the org label be different on ui image

I like this idea! We don't need to change much for this to work

@mrsdizzie
Copy link
Member

As original author I got pinged in #10814 (comment) for opinion. The claims of:

there was no intention to "group" or divide labels by org defined and repo defined.

I guess the implementation of org labels was just copy-paste, didn't consider about the duplicate labels.

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 kind/bug label and you can't even create a new org wide kind/bug label until you go through and change all of those to some other text.

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 kind/bug search and others don't. Some people want to have different colors and don't care about using the org wide repos.

So not saying the current design is perfect, but it was all intentional and considered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lgtm/need 1 This PR needs approval from one additional maintainer to be merged. modifies/go Pull requests that update Go code modifies/templates This PR modifies the template files size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants