# EIPs TODO

Also realised there’s two other things which can be done:
1) Check all drafts if there is still anyone pursuing them, if not mark them abandoned
2) Check if those which aren’t abandoned have a discussion-to URL
The goal for 2020 would be to reduce pending PRs to a dozen, to clearly mark abandoned EIPs and to get most of the others to Final state.

Goals 2020 Q1:
- Reduce the number of PRs
- Reduce the number of abandoned drafts
- Move a bunch of ERCs to the Final status

Steps/Issues:
1. A lot of drafts don't conform to EIP-1 (e.g lacking a discussion URL)

### Autoprocessing of EIPs through the Bot
James: Bot to mark EIPs/ERCs "Inactive" after 6 months, and "Abandoned" 6 weeks later.

### Decouple EIP standarization Process and Network upgrade Choice


Update EIP statuses, Carve out large sections from EIP 1.
For things to be async we would need to Clarify many definitions:
- Define a Core client (Who gets a say/who can block)
- How is community sentiment included? Accountability
-

### EIP Status Definition v2
https://hackmd.io/QkVQBECwSESgPWqqIqtzYA

digraph EIP{
rankdir=LR
concentrate=true

Idea -> Draft; 
Draft -> Review;
Draft -> Stagnant;
Draft -> Withdrawn;
Stagnant -> Draft;
Stagnant -> Withdrawn;
Review -> LastCall;
Review -> Withdrawn
Review -> Living;
Living -> Review;
Review -> Stagnant;
LastCall -> Review
LastCall -> Final;
LastCall -> Withdrawn;
}

**Draft**
The first formally tracked stage of an EIP in development. An EIP is merged into the repository when properly formatted by an EIP Editor.

**Review**
An EIP Author marks an EIP as ready for and requesting Peer Review.

**Last Call**
This is the final review window for an EIP before moving to `FINAL`. An EIP editor will assign `Last Call` status and set a review end date (review-period-end), typically 14 days later.

If this period results in necessary material changes it will revert the EIP to `REVIEW`.

**Final**
This EIP now represents the final accepted standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-material clarifications.

**Stagnant**
Any EIP in `DRAFT` or `REVIEW` if inactive for a period of 6 months or greater is algorithmically moved to `STANGNANT`. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to`DRAFT`.

>*EIP Authors are notified of any algorithmic change to the status of their EIP*

**Withdrawn**
The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number. If the idea is pursued at later date it is considered a new proposal.

**Living**
A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes most notably EIP-1. Any changes to these EIPs will move between `REVIEW` and `LIVING` states.

### Update EIP Information framework.
Expand EIP 1 into the document that houses all processes, including ToC to make it navigatable.
- Hard fork
- EFI

Make other Meta EIPs into Registries only.
- Fork Meta
- EFI Definitions
- EIP Number Registry
- Change to Hex 0x____
- Final Decimal EIPs to end at 3000
- EIP number is decided by a PR to the Number Registry Document.
- Numbers arbitrated by the EIP Editors.
- EIP Facilitators

#### Registry EIPs
Registry EIPs contain lists that are maintained, while the main definitions are put into EIP-1.
- EIP Numbers
- Add PM Role (EIP Facilitators)https://docs.google.com/document/d/1kCQ-XwziJl0CDsay4B_kR5PdXdkrivlFrPecruWZ_Ns/edit
- Permission from autobot to edit Process Tracking Section
- A good stepping stone for identifying EIP Editors
- Supported Networking Protocols

### EIPs.Ethereum.org Data Feed
Deployed as a Datafeed people can subscribe too.
Example: http://feeds.bbci.co.uk/news/world/us_and_canada/rss.xml

More custom Feed options baked in.
- Per Status
- Per Category

Decouple changes to the EIP repo and the rendering of EIPs (This is currently a blocker to updates to the EIP repo)

Easily extensible for others to create their own readers
- Parsing the EIP repo is difficult. A simple Data feed

---

### Process Tracking Footer

Admin By the Facilitators

## EFI Pipeline Tracking

**Goal:** illuminate the maturity of an EIP and track its progress. My hypothesis is that by visibly tracking these steps Authors will be more motivated to fullfil requirements and document their progress, and it will give core devs a list of EIPs sorted by how far they are along.

*The later is also something that Peter requested on an ACD calls before*
- Tracking the EFI Process

Examples of tracking Documents for the Constantinople upgrade:


### Rename Certain Status's
- Rename EFI to something that is more descriptive
- Accepted ->

Notes on EFI
I don't think EFI should be a status. It should be part of tracking the maturity of an EIP and be done in the Process Tracking Footer. This would allow more steps to be tracked.

### Other Thoughts

As part of a post-mortem on the ice-age, I realized that one one of the issues that led up to it is that current global information about the chain is spread across all of the EIPs. It takes a lot of digging to figure out certain things.

Also, previously Alexey pointed out that another issue is the current state of EIPs.