EIPIP Meeting 88

Transcript

welcome to eipip meeting 88 we have shared agenda in chat which is issue number 257 on eipip GitHub repository thank you everyone for joining we will go ahead and start with our agenda item and the first one here is to discuss open issues and priyas we will also discuss issues from the past that are ongoing discussion will have a look at the monthly Insight a brief of EAP editing office hour and anything else anyone would like to share or discuss today so starting with uh the very first item under which we have the first one listed

here is placing a warning on erc20 I know this was uh recommended by Sam Wilson Sam if you would like to provide an overview on what this is all about sure I wouldn't say I'm recommending this but um I'm the one who put it on the agenda um so there is a developer um dexaran that is annoyed that people keep losing money with erc20s and they're asking us to put a warning on uh erc20 to tell people that um it doesn't require that the destination of a transfer can actually

accept erc20 tokens so this is fixed in a bunch of newer proposals but people keep deploying erc20s and people keep losing money um my personal view on this is that we shouldn't modify erc20 and if people want to use a better standard they can but I wanted to bring it up here um because I said I would yeah I noticed he was also like trying to get in touch with the foundation through us and things like that and um yeah I think you you sort of

let him know that he was talking to the wrong people but uh he should be talking to core devs and contacting the foundation directly with some of these issues and of course crc20 and anything final is immutable so I think that's that we don't I guess he could open a new way new EIP at the informative level to tell people about this [Music] all right I I

so um my view on this is that uh the rc20 is definitely um as that caveat um and uh that is by Design um finding the right place to show the uh the warning is um something that I felt slightly leaning towards in favor of um but I also think in a larger uh scope in a larger context we should start to think about um how do we allow proceeds uh allow supersedes or how do we allow newer best practice for example like the internet

standards like rfcs they will say this RFC is superseded by the other one and also they will have a number for Best Practices so they will actually refer to best practices in those cases and for standards that's important like the erc20 uh maybe it's a play a good place and good uh um example for us to discuss uh EIP editors and ERC editors group as a whole how do we um harness and QA this practice of continuing to improve we've seen this we also seen the

caveats in the how the approval was made right initially erc20 was designed to set up specific approval approval limit however most of the exchanges uh these decks require a very very high or almost unlimited approval when they actually use that like uni slot permit 2. those are prac what we see in practice and then um I think of a good starting point for us to discuss how do we talk about Improvement of standards and how do we direct people to use newer and better Backward Compatible versions so that's my view

yeah I'm done talking yeah thanks for that I I tend to agree that some form of update or a Rada uh should coexist with the immutability of a final one I think one I can't remember where but I think I offhandedly said like underneath but just instead of something that and maybe when something goes final an author should be able to say like please see this later informational EIP that some of us also wrote that wrote this EIP sort of like

best practices like you mentioned like linking to a later document that nuances that are caveat that or give the implementation guidance or something because like super session sort of implies a technical thing being replaced by an a newer technical thing with Legacy support for whether to proceeding but like just a newer document that just describes problems not foreseen at the time it went final is a different speed you know it's not a super session it's just sort of a please see this later document as well from the author

yeah I know yeah I think we I mean there's like two issues here should these be allowed in in general and in this one a particular should it be allowed I think there needs to be some sort of standards I think I I'm personally opposed to putting a warning on erc20 um for this because it amounts to user error and I think that should be considered part of the warning one that I could get behind was let's say hypothetically there's a break for the Blake too um for the Blake 2 hash function that you know something is cryptographically broken that's worthy of a warning on an ERC or an EIP um but something that is you know practice and use um I don't think raises to the level of putting a warning sticker on there so what are the big problems with these

kind of um warnings and additional notices and I think that's one of the reasons we don't have them so far is that who has the authority to make these claims so like let's say that um I don't know Blake two is broken um how do we verify that it's broken and how do we verify that adding that information is you know correct uh and maybe for for Less um black and white things like this erc20 there are you know fungible token standards that don't let you send tokens to contracts that don't support it so they fix that whole class of user errors but you know I say I'm with you on this one day I know where I I don't

