TypeType Docs

Appearance

Reporting issues ​

All issues live in one place: Priveetee/TypeType.

Open everything there, whether it is about the web app, the API, or downloads, and pick the form that fits.

You never have to guess which part is at fault. If a report turns out to be backend-specific, the maintainers take it from there.

There are two ways to report:

  • Open an issue directly on GitHub, at the link above.
  • Use the in-app reporter, described below.

From inside the app ​

The quickest way to flag something is the built-in Report a bug action, for example from the action bar on the watch page. It opens a short form, and you do not need a GitHub account to use it.

You fill in just two things:

  • a category, one of Player, Audio Language, Subtitles, Interface, or Functionality,
  • a short description of what went wrong.

The app collects everything else for you. The report automatically captures the page or video you were on, your browser and language, the player state, and any recent crash logs or API errors, all gathered in the browser as you use the app. You never have to dig out technical details by hand.

When you submit, the report is saved on your instance. What happens next:

  1. The report is saved on your instance.
  2. An administrator reviews submitted reports in the Admin area.
  3. From a report, an admin can open a prefilled GitHub issue: the app builds a issues/new link for your configured repository, with the title, a prefilled body (the report and its context), the bug label, and, when GITHUB_ISSUE_TEMPLATE is set, that template. Domains are redacted from the body first, so a report never leaks where your instance is hosted.

No GitHub token is needed, the app only generates the prefilled link; the issue is created when someone submits it on GitHub.

Template vs prefilled body

GitHub does not reliably honour a prefilled body and a template in the same link, the two can override each other, and on mobile the prefilled fields may be dropped when a template exists. If you want the full prefilled report to show, leave GITHUB_ISSUE_TEMPLATE empty; if you prefer the repository's template form, keep it.

Configuration ​

Two variables decide where in-app reports point (see Configuration):

VariableDefaultMeaning
GITHUB_REPOPriveetee/TypeType-ServerRepository the prefilled issue targets
GITHUB_ISSUE_TEMPLATEbug_report_backend.mdIssue template the link selects, leave empty for none

To keep every user report in the single tracker above, point GITHUB_REPO at Priveetee/TypeType. Use your own fork instead if you run a separate tracker.

Make a report useful ​

  • Say whether you are on the main or beta channel (see Beta and main).
  • Include steps to reproduce, what you expected, and what happened.
  • For playback problems, note the video, the provider (YouTube, NicoNico, BiliBili), and the quality.
  • Check docker compose logs typetype-server for an error around the time it happened.

How issues are organised ​

Every issue is sorted with labels, so the tracker stays easy to navigate:

  • Type, what kind of report it is: bug, feature request, enhancement, documentation, or question. The in-app forms set this for you automatically.
  • Area, which part it touches: area: frontend, area: backend, area: token, or area: downloader. Maintainers add this during triage, so you never have to.
  • Priority: priority: high, priority: medium, or priority: low.

In practice, most reports are about the web app and playback, the player, playlists, subtitles, imports, and the interface, with a smaller share on the backend (extraction and the API). Reports are triaged and the large majority get fixed and closed, so a clear report really does turn into a fix.

Want to contribute? ​

Two labels are worth watching: