diff --git a/docs/handbook/bug_reports/a_bugs_life.md b/docs/handbook/bug_reports/a_bugs_life.md index 88249872..9e6b4bbf 100644 --- a/docs/handbook/bug_reports/a_bugs_life.md +++ b/docs/handbook/bug_reports/a_bugs_life.md @@ -3,31 +3,42 @@ There are different stages of the life of a bug. Each of them requires a different skill set, responsibility and dedicated time: -![](../../images/A_Bug's_Life.png) +```mermaid + flowchart LR + Triaging --> Investigation --> Fix +``` - **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? +- **Investigation**: Is the severity correct? Should a milestone be assigned to it? 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 + *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. +estimated severity. -*Classification* is a job for the module owners and development -coordinators. The report priority is confirmed / updated and its quality +## Investigation + +*Investigation* is a job for the module owners and development +coordinators. The bug severity is confirmed or 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 (or ToDo even). -*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. +* For high severity issues this is when developers are assigned and +milestones are encouraged to be set. + +* An assigned bug is a clear statement that the issue is on the module's +radar and will be worked on soon. + +* If a high severity bug won't be tackled soon, it should set a milestone to a +future release, ideally with some explanation on the bug report. + +## Fix *Fix* includes the development time as well as sending the patch for review and having it fully merged in the code base. @@ -78,7 +89,7 @@ label). To help discoverability in the case the issue touches multiple areas in blender, (multiple) `Interest >` tags can still be added optionally. -4 - Initial priority is set (for a list of Priority Clarifications see +4 - Initial severity is set (for a list of Severity Clarifications see the [bug triaging playbook](triaging_playbook.md), also check there what to do if the issue turns out to be a recent regression). @@ -90,7 +101,7 @@ Classification) with this issue). 6 - Bug tested with older Blenders (e.g., 2.79) to determine if this is -a regression (this influences the initial priority as well, see above). +a regression (this influences the initial severity as well, see above). 7 - A simple example file (with the font packed) was created. diff --git a/docs/handbook/bug_reports/help_triaging_bugs.md b/docs/handbook/bug_reports/help_triaging_bugs.md index abd50516..3d01e715 100644 --- a/docs/handbook/bug_reports/help_triaging_bugs.md +++ b/docs/handbook/bug_reports/help_triaging_bugs.md @@ -74,7 +74,7 @@ the `Status >` label next to the report. The most important status are these: unusual behavior can be reproduced by the triaging team, but it is unclear whether this is a known limitation or bug. - Confirmed: The report has been reproduced by triagers, assigned a - priority and module label and the bug should be fixed at some point. + severity and module label and the bug should be fixed at some point. Depending on the current status, you can do different things. @@ -138,8 +138,8 @@ Depending on the current status, you can do different things. label). To help discoverability in the case the issue touches multiple areas in blender, (multiple) `Interest >` tags can still be added optionally. - - Assign an initial priority based on the severity of the bug (add the - corresponding `Priority >` label), also see [Bug Triaging + - Assign an initial severity based on how critical the bug is (add the + corresponding `Severity >` label), also see [Bug Triaging Playbook](triaging_playbook.md)). - Change the `Status >` label to `Status > **Confirmed**`. - If you are part of the triaging team, the issue is reproducible, the diff --git a/docs/handbook/bug_reports/triaging_playbook.md b/docs/handbook/bug_reports/triaging_playbook.md index 94853355..4e6db8a7 100644 --- a/docs/handbook/bug_reports/triaging_playbook.md +++ b/docs/handbook/bug_reports/triaging_playbook.md @@ -22,7 +22,7 @@ copy/pasted from this page instead for now. The actions and example tasks are only present here on the wiki. -> NOTE: **Priority Clarifications** +> NOTE: **Severity Clarifications** > > - _Unbreak Now!_ - Leave for [module owners](), but contact the responsible person on [blender.chat](https://blender.chat) if you think you @@ -592,7 +592,7 @@ or debug modes. **Example:** [\#69810](http://developer.blender.org/T69810), [\#68586](http://developer.blender.org/T68586) -**Note 1:** Change the `Priority >` label to `Priority > **High**` +**Note 1:** Change the `Severity >` label to `Severity > **High**` unless it is a really obscure bug. If you think it should be **Unbreak Now!** contact the corresponding module developers or one of our coordinators. @@ -685,7 +685,7 @@ example tasks). - If the file is complex enough that a developer would need to spend time further simplifying it, ask user to help. - If the issue was introduced within approximately the last 6 months - this is a regression so change the `Priority >` label to `Priority > **High**`. + this is a regression so change the `Severity >` label to `Severity > **High**`. **Advanced Action:** diff --git a/docs/handbook/guidelines/design/examples/npr.md b/docs/handbook/guidelines/design/examples/npr.md new file mode 100644 index 00000000..b16f6943 --- /dev/null +++ b/docs/handbook/guidelines/design/examples/npr.md @@ -0,0 +1,14 @@ +# Example NPR + +Let's look at NPR for example. At the heart of the problem users want to create NPR art. +Not-restricted to, but commonly Anime or cartoon-style rendering. + +You can start by collecting examples of intended final artworks (already possible or not) of different NPR styles. + +* Use cases: Collect NPR examples +* Audience: Define the audience (technical artists? beginners?). If it helps think of personas, or elect some real artists to be used as core audience. Try to classify the different use cases for the different audiences. +* Prioritization: + * Elect the most important use case (e.g., ) + +* More use cases: + diff --git a/docs/handbook/release_process/lts.md b/docs/handbook/release_process/lts.md index f6081d91..269a7050 100644 --- a/docs/handbook/release_process/lts.md +++ b/docs/handbook/release_process/lts.md @@ -8,8 +8,8 @@ which will provide critical fixes throughout a 2-year time span. ## Criteria to determine what to be ported Currently, for non-LTS releases, Blender only has a corrective release -if severity 1 issues (high priority bugs) are found. When the corrective -release is agreed on, however, severity 2 (high priority and normal +if severity 1 issues (high severity bugs) are found. When the corrective +release is agreed on, however, severity 2 (high severity and normal bugs) fixes are ported along. For the LTS releases, a more limited policy would apply (only porting diff --git a/docs/handbook/release_process/release_checklist/index.md b/docs/handbook/release_process/release_checklist/index.md index 3b471a18..108e51ef 100644 --- a/docs/handbook/release_process/release_checklist/index.md +++ b/docs/handbook/release_process/release_checklist/index.md @@ -293,7 +293,7 @@ too, see `create_release_notes.py`) - Backports should be done one week before the LTS release, to give some time for testing. ### Releases -- LTS releases are done once a month, even if there is just one (high priority) bugfix. +- LTS releases are done once a month, even if there is just one (high severity) bugfix. - Backports are to be done by the second Tuesday of the month. - Release is on the third Tuesday of the month. diff --git a/docs/handbook/release_process/release_cycle.md b/docs/handbook/release_process/release_cycle.md index c94f7b68..c95a5b75 100644 --- a/docs/handbook/release_process/release_cycle.md +++ b/docs/handbook/release_process/release_cycle.md @@ -88,7 +88,7 @@ only) while Blender 4.1 is in Alpha (open for new features). The Python API remains stable during this phase, so add-ons have time to update before the release.

- High priority bugs dictate how much time developers will spend in the tracker + High severity bugs dictate how much time developers will spend in the tracker as opposed to new features for the next release. `blender-v{VERSION}-release` @@ -104,7 +104,7 @@ only) while Blender 4.1 is in Alpha (open for new features). Release candidate and release builds are made.

Developers spend a short time 5 days/week with an eye in the tracker for any - unexpected high priority regression. + unexpected high severity regression. `blender-v{VERSION}-release` Release Candidate diff --git a/docs/images/A_Bug's_Life.png b/docs/images/A_Bug's_Life.png deleted file mode 100644 index 94200bbb..00000000 --- a/docs/images/A_Bug's_Life.png +++ /dev/null @@ -1,3 +0,0 @@ -version https://git-lfs.github.com/spec/v1 -oid sha256:c4f43e36e4d076cbabf2e7031c7c8fbd225b2275919b87d8d23886d8ecfed828 -size 5218