joss-reviews: where JOSS reviews are tracked in the open

A repository whose content is issues, not code

The joss-reviews repository has an unusual shape for something that appears in a directory of open source projects. Its entire top level is a .github directory, a .buffy directory, a LICENSE file and a README file. There is no source tree, no build system and no package manifest, because there is nothing to build.

What the repository is for is stated in its first line: it is the GitHub repository used to track the progress of reviews for The Journal of Open Source Software. The papers currently in review can be viewed as issues in that repository.

That is the whole mechanism. A submission under review becomes a public issue, and the review conversation happens there in the open rather than in a private system. Anyone can read how long a paper has been waiting, what the reviewers have asked for, and how the editorial process is moving.

The repository is not the journal. The README redirects readers who want information about the JOSS project to the JOSS website, and readers who want the open source application that powers JOSS to a separate repository. Three things, three places: the website for information, the application for the software, this repository for the editorial work in flight.

For an engineer deciding whether to adopt anything here, there is nothing to adopt. For someone watching how open peer review is run in practice, it is a rare transparent window.

Filing issues in the right place

The first thing the README does is warn, with emphasis and warning symbols on both sides, that bug reports for JOSS should not be submitted here and should go to the JOSS repository instead, where the issues section lives.

That warning is the single most practical piece of information in the file, and it points at a general property of this kind of repository. An issue tracker that is used as an editorial workspace attracts the wrong traffic: someone hits a bug in the journal website, opens an issue against the repository they found first, and the editorial volunteers spend time triaging something that belongs to the software project.

The routing the README describes is therefore worth stating explicitly. Bugs and issues about the JOSS software go to the openjournals/joss repository. Questions about the journal itself, such as what JOSS is and how it works, go to the website at joss.theoj.org, where the about page is linked. Reviews of submitted papers are tracked in the repository this article is about.

Three destinations, one sentence each, and a warning at the top of the file. If you are about to open an issue anywhere in the JOSS organisation, that routing is the first thing to check.

The code of conduct and how it is enforced

The README carries a code of conduct section, and it is the most substantial part of the document.

In the words of the README, JOSS adheres to a code of conduct adapted from the Contributor Covenant, in order to have a more open and welcoming community. The text asks people to adhere to it in any interactions with the JOSS community.

Three claims follow, and they are specific enough to be checkable. The code of conduct is strictly enforced on all official JOSS repositories, on the JOSS website, and on resources. The scope is therefore wider than this repository: it covers the software, the site and the surrounding material, not only the review issues. And there is a named escalation path, with reports going to the Editor-in-Chief, whose GitHub handle is arfon, or to someone on the editorial board, whose members are listed on the JOSS about page.

The README also states what happens after a report: the Editor-in-Chief or the editorial board will address it as soon as possible.

For a repository that contains no code, this is the correct place for the document. The people who read these issues are volunteers, and the people who comment on them are strangers, so the rules of interaction have to be stated where the interaction happens. Placing the code of conduct in the review repository, rather than only on the website, puts it in front of exactly the audience it governs.

The .buffy directory and the automation around reviews

Two hidden directories in the repository root hint at how much of the review process is automated. The .github directory is the familiar one, holding the repository configuration GitHub itself understands, such as issue templates and workflows. The .buffy directory is the less familiar one, and its name points at the automation JOSS uses to drive review submissions.

What the README does not do is describe any of it. There is no explanation of what the directory configures, which commands are run, how the bot interacts with the issue tracker, or what a submitter should expect to see appear in an issue. For a project with an active maintenance record, with the last push on 2026-10-19, that silence suggests the configuration is considered internal machinery rather than something that needs documenting for the community.

That is a reasonable editorial choice, but it has a consequence for anyone who wants to understand the process in detail. The visible part of the process is the issues themselves, and the automated part has to be inferred from the repository contents and from what appears in the issue threads.

The same is true of the relationship between the review tracker and the publishing side of the journal. The README points at the separate repository for the open source application that powers JOSS, so the two are distinct codebases with distinct purposes, and this one holds the editorial state rather than the software.

Licence, maintenance and who should read this repository

The licence file at the root is the interesting legal detail, and it is not the usual choice for a repository. The licence is CC0-1.0, a public domain dedication rather than a permissive software licence.

The reasoning fits the content. There is no source code here that someone could copy into a project, so the copyleft obligations of a software licence would buy nothing. What the repository holds is editorial discussion, and CC0 means that content is dedicated to the public domain, so it can be reused, quoted and republished without attribution requirements or restrictions.

That is a deliberate signal for a journal that publishes reviews of open source software under an open model. The reviews themselves are the public record, and the licence makes it clear that anyone can build on them.

On maintenance, the facts are modest. The repository has no GitHub releases, which makes sense for something that is a live workflow rather than a distributed artifact, and the last push was on 2026-10-19, the day before this article was written.

So who should read this repository? Three groups, in order of how likely they are to benefit. Authors with a paper under review, who want to see the state of their own review. Reviewers and editors, who work there. And everyone else who wants to see what peer review looks like when it is done in the open, since the issue threads are the product here rather than a side effect.

And everyone else should remember the routing: bugs for the journal software go to the JOSS repository, not here.

Editorial conclusion

joss-reviews matters to anyone publishing in JOSS or watching how open source review is organised, because the review queue is public and the code of conduct that binds it is stated in the same place, and for maintainers who want to follow the discussion of papers about their own field. It is the wrong repository for anything else, since the README asks explicitly that bug reports for JOSS go to the JOSS repository instead. Verify first which repository a question belongs to before opening an issue, and read the code of conduct section in full, since the README says it is strictly enforced across all official JOSS repositories, the website and related resources.

Frequently asked questions

Official sources

1. Issues
2. License: CC0-1.0
3. openjournals/joss-reviews on GitHub
4. README