EIPIP Meeting 102

Transcript

welcome to EIP meeting 102 this is issue number 326 on E cat her EIP I get up repository we have a few full requests added here for discussion which are edits to final proposal there are list of potential spam and some Community proposals those have been added to issue on EIP GitHub repository we'll take a look at call for input and discuss some of the earlier meeting decision or look into the progress where we are at um starting with the first item which is discuss open issues PRS and other

topics here I have tried to consolidate a list of currently active full request for proposals which are already in final status sharing the first one which is for ERC GitHub repository the pr number is 304 I wonder what editors think about all these PLL requests I'm okay merching it it's um I went through it it's just spelling Corrections so anyone not in favor of merging

okay um the next one is PR number 317 that is for updating ERC 7231 yep so similarly I'm okay with this one very well moving on to the next one which is PR number 367 uh this is for updating ERC 5585 so this is changing a username

again um yeah we probably need a call for input for this one I can go and open that all right I think there is a call for input open for something similar we can bring it back for discussing when yeah when we are there or are we trying to consider individual call for input for individual pull request meaning are we considering it Case by case um I think Case by case makes the most

sense okay okay so for this one for PR 367 um the decision here would be like you would be opening a call for input and we'll collect input yep okay perfect the next one listed here is uh PR 342 which is for updating ERC 2098 all right I haven't seen this one Sor I just give me one second yeah I have no idea if this is

valid or not um well need to wait for um rickm to to comment very well the next one I see that it is already closed so we can skip this one I've added a couple of potential spam I don't know when I added I I was able to find this uh issue but now it is is a 404 the number is 8352 on EIP GitHub repository I think it only 404s if the

user that opened it is marked as a Spam account by GitHub ah if it had been if it had been closed by the opener or something it wouldn't be 404 okay that makes a lot of sense very well um that is already gone so we we can perhaps take a look into this another one that is 8371 I'm sorry I think by mistake I wrote the wrong number but the next one is 8371 which is again some kind of suggestion it looks like spam so yeah I just deleted it perfect okay um one of our team contributor have created a pull request for RP repository

just to uh add some boiler plate in order to uh enable that repository to be functioning as we have EIP and ERC so um the user will be in a position to fetch data and be able to add it to eips ethereum.org but this is a p request and that needs to be reviewed by RP editor I don't see anyone on the call here today um but yes if anyone else gets a chance and may want to add any input or feedback please feel free to take a look this is uh pull request number 17 on RP GitHub repository moving ahead we have a sorry

that's that's for that's for us to look at or that's for RP editors to look at I mean either way it would be helpful uh because this is just adding boiler plate to uh enable the RP repository I think because we have done work with EIP and ERC both are going to be similar so it would be nice if someone can take a look and add a review comment other that would also give confidence to rip editors I had a chat with the one of the editor yesterday but he's fairly new and is definitely looking for some support from this team uh he could not join this meeting uh because of some holiday at his place hopefully we'll be joining in future EIP

meetings sounds good what do we know if the boiler plate was just cut and pasted from another repo like the EIP or ERC repo my best guess is it should be very much similar to EIP ERC repo yes okay I haven't reviewed the proposal I'm in the pull request here looks like a giant copy paste from some some jaal site with the exact same setup I'm just trying to figure out how how it would be reviewable right the idea is like you know we want to have all those repository because ERC was a fork of EIP

it has the exact set so it was convenient to be used but rip was from the base uh we would want that to be like on similar similar page so it would be easier to pull out data from there feel free to add all your comments if it feels like not a good full request we should not let them merge this one but yeah we could uh use some guidance here moving ahead we have a bunch of community proposals added to issue section uh on E GitHub repository I don't know how much we will be able to

discuss here today but just have added the entire list uh the first one mention here is about um living EIP it's a proposal about living EIP I wonder if people have any thought they can share it right here or maybe add as a comment so what Sam asking for here they're asking for um what just a way to link to an EIP or or what the kind of feel like he's asking for a hash link or something but where like uh yeah I guess I can just

ask that so made as a reference I mean one way to easily do that is to for the EIP to carry the last version of this particular AIP as a pre as as a header and so basically Perma link to it and then you can clck click to go back and then you can click to go back oh like you can look at older versions of e one kind of

