Template for NEP

0000-template.md

@@ -0,0 +1,77 @@
+- Proposal Name: (fill me in with a unique ident, `my_awesome_feature`)
+- Start Date: (fill me in with today's date, YYYY-MM-DD)
+- NEP PR: [nearprotocol/neps#0000](https://github.com/nearprotocol/neps/pull/0000)
+- Issue(s): link to relevant issues in relevant repos (not required).
+
+# Summary
+[summary]: #summary
+
+One paragraph explanation of the proposal.
+
+# Motivation
+[motivation]: #motivation
+
+Why are we doing this? What use cases does it support? What is the expected outcome?
+
+# Guide-level explanation
+[guide-level-explanation]: #guide-level-explanation
+
+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 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-level explanation
+[reference-level-explanation]: #reference-level-explanation
+
+This is the technical portion of the NEP. Explain the design in sufficient detail that:
+
+- Its interaction with other features is clear.
+- 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.
+
+# Drawbacks
+[drawbacks]: #drawbacks
+
+Why should we *not* do this?
+
+# Rationale and alternatives
+[rationale-and-alternatives]: #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?
+
+# Unresolved questions
+[unresolved-questions]: #unresolved-questions
+
+- 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
+[future-possibilities]: #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 the this 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.

README.md

@@ -1,12 +1,13 @@
 # NEPs
 
-Near Enhancement Proposals (NEPs) describe standards for the Near Protocol, including core protocol specfication, APIs, contract standards and process workflows such as NEPs themself.
+Near Enhancement Proposals (NEPs) describe standards for the Near Protocol, including core protocol specfication, APIs, contract standards and process workflows such as NEPs themselves.
 
 ## Contributing
 
-1. Review NEP-0, which describes contribution guideline
-2. Fork the repository by clicking "Fork" in the top right on Github.
-3. Add your NEP to your fork of the repository. Template TODO.
-4. Submit a Pull Request to [this repo](https://github.com/nearprotocol/NEPs).
+* Copy `0000-template.md` to `text/0000-my-feature.md` (where "my-feature" is descriptive. don't assign an NEP number yet).
+* If applicable, link to the issued in specific repositories;
+* Fill in the NEP. Put care into the details: NEPs that do not present convincing motivation, demonstrate understanding of the impact of the design, or are disingenuous about the drawbacks or alternatives tend to be poorly received.
+* Submit a pull request. As a pull request the NEP will receive design feedback from the larger community, and the author should be prepared to revise it in response.
+* Build consensus and integrate feedback. NEPs that have broad support are much more likely to make progress than those that don't receive any comments. Feel free to reach out to the NEP assignee in particular to get help identifying stakeholders and obstacles.