Splitting Out EIP repo into EIPs & ERCs #61
Comments
|
Goal: Separate notification systems for ERC editors/subscribers and EIP editors/subscribers. |
|
I think there is an option to customize a subscription for GitHub Notification, wondering if this will help following the proposal for issuing ERC numbers via EIP GitHub (Issue). IMO, the upside of this proposal
The only (maybe) downside is, the EIP repo will still have some room for ERCs but that would be limited to the Issue section. It shouldn't be a worry for people who don't want to pay attention to ERCs by opting for custom notifications.
|
|
Adding options suggested for numbering in meeting 30
|
|
@poojaranjan For your suggestion, what would the content of the ERC reservation issue be? Just placeholder text and we immediately close the issue? |
|
The way I look at it is the issue created in EIP GitHub by an ERC author is simply to request an ERC number. As soon as it is approved by the EIP/ERC editor, it can be closed. Rest all process will be the same as EIP, like creating a PR to request review and add finally merge the ERC. All these actions will be performed in the new ERC repository. No PR will ever be requested in the EIP GitHub so technically it will never be merged to the EIP GitHub. There will not be any change in the current process except the placeholder for ERC proposals. The transition will be seamless IMO. |
|
This is a great idea, overall it is kind of a confusing situation to new develoeprs because ERCs are EIPs, as are Core EIPs, etc. And noisy w/ the GitHub notifications. Could we perhaps use a fork of ethereum/EIPs and call it ethereum/ERCs, and periodically sync between them? The same for Core-EIPs, perhaps in the future. This would preserve the numbering and indicate which is the authoritative repo for all EIPs: the ethereum/EIPs. https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/syncing-a-fork In this scenario coordination would still need to be happen so that downstream repos only touch EIPs in their purview, and especially that numbering proceeds w/o collision. |
|
To make this notion a more formal proposal: Goal: Separate notification systems for ERC editors/subscribers and EIP editors/subscribers. Potential Solution: Maintain a top-level GitHub repo for all EIPs, then facilitate the forking of GitHub repositories along "EIP type" so people can watch one repository or the other or both or neither. Details
Potential Advantages: Ability to scale to more developers and more kinds of Ethereum improvement, while maintaining a cohesive process. Every time a community emerges for proposing standards, a new type is added and a fork is created. Potential Problems: Complexity, coordination, some need for central control / intervention. Who would manage the main EIPs repo? (probably the ECHs) |
|
It is unclear to me what the advantage of starting with a fork are vs starting from scratch. The ERCs repository would most likely diverge from the EIPs repository sufficiently to make merging upstream a very manual process. For example, we probably would rewrite EIP-1 and the readme to be ERC focused, and we would probably want to rename the |
|
Ok, this makes sense considering that there will be a new "EIP-1" and the greater wish to fully diverge. Essentially this is a divorce in which assets are divided. This means that there will have to be a new "Purpose and Guidelines" created for the ERCs, not EIP-1 as this must reside only in one place (per the anti-collision mandate). Does it mean that there are Meta ERCs, and the first post-divorce Meta ERC should be the EIP-1 equivalent w/ a new number? |
|
I'm not personally a huge fan of EIP-1 being a meta EIP or ERC. It is such an outlier from EIPs in basically every way, it makes more sense to me to just be an independent file that doesn't have to be integrated into the EIP/ERC process. That being said, if people want there to be meta ERCs and have EIP-1 be that I won't fight too hard on that topic. |
|
Yes ERC editors and stakeholders would need to form a new process for how its proposal pipeline works, how consensus is reached to move to each milestone, etc. This means a new file gets created and EIP-1 really only applies to Core EIPs. |
|
Proposal: Keep one repository. Two separate RSS feeds. |
Perhaps, the ERC process can be added to the README file of the new repository. To me, it seems like the biggest challenge is to create a repo (https://github.com/ethereum/ERCs ) if there is no strong disagreement in creating one? @jpitts could you suggest someone who can help with creating an ERC GitHub and probably grant access to the present EIP editors? |
I am not sure if RSS feed is being followed by a decent number of people. |
|
Is there a motivation listed somewhere how and why the split will be beneficial? |
Good point! I am not sure it is available in form of a document anywhere yet, but ECH will be publishing a blog to create awareness if and when the new process is approved and in action. For now, it is available in part in meeting notes 30, 31, and this issue. |
|
Surely more people can be bothered to subscribe to an RSS feed that to create a GitHub account and read every issue in a repo. Trust me, I've tried. I do not support making a new repo. The threshold for a new repo should be people that write non-ERC EIPs saying they don't want others in their playground. But to reduce noise, I do recommend turning off issues in the EIPs repo and turning on discussions. And listing GitHub Discussions as the official place where EIP discussions should take place. We have a problem. GitHub solved the problem. GitHub are nice people. Let's use their solution. |
|
Thanks @poojaranjan! 30 starts with saying "Pooja introduces the topic, which stems from the decision made in the previous meeting". 29 apparently lists the main problem of EIP editors not being familiar with the content of ERCs and not being capable of conducting their duties of review properly. I really wonder if that just means that more editors (including ERC editors) could be added to the EIP repository and based on proper conduct, "ERC editors" not familiar with Core EIPs will not approve such changes, and EIP editors not familiar with ERCs will not approve those. Wasn't the main argument always that if an editor makes a (honest/malicious) mistake it can always be easily reverted? Second, probably the notion of EIP editors not being capable of reviewing ERCs stems from the core disagreement about the role of an editor. While probably it is not well described in EIP-1, the role was that of a person guiding and enforcing the formatting rules dictated by EIP-1. The role however did not include thorough technical review capability of the content. The Review / Last Call state supposed to accomplish that by inviting interested parties. What made the situation more of a grey area is that most EIP editors also participated in protocol level development (and ACD), hence were capable of providing technical review of Core EIPs -- while doing that technical review however they usually did not disclose whether they are doing a review as an editor or as a technical reviewer, contributing to the confusion. If the role of the editor is purely for guiding through the process and ensuring formatting rules, then both "EIP editors" and "ERC editors" should be capable of reviewing any "EIP/ERC". |
|
It is clear that the number of active editors to review EIPs and ERCs is really low and adding more editors is very much needed. We've published a post inviting participation to become an EIP editor. The challenging part is the interested applicant has to be familiar with the current process and best if he/she has actually participated in the process at some point in time. Hopefully, we get more people to volunteer. As it appears to me, the bigger issue than "not being capable of reviewing ERCs" is actually "not having a bandwidth of reviewing both ERCs & EIPs". As one of the reviewers dropped looking into ERCs, the number of open PRs started to getting higher. In long run, this will make it difficult for other editors to understand which PR needs to be reviewed and most of the ERC PR will be marked stale and eventually closed by the bot in absence of getting attention from editors. The current stats. of eips.ethereum.org suggest 113/141 ERC are in "Draft" status, obviously adding proposals that haven't been merged yet will increase the number. I understand, partially this can be taken care of by using labels but then it was highlighted that EIPs and ERCs are generally catering to different sets of users, so it would make sense to be separated. Those who are interested in getting feeds for EIPs should get EIP GitHub feeds and those who are interested in ERC repo feed can subscribe to ERC GitHub and those looking for both can subscribe to both of them. The main goal of splitting EIP & ERC into different repositories is to simplify things for actively involved people. However, if the proposal of having a separate GitHub is having more downside than the advantage as expected, it is worth reconsidering.
Agreed, EIP-1 may need attention to describe the changes comprehensively. |
|
How does having a separate repository helps in getting more people involved in editing? I know this separation is a recurring topic, but have not seen any convincing answer so far how does it help in getting more editors. As you mention some of the downsides are discussed above and in the notes (numbering conflicts, question of setup, etc.) |
@axic, you're correct, the separation is a recurring topic. I think, one of the driving forces behind this proposal is the Discord conversation and perhaps @lightclient's interest to help with ERC PRs as editor. (Having someone in the picture is better than being blindsided). Once the ERC process is redefined and agreed upon, we can restart looking into more editors. As of now, I don't see separating guarantees more editors' participation.
A possible solution has been identified for numbering conflicts and the process does not invite any major change except the GitHub repositories to request for an ERC number and submit a Pull Request to be merged. As per my understanding, the showstopper here is unawareness of people having the right access to create a repo in Ethereum GitHub. |
For most people, it is far easier to subscribe to a GitHub notification email feed than it is to subscribe to an RSS feed. Also, for EIP editors, we would need an RSS feed that essentially replicates the GitHub notification system, but filters out notifications related to ERCs which would require a non-trivial amount of engineering to get right. |
If one wants to participate in EIP editing/reviewing, you would want to watch/subscribe to the EIPs repository. If you do this today, your inbox is flooded with notifications for both EIPs and ERCs (along with a smattering of others). Inversely, if you want to participate in ERC editing, you get a large volume of notifications you don't care about related to EIPs. By splitting into two repositories, people can receive more targeted notifications specifically related to their area of interest, rather than being spammed by notifications that they have to manually filter (automated filtering of ERC/EIP is possible, but non-trivial). Note: Even if we agree (which not everyone does) that EIP editing should be purely a bureaucratic process that could be fully automated or farmed out to low-skilled laborers, the problem of EIP reviewers is still present. |
|
There are many smart contract developers now who have little interest in the inner workings of the ethereum protocol. I'd love for them to have a place where they can collaboratively work on standards. There are also core developers who are mostly uninterested in the code running atop their clients. I would like for them to be able to monitor and review the latest proposed core changes without being inundated with ERCs. There seem to be a few options:
I prefer to transition to a spec-driven development process (similar to eth2), but I don't think we're ready for that yet as that would require us use the yellow paper as the canonical spec. My second preference is to split ERCs out into their own repository. I am having a little bit of cold feet on this now, because if we do move to a spec-driven dev process we'll no longer need the EIPs repository as a whole anyways. So it would've been better to just leave the ERCs where they are. |
|
Nice to see this come to fruition! |
|
I think ERCs doesn’t need to go to final stage in order to be implemented and used. I'm a fan of separating ERCs from EIPs repo and I would love to see it happen. Adding tags on ERCs would help sort them out and categorise so dApp devs can use them. I think ERCs are more of suggestions how dApps can be build, improving the logic of smart contracts in general. On behalf of Ethereum Magicians I would like to propose @wschwab as ERC editor who can help out separate ERCs and tag them with relevant category for example "wallets ", "token", "metadata"... I do think William should not do this work alone and have someone else help him out at least sorting and categorising ERCs would be helpful. |
|
@lightclient could you elaborate on what you mean by "specs-driven development", and how this is not spec-driven right now? Is it that there is a complete cohesive specification of the entire system maintained in one place? I can see your argument that the Specs repos could be generated from a single EIPs/ERCs corpus. We can look at the EIPs as components, and organize herding work around types of systems. Rather than splitting the EIPs repos by type, perhaps we should leave the EIPs in one repo and encourage specification-driven repos to emerge, e.g. Ethereum-Wallet-Specs. All component EIPs of all types go into one pool w/ general "Editors" maintaining the submission, and status change process, and specialized "Herders" working on each specs repo. This seems to be already happening w/ Eth1 and Eth2 core devs who draw from a common pool of EIPs, we can make this a model for all kinds of efforts in the community. And a question for ECH / @poojaranjan / @timbeiko: the Eth1.0-Specs repo is used by the Ethereum Cat Herders to organize the process of producing working code and network deployments from specifications as part of a feedback loop w/ Core Devs, client teams, and others. Is the intention to move the Yellow Paper or some kind of cohesive system spec into this repo? |
|
@jpitts by "spec-driven" I mean via diffs against a canonical spec, the way the eth2 consensus changes are written. |
|
Ok, thanks for the clarification. We do need to address the noise issue. Again I go back to using git and GitHub. Why not use GitHub forks of the main EIPs repo for each Specs team? There would be specialized Editors and Herders for each type of system (Eth1, Eth2, Wallet, NFT, FungibleToken, etc). Probably the latter three would start w/ an ERCs fork. Comments and changes to a PR happen on the appropriate fork of EIPs, and this git repo is periodically sync'd back to the main EIPs repo. This way the EIPs stay in a pool of available standards. |
|
How about something like DOIs, where registration agencies assign their own identifiers so that a resource is specified by the RA and the identifier? The original EIP repo could be one of the "RA"s, a separate ERC-only repo could be a second, and a new EIP-only repo could be a third. (Self-promo time) https://eips.ethereum.org/EIPS/eip-4834 would be a good system for this if one were to want this on-chain :) |
|
I fully support the discussion of whether or not to split ERC vs other EIPs. (I've not lean towards any side but think it's valuable to discuss). To put into context, if the goal is to reduce notification burden, it came to my attention that octobox.io can support this query to filter ERC or filter out ERC (seems buggy) https://octobox.io/?q=inbox%3Atrue+repo%3Aethereum%2FEIPs+-label%3A%22type%3A+ERC%22 While this feature is not natively supported by Github notification system yet, but I figure if a tool supports it, it might be supportable by future Github notification or other tools. |
|
lol forgot about this one |
|
Closing in light of EIP-7329: ERC/EIP Repository split |
At EIPIP Meeting 29 we discussed splitting the EIPs repo into 2 repos with different editors at each: 1 for EIPs and 1 for ERCs. Here is what we have agreed upon so far. We have agreed we want to have EIP editors that are separate from ERC editors. We are still looking into how best to separate the repos, especially when it comes to how to number EIPs and ERCs going forward once they are separated.
The text was updated successfully, but these errors were encountered: