-
Notifications
You must be signed in to change notification settings - Fork 235
Closed
Labels
P1High: Likely tackled by core team if no one steps upHigh: Likely tackled by core team if no one steps upeffort/weeksEstimated to take multiple weeksEstimated to take multiple weekskind/maintenanceWork required to avoid breaking changes or harm to project's status quoWork required to avoid breaking changes or harm to project's status quostatus/in-progressIn progressIn progress
Description
The aim here is to create a convention-driven process that enables IPFS community
to propose changes to existing specs or even propose new ones.
Guiding principles
- no new tooling
- reuse markdown, git, and existing github PR review process for user auth / reputation etc
- convention over byzantine process
- proposing RFC should have low cognitive overhead, allowing us to focus on specs
- one should be able to create a valid RFC without reading about the process: just looking at past RFCs, and then copying a template and opening a PR with their proposal should be good enough
TODO
- decide on "IPFS RFC" or pick a different name
- limit the time spent on this bikeshed: using something else makes better SEO as there won't be overlap with IETFs RFCs, but big projects like Rust use "RFC" and it's also fine
- decision: going with "IPFS RFC" and short "RFC" unless someone proposes something better
- limit the time spent on this bikeshed: using something else makes better SEO as there won't be overlap with IETFs RFCs, but big projects like Rust use "RFC" and it's also fine
- document the process – see IPIP 0001: Lightweight "RFC" Process for IPFS Specifications #289
- create
ipfs/specs/RFC/0000-template.mdand use it for 0001 that documents the RFC process (see prior art at the end)- clear licensing CC0 (same as FIPs)
- leverage CODEOWNERS file – you are automatically responsible for new things you create (tbd if same applies to things you modified)
- create
- test the process internally by creating diffs against HTTP gateway specs or similar
- gateway: IPLD
?selectorsupport - gateway: dag-json and dag-cbor support and response types
- TAR Gateway Response Format (IPIP-288: TAR Gateway Response Format #288)
- badbits spec
- WAC (WASM format for pluggable codecs and ADLs) from this PR
- gateway: IPLD
- test the process with community members – land at least 1 from the list below:
- integrating gateway support into existing apps
- gateway: writable methods
- gateway:
_redirectsand_headers(+feat(gateway): _redirects file support kubo#8890) - gateway: DNSSEC proofs for DNSLink responses
- WebDAV gateway
- (or maybe someone will propose something else)
Prior art
- similar projects
- other
mishmosh and SgtPookimxinden and TheDiscordian
Metadata
Metadata
Assignees
Labels
P1High: Likely tackled by core team if no one steps upHigh: Likely tackled by core team if no one steps upeffort/weeksEstimated to take multiple weeksEstimated to take multiple weekskind/maintenanceWork required to avoid breaking changes or harm to project's status quoWork required to avoid breaking changes or harm to project's status quostatus/in-progressIn progressIn progress