EIPIP Meeting 47

Transcript

all right welcome to the ethereum improvement proposals improvement process meeting 47 eipip meeting 47 we have agenda shared and the first item listed here is a eip's repository spam um we briefly discussed this concern in the last meeting and micah pointed out it's a concern and how it can be addressed it was also brought up by sam wilson in the ethereum discord and uh the last message from micah on ec scott suggested to be added to eipip meeting and to be discussed so micah if you would like to briefly

talk about the issue so the i realized the other day that the majority of my time doing eip editing is actually just dealing with uh like administrative stuff like reporting spammers and closing tickets that they create and closing deleting comments when they leave them this is a job that i think pretty much anyone could do like it doesn't it's not terribly hard to learn to identify the spam they're the spammers are not particularly ingenious they seem to be in a hurry their accounts are very obvious and so it's it's a relatively simple process to just go through and delete their message if possible uh close their issue if they opened it closer pr if

they opened it leave it leave a comment if there's confusion by actual editors or authors about the the spammers and then report them to github and uh i think if someone was doing that along with a couple other like little administrative tasks like categorizing like putting labels on things or mentioning people as needed like mentioning appropriate people i could in theory uh unsubscribe from the eips repository and just get the mentions at that point which would lower the burden greatly and lowering the burden is a mica is a good thing because it makes it more likely mica will stick around for a

long time and so if we can find someone to fill that role perhaps someone who is interested in getting involved in the process but doesn't have like the deep technical background to do like uh the the editing itself that might be a good opportunity for somebody that make total sense um just wondering if we have anyone from the present meeting who would be interested because my understanding is this uh rule can be done by someone who is having uh access to delete messages and report yeah so the the hardest part is finding someone that is trusted enough to do this um trust being hard to come

by on the internet uh if we can solve that problem then i feel like we just need to find someone who's interested and meets that trust requirement hello yeah yeah yeah so what we can do is that maybe not directly trust someone just assign someone to figure out what the spam issues or pr's are and then tag someone who can actually delete it and then see how how active they are and depending on that maybe we can give them an access or something like that does that make sense if that's fine i guess treatment yes i'm trying to think of how much

yeah that would probably help i mean again that would get to get us to the point where we at least can um like the editors themselves can actually stop unsubscribe from the eips repo which would be really nice yes yes because the repository is very spammy and a lot of it is stuff that the editors don't actually need to respond to it's just people like updating their own pr's and whatnot and you just get you know you get a notification every time and it's uh if we just had one person whose job was to kind of go through all of that and then mention people as necessary and i can include you're right it can include mentioning someone to say hey spammer please delete yeah i've been having kind of doing that for the past week

tagging pooja you are maybe like uh sorry matt sometimes if i find a spam comment um uh what you can also do is maybe you know just tag maybe you puja or matt and at the end of the week you can take up that responsibility and delete those because you should you might not it not be effective for you to spend uh time daily deleting these issues or pr's right because they are spam by default and they require as as much less attention as it is needed by the eip editors so it can be done at the end of the week or maybe end of the month whatever or like a fortnight one whatever works for you good first step maybe i mean realistically i'll probably delete them as soon as i notice the

dimension which is fine with me i'm trying to find a good example i wanted to uh one second let me see if i can find a vips i wanna do a screen share and just show you guys what the process is um for the reporting and how to identify them um anyone happen to know recent spammer there's a lucid 36 guy uh yeah okay can you pull this up and i'm sure

you can see that and it's a thing you see a github it didn't get in excellent that was close okay uh so um this guy for example so my usual process is so right off the bat they almost never fill anything in here if they do something feels name in for the the description or their comment it'll be like just like a link to somewhere else or another eip or sometimes they get particularly clever and they copy and paste someone else's submission and so you do have to look out for those like um but if you go and click on the user lucid36 here so one of the indicators is their new

