Stop auto labelers because there are too many inacculate behaviours to make confusing

[lunny]

It's very difficult to get to know the aim of PR creator according changed files. A file maybe changed project files but the PR maybe a bugfix/a refactor/a comment added and etc.

Revert #26962

[silverwind]

If our intend is to capture PR intend in the labels, then yes I agree, the labeler is unsuited.

[silverwind]

Labeler is only suitable for "subsystem" style labels, like ui or build. Maybe keep those uncontested cases?

[silverwind]

Overall I think the labeler is more beneficial than it hurts. Take a look at recent PRs, they do have good labels.

Maybe we should disable the sync-labels option so that it never removes labels? I think some of the issues come from this option.

[lunny]

i.e. The auto labelers for #23894 is totally wrong and annoying. And I also encounter many times like this.

[silverwind]

It correctly labeled what we told it to. Big refactors like that are likely to trigger many labels. I think we should probably just remove these labels from the config: theme/package-registry, kind/api, kind/cli, kind/lint and set sync-labels: false.

[wxiaoguang]

It's a kind of laziness to let a bot process the unclear labels.

I do not think the labeler is really useful at the moment. The mergers should should pay enough attention to the PR itself (title, description, code change) and the labels, instead of just clicking the "merge" button.

And the label system is not well-designed, for example: what is kind/ui kind/ux kind/usability javascript?

When there is a problem, it's not right to say "oh, just add a bot to deal with it, nobody would really spend time on it".

[wxiaoguang]

If anyone really spent time on the label system, really ever maintained the labels, and then introduce the labeler carefully, then I could agree with them.

[silverwind]

I can guarantee that if we remove the labeler, many PRs will merge unlabeled because many do not care about those labels in reality. I'm fine with merging unlabeled PRs too, I don't need them. But the changelog tool might.

Another option might be to require a prefix on commit message to categorize the PRs and remove most if not all of the labels.

[wxiaoguang]

I can guarantee that if we remove the labeler, many PRs will merge unlabeled because many do not care about those labels in reality.

Default/no-op is better than wrong.

But the changelog tool might.

I can understand such requirement. IMO the solution for such "label problem" should start from the changelog tool.

Define which kinds of labels are really needed and necessary first, maintain the current labels, remove dead ones, clarify how to use the labels correctly, then fine tune the labeler bot.

[wxiaoguang]

Another option might be to require a prefix on commit message to categorize the PRs and remove most if not all of the labels.

That's somewhat related. One of the problems is that the "changelog" rules are not clear. For example, why there is a separate "API" section? A change should be either a feature/enhancement/bugfix/.../misc. If a PR does a bugfix(enhancment) for both web and api, why it should appear in the API section?

The historical unclear rules are the root problem.

[silverwind]

I wouldn't mind if we just set a optional single category label manually like feature,enhancement,fix,refactor.

If we retain subsystem labels like ui, those should stay in the labeler imho.

[denyskon]

I agree that we need to rework our label system before we start applying labels automatically.

I would suggest:

1. split PR and issue labels
2. for issues, keep it simple and only separate by kind (proposal, bugreport, question, misc) and status (needs feedback, confirmed, in implementation)
3. decide what PR labels are for (which information are they supposed to provide?)
   I can think of the following categories:

• section - which part(s) of the codebase does it affect: templates, web_src, backend, api
• kind - what does this PR do: feature, bugfix, enhancement, refactoring, docs
• topic - which functionality does it affect: package-registry, administration, actions, wiki, issues, repos, authentication, ui
• review status: wip, blocked, ready to merge, in review, pending, urgent
• MAYBE complexity, but not according to the useless size bot but according to the author

I think that would make labels more logical and useful for everyone. And the section part is the only one we can automatically apply according to the files changed.

[silverwind]

Alternative PR: #27502

[silverwind]

#27502 was merged, pending further adjustments.