Skip to content

Submit your code

Anyone working in or with the NHS can add their code to the library. You do not need to meet a quality bar: the Baseline tier only asks that your code is findable and described. Sharing messy-but-useful code beats not sharing at all.

How it works

  1. Open a submission issue using the Submit a Library Entry issue template. It walks you through every field.
  2. Automation drafts the entry. A workflow reads your issue, generates the library/<slug>/metadata.yaml file, validates it, and opens a pull request. If anything fails validation, it comments on your issue explaining what to fix.
  3. A maintainer reviews the pull request. Once merged, your entry appears in the catalogue on the next deploy.

If you are comfortable with pull requests, you can skip the issue and submit the YAML file directly.

Direct submission: a starter file

Create library/<your-slug>/metadata.yaml with the required fields below, then open a pull request. Validation runs automatically.

title: My Project Name
description: >
  One to three sentences in plain English. What does it do,
  and who is it for?

category: data_analytics            # see the categories page
project_type: Dashboards            # must match the category

language:
  - python

repo_url: https://github.com/your-org/your-repo
repo_visibility: public             # public | private | internal

reusability_tier: baseline          # baseline | bronze | silver | gold

organisation: Your NHS Organisation
contact: you@your-org.nhs.uk        # or a GitHub username

Every other field is optional; the data model reference lists them all. Adding tags, a documentation link, and a tier rationale raises your entry's quality score.

What you will need

  • Repository URL, public, private, or NHS-internal. Private repositories are welcome; the entry just needs to say who to contact for access.
  • A short description: 1-3 sentences in plain English. What does it do, and who is it for?
  • Category and project type: see the category taxonomy.
  • A self-assessed reusability tier: see the framework, which includes a self-assessment checklist. Be honest; Baseline is a perfectly good place to start.
  • A contact: an email address or GitHub username for questions and access requests.

Ground rules

No patient data

Submissions must not contain patient data, hardcoded credentials, or anything that should not be publicly listed. Use synthetic or anonymised data in any examples. The catalogue entry itself is always public, even when the repository is private.

Updating an entry

Code moves on; the catalogue should keep up. Unlike new submissions, updates and withdrawals are applied by a maintainer by hand rather than by automation, so allow a little longer for them.

  • Correct or update an entry with the Update a Library Entry issue template, or open a pull request editing the entry's metadata.yaml.
  • Withdraw an entry with the Withdraw a Library Entry issue template. Withdrawn entries keep their YAML file in the repository with status: withdrawn, so there is an audit trail, but they leave the catalogue.

Raising your tier

Once listed, you can resubmit at a higher tier as your code matures. The reusability framework sets out exactly what each tier requires; most projects reach Bronze with an afternoon of tidying: remove hardcoded paths, add a dependency file, and explain access in the README.