Skip to content

Issue Management

Frank Dana edited this page Oct 15, 2019 · 7 revisions

The following document describes the issue management approach used by OpenShot developers to manage the hundreds of issues we receive. OpenShot users far outnumber our developers, and the goal of this approach is to keep things simple, organized, and easy for both users and contributors.

Goals

  • High-quality, useful issues
  • Organized, labeled issues
  • No duplicate issues
  • Increased visibility for "hot" issues (affecting a large # of users)
  • Increased visibility for "newcomer" issues (easy to fix bugs for new contributors)

Basic Labels

  • bug (A reproducible issue which is clearly broken)
  • duplicate (Contains the same bug or enhancement of an existing active issue)
  • enhancement (An idea, wish, or feature request)
  • needs info (A low-quality or non-reproducible issue, lacking specifics, logs, and/or steps to reproduce, or requires more info from the user)
  • question (A general question about how to use OpenShot or about the project). However, it is recommended that users visit our Reddit community for general questions.

Additional Labels

  • good first issue (A high-quality, well understood, and easy to fix issue. Perfect for new contributors)
  • help wanted (This issue needs additional developer support, or specialized skills to help debug or troubleshoot.)
  • hot (An issue which affects many users and needs to be fixed immediately)
  • bounty (A high-quality issue which OpenShot Studios is willing to offer a cash payment for a solution. This tag is only valid if added by Jonathan Thomas, and details of the bounty are included in the comments of the issue.)
  • closer (This PR fixes one or more reported Issues)
  • pending (A PR has been submitted to fix the issue)
  • needs testing (Issue or PR needs some help testing from the community or other developers)
  • workaround (The issue has at least a partial workaround)

Optional Category Labels

  • cloud (Issues relating to OpenShot Cloud API)
  • docs (Bad or missing help texts / documentation)
  • interface (GUI / user interface issues, i.e. windows, buttons, scrolling, pop-ups, etc...)
  • libopenshot (Issues or PRs that involve the libopenshot C++ backend)
  • media-handling (Issues related to video/audio file processing & playback)
  • OS:Linux (Issues specific to the Linux operating system)
  • OS:MacOS (Issues specific to the MacOS operating system)
  • OS:Windows (Issues specific to the Windows operating system)
  • preferences (Issues involving the OpenShot preferences data or interface)
  • showcase (Some cool videos that the users have made using OpenShot)

Use Milestones (for each release)

Milestones are used to track issues targeted for each release. All issues and pull requests fixed in a release cycle, should be targeted for the current milestone. This helps keep track of what was completed in each release, and is also useful for planning future releases.

  • v2.4.1
  • v2.5.0
  • v3.0

Report a Bug

To help improve the quality of GitHub issues reported, we have created a new bug reporting website: https://www.openshot.org/issues/new/. This website helps search for duplicate issues, uploads and searches log files for clues, and helps format the GitHub issue.

Workflow:

  • User opens Issue on openshot.org or GitHub
    • Issues created using GitHub Issue Templates are auto-labeled "Bug", "Feature Request", or "Question", corresponding to the template chosen
    • Issues created from openshot.org, are auto-labeled "Bug"
  • Developers scan daily for "new" or "unlabeled" issues
    • Correct bug/enhancement/question label (if needed)
    • If there are no steps to reproduce or no log file, mark as 'needs info'
  • Auto-Close issues marked 'needs info' if user does not respond within 7 days
  • Fix bug, create new branch, share PR, merge into develop branch (See Becoming a Developer)
  • Mark bug as Closed
Clone this wiki locally