|
1 | 1 | # Contributing to Arconia |
2 | 2 |
|
3 | | -Thank you for considering contributing to Arconia! We appreciate your time and effort in helping make the project better. These guidelines aim to streamline the contribution process, ensure clarity in communication, and align your efforts with the project's goals. |
4 | | - |
5 | | -Arconia is an open-source project that welcomes contributions from everyone. Whether it's reporting bugs, suggesting features, improving documentation, or submitting code changes via pull requests, your input is valuable. Please follow these guidelines to ensure a smooth and efficient collaboration. |
6 | | - |
7 | | -## Table of Contents |
8 | | - |
9 | | -- [Ground Rules](#ground-rules) |
10 | | -- [Getting Started: Prerequisites](#getting-started-prerequisites) |
11 | | -- [Contribution Workflow: Issues and Pull Requests](#contribution-workflow-issues-and-pull-requests) |
12 | | -- [Reporting Bugs and Suggesting Features](#reporting-bugs-and-suggesting-features) |
13 | | -- [Asking Support Questions](#asking-support-questions) |
14 | | -- [Reporting Security Vulnerabilities](#reporting-security-vulnerabilities) |
15 | | -- [Development Guidelines](#development-guidelines) |
16 | | - - [Code Style](#code-style) |
17 | | - - [Commit Messages](#commit-messages) |
18 | | - - [Signing Commits](#signing-commits) |
19 | | - - [Developer Certificate of Origin (DCO) Sign-off](#developer-certificate-of-origin-dco-sign-off) |
20 | | -- [Code of Conduct](#code-of-conduct) |
| 3 | +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. |
21 | 4 |
|
22 | 5 | ## Ground Rules |
23 | 6 |
|
24 | | -* **Be Respectful**. Interact politely and respectfully with everyone in the community. Adhere to the [Arconia Code of Conduct](CODE_OF_CONDUCT.md). |
25 | | -* **Discuss First**. For any non-trivial changes (more than fixing a typo), **please open a [GitHub Issue](https://github.com/arconia-io/arconia/issues/new/choose) first.** Discuss your proposed changes and get feedback before starting work. This prevents wasted effort and ensures alignment. Failure to do so might result in your pull request being rejected. |
26 | | -* **Use Discussions for Questions**. For general questions or help, please use [GitHub Discussions](https://github.com/arconia-io/arconia/discussions). |
27 | | -* **Focused Pull Requests**. Keep each pull request focused on a single issue or feature. Link the PR to the corresponding issue (e.g., `Fixes #123` or `Closes gh-XXXX` in the PR description). |
28 | | - |
29 | | -## Getting Started: Prerequisites |
| 7 | +* **Be Respectful.** Adhere to the [Code of Conduct](CODE_OF_CONDUCT.md). |
| 8 | +* **Discuss First.** For non-trivial changes, [open an issue](https://github.com/arconia-io/arconia/issues/new/choose) before starting work. PRs without a prior discussion may be rejected. |
| 9 | +* **Use Discussions for Questions.** The issue tracker is not for support questions. Use [GitHub Discussions](https://github.com/arconia-io/arconia/discussions) instead. |
| 10 | +* **Focused PRs.** Each pull request should address a single issue or feature, linked to the corresponding issue (e.g., `Fixes #123`). |
| 11 | +* **Security Vulnerabilities.** Report them responsibly via the [Security Policy](SECURITY.md). Do **not** open a public issue. |
30 | 12 |
|
31 | | -Before you start contributing code, ensure you have: |
| 13 | +## Prerequisites |
32 | 14 |
|
33 | | -* Java 21 or later installed. |
| 15 | +* Java 21+ installed. |
34 | 16 | * A container runtime compatible with Testcontainers (e.g., [Podman Desktop](https://podman-desktop.io), [Docker Desktop](https://www.docker.com/products/docker-desktop/)). |
35 | 17 |
|
36 | | -## Contribution Workflow: Issues and Pull Requests |
| 18 | +## Contribution Workflow |
37 | 19 |
|
38 | | -Contributions are made via GitHub Pull Requests. Here’s the typical workflow: |
39 | | - |
40 | | -1. **Find or Create an Issue**. Ensure a [GitHub Issue](https://github.com/arconia-io/arconia/issues) exists for the bug or feature you want to address. If not, create one to discuss the change first (see [Ground Rules](#ground-rules)). |
41 | | -2. **Fork and Clone**. Fork the `arconia-io/arconia` repository on GitHub and clone your fork locally: |
| 20 | +1. **Find or create an issue.** Ensure a [GitHub Issue](https://github.com/arconia-io/arconia/issues) exists for the change you want to make. |
| 21 | +2. **Fork and clone** the repository: |
42 | 22 | ```shell |
43 | 23 | git clone https://github.com/<your-username>/arconia.git |
44 | 24 | cd arconia |
45 | 25 | ``` |
46 | | -3. **Create a Branch**. Create a descriptive branch for your changes off the `main` branch: |
| 26 | +3. **Create a branch** off `main`: |
47 | 27 | ```shell |
48 | | - git checkout -b my-descriptive-feature-branch main |
| 28 | + git checkout -b my-feature-branch main |
49 | 29 | ``` |
50 | | -4. **Implement Changes**. Make your code changes. Follow the [Code Style](#code-style) guidelines. |
51 | | -5. **Add Tests**. Write unit or integration tests covering your changes. |
52 | | -6. **Update Documentation**. If necessary, update documentation in the `docs/` directory. |
53 | | -7. **Build and Test Locally**. Ensure everything builds and all tests pass: |
| 30 | +4. **Implement your changes.** Follow the [code style](#code-style) guidelines, add tests, and update documentation in `docs/` if needed. |
| 31 | +5. **Build and test locally:** |
54 | 32 | ```shell |
55 | 33 | ./gradlew build |
56 | 34 | ``` |
57 | | -* **Commit Changes**. Commit your work using descriptive messages that follow the [Commit Messages](#commit-messages) format. Crucially, ensure your commits are signed off (see [Signing Commits](#signing-commits)). |
| 35 | +6. **Commit** using [Conventional Commits](#commit-messages) format with a [DCO sign-off](#dco-sign-off): |
58 | 36 | ```shell |
59 | | - git add . |
60 | | - git commit -s -m "feat(core): Implement the new feature" |
| 37 | + git commit -s -m "feat(core): Add new feature" |
61 | 38 | ``` |
62 | | -9. **Keep Branch Updated**. Before pushing, and periodically during development, update your branch with the latest changes from the upstream `main` branch using rebase (NEVER merge): |
| 39 | +7. **Keep your branch updated** via rebase (never merge): |
63 | 40 | ```shell |
64 | | - # Add upstream remote if you haven't already |
65 | | - git remote add upstream https://github.com/arconia-io/arconia.git |
66 | | -
|
67 | | - # Fetch latest changes and rebase your branch |
68 | 41 | git fetch upstream |
69 | 42 | git rebase upstream/main |
70 | | - # Resolve any conflicts if they occur |
71 | 43 | ``` |
72 | | -10. **Push to Your Fork**. Push your branch to your fork. Use `--force-with-lease` if you rebased or amended commits: |
73 | | - ```shell |
74 | | - git push origin my-descriptive-feature-branch --force-with-lease |
75 | | - ``` |
76 | | -11. **Open a Pull Request**. |
77 | | - * Navigate to the `arconia-io/arconia` repository on GitHub. |
78 | | - * Click "New pull request" and choose to compare across forks, selecting your fork and branch. |
79 | | - * Target the `main` branch of `arconia-io/arconia`. |
80 | | - * Ensure the PR title follows the [Commit Messages](#commit-messages) format. |
81 | | - * Fill out the pull request template, clearly describing the changes and linking the related issue (e.g., `Fixes #123`). |
82 | | -12. **Code Review:** Project maintainers will review your PR. Address any feedback by making changes on your branch, committing them (signed-off), and pushing again. The PR will update automatically. |
83 | | -13. **Merge**. Once the PR is approved and all checks pass, a maintainer will merge it. Congratulations and thank you for your contribution! |
| 44 | +8. **Push and open a PR** targeting `main`. Ensure the PR title follows [Conventional Commits](#commit-messages) format and fill out the PR template. |
| 45 | +9. **Address review feedback.** Maintainers will review your PR. Push additional signed-off commits as needed. |
84 | 46 |
|
85 | 47 | ## Reporting Bugs and Suggesting Features |
86 | 48 |
|
87 | | -Use our [GitHub Issues](https://github.com/arconia-io/arconia/issues/new/choose) page to report bugs or suggest features, selecting the appropriate template: |
| 49 | +Use [GitHub Issues](https://github.com/arconia-io/arconia/issues/new/choose) with the appropriate template: |
88 | 50 |
|
89 | 51 | * **Bugs:** Use the **"Bug: Generic"** template. |
90 | 52 | * **Features:** Use the **"Request: Feature"** template. |
91 | 53 | * **Dev Services:** Use the **"Request: Dev Service"** template. |
92 | 54 |
|
93 | | -Before submitting: |
94 | | - |
95 | | -1. Search existing issues to avoid duplicates. |
96 | | -2. For bugs, ensure it's reproducible with the latest version. |
97 | | -3. Provide clear descriptions and follow the template instructions. |
98 | | -4. Remember to discuss significant changes *before* starting implementation (see [Ground Rules](#ground-rules)). |
99 | | -
|
100 | | -## Asking Support Questions |
101 | | -
|
102 | | -Please **do not** use the issue tracker for support questions. Use [GitHub Discussions](https://github.com/arconia-io/arconia/discussions) instead. |
103 | | -
|
104 | | -## Reporting Security Vulnerabilities |
105 | | -
|
106 | | -If you discover a security vulnerability, report it responsibly by following the instructions in our [Security Policy](SECURITY.md). **Do NOT open a public issue or disclose it publicly.** |
| 55 | +Before submitting, search existing issues to avoid duplicates and ensure bugs are reproducible with the latest version. |
107 | 56 |
|
108 | 57 | ## Development Guidelines |
109 | 58 |
|
110 | 59 | ### Code Style |
111 | 60 |
|
112 | | -* The project uses [.editorconfig](/.editorconfig) to define basic code formatting. Please ensure your editor respects this file. |
113 | | -* Use explicit imports; avoid wildcard (`*`) imports. |
114 | | -* Follow the existing sorting order when adding items to lists (usually alphabetical). |
| 61 | +* The project uses [.editorconfig](/.editorconfig) for formatting. Ensure your editor respects it. |
| 62 | +* Use explicit imports (no wildcards). |
| 63 | +* Follow existing alphabetical sorting conventions. |
115 | 64 |
|
116 | 65 | ### Commit Messages |
117 | 66 |
|
118 | | -We follow the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification for PR titles and commit messages. This aids automated releases and improves history readability. |
| 67 | +We follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) for both commit messages and PR titles. |
119 | 68 |
|
120 | | -Format: |
121 | 69 | ``` |
122 | 70 | <type>[optional scope]: <description> |
123 | | -
|
124 | | -[optional body] |
125 | | -
|
126 | | -[optional footer(s)] |
127 | 71 | ``` |
128 | 72 |
|
129 | | -* **Types**: `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `build`, `ci`, `chore`, `revert`, `deps`. |
130 | | -* **Scopes** (optional, relate to project modules): `core`, `dev`, `k8s`, `multitenancy`, `otel`. Do not include a scope if the change doesn't relate to one of these modules. |
131 | | -* **Description**: Use present tense ("Add feature", not "Added feature") and imperative mood ("Move cursor", not "Moves cursor"). |
132 | | -* **Breaking Changes**: Indicate breaking changes with `BREAKING CHANGE:` in the footer or by appending `!` after the type/scope (e.g., `feat(core)!:`). |
| 73 | +* **Types:** `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `build`, `ci`, `chore`, `revert`, `deps`. |
| 74 | +* **Scopes** (optional, relate to project modules): `core`, `dev`, `k8s`, `multitenancy`, `otel`. Omit scope if the change doesn't relate to one of these modules. |
| 75 | +* **Style:** Present tense, imperative mood (e.g., "Add feature", not "Added feature"). |
| 76 | +* **Breaking changes:** Append `!` after the type/scope (e.g., `feat(core)!:`) or add `BREAKING CHANGE:` in the footer. |
133 | 77 |
|
134 | 78 | Example: `fix(dev): Correct handling of container startup timeout` |
135 | 79 |
|
136 | | -The Pull Request title *must* also follow this convention. |
137 | | - |
138 | | -### Signing Commits |
139 | | - |
140 | | -All commits contributed to Arconia must be **signed-off**, attesting to the [Developer Certificate of Origin (DCO)](#developer-certificate-of-origin-dco-sign-off). |
141 | | - |
142 | | -Commits lacking sign-off will block merging. |
143 | | - |
144 | | -#### Developer Certificate of Origin (DCO) Sign-off |
145 | | - |
146 | | -The DCO certifies you have the right to submit your contribution. |
| 80 | +### DCO Sign-off |
147 | 81 |
|
148 | | -The easiest way to sign-off a commit is using the `-s` flag: |
| 82 | +All commits must include a [Developer Certificate of Origin](dco.txt) sign-off. Commits without it will block merging. |
149 | 83 |
|
150 | 84 | ```shell |
| 85 | +# Sign-off a new commit |
151 | 86 | git commit -s -m "Your commit message" |
152 | | -``` |
153 | | - |
154 | | -To add a sign-off to your *last* commit if you forgot: |
155 | 87 |
|
156 | | -```shell |
| 88 | +# Add sign-off to the last commit |
157 | 89 | git commit --amend -s --no-edit |
158 | 90 | ``` |
159 | | - |
160 | | -For older commits, use interactive rebase (`git rebase -i`). |
161 | | - |
162 | | -## Code of Conduct |
163 | | - |
164 | | -All participants in the Arconia community are expected to adhere to our [Code of Conduct](CODE_OF_CONDUCT.md). Please read it to understand the expected standards of behavior. Treat everyone with respect and kindness. |
0 commit comments