本文目录导读：
遵守开源社区规范是参与开源项目的基本素养，这不仅有助于你融入社区，也能让项目健康发展,以下是一些关键原则和具体做法：
核心原则：尊重、协作、透明
- 尊重他人：无论对方的技术水平、观点或背景如何，都应保持礼貌和友善，避免人身攻击、侮辱性语言或任何形式的歧视。
- 协作共赢：开源的核心是协作，你的贡献是为了让项目更好，而不是宣扬个人，主动帮助他人,也乐于接受他人的帮助。
- 透明公开：所有讨论、决策和代码变更都应在公开渠道（如GitHub Issue、邮件列表、聊天频道）进行,避免私下沟通关键事项。
具体行为规范
阅读并遵守《行为准则》（Code of Conduct）
- 第一步：几乎所有成熟的开源项目都有《行为准则》，《贡献者公约》（Contributor Covenant）,参与前务必仔细阅读并理解。
- 做法：如果发现有人违反准则，可以通过项目官方渠道（如维护者邮箱）举报，如果你无意中冒犯了别人,诚恳道歉并改正。
有效沟通
- 使用清晰、简洁的语言：避免行话或模糊表达，如需讨论复杂问题，用代码、截图或示例来阐述。
- 选择合适的平台：
- 问题报告 / 功能请求：使用 GitHub / GitLab 的 Issues。
- 代码贡献讨论：在 Pull Request (PR) 中评论。
- 日常交流、问答：加入项目的 Discord / Slack / Matrix 频道。
- 长期讨论：使用 邮件列表。
- 先搜索，再提问：在提问前，先搜索项目的 Issues、文档或 Wiki，很可能你的问题已经被回答过,这能节省大家的时间。
- 提问时提供足够信息：如果是报告Bug，请附上：
- 环境信息（操作系统、软件版本）。
- 复现步骤。
- 期望的行为和实际发生的行为。
- （如果是代码问题）贴出相关代码片段和错误日志。
贡献代码
- 遵循项目贡献指南（CONTRIBUTING.md）：大部分项目都有此文档，其中说明了：
- 如何 fork、克隆仓库。
- 代码风格（缩进、命名等）。
- Commit 信息的格式（
fix(api): correct typo in get endpoint）。 - 如何提交 PR 和回复审查意见。
- 发起讨论再行动：对于大的功能或重构，先在 Issue 中提出想法，与维护者和其他贡献者讨论,避免花大量时间写出一个没人想要的代码。
- 保持代码整洁、可测试：遵循项目已有的代码风格，编写测试用例,确保你的代码不会破坏现有功能。
- 耐心等待审查：维护者通常是志愿者，不一定能立刻回复，如果长时间无回应，可以在原 PR 下礼貌地 @ 询问进展。避免频繁催促。
参与讨论与审查
- 积极反馈，但避免“me too”：对其他人提出的 PR 或 Issue 提供有建设性的意见（如“这里是更好的写法”、“我发现一个隐藏问题”），纯水贴（如“+1”、“我也是”）可能会扰乱讨论，如果有同样的需求，用 GitHub 的 👍 表情表达支持更合适。
- 尊重不同观点：技术选型常有多样性，如果不同意他人的方案，冷静陈述理由，而不是否定他人,最终决定权通常在维护者手中。
- 学会说“不”：如果你需要拒绝某个不够好的 PR，礼貌地解释原因（如“这个功能可能超出项目范围”、“这里可能引入安全风险”）。
文档与知识分享
- 完善文档：如果你发现文档有误、过时或不清晰，提交 PR 进行修正,这是最容易且极受欢迎的贡献方式之一。
- 分享经验：在社区中回答新手问题，写技术博客分享你使用此项目的经验,或在会议上做演示。
常见误区与规避
- “只索取不贡献”：虽然完全合法，但长期只提问题不贡献会消耗维护者的精力，即使只是反馈了一个文档错别字,也是贡献。
- “提一个巨大的PR”：一次改几百行代码且没有拆分，会让审查非常痛苦，尽量将大的改动拆成多个逻辑清晰的、小的 PR（每个 PR 解决一个问题）。
- “在公开渠道表达负面情绪”：例如抱怨项目“设计太差”、“Bug太多”，这不仅不解决问题，还可能打击维护者的积极性，如有不满,用理性的方式反馈。
- “未经许可使用项目代码”：务必遵守项目所采用的开源许可证（如 MIT、Apache 2.0、GPL 等），GPL 许可证要求衍生代码也必须开源。
从旁观者到贡献者的一条路径
- 看：先观察社区的沟通方式、Issue 讨论风格、PR 的审查流程。
- 学：阅读《行为准则》、《贡献指南》、现有文档和代码。
- 帮：从小事做起——修正文档错别字、回答 Issue 中的简单问题、改进测试用例。
- 写：提交你的第一个 PR，哪怕只是修复一个小小的 Bug。
- 教：当经验丰富后，主动帮助新人,成为维护者或社区大使。
记住开源社区的核心是人，而不仅仅是代码。 友好、耐心、持续学习的态度,会比你的任何技术能力都更能让你赢得尊重和信任。
