# Firefox WebGPU Bugzilla Priorities

Bugs in the "Graphics: WebGPU" component assign "Priority" values based on criteria tailored for our pre-release burn-down process.

Because WebGPU isn't enabled in Firefox beta or release, S1 and S2 severities on WebGPU bugs draw unwarranted attention from other parts of Mozilla. To better communicate these bugs' significance, WebGPU bugs will use S4 (or possibly S3), and the team will use the Priority values below as we prepare WebGPU for release.

Mozilla Central work is tracked with Bugzilla, while wgpu work is tracked on GitHub. We use the [Firefox Triage](https://github.com/orgs/gfx-rs/projects/7/views/5) GitHub project for prioritizing wgpu work, and Bugzilla's Priority field for prioritizing Mozilla Central work.

Unfortunately, Bugzilla's priorities are more restricted than a GitHub Project's, so the scales are slightly different.

When descriptions overlap, higher priorities shadow lower priorities.

- GitHub **P0**, Bugzilla **P1**:
- potentially exploitable crashes (i.e., not panics)
- fuzzblockers, and anything else that would prevent us from seeing potentially exploitable crashes
- GitHub **P1**, Bugzilla **P1**:
- Blockers for general use
- CTS impact widespread enough that it obscures other issues
- **P2** (both):
- Incorrect implemented functionality. Panics or wrong results.
- bugs in upstream CTS (doesn't correspond to spec)
- Poor diagnostics that impede Mozilla development.
- Performance is catastrophically poor.
- WebGPU work causes Firefox performance regressions *outside* WebGPU.
- Mochitest failures.
- **P3** (both):
- Unimplemented core functionality.
- popular demos
- Incorrect but tolerable behavior.
- High-frequency intermittents: >= 10/week
- **P4** (both):
- New fuzzers
- Missing optional functionality.
- Poor diagnostics that impede users.
- Low-frequency Intermittents < 10/week
- GitHub **refactor**, Bugzilla **P5**:
- quality of implementation is poor
- GitHub **performance**, Bugzilla **P5**:
- performance is poor