Skip to content

(RFC) Draft initial RFC guidance #868

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

michaeltlombardi
Copy link
Collaborator

PR Summary

This change adds the .rfc folder to the project with draft documentation for the RFC process, an RFC template, and scaffolded folders for accepted RFCs (.rfc/draft) implemented RFCs (.rfc/final).

PR Context

Drafting an RFC process to address growing need for more in-depth design documents/discussion than we can review in issues or discussions alone.

This change adds the `.rfc` folder to the project with draft documentation
for the RFC process, an RFC template, and scaffolded folders for accepted
RFCs (`.rfc/draft`) implemented RFCs (`.rfc/final`).

- **Author**: All members of the community are allowed to author new RFCs and can provide feedback
to any RFC.
- **DSC Committee**: The design committe that votes to accept or reject an RFC. Currently, the DSC
Copy link
Member

Choose a reason for hiding this comment

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

Since DSC team members are also members of the DSC WG, I wonder if we need to have a Committee above it

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'm in favor of streamlining this to only including the working group for the time being - if we need to add a higher layer later, we can always amend the process for that.


When submitting an RFC, the Author shall:

- Create a file named `RFCNNNN-<Title>.md` in the `.rfc/drafts` folder.
Copy link
Member

Choose a reason for hiding this comment

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

Is there a reason to use .rfc instead of just RFC? I don't see a need for it to be hidden?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Habitual on my part - rfc/ works just as well.

becomes harder to change at the risk of compatibility.

This process was adapted from the PowerShell RFC process, which itself was adapted from the Chef
RFC process and the DMTF.org process.
Copy link
Member

Choose a reason for hiding this comment

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

Since we don't want/need to have all the docs from the PowerShell repo, we can probably just link to relavent docs in the PS repo as applicable here. For example, I would still prefer community members to start with an issue/discussion instead of spending time on an RFC. This is somewhat covered below in the roles, but I'd rather put it up front so we don't suddenly get a bunch of RFC PRs.

After the author marks their PR as ready for review, the RFC moves into the formal review state.
The RFC remains in this state until one of the following conditions is met:

- The Committee decides to reject the RFC, changing the state to [Rrejected](#rejected).
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
- The Committee decides to reject the RFC, changing the state to [Rrejected](#rejected).
- The Committee decides to reject the RFC, changing the state to [Rejected](#rejected).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants