Suggestion: wider use of GitHub for task management
Contribution, August 2026.
The proposal in brief
The project should adopt GitHub Projects for cross-cutting work – in the same way the pilots already use GitHub to keep track of their tasks.
A GitHub Project is a board, much like a Kanban board in Planner or Trello. What sets it apart from other boards is that it can pull items from several different work areas at once and show them together.
What the proposal is not
This is not a proposal to stop using Planner.
Planner works well for distributing tasks internally within the core team – who does what, and by when. It can keep that role.
The proposal concerns a different kind of task: the cross-cutting work that belongs neither to one particular pilot nor to the core team’s internal distribution of work.
How things stand today
The pilots record their tasks as issues in a shared work area on GitHub called “Oppgaver”. Each item is labelled with the pilot it belongs to. In August 2026 it holds 62 items: 6 labelled pilot 1, 14 pilot 2 and 24 pilot 3. Pilot 4 has been given its own label, but has not started using it.
The core team uses Planner.
What is missing
Between these two lies a third category that has no natural home today:
- shared vocabulary
- overall architecture that several pilots build on
- methodology and ways of working
- preparations for gatherings, such as the August workshop
- clarifications that concern everyone, such as access management and roles
Today such tasks are either labelled with one arbitrarily chosen pilot, placed in Planner where pilot participants cannot see them – or not written down at all.
How it could work
An organisation-level project board can pull items from several work areas at once: from “Oppgaver”, from the pilots’ own areas and from the documentation.
Each item can then stay where it belongs, while the board provides a combined cross-cutting overview. You keep the link between a task and the specific work it concerns, and gain the overview as well.
What it would take
- Creating the board, and deciding which work areas it draws from
- Agreeing on a label for cross-cutting items
- Clarifying who keeps the board up to date
None of this requires new software or new licences. The GitHub accounts already exist, and all participants have access.
The relationship to Planner over time
The project already has a two-part division: Planner for the core team’s internal distribution of work, GitHub for the open work. The two are not connected, and that is part of why the work on one side is barely visible from the other.
This proposal does not change that. It is about giving cross-cutting work somewhere to live, not about touching Planner.
Should Planner’s role be reconsidered later – for reasons of licensing, accessibility or digital sovereignty – there are project tools that connect to GitHub, so that a task shows the status of the actual change.
One obvious example is OpenProject, a web-based open source project management tool. It is listed in the EU catalogue of open source for the public sector, is explicitly aimed at public administration, can be self-hosted or run in an EU-based cloud, and is used by the European Commission itself among others. It also meets the accessibility requirements (WCAG 2.1).
But this is a separate question, and should be handled on its own.
Questions for discussion
- Is it correct that cross-cutting tasks have no home today – or do they exist somewhere I am not aware of?
- Should the board be open to all participants, or limited to some?
- Where does the boundary against Planner’s role lie in practice?
Why this is considered good practice is discussed in more general terms under Co-creation → Task management.