doc - Extended contribution documentation

---

We've updated the contribution documentation to add a bunch of new
guidelines for forming conventional commits.

---

Type: doc
Breaking: False
Doc Required: False
Backport Required: False
Part: 1/1

CONTRIBUTING.md

@@ -159,7 +159,7 @@ Type - Attributes - Summary
 
 ---
 
-Description
+Description wrapped with 75 characters word-wise
 
 ---
 
@@ -182,6 +182,10 @@ For types, you should select exactly one type from the following types:
 * `dev`: for development checkpoints (version bump, etc.)
 * `fin`: for development finish points
 * `chg`: for minor changes to previous commits
+* `int`: for continuous integration changes
+* `bkp`: for backports (an empty commit for cherry-picked commits or a full commit for non-cherry-picked backports)
+* `prj`: for project initialization
+* `pkg`: for packaging-related changes, such as Debian, PKGBUILD, Flatpak, etc.
 * `und`: for other changes that don't apply
 
 Additionally, attributes are optional and can be specified. Multiple attributes should be separated with the pipe character (`|`). However, there are special cases that you may need to handle when you're committing your changes to your pull request:
@@ -212,6 +216,38 @@ Take note that if you've set a commit that is a backport, make sure that the typ
   * `ptp`: for prototyping
   * `brk`: for breaking changes
 
+In addition to that, if you've backported a commit from a different branch or tag, you must specify this stanza directly after the description section, just like this:
+
+* For tags:
+    ```
+    The following commits or tags are used for this backport:
+      - D877EC56... [Tag 1]
+      - C6100AF1... [Tag 2]
+    ```
+* For backported commits:
+    ```
+    The following commits or tags are used for this backport:
+      - E3218765...
+      - FAE890DA7...
+      - BE2701D2...
+    ```
+
+If you want to specify a command output, you must specify the output name, the description, the command used, and the output. This is placed directly after the description section and, if it exists, the backported commits section, like this:
+
+```
+Output
+
+List of files
+
+  - ls
+
+total 151
+drwxr-xr-x 1 Aptivi None     0 Nov  6 12:52 .
+drwxr-xr-x 1 Aptivi None     0 Aug  2 09:07 ..
+-rw-r--r-- 1 Aptivi None  4351 Nov 15  2022 DIR_COLORS
+(...)
+```
+
 ## Releases
 
 When planning for a new version, always start the development of the next version by changing the version found in all the relevant files (usually `Directory.Build.props` for C# projects) before starting to push commits that add new features and everything else. When development finishes, before the release tag can be pushed, the `CHANGES` file should be changed to reflect the new release, as long as it follows this convention: