Skip to content
94 changes: 94 additions & 0 deletions .github/ISSUE_TEMPLATE/eip-tracker.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,94 @@
name: "EIP Implementation Tracker"
description: "Track specification and testing progress for an EIP"
title: "EIP ${{ form.eip_number }} Progress Tracker"
labels:
- A-spec-specs
- A-spec-tests
- C-eip
- C-test

body:
- type: input
id: eip_number
attributes:
label: "EIP Number"
description: "Enter the EIP number (digits only)."
placeholder: "e.g., 8024"
validations:
required: true

- type: input
id: eip_title
attributes:
label: "EIP Title"
description: "Copy the title from the EIP."
placeholder: "e.g., Backwards compatible SWAPN, DUPN, EXCHANGE"
validations:
required: true

- type: dropdown
id: fork
attributes:
label: "Fork"
description: |
Specify the target fork **only if the EIP has reached the CFI stage**.
More info: https://eips.ethereum.org/EIPS/eip-7723#considered-for-inclusion
options:
- TBD
- amsterdam
- bogota
validations:
required: true

- type: markdown
attributes:
value: |
## [EIP-${{ form.eip_number }}](https://eips.ethereum.org/EIPS/eip-${{ form.eip_number }})

### Target Fork

Fork **${{ form.fork }}**

### Instructions

- [ ] Assign issue to EIP specification and testing owner(s).

> [!IMPORTANT]
> A specifications specialist and a testing specialist should ideally share ownership of the EIP.

- [ ] Add the issue to the target fork milestone if applicable (i.e., the EIP is at least in the [CFI stage](https://eips.ethereum.org/EIPS/eip-7723#considered-for-inclusion)).

#### Guidance for Marking Items Complete

An item should only be checked off once the EIP is considered *stable*. In this context, stable means:

- No major issues or ambiguities are still being uncovered in the specification or tests.
- There are no open discussion points awaiting resolution.
- Client implementations have been consistently passing the tests for at least a week.

It is ultimately up to the owners' discretion to decide when an item should be marked as complete, using this guidance as the basis for that decision.

In exceptional cases, an EIP may require changes after some items have been marked complete or even after the entire issue has been completed and closed. This can happen, for example, when significant design optimizations are identified and agreed upon in ACD, or when critical security issues surface and require updates to the specification or tests.

When this occurs, owners should either unmark the relevant checkboxes if the issue is still open, or create a new tracking issue for the modifications if the original issue had already been closed.

### Specification + Testing Status

- [ ] Testing complexity assessed and documented.
- [ ] Specification implementation merged to `eips/${{ form.fork }}/eip-${{ form.eip_number }}` *(skip if the fork branch merge below is already complete)*.
- [ ] Specification updates merged to the corresponding `forks/${{ form.fork }}` branch.
- [ ] EIP updates proposed in case of architectural choices surfaced during implementation.
- [ ] Required testing framework modifications implemented.
- [ ] Test suite implemented.
- [ ] Full code coverage for all changes.
- [ ] No regressions or failures in tests from prior forks (including static tests).
- [ ] [Testing checklist](https://github.com/ethereum/execution-specs/blob/HEAD/docs/writing_tests/checklist_templates/eip_testing_checklist_template.md) complete.
- [ ] Hardening session completed.
- [ ] Benchmarking tests written and results documented.
- [ ] Ran tests using `execute` to ensure compatibility, and marked specific tests to be skipped when they cannot be executed on live networks.
- [ ] Added Mainnet-marked tests ([example test](https://github.com/ethereum/execution-specs/blob/2a6f9ee98ba7c0d04c7d523a0ea0ee8a98a5c418/tests/osaka/eip7939_count_leading_zeros/test_eip_mainnet.py)).

### Process Status

- [ ] Hive tests passing on at least two implementations.
- [ ] EIP included in a devnet.
Loading