Process/Help Triaging Bugs

How to help triaging bugs?

There are many ways in which users can help developers to improve Blender. Unfortunately, many of those increase the workload of the existing developers. That is not to say, that it is bad to report bugs or make feature requests. But, since the number of users is much larger than the number of developers, this can be overwhelming.

This document will explain how every Blender user can help reduce "wasted" developer time. With "wasted" I mean, that this time produces very little value relative to the time spent.


Where are the bug reports?

On the front page of are Recent Tasks. Most of these tasks are bug reports that have been created lately.

Most relevant bugs are in the BF Blender project. A list with most existing reports can be found here.

I've found the reports, what next?

Every report has a specific priority (although the term priority can be a bit misleading). The priority is indicated by the color of the line or icon next to the report. The most important priorities are these:

  • Needs Triage by Developer: Initial state of every report.
  • Needs Information from User: The bug cannot be reproduced with the given amount of information.
  • Waiting for Developer to Reproduce: It looks like this is a valid report, the report has been assigned to a developer to follow up on, but it has not been reproduced yet (possibly due to specific hardware requirements).
  • Confirmed, xxx: The report has been reproduced by a developer, assigned a priority and the bug should be fixed at some point.

Depending on the current priority, you can do different things.

Needs Triage by Developer

  • Check that the report contains the relevant system information (click on Help -> Report a Bug in Blender to see what is necessary).
  • Check that the used Blender version is somewhat recent. Ideally, the most recent version.
  • Check if you can easily understand the bug, based on the report.
  • Check if you can reproduce the bug yourself, given the steps explained in the report.
  • If any information is missing, set the priority of the report to Needs Information from User and explain what information is missing. Also encourage that the original report should be updated, instead of just adding more and more comments.
  • If there is nearly no information at all in the report (e.g. only the title), the report can be closed as invalid. Post a comment like "Please create a new report that contains all the information the template asks for."
  • If the information is all there, but you don't understand the bug, you can leave the priority as is. Furthermore, you should ask if the person, who created the report, can give a more concise explanation (short, well formatted). Also ask for additional screenshots, a .blend file or a .gif file showing the issue.
  • If the bug is easily understandable, but you cannot reproduce it yourself, either ask for better reproduction steps, or leave the report for a developer to triage.
  • If you can reproduce the bug in the newest version, comment in the report but don't change the priority to confirmed yet. Leave this to a developer who can set the appropriate priority and assign the bug to the relevant developer.
  • If you can reproduce the bug, but it is quite difficult or the file is large and complex, try to find an easier way to reproduce it.

Needs Information from User

If you think you experience the same bug, post the missing information and set the priority back to Needs Triage by Developer.

Waiting for Developer to Reproduce

If you can reproduce the bug on your machine, post the OS, hardware and driver versions you use in the thread (if they haven't been mentioned before). Additionally, you can try to come up with easier reproduction steps, if the problem does not seem to be hardware dependent.

Confirmed, xxx

At this state you can still add easier reproduction steps.

The Perfect Bug Report

The steps explained above hopefully end up in bug reports that developers can easily work with. An ideal bug report should check the following boxes:

  • The title describes the problem in a short and concise way.
  • All necessary system information is given.
  • The broken (and optionally working) Blender version is given.
  • After looking 10 seconds at the report, it should be obvious that the bug is real (without opening Blender, even when opening the report on a phone). Images or short screen casts can help a lot.
  • The bug can be reproduced easily with a given .blend file (ideally, the developer only has to do zero or one clicks once the .blend file is open).
  • A .blend file with the bug can easily be build from the default startup file.
  • All relevant information is given in the top most post.

If any of these boxes is not checked when a developer tries to understand the report, some time will be wasted.