About this maintenance tracker

First, issues and other contributions are always welcome through our Github repository.

This tool scans the Github repositories for the browser specifications from browser-specs and finds issues and PRs that have been waiting for action for longer than they should have. (We generally use "issue" to refer to both issues and PRs.) We infer a priority for each issue. Issues can also be in a few other categories like "being on a WG's agenda" or "needing their resolution to be edited into the specification".

We then assign Service Level Objectives (SLOs) depending on the priority or membership in other categories. For a priority, the target is generally resolving the whole issue, while for the other categories, it's just leaving that particular category. Generally a specification's working group or editors are responsible for making sure issues are resolved within their SLOs, but it's important to note that there are no consequences for violating an SLO. The issue just gets listed in the appropriate place on this website.

Finally, in addition to this human-readable website, we expose machine-readable versions of the data in JSON and CSV formats.

Priorities

Urgent
Inferred from the Priority: Urgent label. These issues should be be resolved within .
Soon
Inferred from the Priority: Soon label. These issues should be resolved within .
Eventually
This is the default category for triaged issues, and it doesn't commit to resolving them with any particular deadline. This category is identified in 3 different ways:
  • If a repository has configured a per-repository triage predicate, that's used. For example, the CSSWG treats issues as triaged if any label has been applied, on the theory that whoever applied the label also decided not to give the issue a higher priority.
  • The Priority: Eventually label.
  • If a repository hasn't defined the Priority: Eventually label, an issue without another priority label is counted as triaged if it's assigned to a milestone or someone other than the original author has commented.
Needs triage
All other issues need triage. Issues should be triaged within .

The Service Level Indicator for priorities (the amount of time that gets compared to the SLO) is the total amount of time the issue has had that priority or a higher one applied. When someone adds the Needs Reporter Feedback label, the SLI stops advancing until the issue author replies. The SLI for a PR also stops advancing while the PR is marked as a draft.

Other categories

The SLI for handling category membership only counts the current application of this label, unlike priorities which include previous times their label was added and then removed.

On the agenda

An issue labeled Agenda+ should be discussed and have the label removed within .

Groups should have enough meetings to keep their agendas below 25 items.

Needs edits
An issue labeled Needs Edits has a decision recorded in the issue and needs a spec editor to apply that decision to the specification. This should happen within .

Machine-readable data

We provide both a global summary of how all repositories are doing at their SLOs, and separate JSON files for each repository.

The global summary is available as both a CSV file (generated by /frontend/src/pages/slo.csv.ts) and a JSON file (with a Zod schema called SummaryJson).

Each repository page /spec-maintenance/org/repo/ has a paired /spec-maintenance/org/repo.json again with a Zod schema called RepoJson. For example, the machine-readable version of the whatwg/url triage data is at /spec-maintenance/whatwg/url.json