Bug Priorities and Status #71418

New Issue

Dalai Felinto · 2019-11-08T06:13:59+01:00

Dalai Felinto commented

2019-11-08 06:13:59 +01:00

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.

# Bug Priorities and Status This proposal intents to align bug priorities and status with [Blender triaging process ](https://wiki.blender.org/wiki/Process/A_Bugs_Life). 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.

Dalai Felinto commented

2019-11-08 06:13:59 +01:00

Added subscribers: @dfelinto, @Sergey

Paul Kotelevets commented

2019-11-08 11:39:08 +01:00

Added subscriber: @1D_Inc

Paul Kotelevets commented

2019-11-08 11:39:08 +01:00

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.

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

noki paike commented

2019-11-08 13:06:06 +01:00

Added subscriber: @nokipaike

noki paike commented

2019-11-08 13:06:06 +01:00

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

Philipp Oeser commented

2019-11-08 13:18:59 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2019-11-08 13:18:59 +01:00

In #71418#807908, @nokipaike wrote:
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?

> In #71418#807908, @nokipaike wrote: > 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?

noki paike commented

2019-11-08 22:30:54 +01:00

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

gbayliss commented

2019-11-09 12:54:21 +01:00

Added subscriber: @merlinstail

gbayliss commented

2019-11-09 12:54:21 +01:00

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.

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.

Paul Kotelevets commented

2019-11-11 11:15:53 +01:00

In #71418#808264, @merlinstail wrote:
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.

In #71418#807926, @lichtwerk wrote:
We try to direct them to devtalk

Yes, they do.

> In #71418#808264, @merlinstail wrote: >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. > In #71418#807926, @lichtwerk wrote: > We try to direct them to devtalk Yes, they do.

Maciej Jutrzenka commented

2019-11-26 18:04:50 +01:00

Added subscriber: @MaciejJutrzenka

Maciej Jutrzenka commented

2019-11-26 18:04:50 +01:00

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

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

Robert Guetzkow commented

2019-11-29 01:22:30 +01:00

Added subscriber: @rjg

Robert Guetzkow commented

2019-11-29 01:44:38 +01:00

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

Evan Wilson commented

2019-11-29 03:58:35 +01:00

Added subscriber: @EAW

Maciej Jutrzenka commented

2019-12-07 19:36:40 +01:00

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

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 commented

2020-06-24 11:16:55 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Dalai Felinto closed this issue

2020-06-24 11:16:55 +02:00

Dalai Felinto self-assigned this 2020-06-24 11:16:55 +02:00

Dalai Felinto commented

2020-06-24 11:16:56 +02:00

Fully implemented since late December 2019.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Bug Priorities and Status #71418

Bug Priorities and Status