1 files changed, 204 insertions, 0 deletions
diff --git a/docs/CONTRIBUTIONS.md b/docs/CONTRIBUTIONS.md
new file mode 100644
index 0000000..9b4aa1e
--- /dev/null
+++ b/docs/CONTRIBUTIONS.md
@@ -0,0 +1,204 @@
+# Contributing to sxwm
+
+Firstly, thanks for taking the time to contribute to `sxwm`! Your interest
+in improving the project is truly appreciated.
+
+## Code Style and Formatting
+
+There is an included `clangd` formatting file, but it won’t do everything for you.
+Please follow the rules below to keep the codebase consistent and clean.
+
+### Indentation
+
+* Use **tabs** for indentation — never spaces.
+
+### Blocks
+
+* All blocks of C code must be wrapped in curly braces `{}`.
+* Each statement must be on its own line.
+* Always add a space between keywords and the opening parenthesis.
+
+**Example**:
+
+```c
+if (x) {
+    y();
+}
+else {
+    z();
+}
+```
+
+### Comments
+
+* Use this format for comments to maintain consistency:
+
+```c
+/* this is a comment */
+```
+
+* For temporary notes, use:
+
+```c
+/* TODO: something to fix */
+/* FIXME: known issue */
+```
+
+### Function Declarations
+
+Functions should look like this:
+
+```c
+void function_x(void)
+{
+}
+
+void function_y(int y)
+{
+}
+```
+
+### Variable and Function Naming
+
+* Use `snake_case` for all variable and function names.
+
+**Examples**:
+
+```c
+int some_variable = 2;
+float other_variable = 5;
+
+void do_something(void);
+```
+
+### Header Guards
+
+If you create a header file, use header guards:
+
+```c
+#ifndef HEADER_NAME_H
+#define HEADER_NAME_H
+
+// content
+
+#endif /* HEADER_NAME_H */
+```
+
+### Line Length
+
+* Keep lines under **100 characters** when possible to improve terminal readability.
+
+### Whitespace
+
+* No trailing whitespace.
+* One blank line between function definitions.
+* Avoid unnecessary vertical spacing.
+
+### Include Order
+
+Organize includes like this:
+
+1. Corresponding header (if any)
+2. Standard library headers
+3. Other project headers
+
+---
+
+## Build
+
+* `make` must succeed **with no warnings** on your system.
+* Don’t commit build artifacts (e.g., `.o`, `sxwm`) or backup files (e.g., `*~`).
+* Test your changes, especially on **multi-monitor setups** using **Xephyr**.
+
+---
+
+## File Layout
+
+* Don’t create new `.c` or `.h` files unless absolutely necessary.
+* Keep most changes within `sxwm.c` to maintain cohesion.
+
+---
+
+## Submitting Changes
+
+* Open a pull request with a **clear description** of what and why.
+* Keep **one purpose per commit** — don’t mix unrelated changes.
+* If fixing a bug, describe **how to reproduce it**.
+* If adding a feature, ensure it fits with `sxwm`’s **minimalist philosophy**.
+* **Open separate PRs** for unrelated changes.
+
+---
+
+## Git Commit Guidelines
+
+* Use imperative mood: `Add foo`, not `Added foo`.
+* Keep the summary under 50 characters.
+* Add a detailed body if needed.
+
+**Example**:
+
+```
+Fix crash when window is closed
+
+Previously, sxwm would segfault if a client closed itself.
+This patch adds a check for null pointers before accessing window data.
+```
+
+---
+
+## Tooling & Analysis
+
+* Use the provided `.clang-format` file where applicable.
+* You may optionally run:
+
+  * `cppcheck`
+  * `clang-tidy`
+* Avoid committing debug code like stray `printf()` or `fprintf(stderr, ...)`.
+
+---
+
+## Editor Configuration
+
+A sample `.editorconfig` file is provided (or you can request one).
+It ensures editors match the project’s formatting conventions.
+
+---
+
+## Documentation
+
+Update all relevant documentation if applicable:
+
+* `sxwm.1`
+* `README.md`
+* `default_sxwmrc`
+* `CHANGELOG.md`
+
+---
+
+## Respect the Existing Structure
+
+* For **large changes**, open an issue for discussion first.
+* Do not change code for personal style unless it improves clarity or solves a specific problem.
+
+---
+
+## Testing Checklist
+
+Please ensure the following before opening a PR:
+
+* [x] Code builds **without warnings**
+* [x] Changes are **fully tested**
+* [x] PR includes a **clear explanation**
+* [x] Configuration reload works (if relevant)
+
+---
+
+## Code Review Etiquette
+
+* Be respectful and open to feedback.
+* Feel free to ask questions about any review comments.
+* Reviews are collaborative and meant to improve the code, not criticize you personally.
+
+---
+
+**Happy hacking!**