docs: update documentation (#319)

* docs: unclutter repository root

Move community health files to .github folder

* ci: remove redundant stanza from .mega-linter.yml

* ci: rename dependabot group for GitHub Actions

* docs: update contributing guideline

* docs: update PULL_REQUEST_TEMPLATE.md

* ci: fix linter findings

* docs: minor corrections to convetional commit style

CONTRIBUTING.md → .github/CONTRIBUTING.md

@@ -20,6 +20,7 @@ Use your best judgment, and feel free to propose changes to this document in a p
     - [Want to improve the documentation?](#want-to-improve-the-documentation)
   - [Submission Guidelines](#submission-guidelines)
     - [Submitting an Issue](#submitting-an-issue)
+    - [Pull Request Title: Conventional Commits](#pull-request-title-conventional-commits)
     - [Submitting a Pull Request (PR)](#submitting-a-pull-request-pr)
     - [Reviewing a Pull Request](#reviewing-a-pull-request)
   - [Your First Contribution](#your-first-contribution)
@@ -32,7 +33,7 @@ Following these guidelines helps to communicate that you respect the time of the
 
 ### Learn about our code of conduct
 
-See the [code of conduct](CODE_OF_CONDUCT.md).
+See the [code of conduct](./CODE_OF_CONDUCT.md).
 
 ### Got a Question or Problem?
 
@@ -49,7 +50,7 @@ If you find a bug in the source code or a mistake in the documentation, you can
 
 ### Found a security vulnerability?
 
-If you discover a vulnerability in our software, please contact a [maintainer](.github/CODEOWNERS) directly and report it appropriately.
+If you discover a vulnerability in our software, please refer to the [security policy](./SECURITY.md) and report it appropriately.
 Do not submit an issue, unless asked to.
 
 ### Missing a Feature?
@@ -83,9 +84,45 @@ Unfortunately, we are not able to investigate/fix bugs without minimal reproduct
 
 You can file new issues by selecting from our new issue templates and filling out the issue template.
 
+### Pull Request Title: Conventional Commits
+
+The title of your Pull Request (PR) should follow the style of [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/). Not only does this present a standardized categorization of the kind of work done on a pull request, but it also instructs the release workflow to increment the correct level of the version according to the rules of [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+The format of the title of the pull request is this:
+
+ `<type>[(optional scope)][!]: <description>`
+
+The `<type>` of the pull request is one of these:
+
+- `feat:` adding new functionality
+- `fix:` fixing a bug
+- `test:` adding, improving, fixing tests
+- `ci:` modifications on how GitHub interacts with the archive: workflows and configuration files
+- `docs:` anything documentation related
+- `refactor:` refactoring code, including applying formatters
+- `chore:` a catch-all type for any other commits
+
+An exclamation mark `!` is added to the type if the change is not backwards compatible. This should only be added to `feat` or `fix`.
+
+> [!NOTE]
+> We do not enforce conventional commits for individual commit messages, only for the title of your pull request.
+
+Examples:
+
+- `feat: add required-tool to devcontainer`
+
+   This pull request adds the "required-tool" to the devcontainer because everybody want to use it.
+
+- `fix!: escape fe ff in binary ports`
+
+   This pull request fixes binary ports, and indicates that this is a backwards-incompatible change.
+
+> [!TIP]
+> If your work consists of a single commit, creating a pull request will default to the name of that commit. If you use conventional commit style for that single commit, your pull request already has the correct name.
+
 ### Submitting a Pull Request (PR)
 
-Before you submit your Pull Request (PR) consider the following guidelines:
+Before you submit your pull request consider the following guidelines:
 
 1. Search the GitHub Repository for an open or closed PR that relates to your submission.
    You don't want to duplicate existing efforts.
@@ -98,7 +135,7 @@ Before you submit your Pull Request (PR) consider the following guidelines:
 1. Make your changes in a new git branch:
 
    ```shell
-   git checkout -b my-fix-branch main
+   git checkout -b feature/my-fix-branch main
    ```
 
 1. Create your patch, include tests if necessary.
@@ -116,7 +153,7 @@ Before you submit your Pull Request (PR) consider the following guidelines:
 1. Push your branch to your GitHub fork:
 
    ```shell
-   git push origin my-fix-branch
+   git push origin feature/my-fix-branch
    ```
 
 1. In GitHub, send a pull request to merge from the branch on your fork to the main branch in the upstream.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,16 @@
+# Pull Request
+
+## Description of changes
+
+<!-- Fill in a description of what this PR changes/introduces/fixes
+     Link to GitHub issues using keywords https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests when necessary
+-->
+
+## Checklist
+
+<!-- We follow conventional commit-style PR titles and kebab-case branch names -->
+
+- [ ] I have followed the contribution guidelines for this repository
+- [ ] I have added tests for new behavior, and have not broken any existing tests
+- [ ] I have added or updated relevant documentation
+- [ ] I have verified that all added components are accounted for in the SBOM

.github/dependabot.yml

@@ -7,7 +7,7 @@ updates:
     schedule:
       interval: daily
     groups:
-      minor-and-patch-action-updates:
+      github-actions:
         update-types:
           - minor
           - patch

.mega-linter.yml

@@ -1,4 +1,3 @@
-APPLY_FIXES: all
 ENABLE:
   - ACTION
   - DOCKERFILE

README.md

@@ -81,27 +81,27 @@ The resulting containers can be used in a `.devcontainer.json` file or in a `.de
 
 ## Community
 
-This project uses a [code of conduct](./CODE_OF_CONDUCT.md) to define expected conduct in our community. Instances of
-abusive, harassing, or otherwise unacceptable behavior may be reported by contacting a project [CODEOWNER](./.github/CODEOWNERS)
+This project uses a [code of conduct](.github/CODE_OF_CONDUCT.md) to define expected conduct in our community. Instances of
+abusive, harassing, or otherwise unacceptable behavior may be reported to the repository administrators by using the [`Report content`](https://docs.github.com/en/communities/maintaining-your-safety-on-github/reporting-abuse-or-spam) functionality of GitHub.
 
 ## Changelog
 
 See the [changelog](./CHANGELOG.md) for more info on what's been changed.
 
 ## Contributing
 
-This project uses [Semantic Versioning 2.0.0](https://semver.org/spec/v2.0.0.html) and [Conventional Commits 1.0.0](https://www.conventionalcommits.org/en/v1.0.0/) please see the [contributing](./CONTRIBUTING.md) guideline for more information.
+This project uses [Semantic Versioning 2.0.0](https://semver.org/spec/v2.0.0.html) and [Conventional Commits 1.0.0](https://www.conventionalcommits.org/en/v1.0.0/) please see the [contributing](.github/CONTRIBUTING.md) guideline for more information.
 
 ### Build & Test
 
 The container can be built and tested locally by importing this repository in VS Code with the [`Remote Containers`](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) plug-in installed. As a prerequisite Docker needs to be installed on the host system. Alternatively a GitHub Codespace can be started.
 
-A test task is available to run the included `bats` tests. Choose `Tasks: Run Test Task` from the command pallette.
+A test task is available to run the included `bats` tests. Choose `Tasks: Run Test Task` from the command pallette (<kbd>Ctrl</kbd> + <kbd>Shift</kbd> + <kbd>P</kbd>).
 
 ## Reporting vulnerabilities
 
 If you find a vulnerability, please report it to us!
-See [security](./SECURITY.md) for more information.
+See [security](.github/SECURITY.md) for more information.
 
 ## Licenses