rfc: RFC

[alanshaw]

📖 Preview

An RFC to request comment on proposed customs and practices fo RFCs. This was adapted from a recent revamp of the RFC process in Storacha storacha/RFC#71 and includes feedback that didn't make it int o the final version (templates, sign off procedure).

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds an initial “RFC for RFCs” to define how this repo uses RFCs and updates the root README to point contributors at the process.

Changes:

• Added rfcs/000-rfc.md describing RFC purpose, statuses, templates, and PR-based workflow/signoff.
• Updated README.md with a short repo description and “how to request comment” steps.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 7 comments.

File	Description
rfcs/000-rfc.md	Introduces the canonical RFC process doc (statuses, templates, review workflow).
README.md	Documents the repo purpose and links to the RFC process entrypoint.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Grammar issue: this sentence is ungrammatical and reads like it has an extra “is”. Consider rewriting to something like “This repository is a place for having structured feedback loops on work-related subjects.”

Suggested change

	This is repository is place for having structured feedback loops on various work related subjects.
	This repository is a place for having structured feedback loops on various work-related subjects.

[Copilot]

This relative link looks incorrect given the RFC file added in this PR is rfcs/000-rfc.md. Update the link target to the correct path so the README doesn’t 404.

[Copilot]

The PR description’s preview link points to docs/rfc-rfc/000-rfc.md, but the actual added document is rfcs/000-rfc.md. Please align the documented/advertised location (either move the file or update the preview/link references) to avoid confusion.

[Copilot]

Minor grammar: “courses of actions” should be “courses of action”.

Suggested change

	1) Building consensus on courses of actions that could face blocking issues from other team members.
	1) Building consensus on courses of action that could face blocking issues from other team members.

[Copilot]

Typo: “sheparding” should be “shepherding”.

Suggested change

	The first stage of our standards process. All team protocols intended to serve as externally facing standards start here. Moving an RFC into "Proposed Standard" suggests we would like third parties to engage and potentially implement the RFC and represents a commitment on our part to sheparding this process.
	The first stage of our standards process. All team protocols intended to serve as externally facing standards start here. Moving an RFC into "Proposed Standard" suggests we would like third parties to engage and potentially implement the RFC and represents a commitment on our part to shepherding this process.

[Copilot]

These two statements conflict: earlier the doc says RFCs “can and should change status over time” (e.g., Informational → Experimental), but later it restricts permissible status changes to only Proposed Standard → Standard and anything → Historical. Please reconcile the policy (either broaden the allowed transitions, or remove/update the earlier claim). Also, <anything> will be parsed as an HTML tag in Markdown; use code formatting (e.g., backticks) or escape the angle brackets so it renders correctly.

[Copilot]

These two statements conflict: earlier the doc says RFCs “can and should change status over time” (e.g., Informational → Experimental), but later it restricts permissible status changes to only Proposed Standard → Standard and anything → Historical. Please reconcile the policy (either broaden the allowed transitions, or remove/update the earlier claim). Also, <anything> will be parsed as an HTML tag in Markdown; use code formatting (e.g., backticks) or escape the angle brackets so it renders correctly.

Suggested change

* The only permissible status changes are `Proposed Standard` → `Standard` and `<anything>` → `Historical`. This does not involve changing the body of the RFC, only the status (but small exceptions are acceptable if agreed in the PR). Otherwise, a new RFC is created rather than the existing one being updated.

* Permissible status changes include reclassifying an RFC to reflect its maturity or current role over time—for example, `Informational` → `Experimental`, `Proposed Standard` → `Standard`, and `anything` → `Historical`. These changes ordinarily do not involve changing the body of the RFC, only the status (but small exceptions are acceptable if agreed in the PR). Otherwise, a new RFC is created rather than the existing one being updated.

[frrist]

This RFC RFC is based heavily on a prior storacha/RFC#71 by Travis Vachon.

👍 LGTM

[bajtos]

I find the proposed process a bit too heavy; I prefer a more lightweight setup that gives more freedom to RFC authors.

Having said that, I don't have experience with working in RFC-heavy projects. It's possible the structure & process described here are needed to avoid pitfalls I am not aware of.

[bajtos]

This feels like a lot of complexity we may not need. What was your experience in DAG House and Storacha - did the team find these different status values useful, and were all of these statuses used frequently?

I propose removing the Status field from the first version of the RFC process and introducing it later, once we need it.

Thoughts?

[Peeja]

I think some status is important, but we can probably simplify it a lot. How about:

• Experimental
• Standard
• Historical

Here's what I'm thinking:

