feat: RFC RFC #71

travis · 2025-10-22T21:33:02Z

An RFC to request comment on proposed customs and practices for Storacha RFCs. This was synthesized from a large amount of feedback from our developer team about the strengths and weaknesses of our current process - happy to share the underlying feedback with anyone interested, but have elided it to maintain the privacy of respondees.

Please take a look and let's hammer our the next version of this process!

An RFC to request comment on proposed customs and practices for Storacha RFCs. Please take a look and let's hammer our the next version of this process!

fforbeck

❤️

rfc-rfc.md

frrist

🚢 Love this

rfc-rfc.md

BravoNatalie

❤️

rfc-rfc.md

alanshaw

🙏 Can this RFC be the repo README? Or at the very least linked from.

Non-blocking suggestions:

It would be nice to add a status to existing RFCs and PRs
Merge/close existing PRs

rfc-rfc.md

alanshaw · 2025-10-23T08:44:49Z

rfc-rfc.md

+
+Discussion of an RFC should take place in the Pull Request using standard GitHub Pull Request tooling.
+
+Developers SHOULD indicate their signoff on an RFC by "approving" the PR.


Some discussion about whether it is necessary to merge the PR and when that should be done?

issue (blocking): Also, what "signoff" means. Does signing off on an Informational RFC mean simply acknowledging it? Does signing off on a Proposed Standard RFC mean approval of the proposal, or of adopting it? What's the difference between a PR for a Proposed Standard RFC, a merged Proposed Standard RFC, and a PR for a Published Standard RFC? What does the status change process look like?

Blocking because I think we'll be immediately stymied by not having some clear procedure here. We certainly don't have to get it right on the first go, though; we can always RFC the RFCs again.

Proposal:

^{(✅=approved, ❌=changes requested, 🔀=merged)}

Informational:

✅: Read and acknowledged

❌: Clarification required

🔀: Acknowledged by a quorum

Experimental:

✅: Read and acknowledged

❌: Clarification required

🔀: Acknowledged by a quorum

Best Current Practice:

✅: Confirmed as description of best current practice

❌: Disagreement about being best, or about being current practice, or clarification required

🔀: Confirmed by a quorum

Proposed Standard:

✅: Read, acknowledged, and agree worth proposing as written

❌: Disagreement over details, or that idea is worth discussing further, or clarification required (entirely separate proposals are not a ❌, but a separate Proposed Standard RFC)

🔀: Confirmed by a quorum as a presentable proposal

Published Standard: (almost(?) always a PR to promote an existing RFC from Proposed Standard to Published Standard)

✅: Agreed ready to become a standard

❌: Disagreement that proposal is ready (details and clarification is usually already hashed out in Proposed Standards)

🔀: Confirmed as a standard which should be followed until Obsoleted by a new Published Standard

Historical: (always a PR to move an existing RFC to Historical)

✅: Agreed the RFC is now historical (no longer a going concern)

❌: Disagreement that RFC is historical

🔀: Confirmed as historical

Additionally:

The only permissible status changes are Proposed Standard → Published Standard and → 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.

A standards-track RFC which adds to a prior standard should be marked Updates: XXX. A PR promoting that RFC to Published should amend the updated RFC to be marked Updated by: XXX. These annotations should be hyperlinks.

Likewise, a standards-track RFC which entirely replaces a prior standard should be marked Obsoletes: XXX, and a PR promoting that RFC to Published should amend the updated RFC to be marked Obsoleted by: XXX. Again, these annotations should be hyperlinks.

Notably, the list of RFCs is not a list of (solely) standards, or even a list of (solely) current information or practices. "All current published standards" could be defined by a query over the information in the RFCs, if we had such a tool, but since that seems unlikely, we may want to keep some sort of manual list of them up to date in the repo.

I am also struggling with the relationship between the RFC process and https://github.com/storacha/specs

What is that other repo if not Published/Proposed Standards?

rfc-rfc.md

Peeja · 2025-10-23T14:49:06Z

rfc-rfc.md

+
+Discussion of an RFC should take place in the Pull Request using standard GitHub Pull Request tooling.
+
+Developers SHOULD indicate their signoff on an RFC by "approving" the PR.


issue (blocking): Also, what "signoff" means. Does signing off on an Informational RFC mean simply acknowledging it? Does signing off on a Proposed Standard RFC mean approval of the proposal, or of adopting it? What's the difference between a PR for a Proposed Standard RFC, a merged Proposed Standard RFC, and a PR for a Published Standard RFC? What does the status change process look like?

