Working on GitHub

This is the guide for newcomers to our GitHub spaces. It gives an overall, practical overview of how we work on the collaboration spaces: accounts, security, issue handling, stewardship and publication. The details are in our checklists and other supporting material.

The focus is on DiggSweden; in time the same principles will apply to SwedenConnect.

If you are new to open source as a whole, we recommend you first read through opensource.guide — a broader introduction to the field, the community and how to contribute. There is also a Glossary of terms and concepts — definitions of the concepts used in this handbook.

Collaboration spaces

Digg currently has two external collaboration spaces on the GitHub platform:

DiggSweden — Digg’s own GitHub organisation, for solutions and documentation where Digg is the lead.
SwedenConnect — the GitHub organisation for the Sweden Connect federation (Swedish eID and eIDAS), operated by Digg.

That is where work happens around different projects, together with external consultants, contributors and Digg staff. The spaces hold mostly programming-heavy projects, but pure documentation and specification projects also occur.

Organisation	Purpose	Main responsibility
DiggSweden	Releasing our own solutions, working with others	`ospo@digg.se` (Open Source Guild — fills much of an OSPO role at Digg) GitHub users with the Owner role
SwedenConnect	Most SwedenConnect-related projects	GitHub users with the Owner role

The list of Owner accounts is not published externally. OSPO/Open Source Guild is active on DiggSweden; SwedenConnect is coordinated through its Owner roles. The rest of this guide describes processes specific to DiggSweden.

GitHub accounts

You first need a GitHub account.

You should add your name@digg.se address to your existing GitHub account if you already have one. That is the simplest path, and personal contributions to open-source projects are not a problem from Digg’s perspective. If you want to keep work and personal activity entirely separate on GitHub — for privacy and clarity — you can create a separate account for your professional role with us.
Bear in mind that your account is partly public — outsiders who see your activity there may perceive you as a representative of us. You are therefore expected to conduct yourself professionally and in a way befitting a public agency on the account linked to your name@digg.se address.
Whatever username you have, also fill in your real name (GitHub → Edit Profile → Name).

Basic security for your GitHub account

Two-factor authentication (2FA) must be enabled — set it up via GitHub’s instructions and keep the recovery codes somewhere safe so you don’t risk being locked out if you lose your device.

If you contribute via pull requests, two more things matter. Always use your name@digg.se address in your commits — that is how Digg, as a public authority, can show who contributed what. You must also sign your commits so others can verify that you really are the sender.

Also enable “Vigilant Mode” on your GitHub account — it makes your signed commits show as verified to others.

Adding a user to DiggSweden

If you only contribute occasionally to public projects, the role External Collaborator is recommended. If you work in the organisation daily — and sometimes also with private projects — you instead need to join our GitHub organisation and be added to one or more Teams (GitHub’s term for a group of users inside the organisation). As a rule of thumb, employees join the organisation while consultants are mainly External Collaborators.

Whichever role you are assigned here, the invitation comes from someone with the Owner or Admin role — in most cases through a project or consultant team you are already part of. If you don’t know who has that role for your team, contact OSPO — state your purpose and what you need, and they will help from there.

Base settings and template project

There are two different supports to know about. One is inherited automatically, the other you choose actively.

The organisation’s base settings

All repositories on DiggSweden inherit a default set of templates for bug reports, feature requests and pull requests from diggsweden/.github. The templates are active from the first commit, and the repository can then adapt them to the project’s needs.

Template project for creating or publishing new open projects

If you are creating a new open project — or publishing an existing internal project openly — we have a Template project for open source software with community files, REUSE licensing, OpenSSF Scorecard and more. The template’s files are copied into the new repository and adapted to the project’s needs.

Stewardship and lifecycle management

Issue handling

The team that owns a repository has primary responsibility for responding to issues. How the team organises that work in detail is up to the team.

Remember that our GitHub and project spaces are primarily intended for project-focused issues. Discussions that do not relate to a project directly should be steered to other spaces. Questions that are not technical or do not concern a specific project are referred to our customer service (info@digg.se).

Digg is a public agency and the public expects us to answer politely, correctly and within a reasonable time. Recommended response time for an issue is five days.

Handling inactive members

Two cases are handled differently:

When someone leaves. When someone leaves Digg or otherwise ends their assignment, they are removed from the GitHub organisation — that means Team memberships go away, but the personal GitHub account remains. Each Team’s Admin keeps an informal eye on its members (an automated check is in the works).

On prolonged inactivity. Users in the GitHub organisation who have had no visible activity (commits, comments, issue updates) for a year are removed automatically — even if their employment with Digg is still active. If you need to re-join, the route is the same as the first time: contact your Admin/Owner or OSPO.

Archiving projects

Projects without maintainers count as inactive and must be archived — ideally with a note in the README.

Inactivity is judged on a yearly basis. Inactivity means the project has no commits, issue updates or other visible activity.

To identify maintainers from the start, a CODEOWNERS file is recommended — it complements the README and ensures the right person automatically receives review requests. See the Release preparation checklist.

Vulnerability and security

GitHub provides several built-in tools for automated vulnerability and security scanning. We, however, prefer vendor-neutral tools where possible — for example, Renovate for dependency monitoring and Opengrep for static code analysis. GitHub-specific features such as secret scanning are used where they fit better. The reasoning behind the platform-neutrality is that we should be able to work in similar ways on other code-collaboration platforms — for example GitLab or Forgejo — without having to rebuild the toolchain.

