8 Issue Guidelines
Joshua M. Boniface edited this page 5 years ago

Issues should detail one of three things:

  1. A software bug with Jellyfin.
  2. A feature request or suggestion.
  3. A task to be done with Jellyfin.

All other discussions should be directed towards one of the Jellyfin Riot channels, or our subreddit.

Opening an issue

When writing an issue, please ensure you capture as much relevant detail as possible - this is very important to assist in troubleshooting and triaging/investigating the issue. Some useful elements include:

  • How you installed Jellyfin (upgrade/fresh install)
  • What platform and operating system you're using (Debian, Arch, Docker, etc.)
  • What you were doing that caused the error or issue to appear
  • Any relevant log output
  • Any non-standard configurations you use

To assist in triaging, if you know which label(s) should applied to your issue, please add them to the beginning of the issue name in square brackes, like this: "[feature][UI] Add the widget to the front panel". Issues will be triaged in time by the administrative team, and these flags will be removed from the title and issue labels added. This is required due to GitHub's permission system. The list of labels can be found below.

Searching for issues and upvoting

Before opening an issue, please search the existing issues to see if a similar problem or feature request has been reported. Duplicate issues clutter the repository and should be avoided.

If you do find an issue that matches, or closely matches, your issue, please make use of the 👍 reaction to confirm the issue also affects you or that you support the feature request. If you wish, add a comment as well describing your version of the issue or feature usecase.

If the existing issue is closed, please read through it to see if the accepted workaround(s) apply to your case. If not, leave a comment and the issue will be reopened. Note that, since PRs go into dev first but releases are built from master, an issue's fix won't be immediately available in the official sources, but will be included in the next release.

Once you're ready to open an issue, please see this page!

Issue Labels

Jellyfin features a number of issue labels to assist in triaging and managing issues. Users cannot assign these themselves due to GitHub's permissions; they will be added by an administrative team member during triaging.

Category Labels

These first three labels are broad categories for which part of Jellyfin the issue affects:

  • UI: An issue that mainly relates to the UI frontend code.
  • Backend: An issue that mainly relates to the server backend code.
  • build/platform: An issue that mainly relates to building or packaging the project.

Criticality Labels

These labels help determine how critical an issue is:

  • regression: An issue in need of immediate attention due to a regression from the last build.
  • bug: A bug in the code that affects normal usage.
  • enhancement: An issue that requests a modification of an existing feature.
  • feature: An issue that requests a new feature not present in Jellyfin.

Management Labels

These labels help assist in managing the project and direction:

  • Good first issue: Something that should be very straightforward to do, and is a great place to get started.
  • help wanted: An issue that currently has no clear expert within the project and could use outside assistance.
  • roadmap: A meta-issue related to the future roadmap of the project.
  • documentation: An issue related to the documentation of the project.
  • fork: An issue related to the forking from Emby.

PR Labels

These labels apply only to Pull Requests for administrative purposes:

  • WIP: A Work-in-progress PR that is not yet ready to be merged, usually blocked by further work from the contributor or a testing requirement.
  • requires testing: A PR that has not been tested in a live environment yet. Any major backend-affecting PRs should be tested before being merged to avoid regressions.