[docs] Clarify the difference between React and UI components

[oliviertassinari]

Should an issue/PR that touches on the <TreeItem> React component have the component: TreeView GitHub label?

While I believe the answer should be yes, so we can have sub-product owners that can monitor the labels they care about, I believe the label casing, colors, descriptions were not making it clear. This change is meant to solve this confusion. Now, we have:

• GitHub labels that are about UI components. They could include Joy, Material Design, Unstyled, etc. The important part here is that no matter how it's implemented, the end-user experience is what ultimately matters the most (see the survey where people ranked "look & feel" as the number one criteria for picking a UI library). Therefore, I think that we should organize ourselves around it.

  Before
  

  After
  

• GitHub labels that are about technical components (React) now have a slightly different description:

  Before
  

  After
  

I hope this proposal makes it clearer.

[mui-pr-bot]

No bundle size changes

Generated by 🚫 dangerJS against 0f996c1

[mnajdova]

If the issue is about the TreeItem component does that mean that we need to label it with: component: tree view and component: TreeItem, or only the first?

[oliviertassinari]

If the issue is about the TreeItem component does that mean that we need to label it with: component: tree view and component: TreeItem, or only the first?

@mnajdova I think that the component: tree view label is what would matter the most. The community can then use it to find all the work history on the tree view. The maintainers owning this component can use it to drive all the ongoing effort.

As for adding the component: TreeItem GitHub label, I personally can't think of a use case for it. Do you have one in mind?

Actually, this makes me think of another topic. I believe the in the issue/PR titles [label] Description, what we currently do is put in the label is either be the name of the JS module (e.g. [TreeItem] Fix text selection), or the most important GitHub label (e.g. [tree view] Fix text selection). Usually, what I have noticed we do, is put the JS module when possible, or the GitHub label when it touches multiple JS modules, like <TreeItem> and <TreeView> at the same time.

[siriwatknp]

I hope there is no impact on the existing labeled issues. No objection from my side.

[oliviertassinari]

I hope there is no impact on the existing labeled issues.

@siriwatknp None I'm aware of.

[hbjORbj]

No objection from my side as well.

[mnajdova]

👍 for issues
👍 for using the JS module on PRs (it's more descriptive related to the changes)

[mnajdova]

Probably needs to be updated once more before merging

[m4theushw]

We had a small discussion about this in mui/mui-x#3312 (comment). Basically, in MUI X we were using the component name for things that users can perceive and "core" for internal stuff of the component. Removing the concept of the component name and using the sub-product name makes more sense and scalable.

Actually, this makes me think of another topic. I believe the in the issue/PR titles [label] Description, what we currently do is put in the label is either be the name of the JS module (e.g. [TreeItem] Fix text selection), or the most important GitHub label (e.g. [tree view] Fix text selection). Usually, what I have noticed we do, is put the JS module when possible, or the GitHub label when it touches multiple JS modules, like and at the same time.

With the new label, does it mean that the title of an issue touching several parts of the TreeView will be prefixed with [tree view]?

[mnajdova]

With the new label, does it mean that the title of an issue touching several parts of the TreeView will be prefixed with [tree view]?

As far as I understood not, it should be the JS module, so [TreeView] I suppose,

[mui-bot]

No bundle size changes

Generated by 🚫 dangerJS against 7e8542c