multiformats / multiformats/multicodec
Affirm or replace "first come first assign"
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 383
- Forks
- 221
- Avg merge
- 24d 6h
- Merged PRs (30d)
- 1
Description
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
multicodecfield 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.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the current procedure in README, the validation behavior in validate.py, and the relevant entries in table.csv, then compare them with the RFC-8949 first-come-first-served guidance linked in the issue. Done means the project reaches agreement on the registration standard and records the resulting procedure clearly in the README.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100