Methodology

Definition of done

An entry MUST NOT be done until a stable release contains OSC 7501 support. A stable release is a release that the default install or update method delivers. If OSC 7501 support is off by default, the entry is done and MUST have a note that tells how to enable support; any done entry with other limits, such as a different id limit, SHOULD also have a note. The source MUST be the release or changelog.

For a closed-source tool, official documentation or a changelog that names OSC 7501 MAY stand in for a stable release.

Definition of working

A pre-release, beta or nightly build that requires explicit user opt-in MUST have the state working, not done. Open PRs, and merged code that is not yet in any release, also have the state working. For closed-source tools, proofs of concept and announcements SHOULD have the state working. The source MUST be the PR or announcement.

Definition of blocked

An entry MUST have the state blocked if an attempt to add OSC 7501 support stopped. If a maintainer refused to add it, the entry MUST have the state error instead. The source MUST be the closed PR or other stopped attempt.

Definition of idle

An entry MUST have the state idle if no work on OSC 7501 support exists, or only a feature request. If a request exists, the source MUST be that request.

Definition of error

An entry MUST have the state error if a maintainer refused to add OSC 7501 support, or closed the request as not planned. The source MUST be the issue or comment that shows this decision.

The verdict

Each side MUST have one verdict word. The word comes from the score of that side. Libraries and engines MUST NOT count toward the score.

score = (done + ½ × working) ÷ featured entries

A working entry counts toward the score because it shows that support is coming. Thus the verdict can change before a release. The entry counts as half because users cannot use it yet.

Programs and terminals

This site uses the terms program and terminal as the spec defines them.

If a library or engine helps a program send reports, it is under programs. If it helps a terminal keep the reports, it is under terminals. Libraries and engines MUST NOT count toward the verdict, because end users do not use them directly.

Featured entries

An entry is featured if its project has 1,000 or more GitHub stars, or if a major vendor makes it. Non-featured entries overflow into “+ N more” at the end of their group. Maintainers MAY feature an entry manually.

Spec revisions

OSC 7501 is at its fourth revision, and more revisions are likely. Each entry MUST record the spec revision of its last check. A new revision MUST NOT change the state of an entry. If a new revision affects an entry, that entry SHOULD get a note. The revision history of the spec has the details.

Weekly checks

Each Monday, a GitHub Action finds new PRs and issues that mention OSC 7501. The action also compares each working entry with the latest release of its project. The action puts all findings into one PR. A person MUST review that PR before the data changes.

Each entry shows the date of its last check. If the action cannot follow the last history block of an entry, a person SHOULD check that entry manually at least every 30 days. The action can follow a PR, an issue, a commit, or a release in the GitHub repo of the project. If a featured entry changes state, the change shows in the Atom feed.

Data sources

The first list came from awesome-osc7501 by hyeebeen. We checked the featured entries against primary sources. Like that list, our data is CC0. /data.json has every entry and its history.