Affirm or replace "first come first assign"

[stevegt]

Experiencing #409, and reviewing #16 and stale PRs, it looks to me like we're not following the written procedures we do have, and that's causing:

• extra work for reviewers
• extra work and project delays for registrants
• failed attempts to properly use the multicodec field in CIDS
• failed attempts to interoperate with IPLD and the larger ecosystem
• a backlog of stale PRs
• likely bootleg use of multicodec numbers that are not registered but in use anyway because the registrant gave up

Does anyone have a written spec for what is required to add an entry to table.csv, beyond "first come first assign" and validate.py?

If not, can we agree that multicodec numbers are truly "first come first assign", and then update the README to mirror the RFC-8949 "first come first served" procedure for CBOR tags? That would include, among other things, a requirement for a written spec doc.

A CBOR-tag-style spec doc would not only demonstrate that the registrant has put some thought into the design, but would also provide at least some of the information that reviewers would normally look for, without them having to pull teeth to get the information out of the registrant.

The middle ground we're following right now -- claiming "first come first assign", but then hitting registrants with an informal design review with no obvious written standard, is not only consuming reviewers' time, but is unexpected and frustrating for registrants while blocking projects in the same way that led Juan to suggest "first come first assign" a decade ago.

Thanks all. I hope my frustration isn't coming through too harshly -- I overall think the multiformats project is invaluable. Everyone who has participated and is contributing in any way deserves all the support they can get -- and that's the origin of this issue; right now we're making things harder for reviewers, registrants, and devs.

[stevegt]

In case I wind up being the poor soul who updates the README, something like this is what I would do to adapt RFC-8949's registration process to multicodecs:

• require a draft spec doc with the draft table.csv entry
  • I provided one for 0x1027, but there is currently no dedicated column for a spec doc URL, so it's way over on the right in the description column
• have some sort of template or guidelines for what must be covered in the spec doc
• let the registration go through as a 'draft' entry in table.csv as long as:
  • spec doc coverage meets requirements
  • there are no conflicts with existing stale PRs or reserved allocations
• open an issue to iterate on details in the spec doc in order to advance the entry from 'draft' to 'permanent'
  • this unblocks projects and moves discussion out of the PR and into a longer-lived issue
  • gives everyone more time to think
  • works better with github's UI

[stevegt]

At minimum I'm volunteering to update the README to help set expectations for those who come later, by describing the existing process in more detail but adding that spec doc to reduce reviewer workload and PR-comment round trips.

Something like:

• do due diligence; save everyone time by using all resources at your disposal to understand IPLD etc.
• choose the longest-byte multicodec you can live with
• write an RFC-style spec doc for your new multicodec (this is the only real change from existing, I think)
• clone/pull and add the new row to table.csv; include spec doc URL
• run validate.py
• submit PR; include spec doc URL
• expect approximately two weeks for reviewers to chime in before merge
• expect design questions, suggestions, and revisions to spec doc during review period

Those last two points are key -- they currently aren't in the README and if I'd known ahead of time I would have scheduled multicodec registration earlier in my own project plan.