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

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

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

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

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

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

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

模板

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

## Background

## Technical requirement

## Expect

## Potential TODO list

工具

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

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