Introduce RFC Template, README, CC0 1.0 Universal License #2
Conversation
|
Btw. my suggestion is to archive https://github.com/w3f/PPPs and to link to this repo, once this PR is merged. |
That'd be a W3F decision but seems reasonable to avoid ambiguity |
|
|
||
| For any RFC concerning runtime logic or interfaces, the Fellowship's capabilities are bounded by relay-chain governance, which is the ultimate decider of what code is adopted for block processing. As such, these RFCs are only loosely binding - the chains' governance has no obligation to accept the features as implemented and may accept features which have not gone through the RFC process. When it comes to node-side areas of expertise, the Fellowship's vote is more strongly binding, as the governance systems of the chains can't determine the environment the runtime is executed within, and in practice all node implementations should conform to some foundational standards in order to communicate. | ||
|
|
||
| Merged RFCs are only an indication of support for a specific design, not a commitment to an implementation of a feature on any particular timeframe or roadmap ordering. |
There was a problem hiding this comment.
So we will then need some "external process" to come to agreement when certain protocol changes will be implemented?
There was a problem hiding this comment.
Yes, or essentially at the whim of the Polkadot Fellowship / development shops at the moment.
Development has what, when, who, and cost questions. RFCs only commit to the "what", and there should be other processes (implicit or explicit) for determining the rest. e.g. OpenGov may look at pending features and create bounties for ones it deems particularly important, groups of collaborators and maintainers need to form around them, etc. and putting these estimates in what are primarily technical descriptions doesn't make that much sense to me.
rphmeier
changed the title
| The Fellowship will decide, via an on-chain voting mechanism including members III-Dan or above, when to approve and merge RFCs. It does so by issuing an on-chain remark with the body `RFC_APPROVE(xxxx, h)` from the `Fellows` origin on the Polkadot Collectives blockchain, where xxxx is the number of the RFC and h is the blake2-256 hash of the raw proposal text. Once this remark has been made, the PR can be merged. This on-chain process is designed to be resilient to where the RFCs are hosted and in what format, so it can be migrated away from GitHub in the future. The fellowship should not approve more than one RFC with the same number. | ||
|
|
||
| The Fellowship may also decide to reject an RFC by issuing a remark with the text `RFC_REJECT(xxxx, h)`. This is a formality to provide clarity on when PRs (or their analogue on non-GitHub platforms) may be closed. PRs may be closed by their author, as well. PRs may be closed when sufficiently stale, as well - after a period of 1 year without acceptance. |
There was a problem hiding this comment.
I realize that it's not the most fun problem to solve, but if I had to name one problem in the Polkadot ecosystem it's: too many ideas, and most of them are either abandoned or not moving.
If the point of the fellowship is to be the "technical masters" of Polkadot, then they should fulfill their role of "opinion givers". It would in my opinion be preferably to have some kind of deadline after which fellowship members must vote. If the fellowship completely abstains from voting, it means that they (as a group) doesn't fulfill this role of giving opinions.
And if a specific member of the fellowship doesn't vote/give their opinion or doesn't want to, why are they in the fellowship in the first place? Shouldn't they get kicked out?
Also, in my opinion it should be mentioned that implementers should make a reasonable effort to implement the accepted RFCs. After all, if an implementer decides to forever post-pone implementing an RFC, it means that the opinion of the fellowship has no value.
There was a problem hiding this comment.
It would in my opinion be preferably to have some kind of deadline after which fellowship members must vote
Disagree because,
a) it's not enforceable, has no consequences for not meeting that requirement
b) either you can have open RFCs that anyone can submit OR required voting
c) some ideas are just not worth spending time on
There was a problem hiding this comment.
a) it's not enforceable, has no consequences for not meeting that requirement
Maybe there should be consequences?
My opinion is if a fellow is completely idle, they should be removed from the fellowship. Or is being a fellowship member some kind of irrevocable aristocratic title that grants you a rent for life for doing nothing?
b) either you can have open RFCs that anyone can submit OR required voting
c) some ideas are just not worth spending time on
It seems that these two points are to counter spam. There's been 0 spam so far, and the PPPs repository has had 0 spam in its entire existence, so to me this feels like you want to solve a non-existing problem.
Spammers are rarely elaborate. Some people might open a PR that just says "when moon" or something, but these are easily closed as obviously non-serious.
If someone took the time to write down in deep technical details some changes that they want to see, passive-aggressively ghosting them would be an extremely non-welcoming thing to do.
There was a problem hiding this comment.
My opinion is if a fellow is completely idle, they should be removed from the fellowship. Or is being a fellowship member some kind of irrevocable aristocratic title that grants you a rent for life for doing nothing?
No, to stay in the fellowship you need to prove you're active. Any serious RFC should be able to find a champion who will create a referendum on-chain, but rules vs. social norms are very different things.
If lots of serious RFCs are falling through the cracks I'd be the first person to push more fellows to be active.
to me this feels like you want to solve a non-existing problem.
Likewise - therefore it makes more sense now to have fewer rules and then add more based on the problems that do exist.
| @@ -0,0 +1,59 @@ | |||
| # RFC-0000: Feature Name Here | |||
|
|
|||
| | | | | |||
There was a problem hiding this comment.
For discoverability and easier writing what about instead of a table we use a "front matter" in a machine parsable format like toml or yaml as supported by some static page generators(github renders it as a table), it can help tools to easily index and render proposals.
To that front matter perhaps I'd like to add a "tags" field that we can define elsewhere(e.g. a json file) to be able to categorize RFCs by topic, complexity, status, dependencies etc. It could be different fields but as I see them more as helpful optional metadata then one single tags field is simpler.
Example:
---
tags:
- xcm
- status:draft
- relates:#123
- trivial
---
|
This passed (https://collectives.subsquare.io/fellowship/referendum/7) so will be merged |
|
As discussed, the PPP repo was archived. |
Template
The Template is based on a combination of the rust-lang/RFCs template and the Fuchscia template. I removed fields which would need to be altered after a fellowship vote, so that it's easy to correlate text hashes which were voted on with specific proposals.
README
Here I added some explanation of what these RFCs are for, what they are not, and to what extent they are binding.
I also proposed a very basic process, with many details omitted, that will allow us to create things like Final Comment Periods and roadmaps in the future, but don't specify that at the moment.