Kdenlive/Workgroup/Triaging

Some parts of this page are based on https://krita.org/en/item/ways-to-help-krita-bug-triaging/

Introduction

Now that there are so many Kdenlive users, and many new features, we’re getting lots of bug reports. And a lot of those bugs are specific to the reporter’s system. Or so it seems. Some bugs only happen with certain combinations of hardware, operating system, other installed software. Some bugs happen for everyone, but are rare because not that many people use a feature, and some bugs suddenly turn up because we’re human and we make mistakes.

And every report needs to be read, preferably by several people, who can try to determine:

whether they can trigger the bug — and in that case, confirm it
if they cannot understand the report, or determine that the report is incomplete — and in that case, ask for more information
if the bug has been reported before, and if so, close the bug as a duplicate of the earlier report.

The goal is to save developers from doing this, which helps them fix bugs more quickly and use there time to develop new features for Kdenlive instead of doing bug triage. That’s where you come in! If you’re a reasonably experienced Kdenlive user and want to help out, here’s how to get ready and set up! Help with bug triaging is a real and lasting contribution to Kdenlive! If you benefit from the work others did on Kdenlive it is a great opportunity to give something back to the project!

Kdenlive uses the KDE Bugtracker on https://bugs.kde.org powered by Bugzilla

Overview on Kdenlive Bugs

Open bug overview based on Status (REPORTED bugs need triage)

Overview of open bugs based on Component and Keyword

Chart: bugs status over time

Chart: Open bugs over time (only accessible with "contributor" permissions)

Preperations

Before you can start you need to create an account on the bug tracker (Note: the bug tracker is not connected to KDE Identity / MyKDE): Go to https://bugs.kde.org and select Create new Account. Complete the registration forms, and click on the confirmation link in the email you get sent.

After you created your account you should read the general instructions on KDE bug triaging at Guidelines and HOWTOs/Bug triaging

Triaging

Beside the info you got in the KDE Bug Triage Guidlines in the previous section, this chapter will give you a quick overview and some further instructions for bug triaging in the context of Kdenlive.

These are the basic steps for triaging a bug:

Thank the reporter for her/his bug report. Keep in mind that reporting a bug can be scary enough, especially for new users, and that it is also a certain amount of effort. Bug reporters are awesome contributors, too!

Check if the severity is “wish”, if so, see section below
Check whether it’s a duplicate, if so, close it via the Mark as Duplicate function
Check whether the subject makes sense and mentions the most pertinent information, if not, update it
Check whether the version isn’t too old. We don’t try to fix bugs for version older than a year. If a bug is reported for an old version the bug should be marked as NEEDSINFO and the user asked to try to reproduce the issue with the latest version
Try to reproduce the bug:
- If there is not enough information to reproduce the bug: set the bug to NEEDSINFO and ask the reporter for more information.
- If it’s easy to reproduce: add any notes on how you reproduced the issue, on your distribution, version of Kdenlive, hardware and set the bug to CONFIRMED if you can reproduce.
- You cannot reproduce the bug even though the report is complete and you can follow all the steps: Note that you cannot reproduce the bug and ask the reporter to reproduce. Set the bug to NEEDSINFO and wait. If the reporter answers that they cannot reproduce either, close the bug as WORKSFORME. Keep in mind that a bug can be related to packaging issues with a specific package type (Flatpak, Appimage,…), a specific OS or other factors of the users environment. If you can not reproduce a bug this doesn't necessarily mean the bug does not exist.
- You cannot reproduce the bug but suspect that that’s because it’s already fixed: add a comment to the bug but don’t change the status yet. You suspect that the reporter simply doesn’t realize that they are using Kdenlive in the wrong way, for instance by mixing 48kHz & 44.1kHz audio. Point the reporter to the manual and close with NEEDSINFO. If the reporter replies that that is the case, we can close the bug

You can mark bugs with any of the 4 Tag types for better sorting/filtering for further "processing" with the following "meaning":

Flag: “Low_hanging” for junior jobs

Flag: “Brainstorm” where you are not sure if this bug is really fixed or is still a bug or a heavy bug (not a junior job)

Flag: “MOVIT” for all GPU issues

Flag: “timeline_corruption” for all timeline issues.

Special Case: Feature Requests

Feature request should be marked as CONFIRMED as long as:

It is conveyed clearly what the feature should do and how it would be useful
The feature has not already been implemented in new version since the report was written (mark as RESOLVED FIXED in this case)
The feature fits to the general nature of Kdenlive (e.g. don't accept requests like "Add 3D modeling support for Character animation")

Tips and Tricks

Get Notifications on New Bugs

Open a list of all UNCONFIRMED Kdenlive bugs, scroll down to the end of the list and click on to add a feed of new Kdenlive bugs to your atom feed reader.

Better Portrayal for Buglists

Go to the Bugtracker: Bugtracker

Scroll down to the bottom and click on “Change Columns” -> add from the left window the item “Flags” and “Severity” to the right window

Click on “Change Columns” -> now you see the Flags which are set already -> click on “Flags” to get it sorted and you see all low_hanging bugs we found so far (I mean it could be a low hanging). The column “Sev” show you the “wis” for whislist and “cra” for crash as well.

</translate>