[support-infra] Fix typeLabels

[oliviertassinari]

What seems right to define as type: https://www.notion.so/mui-org/Pull-request-types-1abcbfe7b66080f4a5a6e593e0a90ce4. It's about the nature of the work: is it's a bug or a new feature? Enhancement is for when we can't decide. So use type to know if we are going in depth or in breadth?

• docs: it's not a type with the definition above.
• regression: it's a sub-type of bug, I have been systematically been adding both bug and regression so far, maybe that wrong 🤔
• maintenance: this look like a duplicate label of "core", but I also don't think it's a type. Looking at https://github.com/mui/mui-x/pulls?q=is%3Apr+label%3Amaintenance+is%3Aclosed, it feels like we should delete this GitHub tag, there are already better labels to use.

[michelengelen]

What seems right to define as type: https://www.notion.so/mui-org/Pull-request-types-1abcbfe7b66080f4a5a6e593e0a90ce4. It's about the nature of the work: is it's a bug or a new feature? Enhancement is for when we can't decide. So use type to know if we are going in depth or in breadth?

• docs: it's not a type with the definition above.

yes, by definition this is not really a type... i intentionally built the way around docs as part of this (actually ignoring all other labels) because we had a discussion around this on slack. If we do not consider this a type anymore we would need to enforce other type labels for docs changes, like enhancement or bug. Fine by me, it makes the whole script a bit easier.

• regression: it's a sub-type of bug, I have been systematically been adding both bug and regression so far, maybe that wrong 🤔

this is debatable. IMO regressions are a more severe bug, so we could just handle it this way.

• maintenance: this look like a duplicate label of "core", but I also don't think it's a type. Looking at https://github.com/mui/mui-x/pulls?q=is%3Apr+label%3Amaintenance+is%3Aclosed, it feels like we should delete this GitHub tag, there are already better labels to use.

for me it is not very clear that core is considered some kind of type. I would rather argue that maintenance is a form of enhancement

[oliviertassinari]

If we do not consider this a type anymore we would need to enforce other type labels for docs changes, like enhancement or bug. Fine by me, it makes the whole script a bit easier.

@michelengelen It feels like it's a matter of answering this question: For docs changes, do we want to know if those are bug, regressions, new features, or enhancements?

It feels like it's equally important to know where we invest our resources, so yes? What was the rationale for removing it?

IMO regressions are a more severe bug

Agree, regressions feels a lot more important than bugs. The problem that if we have "regressions" on the list, then the duplicate type logic complains, so we can't both add bugs and regressions on PRs. The rational I used so far to add both is in case people search for "bugs", I would want them to see regressions too 🤔. But, OK, I'm reverting this, it seems like most people only add regression or bug, I'm the only one who add both.

for me it is not very clear that core is considered some kind of type

Agree core is not a "type" label, it's "kind of work" label. For example, I updated the labels on those to what seems to be right:

• [code-infra] Latest vitest picker changes mui-x#17577
• [core] Fix root package 7.29.1 mui-x#17523

[michelengelen]

If we do not consider this a type anymore we would need to enforce other type labels for docs changes, like enhancement or bug. Fine by me, it makes the whole script a bit easier.

It feels like it's a matter of: for docs changes, do we want to know if those are bug, regressions, new features, or enhancements? It feels like it's equally important to know where we invest our resources, so yes?

IMO docs are not a part of a project, but rather a project on its own, so having it as a type label did not make a lot of sense in the first place. I cannot quite remember the rationale behind adding it like this, so I'm happy with removing it and maybe treat it as a form of indication where the work (-type) was spent on. 👍🏼

IMO regressions are a more severe bug

Agree, regressions feels a lot more important than bugs. The problem that if we have "regressions" on the list, then the duplicate type logic complains, so we can't both add bugs and regressions on PRs. The rational I used so far to add both is in case people search for "bugs", I would want them to see regressions too 🤔. But, OK, I'm reverting this, it seems like most people only add regression or bug, I'm the only one who add both.

Seems like it ... although I have seen others add bug and enhancement together, so it is debatable too how much value it brings if we add it singular, or in combination. I like the idea behind the added severity when both labels are present. It makes sense in this regard. IO would just need to update the metric to filter this out, Makes sense to me.

On the other hand: if we have this do we want to enforce one behavior over the other? 🤔

[michelengelen]

Thinking about this we have 2 different kinds of labels we can add:

1. is a type, so when taking the discussion here into consideration the resulting list should be: 'release', 'bug', 'dependencies', 'enhancement', 'new feature'
2. is the area the work took place. This can be a project (some form of component or simply core as a label), docs, tests and (code-/docs-) infra

This workflow only serves the purpose of 1.

[michelengelen]

IMO we can also ditch regression and try to enforce the combination discussed above, but I would be fine with both

[oliviertassinari]

2 different kinds of labels we can add:

Even 3? https://www.notion.so/mui-org/GitHub-issues-Product-backlog-c1d7072e0c2545b0beb43b115f6030f6?pvs=4#139cbfe7b66080c69573d56038aefe62

[oliviertassinari]

Alright, let's try this; this should be pretty clean in practice.