SNIP numbering policy and draft SNIPs

📜 Development Proposals SNIPs
1

Intro
The current policy for numbering SNIPs has been, with rare exceptions, as follows: the final number of a SNIP is the smallest available (= not taken) number at the time of merging the associated PR. Moreover, there is currently no standard on naming and/or numbering a draft SNIP when it’s still a pull request. This leads to a bit of a mess in the PR section of the repo.

Possible solutions

  1. No change in the numbering policy but introduction of a standard way of naming the PR such as “SNIP-XXX: title” or “Add SNIP: title”. The field “snip” in the header of the md file should be empty. The title of the .md file will be changed at merge time to the correct number.

  2. Change the numbering policy to: the final SNIP number is the PR number (automatically assigned by github). In particular, this number is already accessible at the draft stage. This is the way used by Ethereum until recently (see discussion). Thanks to @ericnordelo for pointing out this numbering policy.

Discussion
We should converge on an agreed upon standard in order to clean up the PR process and make it clearer (e.g. without “race conditions” for available numbers).

2

The ideal solution would be something that’s fully automatic (it’s painful to modify it by hand before merging) but also doesn’t create a lot of sparse SNIPs.

I think the EF has developed a bot that follows rule no. 1 → Rethink EIP numbering · Issue #6990 · ethereum/EIPs · GitHub

What do you think?

4

It feels a bit overkill for the current state of affairs, but if someone is up for writing such a bot (or modifying the existing EF bot) then sure. Writing a bot for policy number 2. is straightforward. Also I don’t think that sparse SNIPs would be a problem at the moment.