account so this account is actually older than most a lot of them just like they just started committing this week so these this green heat map here will always be shifted to the right for spam accounts if you if you're not sure you can also look through their activity and you'll notice a couple of things that are odd one like they'll contribute to a lot of ethereum and cryptocurrency related things and if you click through on their or look at what they do they just do like spam pull request approvals or reviews for example this guy just reviewed you know from 12 different or six different ethereum or cryptocurrency related things they just did a bunch of reviews

in a day um they will also you know if you again just dig through um you'll see they recreate a lot of repositories um again this is fairly abnormal for a real human to create massive prosperity not always these are just each one of these like another little red flag that you can look out for and then if you really want to check you can look for if they posted an issue or a commit or a pr and you'll probably notice that they look like the same thing that they they posted in the theory ips like this like this person is just posting addresses or hashes or something in the my ether wallet repository i think this is obviously

this person and then their friend here are just spamming so anyway so i just do a quick glance this usually takes you know i only spend i don't know 30 seconds or so on it after you've done a few of these you start to notice the pattern and then click this block or report button here actually i take that back then after verifying go back to this page if it is a comment or a new pr or a new issue you can click the dot dot dot and report content here in this drop down and i'll take you over to github's report feature to do and there you go okay and so you just go down i'd like to i want to report abusive content or behavior i want to

report spam or users is disrupting my me or my organization's experience on github and this user disrupting my organization's experience on github and then down here you have to type words or else it will fail and so spam issue creation i think it's pr creation full request creation something like that hit send and then finally that'll go off to github and then finally you go back to the pr question and close it if it was opened or in this case if you don't have the ability close just mention micah and say hey it's the spam please close it and that's it and move on to the next

one um we get maybe five to ten a day of these i think this is off top of my head maybe that's way off i don't know but it feels like five or ten a day um and they're just tedious like it's one of those things that you see a notification or email that just is annoying and um there's two other problems if they do the spam pr review so a lot of people these these same spammers will just go through and those review a bunch of pr's and they'll say approved or reviewed or comment or whatever um and this has two problems one is confusing to authors because authors think oh someone reviewed my pr but this person did not review their pr they just are spamming the repo with approvals the second issue is there's no dot dot dot next to approvals only on comments

and so as you can see on this line there's no like dot dot report so this is where you have to actually open them up go into their account and then you click block a report on the left and then report abuse here and that takes you back to the same page the last and final problem is and this the irony here bugs me um github will only yet let you report people at a certain rate and then you get rate limited for reporting people and they tell you to stop and so if you have a spammer that has two accounts you can outpace your one account that is reporting them and so you have to go create a like second account just so you can keep up and report all of them i've only run into this usually if i fall behind the spammers aren't that bad that

they get to the point where i get very limited but github does rate limit you after about three and then you have to wait an hour or so before you get cleared to do more so if someone could do that and like i said just if you don't have delete access just mention me i try to for comments i try to delete them because you can actually delete them you cannot delete pr review comments but you can't can delete like regular comments if you're an admin and so for their comments i try to delete them if they left a review i usually just report it unless the author is confused by it like if the author says something in response i'll usually have comments saying that's just a spammer please ignore but otherwise yeah just message me and so i can close the issue or delete the

comment does that make sense to everybody sure i do have a doubt micah what's that yeah so i do have a doubt so let's say if i um if i go ahead and i mention to you that this is a spam do you also would like to have an explanation as to why i consider this as spam so that makes easier for you uh no i would just say um i'm guessing that i will recognize it right away as spam um and so like i'll probably still double check at least at first um but if i disagree with you that is spam or whoever mentions me if i disagree that is spam i'll probably i'll leave a comment saying i don't know about this

uh okay but i'm guessing like like i said i i've gone through enough of these that at this point it takes me about 10 seconds to identify someone as a spammer or not yeah i mean every now and then they do something new and clever and it makes me a little bit longer like one guy actually had a pro account they were spamming with meaning they paid github money to spam repositories and that caught me off guard because that was the first time i saw a pro spam right um i still end up being a spammer i but i spent a lot more time digging into that one than i do most of them but yeah like i said most of them i can recognize right away and so the goal here is to make it so i can my my hope is that we can get to a point