thing yeah so basically latest version will carry the the previous version okay and so so basically as a header as a preamble as previous previous version call op link so um if I understand this correctly I mean not exactly this but how uh the proposals work on the giab repository here we do have the history of all existing version like if we get into that uh um double bracket kind of symbol which is there next to um the name of the proposal we'll get into all history and uh I'm not very sure but

this could be even solved with the proposal that we received earlier about versioning in one of the comments to that proposal on FM I have mentioned that we can perhaps have the like vertion update number uh for all proposals including living of course that that would definitely solve this problem as well yeah yeah verion update navely could be just the git commit right so yeah exactly yes yes it it almost sounds like what they're asking for is a uniform notation like that it's kind of strangely worded

but it's like some identifier should be made as an optional reference passive voice not sure who gets to make one or who specifies the identifier syntax or something but it sounds like um the example given is like EIP 1 March 2024 should be some there should be some standard way to write that like ip1 some symbol like it sounds like a query parameter thing it sounds like they want to be able to say uh yeah and they even mentioned the commit specific GitHub URL as something not recommended by

w3c but um they want something functionally equivalent to that or that I don't know yeah I think we just need some more information from from Sam before we can deal with this right does that make sense sounds good yeah I just wanted to bring all these uh proposals here in this meeting so we can uh start interacting for proposals which are good and which can be implemented let's hope for some response and we'll look into it in the next meeting sounds good the next one is uh another proposal

for Citation for eips uh the issue number is 8292 I'm the link yeah that that one it's a good idea no objection for me to it would be it would be good idea to have the next step mentioned for the proposer here um

so he can like proceed with the proposal make a respective PR and then we can discuss the pull request sure yeah Sam are you typing that response I got that oh you got it okay yeah very well okay uh so the next one here is with respect to eips and ERC uh split I think uh there were some recent comment added by William Inon um yeah what people think about

it I think he wants to clarify that we int Our intention is to finish up the uh the the split which I understand uh and uh given our consensus uh I agree that we should proceed with split and large part of it is done he identify specific task list uh I think we should review whether these are good task uh reasonable to be an open item um Sam what's your what's your view on that um I mean I'm Still Holding Out for some kind of agreement on working groups so all of this would be already done

over there I think oh okay so you are your plan is to wait for the working group uh splits or working group set establishment and then come back to to revisit this work plan is that a understand yeah exactly like I think everything here um yeah everything here is taken care of already in um the Eeps WG REO so yeah it would just be once we get like once we get editors to agree on moving to working groups then um all of this would be taken care of

already okay reasonable uh do you want me to like leave that message I'm I'm I'm in in agreement with you should wait for that yeah I'll leave a comment to that okay very well so the next one here is uh add last updated information to EIP ERC page which is the issue number 8282 is it is it similar to what we have have just discussed uh about the

versioning uh yeah actually that is something else that's already taken care of in the working group stuff so I'll I can leave a comment to that effect as well okay sounds good yeah sorry that's a rather unsatisfying answer but oh I'm sorry I was on mute yeah that sounds good anyway yeah I mean as long as all these proposals are receiving comments from editors or whatever people think they are receiving updates it's good so we can move it forward like whatever is the next step people can think about it or if there is something already being done in parallel which

will take care of it at least they will be satisfied so yes that's helpful now I think the question in uh in the last link which is a282 does not involve split between Erb and ERC or establishment with work group I think they're asking if they can automatically or manually add uh last change date of an EIP yes so um the it's not it's not like part of the split just that feature is already implemented in My Demo oh you did yeah yeah of of L last updated not yep exactly so like if you it can be closed the is can be closed that's

already done just waiting to release right um again if we decide to go with my implementation it can be closed I I don't want to just straight up close it because okay yeah yeah I love to use your refer implementation this seems to be a very useful thing maybe uh maybe if the feature they're asking for is already in the draft repo like the the EIP working group you could be it wouldn't be too cheeky to link to like the specific line where it's implemented in you know yeah yeah do that Jack or whatever and then say this is currently in draft here's where you

can go vote on it or like show support because I don't yeah I think I think it's fine to let people know that like this working group split governance is blocking just the operational stuff like there's already draft that would solve this just point them to how they vote is what I mean yeah yeah I wonder if it's there is possibility to depel that it seems that it doesn't have to depend on the working group split it can actually be useful for both right for both EIP and ERC yeah as long as we can come into a consensus like our consensus doesn't

