docs: good first issue doc zh-CN

docs/contributing_guide.zh.md

@@ -13,6 +13,7 @@
 
 ## 如何贡献
 我们欢迎各种贡献，包括但不限于：
+
 - 新功能（feature）
 - 代码构建、CI/CD
 - Bug 修复
@@ -80,9 +81,9 @@ DevStream 真诚地欢迎每一个人参与我们的会议，不需要被邀请
 - TODO: 生成本地文档预览
 
 ## 代码提交署名（Sign Off）
-授权与认证（licensing) 对于开源项目非常重要，它确保了软件能基于作者提供的条款继续运作。我们需要您在贡献代码的时候署名您的提交，[Developer Certificate of Origin (DCO)](https://developercertificate.org/) 是一种认证您编写了此段代码，并表明您持有这段代码。
+授权与认证（licensing) 对于开源项目非常重要，它确保了软件能基于作者提供的条款继续运作。我们需要您在贡献代码的时候署名您的提交，[Developer Certificate of Origin (DCO)](https://developercertificate.org/) 是一种认证您编写了此段代码，并表明您持有这段代码的方式。
 
-您可以通过在提交信息（Git Commit Message）中附加这段信息。注意，您的署名必须用 Git 的用户名和邮箱对应。
+您可以通过在提交信息（Git Commit Message）中附加这段信息。注意，您的署名必须与 Git 的用户名和邮箱对应。
 
     This is my commit message
 

docs/development/good-first-issues.zh.md

@@ -1,3 +1,48 @@
 # Good First Issues 中文文档
+想参与 DevStream（或任何开源项目），但不知道从哪开始？
 
-todo
+浏览 [good first issues](https://github.com/devstream-io/devstream/labels/good%20first%20issue) 吧！
+
+## 关于 Good First Issues 标签
+该标签意味着对应的 issue 只能被 _第一次参与贡献的人_ 认领。
+
+### 对于贡献者们
+在贡献者完成一个（或两个）“good first issue” 后，建议完成带有“help wanted”标签的 issue，将 "good first issue" 留给其他的新贡献者。
+
+### 对于审阅者们
+
+- 请密切关注带有 "good first issue" 标签的 PR, 并指导其完成 [Pull Request 流程](https://docs.devstream.io/en/latest/contributing_guide/#pull-request-lifecycle.zh)。
+- 请让他们知道下一步该做什么，如：
+  - 如果他们不够自信，觉得无法胜任，请向他们推荐更合适的 good first issue。
+  - 继续参与 "help wanted" issues 。
+  - 参与社区交流，如 [Slack 频道](https://join.slack.com/t/devstream-io/shared_invite/zt-16tb0iwzr-krcFGYRN7~Vv1suGZjdv4w)。
+- 若贡献者的代码有问题，应主动指出，并提供修复所需的相关信息（文字、链接、图片、伪代码等）。
+
+所有的行为，都应该让新的贡献者感受到受欢迎与被重视，获得价值感，并向他们保证，他们将在第一次贡献中获得额外的帮助。
+
+_请确保不应让贡献者主动去找审阅者，或者出现贡献者频繁催促才能联系到审阅者的情况；了解CLA（[贡献者许可协议](https://en.wikipedia.org/wiki/Contributor_License_Agreement)）/ DCO（[开发者原创证书](https://developercertificate.org/)） 检查失败的原因，确定他们的构建为何失败，等等。_
+
+### 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 以展示项目是如何运作的。
+- 如果你有时间，请让贡献者知道，如果他们不愿意在群内咨询问题的时候，也可以直接私聊你询问。