where i can unsubscribe from github like uh and instead just get mentions because right now i'm watching this repository for all activity and i think i'm the only person that does that and so i'm the only person that sees you know half the stuff that comes through well this is certainly helpful it's not only that people who are like one of us who are actively involved in these eips repository can uh like tag you or the other eip editors to flag these spams but anyone listening to this call can do that so thank you so much micah for

screen sharing and explaining the process how it can be actually reported and just for record she shank i do not have edit access or delete access so i can also like just forward it to eip editor so it's better to mention it to eip editors only i mean like make a mention of that as right now you can also it might make more sense just to mention and link me like in ethereum cat hearders or ethernd ep editing channel um that way we don't need to further add more spam on top of their spam to people's pr's and whatnot that makes sense because it will again increase our github notification yeah i think that would be better yeah maybe on the discord server it will be

better yeah it's not sure yeah so anyone who notices one just mentioned me and then if things are going smoothly i will unsubscribe and be happy uh well that sounds like a great plan to move ahead i just hope that it should not be against pan spamming but i hope that this is going to be very helpful because these people are not just creating spam but they are ultimately harming the innocent people who believe on them by looking at their github uh you know colors on screen that they are contributed to some of the repositories all right

let's move on to the uh next issue listed here unless anyone has any final comment to add cool so the next item listed here is discus and document process to merge eib bot uh pull request the present eip bot uh it was developed in uh 2021 thanks to elita mo for working on it um i know the eip editors have helped a lot to improve the process of eip standardization in a year and half uh like in in the past 18 months and even at ech we are trying to engage more contributors to work on eap bars

as we know that shashank um he has been working with alita and um looking into the issues which are reported in eip bots issues but we are trying to make the process more uh community contributor based like people should be finding finding it very easy to come forward and help us with any issue to make it more manageable um i suppose he has some thoughts on documentation and process that he would like to share um yeah so i was thinking so currently i don't find any documentation or process as to how one should be contributing eip bot or also how how does the eip part even work

so maybe having a documentation in place of the process of contribution and the understanding of how the iap board is working at a code level uh maybe adding more comments or having or having a general spec for the epipod would make sense um so that any dev who wants to contribute to the ib board can just hop in and look at the documentation and start contributing so that improves the process of me or elite or some other main contributor to the eip what not having to be present at all times to communicate and uh you know dispense information uh it will become uh easier for the devs who are trying to

contribute uh uh from the contribution point of view if that makes sense so i will push back slightly on that with any given project the act of writing documentation is quite time consuming and so you have to weigh is the benefit of the documentation does it outweigh the cost of writing it for some many projects that definitely i wasted like because you get you know 10x 100x effort versus payoff so if you have some piece of code that's likely to be interact with by hundreds or thousands of developers then having documentation is critically important because it allows one person to help inform thousands of others

if you have a piece of code that is worked on by two people very often the active writing documentation takes far longer than just having those two people talk to each other and so the thing that i would be curious about before we sink a significant amount of time into documentation is do we think that the eip bot is going to attract a significant number of contributors and authors or do we think that it's probably just going to be one or two people i think that would depend on how much do we want to automate a stuff using the ip board right because if there are too many tasks being being added or being pending on the eip port then maybe having that

documentation or maybe a basic documentation in place not a maybe detailed one just a basic as to how the ip bot is kind of working like what are the workflows uh and stuff like that would make sense something minimal like contributor guidelines or yep okay because maybe like how to get involved would be a very worthwhile section writing um without going into much technical depth sure sure because i think most of the open source projects do have some sort of contribution guidelines right so i think that would be a good first step and i'm assuming you want something more

