[infra] Fix support tier-1 flow regression

[oliviertassinari]

I have noticed this from #1148. The support flow seems to have had a couple of problems with #985. This PR aims to go after 1.

• 1. https://www.notion.so/mui-org/GitHub-community-issues-PRs-Tier-1-12a84fdf50e44595afc55343dac00fca no longer working, added the status: waiting for maintainer label back in. Similar workflow of the Rust team https://github.com/orgs/community/discussions/139935#discussioncomment-11594872
• 2. Bug reports no longer prompt developers to provide the exact version of their dependencies @mui/envinfo. [envinfo] Ask for output from envinfo in issues material-ui#23881
• 3. Bug reports and issue reports have a redundant H1, e.g. [accordion] <summary> / <details> based implementation #1148
• 4. We no longer have the "Search keywords". Added in [core] Update issue actions & templates mui-x#10375 because it started to be really hard to find duplicate issues
• 5. https://discord.com/channels/1287292451308048406/1287292451308048409 link doesn't work. If we link to Discord, I think [docs] Avoid broken link material-ui#38154 will avoid leaving breadcrumbs of broken links.

On using issue templates (now in Base UI, React, Tailwind CSS) vs. issue forms (Next.js, React Aria). I'm biased for issue forms, since mui/mui-x#2468. But happy either way. It feels like once we become tired of developers opening issues without respecting what we ask for, we will naturally land on issue forms.

[flaviendelangle]

We no longer have the "Search keywords". Added in mui/mui-x#10375 because it started to be really hard to find duplicate issues

I suspect it has been removed after https://mui-org.slack.com/archives/C02P87NQLJC/p1733997960666959

[mui-bot]

Netlify deploy preview

https://deploy-preview-1149--base-ui.netlify.app/

Generated by 🚫 dangerJS against 5851c67

[michelengelen]

Why have the labels been removed in the first place? And shouldn't we also add the default labels, like bug, feature to the respective templates as well? 🤔

[michelengelen]

Suggested change

	labels: ['status: waiting for maintainer']
	labels: ['status: waiting for maintainer', 'bug 🐛']

[michelengelen]

Suggested change

	labels: ['status: waiting for maintainer']
	labels: ['status: waiting for maintainer', 'new feature']

[michelengelen]

Suggested change

	labels: ['status: waiting for maintainer']
	labels: ['status: waiting for maintainer', 'support: question']

[michelengelen]

Suggested change

	labels: ['status: waiting for maintainer']
	labels: ['status: waiting for maintainer', 'support: docs-feedback']

[oliviertassinari]

Shouldn't we also add the default labels, like bug, feature to the respective templates as well? 🤔

@michelengelen Only MUI X repository has them so far.

Per mui/mui-x#13954 (comment), I don't know. We want to be able to trust that the labels are accurate (for analytics, etc. use cases), but these two things are not the same thing:

• A user added the label, and the maintainer made the effort to check and correct the labels. (I would maybe trust at 50%)
• There is nothing, a maintainer made the effort to add the right labels. (I would maybe trust at 90%)

So overall, I would see the right move as (#recommendation):

• no labels by default, revert [infra] Issue template improvement mui-x#13954
• enforce status: waiting for maintainer as long as the right labels aren't applied: [support-infra] Create GitHub action to force issues & PRs labeling mui-public#206

Now, happy either way, the goal being to:

1. Can we have the equivalent for issues: https://www.notion.so/mui-org/KPIs-Product-165cbfe7b66080ddb7a3f306759f1b9a?pvs=4#165cbfe7b6608020b420c0d295f65d32. So we can make roadmap decision on, we need to fix more bug, regression, etc. based on product feedback.
2. We can more rapidly find duplicate work and connect the dots (when you have 10,000 issues, which if Base UI becomes a success would 99% likely have, e.g. an autocomplete would already give us 3,000 issues https://github.com/JedWatson/react-select/issues?q=is%3Aissue+is%3Aclosed, a dialog, a carousel 5,000 issues https://github.com/nolimits4web/swiper/issues?q=is%3Aissue+is%3Aclosed, etc.)
3. Balance 1. with having maintainers spending as little time as really needed labeling issues.

[michelengelen]

• A user added the label, and the maintainer made the effort to check and correct the labels. (I would maybe trust at 50%)

Users are not allowed to add labels to issues, so all labels are from maintainers. I guess this is to make sure that the labels are in fact accurate to a certain degree.

• There is nothing, a maintainer made the effort to add the right labels. (I would maybe trust at 90%)

So overall, I would see the right move as (#recommendation):

• no labels by default, revert [infra] Issue template improvement mui-x#13954

We can do that ... i just wanted to reduce the friction on initial triage a bit.

• enforce status: waiting for maintainer as long as the right labels aren't applied: [support-infra] Create GitHub action to force issues & PRs labeling mui-public#206

This is potentially hard to do right. We can use the approach outlined in the linked issue, but the accuracy of the assigned labels might still be off. Thinking about this it could decrease friction as well, so maybe worth a shot, no?

On the other hand this would potentially already cut into the same corner, so the "right" action could be removing the initial labels ('bug', etc.) from the issue template and replace this with the mentioned GH action.

[colmtuite]

The problem with default labels is that users will often open an issue via the incorrect template. Happy to add the "waiting for maintainer" label.