Skip to content

Contributing

Jump to bottom
Frans Ward edited this page Oct 29, 2026 · 1 revision

Contributing

Edubadges welcomes contributions from institutions, developers and standards specialists. There are two kinds of contribution, and they follow different routes:

You want to… Route Decided by
Fix a bug, improve code, tests or the API Pull request on edubadges-server or edubadges-ui SURF Edubadges team
Correct or clarify the wiki (typos, broken links, unclear text) Issue with label documentation SURF Edubadges team
Change the Edubadges Metadata Model (new field, new extension, new enumeration value, changed meaning or validation) Issue with label metadata-change (see below) Metadata Steering Group
Report a security vulnerability Not a public issue — see Security SURF Edubadges team

All contributors are expected to follow the Code of Conduct.

Contributing code

  1. Open or find an issue first for anything larger than a small fix, so the approach can be agreed before you invest time.
  2. Fork the repository and create a branch from develop (not master). Name it after the issue, e.g. 1234-fix-assertion-expiry.
  3. Set up a development environment as described in the README (Docker or local).
  4. Code style: run ruff check and ruff format (configuration in ruff.toml).
  5. Tests: add or update tests and run ./manage.py test before pushing. Pull requests that lower coverage need a reason.
  6. Migrations: include Django migrations in the same pull request as the model change, and keep them reversible where possible.
  7. Open a pull request against develop, link the issue (Closes #1234) and describe what changed and how you tested it. Add an entry under Unreleased in CHANGELOG.md.
  8. A member of the SURF Edubadges team reviews the pull request. Expect a first response within [TBD: e.g. 10 working days].

Licence. Edubadges server is licensed under AGPL-3.0. By submitting a pull request you agree that your contribution is released under the same licence.

Proposing a change to the metadata model

Changes to the metadata model affect every institution that issues edubadges and every system that reads them, so they go through the Metadata Steering Group rather than straight into code.

Who can propose? Anyone. Proposals backed by an institution or a sector programme (e.g. the Npuls microcredentials programme) carry more weight, but are not required.

How? Open an issue with the label metadata-change and include:

  • Problem: what cannot be expressed today, and for whom (MBO, HBO, WO, employers, wallets…).
  • Proposal: the field(s), datatype, cardinality, allowed values, and on which object (Issuer, BadgeClass, Assertion).
  • Alignment: how the proposal relates to the EU Council Recommendation on micro-credentials, ELM/EDC, Open Badges 3.0 and HORA/MORA. Reuse an existing term where one exists.
  • Impact: is it backward compatible? What happens to badges already issued?
  • Example: a JSON example of the extension object.

What happens next is described in Roadmap and Maintenance → Change process.

Security

Do not report vulnerabilities in public issues. Send them to [TBD: security contact, e.g. a SURF CERT or edubadges security address] with steps to reproduce. You will receive an acknowledgement within [TBD] working days.

Questions and contact

  • General questions: open a GitHub Discussion [TBD: enable Discussions] or an issue with label question.
  • Institutions using the service: [TBD: SURF servicedesk / support address].

Clone this wiki locally