than what's in the readme there that is linked i was just initially wondering if if a dev is trying to read and trying to contribute maybe having this basic understanding of like okay what's the code exactly doing but that makes sense because it actually takes a lot of time to write the whole documentation so uh yeah maybe just the contribution guidelines would be sufficient i suppose yeah so from a quick scheme of the readme maybe just like uh a statement that you know it's open to contribute contributions from from anybody and like that kind of thing i'm not sure um well the idea is here to like decentralize the work i know uh today

yesterday alita was working on it today also she is contributing but uh we are trying to decentralize the contribution and i think uh this contribution guideline like what if people uh find a issue open issue how they would want to respond to it obviously if they would look into the readme that is already existing will give an idea a brief idea of what this depository all about and it would be just nice to have a small contribution guideline that may not consume a lot of time already wrote that contribution

guideline but i'm still not sure as to what exactly ap bot is doing uh like when does it trigger why does it trigger what's the end goal of the ip board or like what is it currently trying to do right like what is the pipeline of the ipod look like is what i'm trying to get at like okay so right now right now we currently have two bots and that definitely doesn't help with clarity actually i think we have three or four bots technically um i can appreciate there being some value in just like having an outline of what roles the different bots have why do we

have multiple bots instead of and um what is the general high-level process for the bots that's a it's a type of documentation that's a little bit easier to write than like more formal documentation it's more just descriptive high level overview yeah i can that might be a good task for later if we think we're going to get multiple editors not just that maybe all the contributors might might not be available all the time so tomorrow if i leave or a little someone else is leaves or someone just wants to join in yeah the the solution we've had in the past

to that problem is just write a new bot lesbians well we have uh spent a decent amount in the past 18 months on these like you know improving process if we can improve the process by adding some documentation like adding some effort and documentation so we do not have to rewrite the bot again i suppose that would be helpful for example yesterday in the eip editors internship meeting there was this guy who came up with new proposal or new set of codes which was again i believe is a set of improvement in the present eip but i understand that he may not be very clear about how it actually works so i

obviously have pointed him out to alita and shishang but i i suppose that it would be useful yeah if you have anything on that particular script too are matching to the original ip1 um um framework or sorry template and now the another issue is the the board that arita wrote isn't typescript right automatically running on javascript so uh now now another another confusion is should we add should we merge these boards or should we keep the parts upright should we add another flow so this just complicates the task of adding new bots so uh i'm sorry we are losing you shashank

i think we have lost them hello yeah you're back i'm back okay so uh so i was saying yeah so basically uh i and alita agree on the point that there should be a single code base for the board and we shouldn't be having multiple bots because that just increases the complexity of maintaining all those individual bots and like now you have to reach out to the authors of the war to understand like what's going on and it just becomes too complicated so having a single bot in a single code base makes sense instead of having multiple bots maybe i tend to agree with that

i suppose a like um a decent compromise here would be like uh if shashank would like to volunteer or one like work on the documentation part look into the process because i know he is trying to get involved with the eip bot issues more and more so it would be nice to have him look into the process and documentation that they think might be useful to add over there unless uh it is like too big of a task and it is like too much of time consuming well i was actually planning on working on that already so i just wanted to sorry we keep losing you shashank but

it looks like to me that you are already working on the documentation part uh so um maybe we can revisit this particular item in the next meeting and see where we are and what else is required to be added yeah i can see that i will thank you so much for this before we move on to the next item i see a comment uh here which i think we can address it right away about the eipv uh it's not a comment actually micah just shared the link for uh resources we had discussed about the uh placeholder for eipv in the past

meetings and i was supposed to work with third of ox team to get the right access uh luckily i got a response from jimmy today and he did mention that uh he he would like to bring it up with the devops team and it's very much hopeful that this can be moved to the ethereum repository soon so that's an update yeah i'm happy that at least we are moving in the right direction all right um anything more on item number two okay i see a comment here uh

