简介

基本流程

  • 挑选项目
    • 工作中接触
    • 日常使用
    • 熟悉项目使用的技术栈
    • ……
  • 发现问题
    • 代码
    • 拼写
    • 文档
    • 测试
    • ……
  • fork
  • 修改
    • 代码
    • 测试
    • 注释
    • 文档
  • 签署开源贡献协议
    • CLA
    • DCO
  • 提交 pull request
    • CI
    • review
    • merge
  • 后续
    • 关闭 issue
    • 等待 release
    • 持续贡献，成为维护者

总体原则

如何成为合格的开源项目贡献者

  • 确定你的技能和技术栈，选择与之匹配的开源项目
  • 了解开源项目的代码结构、功能和规范，并阅读其贡献指南
  • 各类贡献都可以，可以是修复 bug、添加功能、编写文档、测试等
  • 从小的修改开始，比如修改文档、拼写，增加测试代码，修复影响范围较小 bug
  • 核心流程：创建并提交 pull request (PR)，并等待其他贡献者的评审和反馈
  • 与其他贡献者保持良好的沟通和协作
  • 遵循开源项目的行为准则

非英语母语者如何更好地参与

  • 提高英语水平，尤其是阅读和写作能力，这样才能更好地理解项目的需求、文档和代码，并能够清晰地表达想法和建议
  • 选择一些有活跃社区和友好氛围的开源项目，这样可以得到更多的帮助和支持，也可以学习其他贡献者的经验和技巧
  • 遵循开源项目的贡献流程，如 fork、clone、branch、commit、push 和 pull request 等，并遵守项目的编码风格和规范
  • 在提交 issue 或 PR 时，尽量使用简单明了的英语描述问题或功能，并附上相关的截图或代码片段
  • 在与其他贡献者沟通时，保持礼貌和尊重，不要害怕提问或回答问题，并及时回复他们的评审和反馈
  • 如果对某些英语单词或表达不确定，可以使用在词典、翻译或语法检查工具进行辅助交流

如何让开源项目维护者迅速 review 自己的 PR

  • 遵循项目指南：在提交 pull request 之前，请务必查看并遵循项目的贡献指南。确保请求符合项目的规范和标准。
  • 确保代码风格一致：遵循项目的代码风格和格式要求，以减少维护者在 review 时需要修改的代码量。
  • 提供详细描述：在提交 pull request 时，确保提供足够详细的描述，说明修改如何解决问题或改进项目。
  • 提供测试用例：尽量保证新增的代码被覆盖到，有些项目会检测单测覆盖率和覆盖行。
  • 及时回复评论：一旦您的 pull request 得到 review，尽可能快地回复维护者的评论，并考虑讨论的意见和建议。

GIthub Flow

与 Gitlab Flow 区别

Github Flow:

  • Github Flow 是一种简单的工作流程，主要包括创建分支、提交代码、发送pull request和合并分支。这是一个快速迭代的流程，适用于小型团队和敏捷开发。
  • 在Github Flow 中，代码是在 master 分支上进行开发的。开发人员基于 master 创建新分支，开发并测试功能，然后向主分支发送 Pull Request，请求代码审查并将分支合并到主分支中。
  • Github Flow 适用于快速迭代和小团队，但对于大型项目可能会显得过于简单，并可能需要更严格的代码审查和测试。

GitLab Flow:

  • GitLab Flow 是基于 Github Flow 的增强版本，它更加适合大型、复杂的项目，并提供了更多的自动化和流程控制功能。
  • 在GitLab Flow 中，代码是在 feature 分支上进行开发的，类似于 Github Flow，但是它还包括了一个额外的环节——预备环节（preparation stage），用于在开发人员完成特性分支之前进行自动化测试和代码审查等操作，确保代码质量和可靠性。
  • GitLab Flow 通过打标签或者 cherry-pick 的方式来管理发布版本。

熟悉项目

开源协议

开源贡献协议

  • 开源贡献协议有 CLA（Contributor License Agreement）和 DCO （Developer Certificate of Origin）两种；
  • DCO 由 Linux Foundation 提出，是固定的简短条文（只有4条），旨在让贡献者保证遵守开源 license；
  • CLA 是对开源 license 的法律性质补充，由法务制定；
  • CLA 可以自定义，不论是个人还是企业级签署的时候都需要提供详细的信息，如姓名、公司、邮箱、地址、电话等；

CLA CI 状态示例

DCO CI 状态示例

项目结构

src, build, doc 等等

项目文档

  • LICENSE: 根据开源软件的定义，每一个开源项目必须是有开源许可协议的. 可以这么认为：假如说某个项目源码开放，但是没有任何的许可协议，那么它就不能叫做开源。
  • README: README 是一个介绍性的说明文件，对初次光临社区的人们表示欢迎，它通常会解释项目有何用处，为何发起，以及如何快速入门等。
  • CONTRIBUTING: README 文件帮助人们来认识项目，而 CONTRIBUTING 文件则是告诉人们对项目如何做贡献。它解释了目前项目需要什么样类型的贡献者，社区的流程是什么样的。并非所有的项目都会有这个文件，它某种程度上也是展示项目对于贡献者的友好程度。
  • CODE_OF_CONDUCT: 顾名思义，即是一些参与社区时的一些礼仪、说话方式、行为等，让社区形成一种友好的氛围，不是所有的项目都会撰写行为准则文件，它某种程度上也是展示项目对于贡献者的友好程度。
  • 其它文档: 有些项目也许还有其它文档，例如教程、导游，或者是治理规则，这在大型项目中常见。

项目讨论

  • Issues: 讨论项目相关问题的地方，和企业内部沟通测试 bug 的 Jira 类似。
  • Pull requests: 审核代码、以及相关的问题讨论。
  • 论坛或邮件列表: 如 Golang、Python、Linux。
  • 即时聊天: 有一些项目会使用聊天频道（诸如 Slack 、IRC、Gitter），从而能够随意的谈话、协作和快速交流。

CI

  • Github Actions
  • Travis-CI
  • ……

Pull Request

沟通交流

提高英文书面表达能力

机器翻译

  • DeepL
  • Google
  • Bing
  • 百度
  • 有道
  • 腾讯

英文检查纠错工具

  • Grammarly
    • 老牌语法检查工具，免费+付费模式，Chrome上有扩展，手机上有输入法，高级版付费。
  • LanguageTool
    • 开源免费+付费模式，支持语言比 Grammarly 多一些，比如中文。
  • QuillBot
    • 更偏向文章润色。
  • DeepL Write
    • DeepL 翻译推出的语法和文章检查工具。
  • ChatGPT/BingChat
    • 对话式机器人，可以命令它编写英文描述或者检查语法。

参考链接：