Meet our EIP Editor

Transcript

The next speaker here could not join us in person, but he definitely has a message that you would not want to miss. He is our own editor Sam Wilson who is going who is going to guide us through the entire EIP process of documentation. Um, we do have a video from him. I would request an AV team to maybe put it on. Yes, that's perfect. So, it is uh it was supposed to be a workshop but unfortunately we could not connect with him on Zoom right now. So, instead he sent us an recorded video which we are going to play right now. But if you guys have any question, I'm happy to take uh maybe I can respond as much as I can.

Otherwise, I would invite everyone to join us on EIP editing office hour that happens almost every Tuesday at 1600 UTC. But people can know about it in advance uh by checking out the Ethereum/PM GitHub repository as well as Ethereum uh calendar, Google calendar if you if you are subscribed to it already. Yeah. So, can we go ahead with the video please? Hi, welcome to the EIP summit at Dev Connect. I'm one of the EIP ERC editors. My name is Sam Wilson and I've been asked to talk a little bit about the EIP process, what makes a good EIP submission and you know what authors can do to kind of make the editor's jobs easier. So I guess a little bit about me first. I work on the steel team at the

Ethereum Foundation. That's the specifications and testing in the Ethereum execution layer. We work on a Python reference implementation of the Ethereum protocol and that gives us a pretty good overview of how Ethereum works and gets us really deep into the whole specification process. Yeah. So, I guess let's talk about what makes a good EIP submission. If you're not familiar with the EIP process, the first thing you have to do is open a uh forum thread on the Fellowship of Ethereum Magicians forum. This kind of gives you a a starting point to discuss with other authors and other people involved with the community about your proposal, whether that's EIP or ERC. This helps avoid duplicate proposals and kind of collects people's thoughts into a single

proposal for a particular topic. We don't need, you know, 300 different soulbound token standards. We need one soulbound token standard. And if that coordination is done before the proposals are written, there's more opportunity for collaboration. Once you've kind of reached consensus on a topic and how you want to implement it, then the next step is to open a pull request with kind of a draft of your proposal. It doesn't have to be complete. It doesn't have to be technically finished. It just needs to give a kind of overview of the solution that you're trying to propose and that's good enough for a draft. Eventually, an EIP editor will take a look at your draft. We'll provide some feedback mostly on formatting and adherence to

our rules. An important thing to note is that EIP editors do not generally provide technical feedback. We only provide formatting, grammar, that kind of thing. Technical feedback is the responsibility of the author themselves. They have to find the correct reviewers for a proposal. If it's a core proposal, like an EIP, your reviewers are probably going to be core devs. If your proposal is an ERC, you need to find people in that particular subject areas. So, for example, if you're writing a new RPC endpoint proposal, you're going to want to talk to wallet developers. You're going to want to talk to client library developers. Figuring all of that out is kind of the first step. Once the proposal is technically finished, then you can move that proposal into the

review stage. Again, this is a a poll request and an EIP editor will take a look at your proposal. Once approved, your proposal will move into review. This is really where your proposal should be finished and technically complete. This is where you're going to be getting the majority of your feedback. Once you as the author are happy that your proposal has received enough feedback, you open a poll request to move it into last call. It's generally 2 weeks and once that's complete, you can move into the final stage. Something to note that's very important that a lot of authors miss about EPS and ERC's is that once a proposal goes final, it can no longer be edited. Any future changes have to be made in a new proposal with a new number. So it's very important to get

your proposal correct before you move into final. We want the EIP and ERC repositories to kind of stand alone as an archive of the decisions made in Ethereum. That kind of has some implications that are kind of annoying for authors and trust me they're annoying for us editors as well. The biggest one is external links. So let's say you know you're writing your proposal and you want to link to Vitalik's blog post on a topic or you want to link to a company's press release about a new technology they're proposing. Unfortunately we don't allow that because links change these things disappear and it's very important that we have a complete record of the decisions made in Ethereum. So we do provide some kind of tools to cope with this. The one we prefer, generally

speaking, is if the content is under a compatible license, you can move it into your assets directory and then you can link to it from there. That way, the content lives forever alongside the EIP itself in our repository. If the license isn't compatible, which is unfortunately pretty common, we do have some exceptions for links that you're allowed to make. The big one is for academic papers. Anything that's assigned a DOI number, you can use as an external link. There are some examples in EIP1 of how to site those things. There are also exceptions for RFC's like IETF RFC's U3 standards. Generally speaking, we'll allow any document source that has existed for a long time and is likely to continue to exist. But if you find

something that isn't allowed, you can ask us to make an exception and there's a good chance we'll do it. For more information on that, you can take a look at EIP5757. Let's see, what are other common challenges that authors face? A big one that I always notice in proposals is um the difference between rationale and motivation or rather I should say motivation then rationale. So motivation is where you kind of explain why your proposal is necessary where the rationale explains the choices that you make in the proposal itself. So kind of a contrived example here. Let's say we're making a proposal to build a shed to store uh let's say an Ethereum server, right? We need this the motivation answers the question. We need this shed to keep the rain off the

