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
42 changes: 42 additions & 0 deletions .github/ISSUE_TEMPLATE/3.rfc.yml
@@ -0,0 +1,42 @@
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. ⬆️

Thanks for contributing by creating an RFC! ❤️
- type: textarea
attributes:
label: What's the problem? 🤔
description: Write a short paragraph or bulleted list to briefly explain what you're trying to do, what outcomes you're aiming for, and any other relevant details to help us understand the motivation behind this RFC.

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

- type: textarea
attributes:
label: What are our options? 💡
description: |
Have you considered alternative options for achieving your desired outcome? It's not necessary to go into too much detail here, but it can help strengthen your main proposal.

- type: textarea
attributes:
label: Proposed solution 🟢
description: |
This is the core of the RFC. Please clearly explain the reasoning behind your proposed solution, including why it would be preferred over possible alternatives.

Consider:
- using diagrams to help illustrate your ideas
- including code examples if you're proposing an interface or system contract
- linking to relevant project briefs or wireframes

- type: textarea
attributes:
label: Resources and benchmarks 🔗
description: Attach any issues, PRs, links, documents, etc… that might be relevant to the RFC