this consensus doesn't depend on the split or anything right if the split if the split is rejected then the same link to the GitHub example could be copied separately by two different the governors of two different repos very well as since this has been already taken care of uh let's move on to the next one which is uh issue number 8269 um it's something suggesting abolishing ipv4 and

IPv6 propos change of what oh this is somebody who wants to be opening yeah um based ethereum address decentralized IP address yeah so this supposed to be a I think I'm so how did you this is a worthy question how do you Vision Sol

it IP V6 is yeah I really have no idea like this sounds like it's supposed to be an EIP it's supposed to be an RSC that's it that way yeah yeah so I'm just going to close it uh with a little comment and uh they can yeah maybe take the idea to Fellowship of ethereum magician collect some input there and if this looks like a potential proposal they can eventually come up with the proposal exactly

yeah very well this covers all the proposals uh listed here for today's discussion moving on to call for input okay I had this one big question for editors joining this call how to lower the number of open issues and po request I was just trying to take a look at the at the um chart that uh I created based on the um eips Insight of all open issues and pull request since January past 3 months it doesn't seems to be getting lower it's getting higher so we might want to maybe

consider something or any suggestion on this part I'm not sure how to handle this problem um like I I try to edit as much as I can um and I've been mentoring uh somebody else to hopefully add as an EIP editor eventually um but I don't know what the um like I don't know what we're supposed to do to review these things faster I think there is several things that could help one is that it's a little bit hard for me to kind of maintain a pipeline of things that I already started uh looking into I kind of have

to do search all the time um and also I think it would be helpful uh if we can have some kind of way to prioritize come up with a way to prioritize certain s like these ercs seems to be more um like reasonable to prioritize if we have scarse attention um so for the second one I am currently thinking of like reaching out to people and constantly ask if they want to like notifi uh like they if they have want to flx some of these uh these existing ercs as as

more prior as more prioritizing to their view um maybe at some point I will ask them in more open space I've been reaching out to editors uh to authors as well uh uh to get them respond on the E FMS and also invite them to the orc devs and hopefully whoever engage more actively uh means that they're actively at authoring and we can also prioritize based on um how responsive they are in terms of authoring so that's that's my two cents um love to hear feedback at adves so I have noticed on the ERC side

we are receiving a bunch of new proposals which I understand if if it is reviewed and receive editor comment that would be on authors to continue working on that we are taking a lot of proposals a lot of bll request in editing office hour and I understand Sam is already trying to respond to each one of them based on like whoever who like authors who are behind it they want to join the meeting and they want to talk about it so the major input or the major Ro Blocker on ERC side are the new proposals which require a Tarot review before it could be merged but on the EIP

side uh if we notice there are mostly updates we receive very few new proposals but even if they are open they are open for quite some time so I'm just wondering is there a way we can speed up uh the updates uh not the new proposal I mean like I understand new proposal will require more time to to be reviewed I think I think signing sorry go ahead I think as long as uh people uh basically are doing something with updates and uh editor has reviewed it at some particular moment it is fine

I'm not sure if that can be merged directly if the updates are there or can it be uh so if people if it's in the draft status and people are pushing on draft I think it's autoing and if for example someone else if there is a author change then it lingers on oh it doesn't get merged automatically so drafts uh if you push on drafts uh it get merged automatically yeah for example if I author and the status is draft and I basically push on a draft I create a PR on draft as soon as uh the CI uh is

green it gets merged okay so it's not broken at Le at least that's good yeah so I think the only open uh updates that I have seen mostly are about status changes or they are about uh adding some author to it which is okay and I see some changes are being pushed even for the final proposals which are like kind of fixing reference test I'm just taking an example here uh this is for um this is Port request number 8390 which is for an EIP 152

that's currently in the final start it seems like uh the author is trying to update reference test here small PR I'm not sure the utility right now but U how do we deal about these do we need to invite the authors to maybe approve them and that gets into merge or because these are already final proposals sorry what was the question again so how do we want to approach the final oh yeah propos like P request for e is in final status here I think if it's a trivial change like it's an

obvious typo just merge it as an editor um and if it's anything that's possibly controversial open a call for input that's kind of what I think on those it doesn't seems to belonging to either of the category so it's like adding some of the reference test it's possibly controversial so open a call for input this is the final one right it is exactly yeah if it's final they're extend extending bits in the in a test in a in in a test test case for that are we talking about six uh