Blocking because I think we'll be immediately stymied by not having some clear procedure here. We certainly don't have to get it right on the first go, though; we can always RFC the RFCs again.

Proposal:

^{(✅=approved, ❌=changes requested, 🔀=merged)}

Informational:

✅: Read and acknowledged

❌: Clarification required

🔀: Acknowledged by a quorum

Experimental:

✅: Read and acknowledged

❌: Clarification required

🔀: Acknowledged by a quorum

Best Current Practice:

✅: Confirmed as description of best current practice

❌: Disagreement about being best, or about being current practice, or clarification required

🔀: Confirmed by a quorum

Proposed Standard:

✅: Read, acknowledged, and agree worth proposing as written

❌: Disagreement over details, or that idea is worth discussing further, or clarification required (entirely separate proposals are not a ❌, but a separate Proposed Standard RFC)

🔀: Confirmed by a quorum as a presentable proposal

Published Standard: (almost(?) always a PR to promote an existing RFC from Proposed Standard to Published Standard)

✅: Agreed ready to become a standard

❌: Disagreement that proposal is ready (details and clarification is usually already hashed out in Proposed Standards)

🔀: Confirmed as a standard which should be followed until Obsoleted by a new Published Standard

Historical: (always a PR to move an existing RFC to Historical)

✅: Agreed the RFC is now historical (no longer a going concern)

❌: Disagreement that RFC is historical

🔀: Confirmed as historical

Additionally:

The only permissible status changes are Proposed Standard → Published Standard and → 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.

A standards-track RFC which adds to a prior standard should be marked Updates: XXX. A PR promoting that RFC to Published should amend the updated RFC to be marked Updated by: XXX. These annotations should be hyperlinks.

Likewise, a standards-track RFC which entirely replaces a prior standard should be marked Obsoletes: XXX, and a PR promoting that RFC to Published should amend the updated RFC to be marked Obsoleted by: XXX. Again, these annotations should be hyperlinks.

Notably, the list of RFCs is not a list of (solely) standards, or even a list of (solely) current information or practices. "All current published standards" could be defined by a query over the information in the RFCs, if we had such a tool, but since that seems unlikely, we may want to keep some sort of manual list of them up to date in the repo.

rfc-rfc.md

from #71

volmedo

❤️🚀

hannahhoward

I don't think we are quite there yet.

I think we need to clarify:

What is the relationship between this repo and the specs repo
What is the role of merging PRs
What are the standards for "qourum", response times, etc.

Also do we really need all these different RFC types?

hannahhoward · 2025-10-29T13:23:38Z

rfc-rfc.md

