EIPIP Meeting 46

Transcript

all right welcome to eipip meeting 46. so the first item listed here is discus a standard for documenting standard track eips especially erc so um this particular item i have added um from the discussion in the last eip apprentice meeting it's my observation that the general practice to document standard track eip of erc category is erc um dash 123 or whatever it is but this is not the case with any other standard track eips not even with the core eip like we don't say that in core one five five nine but we do say erc 20

so i kind of looked into the eip one and the present eip1 suggests that there are only two mentions where erc category eips have been mentioned as erc but when we look into those erc at eips.etm.org those are listed as eip and i'm giving an example here when we look into erc20 it's not erc20 it's written as eip20 and then uh it is listed at the same way as any other standard tracker eip so um my proposal here was to treat all standard track eips equally and also standardize the documentation of vip

like we should have it like in the synchronous way in eip1 and everywhere else so curious to know what are the thoughts here i'm generally in favor of consistently using the terminology eip throughout the repository documentation etc we should be aware though that it would take a herculean effort to convince people to stop using the erc terminology colloquially and so as long as we're okay with knowing that people are going to continue calling their things erc blah blah instead of vip blah blah i think it's fine to just have the documentation at least be consistent with eip as a terminology right any other thought

i was just wondering if the eip authors already know the difference between an erc and uh uh much more higher abstraction eip so isn't that sufficient for at least from the er eip author's point of view yeah actually uh i think uh there is a general understanding of what erc's are they are basically a part of a standard track eip it's just that for convenience purpose they i think for convenience purpose it is easier to refer it as erc so we also specify the category of it but making that as a standard in my opinion would not be a good idea so having a consistent name as eip it

might take some time like educating people that you should not call it as erc20 call it eip20 but it's a task difficult but can be achieved um the thing is uh if i look at it from an outsider's perspective let's say i'm not an ethereum character or person not in the pm group i am just looking from a web 3 user perspective so it's erc20 is more like a marketing term for me so it makes me it makes easier for the contract developers and every developers and users to uh kind of uh understand it rather quickly like erc 721 erc20 because it's anyway focus more on the uh user and end of the spectrum right most of the core and networking eips are not directly being

used by uh the user user is majority of the times not directly when interacting he's interacting with the wallets and the contracts that are deployed so i think trying to move trying to make erc uh into an eip and from that perspective might might be again i think micah mentioned earlier it would be a herculean effect uh effort but i think uh at least from author's point of view if let's say if an author is coming and writing an eip that turns out to be that goes into the erc category i think that that should be good enough for us right because is the bottle like that uh that we are we as the maintainers having trouble figuring out what an eip erc is or conveying it to the author whether whether you're writing an eip or

an erc or a subcategory of drc is that the bottleneck what what exact problem i think it's just uh we're inconsistent right now like some places we refer to them as eips some places refer to them as the rcs again our documentation okay yeah right so basically erc's our eips it's just that people like to call them yeah please go ahead mike uh do we still plan on splitting the ercs out and just have a repository anyone know we had a chat yesterday um on the penny recording with the light client on this topic and uh the impression that i get is like

we are still in wait and watch see maybe after some time when then after the moon we get some clarity should we separate it or just take out the eaps itself and let the erc stay there anything to add matt here no i kind of feel like wow i kind of feel like we're waiting a little bit too for the execution spec um i think the depending on how people want to use the execute execution spec is going to dictate a bit whether or not we move the erc to their own repository they stay in each repository and each process moves to a different repository et cetera

what seems to happen is that ercs are eips through the whole proposal stage because they are proposals once they get through the last call and their final they at that point they are an erc they're a standard yeah and people don't refer to them consistently i don't know if we want to start labeling them erc's once they have gotten through to final that would be a consistent way for us to use the terminology i think if we if we think that we're going to likely

eventually split out ercs into a repository um i think there's probably value in just calling the rcs and just start start now this is contrary to my argument earlier so i'm arguing both sides of the fence here um just because it's gonna if we try to change everything to eip and then make it consistent throughout the repository and then you know later we pull out sorry later we pull out erc's into a separate repository and then we have to rename everything that can lead to even more confusion on the flip side if this is just for documentation i think that it probably doesn't matter much and we can just call them eips and the docs and let users call them whatever they want