8390 is po request that's right yes confusing it declares oh okay all right yeah I think that's that's okay um we should be able to accommodate that should we call make a call for request call input yeah I think so if we're modifying a final EIP and it's not like trivial we should probably open a call for input okay should we ask them to do it or should we do it yeah whatever is

easier like it's if it's if you don't mind making it just make it for them and then it's easier okay I can I can help them make that I need your template though uh I I love the the way how you make all call for input I couldn't make that table oh uh sure um can you can you if you can if you have added access can you add an issue template there so oh is there an issue template yeah I was about to suggest that can we make it yeah can we yeah I've never done that yeah somebody need to give give uh Sam the edit which I don't have so if someone can help with that

that would be great um I think Sam you should have the permissions but in case you do not then please do let me know yeah I don't think I do I can't it yeah okay I'll update it later today awesome thank you I'll wait for that to start the full request to the cof input I'll put it in my to-do list all right uh so that that was some open questions with respect to open issues and pull requests we hope to see this number getting down because now we have already reached to the mark of 100 which is like before we enter into exact

three digit let's try to handle this as soon as possible with that we can perhaps move on to call for inputs I see the first three call for call for inputs are already closed so we have added the result since we could not meet the um two weeks earlier I have just added the result here for people to follow and we can perhaps discuss some of the new call for inputs which were open uh in the past two weeks I see uh the first one listed here is number 320 initiated by um vend if I'm correct issue number 320 would you like

to maybe provide a background and yeah where we are it's not really initiated by me but I read in that uh so I think it's initiated by Sam yeah right right sorry I'm just in strong favor sorry I lost my uh my mute button there um we're looking at 3177 isue 3 32 z Oh 320 okay uh yeah so it somebody wants to make a link to uh capes um I'm kind of against it because they haven't been around for 10 years

and I'm concerned about giving legitimacy to standards organizations um as opposed to just copying their documents um I don't know if anybody else has any thoughts on the topic I'm in strong favor of allowing link to that you know my stance I mean 10 years is a big time in this industry and uh even eum has not been around for that time so or has it um I mean it's been around for at least a couple years now um five yeah but um but sorry I uh I'm I'm having bad

audio I didn't understand was the question just how long it's been around or I guess my my question about the legitim legitimacy thing is like um that that's very much a value judgment that I I support the EIP editors not making but I I feel like it's sort of uh required by the process of having to approve one by one authorities or domain names yeah so like a officially um the only objection I have is on the length of time it's been around um unofficially I'm concerned about giving legitimacy to standards

bodies that we don't necessarily think are legitimate but that's kind of an offthe books objection I won't like hold up the process based on that like if uh gajinder and and um Victor you both think that capes have been around long enough and you feel like they're you know available then uh we can go ahead and uh approve this call for input I'm not really particular about this particular thing in general I'm of the opinion that maybe we should be more welcoming and allowing as much as we can given they meet certain criteria and criteria shouldn't be 10 years I mean

this is quite of criteria criteria should be in terms of they're not fraud and uh the contender is not bogus I think if if basic sanity can be met then probably we can we should try to allow as many links as possible and then basically it will also not uh not people will also not infer legitimacy from it because if our stated policy is to to allow most of the things and only to Gat keep what we think is bogus and bad uh it won't basically you know act as a stamp of approval to these

bodies that makes sense so I guess the only official rules question left to answer is do you think these links will stop working eventually or do you think they'll be around for the long term I'm I'm less concerned about the link stability here uh there's internet archive and other tooling and ipfs we can help use to kind of Ensure the link stability even erc's are now in a danger of of REM removing itself we end up having to move things um so yeah I generally am in favor of opening up uh more flexibility for authors to link I feel that being able to link is

important for authors to think and also to welcome interoperability so you're both raising the points that are kind of different like you're arguing that our links policy should be changed and I'm asking does this link meet our current policy so if you guys say that you don't think these links are going to disappear then we can merge this right now if you guys want to open a discussion about changing our link policy that's a different discussion yeah so I'm I haven't actually looked into this particular thing so I would't basically say that this is okay or this is not I mean I would basically rely on someone else input on

