1 files changed, 60 insertions, 0 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000..8b15c02
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,60 @@
+# Contributing Guide
+
+Developers of this project highly appreciate your contribution, but
+following the contributing guide makes collaboration much efficient.
+
+## Coding Style
+
+### Java
+
+1. Lower camel case for method names. Upper camel case for class names.
+2. Annotate return values and parameters with @NotNull or @Nullable as
+much as you can.
+3. Document methods as much as you can.
+4. Use IntelliJ Idea code style. Format your code before committing.
+5. Always put `{}` after if or else. `if () xxx()` is not accepted for
+the version control's sake.
+6. Comments: `//` or `/*` or `/**`.
+7. Do your best not to use third-party dependencies to keep the mod small.
+Anything bundled in Minecraft, Fabric or Fabric API are fine.
+
+### C
+
+1. Use `func_name`, not `FuncName`, nor `funcName`.
+2. Mark pointer arguments as `const` if it is not going to be changed in the
+function.
+3. Document functions as much as you can.
+4. Use CLion code style. Format your code before committing.
+5. Always put `{}` after if or else. `if () xxx()` is not accepted for
+the version control's sake.
+6. Comments: `/*` or `/**` only (not `//`).
+7. During testing, make sure it works on both Unix and Windows.
+8. Do not use platform-specific APIs unless wrapped in `ifdef`.
+This includes anything POSIX, Linux-specific or Windows-specific. In other words,
+Use as much as C standard API or library functions as possible.
+9. Functions to be exported must start with `ac_` and annotated using `LIBAC_EXPORT`.
+10. Headers in `libacron/include/` will be installed with distribution. Thus, only
+put public headers here.
+
+## Commit Style
+
+1. Use Angular commit style.
+2. If the WebSocket API or libacron API changes, put `API:CHANGE`, `API:ADD` or `API:DEL`
+in the commit message body.
+3. Try to explain the thing completely in the commit message.
+4. Sign off the commit.
+
+## Testing
+
+Before sending patches, make sure you test your changes throughoutly.
+Unit tests, although are currently absent, are better than manual tests.
+
+Keep threads safety in mind. Read library manuals carefully before using
+them.
+
+## Sending Patches
+
+Before sending patches, make sure you tested it.
+
+Then, use `git-format-patch(1)` to generate an email and send it to
+`yuuta@yuuta.moe`. The subject should include `[PATCH]`.