yeah because i think at least we can make it like an one so in eip1 there are two mention as i mentioned it earlier we said erc20 but when we click the link it says eap 20 token standard it doesn't say erc20 so we are actually following uh eip nomenclature there and as per my understanding as it was explained by lightline the other day this eip thing is generated process generated it is not something that we are adding to it because of the template and all it is getting so people know they are eap 20.

so what we can do i mean i'm getting a general impression that what we can do is like we can update the eip one for now like just call them aip20 and educating community about that we should start calling it as eip and erc is something that we can take it on the later stage does anyone disagree on like we should not make the eip1 consistent i'm finally making erp one consistent i would recommend against encouraging users to change the way they call them i think that's going to be a huge headache and like i said if we end up splitting out

the rc repo we always have to tell them to change their naming back again um for eip1 though i'm totally fine with just consistently using the eip naming nomenclature especially like you said since once you click the link it takes you to a page that says eip not erc and so the easiest fix is to just in a few places where we call it ea erc we just rename it to eip and let users call them whatever they want right okay um um what i can do right now is i i think i can create a full request to make these specific changes in eip1 and let's see if any other editor has any other comment on that or

if people our community comes back with any strong reaction to that then we might want to pull it back otherwise let's give it a try if if anyone has any different opinion here please feel free to share okay let's keep it that way moving on to the uh next item uh it's general consensus to discourage using the issues for discussion two or the eip number so we have discussed it in the last meeting and a few meetings earlier and as an action item i was supposed to

like create a full request to change the uh change the recommendation to make sure that we are recommending people to open the discussion to thread at the fellowship of ethereum magician and not to the issues section i think we have made some prior effort to change the wording and it looks like there is no particular section where we can define the usage of data issues and people are already getting a sense of uh that we should be using fem but there was just one section where it is mentioned that eip number which is allocated to a proposal can be the issue number so what i have done is like i made a pull request and the number is four five

six four to update that section in the eib1 so we can make sure that people should not go ahead with the issues to open a discussion to link that can eventually be considered as the eip number does this seem reasonable here is just to get continue to reinforce what we've already been doing or take it a step further we are we are doing that but the only place where there was a little bit of confusion they can still use the

discussion tooling in issue was the eip number section where it is like eip editor can allocate eip number based on the pull request number or the issue number so my my thought process was it will remove that we can use the issue section for creating eip number probably no one will go and start the discussion to a link over there because there is no other recommendation or suggestion there oh i see um so you're saying just remove the texts and yes that talks about where the eip number comes from yeah that's fine that's me yeah that's a very small uh one line change that is added to eap when the pull request adjuster

greg lightland do you have any thoughts on that is that generally seems okay to um kind of strongly recommended go to fem do not use issues for any pull request purpose sorry the eip name number purpose or the discussion to purpose okay we've been using issues as a way to begin the discussion on an eip and get a number for it which is in the same series as the prs early on we've been doing it that way for years

now ever since i started and even before that i don't see any need to change it's not like we're going to run out of numbers we wanted to the the goal with moving people to ethereum magicians was to consolidate discussions on this consolidated discussions on the magicians platform because they previously were spread out between magicians and eighth research and the issues in github and secondarily to make it so we can actually use the issues section for discussing issues with the iep's repository in the process and stuff like that and so right right now we can't really

use the issues section for actual issues relating to the ip process because it's just chock full of people discussing their eips and proposing ideas for eips so the idea was just get all of that over to three magicians which is generally a better form for it anyways it has like the the tooling i feel is slightly better um for just open-ended discussion the issue should have a link over to the magicians right away yeah there'll be a little discussion on the issue especially if that discussion causes the uh causes eip to to die an early death other discussions happened on what used to be a skype channel that was a discord channel

