[Chore][Docs] Refresh commit message convention to match current practice

.gitignore

@@ -59,3 +59,4 @@ ds_schema_check_test
 # Agent
 docs/superpowers/
 .claude/worktrees
+CLAUDE.local.md

CLAUDE.md

@@ -146,8 +146,8 @@ A **user** hits the UI, which calls the API server. The API server writes to the
 
 ## Project-wide conventions
 
-- **Formatting**: `./mvnw spotless:apply`. CI will fail PRs that aren't formatted. Java imports are ordered; license headers are enforced.
-- **Commit style**: `[Type-ISSUE_ID] [Scope] Subject`, e.g. `[Fix-18168] [Worker] ...`. Scopes match module names.
+- **Formatting**: Run `./mvnw spotless:apply` before every commit/push. Spotless covers Java sources, `pom.xml`, and Markdown files (yes, including the docs); CI runs `./mvnw spotless:check` and will fail PRs that aren't formatted. Java imports are ordered; license headers are enforced.
+- **Commit style**: `[Type-ISSUE_ID][Scope] Subject`, e.g. `[Fix-18168][Worker] ...`. All types except `Chore` require an issue ID. See [commit-message.md](docs/docs/en/contribute/join/commit-message.md) for the full convention.
 - **Branching**: `dev` is the main integration branch (not `main`/`master`).
 - **PRs must link a GitHub issue** and keep their scope tight — one module / one concern.
 - **Do not break wire / DB compatibility** silently. Changes to `extract-*` RPC interfaces, `dao` entities, enum values, and `spi.DbType` ripple to deployed clusters mid-upgrade.

docs/docs/en/contribute/join/commit-message.md

@@ -1,94 +1,91 @@
 # Commit Message Notice
 
-### Preface
+A good commit message states **what changed and why** at a glance. The full story belongs in the linked Issue / Pull Request — keep the commit message itself concise.
 
-A good commit message can help other developers (or future developers) quickly understand the context of related changes, and can also help project managers determine whether the commit is suitable for inclusion in the release. But when we checked the commit logs of many open source projects, we found an interesting problem. Some developers have very good code quality, but the commit message record is rather confusing. When other contributors or learners are viewing the code, it can’t be intuitively understood through commit log.
-The purpose of the changes before and after the submission, as Peter Hutterer said：Re-establishing the context of a piece of code is wasteful. We can’t avoid it completely, so our efforts should go to reducing it as much as possible. Commit messages can do exactly that and as a result, a commit message shows whether a developer is a good collaborator. Therefore, DolphinScheduler developed the protocol in conjunction with other communities and official Apache documents.
+## Format
 
-### Commit Message RIP
-
-#### 1：Clearly modify the content
-
-A commit message should clearly state what issues (bug fixes, function enhancements, etc.) the submission solves, so that other developers can better track the issues and clarify the optimization during the version iteration process.
-
-#### 2：Associate the corresponding Pull Request or Issue
-
-When our changes are large, the commit message should best be associated with the relevant Issue or Pull Request on GitHub, so that our developers can quickly understand the context of the code submission through the associated information when reviewing the code. If the current commit is for an issue, then the issue can be closed in the Footer section.
-
-#### 3：Unified format
-
-The formatted CommitMessage can help provide more historical information for quick browsing, and it can also generate a Change Log directly from commit.
-
-Commit message should include three parts: Header, Body and Footer. Among them, Header is required, Body and Footer can be omitted.
-
-##### Header
-
-The header part has only one line, including three fields: type (required), scope (optional), and subject (required).
+```
+[Type-ISSUE_ID][Scope] Subject
 
-[DS-ISSUE number][type] subject
+(optional body — bullet list of the main changes)
 
-(1) Type is used to indicate the category of commit, and only the following 7 types are allowed.
+(optional footer — BREAKING CHANGE / Closes #xxx)
+```
 
-- feat：features
-- fix：Bug fixes
-- docs：Documentation
-- style： Format (does not affect changes in code operation)
-- refactor：Refactoring (It is not a new feature or a code change to fix a bug)
-- test：Add test
-- chore：Changes in the build process or auxiliary tools
+Header is required; body and footer are optional. Aim for a Subject under 72 characters so it does not get truncated on GitHub.
 
-If the type is feat and fix, the commit will definitely appear in the change log. Other types (docs, chore, style, refactor, test) are not recommended.
+### Type (required)
 
