From GitHub Repo to DOI: Ten Minutes That Make Your Code Citable
Our last post and our earlier one on publisher data policies both landed on the same point: the requirement that reaches the greatest number of HKUST researchers is not a funder mandate. It is the journal you submit to.
That shift has now extended from data to code. PLOS Biology made code sharing a condition of publication at the start of 2026, PLOS Medicine will mandate the same in 2027, and economics journals have been verifying replication packages before acceptance for years. If you write code that produces a figure, a table or a result, there is a good chance your next submission will ask for it.
The Most Common Mistake in a Code Availability Statement
You put your code on GitHub while you were doing the work. That was the natural call: GitHub is where collaboration, version history and issue tracking happen. So when the submission form asks where your code can be found, you paste the repository URL.
For most major journals, that alone will not satisfy the policy. Springer Nature puts it plainly:
"Providing a GitHub link only is not sufficient as it does not assign a permanent identifier to the code."
The objection is not to GitHub as a platform. It is to the properties GitHub does not have. A repository can be renamed, made private, rewritten with a force push, or deleted entirely, and none of those actions leaves a trace at the original URL. What journals want is the opposite: a fixed, citable, permanently retained version of the code exactly as it stood when the paper was accepted.
Here are some more examples from publishers:
| Publisher | Where it stands now | What is required |
| PLOS Biology | Mandatory since January 2026 | A snapshot archived in a permanent public repository such as Zenodo, Code Ocean or Software Heritage |
| PLOS Medicine | Policy live since April 2026, mandatory in 2027 | Repositories issuing DOIs or other permanent identifiers preferred, with domain repositories used where possible |
| Nature Portfolio and Springer Nature | A Code Availability statement is required whenever new code underpins the conclusions | Code should be deposited in a repository that assigns a permanent identifier, such as Code Ocean or Zenodo, and cited in the reference list |
| Science journals | Required where custom computational methods go beyond routine fitting or common algorithms | Deposit in a permanent repository, and archive any GitHub code in its current form before publication, citing that version |
| American Economic Association and partner journals endorsing DCAS | Mandatory, and verified before acceptance | A trusted repository, by default the AEA Data and Code Repository. Code must run as downloaded without manual fixes |
| Elsevier journals | Varies by title, increasingly expected | A DOI-issuing repository such as Mendeley Data |
How to Archive a GitHub Repo
Note that no policy above tells you to stop using GitHub, and several in fact assume you are using it. What they require is an archived version. Follow the steps below. In less than ten minutes, you can get a citable object with a DOI which you can list on your CV and cite in your own later papers.
Set up once, per repository
- Connect the repository to Zenodo. Open an account at zenodo.org, sign in with GitHub, then switch on the repositories you want archived. Zenodo is free and commits to long-term retention.
- Add three files (a README saying what the code does and how to run it, a LICENSE saying what others may legally do with it, and a CITATION.cff saying how to cite you). Zenodo reads the last two automatically to populate its record, so put all three in place before your first release.
Then, for every paper
- Create a release from GitHub's Releases tab. The release is the trigger: Zenodo captures that exact snapshot and mints its DOI. Do this at manuscript submission rather than after acceptance.
- Cite the DOI that Zenodo issues in your reference list and in your code availability statement.
- Add the live repository link as well. PLOS Biology is one example: "please link to both the archived snapshot and live versions of the code, as they serve different purposes and both will be useful for readers."
One ordering trap is worth knowing. With the GitHub integration, Zenodo cannot reserve a DOI in advance, so remember to cut the release before you need the identifier. If you must have a DOI before any release exists, upload to Zenodo manually instead, which does let you reserve one. Alternatively, you can manually upload to our institutional data repository (DataSpace@HKUST) where you can also reserve a DOI.