it so EIP 5757 is our policy for links um as long as we meet the three requirements um there you can link to a particular version um it has a history of availability and it's free to read then we can link to it so as long as you both of you say that it meets those three criteria we can have these links I don't see any reason that they don't uh for now um but yeah um if there's any concern I'm happy to kind of help to help to talk to them to to to their to them to see if if they can be

resolved and yeah I said I don't know this organization so I don't have a particular opinion on this I was just trying to chime in in general you do know that if that domain names are having a limit of renewal for 10 years so requiring something to be 10 year um it's probably needs update uh we need to update our policy but yeah yeah so the policy says it is a sufficient but not necessary so like we can like if it's existed for 10 years we can say that it'll probably exist for another 10 years but it's not necessary to have it exist for 10 years it's kind of like a

guideline if you want to P to have Case Case by case and I think there's no reason for us to believe it wouldn't exist for 10 years uh if you want the general concept I think the only thing I know about ethereum that has last for more than 10 years is yellow P paper and it now it it start to become uh deep deprecated in our policy so I don't think anything actually last 10 years if you want to look at it yeah yeah exactly um we can yeah so I'm hearing that both of you want to merge this and that both of you either giner you don't know the you don't know it well enough to argue the specific

points and Victor you think that it's it has existed long enough and you think it's going to exist forever is that kind of a reasonable summary of I agree yeah I do I think you you summarize my opinion right cool well then I am fin us thank you so does this mean that we are going to add CIP to the list of links that we are allowing Perfect all right moving on to the next one which is the issue number 325 at e cat so it's again started by Sam Wilson Sam would you want to maybe provide a summary of that

sure thing um so this is changing author's username in 1193 if I'm correct that's right yes yeah okay um yeah I think I'll just read through this and and we like decide what the consensus is um so we have me we have like client in favor uh Victor what's your thoughts on this I'm generally in favor of of allowing editor yeah allowing author update them regardless how we generate that uh consensus and uh if we go with

uh what like L you want I think at discretion I'm in favor of it uh if we can go even further we can publish a policy and go by that policy that's even better but yeah let's allow authors to go for it okay and reading your comment gender it sounds like um you are okay updating this as well right yep okay cool so the decision is in favor of the proposal and it will be merged is that correct understanding yep perfect and uh it seems like uh uh and also Victor just mentioned that uh he is in favor of having uh some general policy around it and from the last meeting

101 um I don't know if there was some call for input to be created Victor do you want to take that one as well yeah um I think a general uh said I I my feeling is that it would be better for us to kind of declare why we agree to update their username and for me is because authors should hold that power uh we bar we just for the c p that and uh if we can agree on that kind of policy then we can take that as a policy if we cannot then I'm okay that we back down to at discretion but uh I I can see that uh

one of our contributor uh a ad I don't know how to pronounce his name I new Weekly News editor I never try to pronounce yeah AB I see I say ABC ABC o oh yeah you know who I'm talking about so I think he has a strong opinion to to not have no policy like he wants to have a policy uh and I think I can resonate with that a lot so i' like to discuss with you you

guys I understand this is not directly affecting the response or the result for issue number 325 but um if you would like to maybe go ahead and create a call for input which was recommended in an earlier meeting we can perhaps take it better in that I mean like we can collect feedback response in that one and it in future oh you already did did yeah I did I I am sorry that I probably forget to include that in today's meeting agenda because it was open two weeks ago uh can you can you please number that yeah I I just oh it's already listed oh I have updated it it's already listed okay we'll get there so so I am in favor of uh option three

um I think Sam you don't want to create a you want to remain using a consensus H one time yep uh and then Gant I think your response is simple reject I don't really understand what that is can you help me H why do we want to update the list again I mean I think we have been through a particular kind of this PR where we have you mean just don't just don't let people update them their their name at all no no update their name but not the

change the list of authors oh so so don't let people add or remove authors but let them change their username yeah I mean if it's simple to verify it's the same person yeah okay so no new no new author no remov of authors uh but it's okay to update their name it's okay to update their handles yeah I guess because because for example as somebody mentioned uh on that other PR that someone else has taken up their handle and if that happens then it is basically you know a bit uh so basically

misrepresentation has already happened if and we should or that author should be allowed to correct that okay I can I I think I can agree with you on that I'm fine either way uh so um I can second you on that um my first question for you is do you think that it would be approved by discretion at discretion or consensus or do you think it would be authors it can't be author because there needs to be a make a checker principle over here so maker can't be the Checker here maker cannot be the Checker but uh

