Update EIP-1: EIP pain relief #7230
Conversation
File
|
github-actions
bot
added
c-update
github-actions
bot
added
w-ci
github-actions
bot
added
c-update
EIPS/eip-1.md
Outdated
| A PR moving an EIP from Last Call to Final SHOULD contain no changes other than the status update. Any content or editorial proposed change SHOULD be separate from this status-updating PR and committed prior to it. | ||
| - **Idea** - An idea that is pre-draft. This is not tracked within the EIP Repository. | ||
| - **Draft** - The first formally tracked stage of an EIP in development. An EIP is merged by an EIP Editor into the EIP repository when it meets some initial requirements: It should be technically sound, the Title and Preamble must be correct, and all included Sections should be readable. Problems with language like spelling, grammar, markup, etc. are only considered warnings. | ||
| - **Review** - An EIP Author marks an EIP as ready for and requesting Peer Review. An Editor will merge the EIP when it meets all EIP requirements: it should be a technically sound, complete specification, properly formatted, with correct language, markup and external references. |
There was a problem hiding this comment.
The wording here feels a bit off.
There was a problem hiding this comment.
Agreed. Just a sketch to get discussion started.
github-actions
bot
added
c-update
|
| <!--- markdownlint-capture ---> | ||
| <!--- markdownlint-disable code-block-style ---> |
There was a problem hiding this comment.
The dashes are from an ill-advised global search-and-replace. I've fixed them, but the bot, in it's infinite wisdom, suddenly decided that the DOI example -- which has been there since 2022-- must now be fixed before I can check in my changes. And since I am a second-class editor I can't override it.
There was a problem hiding this comment.
Following is the error that just popped up. I cannot find any difference to explain why it suddenly complained.
There was a problem hiding this comment.
This is a sentence with a footnote.[^1]
[^1]:
```csl-json
{
Check failure on line 500 in EIPS/eip-1.md
GitHub
Actions
/ Markdown Linter
Code block style [Expected: fenced; Actual: indented]
EIPS/eip-1.md:500 MD046/code-block-style Code block style [Expected: fenced; Actual: indented]
"type": "article",
"id": 1,
"author": [
There was a problem hiding this comment.
It's always complained about this.
There was a problem hiding this comment.
Also, the markdownlint bot isn't a required check.
There was a problem hiding this comment.
OK, thanks. It does seem to be generating bad output at the end of the document, and I don't know how I broke it.
| @@ -4,6 +4,7 @@ title: EIP Purpose and Guidelines | |||
| status: Living | |||
| type: Meta | |||
| author: Martin Becze <mb@ethereum.org>, Hudson Jameson <hudson@ethereum.org>, et al. | |||
| discussions-to: https://ethereum-magicians.org/t/update-eip-1-eip-pain-relief-7230/15082 | |||
|
The commit 3675990 (as a parent of d6d3513) contains errors. |
|
|
||
| If the EIP isn't ready, the editor will send it back to the author for revision, with specific instructions. | ||
| If the EIP isn't ready, the editor will send it back to the author with instructions for revision and possibly a request for review by Technical Peers. |
There was a problem hiding this comment.
| If the EIP isn't ready, the editor will send it back to the author with instructions for revision and possibly a request for review by Technical Peers. | |
| If the EIP isn't ready, the editor will send it back to the author with instructions for revision and possibly a request for review by Technical Peers. |
There was a problem hiding this comment.
+1 to the suggestion. Would it make sense to get more specific and recommend a particular WG that they get review from as well?
|
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
|
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
github-actions
bot
added
w-stale
|
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
|
This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
This draft PR is very much a work in progress. So far it tries to alleviate some known pain points in the EIP process. These include
Note: This is independent of whether to split the repo.
Note: The intent is that once an EIP is a Draft the Core Developers will have full control of their workflow until the EIP reaches FInal. The stages of their workflow are not defined by the Editors. The Editors should never be in the position of blocking an upgrade.
To begin with the last:
The Editors and the Developers are fairly independent organizations, with the Editors trying provide the services needed to publish a consistent series of high-quality EIPs. We had envisioned (years back) that most proposals would arrive via independent Working Groups. For the most part working groups didn't happen except, de-facto, the Core Developers.
We propose to clarify the status of Working Groups, and to treat the Core Developers as an independent Working Group, responsible for the specification of Core EIPs and in control of their own workflow.
The Editorial stages for WG EIPs are reduced to three: Draft, Final, or Withdrawn. Anything in between is part of the WG workflow, and should be tracked as such. The formatting and notational requirements for a Specification, its relationship to other specifications, none of these are editorial concerns. They belong to the Working Group.
The Editors retain responsibility for publishing a high-quality series of standards. To that end we maintain the overall requirements for spelling, style, headers, citations, overall format (Abstract ... References ...) and the like. (Some core developers are already serving as editors, so we have a start on coordination.)
For the rest:
We propose to relax the enforcement of EIPW rules for Drafts, enforcing tighter rules only on changes of Status. This should reduce a lot of the friction in the workflow.
Our policy of accepting only a limited range of URLs has caused much pain. We propose to relax that policy. We allow wide editorial and working group discretion on the careful use of external resources, in line with IETF practice. All references must include full citations with authors, title, and publication information, including available DOIs. This helps to ensure that over time external resources can almost always be found somewhere.
We add a few optional headers for use by Working Groups to track their workflow.
We propose to introduce the role of Technical Peers -- volunteers with relevant expertise who can help Authors review their work at the Idea stage. Editors may ask for them when a proposal needs more technical review than the Editors are able to give it. This should help to reduce the strain on the Editor's and increase the quality and general usefulness of proposals, especially ERCs.
EDITED 2023-08-01