think we should put a warning on it because you know you it's like mailing money to an address that doesn't exist and you don't put that warning on the postal service right like um so yeah basically I just don't want EIP editors to have the power to determine whether or not something is worthy of a warning so I'm you know we should just not have them at all it's kind of my thought I think you bring up a good point uh and a center of it is who has the authority and I I think I'm with you on that in that ERC editors um on probably not the best one to have that Authority

um whether to with that consideration somewhere to allow um readers to be more cautious or have an added educated um approach to it is I think a separate story about uh where uh the authority who the authority who has the authority maybe also as the Authority or maybe we can have a social consensus to allow that to happen and even if it's a warning I'm not saying like on top of it there should be a warning I'm more in my mental model I'm more thinking of um maybe it should happens in the consideration I don't know if it's a

security consideration but um this is something pretty new to a lot of people um the metaphor of mailing an envelope to an empties address is a good metaphor but a lot of people doesn't um yet have established that kind of mindset yet so um my view on that is if people will be writing ERC from day one and if there is a consideration section maybe in the consideration section they just mentioned that not all addresses by ethereum Design as the ad um has the ability to um to send back or to resend another erc20 that's different from the address that

doesn't exist um the USPS will rebond address or if it's an empty house some people can go in there and and claim it and buy the design of ethereum at the moment right now um an address is by uh generated by a lot of the actions and then if it doesn't exist then it doesn't exist right the contract is a hashes or EOS is um it's it's the public key so that's the difference between the empty address metaphor versus these uh the the skin scenario I'm done I'm done talking um

I mean I I think there's I I agree that a general purpose warning put there by some big Collective is not good I was kind of assuming that um you ever did the same controllers have changed ideally after it becomes final as well and whoever sort of like speaks whoever can could still updated if it wasn't final could theoretically add some kind of Errata or booth

a generally useful thing um the Blake 2 example is good because if you for instance if you wrote an EIP that was like a pre-compiled for a specific signing function or you know cryptography is sort of always uh supersedable or unforeseen complications other event practices come up later after something goes final the author should be able to say please see this later ehip um and so it isn't really appropriate for that author to say like two is definitively we can't use it anymore they could only say look at this other document and in that other document it

could argue that maybe it's bad According to some criteria but it's like just pointing to a later document not you know anything more substantive that was sort of like my idea of the Errata thing and in that sense also coming back to the specific case um if this guy this person seems like they're maybe on something of a crusade and like it seems like they're trying to prove a point about the governance or the documentation or something so like in a way it's a politest thing to do if there was an errata option available to authors of final EIP H we can tell the person hey you don't

keep bothering us don't keep bothering ethereum Foundation the only person who could point to updated guidance would be the authors of erc20 Like For Better or For Worse maybe this mean to them but I don't know just just on so I think something that we could probably do today would be PR against drc20 updating the security considerations section with a note getting it approved by the author I think that would be um doable I think I think they could fall under Errata or um clarifications so this I just assumed I assumed that

adding any even non-normative uh text to it uh to a final EIP was breaking the immutability I didn't even know that was an option I was assuming you could only Point towards a later EMP you have to ask the authors to make another yeah Greg you were saying something correct you are muted okay there's the button um a final is final and Errata are for the case where the EIP actually fails to

describe um the actual intended normative Behavior so that this is this is what erc20 does um normatively um for all I know there's applications out there that actually use this behavior for a purpose um so there's just there's no there's no point to to going in and changing these things there are other token standards you can use if you don't like this behavior um and this person is quite free to to write an informative EIP

describing this problem and making These Warnings um and he's free in a bigger sense to um create his own group to start some process of going through going through things and starting up the starting a process for finding these problems and creating EIP to to uh to report them maybe a living iip we just don't have a process for this and it's not clear that it's it's at the editor's problem to start keeping track of ways that you can get in trouble

using various um using various standards there's any number of ways to get in trouble with ethereum and lose lots of money so there's nothing wrong with the rc20 that needs to be fixed here it's just what it is I would agree to that like there could be proposals which are superseding but supersede is no more uh status for ethereum improvement proposal so perhaps we can as Greg suggested maybe suggest the user to come up with another proposal which may fix an informational proposal if that helps so they can share

more information about that and also Sam suggested to have a PR against erc20 I don't know what is the conclusion here like what is the recommended action great great pretty much convinced me that that's a bad idea so I think the recommended action is we do nothing and they can tell people as much as they want that your C20 is bad right I I suppose the author is also trying to talk about erc223 which according to the proposal may be referring to some of the issues that he is claiming to be there with the erc20 so if people are interested they can also take a look at proposal

