-
Notifications
You must be signed in to change notification settings - Fork 292
对开源贡献的理解
大家一般都认为开源贡献就是给开源项目提PR、编写代码。其实这不完全正确。
一个开源项目和一个普通的公司项目并没有太多的不同，都是为了用户提供某种价值，可能是解决用户的痛点问题、也可能是提升用户做某些事情的效率。
一个开源项目可能包含很多组成部分，初始可能只有一个基础的框架，比如vue devui项目就包含：
- 一个基于vite的基础工程，这个基础框架工程会集成vue3+TypeScript+JSX+单元测试+各种Lint工具
- 从这个基础框架出发，包含一个组件库，这是对外提供的最核心的部分
- 一个用于演示组件库功能的文档系统
- 一个cli工具，用来做一些自动化的事情，比如自动生成组件模板、构建组件库产物等
从以上组成部分可以看出，贡献可能包括：
- 编写一个新组件，成为这个组件的田主
- 每个组件需要配套的中英文文档
- 保障组件质量的单元测试
- 工程化配套工具的完善（需要深度参与进来才能识别到我们需要什么工具，从而不断完善）
- 组件会出bug，文档会出bug，修复这些缺陷也是一种贡献
- 再继续推演，发现组件或文档的bug，顺手提个issue，也是一种贡献
- 组件的第一个版本不一定是最完美的，它的api、它的源码可能需要完善和重构，对组件的优化也是一种贡献
- 当有社区开发者给开源项目提了一个issue，没有选择一个标签，你发现了，顺手给issue加了个标签，这样其他刚加入这个开源项目的开发者看到标签，能一眼就知道这个issue，自己是否感兴趣，有没有能力解决
- 如果有人提了一个pr，看到pr的标题，你觉得他做的这个功能你很感兴趣，想了解下别人是怎么实现的，这时就可以去检视代码（检视代码的过程你可以理解成一个与pr作者交流的机会，如果你理解了他的代码，觉得写的很妙，可以在评论里给他写一句鼓励的话；如果你觉得写的不好，可以友善地评论一句可以优化的地方，pr作者一定会感谢你的友善行为，并给你一个友善的回馈；如果你没看懂他写的代码，你也可以积极地询问不理解的地方，与pr作者进行友善的探讨，在这个互动和讨论的过程中，相信你一定能有所收获），检视代码也是一种贡献，也许一行代码也没写
- 随着开源项目的不断演进，会有更多的小伙伴加入进来，刚进来的小伙伴对这个社区是很陌生的，比如vue devui有一个微信群，新成员加入都会加入到群里，这时你给新成员打个招呼，欢迎下新加入的小伙伴，我觉得这也是对开源项目的一种贡献，因为你在无形之中让这个社区变得更温暖
- 继续推演，开源社区里面每个成员的背景、经验、能力都不一样，刚加入的小伙伴可能会有很多疑问，并在群里求助，你发现他提出的问题，你正好知道，并给出了自己的思路，让提问者豁然开朗，更快地找到问题的答案，并有所收获，这也是一种贡献
- 由于经常遇到相同的问题，你识别到了，将这些共性的问题整理成文档，放到开源项目的wiki里，后来者看到了能快速开始，这也是一种贡献
- 如果继续推演，我想也许会有更多形式的贡献，每一个让社区和开源项目变得更好的行为、语言、文字等都是一种贡献
而你与开源社区的每一次互动，都会让你对社区有更深入的了解，进而也让自己有所成长，也许只是一句友善的话、或者一个中肯的建议，都能让我们觉得温暖，我想这也许是开源项目与公司项目的不同。
我们理解了开源贡献的广泛含义，面临的第一件事可能就是：我要怎么开始呢？
开源项目的一个最大的特点就是开放透明，没有任何信息是保密的，关于该开源项目的任何东西都是完全公开的，包括：
- 开源项目的源码
- 源码的每一次变更，谁、什么时候、变更了什么内容全部通过git版本管理系统记录下来
- 项目目前有什么问题，都通过issue记录
- 项目的文档都通过wiki记录
- 目前该项目有哪些贡献者
- 谁、什么时候提了pr，pr对哪些文件、有什么变更，谁改了pr的标题、标签，谁合入了pr，全部公开透明
所以你想要了解的关于该开源项目的一切，都在源码仓库里了，对于vue devui，它的源码地址是：
https://gitee.com/devui/vue-devui
不过开源项目也会有另一个问题，就是文档可能是逐步完善和不断变化的。
因为开源项目是社区开发者一起参与贡献的，迭代速度非常快，文档很可能跟不上。
不过也并不是无处开始，任何一个开源项目都有几个关键的部分，可以了解到该项目的一些关键信息，这些信息已经足够一个入门者开始啦。
进入一个开源项目的源码地址页面，首先需要关注的是该项目的名称、简介、readme文档
看完这三部分内容，你基本上会知道这个项目是做什么的，我对它是否感兴趣，我要不要加入这个开源社区。一般readme还会包含快速开始部分，按照快速开始的步骤指引，一般能把项目启动起来。
可以启动起来之后，做什么呢？
这时可以在issue列表和看板里面找自己感兴趣、适合自己的任务
以下是vue devui的：
issue列表列出了该项目目前已经识别到的待办任务，我们可以在issue列表里看到该issue是由谁、什么时候提出的，标题大致描述了这个issue是一个什么任务：一个需要新增的特性还是待解决的缺陷，或者是需要完善的单元测试和文档，还有一个很关键的信息是issue的标签，标签一般明确标识了改issue的性质、属性或分类，我们可以根据标签来决定是否认领这个issue。
如果我们决定认领一个issue，开始贡献，可以点击issue的标题可以进入issue详情，详情一般会详细地列出该issue具体要做什么，可能会有截图用于更清晰地展示该issue，如果是一个新特性，可能会有详细的功能说明文档；如果是一个缺陷，可能会有详细的复现步骤或截图，也可能会有其他开发者的评论和讨论，我们一般可以根据这些信息，结合自己的技能完成这个issue。
如果还有issue没有提供的关键信息，我们还可以在issue下面评论我们想了解的信息，这里有一个小技巧，就是如果你想明确地让谁回应你的提问，可以在评论@那个人，这样对方会受到一个消息（站内信、邮件或者微信公众号消息），这样对方更容易注意到你的问题，并更快地相应。
除了issue列表，还有一个地方可以更方便地所有待认领、进行中、已完成的issue，那就是看板，看板可以认为是一个通过卡片的方式管理issue的地方，如果你想认领一个issue只需要将它从待办那一列拖动到进行中即可，非常便捷。
有些项目可能会整理一些wiki文档，用来详细地记录和这个项目有关的一切，相比README和issue，Wiki的内容更加详尽和丰富。
比如vue devui的wiki就沉淀了很多文档：
- 快速开始
- 贡献者花名册
- JSX简明语法
- DevUI CLI 功能介绍
- ...
如果你不知道怎么开始，就去看看文档，相信很快就会有思路啦~
前面给大家分享了贡献的形式，除了提交代码之外，还有很多贡献的形式，比如检视PR，检视PR不仅仅是阅读别人的代码，它更像是一种与pr作者的交流，积极参与代码检视，相信你一定能有所收获的。
如果看文档不过瘾，不妨fork一份源码，将其clone到本地，跑起来看看，近距离观察下这个开源项目长什么样子。
看看它的源码结构，尝试它的每个部分代表什么含义，尝试在源码里加点东西，看下会有什么变化。
一旦你按照以上的步骤过了一遍开源项目，你对开源项目就有了最初步的认识，下一步就是多与该开源社区的其他开发者交流：
- 在群里讨论技术问题
- 在pr检视代码
- 认领一个
good-first-issue标签的issue试试水 - 然后逐步认领一些复杂一点的任务，可能需要做功能设计、绘制思维导图、流程图、模块图、数据流图等
- 深入到一定程度，你也可以加入开源项目的管理团队，承担更大的责任，参与路标的制定、新项目的孵化、开源生态的建设
拥抱开源，你会发现开源的巨大魅力，看到一个不一样的世界！