Page MenuHome

Bug Priorities and Status
Closed, ResolvedPublicDESIGN

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 Triage (open)
  • Needs Information from User (open)
  • Needs Developer to Reproduce (open)
  • Confirmed (open)
  • Resolved (closed)
  • Invalid Report (closed)
  • Duplicated (closed)

The proposed priorities are:

  • 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.

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.

i think that developers should focus on just fixing.. not haveing to spend on working out is the bug true.. or asking user what GPU he have or crap like that...

triaging is not really a common word, i would use more simple names my propose are.

  • waiting for approve - this is status that is def. when report is submited. i don't call it a bug as we don't know it that yet. i call it report.
  • Valid Report - that would be status for moderators to set when report is done correctly.. have all information.. like hardware drivers good description of bug etc.
  • Confirmed - that means that bug has been confirmed by single person. And now is wateing for developer to check and fix etc.
  • Complex Bug - that is status where moderator.. is not sure is the bug true, Some technical stuff for example this status means that the bug have to be seen by advanced developer.
  • Developer Confirmed - status that says that bug is 100% confirmed by developer.. and should be fixed in first place.
  • Work in progress - Status that says that developer is now working on fixing the bug.
  • Missing information - status that says that report has been checked by someone.. and is lacking information. that is why it dosn't have status valid report.
  • Hard to reproduce - status that says that bug requiers multiple users to try reproduce the bug.. for example it happens only on AMD GPU etc.. kind of stuff..

on top of this we could have as we have now priorities..

however i would just rate it from. 0 to 5 for example or just very low low normal medium etc..

The list of proposed status looks good. I consider the priorities suggested by @gbayliss (gbayliss) better as well.

Current problem and solution:

For example let's say Developer works on new bevel tool.. He would like to see what problems people had in past or bugs with bevel.. U can't... U can't even filter Bug based on System user is useing. not even mentioning GPU or driver. Whole bug report is just random text. with tittle.
we keep code versioning. of blender. and we ask people to give what blender they use but we don't use this information at all.. u can't even filter.. is the bug from 2.79 or 2.8 And what worse. system dosn't automaticlly provide part of code that might make bug. For example if user report Bug about bevel in 2.81.. system will show all latest changes in code about bevel.. before 2.81.. also if developer is working on bevel.. system would show all reports with bevel tag. simpe as that.

currently big % of bug reports are even fixed.. but we didn't even know this.. because a) developer dosn't know about report. b) forgot to close the bug report.
so for example if guy.. is reporting bug in 2.79 about compositor... system checks if there was any change in code in compositor section. after 2.79 if there is 0 system allow bug to be reported.. if there was some code.. system tells user.. to check with for example version 2.81... is bug still happening.. and simply dosn't allow to make report.
on top of this we could add system that ranks bug reports. for example if bug report is done by user who made 10 reports and all where confirmed by developers.. than his next bug report instantly have high priority.

Short version
-Tag bug report as much as u can. for example bug about bevel? tag: [modeling] [Bevel]
-tags only from premade list by BF.
-GPU & Driver mandatory choosen from premade list by BF
-multi stage system of report where u start with question and options.. that lead to a)possible fix b) finall report. example: Does Blender start? yes/no.. if yes.. u have another set of questions.. if no.. instructions how to attach debug log crash..

Dalai Felinto (dfelinto) closed this task as Resolved.Wed, Jun 24, 11:16 AM
Dalai Felinto (dfelinto) claimed this task.

Fully implemented since late December 2019.