docs: add CONTRIBUTING.md; rework readme

CONTRIBUTING.md

@@ -0,0 +1,68 @@
+# Contributing Guidelines
+
+Thank you for being interested in contributing to ContentLib! ContentLib aims to be a community-driven project, and needs contributors and maintainers to ensure this project lives on.
+
+## Working on the Project
+
+You can look for open [issues](https://github.com/LC-ContentLib/ContentLib/issues) that you could take on.
+
+When you are ready to work on an issue:
+
+- leave a message on the issue to let others that know you are working on it.
+- fork this repository.
+- create a new branch on your fork for the issue.
+- when you are ready, open a pull request.
+
+Your pull request will be reviewed and feedback will be given. When everything is fine, your work will be merged into ContentLib!
+
+Make sure to read the rest of the guidelines on this page, as that will help make the review process go smoother. But don't worry about it too much, the most important thing is your contribution!
+
+## Project Design
+
+ContentLib has been built to be modular, easily extensible, and simple.
+
+Each API module should only do one thing, and modules should generally work independent of each other to keep things simple.
+
+However, each API module should probably depend on the `ContentLib.Core` module as it contains all the essential building blocks, like [ContentDefinition](https://github.com/LC-ContentLib/ContentLib/blob/main/src/ContentLib.Core/ContentDefinition.cs).
+
+## Coding Style
+
+We follow and enforce the following coding conventions:
+
+- <https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions>
+- <https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/identifier-names>
+
+These rules are enforced with the help of the [.editorconfig](https://github.com/LC-ContentLib/ContentLib/blob/main/.editorconfig) file. These will show up as warnings or suggestions in your IDE, and they exist to ensure that code style is mostly consistent across all modules.
+
+### Clear Code
+
+You should aim to write code that is easy to understand and follow.
+
+For example, a `Register` method for a content class that derives from [ContentDefinition](https://github.com/LC-ContentLib/ContentLib/blob/main/src/ContentLib.Core/ContentDefinition.cs) should make it clear where the internal logic for injecting said content is in the API module.
+
+Here's an example of [EnemyDefinition's](https://github.com/LC-ContentLib/ContentLib/blob/main/src/ContentLib.EnemyAPI/EnemyDefinition.cs) `Register` method:
+
+```cs
+public override void Register()
+{
+    // ...
+    EnemyDefinitionInjector.Register(this);
+    // ...
+}
+```
+
+This makes it quite obvious where the injection logic is.
+
+### No Magic
+
+By magic, we mean things like Harmony's Patch Attribute system. This is bad because how it works can't simply be figured out by reading the code; you must read the Harmony documentation to know its rules. If you wish to use Harmony, please use it with manual patching.
+
+[MonoMod](https://lethal.wiki/dev/fundamentals/patching-code#monomod) is an alternative tool for patching, which we prefer thanks to its HookGen's helper assemblies that contain Hooks for the game's methods. Using these assemblies also gives your IDE the ability to know if your Hook methods will work or not.
+
+## Implementing New Modules
+
+The first part of implementing a new API module is planning. If you wish for a module to be made, open an [issue](https://github.com/LC-ContentLib/ContentLib/issues) on it so we can start discussing it.
+
+The next part is writing an API design document for the module. This is a document that describes what the public API for this module should expose and how it should be used. Internal behavior can also be in this design document, but it should be made clear what is internal and what is public.
+
+Once the API design document has been approved, it will be moved to [issues](https://github.com/LC-ContentLib/ContentLib/issues) so it can be picked up and implemented. You should use an existing module implementation as reference, like [ContentLib.EnemyAPI](https://github.com/LC-ContentLib/ContentLib/tree/main/src/ContentLib.EnemyAPI).

README.md

@@ -1,43 +1,19 @@
-# ContentLib - A Lethal Company API for Custom Content
+# ContentLib
 
-> [!NOTE]  
-> This project is still a WIP!
-
-ContentLib is a modular Custom Content API for Lethal Company.
-
-## Contributing
-
-If you are a developer, consider contributing to ContentLib!  
-ContentLib aims to be a community-driven project, and needs contributors and maintainers to ensure this project lives on.
-
-### About the Project
-
-This project has been built to be modular and easily extensible, and aims to be very accessible for new contributors. New modules are generally built on top of the [ContentLib.Core](/src/ContentLib.Core/) module, which provides all the important base classes like [ContentDefinition](/src/ContentLib.Core/ContentDefinition.cs). An excellent example of a module implementation is [ContentLib.EnemyAPI](/src/ContentLib.EnemyAPI/).
-
-### Working on the Project
+A modular custom content API for Lethal Company.
 
-You can look for open [issues](https://github.com/LC-ContentLib/ContentLib/issues) that you could take on.
+- **[Documentation](https://lc-contentlib.github.io/ContentLib/index.html)**
 
-When you are ready to work on an issue:
-
-- leave a message on the issue to let others that know you are working on it.
-- fork this repository.
-- create a new branch on your fork for the issue.
-- when you are ready, open a pull request.
-
-Your pull request will be reviewed and feedback will be given. When everything is fine, your work will be merged into ContentLib!
-
-See these resources on code style and naming conventions to help write better code:
-
-- <https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions>
-- <https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/identifier-names>
-
-We enforce some coding style rules based on the above resources. These rules are configured in the [.editorconfig](/.editorconfig) file. These will show up as warnings or suggestions in your IDE, and they exist to ensure that code style is mostly consistent across all modules.
+> [!NOTE]  
+> This project is still a WIP! Don't try to use it yet!
 
-### Implementing New Modules
+## API Modules
 
-The first part of implementing a new module is planning. If you wish for a module to be made, open an [issue](https://github.com/LC-ContentLib/ContentLib/issues) on it so we can start discussing it.
+- EnemyAPI (WIP)
+- HazardAPI (TODO)
+- More coming soon...
 
-The next part is writing an API design document for the module. This is a document that describes what the public API for this module should expose and how it should be used.
+## Contributing
 
-Once the API design document has been approved, it will be moved to [issues](https://github.com/LC-ContentLib/ContentLib/issues) so it can be picked up and implemented. Consider using an existing module implementation as reference. For example: [ContentLib.EnemyAPI](/src/ContentLib.EnemyAPI/).
+If you are a developer, consider contributing to ContentLib!  
+See [CONTRIBUTING.md](/CONTRIBUTING.md) for more information.

docs/docs/contributing/contributing-guidelines.md

@@ -0,0 +1,5 @@
+---
+title: Contributing Guidelines
+---
+
+[!INCLUDE [CONTRIBUTING](../../../CONTRIBUTING.md)]

docs/docs/toc.yml

@@ -2,4 +2,5 @@
 - href: ../index.md
 - href: getting-started.md
 - name: Contributing
+- href: ./contributing/contributing-guidelines.md
 - href: ./contributing/writing-articles.md