but it's just the way it's worked for years and trying to change the way something works after years is i just don't think it's worth to bother and it was very nice that you could start an issue and not have to wait for an editor to assign a number it it had a number immediately you could start to refer to it by number um instead of that issue that we've been discussing which someday we'll have a number i just don't see the point of changing the practice that works just because it causes a little inconvenience for the others so do you feel um do you feel that

there is if i understand correctly you're saying that there's value in getting a number before you are ready to submit an actual draft is that accurate yes exactly i'd rather clutter up the issues with things that don't become drafts in the end then clutter up the repository with drafts that die well i don't think that it's a good practice to call a proposal which is not even merged in the eip's ref repository as an eip we

should actually refer them as full request and the whole idea here is like to organize the eip standardization process and ask the user to follow the recommendation of eip1 and as per eip1 an author is not isn't supposed to pick up an uh eip number it should be on the eip editors to allocate them because we have seen in the past they were squatting issues because we allow i mean like we didn't allow it it just that they thought that it is allowed and they started picking up the numbers of their choice so i think it it makes sense that the responsibility should be on the editors to provide the number and not on the authors on the second thought about the issues

to be the first discussion to link if we keep that the process continued we were having a ton of open issues because we don't know when to close that discussion and actually the discussion shouldn't be closed if that is related to any proposal so to make better use of the issues section we like in the previous meeting we thought that let's move all the proposal related discussion to the magician fam uh forum so we can better utilize this issue section moreover uh we haven't seen in practice that a user who wants to discuss about a proposal will go back five to six pages down in the github to pull out that issue section and start discussing it is

way more convenient on fpm um the magician's discussion has to point to something if you make it point to a draft then you start cluttering up the repo with drafts that are going to die when the discussion says no this is a bad idea if you start the discussion on the issue yeah you just put the draft in as as the first comment on the issue it's editable so you've got a history there um it works it's it's been working for years it's difficult to change the practice not everyone does it that way it's not a requirement

um it's just a common way of doing things but the only hassle has been people who decide to keep clicking the number until they get a number they like that's that's a bad thing to do when people do that you scold them um but at least you know let people do it people are going to do it then it's not worth scolding them about it or telling them not to it works and trying to use issues to keep track of what's happening in the repo it doesn't work very well anyway yeah just discussing them on the channel works much better um why do you why do you think there needs to be

something to link back to why can't someone just create an ethereum magician's discussion link that talks about their idea and their proposal and just has the whole thing happen there like why do we need an issue at all for that where does where is the initial draft to discuss go you want to write up something you want to write up something initially that's substantial enough to have a discussion people vary i like to write up something fairly close to an actual spec so that so that there's something to discuss rather than just a vague idea um

and i don't want to have to make a draft in the repo for that purpose because when the discussion is done the upshot of the discussion may be no this is a bad idea so why clutter up the repo with that better than just cluttering an issue i think one of the issues of having two places for eaps is that sometimes you it's not easy to find an eip number someone refers to some of these old eeps that never made it into the repository you try and search on eepson ethereum.org and it's not there and you don't think it's an e and you look in the github it's not an eep but it's hidden somewhere in the issues and there's no good way of navigating to

that if it's if it's in an issue it's it's just a discussion it's there's nothing really to navigate well but he has an eip number and people referring to it as an eip oh i see i see your issue um if it never gets into the repo it's not quite real um and yeah i agree with that i see your point i see your point but it just doesn't bother me as much as it bothers you as i keep saying people have been doing this for i don't know five or six years now so it's just it's swimming upstream to try and change it it you can change the advice in eip1

so that people start doing it in a different way the problem remains where to put the initial the initial big piece of text that you want to discuss i i prefer that that be something close to a specification rather than just i have a vague idea i'd like to discuss that might become an eip go take that somewhere else if if you just want to discuss vague ideas um so so why why can't you just put that in the ethereum magician's forum so let's say you write something it's not quite quite a draft but it's close to a spec like you described just creating a conditional thread that just has that as the body yeah the hassle is

