Move away from Github Projects to Mardown to track CFI

[timbeiko]

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:

• Proposal to have "Considered for Inclusion" reset after each upgrade pm#295 (comment)
• Proposal to have "Considered for Inclusion" reset after each upgrade pm#295 (comment)

cc: @holgerd77

[poojaranjan]

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]

@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:

• EIP Number & name (with link to EIP)
• AllCoreDevs issue where it is proposed for inclusion in a specific upgrade
• CFI Acceptance (with a link to, ideally, timestamped Youtube, but at least the ACD call agenda)

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]

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]

@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 😅