如何优雅地参与开源贡献，向顶级开源项目提交 PR（Pull Request），如何更好地提交 PR?
针对这些问题和疑惑，我们邀请了 OpenAtom OpenHarmony（以下简称“OpenHarmony”）社区运营专家祝尚元，为大家分享《如何成为 OpenHarmony 社区贡献达人》。他将着重为大家讲解：社区角色定义、贡献类型、贡献前须知、贡献方式、如何处理冲突等 5 个方面，帮助大家更加高效地提 PR，助力大家成为顶级社区的大神。
参与战“码”先锋，PR 征集令！ 你可以在 Gitee 的 OpenHarmony 代码仓提交 PR 参与活动，和全球开发者同台竞技，比拼技艺，为 OpenHarmony 贡献力量。
祝尚元
OpenHarmony社区运营专家
一、成为社区达人，先从了解角色定义和贡献类型开始
独行快，众行远，社区的发展需要社区参与者的持续贡献。每个参与者可以根据自己在社区中的角色来做相应类型的贡献。祝尚元解释到，社区角色可分为：User、Contributor、Committer、SIG leader、PMC，每个角色的解释和贡献类型如图所示。
社区角色定义及贡献类型
二、如何参与社区贡献
OpenHarmony 社区的发展需要大家共同参与，开发者参与社区贡献的最主要方式是提 Issue 和 PR。当开发者发现问题时，可以通过提 Issue 的方式表达出来。开发者可以通过提 PR 解决相关问题。在提 PR 之前，开发者需要签署开发者原创声明，熟悉相关文档和代码编写规范，并配置环境，准备Git 命令行工具、Gitee 账户，设置账户信息等。
一切准备就绪后，即可 Fork 目标代码仓到自己的 Gitee 账户，将代码 Clone 到本地开始编辑修改。当修改完善后，即可提交 PR，并关联 Issue。提交的 PR 将会被 Committer 检视并提出检视建议。贡献者根据建议再次修改完善后，如果得到 Committer 的认可，PR 将被成功合入到代码仓，自此 PR 顺利提交完成。流程可见下图。
参与社区贡献的流程
三、贡献代码之前需要了解
社区需要参与者踊跃贡献，更需要大家有序贡献，这就需要大家在贡献之前了解相关的指引文档。
作为一个开源社区公民，共建友好的社区开发和协作环境，是我们应尽的责任。在加入开源社区前，我们需要遵守《贡献者公约》V1.4。还需要了解设计规范和代码风格文档，通过遵守设计原则，治理章程，可以引导 OpenHarmony 生态向健康、有序的方向发展和演进；另外，遵循编程规范，在进行代码开发、检视、测试中，保持代码风格的统一，将有助于后续的维护和更新迭代。
如果想引入第三方开源软件，需要了解第三方开源软件引入指导文档，保障引入到 OpenHarmony 项目中的第三方开源软件的质量。如果想对文档进行贡献，可以先了解文档写作规范。撰写规范的文档是为了方便后续的社区参与者更好地阅读和了解项目。
提PR之前需要了解的事项
四、参与贡献的5个方式
对于刚接触开源社区的开发者，普遍存在的疑问是能在社区贡献什么？因为大家对项目熟悉程度的不同，可以根据自身能力寻找可以贡献的点。针对这个问题，祝尚元给出了 5 点建议。
接触开源项目，第一，从阅读文档开始。对于在初期的开源项目，由于运营时间较短，参与人数可能不多，缺乏详细的项目文档资料，参与者可以通过编写文档为开源项目做出贡献。现有的文档也有利于开发者去学习、掌握一个开源项目的入口。在我们使用文档时，如果发现问题，也可以反馈问题，帮助修复问题。
第二，找到自己的兴趣点，关注（Watch）感兴趣的项目。当遇到项目中提到的问题Issue，可以研究问题的缘由，并尝试解决问题，也可以学习其他人是如何解决问题，去评论和发表自己的看法。
第三，参与开源项目测试，贡献测试用例，编写贡献 Demo。当我们上手练习的时候，可以加深对项目的理解，在上手的过程中发现问题，并向社区反馈，进行贡献。
第四，如果在工作中能使用到开源项目，就有更大的便利性来进行社区贡献。我们可以在使用开源项目时，反馈需求，希望开源项目支持更丰富的功能，也可以反馈缺陷。当我们有相应的能力，可以去帮助实现这些需求，修复这些提交的缺陷。
第五，当你具备一定的开发水平，并对开源项目十分了解，可以直接认领在项目中被提出的需求，或者发现自己有更好的想法能够帮助项目带来更好的提升，这样可以直接提交PR进行贡献。
为开源项目做贡献的五个点
五、如何处理代码冲突
提交代码后，经常会遇到一个常见的场景：处理代码冲突。对于解决冲突，祝尚元强调：首先需要了解冲突的由来。当有贡献者与你同时改动了同一个文件的同一行代码，并提前于你提交 PR 被合入，那你再提交 PR 就会发生冲突。
遇到冲突时，一些贡献者容易想到把冲突的 PR 关掉，更新到最新的代码后，再提交一个新的 PR，其实大可不必这样。为了避免冲突，编码前一定要更新到最新的代码。当冲突发生时，修复冲突，推荐使用 Rebase 变基操作，而不是 Merge 合并操作。Merge 合并会产生冗余的 Commit 提交记录。
修复提交冲突
为 OpenHarmony 社区做贡献，成为开源达人，从提交第一个 PR 开始，把我们对 OpenHarmony 的热爱和期望编写到代码中。OpenHarmony 社区需要每一位开发者的支持与贡献，你的每一个 Issue、每一个 PR 贡献，都将被广大的开发者们看到并从中收益，一起来行动，提 PR，一起成为开源达人！
