1 files changed, 59 insertions, 0 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 00000000..7db14516
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,59 @@
+# Contributing
+
+Thanks for helping improve accel-ppp. Please keep changes focused and easy to review.
+
+## Code style and quality
+- The current style in this repository is evolving and not yet uniform.
+- New contributions are expected to follow improved styling standards as we gradually improve the codebase.
+- For C, follow Linux kernel style (K&R-like), unless a file clearly follows a different local convention:
+  - Use hard tabs for indentation (8-column tab stops); avoid spaces for leading indent.
+  - This matches existing files and avoids alignment issues in different editors. 
+  - Function definitions: opening brace on the next line.
+  - Control blocks (`if/for/while/switch`): opening brace on the same line.
+  - `else` and `while` (for do-while) align with the closing brace.
+- Prefer this layout:
+
+```c
+int foo(int x)
+{
+	if (x > 0) {
+		bar(x);
+	} else {
+		baz();
+	}
+}
+```
+  - References:
+    - Linux kernel coding style: `https://www.kernel.org/doc/html/latest/process/coding-style.html`
+    - K&R brace/indent style overview: `https://en.wikipedia.org/wiki/Indentation_style`
+- Prefer small, focused functions and avoid unnecessary refactoring or cosmetic churn.
+
+## Commits (recommended, not strictly enforced)
+- Use concise, imperative messages (e.g., "cli: fix output formatting").
+- A simple component prefix is helpful but not required.
+- Squash or group related changes when it improves clarity.
+
+## AI-generated or assisted code
+- We do not have a final policy decision yet.
+- If you use AI assistance, you must review and edit your patches.
+- Obvious slop, hallucinations, or nonsense will be rejected immediately.
+
+## Tests and documentation
+- Run relevant tests when possible; note what you ran in the PR/commit.
+- Update documentation and man pages if behavior or options change.
+
+## PR acceptance criteria
+- New features or improvements must provide clear value to the accel-ppp community.
+- Changes should not break existing behavior unless it is truly necessary; in such cases, contributors must make all reasonable efforts to provide a clear migration/adaptation path for users.
+- Relevant tests must pass.
+- Submissions must be testable by maintainers and reviewers.
+- For bug fixes where trigger conditions are unclear, maintainers/reviewers may ask for details needed to reproduce the issue.
+
+## PR review process
+- We aim to review PRs within 1 week.
+- If there is no maintainer activity, maintainers may be unavailable (volunteers) or the PR is too complex to review quickly.
+- For major functionality changes or behavior changes, please discuss first before submitting a PR.
+
+## Review expectations
+- Please respond to review comments and update the PR as requested.
+- Be prepared to rebase or adjust commits if asked by maintainers.