Merge pull request #4 from vividctrlalt/prcheck2

docs: move type and scope reference to PR guidelines

Author: vividctrlalt

CONTRIBUTING.md

@@ -17,6 +17,7 @@ Here are some guidelines to get started quickly and easily:
   - [Branch Naming Conventions](#Branch-Naming-Conventions)
   - [Pull Request Guidelines](#Pull-Request-Guidelines)
     - [PR Title Format](#PR-Title-Format)
+    - [Type and Scope Reference](#Type-and-Scope-Reference)
     - [PR Description](#PR-Description)
   - [Special Situations And How To Deal With Them](#Special-Situations-And-How-To-Deal-With-Them)
 - [Conduct](#Conduct)
@@ -167,6 +168,66 @@ Template:
 The message header is a single line that contains succinct description of the change containing a `commit type`, an optional `scope` and a subject.
 
 `commit type` describes the kind of change that this commit is providing:
+* feat     (new feature)
+* fix      (bug fix)
+* docs     (changes to documentation)
+* style    (formatting, missing semi colons, etc. no code change)
+* refactor (refactoring production code)
+* test     (adding or refactoring tests. no production code change)
+* chore    (updating grunt tasks etc. no production code change)
+* ci       (CI/CD configuration)
+* perf     (performance improvement)
+* build    (build system changes)
+* revert   (reverting a previous commit)
+
+The `scope` can be anything specifying place of the commit change. For example: `framework`, `api`, `tvm`, `db`, `net`. For a full list of scopes, see [Type and Scope Reference](#type-and-scope-reference). You can use `*` if there isn't a more fitting scope.
+
+The subject contains a succinct description of the change:
+1. Limit the subject line, which briefly describes the purpose of the commit, to 50 characters.
+2. Start with a verb and use first-person present-tense (e.g., use "change" instead of "changed" or "changes").
+3. Do not capitalize the first letter.
+4. Do not end the subject line with a period.
+5. Avoid meaningless commits. It is recommended to use the git rebase command.
+
+Message body uses the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.
+
+Here is an example:
+```
+feat(block): optimize the block-producing logic
+
+1. increase the priority that block producing thread acquires synchronization lock
+2. add the interruption exception handling in block-producing thread
+
+Closes #1234
+```
+If the purpose of this submission is to modify one issue, you need to refer to the issue in the footer, starting with the keyword Closes, such as `Closes #1234`,if multiple bugs have been modified, separate them with commas,such as `Closes #123, #245, #992`.
+
+
+
+### Branch Naming Conventions
+1. Always name the `master` branch and `develop` branch as "master" and "develop".
+2. Name the `release_*` branch using version numbers, which are assigned by the project lead (e.g., Odyssey-v3.1.3, 3.1.3, etc.).
+3. Use `hotfix/` as the prefix of the `hotfix` branch, briefly describe the bug in the name, and connect words with underline (e.g., hotfix/typo, hotfix/null_point_exception, etc.).
+4. Use `feature/` as the prefix of the `feature` branch, briefly describe the feature in the name, and connect words with underline (e.g., feature/new_resource_model, etc.).
+### Pull Request Guidelines
+
+#### PR Title Format
+
+PR titles must follow the conventional commit format and will be checked by CI:
+
+```
+type(scope): description
+```
+
+| Rule | Requirement |
+|------|-------------|
+| Format | `type: description` or `type(scope): description` |
+| Length | 10 ~ 72 characters |
+| Type must be one of | `feat` `fix` `refactor` `docs` `style` `test` `chore` `ci` `perf` `build` `revert` |
+
+#### Type and Scope Reference
+
+**Type Reference**
 
 | Type | Purpose | Example |
 |------|---------|---------|
@@ -182,9 +243,7 @@ The message header is a single line that contains succinct description of the ch
 | `build` | Build system changes | `build: add aarch64 support for RocksDB` |
 | `revert` | Reverting a previous commit | `revert: restore ApiUtilTest.java` |
 
-The `scope` is optional and specifies the place or module of the commit change.
-
-#### Module Scopes
+**Module Scopes**
 
 | Scope | Description |
 |-------|-------------|
@@ -197,7 +256,7 @@ The `scope` is optional and specifies the place or module of the commit change.
 | `plugins` | Node tools (Toolkit, ArchiveManifest, database plugins) |
 | `protocol` | Protocol definitions, protobuf messages, gRPC contracts |
 
-#### Functional Domain Scopes
+**Functional Domain Scopes**
 
 | Scope | Description | Example |
 |-------|-------------|---------|
@@ -219,7 +278,7 @@ The `scope` is optional and specifies the place or module of the commit change.
 | `docker` | Docker containerization and deployment | `feat(docker): add ARM64 support` |
 | `version` | Version and release management | `chore(version): bump to v4.7.8` |
 
-#### Feature Scopes
+**Feature Scopes**
 
 | Scope | Description |
 |-------|-------------|
@@ -230,51 +289,6 @@ The `scope` is optional and specifies the place or module of the commit change.
 | `lite` | Lite fullnode functionality |
 | `toolkit` | Node maintenance tools (Toolkit.jar) |
 
-You can use `*` if there isn't a more fitting scope.
-
-The subject contains a succinct description of the change:
-1. Limit the subject line, which briefly describes the purpose of the commit, to 50 characters.
-2. Start with a verb and use first-person present-tense (e.g., use "change" instead of "changed" or "changes").
-3. Do not capitalize the first letter.
-4. Do not end the subject line with a period.
-5. Avoid meaningless commits. It is recommended to use the git rebase command.
-
-Message body uses the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.
-
-Here is an example:
-```
-feat(block): optimize the block-producing logic
-
-1. increase the priority that block producing thread acquires synchronization lock
-2. add the interruption exception handling in block-producing thread
-
-Closes #1234
-```
-If the purpose of this submission is to modify one issue, you need to refer to the issue in the footer, starting with the keyword Closes, such as `Closes #1234`,if multiple bugs have been modified, separate them with commas,such as `Closes #123, #245, #992`.
-
-
-
-### Branch Naming Conventions
-1. Always name the `master` branch and `develop` branch as "master" and "develop".
-2. Name the `release_*` branch using version numbers, which are assigned by the project lead (e.g., Odyssey-v3.1.3, 3.1.3, etc.).
-3. Use `hotfix/` as the prefix of the `hotfix` branch, briefly describe the bug in the name, and connect words with underline (e.g., hotfix/typo, hotfix/null_point_exception, etc.).
-4. Use `feature/` as the prefix of the `feature` branch, briefly describe the feature in the name, and connect words with underline (e.g., feature/new_resource_model, etc.).
-### Pull Request Guidelines
-
-#### PR Title Format
-
-PR titles must follow the conventional commit format and will be checked by CI:
-
-```
-type(scope): description
-```
-
-| Rule | Requirement |
-|------|-------------|
-| Format | `type: description` or `type(scope): description` |
-| Length | 10 ~ 72 characters |
-| Type must be one of | `feat` `fix` `refactor` `docs` `style` `test` `chore` `ci` `perf` `build` `revert` |
-
 #### PR Description
 
 - PR description must not be empty, minimum **20 characters**.