the hassle is you wind up with a discussion thread there that's difficult to link to but and you have no history if you start editing things there but the alternative has been to is to get things started in your own repo but not everybody manages their own their own get repo yeah that's that's a difficult thing to do actually um yeah i think your point that uh you don't have an eip to link to i think is actually kind of like matt said a minute ago that's to me a selling point like we don't want people linking to

this as an eip we want to be very clear this is not an eip it is not until it makes it as a pull request that is accepted as a draft it's not an eip it doesn't have a number and so it is just an idea and it can be a you know well specified idea but it it is just an idea and by having it not in the eip's repo until it's an eip helps kind of make it more clear that there's not actually an ap because we run into a lot of problems with people you know calling things vips and advertising them on twitter and whatnot and then you know it doesn't even make it to draft and then people come by later and like hey what happened to that eip and i have to tell them it died that was never an eip yeah it died

if you get to draft and if it dies it's it's still just a dead number um as i said we can change the advice of how we want people to do it in eip1 but trying to enforce it is just not worth to bother well i think the process of a standardization means like whatever we are recommending uh we that should be for like everyone to follow and then only we can make it as standard and when we are talking about eip uh because that is something from coming from ethereum repository we would like to make sure that the

standard that we are providing is actually a standard it's not just a suggestion that people start using and start calling them to be a part of ethereum i'm very disinclined to change the way that i do things i'll tell you that because it works very well for me but i don't get things started on the issues until i'm almost certain i'm going to write a draft so but then what about the new eip authors that might come in the future because if they're coming they they need to have minimal friction in order for them to author an eip post a discussion and get a consensus around that uh if there is no standard process then

the friction kind of increases in that span does that make sense but the advantage of of the issues um is that github maintains a history now so it provides a place to to edit during discussions and maintain a history of what you're doing without involving the eip editors until it's more substantial and you're willing to submit yourself to that process as the process slows things down a lot once once every edit has to go through an editor yeah but

you can also see the addition i see i really do see the arguments on both sides i just um it's my old psychologist coming out here saying that when you've got a social practice that's been established for years uh whatever the arguments are it's still hard to change the practice the thing is less than 10 of people create issues as their discussion threads anymore so it's not like this is affecting a huge number of people yeah okay andre what if ever i write another vip i'm still inclined to do it that way because it

works very well for me all right uh let's try uh let's let's uh try from our end to uh propose this to the community and maybe we can see the response how it works because every time when someone new wants to document a proposal the first recommendation is to follow eip1 so at this point i can just assume that whatever is there in the eip1 is a standard that we are providing to the community to follow along and if there are other issues that comes on the way we can probably address in

one of the future meetings uh just a quick question um if you do drop the first you know pre-draft as it were into the start of a discussion thread on magicians does it let let you keep editing it indefinitely or does it stick some arbitrary time limit and then not let you touch it anymore my understanding is there is a time limit but we are trying to uh assess like cad headers are working with fem people and trying to assist the author in case there are an issue in

editing that particular proposal after a certain period of time so that is at this point i think it's referring to the ethereum magicians forum itself is their uh edit timer on it some forums have like uh you can only edit within the first 30 minutes and then you can't edit anymore i don't know the answer to that so that's the problem it's where to put the text that might become a draft but it might not you're having this discussion and the discussion might end up being no this is actually not a good eip so don't you know there's the problem of cluttering the

issues but cluttering up the drafts is a worse problem yeah i really don't want people submitting things as drafts just so they have a place to discuss them in a number to discuss them by yeah so i actually i find that a complaining argument if ethereum magicians does in fact have a edit timer then that is a compelling argument that this is not a viable solution to the problem that's been described um i don't know if it has a timer or not and the page isn't loading for me for some reason right now maybe my vpn or something so you can edit old posts on femme i don't know if that's because i'm a moderator um

are you a moderator i'm a moderate moderator but yeah i think i'm not but i can't load it for reasons that are um looking for me i mean not the editing part but the fellowship of the imagination page is definitely loading and if i understand correct yes there is a timer after which a post is not editable and in the past we have came across certain cases where an author wants to make some change on the initial draft but there was something that because of time period it wasn't allowed but we got that result very fast like one example is eip3675 the merging ip mikhail had this issue and we were with the team and it got solved so we are

