1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
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.
|
