We would like to introduce the RFC process for substantial changes on the polkadot protocol. With this we’re attempting to engage the community more into further developing the protocol and being part on decisions made to it.
This RFC process is our first shot and as we go along we will for sure adapt it more to the community’s needs, if that’s necessary.
In future, for any substantial change to the protocol, especially changes that touches one of the following categories will need to go through the RFC process.
Runtime Environment
Changes to Host API, Runtime API or other properties of the WASM environment
Consensus Algorithms
Changes to block production or finality algorithms
Networking
Changes to the networking protocols
For this, we prepared a template that should be filled out in order to start discussions with the community and maintainers of the protocol. The template should support you in giving your thoughts a structure and also provide enough information to everyone onboarding to a conversation about it.
After submitting your draft, the PR goes under a first review cycle of four weeks. In this period your template might be modified based upon feedback from the maintainers and the community. Significant modifications may trigger a new final comment period. Once agreed upon a decision your proposal will be either accepted, declined or postponed to a later time or once preparation work for this PPP is final. If accepted, you can open a PR for the implementation of your proposed change, which will then again go under review of the maintainers and community until it’s merged.
Changes to Host API, Runtime API or other properties of the WASM environment
What else is defined as the “property of the wasm env”?
I am mainly asking for FRAME/Staking changes that I am personally involved in. I generally try to communicate and gather feedback about both fore implementing big changes, specially the latter. Do they now fit in the same process?
I personally think FRAME is not part Polkadot’s RFC process, but pallets that are in the Polkadot runtime, including to Staking (and moreover governance etc.) could undergo the same RFC process.
After submitting your draft, the PR goes under a first review cycle of four weeks. In this period your template might be modified based upon feedback from the maintainers and the community. Significant modifications may trigger a new final comment period. Once agreed upon a decision your proposal will be either accepted, declined or postponed to a later time or once preparation work for this PPP is final.
This is rather light on the details of the process for acceptance and the definition of ‘maintainers’. The natural choice of maintainers is the on-chain fellowship IMO.
Yes that is right. For now RFCs are mainly on the host part, because others need to implement this (which isn’t the case for the runtime). So, this is a good point to start with. However, having a similar process for the runtime will probably be required at some point as well. Let’s see what we learn by doing the RFC process for the host and how we can include the runtime at some point
Exactly. The entire process and what it includes is kept a little bit opaque for now. We clearly need to come up with such a list and I also know that people already “requested” this. This will also make it crystal clear on what needs to go through a RFC to be changed. However, I wanted that we have something to start with. The discussion on what should be included can then maybe also start as some kind of RFC.
Yes! We should have made this more clear, it will be the fellowship We just need to come up with some criteria on who is allowed to vote etc.
Thanks for sharing those ideas. Ack your point about everyone being ‘idea-rich’ & ‘time-poor’. However, a middle ground might be to post/track those ideas as W3F-RFP’s.
Still wondering if these proposals get implemented via Substrate, are to be pushed to Substrate separately or are independent of Substrate?
I think the bigger question here is what we consider the Polkadot Protocol.
For us in spec it is pretty clear that it is anything that concerns the host, so maybe we just have to communicate that better. IMHO the protocol could not care less if you use FRAME or something else inside the runtime and I do not think we should limit ourselves to this either.
So to answer your question, any change in the way the runtime integrates with the host that requires changes to the host itself should require an RFC.
Until we can find a trustless way to integrate the fellowship with a process like this, I do not see why we should not be honest and state that this is a GitHub-centric process for now.
I agree however that we should start discussing how to determine who should be a maintainer. Given however the extended scope of such a discussion, the need to start a process quickly outweighed the need to integrate it with the still experimental fellowship for now.
I also should mention that there has been no clear road to onboard the existing staff that has been maintaining the protocol spec so far into the fellowship, so this will also need to be part of the discussion going forward.
Substrate is used to provide the Parity Polkadot node implementation. So, everything that is accepted as a RFC for Polkadot will also be implemented in the Parity Polkadot node code base or in Substrate if it is more fundamental. Not that complicated actually.
However, other node implementors will also need to add these changes to their node implementation to stay compatible with the protocol.
So Substrate/other-node-implementors will need to come up with their own RFC process, or live with Parity deciding what belongs in Substrate?
Which is, actually, just the current state of play - correct?
To avoid doubt:
It would be out of scope of the Polkadot Protocol Proposals RFC process to propose moving part of the Parity Polkadot Protocol node code base into Substrate - because that is an implementation detail, and not a protocol detail.
Hi, thank you all for the feedback. The RFC repo will be moved to the fellowship org, so that it’s open for them to approve the suggested changes. @otar will announce it in the channel once this is done and explain the process behind it, until then I kindly ask you to add categories that you wish to see in the RFC process and vote on the ones already provided here.
I don’t really see the point of having to indicate a category?
If we are afraid to be flooded by so many RFCs that it becomes difficult to find a specific one without categories, it seems a bit early to me to solve this problem.
the categories should serve as an orientation to what is meant by “substantial” changes. Yes, we can adapt them while we go, but as there was negative feedback that the categories weren’t specific enough we thought about getting more input before moving the RFC to the fellowship
I don’t think that at the beginning there will be that many people that will end up writing a RFC. We can also just say that we start with host functions, which I would recommend any way. Then we can start including runtime api and then as a next step other things. We can also see what comes along the way, it isn’t currently that there are that many people doing these kind of changes.
Host function are in my opinion, by definition, the most important part that we can have RFCs for (from the perspective of the Polkadot runtime). RFCs for those seems like a no brainer to me.
I added a suggestion a suggestion in the poll about fundamental pallets as well, but now I find that kinda short sighted as it ignores the fact that FRAME is optional in any way for Polkadot to exist, so I would retract that.
