Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
90 lines (67 loc) · 3.92 KB

CONTRIBUTING.md

File metadata and controls

90 lines (67 loc) · 3.92 KB

Contributing to Arconia

Thank you for your interest in contributing! Whether it's reporting bugs, suggesting features, improving documentation, or submitting code, your input is welcome and valued.

Ground Rules

  • Be Respectful. Adhere to the Code of Conduct.
  • Discuss First. For non-trivial changes, open an issue before starting work. PRs without a prior discussion may be rejected.
  • Use Discussions for Questions. The issue tracker is not for support questions. Use GitHub Discussions instead.
  • Focused PRs. Each pull request should address a single issue or feature, linked to the corresponding issue (e.g., Fixes #123).
  • Security Vulnerabilities. Report them responsibly via the Security Policy. Do not open a public issue.

Prerequisites

Contribution Workflow

  1. Find or create an issue. Ensure a GitHub Issue exists for the change you want to make.
  2. Fork and clone the repository: 
    git clone https://github.com/<your-username>/arconia.git
cd arconia
  3. Create a branch off main: 
    git checkout -b my-feature-branch main
  4. Implement your changes. Follow the code style guidelines, add tests, and update documentation in docs/ if needed.
  5. Build and test locally: 
    ./gradlew build
  6. Commit using Conventional Commits format with a DCO sign-off: 
    git commit -s -m "feat(core): Add new feature"
  7. Keep your branch updated via rebase (never merge): 
    git fetch upstream
git rebase upstream/main
  8. Push and open a PR targeting main. Ensure the PR title follows Conventional Commits format and fill out the PR template.
  9. Address review feedback. Maintainers will review your PR. Push additional signed-off commits as needed.

Reporting Bugs and Suggesting Features

Use GitHub Issues with the appropriate template:

  • Bugs: Use the "Bug: Generic" template.
  • Features: Use the "Request: Feature" template.
  • Dev Services: Use the "Request: Dev Service" template.

Before submitting, search existing issues to avoid duplicates and ensure bugs are reproducible with the latest version.

Development Guidelines

Code Style

  • The project uses .editorconfig for formatting. Ensure your editor respects it.
  • Use explicit imports (no wildcards).
  • Follow existing alphabetical sorting conventions.

Commit Messages

We follow Conventional Commits for both commit messages and PR titles.

<type>[optional scope]: <description>
  • Types: feat, fix, docs, style, refactor, test, build, ci, chore, revert, deps.
  • Scopes (optional, relate to project modules): core, dev, k8s, multitenancy, otel. Omit scope if the change doesn't relate to one of these modules.
  • Style: Present tense, imperative mood (e.g., "Add feature", not "Added feature").
  • Breaking changes: Append ! after the type/scope (e.g., feat(core)!:) or add BREAKING CHANGE: in the footer.

Example: fix(dev): Correct handling of container startup timeout

DCO Sign-off

All commits must include a Developer Certificate of Origin sign-off. Commits without it will block merging.

# Sign-off a new commit
git commit -s -m "Your commit message"

# Add sign-off to the last commit
git commit --amend -s --no-edit