Issue 管理者

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

职责

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

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

要求

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

对管理者有帮助的 Prow 命令

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

  1. # 重新打开 Issue
  2. /reopen
  4. # 将不切合 k/website 的 Issue 转移到其他代码仓库
  5. /transfer[-issue]
  7. # 更改陈旧 Issue 的状态
  8. /remove-lifecycle rotten
  10. # 更改过期 Issue 的状态
  11. /remove-lifecycle stale
  13. # 为 Issue 指派 SIG
  14. /sig <sig_name>
  16. # 添加具体领域
  17. /area <area_name>
  19. # 对新手友好的 Issue
  20. /good-first-issue
  22. # 需要帮助的 Issue
  23. /help wanted
  25. # 将 Issue 标记为某种支持
  26. /kind support
  28. # 接受某个 Issue 的归类
  29. /triage accepted
  31. # 关闭还未处理且未修复的 Issue
  32. /close not-planned

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

何时关闭 Issue

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

关闭 Issue 的时机包括：

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

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