Introduce RFC Template, README, CC0 1.0 Universal License #2
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,39 @@ | ||
| # RFC-0000: Feature Name Here | ||
|
|
||
| | | | | ||
| | --------------- | ------------------------------------------------------------------------------------------- | | ||
| | **Start Date** | Date of initial proposal | | ||
| | **Description** | One-sentence description | | ||
| | **Authors** | | | ||
|
|
||
| ## Summary | ||
|
|
||
| One paragraph summary of the RFC. | ||
|
|
||
| ## Motivation | ||
|
|
||
| Longer motivation behind the content of the RFC, presented as a combination of both problems and requirements for the solution. | ||
|
|
||
| ## Stakeholders | ||
|
|
||
| A brief catalogue of the primary stakeholder sets of this RFC, with some description of previous socialization of the proposal. | ||
|
|
||
| ## Explanation | ||
|
|
||
| Detail-heavy explanation of the RFC, suitable for explanation to an implementer of the changeset. This should address corner cases in detail and provide justification behind decisions, and provide rationale for how the design meets the solution requirements. | ||
|
|
||
| ## Drawbacks | ||
|
|
||
| Description of recognized drawbacks to the approach given in the RFC. Non-exhaustively, drawbacks relating to performance, ergonomics, user experience, security, or privacy. | ||
|
|
||
| ## Prior Art | ||
|
|
||
| Provide references to prior art which served as inspiration for the submitted design. | ||
|
|
||
| ## Unresolved Questions | ||
|
|
||
| Provide specific questions to discuss and address before the RFC is voted on by the Fellowship. This should include, for example, alternatives to aspects of the proposed design where the appropriate trade-off to make is unclear. | ||
|
|
||
| ## Future Possibilities | ||
|
|
||
| Describe future work which could be enabled by this RFC, if it were accepted. This is a place to brain-dump and explore possibilities, which themselves may become their own RFCs. | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,23 @@ | ||
| Permission is hereby granted, free of charge, to any | ||
| person obtaining a copy of this software and associated | ||
| documentation files (the "Software"), to deal in the | ||
| Software without restriction, including without | ||
| limitation the rights to use, copy, modify, merge, | ||
| publish, distribute, sublicense, and/or sell copies of | ||
| the Software, and to permit persons to whom the Software | ||
| is furnished to do so, subject to the following | ||
| conditions: | ||
|
|
||
| The above copyright notice and this permission notice | ||
| shall be included in all copies or substantial portions | ||
| of the Software. | ||
|
|
||
| THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF | ||
| ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED | ||
| TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A | ||
| PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT | ||
| SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY | ||
| CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION | ||
| OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR | ||
| IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER | ||
| DEALINGS IN THE SOFTWARE. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1 +1,49 @@ | ||
| # RFCs | ||
|
|
||
| This repository contains a number of Requests for Comment (RFCs) detailing proposed changes to the technical implementation of the Polkadot network. These RFCs are for the discussion and design of features which have been submitted for consideration to the developer Fellowship of Polkadot, as well as targets for the Fellowship's on-chain bodies to signal approval or disapproval of. | ||
|
|
||
| ## Scope | ||
|
|
||
| According to the [Fellowship Manifesto](https://github.com/polkadot-fellows/manifesto/blob/0c3df46d76625980b8b48742cb86f4d8fa6dda8d/manifesto.pdf), members of the Polkadot Fellowship are responsible for expertise in the strict description(s) and/or implementation(s) of these areas of contribution: | ||
| * the internals of all functional Polkadot node implementations; | ||
| * cryptographic data-structures, algorithms, languages and APIs required for the continued upkeep of the Polkadot (Main) Network; | ||
| * consensus algorithms concerning the Relay-chain (BABE \& GRANDPA); | ||
| * trust-free bridges relying on said consensus algorithms (planned to be) utilised by system chains; | ||
| * parachain consensus; | ||
| * cross-chain message passing (XCMP, HRMP, DMP \& UMP); | ||
| * the Polkadot libp2p-based peer networking protocol; | ||
| * the Polkadot topology strategies; | ||
| * chain synchronisation strategies utilised by Polkadot; | ||
| * the Polkadot business-logic (aka the 'runtime'); | ||
| * pallets utilised by the Polkadot (Main) Network and its system chains; | ||
| * the internals of the frame pallet framework; | ||
| * runtime and host APIs; | ||
| * the XCM specification and realisation; | ||
| * standard RPCs; | ||
| * user-interface code required to practically execute upgrades to the Polkadot (Main) Network; and | ||
| * code or technology required by, and utilised primarily for, any code or technology already included. | ||
|
|
||
| These RFCs are scoped to the subset of these concerns which must be held consistent across all implementations. Various implementation details, such as internal node algorithms, programming languages, or database formats are out of scope. Changes to network protocol descriptions, runtime logic and runtime public interfaces, inherents, transaction formats should be discussed via RFCs. | ||
|
|
||
| ## Significance | ||
|
|
||
| These RFCs are in practice only a signaling mechanism to determine and indicate the Fellowship's design and architecture preferences and to coordinate discussion and social consensus on architectures and designs according to open-source principles. | ||
|
|
||
| The Fellowship holds only the powers vested in it by Polkadot's governance, which are limited to the expression of expert opinion and the ability to move proposals to more lenient governance tracks when necessary. It is not an arbiter of the "correctness" of any particular runtime or node implementation, and the practical meaning of these RFCs follows as a consequence of its limited powers. | ||
|
|
||
| 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. |
||
|
|
||
| ## Process | ||
|
|
||
| The RFC process is open to all contributors. Anyone may open an RFC or provide comments on open RFCs. | ||
|
|
||
| To open an RFC, follow these steps: | ||
| * Copy the `0000-template.md` file into the `text` folder and rename to match the title of the RFC | ||
| * Fill out the RFC template and open a PR. | ||
| * Rename the file to correspond to the GitHub pull request number and update the "RFC PR" field in the file. | ||
|
|
||
| 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. | ||
|
Comment on lines
+47
to
+49
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. 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.
Disagree because, There was a problem hiding this comment.
Maybe there should be consequences?
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.
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.
Likewise - therefore it makes more sense now to have fewer rules and then add more based on the problems that do exist. |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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: