Community Development Roadmap

Strategic initiatives tracked in Bugzilla, organised by release and theme.

Loading…

Putting your work on the roadmap

This roadmap is built live from Bugzilla — there is no separate page to edit and nothing to keep in sync by hand. If you tag your bugs correctly, your work shows up here automatically and stays accurate.

This replaces the old wiki roadmap pages. Bugzilla is now the source of truth; this dashboard is the view. You only need to set a handful of custom fields on bugs you already have.

The three things the roadmap reads

1. Initiative type — what role does this bug play?

Set the Initiative type field on the bug (--- by default). Most bugs stay --- and never appear on the roadmap. Promote a bug only when it represents planned strategic work:

ValueUse it for
MetaA long-running programme spanning several releases (e.g. an Omnibus)
EpicA project that delivers something concrete in a release
FeatureA specific deliverable inside an Epic
---An ordinary bug — leave it here unless it's roadmap-worthy

Epics are the unit the roadmap shows as cards. A Meta is the heading that groups them.

2. Theme — which strategic area does it belong to?

Set the Theme field. This is not a module/component (Bugzilla components already do that) — it's a broad cross-cutting concern that groups the roadmap into swimlanes:

Modernisation · Accessibility · Performance · Developer Experience
User Experience · Interoperability · Security

Pick the one that best describes the strategic intent. If you leave it blank the Epic still appears, but in an Unthemed section at the bottom — so it's worth setting.

3. Target milestone — which release are you aiming for?

This is the standard Bugzilla Target Milestone field, and it drives the release tabs at the top of the roadmap.

  • Set it to the release you're aiming to land in, e.g. 26.11.
  • Set it to Future (or leave it unscheduled) if you have the ambition but no committed release yet — it shows under the Future tab.
  • Past releases (25.11, 26.05, …) act as an achievement record of what shipped.

The roadmap opens on the next upcoming release by default, so put your target there to be seen.

Linking work into the hierarchy (this is what builds the tree)

The roadmap structure comes entirely from Bugzilla's dependency graph — the Depends on / Blocks fields. There is no extra "parent" field to set.

Read it as: the parent depends on its children being done.

Meta  "Depends on"  →  Epic     (the Meta blocks until its Epics are done)
Epic  "Depends on"  →  bugs     (the Epic blocks until its tasks are done)

So to attach your Epic to a programme:

  1. Open the Meta bug.
  2. In Depends on, add your Epic's bug number.

And to give your Epic a progress bar:

  1. Open your Epic bug.
  2. In Depends on, list the individual features/bugs that make it up.

The progress bar counts all descendants down the tree (not just the direct ones), so deep dependency chains are reflected automatically. An Epic with no children simply shows "No child bugs tracked" — still valid, just no bar yet.

An Epic that isn't under any Meta is fine: it renders as a standalone card in its theme row.

Signalling that you intend to work on something

Two signals, both standard Bugzilla:

  • Assignee — assign the Epic to yourself. Your name appears on the card, linked to your personal dashboard, so people can see who's driving it.
  • Target milestone — set the release you're aiming for. This is how you state ambition and timeline: "I intend to land this in 26.11." Use Future for "I want to do this, no date yet."

If you want sponsors credited, fill in the Sponsors field — free text, shown on the card. (Funding goals/targets live on the separate Crowdfunding page, not here.)

Quick recipes

"I'm starting a new project for the next release."

  1. File or pick the Epic bug → set Initiative type = Epic.
  2. Set Theme and Target milestone = 26.11.
  3. Assign it to yourself.
  4. Add its constituent bugs under Depends on.
  5. If it's part of an existing programme, add it to that Meta's Depends on.

"I have a long-running Omnibus that spans releases."

  1. Set the Omnibus → Initiative type = Meta, set its Theme.
  2. Leave the Meta's milestone alone — the Epics carry the release targets.
  3. Make sure each Epic is in the Meta's Depends on list.

"I want to flag an ambition with no committed release."

  1. Set Initiative type = Epic, set Theme, assign yourself.
  2. Set Target milestone = Future. It appears under the Future tab until you commit a release.

Notes

  • Changes show up within an hour (the roadmap caches its data for 1 hour).
  • Nothing you do here changes how an ordinary bug behaves — only bugs you explicitly mark as Meta/Epic/Feature appear on the roadmap.
Filter