Finished the page up until needing to edit the corresponding repositories

docs/docs/development/module-creation.md

@@ -10,19 +10,19 @@ sidebar_label: ZMK Module Creation
 - Modules containing drivers
 - Modules containing visual effects
 
-ZMK comes with a Git repository called `zmk-modules` which tracks various different modules. This allows modules to be discovered and used by various tools and scripts. The below described creation process will guide you through the creation and addition of a module to `zmk-modules`. For a precise description of the requirements, see the `README.md` found in the `zmk-modules` repository.
+ZMK comes with a Git repository called `zmk-modules` which tracks various different modules. This allows modules to be discovered and used by various tools and scripts. The below described creation process will guide you through the creation and addition of a module to `zmk-modules`.
 
-## Template
+## Module Setup
 
 ZMK has a template to make creating a module easier. Navigate to [the ZMK module template repository](./new-shield.mdx) and select "Use this template" followed by "Create a new repository" in the top right.
 
 The rest of this page will go through the contents of the template step by step, guiding you through the configuration of the module.
 
-## Zephyr Module File
+### Zephyr Module File
 
 This is the file that defines your module. Only when this file is configured correctly will your module function as expected.
 
-### Name
+#### Name
 
 First, you will need to name your module. ZMK has a naming convention that you should follow:
 
@@ -51,7 +51,7 @@ Your module name goes in the `zephyr/module.yml` file:
 name: <your module name>
 ```
 
-### Build Options
+#### Build Options
 
 Next, you need to define the options to build your module. These also go into `zephyr/module.yml`, as children of the `build` property. Commonly used options are:
 
@@ -64,7 +64,7 @@ Next, you need to define the options to build your module. These also go into `z
 
 See the `zephyr/module.yml` found in the template for a usage example.
 
-## Dependencies
+### Dependencies
 
 If your module depends on other modules, then you should also define a [west manifest](https://docs.zephyrproject.org/3.5.0/develop/west/manifest.html) file. While the `zephyr/modules.yaml` file defines _which_ modules your module depends on, the west manifest file defines _where_ said modules are found. This then allows automatic tooling to fetch the modules when building firmware.
 
@@ -86,13 +86,13 @@ manifest:
 
 See the [modules feature page](../features/modules.mdx) for additional information on using west manifest files.
 
-## Informational Files
+### Informational Files
 
 Make sure to include a `README.md` file and a `LICENSE` file in your repository. Only modules with MIT-compatible licenses can be added to `zmk-modules`.
 
-## Predefined Files and Folders
+### Predefined Files and Folders
 
-The repository comes with a number of files and folders already positioned for you to edit. The below table describes which files are most likely kept and which are most likely deleted, based on your module's type. Note that these aren't hard rules, merely the most common use case. The only rule that needs to be followed is that unused files and folders should be deleted.
+The repository comes with a number of files and folders already positioned for you to edit. The below table describes which files are most likely kept and which are most likely deleted, based on your module's type. Note that these aren't hard rules, merely the most common use case.
 
 |                  | `keyboards` | `components` | `behavior` | `driver` | `feature` | `vfx` |
 | ---------------- | ----------- | ------------ | ---------- | -------- | --------- | ----- |
@@ -116,4 +116,51 @@ The below table reminds of the purpose of each of these files and folders, if yo
 | `src/`           | Folder for C source files                                                              |
 | `snippets/`      | Folder for [snippets](https://docs.zephyrproject.org/latest/build/snippets/index.html) |
 
-##
+Note that the `include` and `src` folders are not mandated by the module system, and all of these can be positioned anywhere in your module's filetree if you adjust the `zephyr/module.yml` accordingly.
+
+## Inclusion in ZMK Modules Repository
+
+:::warning
+The ZMK modules repository is currently experimental, and the below content is subject to change. ZMK modules is also missing tooling.
+:::
+
+Once you have written and tested your module, you should prepare it for inclusion into `zmk-modules`. The primary reasons for you wanting to do so are:
+
+- It makes discovering and using your module significantly easier for other users
+- Automated tools can help you maintain your module notifying you if there are any potentially breaking changes that you should investigate or new features that you may want to account for.
+
+### Requirements
+
+The following requirements are necessary for a module to be included in `zmk-modules`:
+
+- [] The module is named according to convention
+- [] The module has been tested and confirmed working
+- [] The module features a `README.md` file describing the module
+- [] The module is licensed under an MIT-compatible license, preferably through a `LICENSE` file
+- [] The module follows the general style of other modules of the same type found in `zmk-modules`
+- [] There are no unused files or folders present in the module
+- [] The module is up-to-date with the current version of ZMK
+- [] If the module defines keyboards or hardware components, said keyboards/components are available for public use (sold by a vendor, open source, etc.)
+- [] If the module defines boards or shields, they follow the "good board/shield definition practices"
+
+### Module File
+
+If the requirements are satisfied, then you will need to make a pull request to the `zmk-modules` repository adding a file allowing us to track your module.
+
+The file should be named `<module-name>.yml`, where module-name is the _Zephyr_ module name, not the _repository_ name. It has the following format:
+
+```yaml title="<module-name>.yml"
+remotes:
+  - name: remote-name
+    url: https://github.com/remote-name/repository-name
+versions:
+  - remote: remote-name
+    zmk: "0.1.0"
+    commit: d1d9b06ebb524d5c8edc6d6dba58b98d98a5a6aa
+```
+
+The `versions` property is used to assign particular commits in the repository to ZMK versions. This simultaneously protects `zmk-modules` from malicious commits and allows for improved compatibility - if multiple modules are being used, the maximum version that all modules are compatible with is used. Ideally, for each ZMK update a new entry would appear under `versions`. The addition of automated tools to help with this process is planned.
+
+The `remotes` name exists primarily as a fallback in case a module is not maintained for a prolonged period of time. If such an event was to happen, then another user could update the module for a more recent version and "take over" the duties of maintaining the module.
+
+The module file should be added to the appropriate `type` folder under `zmk-modules`. Once you have done so, you can make a pull request.