问题管理#

此页面为负责 GNOME 项目问题追踪器（主要为维护者）的人员提供指南和建议。

功能请求策略#

通过问题追踪器提交的功能请求难以解决，并且可能演变成对抗。因此，模块不通过其问题追踪器接受功能请求，并制定新的功能建议替代方案可能是有益的。如果模块的维护者决定采用此策略

  • 应明确记录（在项目的 issue 模板和/或 README 中）

  • 应提供一个功能讨论的替代论坛，例如 Discourse 标签和/或 Matrix 聊天室

  • 替代论坛的位置应在 Gitlab 项目描述以及项目的新 issue 模板中进行宣传

  • 维护者应理想情况下参与功能建议，而不仅仅是忽略它们；但是，他们不应感到有义务批准或拒绝每一个提案

即使在实施“不接受功能请求”策略的情况下，仍然可以使用 issue 来跟踪新功能。但是，只有在新功能经过讨论并且达成共识后才能这样做。

树立良好的榜样#

如果既定的贡献者不遵守我们的 issue 指南，那么我们不能期望外部参与者这样做。因此，以身作则是很重要的

  • 在提交修复 MR 之前，先提交 bug issue。

  • 在提交 issue 时，请填写 issue 模板并遵循 issue 报告指南。

  • 使用适当的论坛（Matrix/Discourse/GitLab）讨论功能添加和更改，并在提交 MR 之前获得大致共识。

  • 通常，应避免在 issue 追踪器中进行开放式讨论，例如讨论是否需要某个功能。如果您确实想使用 issue 进行讨论，请使用 RFC 标签明确标记。建议在 issue 停滞两周后关闭此类 issue。

鼓励贡献者#

让贡献者参与 issue 审查可以大大减轻维护者的负担，因此强烈鼓励维护者通过鼓励 issue 审查来帮助自己

  • 将 issue 审查添加到您项目的贡献指南中，并链接到 审查指南。

  • 留意潜在的 issue 审查贡献者。如果有人提交 issue，这是一个询问他们是否有兴趣帮助进行审查的好机会。

  • 授予新的贡献者额外的 issue 追踪器权限是一种激励他们的方式，所以不要害怕这样做。您可以告诉贡献者他们应该做什么和不应该做什么，如果您正在监视 issue 追踪器，那么在必要时进行干预也很容易。

    • 可以通过在 GitLab 中分配 Reporter 角色来授予额外的 issue 追踪器权限。请注意，拥有此角色的帐户可以读取和写入机密 issue。

  • 一旦新的贡献者在 基本任务方面获得了一些经验，请鼓励他们承担更多责任。

鼓励贡献者帮助处理 issue 追踪器有时会让人感到害怕，但事实并非如此。风险相对较低，回报可能巨大。