Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apply trivial fixes to NEP-1 #107

Merged
merged 1 commit into from
Nov 13, 2019
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions nep-1.mediawiki
Original file line number Diff line number Diff line change
Expand Up @@ -33,13 +33,13 @@ The NEP process begins with a new idea for NEO. It is highly recommended that a

Each NEP must have a champion - someone who writes the NEP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea.

Vetting an idea publicly before going as far as writing an NEP is meant to save the potential author time. Asking the NEO community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where NEO is used. Examples of appropriate public forums to gauge interest around your NEP include [https://www.reddit.com/r/NEO the NEO subreddit], [https://github.com/neo-project/proposals/issues the Issues section of this repository], and [http://slack.neo.org one of the NEO Slack channels]. In particular, [https://github.com/neo-project/proposals/issues the Issues section of this repository] is an excellent place to discuss your proposal with the community and start creating more formalized language around your NEP.
Vetting an idea publicly before going as far as writing an NEP is meant to save the potential author time. Asking the NEO community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where NEO is used. Examples of appropriate public forums to gauge interest around your NEP include [https://www.reddit.com/r/NEO the NEO subreddit], [https://github.com/neo-project/proposals/issues the Issues section of this repository], and [https://discord.io/neo the NEO Discord]. In particular, [https://github.com/neo-project/proposals/issues the Issues section of this repository] is an excellent place to discuss your proposal with the community and start creating more formalized language around your NEP.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@corollari, this part is looks wrong:

" [https://github.com/neo-project/proposals/issues the Issues section of this repository]"
Perhaps the link needs a ] before

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just double checked and it should be alright, maybe the confusion stems from the fact that these are mediawiki-style links instead of markdown-style ones?


Once the champion has asked the NEO community whether an idea has any chance of acceptance a draft NEP should be presented as a pull request. This gives the author a chance to continuously edit the draft NEP for proper formatting and quality. This also allows for further public comment and the author of the NEP to address concerns about the proposal.

If the NEP collaborators approve, the NEP editor will assign the NEP a number, label it as Standards Track, Informational, or Meta, give it status "Draft", and add it to the git repository. The NEP editor will not unreasonably deny an NEP. Reasons for denying NEP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the NEO philosophy.

Standards Track NEPs consist of three parts, a design document, implementation, and finally if warranted an update to the formal specification. The NEP should be reviewed and accepted before an implementation is begun, unless an implementation will aid people in studying the NEP. Standards Track NEPs must include an implementation -- in the form of code, a patch, or a URL to same -- before it can be considered Final.
Standards Track NEPs consist of three parts, a design document, implementation, and finally if warranted an update to the formal specification. The NEP should be reviewed and accepted before an implementation is begun, unless an implementation will aid people in studying the NEP. Standards Track NEPs must include an implementation -- in the form of code, a patch, or a URL to some -- before it can be considered Final.

For an NEP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.

Expand Down