Skip to content

Instantly share code, notes, and snippets.

@kdenhartog
Last active May 15, 2023 10:52
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save kdenhartog/5396387cd63d8dd85499b6ee8e843364 to your computer and use it in GitHub Desktop.
Save kdenhartog/5396387cd63d8dd85499b6ee8e843364 to your computer and use it in GitHub Desktop.

EIP-6963 Development Repository

Why create a separate space dedicated to a single EIP?

Today, much of the discussions to develop a standard within the Ethereum community happens across many different channels that are not always easy to find or possible to access without an invite. For example, the conversation to drive this EIP-5749 and now EIP-6963 forward has moved between Telegram channels, Twitter, Discord Servers such as All Wallet Devs, and Ethereum Magicians. This makes for a difficult experience to follow the movement of the specification unless you can track the many different channels where conversations are occurring. Especially if you don't have an invite such as to the private Telegram channels. Furthermore, when conversations are being had across a variety of different channels it creates an incomplete archival of why certain decisions were made forcing us to revisit many different conversations even when no new points have been made. So, by moving the official communications to a github repository we're able to leverage the tools to converge conversations and move the spec to a completion while maintaining a great historical record of why certain decisions are made.

How can a member of the community contribute?

As a group, we have a few ways in which people can participate in sheparding the specification forward to the final status as an Ethereum. Here's the suggested way for members of the community to contribute to this specification.

  1. If you see an issue open an issue within this repository to kick off a discussion. The goal of an issue is to lead to a pull request to modify the spec and it's the responsiblity of the assignee on the issue to drive consensus on the issue and author a PR that gets merged.
  2. Once a PR has been opened we'll leave it open for a minimum of 7 days to give a sufficient time for people to comment and at the point when we have rough consensus (not absolute consensus) around merging the PR can be merged.
  3. At set time periods we will cut a draft-version of the spec and merge the updated draft to the EIP repository
  4. TBD if we'll also create bi-weekly calls to work through issues

Timeline

The goal of this is to achieve a finalized spec that's interoperably implemented with tests in the test suite by December 31st, 2023

To achieve this we'll aim to hit the following deadlines:

  1. Feature freeze - September 31st, 2023 no major normative changes to be made after this point
  • First version cut: May 20th, 2023
  • Second version cut: June 20th, 2023
  • Third version Cut: August 20th, 2023
  • Feature freeze cut: September 31st, 2023
  1. Test suite development - October 31st, 2023 at this time we should have a robust set of tests within the test suite for implementers to be able to test their implementation for interoperability
  2. Implementation period - September 31st to November 31st, 2023 - this is the time for implementers to implement and provide final feedback about concerns discovered during implementation. This period may lead to normative changes to the spec so be prepared to adapt.
  3. Final call period - November 31st, 2023 to December 15th, 2023 This is the period for final objections to be voiced and addressed by the broader community. It gives a chance for non-active participants to signal any last concerns before the spec is finalized
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment