跳到主要内容

IvorySQL 贡献指南

IvorySQL 的成长离不开全球开发者、测试人员、文档作者、翻译者、社区布道者和使用者的持续参与。本页面先概述社区当前的主要贡献方式与激励政策，再说明代码贡献的具体参与流程与注意事项。

贡献方式​

IvorySQL 社区始终坚持“开源无门槛，贡献无大小”。你可以根据自己的经验、兴趣和时间，选择适合自己的参与方式：

  • 代码类贡献：内核开发、功能迭代、Bug 修复、插件开发、生态工具适配、回归测试、代码评审等。
  • 非代码类贡献：Issue 反馈、文档完善、技术翻译、社区问答、线上或线下技术分享、案例征集、迁移实践总结、社区推广等。

如果你暂时还不准备直接修改代码，也完全可以先从问题复现、需求梳理、文档改进、测试建议或社区讨论开始参与。

激励政策​

为鼓励更多开发者持续参与 IvorySQL 社区建设，社区也在不断完善贡献者的认可与激励机制：

  • 荣誉认可：为贡献者颁发社区电子证书，并在官网贡献者墙记录社区足迹。
  • 导师支持：通过“灯塔”导师机制，提供资深开发者的一对一技术支持与 Code Review 帮助，协助贡献者成长。
  • 社区活动权益：活跃贡献者可获得 HOW 等社区活动的演讲、分享或参会机会。
  • 年度激励：社区会结合全年贡献情况评选优秀贡献者，并提供周边礼品、宣传展示和更多社区合作机会。

具体激励安排会根据社区计划持续迭代，但每一类持续、真实且有价值的贡献，都会被社区认真记录与认可。

如果你对代码贡献感兴趣，但暂时还没有明确的切入点，或者这是你第一次参与 IvorySQL，欢迎继续阅读下面的代码贡献指南，帮助你更快找到起点、降低参与门槛。

代码贡献指南​

process

开始之前​

IvorySQL 主要在 GitHub 上协作开发。开始代码贡献前，建议你先完成以下准备：

  • 拥有 GitHub 账号，并熟悉基本的 Git 工作流。
  • Fork 官方仓库，并在自己的仓库分支中进行开发。
  • 对于较大的需求或改动，提前关注社区讨论或邮件列表。

在提交代码或文档贡献之前，个人或企业贡献者需要先签署贡献者许可协议（CLA）。请根据身份下载并签署 CLA，然后发送至 cla@ivorysql.org：

未签署 CLA 的 Pull Request 将无法进入正式评审阶段。

补丁提交​

推荐按以下流程参与代码贡献：

  1. 从 GitHub Issues、文档待改进项、社区活动或生态需求中选择一个切入点。
  2. 如果改动较大，建议先在 Issue、PR 讨论区或邮件列表中同步思路，减少返工。
  3. Fork 仓库并创建独立分支，保持单次改动聚焦、清晰、易于审查。
  4. 完成开发、测试或文档更新后，先在本地完成自查。
  5. 向官方仓库提交 Pull Request，或通过 Issue / 讨论区等方式提交非代码类贡献。
  6. 根据评审意见继续补充提交，直至达成合并共识。

编码与测试指南​

为了提高评审效率与合并质量，建议你在提交前注意以下事项：

  • 将较大的需求拆成多个小而独立的提交，便于审查与回归。
  • 对 C 和 C++ 相关改动尽量遵循 PostgreSQL 编码规范。
  • 对 C / Perl 代码按需运行 pgindent。
  • 提交前使用 git diff --color 检查是否有无关的空白变更。
  • 新增功能尽量补齐回归测试。
  • 至少运行 make installcheck-world，确保没有引入明显回归。

如果你不确定如何测试、如何补文档或如何拆分提交，可以在 ivorysql-hackers 邮件列表中提出问题，社区会尽力协助你完成首批贡献。

贡献内容的许可​

如果你提交的是原创内容，可以默认它将作为 IvorySQL 的一部分，按照 Apache License 2.0 发布。

如果你提交的内容不是原创作品，请明确说明原始许可证，并确保其条款与 Apache License 2.0 兼容；同时按要求保留原有许可证头与归属说明。除非你非常确定可以移除，否则不要删除现有的许可声明。

如果你不确定相关许可是否合适，建议在提交前先与社区沟通确认。

与 PostgreSQL 上游相关的改动​

如果你的改动涉及 PostgreSQL 与 IvorySQL 之间的共通能力，社区可能会建议你将改动同步提交到 PostgreSQL 上游。这有助于减少两个项目之间的长期差异，也能让更通用的能力获得更广泛的审查与反馈。

补丁评审​

通过基础校验的 Pull Request 会进入同行评审阶段。评审的目标，是确保贡献质量符合项目标准，并与社区路线图和长期维护方向保持一致。

评审过程中，社区可能会提出补充提交、收敛范围、完善测试或更新文档等建议。对于开源协作来说，这种迭代是正常且有价值的过程。

如果几天内没有收到预期反馈，可以在 Pull Request 下礼貌留言催更，或通过社区渠道同步说明进展。

直接提交​

对于极小的、非功能性改动，核心团队成员有时会直接提交到仓库。但凡涉及功能行为、测试结果或用户体验的改动，原则上都应通过 Pull Request 工作流完成。