Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
59 lines (50 loc) · 2.71 KB

CONTRIBUTING.md

File metadata and controls

59 lines (50 loc) · 2.71 KB
Raw

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:
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.