erc223 which is currently is in the last call and the deadline is September 3rd foreign I think with that the conclusion for this item is uh editors may not be responsible of keeping track of adding warnings to proposals which are already into the final status and the user can come up with information on EIP and share the information at various levels moving on to thank you Sam moving on to the next item here which is update eip1 remove

requires headers I suppose this is initially opened by Panda peep but I suppose some mentioned that we should be discussing it over here yeah so Panda's been having an effort to cite uh yeah like to have EIP show up in Google Scholar um and one of the things you need to do to have that happen is have a like a real bibliography um this is uh one step towards that where uh Panda wants to remove the requires header and instead generate the bibliography from links to eips in The Proposal itself so we would no longer have the distinction between like

[Music] non-normative and normative like EIP references they'd all just be regular links um is this a requirement for biblings uh biography to be generated no can we have that and maybe touch the movie requires later down the road I know that in some places we strictly previously strictly enforces what goes into the requires must uh there's normative links and if we have nothing I'm not I was not a big fan of that requirement but if we

have uh mandated that in the past maybe that needs to be considered taken into consideration when we remove this all together so you're saying you'd like to see the bibliography stuff before we remove the required Setter or I was saying that it since the original proposal was to introduce bibliography section it seems to me based on your understanding and my understanding having a request doesn't block generating bibliography so there's no enough justification to support removing requires at this moment

anyone else has any thought on this one um yeah I agree with Victor there we've I've proposed a reference section um and not all of the links in a reference section have to be up to date in the way that the require section does need to does need to track um track what's normative at a given time so I think they serve independent purposes and I wouldn't I wouldn't want to try to generate require system automatically [Music] um I would appreciate if uh either Victor

or Greg May add a comment to this pull request that might be helpful because panda is not on the call although the recording will be made available but that would help future discussion on this PR I I can I can help put down if yeah very well anything else on this one I'm Greg I am wondering if your hand is raised for this one or from the earlier okay cool

moving on to the next one is uh adding adding numbering guideline I think this PR is also created by Panda peep last month with respect to how we are changing EIP numbering I suppose uh the pr number here is 7388 any comments on that seems to be approved by Sam and okay yeah my cousin also mentioned it for another beer yeah any thoughts by

editors on this one yeah I think it's good to update this since we did change how we number stuff so so this just requires merging nothing else to be done cool so we can consider this as approved and will be merged unless anyone else has any comments to add on the pr directly if not here moving on to the next one is about semi stagnation of the last call eips um this was earlier discussed in

one of the eipip meetings about um uh proposals standing in last call for a longer duration of time I believe at the time most of the editors were in agreement that this is fair uh to move the proposal into the stagnant status anyone opposes to this PR so and let me see this one this um so move this will just say that we can move things from last column to stagnant that's right and with the help of what I mean

I feel like we should just move them forward for the authors but maybe we shouldn't I don't know so what happens what happens here is like if if the pr is not raised if the pr is sitting then we get a warning to the author but if the author forgets to create a peer there is no warning sent to the author yeah I think I'm okay with this it'll just move it into stagnant which I think is fine okay yeah the idea is the bot will move it to stagnant and the moment the bot will

make it to the stagnant it will obviously create a PR and that will automatically generate a message to the author that this proposal I mean this EIP is being moved to stagnant if he or she wants to not stagnant that proposal they can come up with a PR to move it to the final yeah that makes sense cool so let's mark this as approved as well the pr number is seven three four six I felt this is another example of um problem with EIP ownership um the problem happens when authors contribute to the point when they stop getting actively engaged do they still

own the VIP or does the community or in in any group owns this community this come up uh in our previous conversation um of the remove whether to add a warning to yes20 the author was no longer very active in this particular ercs and then also um in in that in this case of when at EIP of last call losses authors to move it to final so maybe in the future we can discuss about how do we handle or how do we help in this case in those cases um in an ownership perspective

sounds good moving on to the next one here on the agenda is ADD adaptable field the pr number is 5533 I think it was added by Sam Wilson um yeah I thought we had decided that we weren't doing this okay ownership problem yes yeah so we need to close this PR I think PennDOT actually bumped it up and we've opened it so Panda was not here um please