-(2) Scope
+|     Type      |                                                When to use                                                |  Issue ID required?  |
+|---------------|-----------------------------------------------------------------------------------------------------------|----------------------|
+| `Feature`     | A new user-visible feature                                                                                | Yes                  |
+| `Improvement` | Enhancement to an existing feature (refactor, perf, UX polish)                                            | Yes                  |
+| `Fix`         | Bug fix                                                                                                   | Yes                  |
+| `Doc`         | Documentation only                                                                                        | Yes                  |
+| `DSIP`        | A change implementing a [DSIP](https://github.com/apache/dolphinscheduler/issues?q=label%3ADSIP) proposal | Yes (the DSIP issue) |
+| `Chore`       | Build, CI, test scaffolding, dependency bumps, trivial cleanup                                            | No                   |
 
-Scope is used to indicate the scope of commit impact, such as server, remote, etc. If there is no suitable scope, you can use \*.
+Every type **except `Chore`** must carry an Issue ID. If no Issue exists for the change, file one first or reclassify it as `Chore`.
 
-(3) subject
+### Scope (optional)
 
-Subject is a short description of the purpose of the commit, no more than 50 characters.
+The module the change touches: `Master`, `Worker`, `API`, `UI`, `TaskPlugin`, `Dao`, etc. Match a real module name. Omit `[Scope]` when the change is genuinely cross-cutting (most `Chore` commits).
 
-##### Body
+### Subject (required)
 
-The body part is a detailed description of this commit, which can be divided into multiple lines, and the line break will wrap with 72 characters to avoid automatic line wrapping affecting the appearance.
+A short imperative sentence describing the change.
 
-Note the following points in the Body section:
+- Use the imperative mood: *Add*, *Fix*, *Remove* — not *Added* / *Adds*.
+- State the **purpose**, not the implementation detail. The diff already shows the *how*.
+- No trailing period.
 
-- Use the verb-object structure, note the use of present tense. For example, use change instead of changed or changes
+### Body (optional, recommended for non-trivial changes)
 
-- Don't capitalize the first letter
+When the change is not self-evident from the Subject, add a bullet list of the main changes. Keep it tight — one line per change point. Lengthy rationale, design notes, or testing plans go in the **Pull Request description** (see [PULL_REQUEST_TEMPLATE.md](https://github.com/apache/dolphinscheduler/blob/dev/.github/PULL_REQUEST_TEMPLATE.md)), not in the commit message.
 
-- The end of the sentence does not need a ‘.’ (period)
+### Footer (optional)
 
-##### Footer
+- `BREAKING CHANGE: <description>` — for incompatible changes. Required if the change breaks RPC, DB schema, or public API compatibility. Also add an entry to `docs/docs/en/guide/upgrade/incompatible.md`.
+- `Closes #1234` — to auto-close the linked issue on merge.
 
-Footer only works in two situations
+## Examples
 
-(1) Incompatible changes
+Good:
 
-If the current code is not compatible with the previous version, the Footer part starts with BREAKING CHANGE, followed by a description of the change, the reason for the change, and the migration method.
+```
+[Fix-18201][TaskPlugin] Fix RemoteShell task NullPointerException on empty stdout
+```
 
-(2) Close Issue
+```
+[Improvement-18224][API] Migrate EnvironmentService to typed return values
 
-If the current commit is for a certain issue, you can close the issue in the Footer section, or close multiple issues at once.
+- Replace Map<String, Object> returns with dedicated DTOs
+- Update controller and unit tests accordingly
+```
 
-##### For Example
+```
+[Chore][API] Remove deprecated ProjectService#checkProjectAndAuth
+```
 
 ```
-[DS-001][docs-en] add commit message
+[Feature-17900][Master] Support task-group priority override at runtime
 
-- commit message RIP
-- build some conventions
-- help the commit messages become clean and tidy
-- help developers and release managers better track issues
-  and clarify the optimization in the version iteration
+- Add priority field to TaskGroupQueue
+- Honor override when dispatching ready tasks
 
-This closes #001
+Closes #17900
 ```
 
-### Reference documents
+Avoid:
+
+- `fix bug` — no type prefix, no scope, no information.
+- `[fix] update master` — wrong casing, missing issue ID, vague subject.
+- `[Improvement][Master] refactor scheduler to use new state machine and also fix a NPE in worker dispatch and adjust some logs` — multiple unrelated changes; split into separate commits.
 
-[Commit message format](https://cwiki.apache.org/confluence/display/GEODE/Commit+Message+Format)
+## References
 
-[On commit messages-Peter Hutterer](http://who-t.blogspot.com/2009/12/on-commit-messages.html)
+- [PULL_REQUEST_TEMPLATE.md](https://github.com/apache/dolphinscheduler/blob/dev/.github/PULL_REQUEST_TEMPLATE.md)
+- [Pull Request Notice](./pull-request.md)
+- [Apache Geode commit message format](https://cwiki.apache.org/confluence/display/GEODE/Commit+Message+Format)
+- [On commit messages — Peter Hutterer](http://who-t.blogspot.com/2009/12/on-commit-messages.html)
 
-[RocketMQ Community Operation Conventions](https://mp.weixin.qq.com/s/LKM4IXAY-7dKhTzGu5-oug)

docs/docs/en/contribute/join/pull-request.md

@@ -82,8 +82,11 @@ Please refer to the commit message section.
 [//]: # (DolphinScheduler uses `Spotless` to automatically fix code style and formatting errors,)
 [//]: # (see [Development Environment Setup](../development-environment-setup.md#code-style) `Code Style` section for details.)
 
-DolphinScheduler uses `Spotless` to automatically fix code style and formatting errors,
-see [Development Environment Setup](../development-environment-setup.md) `Code Style` section for details.
+DolphinScheduler uses `Spotless` to enforce code style and formatting. It covers Java sources, `pom.xml`, and Markdown files (including the docs in this directory).
+
+**Before opening a Pull Request, you must run `./mvnw spotless:apply` locally and commit the result.** CI runs `./mvnw spotless:check` and will fail the PR if any file is not formatted.
+
+See [Development Environment Setup](../development-environment-setup.md) `Code Style` section for details.
 
 ### Question
 

docs/docs/en/contribute/join/submit-code.md

@@ -42,7 +42,9 @@ git checkout -b xxx origin/dev
 ```
 
 Make sure that the branch `xxx` is building successfully on the latest code of the official dev branch
-* After modifying the code locally in the new branch, submit it to your own repository:
+* After modifying the code locally in the new branch, run `./mvnw spotless:apply` to apply project formatting before committing. CI runs `./mvnw spotless:check` and will fail the PR if any file is not formatted (see [Pull Request Code Style](./pull-request.md#pull-request-code-style)).
+
+* Submit it to your own repository:
 
 `git commit -m 'commit content'`