Automate EIP Number Allocation with Bot and Public Tracking

[poojaranjan]

Currently, EIP number allocation is handled manually by EIP Editors and Associate Editors. The allocation is tracked in a Google Sheet with the following fields:

• Number
• PR URL
• EIP / ERC / RIP
• Assigned by
• Notes (if any)

While this process works, it introduces manual overhead and limited transparency.

Proposal

Introduce a bot-driven EIP number allocation system that:

1. Automatically assigns EIP numbers upon meeting predefined criteria
2. Validates the completeness of the EIP template before allocation
3. Maintains a public, GitHub-based record of allocations for transparency

Suggested Workflow

1. Author submits PR
2. Bot checks:

• Required EIP template fields are complete
• Correct formatting and metadata

3. If valid:

• Bot assigns next available EIP number
• Updates PR title and metadata
• Logs entry in a public registry (list or file in repo)

4. If invalid:

• Bot comments with required fixes

Public Allocation Record (Proposed)

Maintain a file (list) in the repo with:

• Number
• PR URL
• Type (EIP / ERC / RIP)
• Assigned by (bot/editor)
• Notes

Editor Override

• Editors can:
• Override assigned number if needed
• Add reasoning in the “Notes” field
• All overrides should be logged for transparency

This will help us with a streamlined, transparent, and automated EIP number allocation process that improves efficiency while preserving editorial oversight.

[abcoathup]

Looks like I've assigned 484 out of 698 numbers (69%) using the current process.
For EIPs we want numbers assigned quickly so they can be referenced in the ACD process. Currently numbers are assigned within 24 hours on a weekday. Automated can improve this to hours or even minutes.

Validates the completeness of the EIP template before allocation

Currently the criteria used for having a number assigned is a non-trivial spec and mostly compliant with the template.
If the criteria is too high, this will delay time taken for a number to be assigned. e.g. requiring a discussions topic created on Eth Magicians.

Override assigned number if needed

Number overrides should ideally go through a similar bot driven process. Where a editor can request the bot issue a new number for a specific reason (e.g. number sniping).

Number sniping

Number allocation should also disincentivize number sniping. Ideally not require manual intervention by editors.

Number exhaustion

Number allocation should have some limit on how many numbers can be issued in a day/week/month/year to prevent bots from using a large amount of numbers. e.g. an increasing cool down period for numbers overall and per GitHub account.

[jochem-brouwer]

I am fine with automating this but as @abcoathup mentioned by automating this, the process is known and numbers will be sniped. The question is if we care about this at all. An EIP with "nice numbers" is indeed easier to market, but I think in the end a good descriptive name is what matters. Since we are already in the 4-number realm and soon the 5-number realm I'd think that the "nice numbers" count here will decrease. EIP-11111 would be a nice number but what would the catchy name be? "one-one-one-one-one"? "five ones¨?
I think in the end the name is what matters and I think most/all (?) people refer to implemented EIPs and also draft EIPs by their name instead of their number (correct me if I'm wrong). I also think short descriptive names are easier to remember than the numbers.
If the system is clearly gamed or abused by spamming PRs we should obviously intervene (mass open PRs for instance). I think to speed up the process, a quicker automated bot to assign a number would be helpful.

Note that if the new EIP is not merged, the bot can submit a draft number, and only once we merge it this number would be final.
If people abuse the system to get a number on a draft EIP, we can discuss this before merging the EIP and then making clear that the previously assigned number is discarded (and it will not be used by any other proposal) and this EIP would get a new one.

This would mean that as editor we check before we merge a new EIP if the number seems to be assigned in a non-abused way and if it is, we raise this and don't merge it. This removes the editorial part of "assigning a number", it would now change to check the number and if necessary (after raising this point with editors) change it if the system is abused.

My feeling is that the system is much less abused than in the past nowadays. (But obv. if we change the number assignment task/procedure this could raise again).

[abcoathup]

@jochem-brouwer

the bot can submit a draft number, and only once we merge it this number would be final.

We would want this to be the exception rather than the rule, as it is today. To avoid authors having to wait for a finalized number and to reduce the load on editors. An editor can always overrule a number assignment before a PR is merged.

think most/all (?) people refer to implemented EIPs and also draft EIPs by their name instead of their number

ACD(E/C/T) IMHO heavily refer to EIPs by number rather than name, except for headliners.

"nice numbers" count here will decrease

"nice numbers" still appear to be highly valued for marketing EIP/ERCs and what is deemed nice is subjective. I want to avoid the amount of times editors need to get involved in sniping debates (I still have scars).

much less abused than in the past nowadays

As numbers are currently assigned by a manual process (mostly by me) rather than based on the PR number there is less scope for sniping. Once this is automated I suspect we will see a lot more sniping. AI also lowers the bar greatly to create an EIP/ERC.

[jochem-brouwer]

We would want this to be the exception rather than the rule, as it is today. To avoid authors having to wait for a finalized number and to reduce the load on editors. An editor can always overrule a number assignment before a PR is merged.

Right, let me re-phrase, the bot number is considered semi-final unless we determine it is abused/sniped where we override, I think this is what you mean? By this post: #430 (comment) I would assume you would also like the automation? But I might be wrong here.

ACD(E/C/T) IMHO heavily refer to EIPs by number rather than name, except for headliners.

Yes, ok, you are right, although in my perception the EIP number is mentioned for clarity and then by the short title or by the number (usually in the call) but this is my perception. I was wrong on the part that people don´t really refer to it by the number anymore because this is indeed incorrect.

"nice numbers" still appear to be highly valued for marketing EIP/ERCs and what is deemed nice is subjective. I want to avoid the amount of times editors need to get involved in sniping debates (I still have scars).

Yes, thanks a lot for battling these, and let's try to not get you or anymore more (or first) scars.

As numbers are currently assigned by a manual process (mostly by me) rather than based on the PR number there is less scope for sniping. Once this is automated I suspect we will see a lot more sniping. AI also lowers the bar greatly to create an EIP/ERC.

I realized that I might underestimate the "sniping" thing here.

I also realized I don´t really have the right to have any opinion here, as so far I did not assign any number, so I'll leave you to it to improve this process 😄 👍

[abcoathup]

@jochem-brouwer

assume you would also like the automation

Absolutely, I am very keen for the automation. Assigning numbers is an unpaid/unloved task that I am happy to say goodbye to.

I just really care about numbering: to make the EIP process faster/smoother, to refer to them in the my work and to avoid number sniping.

I also realized I don´t really have the right to have any opinion here, as so far I did not assign any number, so I'll leave you to it to improve this process

Your opinion on numbering matters and is valued. You are an editor (which I am not). The reason why you haven't got the opportunity to assign numbers is that I generally get there before any editors. (except last year when I was on a long break).