okay in that case maybe if we can drop a comment that we decided to close this one and we can take any further discussion on the Discord yeah and Sam already commented perfect uh the next one here is ADD nist as permitted origin for a reference for external link so this would allow linking to cves which I think might be kind of nice and we have an author asking for it I just wanted to know if anybody had uh objections to that before I wrote up the EIP for it or the the pr rather

yes we should be able to let wait link to cve I'm in favor of that all right I'm not hearing any objections so I'll put it on my to-do list just to clarify so uh for this particular item uh people think that it would be a good idea to come up with an EIP and Sam would be taking care of that yep perfect the last one under this section is um update EIP 5069 replace handbook with Charter so in the in the last meeting of

eipip we discussed that the proposal uh the charter shared by Sam should be in two parts some updates goes to eip1 and some update schools to EIP 5069 I see a big overhaul here uh the proposal is being moved from informational to meta and a lot of things are being changed the pull request number is 7468 I think um Sam is looking for some um last feedback if people have any before this could be merged my I'm generally in favor of that direction um proceduralize them uh what do you think if we

change the content and teach them informational at least for a amount of time like a few months for the general public um editors uh authors and everyone to get familiar with them before moving them to the meta the reason being that moving to Mata is enforceable and for important document like this is since we need more um like if we are imposing a review last call final for a technical document I think we should also have a way for people to know that something is coming up it's important and if we want to adopt them there is a time for you to

voice your um your feedback in in general public uh property in general public this this is because the editing itself is still in drugs and it has not been published to be viewed by a lot of people it's currently only editors are involved well this is a governance decision for ourselves so I don't I don't know if it needs to be like open to everybody but I think ourselves if we're refer to editors and authors I'm under that impression because it impacted how authors like being treated in the future down the road

so what would be the the externally Visible Changes that authors would see if we adopted this I think we should I think at least um a better way is to publish it as an informational and then have a PR standing there to say hey in a few a long number of weeks that were moving into Mata enforcing it and you better um response by by this and then also I think it's worthy of bumping up the uh fem threads that this is turning from informational

to um meta I can do it as a different EIP if that makes it better like and just go through the the process um like well that yeah that will work currently no one is engaging in uh in the EIP editor handbook um thread and if we're turning it into Charter which is I think I'm in favor of that it makes enforceable and then then people should really care I'm just really not seeing what other people need to care about for this it's not going to make any differences for

people outside the EIP editor group like there's no topic groups in here anymore it's literally just like writing down our decision making process um okay I hear that you said there's no point notifying outside of the IP editor groups because you think this is a decision make among ourselves um yeah exactly I just I I don't understand what um like like why do we need input from people who are not editors on this um I don't know Dana what's your view I guess maybe providing a a perspective

so when you're working with a system it's nice to know how you expect it to work although this would be law and how these readings actually work as case law and they are quite different so that is a point of frustration is that it's a random number generator when someone who is not an editor interacts with the system um I'm kind of disappointed now to hear the topic groups you're out of this are they out in general are they just out of the specific ERC uh they're just out of it until we like there's still some finer points that we want to work on um so we're just getting this in first and then we're going to add topic groups or working groups um I mean from an outside perspective when The Outsiders don't have any input and they watch what should have been an

agreed-upon thing that was agreed in principle three weeks ago um get spinned over and over they lose a lot of faith so that's that's a perspective as an outsider I I think what I hear Daniel says is that it will if we let Outsider give us the back on this and give them some time it will allow us to uh um accumulate more faithful credit uh from them if we don't then we lose the chance to um to get their credit and to improve our credibility by soliciting outside feedback

is is that a good understanding of your perspective well even if you get the outside feedback um will it speed up the process of actually coming to a decision and consensus because anything that slows down that process is going to cost credibility I'm sorry which do you want um did things go really fast or that the community has time to let us know that that this is a charter for a group that

they actually want to uh serve them in the ways that we want to serve them well we want a certainty it's like a court of law you want certainty you don't want you don't want unpredictability but we we also I do think we want feedback from the community um so that they understand we are the editors and this is what we are proposing to do um we can reject the feedback but it would be good to have that feedback and

we've been around long enough that uh taking a bit of time to try and try and get things right is I don't think a big problem um all right so I'm hearing that you guys want me to have a last call type period for this where we can get feedback from the community um and I'm also hearing that Dano is uh upset that it's taking a very long time and that we aren't making any decisions is that a reasonable summary of everybody's um stances it's not that it's taking a long time is

that three weeks ago there's one decision and then all of a sudden it's just thrown up in the air like 52 card pickup so that's my personal perspective I'm not speaking for awkward devs in this regard yeah okay just to uh I traded here a proposal which are moved as living there are very limited proposals which are in living status that already provides this flexibility to make changes in future that's the reason why we do not have this last call thing added for proposals which are in living statuses however I find it as a good idea to have it publicized reliving the fem discussion

thread is uh good suggestion we can perhaps make use of that but as per my understanding we do not necessarily wait for another 14 days for this to be settled down so if people are okay we can perhaps keep this PR open for another seven days or so and maybe uh we can have um discussion thread ignited again on fam about this change coming up would that be a fair resolution that we are coming to a decision we are going towards uh getting this certainty and we are not waiting for a very long time

I think I'm just more disappointed that it was communicated to me that there was a consensus and they were going forward in that all of a sudden everything's on the table again so that's where a lot of my frustrations come from um yeah I understand that but I I don't think we'll be moving in that direction we are not going back the decision is still there we are just trying to make sure the decision is added and being reflected in the document so people can follow and refer it in future so I see a couple of hands up by the editors here just as a summary we can have this pull request open for next uh seven days and after that if Sam will change from uh you know draft draft to a

real PR that would be merged by bot so anyone having any thoughts try to come up before that so um um so um I think um I would personally suggest that we publish it at as opposed to um merged as a SL post of keeping it as a draft PR because not be not many people will be able to see that and also um publishing it uh allows search engine to pick it up allows much more notification to kick off so what I would suggest alternatively we uh introduce all the change publish it except for the

type being informational rather than meta and uh in a few weeks we made another pull request to Move It from informational to matter just start enforcing it I want to know what people think about of this approach instead my quick question here I know the original author is Sam Panda and me and Sam has created the pr what can be done that bot does not merge it if Sam moves it to draft uh well as long as I keep in draft it won't merge it that's why I keep it in draft

yeah but I think Victor is suggesting that we should make it um like as a normal PR so people can see it and it should be publicized yeah I actually should merge it and publish it as an informational before we start enforcing it in the meta and maybe we should drop a line in the document says this is going into matter if no objection uh like in a time that we agree in a timeline that we agree upon yes Greg um I'm confused wouldn't this be better as a living document um yeah it'll be living in the meta

category yeah um okay so yeah if we go ahead and publish it sorry if we go ahead and publish it and it will have a discussions to link so any discussion on it can continue and as it moves to living changes can be made on the basis of the discussion and I I think that that takes care of of what I'm hearing so the idea here is the status is going to be living it is not changing that one thing that is changing is category and time earlier it was informational and now we are talking about moving it

to meta all right so just to reiterate one final time my understanding of the plan is change the pr from a meta to informational so that there will no longer be a status update then merge the pr and then in two weeks from today on the next eipip call we can ratify the like make this our government's process do I understand that correctly yeah except for two weeks maybe too short for people to give this kind of uh feedback but I'm okay if it's too weak I'm just yeah

the league is generally the um last call period even if we are not following it formally the last call period informally it is being founded here so and this will be I think I don't know week five or week six that the proposal has been circulating at least semi-publicly so yeah okay I'll I'll do that perfect so seven four six eight with the status with the type change back to informational the par should be good to be merged and in the next meeting we can discuss further changing from informational to

meta the next one here is a is a set of proposals for uh which are already into final status number one is one eight two zero the pr is 7506 I think all of them are created by Sam if I am not mistaken maybe you can share the purpose of having this changes to already funnel proposals uh so these are seven five zero six and seven five zero five yeah okay so these two are um somebody put raw HTML in their proposal um they just look like it's just not necessary HTML tag

um so I just want to remove it for formatting purposes anyone has any objection so the other PR 7505 is also uh same or similar right exactly it's just removing okay pre-tags okay so maybe editors can take a look and if anyone has any objection drop a comment over there otherwise this PR should be good to be merged in next two weeks if not before that um

