diff --git a/neps/nep-0001.md b/neps/nep-0001.md index 2db052b98..3df1f3662 100644 --- a/neps/nep-0001.md +++ b/neps/nep-0001.md @@ -1,228 +1,177 @@ --- NEP: 1 -Title: NEP Purpose and Guideline -Authors: Bowen W. ; Austin Baggio ; Ori A. ; +Title: NEP Purpose and Guidelines +Authors: Bowen W. , Austin Baggio , Ori A. , Vlad F. ; +Status: Approved DiscussionsTo: https://github.com/near/NEPs/pull/333 -Status: Living -Type: Process -Created: 03-Mar-2022 +Type: Developer Tools +Version: 1.1.0 +Created: 2022-03-03 +Last Updated: 2023-03-05 --- +## Summary +A NEAR Enhancement Proposal (NEP) is a design document that specifies reusable and interoperable components integrated across the NEAR ecosystem. -## What is a NEAR Enhancement Proposal (NEP)? -A NEP is a design document for providing information to the NEAR community or describing a new feature for the NEAR protocol or Smart Contract standards. The NEP should provide a concise technical specification and a rationale for the feature. +NEPs are the primary mechanism for evolving NEAR’s runtime, Smart Contract Standards, and Wallets ecosystem in a community-driven way. NEPs provide a concise technical specification and a rationale for the feature. The NEP author is responsible for building consensus within the community and documenting dissenting opinions. The typical primary audience for NEPs are the developers of the NEAR reference implementations and decentralized application developers. -NEPs are intended to be the primary mechanism for proposing new features, coordinating formal feedback, and documenting design decisions that were integrated into NEAR’s runtime or Smart Contract ecosystem. +NEPs are stored as text files in a versioned repository, allowing for easy historical tracking. A list of NEPs is available on [GitHub](https://github.com/near/NEPs). -As such, the NEP’s author is responsible for building consensus within the community and documenting dissenting opinions. +## Motivation -Because NEPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. A list of NEPs is available on [GitHub](https://github.com/near/NEPs/). +The purpose of the NEP process is to ensure the seamless evolution of the NEAR platform and to empower the community to contribute to its development. Given the complexity and number of participants involved across the ecosystem, a well-defined process helps ensure transparency, security, and stability. -## Motivation +## NEP Types +There are four kinds of NEPs: -The purpose of the NEP process is to ensure seamless protocol upgrades and to empower the community to contribute to the development of the NEAR platform. Given the complexity of the protocol and the large number of participants across the ecosystem, the process introduces working groups as a way to operationalize the review of NEPs that builds legitimacy and community support. +1. A **Protocol** NEP describes a new feature of the NEAR protocol. +2. A **Contract Standards** NEP specifies NEAR Smart Contract interfaces for a reusable concept in the NEAR ecosystem. +3. A **Wallet Standards** NEP specifies ecosystem-wide APIs for Wallet implementations. +4. A **Developer Tools** NEP defines norms and guidelines for developer tooling in the NEAR ecosystem. -The working groups are responsible for coordinating the public review of NEPs, gauging the viability and community support, and overseeing decisions. Each group will focus on various ecosystem needs, such as the protocol, standards, and tools. +Currently, all types of NEPs follow the same process, but for Protocol NEPs a draft implementation is required. -Pagoda has selected a few experts to help bootstrap the first two groups: Protocols and Contract Standards. Putting these groups into practice will require flexibility. The goal is to iterate and eventually introduce more groups and broader participation. Visit [https://near.org/developer-governance](https://near.org/developer-governance) to learn more about these groups, their members, and the upcoming meetings. +## Submit a NEP -## Audience -The typical primary audience for NEPs are the core developers of the NEAR reference implementations and decentralized applications developers +### Start with ideation +Everyone in the community is welcome to propose, discuss, and review ideas to improve the NEAR protocol and standards. The NEP process begins with a [new idea](https://www.neardevgov.org/blog/how-to-ideate-in-the-near-developer-governance) for the NEAR ecosystem. A single NEP should contain a single key proposal or new idea. -## NEP Types -There are two kinds of NEPs: - -1. A **Standards** NEP describes a new NEAR Smart Contract implementation standard. -2. A **Protocol** NEP describes a new feature for the NEAR protocol. - -Currently, both types of NEPs follow the same process. - -## NEP Workflow -### Start with an idea for NEAR -Everyone in the community is welcome to propose, discuss, and review ideas to improve the NEAR protocol and standards. The NEP process begins with a new idea for the NEAR ecosystem. A single NEP should contain a single key proposal or new idea. - -Each NEP must have an author: someone who writes the NEP using the style and format described below. The author, or another champion, shepherds the discussions in the appropriate forums and attempts to build community consensus around the idea to help it progress toward completion. - -Before submitting a NEP, the author should first attempt to ascertain whether the idea is NEP-able. Vetting an idea publicly before writing a NEP saves the potential author time. Asking the NEAR community first if an idea is original helps prevent effort on something that is guaranteed to be rejected based on prior discussions. It also helps ensure the idea is applicable to the entire community. Just because an idea sounds good to the author does not mean it will work for most people in most use cases. - -In general, the process to socialize an idea is: - -- **Check prior proposals:** Many ideas for changing NEAR come up frequently. Please search the [governance](https://gov.near.org/)[ ](https://gov.near.org/)[site](https://gov.near.org/) forums and NEPs in this repo before proposing something new. -- **Share the idea:** Join the [governance](https://gov.near.org/)[ ](https://gov.near.org/)[site](https://gov.near.org/) and make a post to the appropriate section. For instance, during the ideation phase of a standard, one might start a new conversation in the [Development](https://gov.near.org/c/dev/standards/29)[ » ](https://gov.near.org/c/dev/standards/29)[Standards](https://gov.near.org/c/dev/standards/29)[ ](https://gov.near.org/c/dev/standards/29)[section](https://gov.near.org/c/dev/standards/29). Similarly, during the ideation phase of a proposal to change the protocol, one might start a new conversation in the [Development](https://gov.near.org/c/dev/proposals/68)[ » ](https://gov.near.org/c/dev/proposals/68)[Proposals](https://gov.near.org/c/dev/proposals/68)[ ](https://gov.near.org/c/dev/proposals/68)[section](https://gov.near.org/c/dev/proposals/68). -- **Get feedback:** The forum has comment threading which allows the community and NEAR Collective to ideate, ask questions, wrestle with approaches, etc. If more immediate responses are desired, consider bringing the conversation [to](https://near.chat/)[ ](https://near.chat/)[Discord](https://near.chat/). - -### Submit a NEP -Following the above initial discussions, the author should submit a draft NEP via a GitHub pull request. The draft must follow the NEP style as described below, else it will fail review immediately (although the moderators may correct minor errors). - -The NEP workflow is: - -- You, the NEP author, fork the NEPs repository, and create a file named neps/nep-9999.md that contains your new NEP. Use “9999” as your draft NEP number. -- Your first update is to change the nep filename to match the Pull Request number. For example, if the PR is 305, the NEP should be neps/nep-0305.md. -- In the “Type:” header field, enter “Standards” or “Protocol” as appropriate, and for the “Status:” field enter “Draft”. For full details, see NEP Header Preamble. -- Push this to your GitHub fork and submit a pull request. -- The NEP moderators review your PR for structure, formatting, and other errors. For a markdown-formatted NEP, nep-template.md is provided as a template. - Approval criteria are: - - The content is sound and complete. The ideas must make technical sense. The moderators do not consider whether they seem likely for acceptance. - - The title accurately describes the content. - - The language (spelling, grammar, sentence structure, etc.) and code style are correct and conformant. -- If the NEP is not ready for approval, the moderators will send it back to the author for revision, with specific instructions in the pull request. The review by the moderators is expected to finish within one week. -- Once the moderators agree that the PR is ready for review, the moderators will notify the approvers (working group members) to assign a team of at least two reviewers (subject matter experts) to review the NEP. The reviewers will review the technical details of the proposal and assess its merits. They may ask clarification questions, request changes, or reject the proposal. If the assigned reviewers feel that they do not have the relevant expertise to fully review the NEP, they can request the working group to re-assign subject matter experts for the NEP. -- The review by the reviewers is expected to finish within one week. After completing the review, the reviewer must add an explicit comment to indicate the next step and tag the appropriate member: - - To request revisions from the author: "As the assigned Reviewer, I request from the author @author-username to address [provide concerns or suggestions]." - - To move to the next stage: "As the assigned Reviewer, I do not have any feedback for the author. I recommend moving this NEP forward and for the working group to [accept or reject] it based on [provide reasoning, including a sense of importance or urgency of this NEP]." -- The author of the proposal is free to revise the proposal and re-request reviews from reviewers. If a proposal is in the review stage for more than two months, the moderator will automatically reject it. To re-open the proposal, the author must start over with the NEP process again. -- Once the two reviewers agree that the proposal is close to the voting stage, the moderators will assign the approvers (working group) to review the NEP. The approvers will review the proposal and add their voting indication. -- The final review period by the approvers is expected to finish within one week. After completing the review, the approvers must add an explicit comment with their voting indication: - - To reject: "As a working group member, I lean towards rejecting this proposal based on [provide reasoning]." - - To approve: "As a working group member, I lean towards approving this NEP based on [provide reasoning]." -- Once all the approvers add their voting indication, the moderator will review the voting indication for a 2/3 majority vote: - - If the votes lean toward rejection: The moderator will summarize the feedback and close the NEP. - - If the votes lean toward approval: The moderator will schedule a public call (see [NEP Communication](#nep-communication)) for the author to present the NEP and for the working group members to formalize the voting decision. If the working group members agree that the NEP is overall beneficial for the NEAR ecosystem and vote to approve it, then the proposal is considered accepted. After the call, the moderator will summarize the decision on the NEP. +Each NEP must have an author: Someone who writes the NEP using the style and format described below. The author, or another champion, shepherds the discussions in the appropriate forums and attempts to build community consensus around the idea to help it progress toward completion. -### NEP Communication +Before submitting a NEP, the author should first attempt to ascertain whether the idea is NEP-able. Vetting an idea publicly before writing a NEP saves the potential author time. Asking the NEAR community first if the idea is original helps prevent effort on something guaranteed to be rejected based on prior discussions. It also helps ensure the idea applies to the entire community. Just because an idea sounds good to the author does not mean it will work for most people in most use cases. -NEP discussions should happen asynchronously within the NEP’s public thread. +In general, the process for socializing an idea is: -However, if a discussion becomes circular and could benefit from a synchronous conversation, any participants on a given NEP can suggest for the moderator to schedule an ad hoc meeting. For example, if a reviewer and author have multiple rounds of comments, they may request a call. The moderator can help coordinate the call and post the registration link on the NEP. The person who requested the call should designate a note taker to post a summary on the NEP after the call. +- **Check prior proposals:** Many ideas for changing NEAR come up frequently. Please search the [Dev Gov Gigs Board](https://devgovgigs.near.social), the [NEAR Forums](https://gov.near.org), and NEPs in this repo before proposing something new. +- **Share the idea:** Submit your [idea](https://www.neardevgov.org/blog/how-to-ideate-in-the-near-developer-governance) on the [Dev Gov Gigs Board](https://devgovgigs.near.social). +- **Get feedback:** The [Dev Gov Gigs Board](https://devgovgigs.near.social) has comment threading which allows the community to ideate, ask questions, wrestle with approaches, etc. If more immediate responses are desired, consider bringing the conversation to the appropriate [Community Group](https://gov.near.org/c/dev/community-groups/103). -When a NEP gets to the final voting stage, the moderator will schedule a public working group meeting to discuss the NEP with the author and formalize the decision. The moderator will first coordinate a time with the author and working group members, and then post the meeting time and registration link on the NEP at least one week in advance. +### Submit a NEP Draft +Following the above initial discussions, the author should submit a NEP draft into the GitHub NEP repository. The draft NEP must follow the [NEP-0000 template](https://github.com/near/NEPs/blob/master/nep-0000-template.md), or else it will fail the review immediately. -### NEP Maintenance -In general, NEPs are no longer modified after they have reached the Final state. +To submit a NEP draft as a pull request, the NEP author should: -## NEP Life Cycle +1. Fork the [NEPs repository](https://github.com/near/NEPs). +2. Copy `nep-0000-template.md` to `neps/nep-0000-my-feature.md` (where “my-feature” is descriptive; don’t assign a NEP number yet). +3. Fill in the NEP following the NEP template guidelines. For the Header Preamble, make sure to set the status as “Draft.” +4. Push this to your GitHub fork and submit a pull request. +5. Now that your NEP has an open pull request, use the pull request number to update your `0000` prefix. For example, if the PR is 305, the NEP should be `neps/nep-0305-my-feature.md`. +6. Push this to your GitHub fork and submit a pull request. Mention the @near/nep-moderators in the comment and turn the PR into a "Ready for Review" state once you believe the NEP is ready for review. + +## NEP Lifecycle +The NEP process begins when an author submits a [NEP draft](#submit-a-nep-draft). The NEP lifecycle consists of three stages: draft, review, and voting, with two possible outcomes: approval or rejection. Throughout the process, various roles play a critical part in moving the proposal forward. Most of the activity happens asynchronously on the NEP within GitHub, where all the roles can communicate and collaborate on revisions and improvements to the proposal. ![NEP Process](https://user-images.githubusercontent.com/110252255/201413632-f72743d6-593e-4747-9409-f56bc38de17b.png) -A given NEP can have one of the following states: -- **Draft**: The first formally tracked stage of a NEP in development. A NEP is merged by a NEP Moderator into the NEP repository when properly formatted. -- **Review**: A NEP moderator marks a NEP as ready for Subject Matter Experts Review. - - If the NEP is not approved within two months, it is automatically rejected. -- **Voting**: This is the final voting period for a NEP. The working group will vote on whether to accept or reject the NEP. This period is limited to two weeks. If during this period necessary normative changes are required, the NEP will revert back to Review. -- **Approved:** If the working group votes to approve, they will move the NEP to Approved. Once approved, Standards NEPs exist in a state of finality and should only be updated to correct errata and add non-normative clarifications. -- **Rejected:** If the working group votes to reject, they will move the NEP to Rejected. -- **Living** - A special status for NEPs that are designed to be continually updated and not reach a state of finality. This includes most notably NEP-0001. +### NEP Stages + +* **Draft:** The first formally tracked stage of a new NEP. This process begins once an author submits a draft proposal and the NEP moderator merges it into the NEP repo when properly formatted. +* **Review:** A NEP moderator marks a NEP as ready for Subject Matter Experts Review. If the NEP is not approved within two months, it is automatically rejected. +* **Voting:** This is the final voting period for a NEP. The working group will vote on whether to accept or reject the NEP. This period is limited to two weeks. If during this period necessary normative changes are required, the NEP will revert to Review. + +### NEP Outcomes -## NEP Roles and Responsibilities -The NEP process has various roles and responsibilities. +* **Approved:** If the working group votes to approve, they will move the NEP to Approved. Once approved, Standards NEPs exist in a state of finality and should only be updated to correct errata and add non-normative clarifications. +* **Rejected:** If the working group votes to reject, they will move the NEP to Rejected. +### NEP Roles and Responsibilities ![author](https://user-images.githubusercontent.com/110252255/181816534-2f92b073-79e2-4e8d-b5b9-b10824958acd.png) **Author**
*Anyone can participate* -- Writes proposal following the standards -- Submits proposal with prototype when ready for review and changes the status to “Draft” -- Addresses comments -- Presents to working group and incorporates necessary changes -- Provides final implementation with sufficient testing and documentation once approved +The NEP author (or champion) is responsible for creating a NEP draft that follows the guidelines. They drive the NEP forward by actively participating in discussions and incorporating feedback. During the voting stage, they may present the NEP to the working group and community, and provide a final implementation with thorough testing and documentation once approved. ![Moderator](https://user-images.githubusercontent.com/110252255/181816650-b1610c0e-6d32-4d2a-a34e-877c702139bd.png) **Moderator**
-*Assigned by working group* +*Assigned by the working group* -- Ensures proposal meets standards - - If proposal needs revisions, provides comments on improvements and keeps status as “Draft” - - If proposal does not meet standards, changes status to “Rejected” - - If proposal is ready for review, changes status to “Review” -- Coordinates working group to assign reviewers and review proposals -- Does not assess the technical feasibility or writes any parts of the proposal +The moderator is responsible for facilitating the process and validating that the NEP follows the guidelines. They do not assess the technical feasibility or write any part of the proposal. They provide comments if revisions are necessary and ensure that all roles are working together to progress the NEP forward. They also schedule and facilitate public voting calls. ![Reviewer](https://user-images.githubusercontent.com/110252255/181816664-a9485ea6-e774-4999-b11d-dc8be6b08f87.png) -**Reviewer** (Subject Matter Experts)
-*Assigned by working group* +**NEP Reviewer** (Subject Matter Experts)
+*Assigned by the working group* -- Gives feedback on proposals -- Assesses technical feasibility of proposals -- Does not have the ability to approve proposal +The reviewer is responsible for reviewing the technical feasibility of a NEP and giving feedback to the author. While they do not have voting power, they play a critical role in providing their voting recommendations along with a summary of the benefits and concerns that were raised in the discussion. Their inputs help everyone involved make a transparent and informed decision. ![Approver](https://user-images.githubusercontent.com/110252255/181816752-521dd147-f56f-4c5c-84de-567b109f21d6.png) -**Approver** (Community Working Groups)
-*Appointed by Pagoda in the bootstrapping phase* +**Approver** (Working Groups)
+*Selected by the Dev Gov DAO in the bootstrapping phase* -- Assigns reviewers to proposals -- Attends working group meetings to review proposals -- Votes to approve or reject proposals - -## What does a successful NEP look like? -Each NEP should have the following parts/sections: +The working group is a selected committee of 3-7 recognized experts who are responsible for coordinating the public review and making decisions on a NEP in a fair and timely manner. There are multiple working groups, each one focusing on a specific ecosystem area, such as the Protocol or Wallet Standards. They assign reviewers to proposals, provide feedback to the author, and attend public calls to vote to approve or reject the NEP. Learn more about the various working groups at [neardevgov.org](http://neardevgov.org/). -1. Preamble - [RFC](https://www.ietf.org/rfc/rfc822.txt)[ 822](https://www.ietf.org/rfc/rfc822.txt) style headers containing meta-data about the NEP, including the NEP number, a short descriptive title, the names, and optionally the contact info for each author, etc. -1. Summary - a short (~200 word) description of the technical issue being addressed. -1. Motivation - The motivation section should clearly explain why the existing contract ecosystem is inadequate to address the problem that the NEP solves. This can include collecting documented support for the NEP from important projects in the NEAR ecosystem. NEP submissions without sufficient motivation may be rejected. -1. Rationale and alternatives - The rationale fleshes out the specification by describing why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other platforms. -1. Specification - The technical specification should describe the syntax and semantics of the contract or protocol feature. The specification should be detailed enough to allow competing, interoperable implementations for at least the current major NEAR version. -1. Draft Implementation - A draft implementation showing the viability of the proposal must be completed before any NEP is given the “Approved” status. - While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of “rough consensus and running code” is still useful when it comes to resolving many discussions of API details. Once approved, the final implementation must include test code and documentation. -1. Security Implications - If there are security concerns in relation to the NEP, those concerns should be explicitly written out to make sure reviewers of the NEP are aware of them. -1. Drawbacks - Throughout the discussion of a NEP, various ideas will be proposed which are not accepted. Those rejected ideas should be recorded along with the reasoning as to why they were rejected. This both helps record the thought process behind the final version of the NEP as well as preventing people from bringing up the same rejected idea again in subsequent discussions. - In a way this section can be thought of as a breakout section of the Rationale section that is focused specifically on why certain ideas were not ultimately pursued. -1. Unresolved Issues - While a NEP is in draft, ideas can come up which warrant further discussion. Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution. This helps make sure all issues required for the NEP to be ready for consideration are complete and reduces people duplicating prior discussion. -1. Future possibilities - Future possibilities describes any natural extensions and evolutions to the NEP proposal and how it would affect the project. Try to use this section as a tool to more fully consider all possible interactions with the project in your proposal. Also consider how this all fits into the roadmap for the project and of the relevant sub-teams. -1. Copyright Waiver - All NEPs must be in the public domain. See the bottom of this NEP for an example copyright waiver. - -## NEP Header Preamble -Each NEP must begin with an [RFC](https://www.ietf.org/rfc/rfc822.txt)[ 822](https://www.ietf.org/rfc/rfc822.txt) style header preamble. The headers must appear in the following order. +### NEP Communication -``` - NEP: - Title: - Author: - Status: - DiscussionsTo (Optional): - Type: - Requires (Optional): - Replaces (Optional): - SupersededBy (Optional): - Created: -``` - - -`Title`: The NEP title header should not be more than 4-5 words, describing +NEP discussions should happen asynchronously within the NEP’s public thread. This allows for broad participation and ensures transparency. -`Author`: The Author header lists the names, and optionally the email addresses of all the authors/owners of the NEP. The format of the Author header value must be +However, if a discussion becomes circular and could benefit from a synchronous conversation, any participants on a given NEP can suggest that the moderator schedules an ad hoc meeting. For example, if a reviewer and author have multiple rounds of comments, they may request a call. The moderator can help coordinate the call and post the registration link on the NEP. The person who requested the call should designate a note-taker to post a summary on the NEP after the call. - Random J. User ; - Other I. User +When a NEP gets to the final voting stage, the moderator will schedule a public working group meeting to discuss the NEP with the author and formalize the decision. The moderator will first coordinate a time with the author and working group members, and then post the meeting time and registration link on the NEP at least one week in advance. -if the email address is included, and just +All participants in the NEP process should maintain a professional and respectful code of conduct in all interactions. This includes communicating clearly and promptly and refraining from disrespectful or offensive language. - Random J. User -`DiscussionsTo`: The DiscussionsTo header provides the URL to the current canonical discussion thread for the NEP. +### NEP Playbook -`Type`: The Type header specifies the type of NEP: Standards or Protocol +1. Once an author [submits a NEP draft](#submit-a-nep-draft), the NEP moderators will review their pull request (PR) for structure, formatting, and other errors. Approval criteria are: + * The content is complete and technically sound. The moderators do not consider whether the NEP is likely or not to get accepted. + * The title accurately reflects the content. + * The language, spelling, grammar, sentence structure, and code style are correct and conformant. +2. If the NEP is not ready for approval, the moderators will send it back to the author with specific instructions in the PR. The moderators must complete the review within one week. +3. Once the moderators agree that the PR is ready for review, they will ask the approvers (working group members) to nominate a team of at least two reviewers (subject matter experts) to review the NEP. At least one working group member must explicitly tag the reviewers and comment: `"As a working group member, I'd like to nominate @SME-username and @SME-username as the Subject Matter Experts to review this NEP."` If the assigned reviewers feel that they lack the relevant expertise to fully review the NEP, they can ask the working group to re-assign the reviewers for the NEP. +4. The reviewers must finish the technical review within one week. Technical Review Guidelines: + * First, review the technical details of the proposals and assess their merit. If you have feedback, explicitly tag the author and comment: `"As the assigned Reviewer, I request from @author-username to [ask clarifying questions, request changes, or provide suggestions that are actionable.]."` It may take a couple of iterations to resolve any open comments. + * Second, once the reviewer believes that the NEP is close to the voting stage, explicitly tag the @near/nep-moderators and comment with your technical summary. The Technical Summary must include: + * A recommendation for the working group: `"As the assigned reviewer, I do not have any feedback for the author. I recommend moving this NEP forward and for the working group to [accept or reject] it based on [provide reasoning, including a sense of importance or urgency of this NEP]."` Please note that this is the reviewer's personal recommendation. + * A summary of benefits that surfaced in previous discussions. This should include a concise list of all the benefits that others raised, not just the ones that the reviewer personally agrees with. + * A summary of concerns or blockers, along with their current status and resolution. Again, this should reflect the collective view of all commenters, not just the reviewer's perspective. +5. The NEP author can make revisions and request further reviews from the reviewers. However, if a proposal is in the review stage for more than two months, the moderator will automatically reject it. To reopen the proposal, the author must restart the NEP process again. +6. Once both reviewers complete their technical summary, the moderators will notify the approvers (working group members) that the NEP is in the final comment period. The approvers must fully review the NEP within one week. Approver guidelines: + * First, read the NEP thoroughly. If you have feedback, explicitly tag the author and comment: `"As a working group member, I request from @author-username to [ask clarifying questions, request changes, or provide actionable suggestions.]."` + * Second, once the approver believes the NEP is close to the voting stage, explicitly comment with your voting indication: `"As a working group member, I lean towards [approving OR rejecting] this NEP based on [provide reasoning]."` +7. Once all the approvers indicate their voting indication, the moderator will review the voting indication for a 2/3 majority: + * If the votes lean toward rejection: The moderator will summarize the feedback and close the NEP. + * If the votes lean toward approval: The moderator will schedule a public call (see [NEP Communication](#nep-communication)) for the author to present the NEP and for the working group members to formalize the voting decision. If the working group members agree that the NEP is overall beneficial for the NEAR ecosystem and vote to approve it, then the proposal is considered accepted. After the call, the moderator will summarize the decision on the NEP. +8. The NEP author or other assignees will complete action items from the call. For example, the author will finalize the "Changelog" section on the NEP, which summarizes the benefits and concerns for future reference. -`Created`: The Created header records the date that the NEP was assigned a number, should be in dd-mmm-yyyy format, e.g. 03-Mar-2022. +### Transferring NEP Ownership -`Requires`: NEPs may have a Requires header, indicating the NEP numbers that this NEP depends on. +While a NEP is worked on, it occasionally becomes necessary to transfer ownership of NEPs to a new author. In general, it is preferable to retain the original author as a co-author of the transferred NEP, but that is up to the original author. A good reason to transfer ownership is that the original author no longer has the time or interest in updating it or following through with the NEP process. A bad reason to transfer ownership is that the author does not agree with the direction of the NEP. One aim of the NEP process is to try to build consensus around a NEP, but if that is not possible, an author can submit a competing NEP. -`SupersededBy`: NEPs may also have a SupersededBy header indicating that a NEP has been rendered obsolete by a later document; the value is the number of the NEP that replaces the current document. +If you are interested in assuming ownership of a NEP, you can also do this via pull request. Fork the NEP repository, modify the owner, and submit a pull request. In the PR description, tag the original author and provide a summary of the work that was previously done. Also clearly state the intent of the fork and the relationship of the new PR to the old one. For example: "Forked to address the remaining review comments in NEP \# since the original author does not have time to address them. -`Replaces`: A newer NEP marked with a SupercededBy header must have a Replaces header containing the number of the NEP that it rendered obsolete. +## What does a successful NEP look like? -## Auxiliary Files -Images, diagrams and auxiliary files should be included in a subdirectory of the assets folder for that NEP as follows: assets/nep-N (where N is to be replaced with the NEP number). When linking to an image in the NEP, use relative links such as …/assets/nep-1/image.png +Each NEP should be written in markdown format and follow the [NEP-0000 template](https://github.com/near/NEPs/blob/master/nep-0000-template.md) and include all the appropriate sections, which will make it easier for the NEP reviewers and community members to understand and provide feedback. The most successful NEPs are those that go through collective iteration, with authors who actively seek feedback and support from the community. Ultimately, a successful NEP is one that addresses a specific problem or needs within the NEAR ecosystem, is well-researched, and has the support of the community and ecosystem experts. -## Transferring NEP Ownership -It occasionally becomes necessary to transfer ownership of NEPs to a new author. In general, it is preferable to retain the original author as a co-author of the transferred NEP, but that is up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the NEP process. A bad reason to transfer ownership is because the author does not agree with the direction of the NEP. One aim of the NEP process is to try to build consensus around a NEP, but if that is not possible, an author can submit a competing NEP. +### Auxiliary Files -If you are interested in assuming ownership of a NEP, you can also do this via pull request. Fork the NEP repository, make your ownership modification, and submit a pull request. In the PR description, tag the original author and provide a summary of the work that was previously done. Also clearly state the intent of the fork and the relationship of the new PR to the old one. For example: "Forked to address the remaining review comments in NEP # since the original author does not have time to address them." +Images, diagrams, and auxiliary files should be included in a subdirectory of the assets folder for that NEP as follows: assets/nep-N (where N is to be replaced with the NEP number). When linking to an image in the NEP, use relative links such as .../assets/nep-1/image.png -## Style Guide +### Style Guide #### NEP numbers -When referring to a NEP by number, it should be written in the hyphenated form NEP-X where Xis the NEP’s assigned number. + +When referring to a NEP by number, it should be written in the hyphenated form NEP-X where X is the NEP's assigned number. #### RFC 2119 -NEPs are encouraged to follow [RFC](https://www.ietf.org/rfc/rfc2119.txt)[ 2119](https://www.ietf.org/rfc/rfc2119.txt) for terminology and to insert the following at the beginning of the Specification section: -The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. +NEPs are encouraged to follow [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) for terminology and to insert the following at the beginning of the Specification section: + +The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). + +## NEP Maintenance + +Generally, NEPs are not modifiable after reaching their final state. However, there are occasions when updating a NEP is necessary, such as when discovering a security vulnerability or identifying misalignment with a widely-used implementation. In such cases, an author may submit a NEP extension in a pull request with the proposed changes to an existing NEP document. + +A NEP extension has a higher chance of approval if it introduces clear benefits to existing implementors and does not introduce breaking changes. + +If an author believes that a new extension meets the criteria for its own separate NEP, it is better to submit a new NEP than to modify an existing one. Just make sure to specify any dependencies on certain NEPs. ## References -The content of this document was derived heavily from the PEP, BIP, Rust RFC and EIP standards bootstrap documents: +The content of this document was derived heavily from the PEP, BIP, Rust RFC, and EIP standards bootstrap documents: * Klock, F et al. Rust: RFC-0002: RFC Process. https://github.com/rust-lang/rfcs/blob/master/text/0002-rfc-process.md * Taaki, A. et al. Bitcoin Improvement Proposal: BIP:1, BIP Purpose and Guidelines. https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki