Contributing
April 25, 2026 · View on GitHub
Thank you for your interest in Actionbase. Any form of participation—using the project, asking questions, reporting issues, improving documentation, or contributing code—is appreciated.
Getting started
New to open source? Look for issues labeled good first issue.
Development setup
Prerequisites
- Java 17+
- IntelliJ IDEA (Community or Ultimate)
Setup
git clone https://github.com/kakao/actionbase.git
cd actionbase
Open in IntelliJ: File > Open → select project root.
IntelliJ will auto-import Gradle. Wait for indexing to complete.
Build
./gradlew build
Or in IntelliJ: Gradle panel > actionbase > Tasks > build > build
Format
Run before committing:
./gradlew spotlessApply
This formats Kotlin/Java code according to project style.
Run
./gradlew :server:bootRun
Server starts at http://localhost:8080.
Test
# All tests
./gradlew test
# Specific module
./gradlew :core:test
./gradlew :engine:test
./gradlew :server:test
Testing
One rule for now: if your test is data-driven, use @ObjectSource. Other
test shapes are left open. See TESTING.md.
PR workflow
Fork kakao/actionbase on GitHub, then set up remotes:
git remote rename origin upstream
git remote add origin https://github.com/YOUR_USERNAME/actionbase.git
- Create branch:
git checkout -b feature/your-feature - Make changes
- Format:
./gradlew spotlessApply - Test:
./gradlew test - Commit:
git commit -m "feat(scope): description" - Push & create PR
AI-Assisted Pull Requests
AI-assisted pull requests are welcome, provided that you:
- Note in the PR description if the changes were largely written by AI.
- Name the AI tool and model that produced them (e.g., Claude Code, Cursor, Codex, ChatGPT).
- Understand the changes — be ready to discuss any line.
- Write the PR description and reply to reviewers in your own voice. Do not paste AI-generated text into review threads.
- Read through the diff yourself before opening the PR.
- Run a code-review pass with your AI tool (e.g.,
/reviewin Claude Code or Codex CLI) before submitting. - Follow the conventions in
CODING_STYLE.mdand the test rules inTESTING.md.
Inspired by SlateDB's contribution policy — thanks to the SlateDB team for codifying these norms.
Translations
Translations are managed through Translation Memory (TM) files. Here's how to contribute:
-
Find documents that need translation. Run the status command to see coverage (
--langdefaults toko):cd website && npm run translate -- --lang ko status -
Pick a TM file in
website/i18n/tm/{lang}/(e.g.ko) and open it in your editor. Each TM file looks like this:meta: contributors: - alice entries: - source: "What is Actionbase?" target: "" # ← fill in your translation here context: heading - source: "Actionbase is a database for serving user interactions." target: "" # ← and here context: paragraph -
Fill in translations. Find entries with
target: ""and add the translated text. -
Add your GitHub username to
meta.contributors. -
(Optional) Preview locally. Build the translated docs and check the output:
cd website && npm run translate -- --lang ko build -
Open a PR. Please submit one section (folder) per PR rather than translating all pages at once — this keeps reviews manageable and allows incremental progress.
See TRANSLATION.md for technical details and TM format.
How we collaborate
We collaborate through GitHub:
- Discussions: Questions, ideas, and open-ended conversations
- Issues: Bug reports, feature requests, and concrete improvements
- Pull Requests: Code and documentation changes
For questions, ideas, or feedback, join us on Discussions.
Pull requests are reviewed collaboratively and merged by Maintainers.
When submitting a pull request, please sign the CLA (Contributor Licensing Agreement) for Individual. If you need a Contributor Licensing Agreement for Corporate, please contact us.
Security
Report security vulnerabilities through GitHub Security Advisories instead of opening a public issue.
Community standards
All contributors are expected to follow the Code of Conduct.
For project roles, see Governance.