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
+- **Investigation**: Is the severity correct? Should a milestone be assigned to it? When to assign this to a developer, and who they are?
-  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
+
 *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
+## Investigation
-coordinators. The report priority is confirmed / updated and its quality
+
+*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
+* For high severity issues this is when developers are assigned and
-coordinators. An assigned bug is a clear statement that the issue will
+milestones are encouraged to be set.
-be worked on soon.
+
+* 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.
 

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
+  - Assign an initial severity based on how critical the bug is (add the
-    corresponding `Priority >` label), also see [Bug Triaging
+    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

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:**
 

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: 
+

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
+if severity 1 issues (high severity bugs) are found. When the corrective
-release is agreed on, however, severity 2 (high priority and normal
+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

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.
 

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.
   <br/><br/>
-  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.
   </td>
   <td markdown>`blender-v{VERSION}-release`</td>
@@ -104,7 +104,7 @@ only) while Blender 4.1 is in Alpha (open for new features).
   Release candidate and release builds are made.
   <br/><br/>
   Developers spend a short time 5 days/week with an eye in the tracker for any
-  unexpected high priority regression.
+  unexpected high severity regression.
   </td>
   <td markdown>`blender-v{VERSION}-release`</td>
   <td>Release Candidate</td>