hey Sam uh did you put in like how long does electing uh keeper how often do we elect to keep her it's whenever anybody asks for it so any any editor can be like I would like to elect a keeper and then an election starts oh okay oh anyone at any time can call for a keeper okay agree upon okay yeah that's good yeah he probably went back to sleep I'm sorry about that um the next one here is a PR number six eight six zero it is about a proposal

which is already in final number is 4804 I think there were some suggestions review Suggestions by Sam and author has responded to that I do not see any uh change in the code here but yeah I wonder if people are generally okay to get this PR mush because it's been a while it is setting over there oh so I I'm still I think in the camp of not updating this but um

yeah I guess we can read this and comment on it yeah that would be helpful moving on to the attempt number two okay we have uh eight minutes left and let's try to move as fast as possible discussion continued or updates from the past meeting it is about EAB ER security repositories split I think we discussed part of it in fact more of it in the earlier discussion uh yes Dano if you have to add anything on this topic the eip7329 you asked me to put a review with all core devs should it be moved to last call now

it's really it's the pr informational meta giving the ration office split yeah that could be done anytime okay I'll move it in last call for uh two weeks from today perfect thank you and I think we are good with all other decisions that the decisions were to move part of it and one and part of it and the EIP editors Charter book yes Greg please go ahead yeah Sam and I discussed this um and there's just an editing merge issue as eip1 has changed enough that the merge

can't happen and there's what we want to happen is to be sure that the core devs can keep track of their own statuses we don't want to force them into the that there must be a review period there must be a last call period um they had their own workflow and they need to put that in the document and I think Sam may remember better the choice was whether to just let the core devs use the existing status field for that purpose or whether to introduce basically a working group Preamble that

the working groups and initially the only working group we we have is the core devs that the core devs can use that Preamble in any way that they want tracking status tracking anything else that they want to track in the document and so that's that was the one thing we needed to settle and the other was um a reference section what we needed to go in there distinctions on informative and normative links I don't think that all got settled but the first one I know Dano had a strong interest in and I'd like to hear back from Dano on that sort

of choice so my understanding was we split this entirely in two the split is separate from all other governance issues whether we use headers or not and those moved into the discussion of what's going on with the new um topic groups and with the EIP editor Preamble I was hoping we could talk about topic groups this week because I was hoping that the new uh Charter would have been resolved by now and I think that we can't really talk about those details until after the charter is is complete and set those standards and because the agreement that I remember from all Cortez from two weeks ago was the split is completely separate from governance issues the splits the splits happening yeah that's what's happening that that's

where the files go in the repo that the question is we still currently have a status field and a defined workflow for what goes in the status field well those are governance issues and those can be resolved once the Charter's done we pretty much are done with the charter that we're going to put it up for some comments but I don't expect any substantive changes there so what's what we broke out of that was the working groups because the question the question Sam and I ran into was simply do we give the core devs

the status field itself um or do we give the core devs their own Preamble um to to keep track of their own governance I'm in favor of um reducing the scope of Court governance so letting the uh topic groups decide their own status thing is in line with that General principle that the the central groups are doing less and less is giving more and more power to the topic groups so I would prefer that poor devs get to do what we want with the status groups you could say like well you need to categorize these in some mutable and immutable States um that would be fine and propose a process for resurrecting abandoned and rejected stuff um but I would very much prefer that

topic groups get full control of their status yeah I think Greg's proposal is whether so if let me set this up Greg and correct me if I'm wrong but you wanted to have two Fields one that was for editorial status and one that's for whatever the working group wants to use for their their progress tracking right and The Proposal I recall sing at one point had the mutable and enemy of the fields and you would just map the topic group ones to an editorial figures from that and that would be the task for the topic groups it's establish what that mapping is the real concern about editorial status is is it mutable or not um not really uh I don't think

um the it's up to the working groups of mutable and immutable is even a concept for them from the from the editor's point of view um the statuses that really matter are draft final um and final doesn't really matter to us until after an upgrade really if the editors want to make it go final before an upgrade fine but we're not concerned um we okay uh so if it's providing a list of states that map to immutable and immutable if the topic groups map their statuses to draft a draft status in the final status

then we don't need the uh the editor status because we can map it into the topic group's workflow brought everything in between draft and Final is up to the core devs um and the question is simply do we let the core devs use the existing status field or do we give the core devs their own Preamble in the header of the document there's an extra Preamble that a working group can use to put any Fields whatsoever that they need yeah and I just want the status field I want two status fields

so let the topic groups control status and if you want to add other headers then what um you can add other headers for topic group um but to have like a header that means two different things between core governance and topic of governance I think is sort of friction that'll result in problems yeah I think um so the way I had originally written this up is the first Seven Fields I think were were fixed and that was like the data was created the authors who can edit the document what topic group it belongs to there's a few of these fixed ones but then anything after those those first uh and number of them uh would be totally up to the topic group

okay what I was seeing on the status field is that from the editor's point of view it goes to draft and it stays draft until it's final from our point of view it's a draft and it's subject to change all along from the core dev's point of view it's going through a sequence of changes that the editors don't need to care about um and while Things Are so I don't know it at that so that is very confusing and it's I think helpful for the editors to to know that and it's pretty much just a tooling issue as to how that gets

displayed on uh you know on the uh what is it eip.etherium dot um it just creates a separation of responsibilities um so we're not having to coordinate it all on that so what if uh the topic groups had a naming requirement to say that if they had if that the last word in their status needs to be one of draft or finals so they could distinguish at the glance so we have proposed draft on CFI draft EFI draft test net draft uh main net final so that way from one field you can get

both informations or you could require that they have every um topic group have a final State and their final state is final and it might be final Dash rejected final Dash implemented final Dash mainnet and everything else is draft I think with with two Fields um you're going to get too many conflicting States because the topic group statuses really should map into this is either a draft date or a final state and it's going to reduce it's gonna result in people messing it up um so maybe we could even in in the uh there is no course data that the editor that the authors put on is something that the regulars put on when they render it onto the main page so we could put the mapping inside of the logic that

there's a sort of VIP logic that Panda's writing yeah I'm not sure if we disagree here I'm tired and and there's lots of details and that's part of why it's not in this document is because there are details um some some of the ritualing details some some of them are just my desire to somehow dissociate dissociate this as much as possible so that the core devs and the editors do not need to coordinate um on this stuff and also that the ietf pretty much gets by with everything either being a draft

or an internet standard that's that's it from the from the publication but we very significantly from the ietf that's why I want to call these topic groups instead of working groups because we don't do anything close to what an ietf working group does we don't assign an editor um we don't assign a chair we don't make the chair responsible for writing it it's not a large group so it's quite different already from ietf which is why I prefer things like calling in a topic group to make it clear that we're not confused with other processes well Google topic group and Google working group under topic group you'll get nothing that makes any sense under working group you'll get all kinds of different working groups and all kinds

of organizations working groups are people who get together and organize themselves to get some work done topics are just anything you can talk about the core devs are organized to work on a task um how they organize themselves is not the editor's concern the editor's concern is just is this a document that's still subject to change or is it a document that is no longer subject to change I I think that's the only thing we care about this is not a this is not a hard it's not like I'm hard and fast on this it's just a detail we sort of need to

resolve and mostly I think the editors can resolve it but I don't want to be in the way of the I don't want to be in the way of the court of developers or mess up their process with this so I think we just provided simple mapping every topic group or working group whatever the call just say this status maps to this data in the core draft final hierarchy and then we can automate it with tools something like that yeah it works for me all right I'm gonna hop off I have another call um thanks for the good discussion on this I appreciate it uh Sam are you are

you pretty sure you understood what Dano said I I'm too tired at this point uh oh sorry go ahead I was up working on zkevm stuff with a mathematician in Australia until 4am so sounds like a fun evening but uh yeah my understanding is that data wants to have a file somewhere that says uh you know on the left hand side the name of the status and on the right hand side of Boolean indicating whether it's a draft or a final and then each each working group defines that file that they can do what they want yeah perfect details of it maybe in the future in the

few things but for two days I think we are all on the same page we are going ahead with this split and uh things are being sorted um uh Sam has dropped off I don't know if there is any future call with respect to that uh proposal if there would be I'm hoping that the announcement would be in the Discord Channel thank you everyone for joining us today have a good day thank you