Update contribution guidelines pages

i18n/zh-CN/docusaurus-plugin-content-pages/community-page.md

@@ -11,7 +11,7 @@ IvorySQL社区包括来自世界各地的开发和使用开源数据库的人员
 
 ---
 
-阅读 [**贡献准则**](https://www.ivorysql.org/zh-CN/contribution-guidelines)
+阅读 [**贡献指南**](https://www.ivorysql.org/zh-CN/contribution-guidelines)
 
 ---
 

i18n/zh-CN/docusaurus-plugin-content-pages/contribution-guidelines.md

@@ -1,62 +1,82 @@
-# 项目贡献流程
-![process](/img/process_cn.png)
+# IvorySQL 贡献指南
 
-# 贡献
-IvorySQL由一个核心开发团队维护，该团队拥有对GitHub上的IvorySQL主存储库的提交权限。同时，我们非常渴望从更广泛的IvorySQL社区中的成员那里获得贡献。如果您希望看到您的代码或文档更改被添加到IvorySQL并出现在将来的版本中，本节的内容介绍是您需要知道的。
+IvorySQL 的成长离不开<strong>全球开发者、测试人员、文档作者、翻译者、社区布道者和使用者的持续参与</strong>。本页面先概述社区当前的主要贡献方式与激励政策，再说明代码贡献的具体参与流程与注意事项。
 
-# 开始
-IvorySQL是在GitHub上开发的，任何希望对其作出贡献的人都必须拥有GitHub帐户，并熟悉Git工具和工作流。还建议您遵循开发人员的邮件列表，因为一些贡献可能会在那里产生更详细的讨论。
+## 贡献方式
+IvorySQL 社区始终坚持<strong>“开源无门槛，贡献无大小”</strong>。你可以根据自己的经验、兴趣和时间，选择适合自己的参与方式：
 
-如果您有GitHub帐户，fork这个存储库，这样您就可以拥有您的私人副本来开始hacking，并将其用作拉取请求的来源。
+- <strong>代码类贡献</strong>：内核开发、功能迭代、Bug 修复、插件开发、生态工具适配、回归测试、代码评审等。
+- <strong>非代码类贡献</strong>：Issue 反馈、文档完善、技术翻译、社区问答、线上或线下技术分享、案例征集、迁移实践总结、社区推广等。
 
-在提交代码或文档贡献之前，个人或企业贡献者需要签署贡献者许可协议(CLA)。签署CLA是IvorySQL社区接受贡献的必要条件，以确保您的贡献被合法分发。请根据下列链接下载CLA进行签署并将签署后的CLA发送至 [email protected]。
+如果你暂时还不准备直接修改代码，也完全可以先从<strong>问题复现、需求梳理、文档改进、测试建议或社区讨论</strong>开始参与。
 
-- [个人贡献者](/pdf/individual_cla.pdf)
-- [企业贡献者](/pdf/corporate_cla.pdf)
+## 激励政策
+为鼓励更多开发者持续参与 IvorySQL 社区建设，社区也在不断完善贡献者的认可与激励机制：
 
-未签署CLA的Pull Request将无法进入评审阶段。
+- <strong>荣誉认可</strong>：为贡献者颁发<strong>社区电子证书</strong>，并在官网<a href="https://www.ivorysql.org/zh-cn/contributors" target="_blank" rel="noopener noreferrer">贡献者墙</a>记录社区足迹。
+- <strong>导师支持</strong>：通过<strong>“灯塔”导师机制</strong>，提供资深开发者的一对一技术支持与 Code Review 帮助，协助贡献者成长。
+- <strong>社区活动权益</strong>：活跃贡献者可获得 <strong>HOW</strong> 等社区活动的演讲、分享或参会机会。
+- <strong>年度激励</strong>：社区会结合全年贡献情况评选优秀贡献者，并提供周边礼品、宣传展示和更多社区合作机会。
 
-# IvorySQL贡献的许可
-如果您提交的贡献是原创作品，那么您可以假设IvorySQL将作为整个IvorySQL版本的一部分发布给下游用户，该版本将遵循Apache许可证2.0版本。
+具体激励安排会根据社区计划持续迭代，但<strong>每一类持续、真实且有价值的贡献，都会被社区认真记录与认可</strong>。
 
-如果您提交的内容不是原创作品，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布。请注意需要满足如下条件：
+如果你对代码贡献感兴趣，但暂时还没有明确的切入点，或者这是你第一次参与 IvorySQL，欢迎继续阅读下面的代码贡献指南，帮助你更快找到起点、降低参与门槛。
 
-1、需要给代码的用户一份Apache许可证。
+## 代码贡献指南
+![process](/img/process_cn.png)
 
-2、如果您修改了代码，需要在被修改的文件中说明。
+### 开始之前
+IvorySQL 主要在 <strong>GitHub</strong> 上协作开发。开始代码贡献前，建议你先完成以下准备：
 
-3、在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议、商标、专利声明和其他原来作者规定需要包含的说明。
+- 拥有 GitHub 账号，并熟悉基本的 Git 工作流。
+- Fork 官方仓库，并在自己的仓库分支中进行开发。
+- 对于较大的需求或改动，提前关注社区讨论或邮件列表。
 
-4、如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache许可证。您可以在Notice中增加自己的许可，但不可以表现为对Apache许可证构成更改。
+在提交代码或文档贡献之前，个人或企业贡献者需要先签署<strong>贡献者许可协议（CLA）</strong>。请根据身份下载并签署 CLA，然后发送至 `[email protected]`：
+
+- [个人贡献者](/pdf/individual_cla.pdf)
+- [企业贡献者](/pdf/corporate_cla.pdf)
 
-最后，请记住，从非原始的工作中删除许可标头从来都不是一个好主意。即使您使用的文件部分最初在顶部有许可标头，您也应该保留它。与往常一样，如果您不太确定您的贡献所涉及的许可问题，请随时在开发人员邮件列表中联系我们。
+<strong>未签署 CLA 的 Pull Request 将无法进入正式评审阶段。</strong>
 
-# 编码指南
-您获得反馈和看到代码合并到项目中的机会在很大程度上取决于更改的粒度。如果您的想法发生了更大的变化，我们强烈建议您在花大量时间编写代码之前，先加入开发人员的邮件列表，并与我们分享您的建议。即使您的建议得到社区的验证，我们仍然建议您将实际工作作为一系列小型的、独立的提交来完成。这使得评审员的工作更加容易，并提高了反馈的及时性。
+### 补丁提交
+推荐按以下流程参与代码贡献：
 
-当谈到IvorySQL的C和C++部分时，我们尝试遵循PostgreSQL编码约定。除此之外：
+1. 从 GitHub Issues、文档待改进项、社区活动或生态需求中选择一个切入点。
+2. 如果改动较大，建议先在 Issue、PR 讨论区或邮件列表中同步思路，减少返工。
+3. Fork 仓库并创建独立分支，保持单次改动聚焦、清晰、易于审查。
+4. 完成开发、测试或文档更新后，先在本地完成自查。
+5. 向官方仓库提交 Pull Request，或通过 Issue / 讨论区等方式提交非代码类贡献。
+6. 根据评审意见继续补充提交，直至达成合并共识。
 
-对于C和Perl代码，如果需要，请运行pgindent。我们建议在查看更改时使用git diff--color，这样您提交的代码中就不会出现任何虚假的空白问题。
+### 编码与测试指南
+为了提高评审效率与合并质量，建议你在提交前注意以下事项：
 
-所有贡献给IvorySQL的新功能都应该由与其一起贡献的回归测试覆盖。如果您不确定如何测试或记录您的工作，请在ivorysql-hackers邮件列表中提出问题，社区的开发人员将尽力帮助您。
+- 将较大的需求拆成多个小而独立的提交，便于审查与回归。
+- 对 C 和 C++ 相关改动尽量遵循 PostgreSQL 编码规范。
+- 对 C / Perl 代码按需运行 `pgindent`。
+- 提交前使用 `git diff --color` 检查是否有无关的空白变更。
+- 新增功能尽量补齐回归测试。
+- 至少运行 <strong><code>make installcheck-world</code></strong>，确保没有引入明显回归。
 
-至少，您应该始终运行make installcheck world，以确保您没有破坏任何东西。
+如果你不确定如何测试、如何补文档或如何拆分提交，可以在 `ivorysql-hackers` 邮件列表中提出问题，社区会尽力协助你完成首批贡献。
 
-# 适用于上游PostgreSQL的更改
-如果您正在进行的更改涉及PostgreSQL和IvorySQL之间的通用功能，则可能会要求您将其转发到PostgreSQL。这不仅是为了我们不断减少两个项目之间的差异，而且是为了让与PostgreSQL相关的任何变化都能从对上游PostgreSQL社区更广泛的审查中受益。一般来说，将这两个代码库都放在手边是个好主意，这样您就可以确定您的更改是否需要前移。
+### 贡献内容的许可
+如果你提交的是原创内容，可以默认它将作为 IvorySQL 的一部分，按照 Apache License 2.0 发布。
 
-# 补丁提交
-一旦您准备好与IvorySQL核心团队和IvorySQL社区的其他成员共享您的工作，您应该将所有提交推送到从官方IvorySQL派生的分支的您自己的存储库中，并向我们发送请求。
+如果你提交的内容不是原创作品，请明确说明原始许可证，并确保其条款与 Apache License 2.0 兼容；同时按要求保留原有许可证头与归属说明。除非你非常确定可以移除，否则不要删除现有的许可声明。
 
-# 补丁审查
-假定提交的拉取请求通过验证检查，可供同行审查。同行审查是确保对IvorySQL的贡献具有高质量并与路线图和社区期望保持一致的过程。我们鼓励IvorySQL社区的每个成员审查请求并提供反馈。由于您不必成为核心团队成员就可以做到这一点，因此我们建议您向有兴趣成为IvorySQL长期贡献者的任何人提供一系列拉动式评论。
+如果你不确定相关许可是否合适，建议在提交前先与社区沟通确认。
 
-同行评审的一个结果可能是达成共识，即您需要以某些方式修改pull请求。GitHub允许您将其他提交推送到从中发送请求的分支中。这些额外的提交将对所有审阅者可见。
+### 与 PostgreSQL 上游相关的改动
+如果你的改动涉及 PostgreSQL 与 IvorySQL 之间的共通能力，社区可能会建议你将改动同步提交到 PostgreSQL 上游。这有助于减少两个项目之间的长期差异，也能让更通用的能力获得更广泛的审查与反馈。
 
-当同行评议收到参与者至少+1张+1和no-1张的选票时，同行评议会趋于一致。在这一点上，您应该期望核心团队成员之一将您的更改引入到项目中。
+### 补丁评审
+通过基础校验的 <strong>Pull Request</strong> 会进入同行评审阶段。评审的目标，是确保贡献质量符合项目标准，并与社区路线图和长期维护方向保持一致。
 
-在补丁审查期间的任何时候，您都可能会因审查人员和核心团队成员的工作效率而遇到延迟。请耐心点，也不要气馁。如果您在几天内没有收到预期的反馈，请添加一条评论，要求更新pull请求本身，或者向邮件列表发送一封电子邮件。
+评审过程中，社区可能会提出补充提交、收敛范围、完善测试或更新文档等建议。对于开源协作来说，这种迭代是正常且有价值的过程。
 
-# 直接提交到存储库
-有时，您会看到核心团队成员直接提交到存储库，而无需执行pull请求工作流。这仅适用于小的更改，我们使用的经验法则是：如果更改涉及任何可能导致测试失败的功能，那么它必须通过pull请求工作流。另一方面，如果更改发生在代码库的非功能部分（例如在注释块中修复打字错误），则核心团队成员可以决定直接提交到存储库。
+如果几天内没有收到预期反馈，可以在 Pull Request 下礼貌留言催更，或通过社区渠道同步说明进展。
 
+### 直接提交
+对于极小的、非功能性改动，核心团队成员有时会直接提交到仓库。但凡涉及功能行为、测试结果或用户体验的改动，原则上都应通过 Pull Request 工作流完成。

i18n/zh-CN/docusaurus-theme-classic/navbar.json

@@ -44,7 +44,7 @@
     "description": "Navbar item with label Online Trial"
   },
   "item.label.Contribution Guidelines": {
-    "message": "贡献准则",
+    "message": "贡献指南",
     "description": "Navbar item with label Contribution Guidelines"
   },
   "item.label.Report an issue": {

src/data/contributors.js

@@ -123,7 +123,7 @@ const CONTRIBUTOR_OVERRIDES = {
   stevenniu: { name: 'Steven Niu', github: 'bigplaice' },
   xiaohuiliu: { name: 'Xiaohui Liu', github: 'hs-liuxh' },
   xiangyuliang: { name: 'Xiangyu Liang', github: 'balinorLiang' },
-  xinjielyu: { name: 'Xinjie Lyu' },
+  xinjielyu: { name: 'Xinjie Lyu', github: null },
   xueyugao: { name: 'Xueyu Gao', github: 'gaoxueyu' },
   yanlianglei: { name: 'Yanliang Lei', github: 'msdnchina' },
   yasirhussainshah: { name: 'Yasir Hussain Shah', github: 'yasir-hussain-shah' },
@@ -221,11 +221,14 @@ export const contributors = Array.from(contributorMap.values())
   .map((item) => {
     const override = CONTRIBUTOR_OVERRIDES[item.id] || {};
     const years = Array.from(item.years).sort((a, b) => b - a);
+    const github = Object.prototype.hasOwnProperty.call(override, 'github')
+      ? override.github
+      : (item.github || null);
 
     return {
       id: item.id,
       name: override.name || humanizeContributorName(item.displaySlug),
-      github: override.github || item.github || null,
+      github,
       avatarSrc: override.avatarSrc || null,
       avatarMode: override.avatarMode || null,
       years,