• Informational isn't really a thing. In the IETF world, there are a huge number of people who need a centralized place to communicate some basic information sometimes. We already have places for that kind of shared context. We don't really need to "inform" each other this way. We could conceivably want to inform the larger community of technical stuff this way, but I think that's unlikely, and we can always add this back if we think it would be useful.
• Experimental, though, is a thing. This is the status for research and experimentation. When we prototype and benchmark something, this is where that report goes.
• Best Practice is something we certainly want to track, but I don't think this is the place for it. This is supposed to be for documenting and informing people of existing practices, and that feels pretty niche for our workflow.
• The Standards Track is a product of the mechanics of the IETF RFC system. We, meanwhile, have git and GitHub. I don't think we get much value out of merging things in a proposed state, confirming that they are, in fact, proposed. I think we're better off using open Standard PRs as proposals, and merged Standard PRs as confirmed standards.
• Historical is good to have, or something in its place. Sometimes and eventually, we'll have standards that are deprecated and superseded. We need some way to document that fact.

All that said, "Standard" vs "Historical" feels like an actual status change, while "Experimental" is a separate category. Maybe we don't call this "status" at all, but "category". Or maybe experimentation goes somewhere else entirely. We need something that tracks whether a standard is still current, but that might be it.

[bajtos]

I love your very thoughtful comment, @Peeja!

I like the direction you proposed - simplify to three values only: Experimental/Standard/Historical.

[bajtos]

Let's include "Last Modified" date in all templates, please. This way, this information is preserved even when the doc is exported from Git.

[Peeja]

Important question: Should these ever be modified, or only superseded by additional RFCs?

[bajtos]

Important question: Should these ever be modified, or only superseded by additional RFCs?

💯

I am fine either way. Let's make sure the process is documented.

[alanshaw]

I think it's fine to modify these. Part of the reason we have them in git is so we can look in history.

I'd prefer to not include a field that humans are likely to forget to update. Also, the last modified date is in git history so unnecessary.

[bajtos]

I see your point. Playing the devil's advocate: If we want to use git to look up metadata, then why don't we use Git to store the authorship info as well? 😉

Anyhow, I am fine with your decision. We can easily revisit it later, if there is ever a need.

[alanshaw]

For authors you might want to list multiple, in case of a collaboration and only one of them may have actually submitted the PR.

[bajtos]

Would it be helpful to include "Alternatives Considered" for Implementation RFCs?

[bajtos]

I see there is the "Alternatives considered" section in the template for an Experimental RFC, but it's not here in the template for Standard RFC. Is that intentional?

I like to have that section in all decision record documents, but I am not sure if Standard RFC belogs to that category.

For example, IPFS's IPIP includes "Alternatives considered" in the improvement proposal template but not in the spec template.

Anyhow, I am fine either way, this is easy to change later if needed.

[alanshaw]

Oh, oops yes I will add to both.

[bajtos]

When an RFC is obsoleted, does it keep its status (e.g. Standard)?

[alanshaw]

I find the proposed process a bit too heavy; I prefer a more lightweight setup that gives more freedom to RFC authors.

This is a valid point. I think previously in Storacha the problem was that there was very little structure. Perhaps this has gone too far the other way? Do you have any suggestions for what we could do to lighten the process?

[Peeja]

Comments added in threads, mainly #1 (comment).

[bajtos]

I find the proposed process a bit too heavy; I prefer a more lightweight setup that gives more freedom to RFC authors.

This is a valid point. I think previously in Storacha the problem was that there was very little structure. Perhaps this has gone too far the other way?

Yeah, I can see how not having enough structure creates a pull towards overspecifying the process the next time. Thank you for sharing this context with me!

Do you have any suggestions for what we could do to lighten the process?

I propose using only one format (a single set of recommended sections) and only a few statuses/categories (as discussed in #1 (comment)).

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bajtos]

The new proposal looks much better to me! I have two more comments to consider, plus one in a thread above. None of them is blocking this PR from getting landed.

[bajtos]

I see there is the "Alternatives considered" section in the template for an Experimental RFC, but it's not here in the template for Standard RFC. Is that intentional?

I like to have that section in all decision record documents, but I am not sure if Standard RFC belogs to that category.

For example, IPFS's IPIP includes "Alternatives considered" in the improvement proposal template but not in the spec template.

Anyhow, I am fine either way, this is easy to change later if needed.

[bajtos]

It would be great to capture our decision on whether RFC documents are updated over time in place or whether a new RFC document obsoleting the previous version must be created.

I prefer the former, as it makes it easier to review changes via git diff.

[alanshaw]

I think there's some nuance here - IMO experimental RFCs can just be updated whenever with whatever. Standard RFCs should not really be updated except for backwards compatible changes. Breaking changes should be proposed as a new standard because it's not really a standard if it keeps changing. Historical RFCs should not change after becoming historical.

[Peeja]

LGTM!

[pyropy]

👏🏻