开源项目之 good-first-issue

开源项目的贡献者群体，大致呈倒金字塔的形态。

项目的管理、规划、主要特性开发或重大缺陷的修复，这些通常是由少量核心的贡献者完成，这可以认为是金字塔的顶部驱动。

还有一些贡献者，提交记录不是很多，但项目参与度也比较紧密；这类贡献者的数量通常也不少，可以认为是金字塔中间力量。

数量最大的部分，是那些有着零星贡献提交记录的贡献者，也正是我们现在讨论的重点：“游客”贡献者。这些“游客”虽然不会贡献重量级的内容，但对一个开源项目而言，同样是有着非常重要的意义：

• 每一位重要的贡献者都是从“游客”开始的，我们想要增加贡献者的数量和“质量”也要从这里着手
• 源源不断的“游客”加入，可以让项目呈现出繁荣的景象
• 新人友好程度是开源项目的成熟标志之一

那么，什么样的 issue 可以标记为 good-first-issue 呢？从字面上看，这是对新人（初次接触）友好的 issues ，也就是对于这类贡献者而言比较容易解决的 issue 。

因此，判断是否应该把一个 issue 标记为 good-first-issue 可以从这两个角度考虑：

1. 如何定义“新人”？

2. 如何定义“友好”？这里的“友好”，一方面是指参与流程的清晰（当然，这是更广泛的社区治理的范畴），另一方面是指参与要求的明确

• 有清晰的技术栈要求
  • “新人”和技术水平的高低无关，只表明初次接触某个项目
  • 从更加客观的角度来讲，issue 的创建者可以列举出来完成这个 issue 所需要的技能
• 有清晰的上下文描述
  • 即使技术水平”高“的贡献者，在不了解 issue 的上下文、背景的前提下，依然是很难去完成
  • 解决 issue 需要的技能
• 没有明显（或潜在）的时间约束
  • 我们不清楚“新人”什么时候会关注到这些 issue ，因此，不要把这些 issue 和你的 milestone （或其他版本发布计划）挂钩
• 有助于贡献者了解项目结构（可选）
  • “新人”完成 good-first-issue 的价值不仅仅是可以增加贡献者数量，更有意义的地方在于：可以帮忙更多贡献者进一步熟悉、了解项目的贡献流程以及项目本身

模板

为了方便大家对 good-first-issue 有更形象的认识，我下面给出一个模板：

## Background

## Technical requirement

## Expect

## Potential TODO list

工具

自动化工具的应用，对于一个开源项目而言是极为重要的。来自 Kubernetes 社区的 Prow 可以帮助项目维护者更好地使用标签。

其他

GitHub 还提供了一个隐藏（没有直接调整的按钮或菜单等）的页面，参考如下——在某个开源项目的仓库地址后加 contribute 即可访问：

https://github.com/LinuxSuRen/open-source-best-practice/contribute