so i will submit the draft for you guys to check and see if there any changes has to be made yeah that would be nice thank you shashank moving on to item number three it's about eips inside it's a monthly report that we share every month uh on what's going on like on the eip editing site i have shared the report for the month of january so far like up till 12th of january we have four new proposals added as draft all these four proposals are of erc categories um there are two proposals which are moved from draft to review and one of those

is already moved to review to last call in total we have three proposals in the last call eip3 448 three six zero seven and eip three six six eight uh the deadline is 24th and 25th january so if anyone has any comment concerns related to these proposals or they want any any further improvement or any suggestions are there please look into the proposal and join the discussion to link at fellowship of ethere magician so your concern should be addressed before they uh finishes their last call deadline and if there are no like major changes we hope to see these proposals getting

into final status very soon other than that there was this one proposal 2098 which was moved to stagnant by the part but the author is very much interested to pursue the proposal i'll suppose it is an informational proposal and uh this is brought back to a review status there is one eip one related change or like we have made this small edit to have this consistent documentation of eips in eip1 so eips are generally called as eips irrespective of their category so we just try to make sure that the eip1 shows the

consistent documentation there are couple of final proposals which had minor edits going on you can check out the entire eip's improvement proposal inside for the month of january to take a look of details of the eips that's about it the next item is eip editors apprenticeship meeting yesterday we had um this meeting and recording is made available uh you can find that recording even from the agenda or also it is available on etm cathode is youtube

it's good to see that more um new people joining in in the last meeting there was someone who was entrusted into erc related editing so we hope that these meetings help newcomers to join uh the community and eventually start contributing in the reviewing process um any anything so far like comment questions nope all right i think the next item is going to be a little interesting uh so last week we had a meeting with uh

william and trichon the lead author of eip721 um that meeting was so if people are interested to learn about the proposal and some use cases the recording is available on ethereum cad headers youtube after the discussion he shared some of the concerns that he initially had when the eip process was evolving and he listed um a list of tasks or maybe concerns that he would like the editors team to look into and if that could be helping in improving the present process i have added the list in the comment section um i don't know if anyone want to pick up anything specific to discuss i mean i was looking into it

some of these things i think are already addressed but yes okay uh the first one is about the mission statement um it seems like the proposal is now stale um and closed okay i see the last comment from micah yeah if you have thoughts on that um i'm reading it right now to remind myself this is a very long time ago i know this is the last minute entry i

should have added this list earlier um we don't have to discuss all of the things today but i just wanted to share the list so whatever we can cover today would be nice to have um regarding mission statements um i'm fine with them as like just indicating you know why why do we do eips um i guess that's fine i mean the my gen i don't i also don't have like a strong desire for them at the same time like it's not the same where i'm like oh yeah we definitely need a mission statement it's critical for our success it's more just if people want a mission

statement sure um like i'm totally fine with the first line read me which just says eips are standards right i think a mission statement is very much closer to the problem statement here like what problem are you actually trying to solve which you think can be a standard and this problem is actually being faced by different applications or the you know clients so but i'm not sure if uh there would be uh like something added to the eip and if that would be maybe some general consensus and changes

to eip template would be required do you have any thoughts on that sorry i got distracted reading this uh thread wouldn't say question again so my understanding is uh this mission statement should be very close to the problem statement and if they are trying to mention that okay this is the generic problem that other projects or dabs may face and this is why it should be considered as a standard then probably it should be added to the eips and if it would be then we might want to update some of the eip uh template maybe something added oh so i don't think he's suggesting we add a mission statement to each eip i think he's saying we add a mission statement

to the eip's repository am i misunderstanding that i think he wants a mission statement for like github.com eips well i think you are right i was wrong yeah it's about to read me that makes sense and that's where i like i'm satisfied with what we have in that opening sentence like i don't feel a need to have more but if third parties are finding that is not explanatory enough then that's also okay like i don't mind expanding on it sounds fair do you have any thoughts or concern on

this math i'm okay with it i don't think it should go on every ep though yeah i totally understand that it was my mistake sorry uh all right then we can probably update him um and if you would like to add something there he can always come back and make up a request all right going on to the next one rewrite readme and index.md with a focus on our audiences of builders and end users so he obviously suggests that he is willing to uh take a lead and creating pr um um we've talked before about how

