Proposed v2 of the IPIP process #324
Conversation
|
@p-shahi take a look! :) |
There was a problem hiding this comment.
Thank you, sgtm, this follows our long term plan for IPIPs.
IPIPs aim to be immutable, but this one is special, because it acts as an entry point for people new to this repo. I think it should point at "current best practices"
Would it make sense to copy this content and create IPIP-specification-process.md in the root of this repo (similar to libp2p/specs/00-framework-01-spec-lifecycle.md ) and point both README.md and this original IPIP0001 at this new living document?
This way we will not overwrite historical IPIP, and make the current process easier to discover.
Proposing some restructuring, rewording, and more structured consensus protocol for moving proposals through the process
This keeps historical record intact, and points at mutable process at the repo root.
lidel
force-pushed
the
reidlw/process-proposal
branch
from
36684f2 to
9f295c5
Compare
There was a problem hiding this comment.
@reidlw fysa I've rebased this PR and moved v2 to IPIP_PROCESS.md, so we are not mutating historical IPIP (+ made it link to the file as the upt-to-date source of truth about the process).
I think this is ready to merge, we can adjust in follow-up PRs, but let's discuss this during today's IPFS Implementers Sync
|
|
||
| 1. [Specs Stewards] will do an initial triage of newly opened PRs roughly monthly. They'll try to filter out | ||
| noise, so that community consideration is given only to reasonable proposals; others they'll reject. | ||
| 2. Specs Stewards will post to the forums linking to the proposal; directing feedback/discussion to |
There was a problem hiding this comment.
What do we mean by "the forums"?
Should I create "IPIP" category under https://discuss.ipfs.tech/c/protocol/30 ?
IPIP_PROCESS.md
Outdated
|
|
||
| Proposals are officially submitted when a pull request into `main` is opened | ||
|
|
||
| Proposals that were reviewed and rejected will be moved into `IPIP/rejected` folder and then merged into `main` |
There was a problem hiding this comment.
Since things that are rejected immediately won't be merged, and we only merge "potentially useful" proposals,
should it be "rejected" or more neutral "deferred" ?
| 5. Proposals that are generating ongoing discussion and seem contentious or stuck will be brought in for | ||
| consideration at a monthly sync, to be announced at least a week ahead of time on the forum. | ||
| 6. After discussion, Spec Stewards will make call on whether to approve or reject the proposal. | ||
| 7. At this point approved proposals get assigned a number (encoded in the filename), |
There was a problem hiding this comment.
Q: could we assign number earlier, during initial evaluation as suggested in #303 ?
Proposing some restructuring, rewording, and more structured consensus protocol for moving proposals through the process