trying to do our best in in terms of communicating with eip authors and make sure the uh the discussion to forum should be better utilized and authors should not face any challenges over there i'm sorry shashank was there a question uh i i thought i saw you on youtube yes so i was wondering if it would be useful to create a different repo under the ethereum um under the ethereum project specifically for discussing uh ideas and maybe discussions and stuff like that because then there is mostly no worries about allocating issue numbers and pr requests and stuff like that well fem was brought into place for this

particular purpose only fem is to bring all sort of discussion related to ethereum it need not be specific to any eip or any proposal but it can be related to anything that you want to talk about an ethereum ecosystem so my understanding is if you want to create a thread you you do not need to have a draft proposal submitted in the first place you can just come and open a thread and start discussing on any topic it can be an idea for a proposal as well can so it does appear that there is a edit timer on ethereum magician can we remove that is that something that's configurable that we can just get rid of i'm not sure this is an open source piece of software we could make a pr if it's not configurable

what software is being used here this is this course this course has like a billion settings i'm guessing you can adjust this um so yes i i do i kind of agree with greg that if if we cannot uh if there's an edit timer on fem then it does not make for a good place to have this idea phase eip like the pre-eip discussion because there is value and as as greg described having a place where you can type up your specification before you're ready you know you're not confident enough it's going to be an eip you don't really want to clog up the eips process you don't want to go through like the actual process of drafting a formal eip but you want to

get feedback and you want to you know iterate on it and having a place to do that is very valuable i do agree pretty strongly with them and right now if we can't if there's an edit timer on fem that makes that a non-viable option and so uh if we can't if we can remove that then i'm back in the camp of we should be having those discussions and uh on fem if we can't remember that for some reason then i tend to agree with greg that femme is not the right place very remember these these discussions go on for years i i have i have vips and variations on eips that have been on the table for five years now um so

edit timers are really a hassle all right uh so if we can attribute it into two two pieces like one issues to be considered for eip number that's number one and number two issues to be considered as discussion tooling so i'd be curious to know thoughts for like fourth section is there any general agreement that only the pull request number and that to buy the editor should be allocated as eip number no that's that the whole advantage of issues is

that the numbers come from the same sequence as the prs so so as soon as you open an issue on it you have a number to refer to it by and the advantage is that everything is in that repo everything's there um it you should move the discussion to fam pretty quickly um not very much should happen in the initial issue once it's at all solid move it over to fam and simply have the discussions too link to the issue until you're ready to make a draft of it but if people don't have a number to refer to

it it's just difficult to get it out into the community for discussion they people need a number and once they have a number then they know oh the first place to look is in the issues and they'll probably find it under that number it works i hate to the only way it's broken is that we get a whole bunch of issues that we can't we can't use issues the way they're usually used in a repo but we've never used them that way they don't even work that well in other repos so we have these discussions on our

you know on our discord trends and that's been working for a long time so i just we're trying to solve a problem that just isn't a big enough problem well i think in the past we have uh we have uh made some effort to uh move the discussion link to what's the fcm and i don't know i haven't heard any any like strong

resistance so far but i am completely open to the like reconsideration of making use of issue though i see there are more downsides of using issues as discussion to link than the advantage that it provides and talking about the serial number once the pull request is there it is from the same sequence of the issue so i don't see there is much of a difference of making pull request number as an issue number but i strongly recommend that this is something that needs to be provided by eip editor that's number one and number two we shouldn't call a proposal as an eip unless it is merged in the eips.etm.org

in the form of draft at least because in the past we have seen a lot of proposals which are implemented in projects they call that they have implemented an ethereum proposal but that ethereum proposal does not exist in ethereum repository maybe this is some something uh like might require a longer discussion or maybe a bigger forum discussion and we have like 15 minutes just left so if anyone has any final comment thoughts to share and then we can move on with the next rest of the topics um puja if i understand correctly you're saying that

