Skip to content

feat: add submitter and reviewer guidelines #384

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

feat: add submitter and reviewer guidelines #384

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 24 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -70,6 +70,8 @@ Selecting the appropriate tag helps maintain organization in the table and provi

### Adding new multicodecs to the table

#### Guidelines for submitters
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The guidelines here don't include anything about adding new categories. I figured that happens much less frequently and we could look at that once we have something we're happy with here.


The process to add a new multicodec to the table is the following:

1. Fork this repo
Expand All @@ -88,6 +90,28 @@ Codec names should be easily convertible to constants in common programming lang

The `validate.py` script can be used to validate the table once it's edited.

Before submitting a new code please:
- [ ] Consider if an existing code works for you
- [ ] Submit a link to the specification the code refers to so that others may reference and use it
- [ ] Give some context on the intended use

To keep the initial review process lightweight and encourage experimentation, newly added codes are probationary.

Six months after submission, the submitter should comment on the merged PR with an update on usage.
If there is no comment or the code is no longer in use, a PR to remove it will be opened. If no objections are raised within 3 months, the code will be removed.

#### Guidelines for reviewers:

For reviewers of new codes please consider:
- [ ] Does the code fit within the relevant tagged category?
- [ ] Is this code needed or could it be served by an existing code?
- [ ] Is the byte size of the requested code suitable or should it be higher?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- [ ] Is the byte size of the requested code suitable or should it be higher?
- [ ] Is the byte size of the requested code suitable or should it be higher? (i.e. `0x7f` and below are the single-byte range, up to `0x3fff` is the two-byte range; you should have good case for occupying lower ranges of the table)

or something like this because I suspect a lot of people have no idea what we're talking about when we refer to this

- [ ] Is the number of codes requested suitable?
- [ ] Is approval of the code unlikely to cause the need for many more codes in a way that is avoidable or would warrant a new category?
- [ ] Is the name of the code unlikely to be confusing or problematic for users?

While reviewers are frequently experienced in the projects of the managed categories and can give guidance around the usage of codes and potential alternatives that better fit the guidelines they are not meant to gate a user's ability to leverage multicodec tooling. If a user has a code that fits the guidelines it should be approved even if the reviewer thinks an alternative approach should be acceptable but the submitter disagrees.

## Implementations

- [go](https://github.com/multiformats/go-multicodec/)
Expand Down