server. We need this shed to provide physical security for the server. So the motivation answers the general questions of you know why we need the shed. Whereas the rationale would answer questions like we painted the shed red because that is the style of the time or we decided to make the shed out of steel to provide increased security. So the rationale section provides information on why you made choices in the proposal itself. how the EIP process has evolved. That's an interesting one. So, I've been an EIP editor for a couple years now. I wasn't with the program when it started, but uh I've definitely been here a while. I've kind of seen the EIP process evolve and I've kind of shephered a little bit of the evolution. So, earlier

on in the process, it was very informal, very rough consensus based and that definitely had its advantages. it was much more easy for editors to kind of come to decisions and and difficulties. But over time, that became a bottleneck in our decision-m process. So, we formalized our decision-m process into the EIP editor's handbook. The number escapes me at the moment, but if you're curious, you can go read that proposal about how we make our decisions, what criteria we use, what our overall goals are. It's kind of our manual of how to be an EIP editor, at least on the governance side. So that's that's probably the biggest evolution recently is codifying our I don't want to call them bylaws but bylaws. How editors and

authors can collaborate more efficiently. So the primary point of contact between editors and authors is through poll requests. I do also run office hours as do some of the other editors. The schedule is available on the Ethereum/PM GitHub repository. Following our rules is probably the biggest thing. If you look at EIP1 and other proposals and just try to copy how they have successfully been merged, newer proposals for sure, don't be copying like ERC20. Yeah. So using EIP1, looking at other proposals and just having everything ready before an EIP editor gets to your poll request is going to help us immensely. Another one is responding quickly to feedback. So, if

we leave a comment on your poll request, you know, resolve it as fast as possible so it doesn't sit there. That'll help us out a lot because we do have something like over 200 poll requests right now. And the faster we can get through them, the better. Any advice for new contributors or future editors? Future editors, uh, is a little bit easier to answer. You're going to want to talk to existing editors and figure out what their individual criteria are for adding a new editor. So, personally for me, I like to see a history of successful edits, successful reviews on pull requests. So, if you're planning to become an editor, start leaving useful feedback on other people's poll requests, and that'll be super helpful for us and demonstrate your ability as an editor. And another one here is just alignment with Ethereum in general. So,

we want to see that you believe in decentralization, credible neutrality, and believe in Ethereum itself, that there's a reason to build this platform and that you're passionate about it. And that's probably the biggest criteria that I have personally for becoming an editor is just being passionate about Ethereum. It's also important to note that you don't need a hugely technical background to be an editor. Most of our job is reviewing grammar, spelling, and adherence to content rules. And that's intentional so that we can get more people involved in the EIP editing process. As for new contributors to the repository, that depends on what type of contributor you are. If you're a software developer, there's a rewrite project that I've been putting off for a

year now. I would love to get some help on that. It's uh written in Rust. So if you're a Rust developer and you want to get involved, hit me up. I could definitely use the help. If you're, you know, more on the product side or on the, you know, just enthusiast side, just providing useful feedback to other people is the the biggest thing. Yeah, I think that's pretty much it. Anyways, yeah, so thanks for coming to the EIP summit. I'm sorry I couldn't be there in person and uh hopefully talk to you soon. >> Thank you so much, Sam. Sam is one of the most active editors we have around and he always shows up for office hour.

Uh you could also talk to him uh outside the office hour. You can join our discord, the EC discord where there's a dedicated channel for EIP editors and um yeah of course you can share questions. Sam did mention about the process in general and he he mentioned about the subject matter expertise. Yes, we are looking for people who can be a subject matter expertise for uh either on protocol side or on the application side. If you are interested, we do run a program which is to onboard EIP reviewers. So please reach out to us and we would be happy to include you and uh make make you uh a participant of the program that we are trying to run over

here. Uh earlier this morning we also noticed a presentation by Dan and Rahul where he shares the idea of future uh process improvement how we can have reviewers assigned technical reviewers assigned for maybe for core proposals. I don't know if that was uh intending for application side as well or not but yes there that is still a dream. I believe it is possible would we will have to look into the process and we will need more participants to help out with that process. So if you have any expertise any interest in helping out with making Ethereum standards please reach out to us. Last but least um Sam did mention

about uh the support that we are looking. So basically we do have multiple bots which are running on Ethereum/ EIP's and ERC's repository and we are looking to improve the bot in order to minimize human intervention to make the proposal move forward. If you have expertise with Rusbot or any other bot that we are currently running on Ethereum/ EIP GitHub repository, please reach out to us and we'll be happy to introduce you to the team and be uh very very thankful to you for helping us with the bot which can help us improve our process.