[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. https://github.com/mui/material-ui/pull/23881
3. Bug reports and issue reports have a redundant H1, e.g. https://github.com/mui/base-ui/issues/1148
4. We no longer have the "Search keywords". Added in https://github.com/mui/mui-x/pull/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 https://github.com/mui/material-ui/pull/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 https://github.com/mui/mui-x/pull/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 https://github.com/mui/mui-x/pull/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 :no_entry_sign: dangerJS against 5851c67502903cd9e69f9d291e9f3447749d4205

[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 https://github.com/mui/mui-x/pull/13954#discussion_r1704666868, 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 https://github.com/mui/mui-x/pull/13954
• enforce status: waiting for maintainer as long as the right labels aren't applied: https://github.com/mui/mui-public/issues/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.

[oliviertassinari]

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 https://github.com/mui/mui-x/pull/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.

Today I learned something new about this. "issue templates" are now flagged as legacy Source

So no real implications for us anytime soon, only to be mindful that GitHub is on a path to eventually remove this.

[netlify[bot]]

✅ Deploy Preview for base-ui ready!

Name	Link
🔨 Latest commit	c13c624bb3fa62488ced67fa4a7468226ddd0eb4
🔍 Latest deploy log	https://app.netlify.com/sites/base-ui/deploys/67a0c41beec12a000847d194
😎 Deploy Preview	https://deploy-preview-1149--base-ui.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.