RFC proposal

[franciscoaguirre]

I propose an RFC process akin to the one in https://github.com/w3f/PPPs to propose changes to the XCM format regardless of implementation.

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/xcm-rfc-process/2447/1

[vstam1]

I like the setup of the RFC process to organise the development of new xcm features and open the discussion about the format to the community. One thing I would like to see is some kind of priority system. Each RFC of course already has a version matched to it. Do we want this version set by the community or the maintainers? And do we want to use this version as a way to prioritise features? Furthermore, I would like to see some impact section where the impact of the feature is defined. For example the impact of a new instruction will possibly be lower than the impact of a change to an existing instruction. Additionally to the impact section, we can assign the impact as an additional field in the frontmatter.

Let me know what you think

[franciscoaguirre]

@vstam1 I think versions should be set by the maintainers, sort of how RFC numbers should also be set after they have been accepted.

The version could be use as a sort of priority (lower-numbered versions come first) but that is mostly useful if we stick to adding only a small set of features per version.

Let's say we have 3 accepted RFCs, and maintainers decided the first two aim for version X while the last one aims for some version Y > X. Then we'd need to keep them as accepted while the main implementations (right now only xcm-executor) add the changes and change them to enacted once they are done. Once the version is complete, we tag the commit. Then we start with the new version. Does that flow make sense?

[franciscoaguirre]

@vstam1

Regarding the impact section:

For example the impact of a new instruction will possibly be lower than the impact of a change to an existing instruction.

Does this mean that the "impact" is some degree of breaking changes? Are you envisioning something like the following?

• Impact: 0 -> Breaking changes
• Impact: 1 -> High
• Impact: 2 -> Low
• Impact: 3 -> Trivial

[KiChjang]

So this is definitely on the right track, as we don't need to have a living standard not too dissimilar to the HTML spec, because the XCM format standard is prescriptive rather than descriptive, i.e. it doesn't document what's already out there, but rather documents future features and plans for implementation.

One thing I would really want to talk about is the acceptance process. Currently it isn't quite clear to me how long a proposal should last before a decision is made, nor is it clear to me who gets to make the decision to accept or reject. I feel like the fellowship is definitely one of the organizations that can decide on such matters, though we might want to also ask "which fellowship?" Naturally we'd say the technical fellowship, but that may not be very appropriate either as not everyone on the fellowship is familiar with XCM matters. The upcoming parachain fellowship however does sound like a good fit, as XCM impacts them directly.

[franciscoaguirre]

@KiChjang

I thought definitely the fellowship instead of parity, but I didn't know about the upcoming parachain fellowship. We should probably talk to them about this. What's a good starting point for that?

I don't know how long the general review period should be. Looking at the rust RFCs for example, that period is only done when a maintainer proposes to start a "final comment period", and those last 10 calendar days. This sounds reasonable. What do you think?

[vstam1]

Does this mean that the "impact" is some degree of breaking changes? Are you envisioning something like the following? Yeah I think this division of impact could be useful.

[franciscoaguirre]

@vstam1 I added the "Impact" field to the frontmatter and section

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/xcm-rfc-process/2447/2