an eip author is trying to submit a pre-draft not even dropped it's a predator right uh but the number should be only allotted after when because i'm unable to kind of grasp that point when should the number be rotted yeah the number should be allotted only if the proposal is ready to be submitted as draft because number comes as the second stage there there should be a draft that needs to be submitted at ethereum github repository as a form of pull request before any number can be allocated to that proposal so then um so for easy identification what would be uh what would be a prefix or a suffix that

we can give to that pre-draft so i should not give anything for pre-drafts you really should not be like you should be soliciting people for uh feedback on your ideas and your thoughts but you should not be telling people hey i have a thing that is a standard you do not have a standard until you have a final eip and so the thing we're trying to discourage is this this pattern that people have gotten into where they uh create an issue or create a pr that never gets merged and then they go out and they tell everybody hey i created an eip everybody should go implement this standard and it is not a standard it is just an idea and it might be a good idea and it might be an idea that eventually becomes a standard um

but it's not something that we want to incentivize and encourage and you know facilitate people you know sharing around like if you're ready to get you know broader feedback then you should create a draft and get it into the efp process like get it start in the process so you get a number you can start sharing your ideas people and you know spamming it to a broader audience if you just want to like get like a small pool of people to just look at your thing then you know if you're a magician's threat or whatever that just has your idea is a greater place to link to um i was asking actually in the perspective of let's say if elita was editor is trying to build a bot on top of a pre-draft so is there a category that these pre-drafts can go into so some kind of automation could be done

later on or easy for uh identifying within the project management community uh from that perspective i understand your point mike i'm just trying to figure out if there is a category that you can give it to so that you can simply identify using a prefix or something like that i don't i don't think so because draft is that thing like draft is the first step like the very first step in creating ap is create a draft the requirements are pretty slim you just basically need to make sure it's formatted right so make sure the front matters there make sure you have the right sections um you know make sure you follow the rules um but that's it like you don't like i've had people submit uh eaps as drafts where the body is almost entirely like tbd like just it's kind of stubbed out they have like a couple of vague ideas in

there um and i've let them through and because like i said that's the first step as soon as you're ready to create an eip just go create a draft um again if if you like greg and you want to discuss it beforehand um that's fine as well and i'm totally okay with that but if you're looking to get like in started on the process itself the first step is to create a draft does have this sort of draft pr idea which is sort of a pre-draft you can put it up there and it may never be merged it can't be merged um that sort of helps i i actually don't want to see these totally empty drafts go in if that really does clutter things up i just don't mind the clutter and issues

i don't care if there's a million issues that never get closed it's i just don't care we're not going to run out of numbers i think i can be convinced to set the bar slightly higher for a draft than what i have right now i'm not super passionate about having the bar be very low i just i don't want the drafts cluttered up that's a repo and if you get a lot of drafts in there that are just dead yeah well with the help of this eip but we may not be having a lot of draft debt it would be moved to stagnant if the author is not around to either champion

or push the proposal so if someone just showed up to submit the first draft and is gone mia the bot is helping us a lot making some noise after six months so you want to continue the proposal come back give feedback or push the proposal if you don't want it will be moved to stagnant so that way we may not be having ton of open pull requests in the repository which will keep it cleaner and the request that we can see will be new and would be like something that can be used people can give their comment to but if we keep on uh like having issues open issues hundreds and thousands of it i'm not sure what advantage do we get with that keeping it on because it would never let us you make use of the appropriate issues we want to actually

address to an issue which was created by one of the user facing some challenges will be buried inside and we may never be able to go to there whatever the github feature of draft prs um they call them just to make it confusing yeah that works pretty well you put it up you mark it draft it can't even be merged you know the bot doesn't care about it the editors don't have to look at it yeah so that gives you a way to put something up get up get a stable number for it um

have a place to point to for discussions and it's it's less clutter if they never if they never make it past draft stage stagnant crafts are actual drafts that just aren't being worked on but they haven't been withdrawn i've i have a five-year-old draft for stemdi that i hope to eventually propose but other stuff has to be done first so it's it's sitting stagnant for the time being but not withdrawn so i'm fine with people creating draft pr's but i'm hesitant to give them a number for the exact reason we mentioned before which is that as soon as people

