We should not be encouraging users to put tests elsewhere and link to them. Instead, we should be recommending users inline or include in ../assets any test cases that are applicable to the EIP.
* Add description field to the EIP header
* Update 2718
* Move description rendering to below the title
* Remove the simple summary from the template
This has been removed from EIP-1 on 15-09-2019 in the PR https://github.com/ethereum/EIPs/pull/2186.
* Update title/description/abstract with new recommendation
* Mention length limit of description
* Rewords Motivation section of template.
While this section is more clear to EIP authors than most, it still requires coaching. Also, the wording was written back when EIPs were tightly coupled with hard fork coordination, which is no longer the case.
* Improved wording.
Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>
Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>
* Adds words to abstract definition.
I have to coach almost every EIP author on what the abstract is, integrating into the template will hopefully help with that process.
* Improved wording.
Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>
Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>
In reality, the `Implementation` section almost always involves someone linking out to a personal or company repository when they create an EIP from the template. External repositories cause problems because:
1. Links move/change over time and eventually the link will be dead.
2. The implementation likely isn't CC0 as the EIP is, and naive users may follow the link not realizing it is GPL and they are screwing themselves legally.
3. People are using EIPs for advertising their project, and they look for any opportunity they can to link out to their project in the body of the EIP.
4. People often link to some monolithic repository (e.g., go-ethereum) as the "implementation" which is less than useful.
Also, the description was written back when EIPs were part of the hard fork coordination process, so that has been rewritten.
This change makes it so it is more clear that this section is optional and that external links are not the preferred solution to completing this section.
EIPs are technical documents, not part of the hard fork coordination process aside from being an asset in that process. Consensus and politics are not relevant to EIPs.
* Try to clarify the meaning of EIP fields
* Remove unhelpful extra comments in the template
* Change EIP-1491 from CRLF to LF
* Remove template comments from EIPs
* Fix heading: Abstarct -> Abstract
* Update EIP-2014
* Change author list of EIP-1
* add mandatory "security considerations" to EIP-1 and template EIP-x
* security considerations: clarify wording and process
* security considerations: update eip-1
* Add updated date to EIP-1
Co-authored-by: Alex Beregszaszi <alex@rtfs.hu>
* EIP-1: make category field in EIP more clear
* Better heading in README
* EIP-2: fix typo in rendering
* EIP-1: clarify that an EIP can move from the Abandoned status to the Draft status
Also clarify that EIPs cannot move from the Rejected and Superseded states.
* EIP-1: rename WIP status to Idea
* EIP-1: change template formatting to fix markdown rendering
With angle brackets markdown renders them as HTML tags sometimes (depending on the rendering engine).
* EIP-1812: change copyright link to the correct CC0 link