+
+The Storacha "Request For Comments" process is modeled after the ["Internet Engineering Task Force" (IETF) process of the same name](https://www.ietf.org/process/rfcs/) both as an homage to this legendary standards body and in recognition of the fact that our team aspires to create open source, standardized protocols for decentralized data storage and authorized upload and retrieval that have the potential to outlast our team and organization. Despite this aspiration, however, our team is both culturally and practically very different from the IETF and as such the customs and practices of the IETF's RFC process are not necessarily well suited to our needs. 
+
+This document lays out guidelines for the creation of Storacha RFC documents. We describe the purpose of a Storacha RFC, discuss the various types of RFCs and provide templates and guidelines for RFC authors to both aid in their creation and help provide consistency between them. We also discuss both existing and desired processes for managing RFCs through their lifecycles and building consensus across our team toward the concrete actions RFCs propose.


Are there templates here? I don't see them. Should there be templates here?

(like I imagine a simple RFC for: informational, exprimental, proposed standard)

hannahhoward · 2025-10-29T13:28:42Z

rfc-rfc.md

+
+Informational RFCs are published for the general information of the Storacha community, and do not represent consensus or recommendations for our team or community, nor any kind of (even potential) process or standard which could be followed. The are simply a statement of facts published to make information more broadly known. As in the IETF's guidelines, "[If it can't be practiced, it's Informational.](https://www.ietf.org/process/process/informational-vs-experimental/#:~:text=If%20it%20can%27t%20be%20practiced%2C%20it%27s%20Informational.)"
+
+### Experimental


Is Experimental a precursor to Proposed Standard? @Peeja comment below suggests you would make a new RFC, but I don't know if that makes sense.

I'm trying to imagine the development lifecycle here:

"I'm about to implement a big thing and need feedback on architecture" -> Experimental
"Ok my thing is implemented and seems to work, let's make the public facing part a standard" -> Proposed Standard
"Alright we all agree it will be a standard, here's the final doc" -> Published Standard

hannahhoward · 2025-10-29T13:29:50Z

rfc-rfc.md

+
+Discussion of an RFC should take place in the Pull Request using standard GitHub Pull Request tooling.
+
+Developers SHOULD indicate their signoff on an RFC by "approving" the PR.


I am also struggling with the relationship between the RFC process and https://github.com/storacha/specs

What is that other repo if not Published/Proposed Standards?

feat: RFC RFC

9731013

An RFC to request comment on proposed customs and practices for Storacha RFCs. Please take a look and let's hammer our the next version of this process!

travis requested review from a team, BravoNatalie, Peeja, alanshaw, fforbeck, frrist, hannahhoward and volmedo October 22, 2025 21:33

fforbeck approved these changes Oct 22, 2025

View reviewed changes

rfc-rfc.md Outdated Show resolved Hide resolved

fix: add status!

959a08b

frrist approved these changes Oct 22, 2025

View reviewed changes

rfc-rfc.md Outdated Show resolved Hide resolved

BravoNatalie approved these changes Oct 23, 2025

View reviewed changes

rfc-rfc.md Outdated Show resolved Hide resolved

rfc-rfc.md Outdated Show resolved Hide resolved

alanshaw approved these changes Oct 23, 2025

View reviewed changes

Peeja reviewed Oct 23, 2025

View reviewed changes

fix: incorporate lots of feedback

02b5ae7

from #71

volmedo approved these changes Oct 27, 2025

View reviewed changes

hannahhoward requested changes Oct 29, 2025

View reviewed changes


		Discussion of an RFC should take place in the Pull Request using standard GitHub Pull Request tooling.

		Developers SHOULD indicate their signoff on an RFC by "approving" the PR.


		The Storacha "Request For Comments" process is modeled after the ["Internet Engineering Task Force" (IETF) process of the same name](https://www.ietf.org/process/rfcs/) both as an homage to this legendary standards body and in recognition of the fact that our team aspires to create open source, standardized protocols for decentralized data storage and authorized upload and retrieval that have the potential to outlast our team and organization. Despite this aspiration, however, our team is both culturally and practically very different from the IETF and as such the customs and practices of the IETF's RFC process are not necessarily well suited to our needs.

		This document lays out guidelines for the creation of Storacha RFC documents. We describe the purpose of a Storacha RFC, discuss the various types of RFCs and provide templates and guidelines for RFC authors to both aid in their creation and help provide consistency between them. We also discuss both existing and desired processes for managing RFCs through their lifecycles and building consensus across our team toward the concrete actions RFCs propose.


		Informational RFCs are published for the general information of the Storacha community, and do not represent consensus or recommendations for our team or community, nor any kind of (even potential) process or standard which could be followed. The are simply a statement of facts published to make information more broadly known. As in the IETF's guidelines, "[If it can't be practiced, it's Informational.](https://www.ietf.org/process/process/informational-vs-experimental/#:~:text=If%20it%20can%27t%20be%20practiced%2C%20it%27s%20Informational.)"

		### Experimental

feat: RFC RFC #71

Are you sure you want to change the base?

feat: RFC RFC #71

Conversation

travis commented Oct 22, 2025 • edited by Peeja Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fforbeck left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

frrist left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

BravoNatalie left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

alanshaw left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

alanshaw Oct 23, 2025

Choose a reason for hiding this comment

Uh oh!

Peeja Oct 23, 2025

Choose a reason for hiding this comment

Proposal:

Uh oh!

hannahhoward Oct 29, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Peeja Oct 23, 2025

Choose a reason for hiding this comment

Proposal:

Uh oh!

Uh oh!

Uh oh!

volmedo left a comment

Choose a reason for hiding this comment

Uh oh!

hannahhoward left a comment

Choose a reason for hiding this comment

Uh oh!

hannahhoward Oct 29, 2025

Choose a reason for hiding this comment

Uh oh!

hannahhoward Oct 29, 2025

Choose a reason for hiding this comment

Uh oh!

hannahhoward Oct 29, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

travis commented Oct 22, 2025 •

edited by Peeja

Loading