Good First Issues 中文文档¶
想参与 DevStream（或任何开源项目），但不知道从哪开始？
点开 good first issues 列表，开始你的贡献吧！
关于 Good First Issues 标签¶
该标签意味着对应的 issue 只能被 第一次参与贡献的人 认领。
对于贡献者们¶
在贡献者完成一个（或两个）“good first issue” 后，建议完成带有“help wanted”标签的 issue，将 "good first issue" 留给其他的新贡献者。
对于审阅者们¶
- 请密切关注带有 "good first issue" 标签的 PR, 并指导其完成 Pull Request 流程。
- 请让他们知道下一步该做什么，如：
- 如果他们不够自信，觉得无法胜任，请向他们推荐更合适的 good first issue。
- 继续参与 "help wanted" issues 。
- 参与社区交流，如 Slack 频道。
- 若贡献者的代码有问题，应主动指出，并提供修复所需的相关信息（文字、链接、图片、伪代码等）。
所有的行为，都应该让新的贡献者感受到受欢迎与被重视，获得价值感，并向他们保证，他们将在第一次贡献中获得额外的帮助。
请确保不应让贡献者主动去找审阅者，或者出现贡献者频繁催促才能联系到审阅者的情况；了解CLA（贡献者许可协议）/ DCO（开发者原创证书） 检查失败的原因，确定他们的构建为何失败，等等。
Good First Issue 的选取标准¶
一个可行的定义是：新的贡献者有能力宣布并解决此 issue，提交可接受（合并）的 Pull Request，而不需要过多的帮助。
决定一个 issue 能否成为 good first issue，除了 issue 自身的因素外，还取决于你在 issue 中留了多少上下文信息，以增大新的贡献者的参与成功率。所以，在创建一个 issue 的时候，请尽可能地提供更多细节。
- 无参与障碍：新的参与者可以不用在安装复杂环境、复杂设置，以及不需要拥有丰富的领域知识的情况下参与进来。
- 提供上下文：如果需要背景知识，应明确提及，包括建议的阅读列表。在未完成上下文的编辑前，请不要为 issue 打 good first issue 标签。
- 解决方案说明：如果有推荐的解决方案，应在 issue 内清晰地阐述。
- 给出示例：链接到类似实现的示例，以便新贡献者获得更多的参考。
- 标识相关代码：应在 issue 中链接相关的代码与测试。
- 准备测试：应该有相关的类似的测试存在，以便贡献者可以复制代码或者简单修改一下，写出自己的测试代码。如果这个模块没有测试代码可参考，在打 good first issue 标签前，请添加测试。这种准备工作通常是一项很棒的帮助性任务！
建立充满激情的社区¶
如果你让大家认同自己是社区的一部分，所有人都可以自如地提问，社区会告诉他们各种规则与惯例，以及告诉他们的贡献是有帮助的并赞赏他们，他们会愿意留在社区！
为了让我们的社区更受欢迎，为了让更多的人愿意参与我们的社区，我们建议：
- 鼓励新的贡献者在合适的 Slack 频道或微信群寻求帮助，介绍他们，并给他们一个参与的机会。
- 提高新的贡献者的声望以便其他人了解他们。"Hey, 有人想审阅一下这个 @新贡献者 的 PR 并给他个 LGTM（Looks good to me, 指认可此次 PR) 吗？以及，在 Slack、微信群、社区会议时提及他们的贡献，或者在其他社交媒体上等等。
- 尽可能地多地在 LGTM时，使用表情。如 💖 🚀
- 确认并感谢他们提交了第一个拉取请求，以及告诉他们，你将尽可能提供帮助。
- 推荐相关领域的 "help wanted" 以帮助他们能某个领域积累经验。
- 当人们知道接下来会发生什么时，他们更有可能继续做出贡献。例如，什么样的要求审核的方式是可接受的，以及如何在 PR 停滞时推动事情的发展。通过帮助他们完成第一次 PR 以展示项目是如何运作的。
- 如果你有时间，请让贡献者知道，如果他们不愿意在群内咨询问题的时候，也可以直接私聊你询问。