Formal NEP Submission Process

Development Standards
1

Hey everyone,

The NEP submission process has been formalized to feel more like the familiar PEP/BIP/EIP model, with pepperings of RustRFC. This should help us transition the plethora of really awesome ideas floating around the community and the engineering teams into a pipeline that aims to be accessible for both authors and consumers. The official NEP1 meta standard on the process of how to create a standard is here. Essentially the process from ideation to Final Standard looks something like this:

  1. Start a discussion thread on our Standards Governance Discourse, or a git discussions thread on the NEP repo, to get feedback from the community on the idea. In the past, authors have created the entire document inline, however, this is not expected at this stage. A couple of paragraphs and some sample contract code/pseudocode is usually enough to get the community engaged in discussion. (If it does feel easier to draft the standard first, proceed directly to step 2)

  2. As the idea is being fleshed out, a formal Draft status NEP Document should be composed using the following template as part of a pull request. While there are optional sections, it is recommended to fill out as much as possible to make sure as many edge cases have been ruled out as possible. It’s important to flush out “Minimum Viable Interfaces” and types in pseudocode as part of the spec. Additionally, a new “Reference Implementation” section expects a link to a living repository of code exemplifying the standard, or, for simpler cases, inline code in a NEAR-compatible contract language. This code should demonstrate the MVI and types in practice. ( ie. traits and structs in rust, and interfaces and classes in AS/JS/TS ), as well as their implementations. Importantly, author attribution per RFC-822 style headers is required.

  3. NEP Editors, who are unopinionated shepherds of the process, check document formatting, completeness and adherence to NEP1 and approve the pull request.

  4. Once ready, the author updates the NEP status to Review allowing further community participation, to address any gaps or clarifications, normally part of the PR.

  5. NEP Editors mark the NEP as Last Call, allowing a 14 day grace period for any final community feedback. Any unresolved show stoppers roll the state back to Review.

  6. NEP Editors mark the NEP as Final, marking the standard as complete. The standard should only be updated to correct errata and add non-normative clarifications.

If you have any questions or comments, please reach out to me here, discord (lodge#4850), telegram(lodgeprime) or email (jay@near.org).

3 Likes