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.
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:
multicodecfield in CIDSDoes 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.