Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[core] Add RFC GH issue template #33871

Merged
merged 10 commits into from Sep 9, 2022
47 changes: 47 additions & 0 deletions .github/ISSUE_TEMPLATE/3.rfc.yml
@@ -0,0 +1,47 @@
name: RFC 💬
description: Request for comments for your proposal.
title: "[RFC] "
labels: ['RFC']
body:
- type: markdown
attributes:
value: |
Please provide a searchable summary of the RFC in the title above ⬆️.
bytasv marked this conversation as resolved.
Show resolved Hide resolved

Thanks for contributing by creating an RFC! ❤️
- type: textarea
attributes:
label: What's the problem? 🤔
description: A short paragraph or bullet list that quickly explains what you're trying to do, what value do we expect to get or any other relevant information to understand motivation behind this RFC
bytasv marked this conversation as resolved.
Show resolved Hide resolved

- type: textarea
attributes:
label: What are the requirements? ❓
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 🤔

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

description: Provide a list of requirements that should be met by the accepted proposal
bytasv marked this conversation as resolved.
Show resolved Hide resolved

- type: textarea
attributes:
label: What are our options? 💡
description: |
Have you considered all options that we can achieve same/similar thing? It doesn't have to be explored in same detail as the main proposal, but having alternative options that you can present can help strengthen main proposal.
bytasv marked this conversation as resolved.
Show resolved Hide resolved

Consider:
- using diagrams to help illustrate your ideas
- including code examples if you're proposing an interface or system contract
- linking to project briefs or wireframes that are relevant
bytasv marked this conversation as resolved.
Show resolved Hide resolved
oliviertassinari marked this conversation as resolved.
Show resolved Hide resolved

- type: textarea
attributes:
label: Proposed solution 🟢
description: |
This is the core of RFC, and its purpose is to clearly explain reasoning for the proposed solution, why it's better compared to the other options or why should it be chosen instead.
bytasv marked this conversation as resolved.
Show resolved Hide resolved

Consider:
- using diagrams to help illustrate your ideas
- including code examples if you're proposing an interface or system contract
- linking to project briefs or wireframes that are relevant
bytasv marked this conversation as resolved.
Show resolved Hide resolved

- type: textarea
attributes:
label: Relevant resources/benchmarks 🔗
bytasv marked this conversation as resolved.
Show resolved Hide resolved
description: Attach any issues, PRs, links, documents, etc… that might be relevant to the RFC