Page MenuHome

Bug Priorities and Status
Open, NormalPublic

Description

Bug Priorities and Status

This proposal intents to align bug priorities and status with Blender triaging process.

Bug priorities should be distinct from status. Status should give us a snapshot of where in the bug fix flow this report is. Priorities should reflect the impact an issue has in the work of the users, not our development planning.

The proposed status are:

  • Needs triaging (open)
  • Needs user information (open)
  • Triaged (waiting for classification) (open)
  • Confirmed (i.e., classified) (open)
  • Fixed (closed)
  • Archived (closed)
  • Bad Report (closed)
  • Duplicated (closed)

The proposed priorities are:

  • Undefined - Needs a priority (by triager or module owner).
  • Unbreak Now! - Show stoppers.
  • High - Most crashes, recent regressions, or bug in a new feature.
  • Normal - Regular valid bug, can be postponed to new releases ad eternum.
  • Low - Small annoyances or glitches for which there are workarounds. Good tasks for new developers.

Conversion

Existing status:

  • Archived → Won’t Fix
  • Invalid → Bad Report
  • Resolved → Fixed
  • Open → Needs triaging / Triaged (if someone assigned)
  • Duplicated → Duplicated

Existing priorities:

  • Unbreak Now! → Unbreak Now!
  • Confirmed, High → High
  • Confirmed, Medium → Normal
  • Confirmed, Low → Low
  • Normal → If it is a bug → Normal, if not a bug, ignore.
  • Needs information from user → Status: Needs information from user; Priority Undefined.
  • Needs triage by developer → Status: Needs triaging; Priority: Undefined.
  • Waiting for developers to reproduce → Status: Needs triaging; Priority: Undefined.

Details

Type
Design

Related Objects

Event Timeline

Priorities should reflect the impact an issue has in the work of the users, not our development planning.

Sounds nice)
But here is a bug definition problem:

  • Reported issue that matches the roadmap leads to a simple definition of an issue as a bug - as software issue.
  • Reported issue that contradicts the roadmap can be both a roadmap design mistake or a misunderstanding of the roadmap by the user. So such issue can be defined as workflow issue, that may need some additional semantic clarifiactions, including cases of uses, task examples, workflow comparisons, etc. It is always hard to define.

Such system can require well-defined multy-industry semantic core to handle and observe workflow issues (priorities, problem coverage, areas of uses, etc.) to protect the roadmap or heal it from gross design mistakes.

Sometimes bug reports that are not bugs but contain useful information, could be directed to devtalk to start a discussion (providing precise information that helps the user how to do it) instead of making them lose in nothing, especially by those new users who do not they know the rules of the community.

Professionals who come from outside, and have difficulties, one of the first things they do is report a bug-issue-feedback here ...

Sometimes bug reports that are not bugs but contain useful information, could be directed to devtalk to start a discussion (providing precise information that helps the user how to do it) instead of making them lose in nothing, especially by those new users who do not they know the rules of the community.
Professionals who come from outside, and have difficulties, one of the first things they do is report a bug-issue-feedback here ...

We try to direct them to devtalk, see https://wiki.blender.org/wiki/Process/Bug_Reports/Triaging_Playbook, do you think the playbook can be improved upon?

@Philipp Oeser (lichtwerk) well, without thinking too much I would inform people of the existence of devtalk with a brief explanation of its purpose and invite them to do research on it to deepen or expand topics ....

It would be more consise to define priorities as:

None,
Low,
Medium,
High,
Critical

These are pretty standard definitions for priority, and while I appreciate that blender does things a little differently, I see no need for floral priority names.

I see no need for floral priority names.

Sounds reasonable)
Especially if to take in account workflow issues, that cannot be determined quickly, and sometimes years of production tests are needed to locate and define a problem.

We try to direct them to devtalk

Yes, they do.