implement comments in PR #93

Author: mariojmdavid

content/06.quality_criteria.md

@@ -13,7 +13,7 @@ Consequently, software components are more eligible for deployment in production
 reducing the likelihood of service disruption.
 
 
-## 4.1. Code management
+## 4.1. Code handling
 
 ### 4.1.1. Code Accessibility [QC.Acc]
 
@@ -91,6 +91,59 @@ A change-based approach is accomplished with a branching model.
   * **[QC.Man02.6]** The pull/merge request description **SHOULD** make reference to the identifiers
     of the issues it is fixing (to eventually close them, either manually or automatically).
 
+### 4.1.4. Code Review [QC.Rev]
+
+Code review implies the informal, non-automated, peer review of any change in the source code
+[@https://owasp.org/www-project-code-review-guide/migrated_content]. It appears as the last step in
+the change management pipeline, once the candidate change has successfully passed over the required
+set of change-based tests.
+
+* **[QC.Rev01]** Code reviews **MUST** be done in the agreed peer review tool within the project,
+  with the following RECOMMENDED functionality:
+
+  * **[QC.Rev01.1]** Allows general and specific comments on the line or lines that need to be
+    reviewed.
+
+  * **[QC.Rev01.2]** Shows the results of the required change-based test executions.
+
+  * **[QC.Rev01.3]** Allows to prevent merges of the candidate change whenever not all the required
+    tests are successful. Exceptions to this rule cover the third-party or upstream contributions
+    which MAY use the existing mechanisms or tools for code review provided by the target software
+    project. This exception **MUST** only be allowed whenever the external revision lifecycle does
+    not interfere with the project deadlines.
+
+* **[QC.Rev02]** Code reviews **MUST** be open and collaborative, allowing external experts
+  revisions.
+
+* **[QC.Rev03]** Code reviews **SHOULD** be concise and use neutral language. The areas where the
+  reviewers MAY focus are:
+
+  * **[QC.Rev03.1]** Message description: commit message is clear, self-explanatory and describes
+    precisely the objectives being addressed.
+
+  * **[QC.Rev03.2]** Goal or scope: change is needed and/or addresses/fixes the whole set of
+    objectives.
+
+  * **[QC.Rev03.3]** Code analysis: useless statements in the code, library or modules imported but
+    never used or code style suggestions.
+
+  * **[QC.Rev03.4]** Review of required tests: check if they include tests of the changes, such as
+    tests of new features, or tests of bug fixing (regression tests), ensuring proper validation of
+    the changes.
+
+  * **[QC.Rev03.5]** Review of documentation: whether the change **SHOULD** bring along a
+    corresponding update in the documentation.
+
+* **[QC.Rev04]** Code reviews **MUST** be checked on change basis.
+
+* **[QC.Rev05]** Code reviews **SHOULD** assess the inherent security risk of the changes, ensuring
+  that the security model has not been downgraded or compromised by the changes.
+
+### 4.1.5. Semantic Versioning [QC.Ver]
+
+* **[QC.Ver01]** Semantic Versioning [@https://semver.org] specification is **RECOMMENDED** for
+  tagging the production releases.
+
 ## 4.2. Files and documents
 
 ### 4.2.1. Licensing [QC.Lic]
@@ -322,64 +375,9 @@ especially effective at the source code level.
 * **[QC.Sec04]** World-writable files or directories **MUST NOT** be present in the product’s
   configuration or logging locations.
 
-## 4.4. Code release
-
-### 4.4.1. Semantic Versioning [QC.Ver]
-
-* **[QC.Ver01]** Semantic Versioning [@https://semver.org] specification is **RECOMMENDED** for
-  tagging the production releases.
-
-### 4.4.2. Code Review [QC.Rev]
-
-Code review implies the informal, non-automated, peer review of any change in the source code
-[@https://owasp.org/www-project-code-review-guide/migrated_content]. It appears as the last step in
-the change management pipeline, once the candidate change has successfully passed over the required
-set of change-based tests.
-
-* **[QC.Rev01]** Code reviews **MUST** be done in the agreed peer review tool within the project,
-  with the following RECOMMENDED functionality:
-
-  * **[QC.Rev01.1]** Allows general and specific comments on the line or lines that need to be
-    reviewed.
-
-  * **[QC.Rev01.2]** Shows the results of the required change-based test executions.
-
-  * **[QC.Rev01.3]** Allows to prevent merges of the candidate change whenever not all the required
-    tests are successful. Exceptions to this rule cover the third-party or upstream contributions
-    which MAY use the existing mechanisms or tools for code review provided by the target software
-    project. This exception **MUST** only be allowed whenever the external revision lifecycle does
-    not interfere with the project deadlines.
-
-* **[QC.Rev02]** Code reviews **MUST** be open and collaborative, allowing external experts
-  revisions.
-
-* **[QC.Rev03]** Code reviews **SHOULD** be concise and use neutral language. The areas where the
-  reviewers MAY focus are:
-
-  * **[QC.Rev03.1]** Message description: commit message is clear, self-explanatory and describes
-    precisely the objectives being addressed.
-
-  * **[QC.Rev03.2]** Goal or scope: change is needed and/or addresses/fixes the whole set of
-    objectives.
-
-  * **[QC.Rev03.3]** Code analysis: useless statements in the code, library or modules imported but
-    never used or code style suggestions.
-
-  * **[QC.Rev03.4]** Review of required tests: check if they include tests of the changes, such as
-    tests of new features, or tests of bug fixing (regression tests), ensuring proper validation of
-    the changes.
-
-  * **[QC.Rev03.5]** Review of documentation: whether the change **SHOULD** bring along a
-    corresponding update in the documentation.
-
-* **[QC.Rev04]** Code reviews **MUST** be checked on change basis.
-
-* **[QC.Rev05]** Code reviews **SHOULD** assess the inherent security risk of the changes, ensuring
-  that the security model has not been downgraded or compromised by the changes.
-
-## 4.5. Delivery
+## 4.4. Delivery
 
-### 4.5.1. Automated Delivery [QC.Del]
+### 4.4.1. Automated Delivery [QC.Del]
 
 Automated delivery comprises the build of Software into an artifact, its upload/registration into a
 public repository of such artifacts and notification of the success of the process.
@@ -396,9 +394,9 @@ public repository of such artifacts and notification of the success of the proce
 * **[QC.Del03]** Upon success of the previous (**QC.Del02**) process, a notification **MUST** be
   sent to pre-defined parties such as the main developer or team.
 
-## 4.6. Deployment
+## 4.5. Deployment
 
-### 4.6.1. Automated Deployment [QC.Dep]
+### 4.5.1. Automated Deployment [QC.Dep]
 
 * **[QC.Dep01]** Production-ready code **MUST** be deployed as a workable system with the minimal
   user or system administrator interaction leveraging software configuration management (SCM) tools.