[docs] Add RFC GH issue template

[bytasv]

• [x] 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+

[mui-bot]

No bundle size changes

Generated by :no_entry_sign: dangerJS against 4b1e9a777c37e93fa5c5d44c30fa90cb999898af

[michaldudak]

:+1: 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 https://github.com/mui/material-ui/issues/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 https://github.com/mui/material-ui/issues/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 https://github.com/community/community/discussions/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 :)

[bytasv]

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

[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 https://github.com/community/community/discussions/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).