currently the readme slash eip1 slash template slash eips repository webpage slash ethereum.org all cover the same thing in slightly different ways and with slightly different words and it's confusing and it's not clear who the target audience is for each of them and we've talked about fixing that before and i would still like to fix that general issue and i think this falls into that this is uh i believe more or less the same problem where we have the readme and eip1 and index.html that kind of could just use being rewritten like they've just been mutated

over time over and over and over again and they just ended up in a unhealthy place so i'm i'm not against that one if someone wants to go through it the hard part is finding someone who wants to go through and clean all that up that makes sense and as per the comment it looks like he's already willing to create a pull request for that so i'll communicate that and maybe when he does if there is anything to be improved or changed or if it's just fine it can be merged all right the next one is increase accountability of core eips i mean to me it is a little unclear like how

but i don't know if you guys have any thoughts on it yeah i don't know what that means that's a little weak and same thing in the next one i'm not sure what i mean by the next one yeah the next one i understand is um it's increased interaction rss email list and with with the talk i had a feeling that he is looking into that rss feed to be more active and if possible someone can maintain the list of emails who are looking um for this you know rss feed i don't know how much it is possible in in real life like is it

really feasible to have this kind of list maintained anywhere we already have an rss feed i believe yeah but uh yeah but i think uh i'm not sure i i don't i am not subscribed to that so i'm not sure if it is still going out is it uh i don't know did it break i don't know who maintains it or where it's hosted i just know it existed at some point okay maybe some research work on this direction can be done if you still find value in maintaining their services feeds and emails now that there are so many processors involved and we are trying to provide

information on different channels um but yeah i think if people is people are interested in having feeds we can always invite them to update it if it is not being updated moving on the next one is recommend a specific place for discussion that are off topic of eip depot that's something different so far we have been recommending that this is the right place to discuss everything related to eips i'm not sure what does he mean that's it's very broad

they mean off topic like where do people go to talk about covet or like is there somewhere in between that they're hoping to like what is the specific scoop they're looking for yeah right maybe i can get more clarity from him or i would ask him to maybe join the next meeting or add comments to this agenda and we can bring it up next time as well provide up yeah please go ahead i just agree thank you uh the next one is provide platform for eip discussions at this allow official discussion outside of our platform avoid link rod so i think we have made significant process uh progress in the

past few months on moving the discussion to fellowship of ethereum magician and making that as an official discussion forum so this is i think is actually taken care of okay all right um i think that's all from the list going back to the agenda items uh we have covered almost everything except this last one review action from the previous meetings so i'm quickly looking into it and from the last meetings looks like we have three action items or decisions make peers to call all eips eips in the documentation and not years is for eips

but erc category uh this has already been merged number two was continue discussion to move all discussion to and pre-draft to ethereum magicians yes we are are trying to enforce that moving all of the eips related discussion to link to fellowship of ethereum magician and the third one is merge greg's pr for him to receive notification for eips i suppose that is already done so that's all from the last meeting and the one i already have updated puja will talk to devops and not for an appropriate placeholder we have

shared the information that we received a response and it should be taken care of that's all from the items listed here anyone has to bring up anything well it was a good meeting and we tried to catch up on things that we left last in december and looks like we have some new tasks and activities to involve more i'm really happy with the progress of eip bot that we are doing recently i noticed the tag that i i suppose bot is providing like as soon as a pull request is created it says that it is about status change it is about uh general

updates it looks really nice and yeah i hope to keep improving the process with the help of this meeting so people who are listening to these calls if you have any questions concerns reach us the eip editors the cat herders teams we are available on ech discord on eip editors channel share your concerns with us and we will try to bring it up in the future meetings thank you everyone for joining us today hope to see you all in two weeks on january 26th thank you thank you have a good one everyone

thanks