A selection of the security features enabled at organisation level is listed in Reference: Default GitHub settings — the list is deliberately not exhaustive. Defaults may need fine-tuning by the team.

When a security alert comes in, the team that owns the repository has primary responsibility to address it.

Publication of external libraries and container images

Work in progress. This section is being migrated.

You must not publish artefacts that Digg is responsible for under personal names. Instead, use a shared Digg account with ospo@digg.se as the owner/sender address — that way we avoid person-dependencies and, in the worst case, stale email addresses. A release bot with signing keys is also set up — see the section below. Active developers can then be added as “Developers” on the package.

If a project needs a new shared account on a package registry, contact OSPO.

Package registry: npmjs.com

For Javascript/Typescript libraries.

Digg currently owns two organisations on NPMJS: digg and diggsweden. The digg organisation is archived; diggsweden is the one to be used going forward.

Package registry: Maven Central Portal

For Java/Kotlin libraries.

Digg owns two namespaces on Maven Central Portal: se.digg and se.swedenconnect.

Use SNAPSHOT releases until you are entirely sure you want to publish a production release. What is published on Maven Central Portal and is not SNAPSHOT cannot be removed, except in very special cases.

Package registry: GitHub Container and Package Registry

GitHub Packages is intended for development, not production releases. Access requires a GitHub token, among other things, which becomes cumbersome at larger scale — every user always needs a token. Therefore also publish on Maven Central Portal.
For container images: prefer small, secure base containers (e.g. distroless, Wolfi or Chainguard).

Release bot, CI flow and available variables

Most newer projects on DiggSweden now use this setup — a release bot together with reusable workflows and configured secrets. We recommend it if you want many of the baseline requirements from the checklists covered out of the box: secure signing, dependency checks, licensing and project-health indicators are part of the default, and individual developers do not have to handle keys or become person-dependencies in the flow. The bot can sign and commit releases in a CI flow triggered by a tag push.

For DiggSweden everything is gathered in diggsweden/reusable-ci — lints, security scans, signing, package publishing and more. See the component list for a current overview.

For a practical example of a release pipeline that uses them, see diggsweden/cose-lib.

Frequently asked questions (FAQ)

Teams

How do I create a GitHub team?
Ask someone with the Owner role, or contact OSPO.
Do I have to create a GitHub team?
No. For cost reasons, not everyone who contributes needs to be in a team in the organisation. If the project is public, it can be enough that one or two maintainers approve external pull requests, just as in any other open source project. You can also be assigned the External Collaborator role.
How should teams be divided: per product, per consultancy, or how?
Existing teams are sometimes split by area of responsibility, sometimes by consultancy affiliation, sometimes by project. Decide what suits you best. Made-up example: a product team for “covidbevis” plus a consultancy team “konsultTeam2” working across several projects. A Member can belong to several teams.
A team gets access to one or more repositories. What rights should they have by default?
Since teams may include external collaborators (consultants and contributors), members are not considered security-cleared. The default rights for a repository team must therefore be Read. The team admin then grants individual members the rights they need (Write, Maintainer etc.) where required.
I want to fork an external project. Should I do it under Digg’s GitHub organisation or under my private user?
In most cases: no fork under our GitHub organisation. Fork under your own user in the first instance. We do not want DiggSweden to be perceived as having taken on the stewardship of a fork of an external project. There are exceptions, though — for example, when a team needs a shared working copy under the organisation in order to contribute back upstream (shared PR flows, longer collaborations). In that case, check with OSPO or an Owner first. Forks placed under the organisation without prior discussion will be archived.

Schrems II and GDPR

May we use GitHub at Digg? It is, after all, an American cloud service. What about GDPR and Schrems II?
For now GitHub is used at Digg as a complement, which is also mentioned in Digg’s guidelines for open source software. At the same time there is an effort to find other solutions, not least because the adequacy decision eases information transfer but does not solve the other risks (eSamverkan summary, in Swedish, PDF).

Contribution

May we contribute bug fixes and issues upstream?
Yes. For practical steps, see the Upstream contribution checklist — it covers policy check, licence choice, CLA/DCO, communication and escalation.
In practice, we already contribute actively to open source and open data today — both directly and through procurements and collaborations where we encourage and require open source from external partners.

Licence headers (REUSE/SPDX)

How do I write licence headers correctly with REUSE/SPDX? There are several common conventions.
Several conventions exist for the licence statement itself, for example:
- <YEAR> <COPYRIGHTOWNER>
- <YEAR> <GITHUBSPACE/PROJECTNAME>
- <YEAR> The <projectname> Authors
Digg recommends <YEAR> <COPYRIGHTOWNER> as the first choice for clarity. Concrete example: 2026 Digg - Agency for Digital Government. See also the REUSE FAQ for further information on licence headers.

Private and public projects

Why are there private projects on Digg’s GitHub? Is it not a platform for open source software?
There are several reasons why a project may need to be private for a phase: ownership is not settled, we have not decided whether an older project from another organisation should become open source, or we need to quality-assure the project before publishing it openly. The starting point is still that private projects should primarily be collaborated on in more suitable (closed, more secure) spaces. Only in exceptional cases, and as a deliberate choice, should they live on GitHub.
I just have more questions. Where do I turn?
Contact OSPO in the first instance. In the second instance, contact someone with the Owner role.

Links

Open source projects