Issue 管理者

除了承担 PR 管理者的职责外, SIG Docs 正式的批准人(Approver)、评审人(Reviewer)和成员(Member) 按周轮流归类仓库的 Issue

职责

在为期一周的轮值期内,Issue 管理者每天负责:

  • 对收到的 Issue 进行日常分类和标记。有关 SIG Docs 如何使用元数据的指导说明, 参阅归类 Issue
  • 密切关注 kubernetes/website 代码仓库中陈旧和过期的 Issue。
  • 维护 Issues 看板

要求

  • 必须是 Kubernetes 组织的活跃成员。
  • 至少为 Kubernetes 做了 15 个非小微的贡献 (其中某些应是直接针对 kubernetes/website 的贡献)。
  • 已经以非正式身份履行该职责。

对管理者有帮助的 Prow 命令

以下是 Issue 管理者的一些常用命令:

# 重新打开 Issue
/reopen

# 将不切合 k/website 的 Issue 转移到其他代码仓库
/transfer[-issue]

# 更改陈旧 Issue 的状态
/remove-lifecycle rotten

# 更改过期 Issue 的状态
/remove-lifecycle stale

# 为 Issue 指派 SIG
/sig <sig_name>

# 添加具体领域
/area <area_name>

# 对新手友好的 Issue
/good-first-issue

# 需要帮助的 Issue
/help wanted

# 将 Issue 标记为某种支持
/kind support

# 接受某个 Issue 的归类
/triage accepted

# 关闭还未处理且未修复的 Issue
/close not-planned

要查找更多 Prow 命令,请参阅命令帮助文档。

何时关闭 Issue

一个开源项目想要成功,良好的 Issue 管理非常关键。 但解决 Issue 也很重要,这样才能维护代码仓库,并与贡献者和用户进行清晰明确的交流。

关闭 Issue 的时机包括:

  • 类似的 Issue 被多次报告。你首先需要将其标记为 /triage duplicate; 将其链接到主要 Issue 然后关闭它。还建议将用户引导至最初的 Issue。
  • 通过所提供的信息很难理解和解决作者提出的 Issue。 但要鼓励用户提供更多细节,或者在以后可以重现 Issue 时重新打开此 Issue 。
  • 相同的功能在其他地方已实现。管理者可以关闭此 Issue 并将用户引导至适当的位置。
  • 报告的 Issue 当前未被计划或不符合项目的目标。
  • 如果 Issue 看起来是垃圾信息并且明显不相关。
  • 如果 Issue 与外部限制或依赖项有关并且超出了本项目的控制范围。

要关闭 Issue,可以在 Issue 中留下一条 /close 的评论。