Yeoman 每个项目都使用 GitHub 问题跟踪器。我们使用 GitHub 提供的功能对问题进行分类，以便于管理并帮助贡献者找到需要完成的任务。

在整个 Yeoman 中，我们主要使用三个功能

1. 标签
2. 里程碑
3. 分配

TLDR？

只需帮助我们解决标记为 actionable 的问题即可。这些问题是可以立即编码的。

标签

标签用于对问题进行分类。我们使用三类标签来描述每个问题——大多数情况下，一个问题至少会包含每一类的标签。

生命周期（可行性）

第一类检查问题是否可操作。它回答了以下问题

这个问题现在可以解决吗？

我们有 4 个可能的标签来描述问题生命周期

• actionable：此问题现在可以由任何人解决。如果一个问题是可操作的，只需将其取走并 发送 PR。
• to-split：此问题范围太大，应将其分解成更小的可操作部分。 to-split 的问题是讨论功能实现细节的好地方。
• to-discuss：这意味着问题需要讨论，Yeoman 团队需要决定是否要将此功能添加到项目中。
• to-confirm：此标签主要用于 bug 类型的 issue，直到有人可以重现该问题。确保为每个 bug 添加重现步骤，以便问题可以立即标记为 actionable。

类型

项目中可能存在多种类型的 issue。主要有

• feature：对项目的建议新功能。
• bug
• maintenance：与项目构建系统、测试、重构、第三方等相关的所有内容
• 文档
• meta：与项目管理相关的问题。权限、发布、变更日志等。

难度

我们使用三个难度级别对问题进行标记：easy、medium、hard

难度的评定基于特定问题需要触及的活动部件/系统部分的数量。可以通过更改单个方法来修复的问题很容易。但需要更改系统 3 个部分的问题则很难。

我们以这种方式对难度级别进行评级，以便向新贡献者提供解决问题所需投入级别的洞察力。一个困难的问题需要更长的时间来学习 Yeoman 的内部结构，而一个简单的问题可能只需要一定程度的 Node.js 知识。

里程碑

里程碑代表未来版本。

Yeoman 版本尽可能遵循 semver 规范。这意味着新功能在次要版本中实现。重大更改在主要版本中添加。错误修复通过补丁版本完成。

这意味着某些问题可能会延迟，直到我们准备好发布可以合并更改的版本。

以下是一些示例

1. 添加新功能的 Pull Request 可能会延迟，直到当前 Yeoman 版本足够稳定，以便我们专注于下一个次要版本。
2. 某些问题可能不适合在主要版本发布之前修复，因为它们意味着破坏向后兼容性。

不过，不要太担心这些。在不久的将来不适合修复的问题不会被标记为 actionable。

分配

Yeoman 团队的成员可能已经开始开发一项功能。如果是这样，大多数情况下，我们会尝试将此成员分配给该问题，以便每个人都知道此问题已经有人在解决了。

如果您觉得问题需要花费太长时间才能解决，请随时在问题上发表评论（或发送电子邮件给被分配者）以主动提出解决。