make installcheck-world，确保没有引入明显回归。
-至少，您应该始终运行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张的选票时，同行评议会趋于一致。在这一点上，您应该期望核心团队成员之一将您的更改引入到项目中。
+### 补丁评审
+通过基础校验的 Pull Request 会进入同行评审阶段。评审的目标，是确保贡献质量符合项目标准，并与社区路线图和长期维护方向保持一致。
-在补丁审查期间的任何时候，您都可能会因审查人员和核心团队成员的工作效率而遇到延迟。请耐心点，也不要气馁。如果您在几天内没有收到预期的反馈，请添加一条评论，要求更新pull请求本身，或者向邮件列表发送一封电子邮件。
+评审过程中，社区可能会提出补充提交、收敛范围、完善测试或更新文档等建议。对于开源协作来说，这种迭代是正常且有价值的过程。
-# 直接提交到存储库
-有时，您会看到核心团队成员直接提交到存储库，而无需执行pull请求工作流。这仅适用于小的更改，我们使用的经验法则是：如果更改涉及任何可能导致测试失败的功能，那么它必须通过pull请求工作流。另一方面，如果更改发生在代码库的非功能部分（例如在注释块中修复打字错误），则核心团队成员可以决定直接提交到存储库。
+如果几天内没有收到预期反馈，可以在 Pull Request 下礼貌留言催更，或通过社区渠道同步说明进展。
+### 直接提交
+对于极小的、非功能性改动，核心团队成员有时会直接提交到仓库。但凡涉及功能行为、测试结果或用户体验的改动，原则上都应通过 Pull Request 工作流完成。
diff --git a/i18n/zh-CN/docusaurus-theme-classic/navbar.json b/i18n/zh-CN/docusaurus-theme-classic/navbar.json
index 51d55168..9cef7ac4 100644
--- a/i18n/zh-CN/docusaurus-theme-classic/navbar.json
+++ b/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": {
diff --git a/src/data/contributors.js b/src/data/contributors.js
index 0a42c0d3..0f66ae56 100644
--- a/src/data/contributors.js
+++ b/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,
diff --git a/src/pages/contribution-guidelines.md b/src/pages/contribution-guidelines.md
index 5e65e6c9..48b7ff3a 100644
--- a/src/pages/contribution-guidelines.md
+++ b/src/pages/contribution-guidelines.md
@@ -1,55 +1,82 @@
-# Project Contribution Process
-
+# 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.
+
+## 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:
-# Contributing
-IvorySQL is maintained by a core team of developers with commit rights to the main IvorySQL repository on GitHub. At the same time, we are very eager to receive contributions from anybody in the wider IvorySQL community. This section covers all you need to know if you want to see your code or documentation changes be added to IvorySQL and appear in future releases.
+- **Code contributions**: kernel development, feature iteration, bug fixes, plugin development, ecosystem tool adaptation, regression tests, and code review.
+- **Non-code contributions**: issue reports, documentation improvements, technical translation, community Q&A, online or offline talks, case studies, migration experience sharing, and community promotion.
-# Getting started
-IvorySQL is developed on GitHub, and anybody wishing to contribute to it will have to have a GitHub account and be familiar with Git tools and workflow. It is also recommended that you follow the developer's mailing list since some of the contributions may generate more detailed discussions there.
+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**.
-Once you have your GitHub account, fork this repository so that you can have your private copy to start hacking on and to use as a source of pull requests.
+## Incentive Policy
+To encourage long-term participation, the IvorySQL community continues to improve how contributors are recognized and supported:
-Before submitting any code or documentation contributions, individual or corporate contributors are required to sign the Contributor License Agreement (CLA). Signing the CLA is a mandatory requirement for the IvorySQL community to accept contributions, ensuring your work can be legally distributed. Please download the CLA from the following link, sign it, and email the signed copy to cla@ivorysql.org.
+- **Recognition**: contributors may receive **community digital certificates** and be featured on the official contributor wall to record their open-source footprint.
+- **Mentorship**: the **"Lighthouse" mentoring model** helps contributors grow with technical guidance, one-on-one support, and code review feedback from experienced community members.
+- **Community opportunities**: active contributors may receive speaking, sharing, or participation opportunities at community events such as **HOW** and other technical activities.
+- **Annual incentives**: the community may select outstanding contributors for merchandise, public recognition, ecosystem exposure, and other collaboration opportunities.
-- [individual contributor](/pdf/individual_cla.pdf)
-- [corporate contributor](/pdf/corporate_cla.pdf)
+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.
+
+## Code Contribution Guide
+
-Pull Requests from contributors who have not signed the CLA will not proceed to the review stage.
+### Getting Started
+IvorySQL development and collaboration happen on **GitHub**. Before contributing, it is recommended that you:
-# Licensing of IvorySQL contributions
-If the contribution you're submitting is original work, you can assume that IvorySQL will release it as part of an overall IvorySQL release available to the downstream consumers under the Apache License, Version 2.0.
+- 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.
-If the contribution you're submitting is NOT original work you have to indicate the name of the license and also make sure that it is similar in terms to the Apache License 2.0. Apache Software Foundation maintains a list of these licenses under Category A. In addition to that, you may be required to make proper attributions.
+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`:
-Finally, keep in mind that it is NEVER a good idea to remove licensing headers from the work that is not your original one. Even if you are using parts of the file that originally had a licensing header at the top you should err on the side of preserving it. As always, if you are not quite sure about the licensing implications of your contributions, feel free to reach out to us on the developer mailing list.
+- [Individual contributor](/pdf/individual_cla.pdf)
+- [Corporate contributor](/pdf/corporate_cla.pdf)
-Coding guidelines
-Your chances of getting feedback and seeing your code merged into the project greatly depend on how granular your changes are. If you happen to have a bigger change in mind, we highly recommend engaging on the developer's mailing list first and sharing your proposal with us before you spend a lot of time writing code. Even when your proposal gets validated by the community, we still recommend doing the actual work as a series of small, self-contained commits. This makes the reviewer's job much easier and increases the timeliness of feedback.
+**Pull requests from contributors who have not signed the CLA cannot proceed to formal review.**
-When it comes to C and C++ parts of IvorySQL, we try to follow PostgreSQL Coding Conventions. In addition to that:
+### Patch Submission
+We recommend the following contribution flow:
-For **C** and **Perl** code, please run pgindent if necessary. We recommend using **git diff --color** when reviewing your changes so that you don't have any spurious whitespace issues in the code that you submit.
+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.
-All new functionality that is contributed to IvorySQL should be covered by regression tests that are contributed alongside it. If you are uncertain about how to test or document your work, please raise the question on the ivorysql-hackers mailing list and the developer community will do its best to help you.
+### Coding and Testing Guidelines
+To improve review quality and merge efficiency, we recommend the following:
-At the very minimum, you should always be running make installcheck-world to make sure that you're not breaking anything.
+- 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.
-# Changes applicable to upstream PostgreSQL
-If the change you're working on touches functionality that is common between PostgreSQL and IvorySQL, you may be asked to forward-port it to PostgreSQL. This is not only so that we keep reducing the delta between the two projects, but also so that any change that is relevant to PostgreSQL can benefit from a much broader review of the upstream PostgreSQL community. In general, it is a good idea to keep both codebases handy so you can be sure whether your changes may need to be forward-ported.
+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.
-# Patch submission
-Once you are ready to share your work with the IvorySQL core team and the rest of the IvorySQL community, you should push all the commits to a branch in your own repository forked from the official IvorySQL and send us a pull request.
+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.
-# Patch review
-A submitted pull request with passing validation checks is assumed to be available for peer review. Peer review is the process that ensures that contributions to IvorySQL are of high quality and align well with the road map and community expectations. Every member of the IvorySQL community is encouraged to review pull requests and provide feedback. Since you don't have to be a core team member to be able to do that, we recommend following a stream of pull reviews to anybody who's interested in becoming a long-term contributor to IvorySQL.
+If you are unsure about the licensing implications of your contribution, please contact the community before submitting it.
-One outcome of the peer review could be a consensus that you need to modify your pull request in certain ways. GitHub allows you to push additional commits into a branch from which a pull request was sent. Those additional commits will be then visible to all of the reviewers.
+### 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.
-A peer review converges when it receives at least one +1 and no -1s votes from the participants. At that point, you should expect one of the core team members to pull your changes into the project.
+### 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.
-At any time during the patch review, you may experience delays based on the availability of reviewers and core team members. Please be patient. That being said, don't get discouraged either. If you're not getting expected feedback for a few days add a comment asking for updates on the pull request itself or send an email to the mailing list.
+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.
-# Direct commits to the repository
-On occasion, you will see core team members committing directly to the repository without going through the pull request workflow. This is reserved for small changes only and the rule of thumb we use is this: if the change touches any functionality that may result in a test failure, then it has to go through a pull request workflow. If, on the other hand, the change is in the non-functional part of the codebase (such as fixing a typo inside of a comment block) core team members can decide to just commit to the repository directly.
+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.
+### 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.
diff --git a/src/pages/contributors.js b/src/pages/contributors.js
index ad170f46..a17d066e 100644
--- a/src/pages/contributors.js
+++ b/src/pages/contributors.js
@@ -28,7 +28,6 @@ const COPY = {
},
sectionTitle: 'Community Contributors',
resultLabel: 'contributors shown',
- noGithub: 'Community contributor',
empty: 'No contributors matched the current filter.',
ctaText:
'Want to appear here? Start by joining the IvorySQL contribution flow.',
@@ -54,7 +53,6 @@ const COPY = {
},
sectionTitle: '社区贡献者',
resultLabel: '位贡献者',
- noGithub: '社区贡献者',
empty: '当前筛选条件下没有匹配的贡献者。',
ctaText:
'也想出现在这里？从参与 IvorySQL 社区贡献开始。',
@@ -87,7 +85,7 @@ function ContributorCard({ contributor, copy }) {
const avatarSrc = localAvatarUrl || (showGithubAvatar
? `https://github.com/${contributor.github}.png?size=240`
: null);
- const handleText = githubUrl ? `@${contributor.github}` : '';
+ const handleText = githubUrl ? `@${contributor.github}` : null;
const yearsLabel = contributor.years.join(' · ');
return (
@@ -117,7 +115,9 @@ function ContributorCard({ contributor, copy }) {
) : (
{handleText}
+ {handleText ? ( +{handleText}
+ ) : null}