 Alrighty, this is a very formal session, as you can imagine. I think we have to open the meeting first. Oh, sorry, yes, yes. Would anyone move to open the meeting? Move in, not out. Is that one second? The basic idea of the whole session is, look at the different ways that we make a standard to the period. Is there a different bit of the puzzle, different approaches to doing it? What are we doing in each place? How does it work? What do we like about each approach? And we learn because each place has different constraints and different factors that influence what you actually can do in that environment. So, I was going to say who we are. I'm Charles. Actually, I'm paid by Pegasus, but to all intents and purposes, I work for the Enterprise Ethereum Alliance. My job is making sure that the standard stuff there works. Dan Burnett, I've been doing web and internet standards for about 20 years. I've got a dozen specs to my name there. I'm currently working on decentralized identifiers at W3C. Some of you may have heard of that, may not have. I'm in the Pegasus standards group with the consensus. I'm Charles as well. I work with the Maker Foundation, and we've been doing some research on proven proposals in general and what's the best keeping considerations when looking at something to implement and taking to all the other programs that you've all worked on. Hi, my name is Jory Berson. I am new to Ethereum. I come from the land JavaScript, where I work on TC39, which is the standard supply that sets the standard for the language. I also work with a number of different open source and standards communities. Knowably, the one I'm going to talk to you today about is OASIS and the new project that we have with Ethereum. Share it with me. I'm Nick Johnson. I lead the EIS and Ethereum into this, and I'm going to be here at the EIP. Cool. Should we slide you more forward with some of the other things? There we go. Yeah, so, you know, we... I'm the one who put this little bit of stuff up on this slide. So, it's interesting. If you ask someone what a standard is, there are very, very, very, very different definitions, depending on which group you're talking to and what they want to accomplish. And it ranges all the way from someone saying, well, basically the two of us agree. We wrote this down. We have a standard. Okay? All the way to probably, you know, one of the most extreme is sort of, if you look at ISO, you know, you have five years of discussion through a whole bunch of working drafts, committee drafts, international draft standards. And eventually you have votes from member, you know, member country standards organizations to publish. And so there's really, you know, basically virtually no process to kind of extreme process. And so we didn't really want to start with a definition more than just to say that there are disagreements about what it means to be a standard. And so now, as we talk through different activities, different approaches, different factors that you can use to distinguish among different standards, organizations and processes, you can see what the variety is and we can discuss, you know, as a group, what are the aspects that we would like for the Ethereum community to work with? So basically we set this up by five different kinds of pieces. A couple of us work, most of us work with two or three hats on in different places, but we're going to present some basic things that we do in different organizations, hopefully quite briefly, just enough to understand what actually happens. And then it's about discussion. It's about what do we all want to do as a community? How do we want this to work? Today we'll be kind of looking at each of these organizations through the lens of a few different factors that help you think about the differences between these organizations. So as Dan was saying earlier, if you think about the definition of standard, just simply being for our sake here in this classroom today, agreement, how did we reach it, there are a few different ways we can look at reaching that goal, reaching that goal of agreement. And we'll talk about the W3C, EEA, the EIP process, the methods they use, the factors they use to reach that. But the thing we want you to really take with you is that that process, that standards slash agreement making process is one that we all own as a community of technologists. So if you don't like a process, you can participate in changing a process, and that should also be part of your consideration. So these are some of the factors that you'll want to bear in mind and that we'll talk about. The first is governance. That's often a bit of a buzzword. I think you probably hear that. I hear that a lot. This is simply, or I should say to simplify it, we are talking about policies that support decision making. It could be a process for how we decide that a decision needs to be paid. It can be a process for the decision itself. It could be other policies that support who gets to make that decision. Can I add one thing to that? Governance to me in the end for standards organizations comes down to what happens when there's a disagreement. Who decides, right? That's ultimately it, and there may be different levels that you go through, but in every organization, if you want to know in the end how it works, you look at the end of the chain and see who is the final arbiter and who is Lee in the web world. Is it Vitalik? I'm not arguing that either one of those is actually correct. I'm just saying it's good to know where the final decision lies, and that's largely what we mean when we talk about governance, although it ends up getting expressed in a variety of formal, semi-formal and informal ways. The next factor we want you to bear in mind is PR, which is an acronym for Intellectual Property Rights, and that may be important to you, it may not be, but in the world of formal standards setting, it ends up being extremely important, and it's one of the key differentiators between a lot of the standards bodies that you are familiar with, like the W3C, the ADA, or so on and so forth, and they're different because they have different approaches to this topic, which is quite complex. So they have a lot of legal support, a lot of staff who focus on policy setting here and understanding how different specifications will have the copyright or the patents are granted on those specifications. Y'all want to add anything? Yeah, I really do. We put this out in the public domain, and anyone can use it is not a patent policy. It's a fucking disaster waiting to happen. It doesn't. The comment I was going to make on that is that every standards organization starts with no rules and no process, and they actually want it that way. If you look at IETF when it started, they were very loose, and gradually they had to get more restrictive, and you'll notice if you go to any IETF meeting, the Internet Engineering Task Force meeting, they put up a no-well slide at the beginning of every working group, every call, every everything, and they say, if you do not understand the contents of this slide, do not speak. Do not give an opinion in any way, shape, or form. That's not an accident. They got to that point because there were lawsuits that eventually forced them to go to that. W3C hated the process they saw in the IETF, and when W3C was formed, things were fairly loose and open. And guess what? A company came in, and they actually argued for a specification to be developed a certain way, and then once the specification was done and all the implementations were out, they sued all the implementers because they had a patent on a core piece of technology that they pushed into the spec. So, you know what? I hate to say it, every order goes through this. They're like, look, we don't want to deal with that stuff until everyone gets sued, and then you're like, oh shoot, we've got to do it too. So we're going to talk about that as we go through it. That's a pretty common insight for pretty much every single standard body that others, submarine patents, what they tend to call it, naturally, they're quite gun shy. Another thing to note about this is these assurances, these policies, assist a specification or a standard in being accessible to certain levels of business and governments, right? So they're very, very concerned with making sure that the provenance of the IP is secure. And that's why this ends up being an open source when you're just sort of rapidly innovating and iterating like it doesn't really matter, cool. But once businesses start to rely on, say, government procurement and enterprise adoption and that kind of thing, the provenance becomes even more critical and this is what I think. Actually, I probably shouldn't Okay, I won't code him but we have a conversation. I don't see it, the Lennox Foundation, the security made them there and he said that actually his number one problem that he has with donated code for projects at the Lennox Foundation is the provenance of the code. Because when people start projects they don't track it at all. But when it gets donated, he's the one who has to go and actually check essentially every commit going back into history to find out where it came from and what intellectual property restrictions are on it. He says it's just an absolute disaster and nightmare for him today. So he's working on trying to come up with a better way to fix that. So I know we're spending a lot of time on that it's because nobody likes to talk about it, but I think it's good for people in this room to understand where it comes from and why we end up having to deal with it. What's the right level of process in the journey? Like you said, the W3C is a function of all these things, knowing what they know now, would they have on day one added all the processes in every single one of them. So your argument would be for today in this community that we should add all these processes. You should have the minimum amount of process possible to not get caught out, let it do stuff, because we all like marching in lines. It's about we want to make sure that the problem does not come up because we stopped it before it started. You should have a fairly lightweight thing as we go through the different organizations we'll look at what they do. And the W3C patent process, which I'm familiar with many, many times is actually not very painful at all. It's a very lightweight if you're doing the right thing, it's completely trivial. When something bad happens and someone turns up with a patent, there is a mechanism for dealing with it. That is about as painless as you can get dealing with patents, which is like if someone is sticking red hot papers into you, it's like they only hurt a little bit. Let's go on, let's get into this. Ari, work style, do you want to explain it? It will be obvious. ITR, it was worth talking about it. Review process really just really quickly by that we mean for a number of these organizations some review period by the public, by a broader membership, by an outside entity or by a group of people concerned about, for example accessibility or internationalization or security. A lot of times these organizations will require other kinds of review so that you get the eyes on it. So that's what we mean by review process. And the last factor that you'll want to consider is which other people or organizations or industry partners who else is participating in that group because that will make a big difference on whether it makes sense to bring your standardization of project into that work area and you'll want to look for places where there's overlap other people that would be interested working on it or other companies you might want to work with. So I think we'll just probably go right into our different standards activities as it pertains to okay. So OASIS is fairly new they are new to Ethereum not very long ago the Ethereum research team along with Consensus and the EPA approached us about starting this this open project and check out what the minimum is there we just started a couple of months ago on the Ethereum slash OASIS open project GitHub repository but the purpose was really to try and start filling what we thought might be a gap to help support standards making where the idea might be that the group wants to produce a formal standard something that would eventually be able to go up through to a national standards body or an international standards body like the ISO and so you can check out our abstract there on the repository but we want to basically provide some guidance and some support for folks who want to produce standards in that way OASIS itself has been doing this for a really long time they started actually in the 90s as SGML Standardized Generalized Market Language a long time ago and related XML standards that kind of thing now a lot of their standardization activities focus on security and privacy it's a pretty large organization there are thousands of people who have contributed to these standards and there's several hundred standards that they've produced this is a consortium so they're typically industry members who come with projects and want to work with other folks in the industry to produce OASIS standards that then move along the national standards track up to again the international bodies like ISO not very long ago at all actually back in March we announced an open projects program so if you can think about traditional standards development there's probably a number of different stereotypical sort of thoughts you might have about that they aren't really known for doing open source work OASIS has been supporting open source projects that assist its technical committees for some time and we wanted to open up a program for open source projects that want to benefit from a standards track possibility so which is a a broad number of open source projects the program helps provide technical governance and fiscal agency so if you're part of an open source project you want to be able to spend money as a group or accept money as a group we provide the intellectual property rights and community development support legal support community management that kind of thing and tooling it is not a membership organization and this program is not a member org it operates on sponsorship dues so companies can come in and choose to sponsor a project like Ethereum as consensus and EBA and the Ethereum foundation have done and that cost is on a sliding scale and I think a lot of times in our communities we're very concerned about where the money comes from and that kind of thing so I'm just being transparent here but anybody can participate in the open projects program anybody can participate in the Ethereum open project in the technical activities to do so however and again this gets back to that provenance concern that we care about in IPR they must sign a CLA that includes a patent on a cert meaning that you're not going to stick anything in there and go sue everybody that's bad looking at those factors this group is open it's free there's no cost to participate if you're a member of the community to contribute to the activity of writing a specification because it brings you joy and happiness then please you can do that and if you are a company or an organization that wants to you know to support it in some way and wants to help drive longer term direction for example the direction of moving into a form of international standard then you can sponsor it and participate on the project IPR is royalty free and our projects have to use one of several approved open source licenses they seem to be the ones that community members need to care about Apache 2 and MIT the work style for the group is very similar to how we work in an open source capacity a lot of activity on get hub mailing list teleconference calls is needed that kind of thing from a decision making standpoint the technical theory groups operate on consensus but again for the formal piece of it where we wanted to move a standard through a formal standard strike that it has to be done by the project review wise the project is able to develop and approve their own specs that you can stop there you don't have to move on but if you choose to make a project make a specification a formal standard with OASIS that means it has to go through the OASIS approval process which provides member and public review periods so the work areas that we're looking to get started on started with our JSON RPC so if you want to get involved with this I would really encourage you to file an issue on the repository or come chat with me because these are really bootstrapping right now we don't have a green field space you can have and get started on we'll give you the slides and then if there's an area that you would be interested in working on you can also come talk to us about establishing a TSC to focus on now sort of what is TSC a technical steering committee so there's also a load of background notes and standards development so that's also fun what would it mean to think of steering committee that you're helping with establishing such a body of maintenance talent for the work environment so you can be analogous to the working group I think roughly it's like this is the piece of work you want to do so we have TSC a technical steering committee to say we are steering the DevP2P development or that's the group that does the work it's not a planning group, they actually do the work just like a working group in ITF or a WC group this one it's brand new so the Enterprise Ethereum Alliance basically what we're trying to do is extend the Ethereum architecture the thing I love about Ethereum is it's based on standards and so we're trying to take things that enterprise by which I mean both your giant fatcap million dollar companies and organizations like your local government run garbage collection service your health service if you live in a civilized country any kind of organization who wants to build stuff wants to build on top of Ethereum about what permissioned networks wants private transactions and so on you can do these things by yourself, you can build it by yourself the point of the EEA is if we have in a greed way of doing it half a dozen different clients if it's a software you can use you're not tied to a vendor if your developer decides to go off to Mars or retire into the mountains you can get another developer because this is all standard stuff people know in the same way that if your ETH developer decides to go to the mountains there are other people who know Solidity know ETH and can build stuff EEA like Oasis has an ISO liaison thing so at our level we're just a liaison, we participate in TC 307 which is ISOs working on international standards for blockchain it's very much about ISO except probably don't want to go there it's a place where people spend a long time working on things like the glossary what is a blockchain is it different from distributed energy technology is it a subset, super set overlapping set after 18 months of discussion or something we as LEAs are participating in this discussion but then it goes to a vote by country representatives so it's literally I don't know how many people watch Eurovision but Tonga 12 points and that is how the decisions are formally made so one of the reasons for the discussion is to try and get to a point where we all agree that it's not going to be a contentious vote because in bad ISO situations what happens is some country with a pile of money goes to a bunch of countries with no money at all and says we will pay you and you and you to be members of this group will pay for your representation if you go to the meeting so that you vote with us on some crazy stupid idea that's when ISO goes wrong that doesn't normally happen thankfully but it's a very slow process it's very very far EAA not so much so the governance is a member consortia you pay to play we provide staff who consist of about five or six people couple of them basically do marketing and talking to members my job is make sure the standards process actually works like down spent 20 years doing this stuff have an idea about how these processes can be there's an agreement that members sign and so we can hold them and do certain patterns of behaviour but specifically of course I hear if you are a member then everything you do goes with a grant of patent licence anything that you put in you promise that anybody can licence that for free you can't come back and say oh we changed our mind we decided we want to charge you for our patent no you signed it away legally already our copyright story is frankly a bit dumb at the moment if you take our specs you can read our public evidence draft specs but if you take and look at the licence it says what do you base our long advice you're not allowed to copy this or do anything with it why is that dumb? because if you're on a development team trying to implement it what you will probably do is take the spec chop it into pieces if you're dense with some commentary technically that's a derivative work technically that is something that you would have to ask us for permission to do the answer will be yes unless you're going to publish like EA version 8.1.a the answer will be yes just use it and that's the discussion we have within the board there's a board of directors who have formal control no work style they're probably like most people stuff is on github we make pull requests where we can we work by lazy consensus which is someone puts up an idea looks like it makes sense we agree that's great but we do have a formal decision making process and we have a weekly meeting teleconference the agenda for that meeting is published in advance so everyone can see it and you can always say I can't go to the meeting but don't do this and that is enough to stop a decision from being made first time if you just keep saying don't do this without justifying it we will put it up for a discussion at the meeting and eventually if you've got nothing except we're deciding to do this so some stuff actually gets discussed at teleconferences most of the work is on github because people come to agreement and it just works the review process is essentially continuous we publish our specs on a six month schedule it's like at DevCon we will publish a new release and the theme of this new release is whatever is ready that we've finished by the time we get to DevCon so the review is just like an open source project literally whatever got through the yeah this is good enough to put in goes out in the next shift and the one thing is EA has paid a play to join RP it's basically the organisations the starting price is 20 grand a year if you're a library or a government or a research organisation or a small company the top price is somewhere like 25 I don't actually know if you're going to talk to the membership people if you want to do that and right now our github repo is restricted to members you can't actually see what's in there we've heard the feedback that we're not sure what's going on and we don't like being that unsure we would like more visibility and so we are going back to take that feedback and say well how do we provide more visibility the concern that people have is right now we know who is putting content in we know who is influencing the direction because their members they pay their money we know who can read the github repo and they sign the agreement if we open up the github repo can we still keep that control to make sure that people aren't driving IPR stuff that's bad that's an open discussion inside EEA my personal feeling is I suspect that we can because I've seen other people do it but right now that's the situation and getting involved you can follow this is our client spec we have the trusted compute of chain framework where you change client spec of trusted computing I'll update this and we will have some more specs coming out soon at antethelines.org you can actually find our release documents but these are our editors this is a live off github whatever we have changed that week to continue you become a member the EIP system is originally based on the BIP protocol system which itself is based on the PIP system which is the Python protocol system which is based on that it turns we've made a few changes because PIPs were originally designed to Python the programming language they are of a slightly different nature to what we're trying to standardise in the Ethereum community and there's kind of a dichotomy inside EIPs as well because there are two main types of things that people try to standardise one is more or less contract interfaces and other sort of application layer standards and the other is changes the subject to hard forks and so forth there's a lot of overlap in how these processes operate but the end result of one is a standard that basically anybody can vote here to write their contract to it here to or their adapt to it here to or it's a standard for an RPC interface to a node or your wallet interfaces with it and the other is something that requires consensus from all the client developers so they start off similarly they have similar discussion processes and so on and basically just requires that it be technically sound and that people come to general agreement on what it should obtain the other is a much more involved process of gathering consensus for a hard fork so we have those two separate parts and we've made some changes as a result to how EIPs work compared to EIPs or EIPs and we've tried to adapt some of the IATF's workflow in building consensus and building useful standards no sorry so EIP it is a job as we see it is mostly to provide almost exclusively to provide editorial services so we review incoming call requests to make sure that the bill doesn't break you make sure that it has the appropriate sections that it makes you know makes a sense and somebody reading it can understand what you're trying to write and we try to set the standard for a new draft very low again kind of following the IATF's process where anybody can simply draft and then we we try help with the editorial process of getting those standards through but we're not trying to be the arbiters of what makes a good standard here we're trying to make that consensus a community driven process so we try and avoid doing technical decision making for the most part the standard process isn't as consensus driven next slide please so factors governance again it's a trial we try to make consensus anyone can participate anyone can write a draft and we've got feedback on technical draft and it brings for at least anyone can write an editorial although anyone can become an editor although our sort of meta process here for like EIP that is appointed how is the EIP process itself amended to get as well-defined as how do you apply to become an editor so at the moment most of you yeah so this kind of folds into like how do you make changes to EIP 1 because at the moment what you do is you open a full request to EIP 1 that adds you as an editor and you say please merge this full request and then you wait 6 months while people argue over who has the right to add it and so forth so that's something we need to establish better the main issue is as with any other change to EIP 1 editors are generally comfortable exercising their judgement over changes to EIP or questions about and so on but we're comfortable about doing that for changes to the entire process understandably and because we have because a lot of our editors are part-time they're occupied with all the things they may be unresponsive and it can be hard to get a consensus among the editors to add an editor or what changes stand in them so this is definitely an area in which the process is currently weakest and actually with a consensus it's rough consensus right I'll talk more about that when I get to WPC because they're what they mean by consensus is different yes and you'll probably do a better job describing it than I would so so OPR this is please don't hurt me all the APIs have to be released copyright wise cc0 but we don't currently have a pattern assignment process and part of the issue with that it's only something that's come onto our radar recently and so the issue is there's no formal counterparty there's no EIPs incorporated there's no organisation that can sign a contract with you giving up patent rights so the challenge in my technology at least is this that without counterparty you have an agreement that's enforceable and there's no party here that can sign that and that can take you to court if you try a certain patent and then the other panellists will have insight into that later so work style everything's done on your pub and so on if you want to write a new draft you submit a call request and sign you a number which is generally the number of the next call request it gets merged into the draft after that we have a bot whose job is basically to allow you to make changes to your own draft or to allow you to accept changes other people want to make to your draft discussion takes place on a basically a forum nominated by the author of the draft and if you want to progress your draft past the draft phase and into a stand-in we have a lightish weight process by which the draft author can nominate to go to final call they have to provide a certain amount of time for people to provide the feedback during that time people can provide technical feedback and it will be in the last call the author is expected to provide a summary of all the objectives that were raised and how they addressed them and then the editors look at their summary and decide whether they think they will be addressed and either can go back to draft or accept that it's final this is the process for the contract level standards the application layer standards for consensus standards and so forth and the principle is the same and then afterwards the editors decide whether they want to accept that into a forum and if they do they add it in practice it's a little more messy stuff often gets into force before it is fully finalised something may need changes as a result as the developer simply needs to get into finding issues and so forth so that's another area in which it's a bit messy at the moment so I just talked about the review process and it's run entirely by volunteer editors and support that year structure and so forth and some of the editors are already here for the release I'm a formal one myself but if you want to dissipate, next slide please please open a PR if you want to write draft open a PR if you want to amend the process and then we can argue about how messy our process amendment process is and likewise if you're able to become an editor talk to us, we can always use more volunteer help be aware of what it is you get very little accolade for it and a lot of drudge work so it's a wonderful thing please come join us and that's it thank you in the role of the editor you're basically assessing technical correctness are there requirements for documentation are there other what are there so partly because we believe in making the process open and decentralized and partly because we have a limited number of volunteers around us and we try to make this as much a community job as possible and that's what the final phase is supposed to help resolve really the goal is that it doesn't get accepted as final unless it is clearly described it has the necessary sections it's a standard where somebody can read it and then something compatible without having to have long discussions with the author and so on and ultimately it's the editor's job to make sure it doesn't get through unless it meets that but we try and make that as my way as possible by getting that and explicitly back from the office is there any change of who cares so can I write the IP for some crazy idea ahead that I am the only person who will ever bother reading to the end of this because everybody says that's just stupid not really, no I've said before that we try not to decide whether your standard is a good idea or whether it's a well-employed and employable idea so if you want to submit a standard for the best way you can submit the kittens then you are horrifying but probably you couldn't get it to write it a lot of people do use the theory of musicians that get feedback on the years yes, so you know there's no officially required place that you have to have a discussions URL it has to be possible for anyone to post there we don't have a requirement that it must be a particular place but the theory of musicians are a popular place to do that because it's a gathering of people who have the insight to be on it long term I would really love to see more like we've got the magician's rings which are called working groups I would love to see them take up the reins for shipping standards of a particular type again, sort of borrowing a little from the ATF if you want to write a standard that does X it would be nice if the others could say that's great, please go talk to the magician's working group for X and if you want to do it on your own you should have a good reason why you don't have a lot of time to do that instead of going talking to the experts but that's currently that's not currently the case what are some other areas in which what are some other areas in which do you improve the IP process I think the most important thing is the meter process around modifications to the process because if we don't have that locked down then we don't have it to be a path involving anything we only have that first but I basically would like to see more ways to make it more systematic so that it depends less on how much time and attention it has available to spend on it and on ways to make it more more sort of procedural in terms of making sure that people understand what makes step is and how they can do it and so forth do you think that there is more incentivization for the IP that more people would try to get involved not really I'm saying if there were more incentivization layers in the IP process for editors or people kind of cutting to the the whole program do you think it would be more engaging and more efficient it's difficult to say I think there's this psychological effect where if I ask you to pass me a glass of water you do if I ask you to pass me a glass of water you're insulted and you say no and I think you need to be very careful about you know we'll give you a gold star every time you approve a pull request or something because I don't think that's why most the IP editors is volunteer but also we do have this volunteer effect you know and I think rather than like direct incentivization a better thing might be if someone might be if we just say we have a budget to hire a full time IP editor you know that is their job now you know and if they don't enjoy it then well sorry it's your job sometimes you don't enjoy your job you know that might be a better way to make sure things move to consistent it's also the case that if you if you provide an incentive to people when you say we're going to pay you for putting stuff into a spec it's like hey I can get free money for making work for other people who does this benefit the answer is not the people you make work for not the ecosystem where that work suddenly becomes a big distraction only the person who's actually taking a pile of money to do stuff that's essentially useless at best before you end up with the reverse effect where I'm incentivized to just accept every call request no matter how bad because I get paid five bucks for a call request let's say the working group builds the spec and does the development side of it do you think that should be incentivized in that way I'm not against incentive schemes except that I don't actually know of one that is set up well enough to work basically so only last question I have on this and then we should move on so we can get to others here a bit it's when there are disagreements who do you talk about at some point there are maybe controversial subjects and how those end up getting resolved so to some degree these have led to reform the IP process so the big ones that come to mind are things like the rescue VIPs I think it was 9.8 which proposed to rescue some parity cards and so on and at the time we were less clear about the role of editors and so on so it seems that if an editor approved this as a draft they were getting the same authenticity that this is how we should govern this is what we should do in the next part so when things have been controversial it's often been because there's an exception in the IP there's an exercising control over how they work operates or over what should be accepted and our response has been to try and separate those concerns to say that we're trying to write standards we're not trying to tell you that you should implement standards or force people to rub the standards and so that's been the main source of controversy there's certainly cases where people have strong feelings about it so you try and finalize it and they say oh my dead body because this is a bad standard and ultimately I think there's no easy solution to that you just have to build a process where generally technical concerns get addressed in a technical manner rather than a personal manner and if somebody is adamant in understanding the ground then you have to have people who can usually say either yes this is a valid concern that should be implemented or we believe that's out of scope or that's a relevant or it's not part of the standard that is being like the core data is essentially right? For standard writing it ends up being the initiatives that should make it into the standard and in the sense that there's a technical south that should be implemented then that's the core data I could write a form of the IP that says as on block number X my account is 10,000 and I believe that that should be standardizable but I also believe that all of this shouldn't be any some error they reject it you know Can you just get out of presentation and reload it? You should No No No Can I ask a question? Sure Like for all these bodies do you guys publish all your processes in a way that anyone can actually read them and find their way through? Certainly everyone is at the EAA Basically to find the EAA's process we have a formal process we don't use much there's a procedure for when things really go bad we can have a vote on stuff that's damned hard to find if you have access to the guitar repos if you remember then we have documents about a basic working style how we have get agendas out and you can object to stuff for us and everybody else's stuff is just public you can read those processes In the case of EIP one describes how you write an EIP, how it's standardized and so on as I say it doesn't describe how it itself should be applied and there is a bit of received wisdom that just doesn't make it into the EIP the convention of this is how you do little things Stuff the editors know but forgot to write down That's actually why I was asking because I was trying I was actually filing a change for EIP one some time ago and I found it kind of hard to actually from EIP one get to an over process view on what am I expected to deliver and what stage is do I have to wait for others to actually provide comments on it or do I even have to go pop on a core devs call and show it there as well and even though it's just a change to EIP one why is it in a core devs call I ended up trading my own process diagram for it so I can just follow it and go through because you should put that in a pool question I actually sent it over to a few people at EIP already so I can also add it there I'm just going to add this this process started six months ago maybe and all of these like in my core dev everyone said okay you should be married and still and even though the change by adding security consideration to the other EIPs so that change or is it a big change it's not a big change I was looking at it just yesterday very simple change in the end and also that those charts that is like why it was present at IETF and it was interesting that IETF in Montreal they don't want to talk about blockchain so I would give you one thing a very simple change that requires 1,000 EIPs or something and if you want 1,000 EIPs to change then it's so simple if you go forward it wasn't meant that in that way if we go back for example where EIP comes from from the Bitcoin protocol Bitcoin got this stuff from PAP PAP has security considerations Bitcoin just got rid of it for some reason EIP got it it didn't make it into EIP because it wasn't in the bin so that's actually just fixing what we lost on the way I looked at it earlier today it looks well reasoned it should probably get and it runs into that hole where the modifications for EIP1 itself are well described and I as an individual editor also don't feel comfortable merging something on the other editors are okay with it and they feel the same and we need to better formalise I was getting the crowd to get a consensus it's funny like with EIP2 actually I think I got a section dubbed in some of the via chain spec for security considerations and privacy considerations and they've since been removed this is a it's a bigger discussion topic there's a discussion security considerations are always addressed it's just not proactive it happens at the end of the life cycle of the EIP or whatever it is that's way too can drag all this information along basically so that even like us auditors we could jump in and help previewing your EIPs or whatever but like the main feedback that I wanted to give for EIP is that we lost in many stages until like in what stages might EIP right now it used to be in limbo mode for some months because I was actually waiting for someone else to do something which was kind of unexpected for me because I had a full request I had discussions on the magician's forum there was only like positive feedback for that it was only like formal change in something that is not really highly debatable whether we want to have it in there and I just didn't know like how to push forward it's important what is the forcing function to make it keep going ok so W3C that's the worldwide web consortium it's the group that defined HTML and related specifications ok so you all know what that is next slide so governance there are more than two kinds of groups but the two main ones that most people care about are community groups and working groups so community groups are completely open completely free to participate in they also require no resources or support from W3C which makes it easy to provide them that way the working groups are membership based when I put corporate it's actually organization like Charles said so you know it could be governments or schools or libraries or whatever but when it's a paid membership allows members of your companies to work in working groups for anything that is a standards track specification the IPR is essentially a custom grant is a royalty free license required for anything you contribute in a community group so actually to contribute in a community group you have to sign an agreement that says that any contributions you make you will grant royalty free once you get to a working group it's actually a royalty free license for anything in any of the specs produced by that working group unless you disclose so within a working group you have an opportunity to disclose that you have a patent and request an exclusion from the policy and the reason for that let's say maybe you don't want to give up the rights to that IPR well that's fine but the group needs to know so now they can make a decision whether they want to change the spec or not so there's no surprise there and there are certain mandated points at which you get an opportunity to do this exclusion or disclosure working style like the others give them a number of groups have regular teleconferences but this is where I wanted to talk about consensus W3C has one of the the strongest consensus requirements of any standards organization I've ever seen IT have started with they use rough consensus okay they like to say rough consensus in running code and you know Ethereum groups in general have adopted that rough consensus does mean though that you might you or five of you might just be out of luck right and in fact ITF feels I know I'm talking about W3C but ITF feels so strongly about that that the way they get they determine whether there's consensus in a physical meeting is through a HUM and you might think that sounds really strange okay so they say HUM if you want this, HUM if you want this and the reason they did that is so that you and your boss are sitting next to each other your boss cannot tell what you voted for so they really want people to be able to give an independent opinion but to be able to get a general sense of the room and they do that right so they go oh yeah it's pretty clear there's like three people back there trying to HUM really loudly but the rest of the room just doesn't want to do that I think it's worth highlighting though that this isn't a majority wins dollars you know it's not a 95% city it's not a vote now and in W okay so right like ISO it's a vote in the EA as you said you're trying very hard not to go there we have a voting procedure I'm very happy that in all my time in EA we have never had a vote right it's always been you get two consensus so W3C goes with just an extremely strong notion of consensus and it's way beyond rough consensus basically I can't remember when it was started I think you know sort of looked at IEGF yeah but then he said no if there are people disagreeing you need to talk and so that's where that came from so it can take longer to get some things out doesn't mean that things don't go forward without a few people disagreeing that boy you really really have to work to make sure that you accommodate disagreements no voting so that sounds like my understanding of the IEGF in the like rough consensus doesn't mean you just ride roughshod over at the three people who object it means that if you want to go past those objections you have to obsess them and either take them into account or take them into consideration I've been in lots of IEGF meetings and usually they will ask those people what their opinions are but in many cases by the time you get to that point you already know what their opinions are it's just that they disagree with the rest and if they're really there's just like a couple like no I don't agree with this and it's been discussed on the mailing list extensively then they go ahead in principle they're pretty similar in practice W3C enforcers and much deeper level of that you really have to explain why you've overrode this thing now if there are two different camps clearly IEGF will get locked until it gets worked until it gets resolved but as far as rough consensus they will go over the small holdouts that's what rough consensus means so review process working drafts which don't imply consensus and then a review process and implementation and I'm going to try to get implementation as early as you can but the reason I want to talk about the review process in W3C there are basically three things that W3C is really known for one is royalty free specs the specs themselves are free and open to read it's not like ISO where you have to pay to get them and then to implement them everyone who worked on it at least will give a royalty free license today to implement it the strong consensus is another one and then the third point is the review process is a pretty formal review process where it's this your group works then they require W3C to look at it and actually outside of your community you are required to demonstrate that anyone else who might peripherally be connected has reviewed it and then they specifically have accessibility, internationalization, security and privacy groups in W3C who must sign off now IETF does the same thing actually IETF the IESG does that effectively the other groups in IETF have to agree and this is one of the things that I think could be looked at whether it's for I don't know whether IETF needs it but for IETF too I think eventually they are going to need something more like this where there is a clearer defined time when security people get in there people who have agreed to be we are going to be security reviewers and so on ok next slide yeah so W3C has a lot of different activities and I just listed between 10 and 24 of these community groups many of them are not even active they all got started rapidly a few years ago when things were hot but they could all be kicked up anytime anyone wants to there are a couple of there is a standards track working group that I mentioned that I do want to talk about decentralized identifiers really about what it is more just to say if you don't like email addresses, facebook accounts and URIs as identifiers then come talking next ok so work is done in public mail and it leads to the get-go reports and this is both for community groups and working groups now so you can follow it very easily to contribute so as I mentioned there is an IPR commitment at some level so if it's a community group it's a personal commitment if it's a working group it's your company's commitment for all aspects that come out of that group now to submit whole requests in working groups requires membership typically and again that's because of really serious concerns about now there are other venues if that becomes a problem but in general it is direct contributions that require membership for leading there is a concept of any invited expert I didn't want to go there so there are cases where if you're an outstanding individual and you work for a two-bit company that it doesn't have the money to join or you work for a large company that has nothing to do with the web and won't join there is a mechanism to say we want this person in the group so bad we will give them the right to do it but it's very much held as a privilege for our excellent great if you want to lead yeah it's just like you said you just do more and you volunteer and you say I want to do this now if you're going to do that in a working group you are going to need to be a member or invited expert okay next slide okay so I'm going to talk about e2 also I do short straw here so please don't shoot the messenger I'm sure I got something wrong because I don't know that anyone even agrees officially with the processes I talked with a couple people and they're like yeah that's kind of what it is so these are some statements along those lines governance is very informal for e2 it's basically guided by guided by the ethereal foundation and developers and of course influenced by individuals who have been instrumental in past versions of ethereal interestingly you know if you look at who has final say actually I didn't talk about this with 33C in the end right they don't vote if there's a disagreement and you get all the way sort of to the end the director will decide where the director is Tim Berners-Lee Tim Berners-Lee right now is on sabbatical he's been on sabbatical for a long time there's an experienced person representing him who acts as the director now that may change over time so anyway e2 it's actually the editors that have final say right now for e2 and that's only because they're the ones who put it in I'm not saying they're arbitrary I'm not saying they're inappropriate but today they are the ones who make that decision there's no other group that says to the editor that can say to the editors you must undo this sorry could you expand on who the editors are I'm assuming not talking about the e-editors not e2 documents this is Beacon Shane and so on so Danny, Ryan the editors I'm sorry the editors of the e2 specs that's what I meant thank you wrong question right so and I say eF editors I probably shouldn't say eF editors Danny Ryan is kind of like one of the primary ones he's not the only one but the eF has taken on itself the role of coordinating and making sure that progress continues to happen so that's why they're not positioning IPR so all of the documentation everything including specs, licenses CC0, 1.0 universal there is no IPR does that happen? working style there are bi-weekly teleconferences but that's for discussion but again all the work really happens in GitHub for the review process it's informal the community just reviews and talks I am not aware of any any kind of formal review process there is not any formal stage at which it will get a security reviewer privacy reviewer whatever although there are times when that tends to be requested more than other times and from my perspective this is an area where eventually they really should look at actually maybe at least saying hey now is when we want to seek that and the advantage of having that not just get lumped in with all review is that it lets the people developing it up front get to have some time working on it before it's like coalesce their thoughts before it gets the detailed security reviewer okay so the other thing is that just like each one the work is very community focused so there's this kind of belief you didn't talk about this in particular but it's more about implementation than the development of the SPACs there's always this kind of implicit why you can always work you can always work you don't like it just work no big deal the truth is that a very large scale defection would be considered failure okay so any kind of big fork so this is where the rock consensus thing happens right so you get a few people who disagree and they really disagree strongly they're just going to go and make their own copy and they're going to try to convince the world that everyone should walk away from those losers over in the room over there and follow them but if there's too big a group then that's considered a bad thing what did I miss because for me to talk about E2 it's very embarrassing I mean the reason you got the job is I got no idea about that yeah so I paid attention okay yeah it's been off and on for a while okay next oh yeah all of you know this you're a dot com phase 0, phase 1, phase 2 phase 0 implementation is actually happening and there's been an interoff event which is really really really cool and it helped them a lot as it does every group that does it when you get stable enough apparently the phase 1 spec work is stabilizing and phase 2 like I mean even coming up with a list of what phase 2 is doesn't work and if you want to know more there's great sessions on this yesterday and the day before that's exactly right okay that's it oh there's getting involved oh yeah you know there are any number of places you could go I am a little biased I get some information from Ben Edginton at Consensus and Pegasus because we both work there but he actually has a really good blog that he maintains the updates regularly about the status of E2 and it really is a good place to follow without having to go read all the github issues and that's a really good way to do it anyone can submit issues if you want to participate and all of us I believe they still require commitment signing for this so for most developers that's not an issue but one of the things that I have learned from many standards efforts is that there are often people who want to contribute who are not necessarily technical people who actually care about societal impacts and things like that and they may not know how to use github at all much less figure out how to get a signature owner to make so that is something to think about and as far as leading boy you need to be ready to live and breathe it because it's all it's all in issues and calls and people's heads and random documents spread all over the internet so it's just not easy it's like a race right leading is easy you just got to run first than everyone else so I asked Ben what to do and he gave me a list like this and I said okay great so I made three bullet points so places you can follow you can contact Demi Ryan a couple ways there and there is a live stream of the highway calls or you can just ask Danny so I should just add to that github has a really great overview of github it talks about all the clients that are working on implementations and how they interact with the offsite and it's a great place to learn everything about github and get started thank you that's it sweet so unlike all the current standards that we've all talked about we have the privilege of major to start from scratch and learn from all the mistakes that have happened in the past and take all the great things that have worked for you guys so right now we're doing a lot of research to open up the way to improve major to the entire anyone who has access to the internet I suppose and similar to the VIP process it inherits from VIP VIP and PEP process to create a standard approach to proposing improvements, standard specs and just overall changes to the protocol so there's a lot of things that we need to consider when implementing a standard for the major protocol and the overall ecosystem some things that actually as a break-up session I want to open it up to people's opinions so if anyone has anything that they think could work I'd be happy to hear it so standardizing the improved proposals there's templates that allow people to kind of propose it easily they have to follow the criteria they put it up there and it gets reviewed by an editor if it checks all the criteria it can move throughout the process of the life cycle and get on its way to being implemented governance overall from our perspective we have to kickstart the program from the major foundation and it would be governed by the community and the NPR holders so we've been really considering what is the best way to get consensus should we use our NPR votes should we have kind of casual polls on discourse forums or forums in general or should we just hear the loud voices on community calls in terms of the workflow everything would be kind of focused around GitHub we would have the entire process on there where people have spent their PRs we would be using the templates that we could provide discussions would happen on discourse where the idea is to be able to get rejected at conception because it's been repeated and accepted or viable we would have to reach out to everyone involved and then we would have the voting community calls potentially to make consensus and decide on these things the review process would be a little more formal than the EIP where the others do review the specific criteria and make sure all the check marks are made in order to move it through the next stages and the community would be heavily involved as well like I mentioned the idea of having polls and votes is interesting and we might want to consider that the key stakeholders that I find would probably be likely involved are the editors people who check all the criteria to make sure this thing can go through the authors are typically technical leads who have an idea to improve the protocol in itself the coordinators are the kind of managers who make everything happen they coordinate with the editors the authors and other stakeholders involved such as implementers and they would also speak with the auditors to make sure that the technical implementation is feasible and technically sound in no potential failure modes so the types of changes are really interesting so the processes would be very different for a protocol change with the smart contract player you would have to go through very much deeper process a process could be a change to the program in general like we mentioned earlier the EIP process isn't really defined so it's less likely to get pushed through but if you define that at the beginning it's a lot easier to actually improve the program iteratively there's just general requests for comments on concerns with security or failure modes in terms of our activities we're very much in a research phase and trying to finalize the program in itself once it's finalized it will be accessible through GitHub and a dedicated website the EIP website that tracks the history of all EIPs and versions of the categories that we fall into the phases of the launch would likely be we release the program all the documentation is there for read everyone can go through it and understand how it works the life cycle of them the people involved, stakeholders and just overall the upgrade types the editors would be more formally defined likely as I mentioned the maker foundation would be kick starting this program we managed the editor process at first but it would evolve over time where community members would be vetted in respected community members based on their contributions in the past and they proceeded that way and then just forums to have one location to discuss everything as opposed to over social media Twitter and everything happens on Twitter but you can't really archive that and go back to those conversations where people rip on the security issues and forget where it is so having it all in one place is very important that's the purpose of the even magicians to have that one place to discuss all these things and I think that's really important for us and then we have our first use case where we can kind of implement it and dog food around the process and make it simple for the rest of the people in the community to do that as well so if you want to have a conversation with us about this you can reach out to us on our reddit make your chat probably the best source to do that and the telegram as well so I'm going to pass it off so I'm going to pass it off to Jory to Maria I guess all of us so one of the challenges that we run into in this work is competing with specifications developed at competing for organizations and famously this you with the HTML specification where you had what WG and W3C developing essentially two different versions of that technology for a long time and it's only recently starting to that situation has recently started to really resolve in terms of those organizations working together and stuff like that so one I think we intended most to talk about the conflict between these two between different organizations here and everything everyone kind of handles it a little differently perhaps more pertinent to this group would be if there are conflicts between say EEA specifications and EIPs and so I wonder if you so part of our approach at EEA because you have to be on the inside to see what we're doing is we take responsibility for figuring out if there's a conflict and as a general principle the idea is you build on top of what a theory makes approximation if these things come into conflict it's our job to fix it and basically to make sure that we are no we are no longer clear in conflict a place where we do think we're going to seriously impact public ethereum ethereum stuff our policy is we will go and write EIPs we will do that work in the standard EIP process so far that hasn't actually come up we just haven't had a place largely we're not mature enough and our stuff is not good enough to be we're going to go and change the public the way ethereum works we may in the next 6 months or a year there are signs that we will consider because we've talked about if we do this thing we need to go and write an EIP and tell the universe how we're doing it we set up a registry for pre-compile if we create an EEP pre-compile we should be really clear to the rest of the universe what that pre-compile is and where it is and how you find and know about it so far that recently a web page that says this is a registry where we will put these things if we ever make them attempt but again those things might happen essentially I think the conflict thing is our approach is we should make sure we're not in the white that's not to be informal standards too which by that I mean standards developed by national bodies or by the deputy 3C by the EA by these consortia groups they often will form these liaison partnerships as well with organizations that they learn are doing similar or related work and my understanding is that recently the Ethereum Foundation and the EEPA also developed a liaison ship there to start this process so we set up a group which is the main networking group and very unfortunately they sort of meet up at DEF CON to figure out what they're going to do and how they're going to do it is it exactly the same time as this session which I have no idea what they did or how it's possible for making it happen that's going to be fun there was a session 2 days ago where we were talking about collaboration there was an introductory session but yeah the basic idea is just to have a group that's actually EF chairs the working group DEF is a member of EA so DEF staff can all go and get inside and see what's happening and that they don't even pay they got a free membership but basically they're there to keep us honest make sure that we're actually doing what I said we would do and you reminded me of this actually earlier we did talk about how do organizations deal with conflict directly like with any group we talked about technical disagreement but you mentioned that often times when we do disagree there can be personal or personal matters brought to the fore which are not relevant so I'm curious if we there's codes of conduct or professional conduct or things like that is it something that you all care about generally there's a big question there's code of conduct actually we have a positive work environment group that forms specifically to come up with code of conduct so yeah it's important it's amazing that you have to teach people what they should have learned and you remember that book and it's like I'm sorry you have to learn how to get along with people in kindergarten and people forget it when they learn how to program but there's no more room alright so we have a formal code of conduct beyond the membership agreement which as some stuff better you will be reasonable you know but it is really important and a bunch of what I actually do is whenever there are things threatening to raise up a bit go around and actually talk to people and say look you know if you get in a situation where you and those other guys you disagree with and think are stupid also disagree with you and they think you're stupid stop talking to each other nicely then this discussion is just going to explode and nothing will happen and we will make no progress if one of you walks out of the room we will lose some fairly important perspectives so at a technical level we do want to get to some kind of agreement and it might be that sometimes you compromise quite often a better technical solution is to say we are going to have sort of half one consensus algorithm and half the other consensus algorithm on our blockchain one side will agree to lose completely and we will have one consensus algorithm because that's just easier to implement for everybody but you still want those perspectives and you still want the email and so making sure that people are doing stuff in a reasonable and friendly way matters if they don't you end up with only the most painful people you've ever met being the ones who decide things and that doesn't work out well as a rule are there codes of conduct in that of course just doesn't have one it should but here's the link well in the past I've worked on projects that have code of conduct so it sounds like what you said so if you're any of the following any comments all these different things you should be warned and you should be kicked out of the community you ought to be decent to people that's pretty much the fault of a student of any code of conduct for any open-source software so one of the tricky things is in this sort of self-organizing setup who is going to take responsibility for calling out bad behavior and what happens is you call that bad and someone calls that bad behavior and the person who names badly makes it around and say well who the f**k are you to tell me that I'm doing wrong you're just being a nice author and there are different ways of establishing some kind of authority W3C or the EA we can basically establish some kind of authority because we have written rules in a community essentially a community has got to decide that they will do this and decide that they will back up one side or the other and what they decide matters because it influences how this community is going to function in the future the tricky bit in a technical direction sometimes if the personalities involved actually end up not arguing for their position and it can be a problem I'll just share really quickly that with the OASIS open projects every project is required to have a code of conduct that's a non-starter you have to have a code of conduct the project can define what those behavior expectations are if they want to use an existing code of conduct in a process like the contributor covenant they're welcome to do that if they want to use something different that's also fine but we do require the other side of it is you want to be careful in how much you ask the community to do because attention is a limited resource and if you expect your community to spend all of their time working on making your thing work then they're not going to have any time left to make their own thing work and actually making their own thing work is probably why they're really there so there is this really hard balance how do you make things easy for people to do the right thing to participate and to help how do you do governance when people would rather someone else do it for them so we were talking about disagreements and governance really helps solve the technical disagreement piece so resolve differing opinions on parameter one and parameter two for example and then the other kinds of disagreements that we see mediated by organizations that produce standards are also maybe political this can certainly come into the play if you're looking at a consortia or group that has listed parties that can really be a consideration and where they have like women in China who have different obviously disagreements over how a standard should be implemented in a given marketplace so those are maybe less interesting to us right now but so I think what we would love to hear is how people in this room feel that standardization processes for Ethereum could be improved how we can help remove obstacles to you for participating obviously we've identified a couple of things and there's the big obstacle with PIP1 that we've been talking about what are things that concern you what excites you what would make it easier for you to do your job frankly slash specification thinking and also generally what other questions might you have about how the organizations we've talked about today the processes we've talked about how would it be easier for you to improve PIP1 for example what do you want the most important part is that there's a process out there that is published somewhere that's easily accessible for me and easily understandable for me because also I myself I don't really have a lot of time to read through all these process descriptions so if you give me a process chart that I could just follow and just read up like I'm in that stage so this is what I'm supposed to do this is what I'm this input this is my activity and this is the output and I should wait for someone else at this stage and it's totally clear and what I have to do is that this step is not in or the EIP in that case is not in any limbo mode and nobody knows what to do with it so this happened I think two times for me that's why it took from I think February when I started writing it until now and it's still not really through the whole process to actually get it that far because I lost track of it at least two three times because I was actually under the assumption that someone else is now giving some feedback on it and I wasn't even sure who is going to give feedback so that's kind of just give me one big picture of how it's supposed to be just to be clear that one you were talking about now is that an EIP or is it an EIP1 I initially filed it as a meter EIP then I presented it at the CODAF's meeting and it was decided it should just be an amendment to EIP1 and then kind of turn around again and it's kind of just more confusing in the end Is this the security considerations? I mean it definitely shouldn't be an amendment to EIP1 my people have orders to make changes by having reactives before and personally my objection has always been that the process can be hard enough to understand now so much worse if you had to read EIP1 and you had to read all the other EIPs that are meant to be EIP1 and try to figure out what the gestaltable that was unfortunately you've picked an area to help us and it's like the worst which is definitely because we can improve in that part right? Well I guess I'd like to if you wanted to improve how we handle changes to EIP1 the process would be to write changes to EIP1 The proposal would be to create an EIP that's actually changing EIP1 right? I still think that the way the best way to do it is PR you know PR to EIP1 rather than a PR that means, oh sorry the EIP that means PR to EIP by description just because it would be very hard to keep track of the current status having spent like years as the editor of W3C's process which W3 started out without a process document it was just like yeah you know just be cool and do things nice you can be sensible and there's been a lot of evolution since then I'm going to need to follow the way I think it's fake have one document which is here is what you need to do fix that document when you need to but one of the things is if you tweak it every week no one knows what the heat is going to be it still needs to be short enough to have a look at it understand what it says and more or less remember it and one of the things is if you make changes like if you change things every six months you should have a list of what we changed over the last six months or a year or however often you expect people to have read it off so we need a PR to EIP1 that says that modifies EIP1 saying here is how you make PRs to EIP1 and then we can have a more clear process and the big question in that is who can accept it and what is the threshold I actually wanted to be called citizen so I read EIP1 and I understood when I want to change any process in EIP there is actually a change in process so that's kind of like this is how what we are doing including the change to EIP1 but with a description of why and all the discussions you can even track the changes which makes sense because that's only editing it you might lose why you even introduced that change but you stick to your actual process that's why I started with this one and at some point we all kind of decided that it only requires a PR to EIP1 I put everything in the pull request in the end and then we had lots of discussions a few changes, there are still one to two changes pending right now to make it more clear what to do but it was kind of a hard lesson to learn to follow the process mainly because it wasn't very clear to me what the actual process is so setting expectations and being clear about like who is holding this thing now and who is the next person who has got to do something is I think pretty important in most processes what did it help for you? I created a process chart for myself just to be able to next time just follow that one I can either post it to the magicians forum with the EIP forum somehow and we can to get a work on that one, it's a royal thing so we can all collaboratively change whatever we have in there so again just to clarify is this the process for writing EIPs or is this the process for changing the EIP1? this is for writing EIPs like the whole process, all stages in there so I'm still under the assumption that whenever I want to amend the EIP I should actually meet the EIP list so if the EIP1 says that then in my opinion it's incorrect if you want to change a draft EIP you set up the R and one of the authors of the draft can accept it if you want to change a final EIP then bad luck you should write a new EIP that claims to obsolete the old one and describes how it's done or ideally describes the whole thing and it sets out sorry? no, EIP1 is the special status active because it can be how do you if you have any idea then you have another EIP that obsolete so do you actually, when I go to the first one and I figure out that there are five things that claim to obsolete this so I don't think we I don't think we do this personally but the generated side would quite easily generate a back language for everything that says it obsolete this so far we've been feeling that I as an editor at least have pushed back when Joe has claimed to write an EIP that obsolete the old EIP and at least Bob says yes that's okay because I don't want to get into a situation where somebody's like my stuff is way better than yours therefore yours is obsolete I think there's room for argument there on whether anyone should be able to just say this obsolete and that's just an advisory thing or whether it should require the consensus of authors that's because there is no official arbitrary, I mean even an IETF there's a point when you're done and so you can write as many drafts as you want to try to obsolete something else but it's only when it's gone all the way through the process and it's final that it actually does obsolete that old because the entire IETF has agreed that it does so if we follow the IETF process then the obsolete thing becomes a thourist but it's a final standard the alternative is that we just say that this is part of the spec the spec says it's obsolete so if you want to follow the spec you shouldn't follow that spec I think the IETF's process is probably better one in this case the problem we're getting to at some point in the segment you look at like spec A is there, spec B is there spec B is newer and shinier and what is the ecosystem actually doing, what are people involved in because if you have like five specs that you say well they're all as good as each other and we don't want to judge anything I walk in with my new company and 50,000 developers to do some work what am I going to work on big one at random and it becomes an unhelpful situation and actually slows us down because people are like nah, I'm going to spend my money on good websites because that's bad and this is where I'd really like to see the Ethereum magician's ring slash working group step up because if you had a working group that says they are the working group for wallet standards or whatever then the editors can say generally we won't accept wallet standard EOP drafts except from that working group unless you have a really good reason why that working group can't handle it and then that working group can take on the job of trying to colour their standards and so on because I think it's attractable to expect editors to understand the entire ecosystem and know when something is due to that or it's irrelevant globally do you have in your in your processes somewhere like we have a process on how to give feedback to the process EEA doesn't, W3C does W3C's processing includes W3C's processing includes how we update this process W3C has a process working group yeah okay you're right it's a community group and that's what they do is they discuss changes to the process and it does get updated actually annually now which is pretty amazing does it have a table of not a table of EOP process or are it informational? there is a BIP on the transcendence chain wouldn't it be a suggestion to improve the process? I mean I think ultimately an informational EOP doesn't have any power to change a thing so if you wanted to change it I think it would be better just discussing it rather than saying it's an EOP and then attempting to get consensus on a change to BIP1 or whatever the appropriate thing is I think it would also be pretty interesting to add an archive on the EOP status because there's so many EOPs that are outstanding or have been touched in months or years that's been an active discussion recently my argument is for a more ITF thing where we don't actually number the EOPs until they get to a more final state and that way you can assume that if it's been numbered it's kind of been adopted and will likely eventually make it to a standard and that your draft is just your draft but that was made with significant objections so instead I think we probably need something like that where since I was a long enough a bot creates a PR wanting the author it's going to be merged in a week and it is stale and it's not being actively worked on and then a week later it merges it and you can reopen it if you want but it helps clear the clutter with the TC39 we have a separate repository and the requirement is that anything that's a draft that is a feature that's just being proposed and worked on has to live in that repository with the new space Proposal Dash or whatever and it's only when it's finalized that it gets to move into the repository with the actual process I think in the GitHub working system it would make sense just to it's in your fork of the the extra repository you know you just link to there until it needs to be merged and the gene needs to be finalized but unfortunately that was I was overruled on that maybe it's time to reopen the discussion I think that's kind of how a lot of other groups are going to get I encourage you to have to reopen the wheel I don't know exactly anyone wants to say what's in on it but that's the problem but we have to do it when it gets to final actually so why not make that decision or let's split earlier and it leads to problems because people like file an issue in the extra repository with like a five seconds description of their idea and they say please see 1, 2, 3, 4 it's not me but it's just she would run some things and says you know it doesn't even have to reply to you you know we were about 10 minutes till we were 10 minutes yeah anything anyone else wanted to ask about or bring up you're all here for the next session I'm sure I have one quick question incentivization for editors you guys have briefly mentioned before just wondering if you have any more thoughts on that and how to get more involvement in the engagement slip me a 20 and I'll read you over please slip me a 20 and I'll tell you the rest of my thoughts on that and well sorry so I said I'm generally very skeptical you know one of the weird things about building standards is it's kind of painful boring work and what you do is sign up and say yes I would like more of that pain than other people because I'm not getting enough in my daily life but actually that's about the only way I know of keeping the rubbish quotient down a bit that doesn't solve the entire problem as soon as you set up incentives for people to do stuff this is like building bureaucracies you don't want to build like a just factory approach or a mechanism to help that my thoughts on it are that's where a really solid and healthy community ecosystem can come into play and so you know you want to unless an organization is willing to say put Brian from Microsoft in a position that allows him to spend 40% of his time editing to spec and that happens with particularly useful or important specs you know that bigger companies will step up and pay for the resource to do that but in a case where the features or the technologies are less business critical you don't have as many companies willing to step up and give that investment so the community needs to fill the gap where and I believe people should be paid for their labor but open collective and Patreon and those things aren't going to really pay anybody's salary to get shit done if there are other kinds of community events community spaces where people can be celebrated recognized and also I think in many cases they need to kind of get to have a little bit of that credit given and a little bit of that deferment like oh we thank you Nick for all the time that you've been spending and kind of like defer a bit to your expertise because you've been owning this process for a long time like that means a lot to people in an open source community where a lot of times you get a lot of shit on when you're a maintainer and thank you but I also thank you for the time that you sit and of course remembering that the reward for doing the job is usually more work but one of the things I have seen one of the things that I think does make sense is that if you find people are doing good work not only do you go around and thank them but slip them a quick 50 or pay for their pay for their airfares buy them a drink think like the airfares to mediums but it should be based on the fact that you stepped up and did stuff and we like what you did rather than or you put stuff up on offer but it's like this is a one time thing you want to shut out if you don't like what you did and you never get any more I think the Ethereum Foundation or the open projects group can do something here where it's like so things I've seen here through this I've also seen people walk away and discuss so I think one of the things that they can do is like you know maybe provide a thank you gift I mean I did this for all of my maintainers of the JS Foundation I gave everybody a thank you card and a shirt and some stickers that was like heartfelt like I appreciate the shit that you put up with and then to your point Dan like if you can afford it bringing them paying for their airfare to come to a community event or having a special event just for them at a DEVCON for example it's not expensive to say we're going to have a lunch you know to thank you for your time and you can kind of come in kibbits with your colleagues in the space and those are just like little things that I think would make it a mess so one of the things I have seen in Ethereum is people watch, you know people do a bunch of work they see some of the people get rewarded and they don't get what they think is their reward and they storm off and don't do shit and I say that not only in Ethereum but in other places you alienate people who are doing hard work by rewarding other people and a perception of injustice and the problem is it's really difficult not to do that because you don't know what people think they should be entitled to so if you start setting up entitlements then it gets messy fast and so yeah the biggest part of the thing is encouraging people to recognize you know that basically the whole point of doing this is we have a really shit job which you probably want to get thankful properly and you should expect it to be painful and miserable rather than setting up a thing of well you know you will get rewarded and you'll get authority probably if you do good stuff in fact and you certainly should but Wendy will come with that expectation you can really upset them in a way that if they come with this sort of someone's good at their work then you're often in a better place Nick is it? Question to you how do you prevent silos across the working groups that you mentioned for example what's the mechanism to keep those separate entities So at the moment the working groups are still in very early they haven't taken over sort of responsibility for their areas the way I would like them to do and so I think their internal communication between working groups is fairly able to fight as well I was quite closely involved with the theory of magicians I was at the first two, I chaired the first meeting but since then I moved to New Zealand and it became a lot harder to make it to the meetings so I'm quite out of date on where they're up to now so I'm probably not the best person to answer unfortunately Yeah, AI participants always get through their own confidence and well it's been it's been physical meetings mostly but the first two I made it to after that it was just literally the other side of the world so which is literally the other side of the world for me So New Zealand it's a lovely place It is, but I know I wouldn't wish that trample on anyone I've done it myself about it many times but do visit it, it's a lovely place I've brought you by the New Zealand to Yeah, but it's one thing we didn't get Yeah I mean so W3C sort of looks at that the problem seriously has done for 20 odd years and the answer is it's kind of a big bad hock if you bear in mind that this is an important problem that you need to keep addressing then you keep remembering that you should have done it and you do a bit of it and as Dan said W3C has what they call these horizontal review groups so groups looking at accessibility privacy architectural consistency it's just an interesting thing to hope for on the web where there is no security, internationalisation and and those groups get kind of because they look at all the different bits of work for the thing they're looking at quite often in those groups you find people who say hey wait a minute this thing and this thing look the same and it's one of those people who says hey you guys should be like not doing this two different ways that are the same thing we thought about talking to each other but W3C also has because it has a formal decision making point at the end of it one of the things that people can object to is like well why are we reinventing this wheel that we already made a square one last week what's with this hexagonal one we shouldn't do that and so if an objection like that comes up basically you can talk to a girl and think harder about it and it may be that the answer is yeah turns out no one like that square wheel we have to triangle once but it's still a bit hard to still like press this doesn't get worked on we should call it because thanks thank you all