GLEP 48: QA 团队的角色和目的

摘要

本 GLEP 概述了 Gentoo 质量保证 (QA) 团队的能力和目的。

动机

多年来，开发人员一直强调我们需要一个赋权的 QA 团队来处理树相关的问题。本 GLEP 为此类团队提供结构，并指定团队将履行的角色。

本 GLEP 已被修订，通过给予 QA 团队理事会的全力支持来改善其任务授权。

规范

QA 团队应获得一定的能力，以维护所有开发人员以及我们用户的最佳利益。QA 团队还应努力确保开发人员获得所需信息，并确保包得到维护。QA 团队还负责确保树策略得到尊重。

• QA 团队的目的是为跨团队合作提供帮助，以保持树处于良好状态。这主要是通过查找和指出问题并将其传达给维护者，以及在必要时采取直接行动来实现。
• QA 团队由一名负责人领导，该负责人每年由团队成员通过私人或公开选举产生，并由理事会确认。QA 团队负责人可以选择一名成员作为副手。副手拥有由 QA 团队负责人直接委托的所有权力，因此他的行动和决定应被视为与 QA 团队负责人的行动和决定同等重要。副手仅对 QA 团队负责人负责。
• QA 团队负责人必须批准希望加入项目的开发人员。申请者必须证明自己对他们希望执行的任务有透彻的了解。通过接受申请者，QA 团队负责人将接受责任，将他们作为团队的一部分进行指导，并将对团队成员代表 QA 团队采取的任何行动负责。
• 在紧急情况下，或者如果包维护者拒绝合作，QA 团队可以自行采取行动解决问题。QA 团队不希望默认情况下覆盖维护者的意愿，而希望在团队发现解决问题对用户和 fellow 开发人员的最佳利益时，尽快解决问题。
• QA 团队还可以提供修复明显的拼写错误和类似的次要问题，并且来自包维护者的沉默可以视为在这种情况下达成一致。编码风格问题属于此类，虽然它们并不严重，但会使树的自动检查更加困难。
• 在某些情况下，我们的工具无法处理特定情况，为了使某些内容完全正常工作，必须违反策略。希望这种情况不会经常发生，但每次发生时，QA 团队和维护者将就临时解决方案达成一致，并预期将向适当的团队提交一个 bug，以寻求正确的解决方案。
• 如果 QA 成员之间存在分歧，大多数已建立的 QA 成员必须同意该行动。分歧的一些例子包括：感知到的问题是否违反了策略，或者解决方案是否使情况变得更糟。
• 如果开发人员仍然坚持认为某个包没有违反 QA 标准，可以在下次理事会会议上提出上诉。该包应按照 QA 的要求进行处理，直到理事会做出决定为止。
• 仅仅因为某个特定的 QA 违规行为尚未造成问题，并不改变它仍然是 QA 违规行为的事实。
• 如果某个特定开发人员持续造成 QA 违规行为（负面影响 Gentoo 系统的行为、其他开发人员的工作或基础设施设施），QA 团队可以发布对开发人员提交访问权限的临时撤销（禁令），最长 14 天。如果出现重复违规行为，QA 团队可以要求 ComRel 重新评估提交访问权限。所有违规行为的证据以及禁令期限将由 QA 团队单独评估和投票。
• QA 团队将维护一份当前“QA 标准”的清单，其中包含有关为什么它们是问题以及如何解决问题的解释。这份清单绝不意图成为一份全面文件，而是一份动态文件，随着新问题的发现而更新。QA 团队还将尽最大努力确保所有开发人员工具符合当前的 QA 标准。
• QA 团队将与招聘人员合作，保持相关文档和测验的最新状态，以便新晋开发人员能够获得避免过去问题的所有必要信息。
• QA 将积极参与清理和从树中移除发现存在问题的未维护包。还鼓励 QA 团队成员协助指导希望接管未维护的包/群组的新开发人员。
• QA 负责人的任期在确认后一年到期，在职位空缺的任何时期，理事会可以任命临时负责人。

向后兼容性

这对本 GLEP 来说不是问题。

版权

本作品根据知识共享署名 - 相同方式共享 3.0 未本地化版本许可协议授权。要查看本许可协议的副本，请访问 https://creativecommons.org/licenses/by-sa/3.0/。