get that number they just start spamming it around and people start referring to it starting linkedin articles like it gets referred to by people in chats and it gets linked to by other eips and then that if that draft vr never makes it through then that's just like a dead permanently dead link all over the internet and we see this often like this is not like uh oh this may be happens this happens very frequently which is why i really want people to if you get a number it should be like your eip should be in like it should be on esp's repository like in in master on the efp site so people can link to it and actually see it otherwise you'll find in the ieee process you'll find in the ansi process

that anybody can write up a draft and it'll be assigned a number um and there's a large number of documents with numbers that are pretty much dead but beginner numbers so i'm totally fine with that it's just to get a number i want like it should actually be in the eps repo so submit any ip get it reviewed by an editor again all you have to do is make sure the front matter is right that you have the right sections and you know you don't have anything that's not allowed in there the rules are pretty simple for getting through a draft right i just don't and you have nothing but i don't want that repo cluttered with ideas that are that are not going to go very far um

plus it's a hassle to go through an editor for this for this very first stage but it just puts more work on the editors but yeah right yeah right we are trying to get more editors on board and the apprenticeship program is helping us a lot like getting more community participation in reviewing the proposal so we hope to get this process a little bit uh speed up and maybe an author may not have to wait for years to get the proposal reviewed and we should be fast tracking every proposal at least the proposals which actually make sense and have chances to be a standard at one point of time rfc has two categories draft and internet standard

that's it lots of things stay draft forever nobody cares about them yeah but you can't just get a number whenever you want to get a number you have to go through the draft process you have to get reviewed by the rfc editor that's not you can't just go to a url and get the number yeah there's kind of a pre-process of viewing the draft what can i say that rfc members tend to be much more professional than we are well we have just like eight minutes left for this meeting uh so if need be we can bring this agenda item back into the next meeting but let's

quickly move over to cover the rest of the items and i wanted to bring attention towards the spam issues those are being created in the issue section as well i have listed in the number here four five five six four five five four maybe uh editors who have uh like closing the uh authorities may look into those issues and close it and it would be interesting to learn about how we can stop these kind of spam issues yeah please go ahead so please anytime you see these click little dot dot dot click report content um and then if you sorry i'm loading it right now so i can remember what the section you want to choose is uh click the dot dot hit report content i want to report abusive content or behavior

i want to report spam a user that is disrupting my or my me or my organization's experience on github or user who's using my personal information without my permission and then user disrupting me or my organization experience by posting spam and then just give like they have like a three word description that says spam issue creation we get a lot of these like i report five or six a day and github does actually ban these people and so there is value in clicking that report and if they get reported the their account gets deleted and the issues they created eventually go away um so yes this is a real problem um just if you see them please reports to github that's really all we can do and then close it

well that's very good suggestion because uh um when i looked into that it looked like someone is just trying to make an impression that they are contributing to ethereum github repository and what they are doing is just spamming so it's good that we should be reporting yeah these are yeah these are these are yeah these are these are scammers and they basically create a github account and then they put it on a website and it makes it look like to the naive user it makes it look like oh this is a legit developer want to leave they're just a scammer trying to steal someone's money so yes please report them as soon as you can it not only helps us keep the repo clean it also caught make costs of them you know more time and effort to have to keep recreating these accounts and it helps protect users from scams

we'll do that thank you the next item listed here is update eip bar to add greg colvin as reviewer to notify his availability from the discussion on the discord chat it appears that craig is very much interested into reviewing the proposal though he was not getting a notification however getting notification can also be done by just subscribing to github but if this is something that that can be done with the help of what i'm just uh yeah yeah we don't need i don't need updates but i just need to get a pr to um there's a file if someone remembers offhand please interrupt me but i'm playing it up right now in the eip's repo there's just a file that you need to

