参与贡献

贡献不止是写代码

]project-open[ 的社区贡献包括：

• 报告可复现的问题；
• 改进中文文档与翻译；
• 提交缺陷修复或小功能；
• 分享部署经验与行业实践；
• 帮助其他用户排查问题。

对中文社区来说，文档与部署经验的价值往往高于零散的代码补丁。一个清晰的安装说明，可能比十个未维护的 fork 更有用。

报告问题

提交问题前，请先搜索是否已有相同记录。一个高质量的问题应包含：

1. 版本信息：]project-open[ 版本、数据库版本、部署方式；
2. 环境信息：操作系统、浏览器、是否使用容器；
3. 复现步骤：从哪个页面开始，做了什么操作；
4. 预期结果与实际结果；
5. 日志片段：脱敏后的错误日志，保留时间与关键堆栈；
6. 截图或录屏：涉及界面问题时附上。

请勿在公开渠道提交真实客户数据、账号口令或包含个人信息的截图。

提交补丁

代码贡献的基本流程：

Fork → 新建分支 → 修改 → 本地验证 → 提交 Pull Request → 评审 → 合并

约定：

• 一个 Pull Request 只解决一个问题；
• 提交信息说明“为什么改”，而不只是“改了什么”；
• 涉及数据库结构变更时，提供可回滚的升级脚本；
• 涉及界面的改动附截图；
• 不提交调试代码、测试数据与本地配置。

对于较大的功能，建议先提交设计说明或 issue 讨论，避免在评审阶段大幅返工。

文档贡献

文档同样走 Pull Request。写作时请注意：

• 用简体中文，术语保持一致；
• 命令与代码块可直接复制执行；
• 说明适用版本与前置条件；
• 不写“应该可以”这类不确定表述，无法验证的内容注明“待验证”；
• 截图需要打码处理客户信息。

本地开发环境

二次开发通常需要：

• PostgreSQL 与 NaviServer 可运行；
• 一份可重置的测试数据库；
• 源码以可调试方式启动；
• 常用页面的冒烟测试清单。

不要在共享测试环境直接改数据库结构；使用个人数据库或容器副本。

行为准则

社区协作遵循以下原则：

• 对事不对人，技术分歧用事实与复现步骤讨论；
• 尊重不同规模团队的实际情况，不贬低他人的技术选择；
• 不发布广告、招聘信息或与项目无关的推广内容；
• 不披露他人隐私与商业数据。

违反上述原则的内容会被删除，严重或反复违规的账号会被限制参与。

沟通渠道

• 文档与指南：本站文档区；
• 问题与建议：通过项目的问题跟踪渠道提交；
• 商业支持：访问商业服务站点获取实施与定制支持。

社区支持由志愿者提供，不承诺响应时限；生产环境的关键问题建议购买商业支持。

下一步

• 阅读架构概览
• 查看版本发布