diff --git a/i18n/zh-CN/docusaurus-plugin-content-pages/contribution-guidelines.md b/i18n/zh-CN/docusaurus-plugin-content-pages/contribution-guidelines.md
index d941cdf..c5a86f0 100644
--- a/i18n/zh-CN/docusaurus-plugin-content-pages/contribution-guidelines.md
+++ b/i18n/zh-CN/docusaurus-plugin-content-pages/contribution-guidelines.md
@@ -1,9 +1,10 @@
# IvorySQL 贡献指南
-IvorySQL 的成长离不开全球开发者、测试人员、文档作者、翻译者、社区布道者和使用者的持续参与。本页面先概述社区当前的主要贡献方式与激励政策,再说明代码贡献的具体参与流程与注意事项。
+IvorySQL 的成长离不开全球开发者、测试人员、文档作者、翻译者、社区布道者和使用者的持续参与。本页面概述社区当前的主要贡献方式与激励政策,详细的操作指南请参阅 IvorySQL 文档站。
## 贡献方式
-IvorySQL 社区始终坚持“开源无门槛,贡献无大小”。你可以根据自己的经验、兴趣和时间,选择适合自己的参与方式:
+
+IvorySQL 社区始终坚持"开源无门槛,贡献无大小"。你可以根据自己的经验、兴趣和时间,选择适合自己的参与方式:
- 代码类贡献:内核开发、功能迭代、Bug 修复、插件开发、生态工具适配、回归测试、代码评审等。
- 非代码类贡献:Issue 反馈、文档完善、技术翻译、社区问答、线上或线下技术分享、案例征集、迁移实践总结、社区推广等。
@@ -11,72 +12,81 @@ IvorySQL 社区始终坚持“开源无门槛,贡献无大小”问题复现、需求梳理、文档改进、测试建议或社区讨论开始参与。
## 激励政策
+
为鼓励更多开发者持续参与 IvorySQL 社区建设,社区也在不断完善贡献者的认可与激励机制:
- 荣誉认可:为贡献者颁发社区电子证书,并在官网贡献者墙记录社区足迹。
-- 导师支持:通过“灯塔”导师机制,提供资深开发者的一对一技术支持与 Code Review 帮助,协助贡献者成长。
+- 导师支持:通过"灯塔"导师机制,提供资深开发者的一对一技术支持与 Code Review 帮助,协助贡献者成长。
- 社区活动权益:活跃贡献者可获得 HOW 等社区活动的演讲、分享或参会机会。
- 年度激励:社区会结合全年贡献情况评选优秀贡献者,并提供周边礼品、宣传展示和更多社区合作机会。
具体激励安排会根据社区计划持续迭代,但每一类持续、真实且有价值的贡献,都会被社区认真记录与认可。
-如果你对代码贡献感兴趣,但暂时还没有明确的切入点,或者这是你第一次参与 IvorySQL,欢迎继续阅读下面的代码贡献指南,帮助你更快找到起点、降低参与门槛。
+## 社区协作流程
+
+IvorySQL 社区采用一套闭环式开源协作流程,确保从问题提出到版本发布,每一个环节都能闭合反馈、持续改进。这一流程鼓励用户与开发者形成良性互动,让社区开发始终围绕实际需求持续演进。
+
+整个协作闭环流程如下:
+
+🐛 提问题(Issue)
+
+用户或开发者在 GitHub 的 Issues 页面提交 Bug、功能建议或使用反馈。
+
+💬 问题讨论(Discussion)
+
+维护者与社区成员就问题展开讨论,确认问题性质与优先级,加入 ToDo List。
+
+🛠️ 开发分支(Fork & Dev)
+
+开发者认领 Issue,Fork 仓库并在本地开发测试,准备提交代码。
-## 代码贡献指南
-
+🚀 提交 Pull Request(PR)
-### 开始之前
-IvorySQL 主要在 GitHub 上协作开发。开始代码贡献前,建议你先完成以下准备:
+将开发分支 Push 到 Fork 仓库后,向上游仓库发起合并请求。
-- 拥有 GitHub 账号,并熟悉基本的 Git 工作流。
-- Fork 官方仓库,并在自己的仓库分支中进行开发。
-- 对于较大的需求或改动,提前关注社区讨论或邮件列表。
+🧐 代码评审(Review)
-在提交代码或文档贡献之前,个人或企业贡献者需要先签署贡献者许可协议(CLA)。请根据身份下载并签署 CLA,然后发送至 `cla@ivorysql.org`:
+维护者或核心开发者对 PR 进行评审,提出修改建议并确保质量。
-- [个人贡献者](/pdf/individual_cla.pdf)
-- [企业贡献者](/pdf/corporate_cla.pdf)
+🔀 合并主分支(Merge)
-未签署 CLA 的 Pull Request 将无法进入正式评审阶段。
+审核通过后,PR 被合并至主分支,对应的 Issue 被关闭。
-### 补丁提交
-推荐按以下流程参与代码贡献:
+📦 版本发布(Release)
-1. 从 GitHub Issues、文档待改进项、社区活动或生态需求中选择一个切入点。
-2. 如果改动较大,建议先在 Issue、PR 讨论区或邮件列表中同步思路,减少返工。
-3. Fork 仓库并创建独立分支,保持单次改动聚焦、清晰、易于审查。
-4. 完成开发、测试或文档更新后,先在本地完成自查。
-5. 向官方仓库提交 Pull Request,或通过 Issue / 讨论区等方式提交非代码类贡献。
-6. 根据评审意见继续补充提交,直至达成合并共识。
+项目定期发布新版本(每季度小版本,每年大版本),包含最新的修复与功能。
-### 编码与测试指南
-为了提高评审效率与合并质量,建议你在提交前注意以下事项:
+🧪 用户测试(Test)
-- 将较大的需求拆成多个小而独立的提交,便于审查与回归。
-- 对 C 和 C++ 相关改动尽量遵循 PostgreSQL 编码规范。
-- 对 C / Perl 代码按需运行 `pgindent`。
-- 提交前使用 `git diff --color` 检查是否有无关的空白变更。
-- 新增功能尽量补齐回归测试。
-- 至少运行 make installcheck-world,确保没有引入明显回归。
+用户升级使用新版,反馈新问题,新的 Issue 随之产生,形成完整的反馈循环。
-如果你不确定如何测试、如何补文档或如何拆分提交,可以在 `ivorysql-hackers` 邮件列表中提出问题,社区会尽力协助你完成首批贡献。
+
-### 贡献内容的许可
-如果你提交的是原创内容,可以默认它将作为 IvorySQL 的一部分,按照 Apache License 2.0 发布。
+通过这套完整的闭环协作机制,IvorySQL 实现了问题响应 → 开发贡献 → 质量保障 → 发布反馈的全流程闭合,推动项目持续健康演进。
-如果你提交的内容不是原创作品,请明确说明原始许可证,并确保其条款与 Apache License 2.0 兼容;同时按要求保留原有许可证头与归属说明。除非你非常确定可以移除,否则不要删除现有的许可声明。
+📢 请务必阅读并遵守我们的 IvorySQL社区行为准则。
-如果你不确定相关许可是否合适,建议在提交前先与社区沟通确认。
+## 快速开始
-### 与 PostgreSQL 上游相关的改动
-如果你的改动涉及 PostgreSQL 与 IvorySQL 之间的共通能力,社区可能会建议你将改动同步提交到 PostgreSQL 上游。这有助于减少两个项目之间的长期差异,也能让更通用的能力获得更广泛的审查与反馈。
+准备好参与贡献了吗?以下是开始的方式:
-### 补丁评审
-通过基础校验的 Pull Request 会进入同行评审阶段。评审的目标,是确保贡献质量符合项目标准,并与社区路线图和长期维护方向保持一致。
+1. 注册 GitHub 账号,熟悉基本的 Git 工作流
+2. 签署贡献者许可协议(CLA):
+ - [个人贡献者](/pdf/individual_cla.pdf)
+ - [企业贡献者](/pdf/corporate_cla.pdf)
+ - 提示:如果在 AtomGit 上进行贡献,可以自动完成 CLA 签署。
+3. 阅读详细贡献指南:docs.ivorysql.org,了解:
+ - 社区协作流程
+ - 代码贡献指南
+ - 生态组件适配流程
+ - 测试和文档要求
+4. 选择感兴趣的方向,找到要处理的 Issue
+5. 提交你的第一个 PR,加入社区!
-评审过程中,社区可能会提出补充提交、收敛范围、完善测试或更新文档等建议。对于开源协作来说,这种迭代是正常且有价值的过程。
+## 需要帮助?
-如果几天内没有收到预期反馈,可以在 Pull Request 下礼貌留言催更,或通过社区渠道同步说明进展。
+- 邮件列表:https://lists.ivorysql.org
+- GitHub Discussions:https://github.com/IvorySQL/IvorySQL/discussions
+- 社区群组:微信、Discord 等聊天群
-### 直接提交
-对于极小的、非功能性改动,核心团队成员有时会直接提交到仓库。但凡涉及功能行为、测试结果或用户体验的改动,原则上都应通过 Pull Request 工作流完成。
+如果你对代码贡献感兴趣,但暂时还没有明确的切入点,或者这是你第一次参与 IvorySQL,详细贡献指南将帮助你找到清晰的起点,降低参与门槛。
diff --git a/src/pages/contribution-guidelines.md b/src/pages/contribution-guidelines.md
index 48b7ff3..ca05230 100644
--- a/src/pages/contribution-guidelines.md
+++ b/src/pages/contribution-guidelines.md
@@ -1,8 +1,9 @@
# IvorySQL Contribution Guidelines
-IvorySQL grows through contributions from **developers, testers, documentation writers, translators, community advocates, and users around the world**. This page first summarizes the main ways to participate in the community and the current incentive policy, then explains the practical workflow for code contributions.
+IvorySQL grows through contributions from **developers, testers, documentation writers, translators, community advocates, and users around the world**. This page summarizes the main ways to participate in the community and the current incentive policy. For detailed technical guides, please refer to our [Contribution Guide](https://docs.ivorysql.org).
## Ways to Contribute
+
The IvorySQL community believes that **open source should be approachable and that no contribution is too small**. You can participate in a way that matches your background and interests:
- **Code contributions**: kernel development, feature iteration, bug fixes, plugin development, ecosystem tool adaptation, regression tests, and code review.
@@ -11,6 +12,7 @@ The IvorySQL community believes that **open source should be approachable and th
If you are not ready to submit code yet, you can still make a meaningful contribution by **reproducing issues, clarifying requirements, improving docs, or helping other users in community discussions**.
## Incentive Policy
+
To encourage long-term participation, the IvorySQL community continues to improve how contributors are recognized and supported:
- **Recognition**: contributors may receive **community digital certificates** and be featured on the official contributor wall to record their open-source footprint.
@@ -20,63 +22,71 @@ To encourage long-term participation, the IvorySQL community continues to improv
Specific arrangements may evolve with community programs, but **sustained and valuable contributions are always taken seriously and recognized**.
-If you are interested in code contributions but are not sure where to start, or if this is your first time contributing to IvorySQL, the guide below is meant to help you find a clear entry point and lower the barrier to participation.
+## Community Collaboration Process
+
+The IvorySQL community employs a closed-loop open-source collaboration process, ensuring that every step—from issue submission to version release—receives closed feedback and continuous improvement. This process encourages positive interaction between users and developers, allowing community development to evolve around actual needs.
+
+The entire closed-loop collaboration process is as follows:
+
+🐛 **Submit Issue**
+
+Users or developers submit bugs, feature suggestions, or usage feedback on the GitHub Issues page.
+
+💬 **Discussion**
+
+Maintainers and community members discuss the issue, confirm its nature and priority, and add it to the ToDo List.
+
+🛠️ **Development Branch (Fork & Dev)**
+
+Developers claim the Issue, fork the repository, develop and test locally, and prepare to submit code.
-## Code Contribution Guide
-
+🚀 **Submit Pull Request (PR)**
-### Getting Started
-IvorySQL development and collaboration happen on **GitHub**. Before contributing, it is recommended that you:
+Push the development branch to the forked repository and initiate a merge request to the upstream repository.
-- Have a GitHub account and be familiar with basic Git workflows.
-- Fork the official repository and work on a dedicated branch in your own fork.
-- Follow community discussions or mailing lists when relevant, especially for larger proposals.
+🧐 **Code Review**
-Before submitting any code or documentation contributions, individual or corporate contributors are required to sign the **Contributor License Agreement (CLA)**. Please download, sign, and send the CLA to `cla@ivorysql.org`:
+Maintainers or core developers review the PR, provide modification suggestions, and ensure quality.
-- [Individual contributor](/pdf/individual_cla.pdf)
-- [Corporate contributor](/pdf/corporate_cla.pdf)
+🔀 **Merge to Main Branch**
-**Pull requests from contributors who have not signed the CLA cannot proceed to formal review.**
+After approval, the PR is merged into the main branch, and the corresponding Issue is closed.
-### Patch Submission
-We recommend the following contribution flow:
+📦 **Release**
-1. Choose an entry point from GitHub issues, documentation gaps, community activities, or ecosystem needs.
-2. For larger changes, discuss the proposal first in an issue, pull request thread, or mailing list to reduce rework.
-3. Fork the repository and create a focused branch for one self-contained change.
-4. Complete the implementation, tests, or documentation updates and review your own changes locally.
-5. Submit a pull request to the official repository, or use issues and discussions for non-code contributions.
-6. Respond to review feedback, push follow-up commits when needed, and iterate until the change is ready to merge.
+The project regularly releases new versions (minor versions quarterly, major versions annually), including the latest fixes and features.
-### Coding and Testing Guidelines
-To improve review quality and merge efficiency, we recommend the following:
+🧪 **User Testing**
-- Split larger ideas into a series of small, self-contained commits whenever possible.
-- Follow PostgreSQL coding conventions for C and C++ related changes.
-- Run `pgindent` for C and Perl code when needed.
-- Use `git diff --color` before submission to catch accidental whitespace-only changes.
-- Add regression tests for new functionality whenever possible.
-- At minimum, run **`make installcheck-world`** to ensure your changes do not introduce obvious regressions.
+Users upgrade to the new version, provide feedback on new issues, and new Issues are generated, forming a complete feedback loop.
-If you are unsure how to test or document a change, ask on the `ivorysql-hackers` mailing list and the community will do its best to help.
+
-### Licensing of Contributions
-If the contribution you are submitting is original work, you can assume it will be released as part of IvorySQL under the Apache License, Version 2.0.
+Through this complete closed-loop collaboration mechanism, IvorySQL achieves full-process closure of issue response → development contribution → quality assurance → release feedback, promoting the continuous healthy evolution of the project.
-If the contribution is not original work, you must clearly indicate the original license and ensure it is compatible with Apache License 2.0 terms. Proper attribution may also be required. In general, never remove an existing license header from third-party or previously licensed work unless you are absolutely certain it is appropriate to do so.
+📢 Please read and abide by our [IvorySQL Community Code of Conduct](https://github.com/IvorySQL/IvorySQL/blob/master/CODE_OF_CONDUCT_CN.md).
-If you are unsure about the licensing implications of your contribution, please contact the community before submitting it.
+## Getting Started
-### Changes Applicable to PostgreSQL Upstream
-If your change touches functionality shared by PostgreSQL and IvorySQL, the community may ask you to forward-port or propose the change upstream. This helps reduce long-term divergence between the two projects and gives broadly useful changes access to wider review in the PostgreSQL ecosystem.
+Ready to start contributing? Here's how to begin:
-### Patch Review
-A submitted **pull request with passing checks** is considered available for peer review. Review feedback helps ensure that changes are aligned with project quality standards, roadmap direction, and community expectations.
+1. **Register a GitHub account** and familiarize yourself with basic Git workflows
+2. **Sign the Contributor License Agreement (CLA)**:
+ - [Individual contributor](/pdf/individual_cla.pdf)
+ - [Corporate contributor](/pdf/corporate_cla.pdf)
+ - **Note**: If you contribute via AtomGit, the CLA signing can be completed automatically.
+3. **Read the detailed contribution guide** at [docs.ivorysql.org](https://docs.ivorysql.org) to understand:
+ - Community collaboration process
+ - Code contribution guidelines
+ - Ecosystem component adaptation workflow
+ - Testing and documentation requirements
+4. **Choose an area of interest** and find an Issue to work on
+5. **Submit your first PR** and join the community!
-Possible review outcomes include requests for additional commits, changes in scope, testing improvements, or documentation updates. Please do not be discouraged by iteration; it is a normal part of open-source collaboration.
+## Need Help?
-When feedback is delayed, it is fine to leave a polite comment on the pull request or ask for an update through the community channels.
+- **Mailing list**: https://lists.ivorysql.org
+- **GitHub Discussions**: https://github.com/IvorySQL/IvorySQL/discussions
+- **Community groups**: WeChat, Discord, and other chat groups
-### Direct Commits
-Small non-functional fixes may occasionally be committed directly by core team members. Changes that affect behavior, testing, or product functionality should go through the pull request workflow.
+If you are interested in code contributions but are not sure where to start, or if this is your first time contributing to IvorySQL, the [detailed contribution guide](https://docs.ivorysql.org) will help you find a clear entry point and lower the barrier to participation.
diff --git a/static/img/p23.jpg b/static/img/p23.jpg
new file mode 100644
index 0000000..63990ac
Binary files /dev/null and b/static/img/p23.jpg differ