Process/A Bugs Life

The Life of a Bug

There are different stages of the life of a bug. Each of them requires a different skill set, responsibility and dedicated time:

A Bug's Life.png
  • Triaging: Is this a valid bug, complying to our guideline, make it ready for a developer to fix.
  • Classification: What is the definitive priority? Do we really have all we need to assign it? Will someone work on this in the upcoming 6 months?
  • Assignment: When to assign this to a developer, and who they are?
  • Fix: Where added value happens, where we should spend most of our development resources.

Triaging should be done by a dedicated team, isolating the rest of the development team from the inflow of tasks in our bug submission platform. Any bug fully triaged should be either closed or tagged to a module (not assigned to a developer). Any confirmed bug should have an estimated priority.

Classification is a job for the module owners and development coordinators. The report priority is confirmed / updated and its quality is confirmed (or rejected back to triaging). This is also when we determine if this is a bug or a known issue.

Assignment is a job for the module owners and development coordinators. An assigned bug is a clear statement that the issue will be worked on soon.

Fix includes the development time as well as sending the patch for review and having it fully merged in the code base.

A Bug is Born

A user went over the instructions on how to make a good bug report, and put time and effort in making the most complete comprehensive report possible. This is only the start of the conversation though.

In this example we have a pretty good bug report, above the average even. In fact more incomplete bug reports would be sent back to the reports asking for more information.


The team of Bug triagers will now dissect the problem following a strict guideline on how to handle the report gracefully. After some investigation and back and forth, the report can be updated so it is ready to be fixed. It is not so trivial to do a final treatment to the bug report, so let's continue with this example.

A Fully Triaged Bug

This right here is a bug report with all the necessary information for its fix condensed right in the bug description. Let's take a closer look at what changed from the original report to the final one:

Bug Triaged Highlight.png

1 - Title updated to give a more precise description of the problem.

2 - Initial priority is set.

3 - Unnecessary information removed (the graphic card has nothing to do with this issue).

4 - Bug tested with older Blenders (e.g., 2.79) to determine if this is a regression.

5 - A simple example file (with the font packed) was created.

6 - The corresponding module is tagged.

7 - No one is assigned to it. It is not a job for the triager to assign bugs to developers.

8 - Clear reference of the expected behaviour.

9 - Added some developer notes that summarize the discussion in the task.

10 - Removed yet more irrelevant information.

Description and Title Updates
We welcome all the community to help with triaging. However not everyone has the edit rights to update the bug report. This is ok, someone with edit access will take care of updating the report before tagging a module, which is when we consider the triaging complete.