共计 1789 个字符，预计需要花费 5 分钟才能阅读完成。
前言
当今程序世界的疾速倒退无奈脱离开源我的项目的茁壮倒退，而作为出名的开源我的项目代码社区，Github 在开源届有着无足轻重的位置，本文就将帮忙大家理解如何在 Github 上参加开源的建设。
参加开源
对于大部分人来说，开源我的项目的应用曾经是粗茶淡饭了，无论是数据库还是 ide，三方库还是连贯工具都有可能是开源我的项目的一员。然而很多人也就是仅仅应用而已，实际上开源我的项目须要每个人的帮忙才可能更加茁壮的倒退。
很多人认为只有提交代码，进行 PR 合并代码才算是对开源我的项目产生奉献，其实这是不正确的，还有其余的计划也同样能对开源我的项目作出贡献。
Discussions
Discussions是 Github 开源我的项目的讨论区，开发者能够在讨论区提出问题和各种话题，并且能够参加探讨。
Discussions会有开源我的项目的管理人员进行治理，开发者在其中提出各种应用上的问题以及能够提出新的想法，设计思路等等，是一个较为凋谢的论坛性质的模块。在其中借助本人对于以后开源我的项目的理解来答复问题能够让更多刚接触到这个我的项目的萌新更加疾速的退出。
Issue
Issue是 Github 的重要性能之一，开发者能够通过创立 Issue 来提出 bug，提出新 feature 等等，也能够提出议题在社区进行探讨。
每个我的项目提出 Issue 的流程会有一些不一样，此处以 open-telemetry/opentelemetry-java-instrumentation 我的项目为样例：
此处的 Issue 通过社区的模版批改分为了三个类型，bug，feature 和安全漏洞，依照指引点开后会发现外部也是预置好了模板的：
仔细阅读模板中的内容而后照着填写即可。
Issue与 Discussions 实际上没有固定的边界，大部分状况下你既能够在 Discussions 提出问题也能够通过 Issue 提出问题。然而以我集体的了解，Issue会更加的正式，并且正规的开源我的项目会有人以专门的流程来解决提出的 Issue，因而如果是一些 bug 类的问题倡议还是提出Issue 更好。
Issue 分类标签
如果只是提出 Issue 的话没法更多的参加我的项目，然而想尝试去解决一些 Issue 往往又无从下手，该怎么办？
此处善用 Issue 的分类标签能够帮上大忙。为了治理 Issue，往往社区人员会查看新提出的Issue 之后会对其打上肯定的标签。社区的新人能够关注如下的标签：good first issue
这个标签示意 Issue 适宜新人来相熟我的项目。有些大型的我的项目甚至还会有相似的 good second issue 等标签。用户长于应用标签筛选，找到这类 Issue 就可能帮忙本人更好的成为开源我的项目的新人。
Pull Requests
Pull Requests个别简称为 PR，是一种将本人改变代码推送合并到开源我的项目的伎俩。个别的开源我的项目都禁止间接在分支上进行推送，所有的代码改变都须要走PR 的流程。
如何提出本人的第一个 PR
此处样例应用的是开源我的项目 open-telemetry/opentelemetry-java-instrumentation
- 首先须要从原开源我的项目 fork 一份到你本人的仓库，这样你本人仓库就会有一份最新的开源代码
- 之后你就能够将本人仓库的 fork 的那份代码 clone 到本地进行开发，举荐创立新的分支来进行开发
- 开发实现后将代码 push 上来，至此都是失常的开发流程
- 此处开始新建 PR
- 之后选定本人的开发我的项目开发分支，以及想要合并到的开源分支，而后抉择创立
PR - 在创立 PR 是须要填写一些 comment，为了 PR 可能通过合并所以倡议详细描述此次
PR做了些什么，解决了什么问题，如果有具体的Issue关联就更好了 - 之后点击 create 就实现了
PR的创立了，后续就是社区管理人员的审核以及提出修改意见，而后后续就是重复的批改欠缺，而后合并代码了。
PR 注意事项
每个开源我的项目对于 PR 都会有不同的标准，具体的详情个别都会在 CONTRIBUTING.md 文件中详细描述，包含编码标准，应用的库的协定标准等等，请在提交 PR 之前进行仔细阅读，防止提交之后违反了标准而被否决。
总结
开源社区中的种种玩法还是很多样的，此处只是介绍了最简略的一些参加开源的玩法，如果想要更加深度的参加各种社区的会议，各种社区的 SIG 等等，能够本人尝试摸索，摸索开源社区的魅力。