the other people if they if they have other people on that author list can validate them I mean it's s of Outsourcing the tasks that we have and making it easier and anyway we will rely upon social consensus to actually figure out whether uh it's the same person or not uh so maybe it's okay so am I hearing it right that uh if author says if the group of authors says that that is the right handle to update we should just appr we should just approve it we don't need like editor discretion I mean unless editors is

something fishy then maybe they can sort of ask for more proof but in general yeah there is no other way I mean we can't go and do a kyc of the person right so we have to rely on social consensus for this okay yeah I agree with you if we use a call for input each editor can use whatever criteria they want to make the determination so like if if I want to you know send an email to the person and make sure that they confirm the changes correct or if I want to talk to all the other authors and make sure they all agree like then I can use that to inform my vote on the call for input like I

think that's easy enough cuz like I'm not like for example if all the authors on a poll request Say Hey I want to change this person's username but I email the person and the person says they don't want to change their username I'm going to follow what the per the email says and not what the rest of the authors say yep that probably makes sense okay that's fine I can see the concern there um so you you mean you want to make it still a editor consensus yeah absolutely like I don't think we need to special case this anymore than we already do like everybody we make a call for input everybody puts their opinion in and then we decide how to handle the author username

change okay I am I am a little bit concerned but um I'm okay to not insist if you both wanted that way I can say uh we agree that it will be cul inputs uh Victor Reserve opinion um like we can we'll just follow this like we do for all the other calls for input so on April 29th I'll look at this this issue and then um make a call based on what comments people have left um and I think that's and in that case

I'm going to say if the authors want to add an author I can still have the rights to to allow that right you can make a call for input and we can talk about it absolutely okay yep yeah so it's like for things that are not controversial like for example like fixing an obvious typo we don't need to call for input but for things that you think might be controversial you should make a call for input otherwise you'll piss people off sometimes it's hard to know where yeah I know I know I know yeah I guess we can do this if someone wants to do it we can kind of go ahead and do it unless two

people raise their concern and then that's an obvious uh that's an obvious cont controversy so you're you're proposing a change to our like decision- making process or specifically just for for the for this never mind I I I was I I was thinking that our our attention together is very scarce and and anything that we put on that require our C would just hold our operation um and let's say if we have more time we should be unblocking the the

split so we shouldn't be discussing the the username updates for like three consecutive um EIP IP meeting while holding the other things that you probably think more important um on hold and especially you put in tremendous time to implement this ew and all toolings and then you're waiting for other people to to approve it I'm 100% in favor of like moving forward um but how frequent do you think that these are going to be I think it's going to be very sparse it's like we get 20 after an air drop and then it stops until the next

air drop it will come more often given the given the pro protocol Guild approach has become a common thing and I think it would come more often but it's okay if it comes up more times and then we realize this a blocker will definitely bring up and discuss it again sounds good uh so I think we're looking at um 327 now um call for input

change solidity in uh 7 2011 um it's changing a tiny bit of solidity um please leave your comments on the uh the CFI I'm just going to go quickly here because we already discussed 329 um 331 what is this one so 331 is another change of username one um yeah please just leave your comments on it and uh I'll sort that out on May 2nd and then have the last one uh which is typo correction PR so this is whether we merge 8254 or not um so again leave your comments on

those P requests uh or issues rather um and that's it for call for inputs and Sam if you may check your permissions I hope you should be able to create the template for like going forward people can just use the issue template to create this call for input okay I'll take a look thanks very well we are about time I would just quickly take a look at if there are any pending action items um we have updated the hacken B for eips inside for this this month and we already have discussed the increasing PR number we will perhaps take a look in the next meeting if there is in a way uh

to bring it down from the earlier meeting there was this one just trying to uh check item number five there is an action item for updating ERC 7201 fixed solidity formula Sam wison will create a call for input for this fold request wondering if we have covered this or this is yet to be created y that was already that's created yeah it's a 327 okay very well and I think uh Victor one is 329 which is again coming from the earlier meeting

so we are good with that and that covers almost everything especially the main items on the agenda thank you everyone for joining us here we hope to see you in two weeks and please feel free to add any action item or any issue that people would like to discuss in future meetings we create the agenda right after this meeting thank you everyone thank you Puja thanks everyone for coming yeah thanks talk to youall soon