[core] Add RFC GH issue template

[bytasv]

• I have followed (at least) the PR section of the contributing guide.

Added an RFC template to GH issues

This is how it looks like: https://github.com/mui/mui-toolpad/issues/new?assignees=&labels=RFC&template=3.rfc.yml&title=%5BRFC%5D+

Same as mui/mui-x#5739 and mui/toolpad#729

[mui-bot]

No bundle size changes

Generated by 🚫 dangerJS against 4b1e9a7

[mnajdova]

Thanks for adding this @bytasv

@michaldudak @siriwatknp please have a look and let us know if you would change something?

[michaldudak]

👍 looks good. I'm not sure about the requirements section, though - what would I enter here?

[bytasv]

👍 looks good. I'm not sure about the requirements section, though - what would I enter here?

@michaldudak let's assume we wanna create an RFC - "Alternative CI runner" - in the requirements we may list all the things we currently support, i.e.:

• supports YML configuration
• reports status back to github
• runs at least at the same speed or faster than current choice
  and so on...

I guess there might also be cases when we might not know all the requirements right at the beginning so we could modify the list as we go

[oliviertassinari]

• a. What are the implications for https://github.com/mui/material-ui/discussions/categories/rfc? I recall we were initially on GitHub issues but then moved to the discussion after [RFC] Migrate to styled-components #6115 because a single thread makes it hard to have multiple people commenting. On Notion, the multiple comments feature reproduces the same feature as GitHub discussions.
• b. Would having a separate repository like https://github.com/reactjs/rfcs so the community can filter out notifications make sense? So far we have assumed that: no.

[bytasv]

Would having a separate repository like https://github.com/reactjs/rfcs so the community can filter out notifications make sense? So far we have assumed that: no.

IMO that might introduce unwanted overhead. It does seem to add value because they do RFCs as markdown files

[mnajdova]

What are the implications for https://github.com/mui/material-ui/discussions/categories/rfc? I recall we were initially on GitHub issues but then moved to the discussion after #6115 because a single thread makes it hard to have multiple people commenting.

Here are some worries I have regarding this:

• discoverability/searchability
• cannot be closed with PR, we need to make sure we manually update it
• as far as I know discussion can be just deleted not closed (I may be wrong in this assumption)

[oliviertassinari]

Alright, then no objections to closing https://github.com/mui/material-ui/discussions/categories/rfc and migrating them as issues if we move forward with this PR.

I wonder though how the community will manage to find new RFCs without the GitHub discussions 😁. The RFC label feels like a must-have. I wish community/community#16645 was a thing, until then, I guess we will have to train them to check this label from time to time.

[mnajdova]

I guess we will have to train them to check this label from time to time.

I would assume this is what most of the community is already doing, but we can double check by asking on Twitter if we have a doubt about this :) cc @samuelsycamore

Also, we can always pin the most important RFCs on top :)

[mapache-salvaje]

Looks good! I've just made some suggestions to tighten up the grammar and make it a little more concise.

[oliviertassinari]

We could consider this as part of the problem statement that is above. At least, it's how it's currently done inside https://www.notion.so/mui-org/Shaping-33647d13ed534b838bde5bc8182eba18 (on this one, the idea was to have the template as open ended as possible).

[bytasv]

I'd need to pull in the exact conversation but when we discussed this it was more about listing requirements in it's explicit section. For shaping items it might be less important, but since it's code related your might have certain constraints that you wanna list more often then not.
We could embed this into "problem statement" but I find having it in separate section is easier to find just by scanning 🤔

[oliviertassinari]

but since it's code related your might have certain constraints that you wanna list more often then not.

I think it's similar for non-code-related topics, e.g. https://www.notion.so/mui-org/Scale-collaborative-inbox-in-Google-Groups-f6f3d7a8a6bd4c24be1fc8b13a8f33f6#7d75b82e0525464c999d5bde5de6a6c2.

[bytasv]

It is indeed similar to what you show - but how would we formulate this explicitly in the problem statement? Do we expect that everyone will implicitly understand to list the requirements?
Should it simply just be "Requirements" subsection under problem statement?

[oliviertassinari]

Should it simply just be "Requirements" subsection under problem statement?

It was what I was wondering about, maybe an opportunity to make the RFC template simpler 🤷‍♂️, e.g. https://github.com/reactjs/rfcs/blob/main/0000-template.md has no notions of requirements. But no real preferences.

[bytasv]

@samuelsycamore thanks for great feedback, I've removed duplication and applied your suggestions, it's ready for re-review 🙇

[mapache-salvaje]

Text looks great! 👍

[oliviertassinari]

What are the implications for https://github.com/mui/material-ui/discussions/categories/rfc?

Are we settling on dropping the use of the GitHub discussions for RFCs?
Or would it work if GitHub discussions are reserved for RFCs we expect a LOT of feedback from the community? So only a handful every year. I feel that for up to 25 comments, a linear history is better, but beyond threads help. In the future, we might even be able to use community/community#2838.

[mnajdova]

Are we settling on dropping the use of the GitHub discussions for RFCs?
Or would it work if GitHub discussions are reserved for RFCs we expect a LOT of feedback from the community?

I would propose we use discussion for sharing ideas we could implement when they are not quite in a form of an RFC. Then we can drop them or create RFC issues for them. For things that we can create RFC directly we should use issues

[oliviertassinari]

@mnajdova Ok, I have made a first iteration on how we use RFCs at MUI in https://www.notion.so/mui-org/GitHub-issues-Product-backlog-c1d7072e0c2545b0beb43b115f6030f6#807f7e11ab87450faddf2c43baf14205 based on this.

Feedback welcome.

@bytasv What do think about updating https://github.com/mui/mui-x and https://github.com/mui/mui-toolpad to match line per line of the RFC template in this repository?

So far, we have used http://github.com/mui/material-ui as the source of truth for most things. Why? Because it's where we have the most demanding environment, where we get the most feedback on how things work in practice (in mui-x and mui-toolpad it usually takes a lot more time to get a correct feedback loop because of the much smaller community, the community is we ultimately optimize for). The second value is that it forces us to pick better options, to take into account more perspectives (X and Toolpad's one).