开源世界规则导览¶
开源允许广泛参与，但并不意味着没有规则。本页是第三节的入口：先给出学习目标与内容地图，再提供两张可填写的工作表（项目入口档案、沟通前检查清单），最后说明如何按课程要求写出一份贡献提案。
学习目标¶
学完本小节后，你应当能够：
- 说明一个项目的决策方式（BDFL、委员会或基金会治理）以及如何提出重大变更。
- 独立完成一份“项目入口档案”，从公开文档中找出贡献流程、沟通渠道与行为规范。
- 按“问题、价值、范围、实施方案、验证方法、潜在风险”六要素写出可评审的贡献提案。
本小节内容地图¶
| 页面 | 一句话内容 | 预计阅读时长 |
|---|---|---|
| 开源项目的运作规则 | 谁说了算：治理结构、核心角色与透明的决策机制。 | 35 分钟 |
| 贡献与回报 | 六类回报、项目是否值得投入、回报的现实面与学生参与渠道。 | 30 分钟 |
| 开源项目的法律与合规 | 许可证、版权、专利、CLA 与 DCO 等法律层面的基本规则。 | 30 分钟 |
项目入口档案¶
进入一个项目之前，先按下面的表逐项查看并记录。它就是你的“项目入口档案”，也是第 1 次课项目画像和第 4 次课贡献提案的输入材料。
| 入口文件 | 看什么 | 记什么 |
|---|---|---|
README |
项目解决什么问题、当前状态、如何安装与运行、维护状态标识 | 一句话项目定位；最近一次发布或更新的时间 |
LICENSE / COPYING |
许可证名称与 SPDX 标识符、是否双授权、是否有附加条款 | 许可证标识符；对使用与分发的具体要求 |
CONTRIBUTING |
如何报告缺陷、如何提交补丁、开发环境与代码规范、评审要求 | 贡献流程的关键步骤；是否需要 CLA 或 DCO |
CODE_OF_CONDUCT |
适用范围、举报渠道、处理流程 | 举报邮箱或表单；发生冲突时的处理路径 |
SECURITY |
漏洞报告渠道、是否接受公开 Issue、响应预期 | 正确的报告渠道；哪些细节不应公开 |
治理文档（GOVERNANCE、MAINTAINERS、ROADMAP） |
决策方式、维护者名单、晋升路径、路线图 | 治理模式（BDFL / 委员会 / 基金会）；如何成为维护者 |
| Issue 与 PR 模板 | 项目要求提供哪些信息（复现步骤、环境、检查清单） | 提交前必须补齐的字段；是否有 good first issue 标签 |
CI 配置（.github/workflows/、.gitlab-ci.yml 等） |
提交会触发哪些检查、能否在本地运行相同检查 | 本地需要运行的命令；常见失败原因 |
填写时只记录能从公开信息确认的内容，查不到就写“未找到”。具体规则以目标项目当前公开的文档为准，本表只是检查清单。
沟通前的检查清单¶
提交 Issue 或提问之前，逐项确认：
- 搜索过重复：用关键词、标签和已关闭的 Issue/PR 搜索，确认问题没有被提出或解决过。
- 有最小可复现：给出最小代码或命令、版本与依赖、期望结果、实际结果，以及完整的错误日志（用文本而不是截图）。
- 写清背景与尝试：说明我在做什么、环境是什么、已经尝试过哪些方法及结果。
- 标题描述现象：标题写清“什么情况下出现什么现象”，不要只写“求助”或“有 bug”。
- 选对渠道：按
CONTRIBUTING指定的渠道（Issue、讨论区、邮件列表或聊天频道）提问，不要同时多处重复投递。 - 尊重沟通规范：使用项目语言与礼貌句式，说明自己的期望（确认问题、给出方向还是评审补丁），不 @ 多人、不催促。
- 保存记录：记录 Issue/PR 链接、时间线与维护者反馈，作为结课证据包的一部分。
提问的基本结构可以固定为三段：我在做什么 → 我看到了什么 → 我希望得到什么帮助。
提案写作¶
贡献提案可以是一个 Issue、一封邮件列表邮件或课程文档。建议按真实贡献项目要求的六要素组织：
| 要素 | 需要回答的问题 | 常见缺陷 |
|---|---|---|
| 问题 | 具体是什么缺陷或缺口？在什么场景下出现？ | 只写“优化代码”，没有可观察的现象 |
| 价值 | 修复后谁受益、以什么方式受益？ | 价值描述空泛，无法与用户或维护者关联 |
| 范围 | 要改哪些文件或模块？明确不做什么？ | 范围过大，一次捆绑多个不相关改动 |
| 实施方案 | 采用什么技术路径？有哪些取舍？ | 缺少方案比较，或与上游既有设计冲突 |
| 验证方法 | 如何证明改动有效？运行哪些测试或检查？ | 只说“测试通过”，不给出命令与结果 |
| 潜在风险 | 有哪些兼容性、性能或维护风险？ | 未考虑向后兼容与评审成本 |
示范（对应课程仓库中的文档类任务）：
问题：
docs/某页的命令示例缺少必需参数，按文档逐步执行会报错，已有读者在 Issue 中反馈。 价值：新用户按文档无法完成首次运行，修正后可以显著降低入门成本。 范围：只修改该页的示例与一处说明文字，不改动其它章节的表述与结构。 实施方案：补齐命令参数并补充预期输出；保持原有标题层级与提示框语法不变。 验证方法：本地执行mkdocs serve按文档逐步操作，确认命令可运行、页面渲染正常，并在 PR 中附上执行结果。 潜在风险：若上游命令后续变更，示例可能再次失效；已在文中注明所依据的版本。
提案的目标是让维护者在不追问的情况下就能判断“要不要做、能不能合”。写完后自查一遍：每一条是否都能被他人验证。