Skip to content

Latest commit

 

History

History
86 lines (58 loc) · 3.48 KB

nep-0000-template.md

File metadata and controls

86 lines (58 loc) · 3.48 KB
Raw
NEP Title Author DiscussionsTo Status Type Category Created
0
NEP Purpose and Guidelines
Todd Codrington III <[email protected]>
Draft
Standards Track
Contract
03-Mar-2022

Summary

One paragraph explanation of the proposal.

Motivation

Why are we doing this? What use cases does it support? What is the expected outcome?

Rationale and alternatives

  • Why is this design the best in the space of possible designs?
  • What other designs have been considered and what is the rationale for not choosing them?
  • What is the impact of not doing this?

Specification

Explain the proposal as if it was already implemented and you were teaching it to another developer. That generally means:

  • Introducing new named concepts.
  • Explaining the feature largely in terms of examples.
  • If the feature introduces new abstractions, explaining how users and/or developers should think about it;
  • If applicable, describe the differences between the existing functionality.

For user-facing NEPs, this section should focus on user stories.

Reference Implementation (Required for Protocol Working Group proposals, optional for other categories)

This is the technical portion of the NEP. Explain the design in sufficient detail that:

  • Its interaction with other features is clear.
  • Where possible, include a Minimum Viable Interface subsection expressing the required behavior and types in a target Near Contract language. (ie. traits and structs for rust, interfaces and classes for javascript, function signatures and structs for c, etc.)
  • It is reasonably clear how the feature would be implemented.
  • Corner cases are dissected by example.

The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.

Security Implications (Optional)

If there are security concerns concerning the NEP, those concerns should be explicitly written out to make sure reviewers of the NEP are aware of them.

Drawbacks (Optional)

Why should we not do this?

Unresolved Issues (Optional)

  • What parts of the design do you expect to resolve through the NEP process before this gets merged?
  • What parts of the design do you expect to resolve through the implementation of this feature before stabilization?
  • What related issues do you consider out of scope for this NEP that could be addressed in the future independently of the solution that comes out of this NEP?

Future possibilities

Think about what the natural extension and evolution of your proposal would be and how it would affect the project as a whole in a holistic way. Try to use this section as a tool to more fully consider all possible interactions with the project in your proposal. Also, consider how all fits into the roadmap for the project and of the relevant sub-team.

This is also a good place to "dump ideas"; if they are out of scope for the NEP you are writing but otherwise related.

If you have tried and cannot think of any future possibilities, you may simply state that you cannot think of anything.

Note that having something written down in the future-possibilities section is not a reason to accept the current or a future NEP. Such notes should be in the section on motivation or rationale in this or subsequent NEPs. The section merely provides additional information.

Copyright

Copyright and related rights waived via CC0.