qubes-issues is where Qubes OS decides what gets built next

A repository with no code, and that is the point

The Qubes OS project keeps its issue tracker in a GitHub repository rather than in the source tree, and the repository says so in its first line. This repository tracks issues and feature development progress for the Qubes OS Project, and the README asks visitors to take a moment to read a short list of important information before doing anything else. That list is the real content of the repository. It links the issue tracking page, the contributing guide, the help and support page with its mailing lists and forum, the code of conduct, and the terms of use. Each of those is a document elsewhere, and the repository is the index that points at them. The top level of the tree matches that description, with a .github directory, a CONTRIBUTING.md, an ISSUE_TEMPLATE.md, a README.md and a travis_status.md. So this is a working surface rather than a codebase, and reading it tells you how the project organises its work rather than how its software is built.

The issue template shapes what a good report contains

The ISSUE_TEMPLATE.md at the top level is the mechanism behind the filing link in the README, which points to a new issue page offering a choice of templates. A template is where a project decides what information it needs before a report is useful, and here the decision is made once and applied to everyone, which is what keeps a tracker of a security focused operating system navigable. The repository also carries a CONTRIBUTING.md of its own, distinct from the contributing guide in the documentation, so the process expectations live next to the templates they describe. The link structure in the README makes the entry points explicit, with one link to file a new issue and one to view all issues. For a project whose users are often reporting subtle security or isolation problems, the difference between a report with the right structure and one without is the difference between a triageable issue and a support request that belongs on the forum.

Labels split the queue into approachable and urgent

The README groups the label views by who they are for, and the grouping itself carries information about how the project triages. Under notable issues there are good first issue, help wanted and community-developed, each of them a live search filtered to open issues. Under high-priority issues there are Blocker and Critical, which the search syntax shows as the labels P: blocker and P: critical. That is a small design decision with a large effect on the queue. A tracker that mixes an onboarding task and a release blocker in one undifferentiated list is unusable at scale, and separating them by label means a newcomer looking for good first issue never sees a critical kernel bug, and a maintainer looking for P: critical never has to filter out onboarding work. The community-developed label is the third and most interesting one, since it marks work the project is not doing itself and is inviting outside help on, which is the boundary between the project and the people using it.

Component build status is published per release, and one source is obsolete

The Components status section is the part of the repository that carries data rather than pointers, and it comes with an important caveat. The component build status by release is published through a GitLab-CI report at qubesos.gitlab.io/qubes-g2g-report/, and there is a second source, a Travis-CI status file called travis_status.md, which is marked obsolete. That single word is doing a lot of work. A project that ships many separate components needs to say which of them are green for a given release, and a link that is labelled obsolete tells a reader that the file sitting in this repository is history rather than current state. The good first issue and help wanted views are also live filtered queries rather than static lists, so the state of the queue is always the current state of the queue. Between the two, the repository acts as a small dashboard of the project without hosting any of it.

Support requests and bug reports are deliberately separated

The link list points at help, support, mailing lists and forum as a distinct destination from the issue tracker, and the presence of a code of conduct and a terms of use page alongside it tells you the project treats the tracker as a governed space. The issue tracking documentation page is listed first, ahead of everything else, which is the right order for a project where the tracker is public and searchable by anyone. A security focused operating system attracts a specific kind of report, ranging from a genuine isolation bug to a user misunderstanding a template VM to a question about documentation, and a single undifferentiated queue handles all three badly. Routing support questions to the forum and mailing lists keeps the tracker meaningful for the people who read it every day, which is the maintainers and the contributors trying to find something to work on.

How this compares with a tracker that lives inside the source tree

The alternative arrangement is the common one, where the issue tracker is simply a feature of the source repository and the project does not think about it as a separate artifact. Some projects do that deliberately, because a single repository is one thing to watch, one set of notifications and one place for a new contributor to look. Qubes OS does the opposite, and the difference is visible in what the repository contains. There is no build system, no source, no release automation and no code, only templates, labels and two status links. The trade is that a contributor has to understand the label vocabulary and the routing rules before their first report is useful, and a project that adopts this model has to keep the templates and the label sets in step with its own documentation. The payoff is that the tracker stays readable, and the commits in this repository are then about process, which is why its last push on 2026-07-08 is a documentation or template change rather than a code change.

Where this repository is the wrong place to look

The first wrong case is expecting source code. This repository is tracking metadata, and a clone of it will not build a system, install a hypervisor or produce an ISO image. The second wrong case is expecting a stable set of labels and views, because every query in the README is a live filtered search over labels the project can rename or retire, so a script that scrapes the good first issue list is reading something that can change under it. The third is expecting the component build status to be authoritative, because one of the two listed sources is marked obsolete and the other is a report published elsewhere, on a schedule this repository does not control. The fourth is treating the tracker as a support channel, which the README steers away from explicitly by pointing support questions at the mailing lists and the forum. The fifth is a project that wants to run its own tracker, since everything here is expressed as GitHub issues, labels and search queries, and there is no import path described for moving elsewhere.

Editorial conclusion

Contributors who want a way into Qubes OS and people tracking why a component is not ready are the audience for this repository, and the good first issue and help wanted views are the two doors in, while the P: blocker and P: critical views show what the project considers urgent. It is the wrong thing to clone for the operating system itself, since the repository holds tracking metadata and no source, and it is the wrong place to look for release binaries, since the component build status is a link away to a separate report rather than a download. Check three things before you rely on it: that the labels you are searching on still match the ones the project uses, since the tracker links to its own label queries, that the component build status you are reading is current, since the Travis-CI one is marked obsolete and the GitLab-CI report is the live one, and that you read the issue tracking and contributing pages, which the README asks every visitor to do before anything else. The repository publishes no GitHub releases and the last push was on 2026-07-08.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. QubesOS/qubes-issues on GitHub
4. README