search

ethereum / execution-specs

Specification for the Execution Layer. Tracking network upgrades.
Creative Commons Zero v1.0 Universal
866 stars 240 forks source link

Move away from Github Projects to Mardown to track CFI #23

Closed timbeiko closed 5 months ago

timbeiko commented 3 years ago

As part of the discussion on ethereum/pm related to resetting CFI between upgrades, it was proposed to stop using Github Projects and move to markdown files instead. To separate the discussions, I'm opening this issue specifically to track the Github Projects/Markdown coversation.

Relevant comments:

cc: @holgerd77

poojaranjan commented 3 years ago

I find the project board simpler for those who just want to know what are the proposals and it's status for upgrades. I'd prefer to provide the link to EIP (from eips.ethereum.org) and the additional details like upgrade name & when proposed, CFI approval date etc. in the card for those interested to dig deep.

I am also fine with xzy.md format. A suggestion (@timbeiko), instead of agenda, (timestamped) video can be added as notes submission will take time and agenda won't provide the clarity that it was CFI approved.

timbeiko commented 3 years ago

@poojaranjan why do you find the board easier than looking at a markdown file? Personally I've found the opposite 😅 ! Also, I like the idea of having a separate .md file per network upgrade so we can better track parallel upgrades and their relative CFI lists. Not a super strong preference, though.

With regards to what fields are necessary, I think the following makes sense:

I don't think we should track the devnets / testnets / etc. in the same file, though: if something is in the devnet spec, then it's in. This way, if we decide to not move something from one stage to the next, we just don't add it to the next devnet spec, but can leave it as CFI for this upgrade.

I'm not sure we should track CFI "proposed" and "rejected" EIPs, but that's a weak preference. Happy to go back and look at the ones we rejected for London already if people think that's valuable.

poojaranjan commented 3 years ago

why do you find the board easier than looking at a markdown file?

@timbeiko For client devs and implementers, .md format is good. It is what a Meta EIP for an upgrade used to be.

However, the project board provides high-level information with more visibility for the less technical community. eg. Eth2 Phase 0 board.

Having said that, I suspect major changes in the process coming up with the Merge. So, whatever works best, I am fine with that!

timbeiko commented 3 years ago

@poojaranjan got it. Yeah, I think that the board works well for specific tasks, but given that CFI is more "tracking status" than "doing tasks", I'd favor a .md. Agreed we have a lot we'll need to clean up with the merge 😅