OSCR

Submitting a paper

OSCR finds most papers by itself. When it has missed one — or missed part of its code — anyone signed in can submit it: a DOI and the links to the authors' code. The registry then treats it as it treats every paper.

When to submit

  • A neuroscience paper whose authors published their code, and that the DOI lookup does not know, or knows without its code.
  • A paper whose code OSCR found only in part. (If you are an author or a maintainer of its code, you can also correct its record directly.)

Step by step

  1. Sign in — with ORCID if you are an author: you are then recognized at once.
  2. On the submission page, give the paper's DOI and one to five links to its authors' code, one a line, and, if you wish, a note for the operator (without an email address: any address is removed).
  3. The site checks the DOI and the links at once and records your submission, or tells you in words what is wrong.
  4. OSCR's harvester reads the paper as it reads every paper, verifies each link at its source — its commit, its licence, its scripts — and matches the code with the paper's paragraphs.
  5. A draft of the record comes back to your account page. Review it; correct the links if need be (the harvester reads them again); then publish.
  6. When your ORCID iD is among the paper's authors, the record is published at once. Otherwise the registry's rules publish it when each code link is proven the paper's by what you cannot write: the paper itself cites it (its text, or the metadata its publisher deposited at Crossref), or its owner is proven one of the paper's authors (an author's public ORCID record links to that GitHub account, or a verified author of the paper owns it). A README citing the paper, or a display name, proves nothing. If nothing proves a link, the submission waits for the operator, 30 days at most, and you are told why (how submissions are decided). Published, the next nightly publication brings it to the site.

The checks made at once

  • The DOI is registered: asked of doi.org's own index.
  • Each link points to a place the registry knows: a forge (GitHub, GitLab, Codeberg, Bitbucket, GIN…), an archive (Zenodo, OSF, figshare, Software Heritage, Code Ocean, Hugging Face…) or a data repository — the same rule as the harvester's. Any other address is refused, and the site fetches nothing else.
  • Each link answers: a link that answers "not found" or "gone" refuses the submission; a slow or failing server is left to the harvester to judge.

The licence is not checked at once: reading it needs the repository itself, which the harvester does.

The draft, and publishing it

The draft is the record exactly as it would be published: the paper's metadata, each repository with its state, licence and commit, and the number of matches. You may correct its links up to ten times. Published, your links become corrections of the record — a new version, which the Versions section records as a correction, without your name. A draft's matches need the paper's full text from Europe PMC; without it, they come after publication. A draft not published within 30 days is closed; correcting it from your account page (its links are kept) makes it a draft again.

Why a submission may be refused

  • the DOI is not registered, or a link is dead;
  • a link points to a place the registry does not know;
  • you already submitted this DOI (one submission per account and paper);
  • the paper is not neuroscience: it stays out of OSCR, whatever its code (the scope);
  • you are not among the paper's authors, nothing proves its links to be the paper's, and the operator refuses it — or no one reviews it within 30 days, and it is closed with how to ask again; either way, you read why on your account page;
  • the operator, reviewing what the rules published, finds it wrong: its links then leave the record.

Limits

At most 10 submissions a day per account, 1 to 5 code links each, a note of 1,000 characters at most.