edit that has a list of who gets notified for which issue types right i i think shashank you are working on the eip bot stuff with alita do you think it is something that you can take care of yeah yes it is yeah so actually so i'd recommend actually greg take care of it so you can pick which ones he wants to do so greg if you just go to that link i just pasted um just add your name your github handle to the uh whichever ones you want to be notified for so like for example i'm only notified on core networking eips whereas matt and alex are notified for all eip types okay easy enough this is this whole thing has been very

frustrating to me for years i've just been an editor and then all of a sudden i by some automatic process i wasn't an editor and then it's been weeks of argument and discussion about how to become an editor again um it's sort of like i got automatically fired from the job for no particular reason and had to argue so it's been unpleasant well i'm deeply regretting the inconvenience that you may have because of the changes that that were brought in with the bot and the process but uh but we are trying to make everything go smoother and that's why we organize this eap ap meeting bi-weekly and i hope

to see you in upcoming meetings so we can have your input regularly not only on the proposal and eap editing side but also the issues and challenges which are being faced by community in terms of submitting the proposal or any other process around the ethereum ecosystem thank you for that um i think that is there on the eip uh inside i'm just gonna quickly go over there because we have just three minutes left so i have shared the link to the december uh eapn site up till 15th of december so far we have new proposals four new proposals a few proposals are pulled back from stagnant to draft um there is no proposal in the last call

there is just one eip that i especially wanted to make a mention after the arrow glacier proposal that went into i don't see that moving into final statuses it's something that we should do it real quick i don't the author just needs to submit and appear so tim probably yeah i'll thank him about that because i i don't find that proposal in my list so i was wondering why is it not done yet all right uh so that's about uh eip inside the details of the eip number and like what changes have been done in the past 14 days in the month of december is already documented and you can find the link in the agenda

for this meeting today the next item is eip editor apprenticeship meeting we had organized this meeting last december and i have added the link to the recording it was again a great session by uh that we try to answer it's great that uh new people who are trying to contribute as an editor are like obviously um reviewer is very helpful like we have seen quite a few engagement and yes if for editors if you have a special specific thought about how to mature them to be an editor right from the apprentice we would highly encourage those ideas do let us know

but the bot doesn't like it but the detail seems to say that one of you people just fixes it i don't know but i just stuck my name in and tried to make a pr oh yeah about uh the pr is there to fix it yeah i'll get that approved no um on the note that puja mentioned uh i recently moved houses and so i'm way behind on my emails and one of the things that got dropped of all the things that i do uh is eap stuff so if anyone wants to go through core eips now is a great time to do so because i haven't for like a week

thanks for the heads up micah um i know uh like exec and matt are already doing i have received a couple of more interest from uh some developers of the ethereum community they would be probably joining from january but i will like inform that if they can start contributing from now and but we hope to have you back very soon i don't think that you're gonna make your escape from here all right uh let's move on the last item is review action items from the um previous meeting one of the most important the discussion from the last meeting was the placeholder for eipv uh i didn't

check with the jamie so far but i'm wondering if matt may have the uh you know permissions to update that i would need someone to make me um whatever role i can create repos in the ethereum organization for a brief moment while i transfer the ownership otherwise i don't think that we'll be able to do that okay if you can just think me about that i would be like taking it with the devops team and trying to get it resolved sorry for the delay thanks all right that makes sense and that also concludes our meeting today aman um anyone has any funny comment question thought that they would like to bring up

okay i have one last question for the group uh the next meeting is uh falling on december 29 do we want to keep that meeting or do we want to reconnect in the january like the 12th of january i don't have a social life so i don't care january all right um like i'm assuming like 29th is like very close to the year end and most of the people will be on vacation so unless we have anything uh urgent to be discussed uh let's keep it tentatively on january 12th but if something comes up that needs uh immediate attention then we will have the meeting on 29th december

yeah by vacation means those who are working for an organization yeah let's see uh let's keep it open uh if we come across any issue that we want to address immediately we'll have the meeting on 29th well that's all for the meeting today thank you everyone for showing up and i'm happy to see the number of participation today and i hope that this continues in the next year as well have a good one everyone