Is GitHub enough for WBSO? What software teams need to prove to RVO

“We use GitHub and Jira. Isn’t that already our WBSO administration?”

It is one of the most common questions software teams ask once WBSO administration comes up, and it starts from a real fact rather than a myth. RVO explicitly names version-control systems such as GitHub and issue trackers such as Jira as project administration it is willing to accept for software R&D.

But there is a distinction that matters more than which tool you use: having the artifacts is not the same as having a clear WBSO dossier. A repository full of commits and a backlog full of tickets can sit next to an approved WBSO project for years without ever explaining what RVO actually needs to see.

The gap tends to show up at the worst possible moment: when an advisor is preparing the mededeling, or when RVO asks for the project administration behind a claim, and someone has to reconstruct, months or years after the fact, which commits belonged to which approved project and why. A team with one repository and one WBSO project can often bridge that gap from memory. A team with several repositories, several projects and people moving between them usually cannot.

Is GitHub enough for WBSO?

Short answer: GitHub, or any version-control and issue-tracking system, can be an important part of your WBSO project administration. It is rarely the whole administration on its own.

RVO’s own guidance for software companies is specific about this. The WBSO Handbook names version control and issue tracking as acceptable sources for project records, precisely because software teams already produce most of their technical history inside these tools. That is good news: your team does not need to invent a parallel documentation process. It does mean the material has to be organized and explained in a way RVO’s requirements actually describe, not just exist somewhere in a repository.

What RVO actually wants to see

The WBSO Handbook is consistent on what a project administration has to demonstrate for each approved project: the nature, content, progress and extent of the S&O work. In practice that breaks down into a few concrete expectations.

• The project administration and the hours administration have to align with each other, not live as two unrelated records.
• The work described in your records has to correspond to what was actually approved in the S&O declaration, not to R&D work in general.
• Hours have to be recorded per person, per project and per day, not as a monthly or quarterly estimate.
• The hours administration has to be brought up to date within 10 working days, and the wider project administration within two months after each calendar quarter.
• Records, including the technical ones, must be retained for seven years, so material has to stay retrievable long after the sprint, or the engineer, has moved on.

None of this says a company must use a specific tool. It says the administration has to be current, specific to the approved project, and kept for long enough that someone outside the original conversation can still make sense of it. A GitHub repository can satisfy every one of those expectations. It does not satisfy any of them automatically just by existing.

What GitHub and Jira prove well

Used well, engineering tools are strong evidence. A pull request or a ticket usually carries exactly the kind of detail a hand-written note tends to lose:

• The date the work happened, not the date someone remembered to write it down.
• Who did the work, tied to a real account rather than a shared login.
• The technical activity itself: a diff, a design discussion, a test run, a benchmark.
• The iterations: the first attempt, the follow-up commit that fixes what did not work, the comment that explains why.
• A trail of issues, pull requests, commits, tests and abandoned branches that together show a project moving, stalling and moving again.

This is exactly why RVO is comfortable naming these systems in its guidance. For a software project, a repository is often where the real R&D history lives.

What GitHub cannot explain by itself

The gap is not in the data GitHub and Jira hold. It is in the questions they were never designed to answer.

• Which approved WBSO project a given commit or ticket belongs to. A repository does not know about your S&O declaration.
• Why a problem involved genuine technical uncertainty, rather than being a known solution that simply took time to build.
• Which specific technical bottleneck a piece of work was addressing, and whether that bottleneck was the approved one.
• Why a particular employee’s hours on that ticket qualify as S&O work, rather than routine implementation around it.
• How a failed approach, such as an abandoned branch, a reverted pull request or a benchmark that missed its target, actually influenced the solution that followed.
• Whether the ticket in front of you is R&D at all, or ordinary maintenance and bug-fixing that happens to sit in the same repository.
• How that piece of technical work relates to the hours someone logged for it, so the two records tell the same story instead of two separate ones.

A reviewer, whether that is an advisor preparing your mededeling or RVO during a check, cannot infer any of this from a commit message alone. It has to be visible in how the administration connects the pieces.

A stronger WBSO evidence chain

The fix is not more documentation. It is a consistent link between the pieces you already have.

Approved technical problem → engineer → hours → issue/PR/commit → result or failed approach

When every piece of evidence can be traced along that chain, a reviewer does not have to take your word for why a ticket qualifies. They can see the technical problem it was approved to address, the person and hours that went into it, and the outcome, successful or not. None of that requires developers to write a second version of what they already put in a pull request description or a ticket. It requires the administration to keep the connection between the project, the person, the hours and the artifact intact, instead of scattering them across several tools with no link between them.

Practical example

Take a realistic situation: a team building a new search feature that has to stay under a strict latency budget at a data volume their current index cannot handle.

Weak evidence: an hour entry that says “development work,” linked to nothing, next to a merged pull request titled “update search.”

Strong evidence: an hour entry for the same day naming the engineer, the project and “tested a sharded index after the flat index missed the 200ms target at 10M records,” linked to the pull request that adds the sharding logic and to the earlier, reverted pull request that shows the first approach failing.

The underlying engineering work can be identical in both cases. The difference is entirely in whether the administration shows the technical uncertainty, the approach that did not work and the approach that did, or whether it shows a vague hour note next to a title that could belong to any sprint.

How R&Dossier helps

R&Dossier does not ask developers to document their work twice. It connects the approved project, the people assigned to it, the hours they log and the evidence already sitting in GitHub, Linear or Azure DevOps, so that chain of problem, person, hours, artifact and outcome stays intact as the work happens rather than being rebuilt from memory later. Pull requests and issues come in as evidence candidates tied to a project mapping, a person still decides what becomes official evidence, and every entry keeps its date, author and review status instead of turning into an anonymous export.

The dossier can then be reviewed as one story instead of reconstructed from several systems under time pressure: which project a piece of evidence belongs to, who logged the matching hours, and how the two are linked are all visible together, not spread across a repository, a spreadsheet and someone’s memory of a sprint from eight months ago.

GitHub is valuable evidence, not the whole dossier

GitHub and Jira are exactly what RVO says they can be: legitimate, often strong, project administration for software R&D. What turns that raw technical history into a WBSO dossier is not extra paperwork. It is enough context and traceability that someone who was not in the room can still explain, months or years later, what was uncertain, what was tried and what qualified.

That is the real test for any WBSO project administration, tool-based or not: not how much technical material exists, but whether the story connecting the approved project, the people, the hours and the evidence still holds together once the people who lived through it have moved on to the next sprint.

Frequently asked questions about WBSO

Is GitHub enough for WBSO administration?

GitHub can be an important part of a WBSO project administration, since RVO explicitly accepts version-control systems as evidence for software R&D. On its own it rarely covers everything RVO expects: the records still need to show which approved project the work belongs to, why it involved technical uncertainty, and how it connects to the hours logged against it.

Can Jira be used as WBSO project administration?

Yes. RVO names issue-tracking systems such as Jira alongside version control as acceptable software project administration. Tickets are strongest as evidence when they make the technical problem, approach and outcome clear, rather than only a title and a status.

Does every WBSO hour need to link to a commit?

No. RVO does not require a one-to-one link between every hour entry and a specific commit or pull request. Linking hours to evidence where it is meaningful improves traceability, but the statutory requirement is that the hours and project administration align and correspond to the approved work, not that every hour has a matching artifact.

How long must WBSO project records be kept?

WBSO records, including project administration such as version-control and issue-tracker evidence, must be retained for seven years. That includes records from project phases and approaches that were ultimately abandoned.