端口维护者指南

联合指导的原因

单独指导的原因

我们期望导师至少在持续一周或两周的初始阶段审查和测试构建所有建议的补丁。

我们期望导师对学员的行为负责。导师应该跟踪学员做出的所有提交，包括已批准的和隐式的提交。

我们期望导师确保他们的学员阅读端口维护者手册、PR 处理指南和提交者指南。虽然不必记住所有细节，但每个提交者都需要对这些内容有一个概述，才能成为社区中有效的一部分（并尽可能避免新手错误）。

没有明确的规则来界定一个候选人是否已准备好；它可能是他们提交的 PR 数量、维护的端口数量、端口更新频率和/或参与某个特定兴趣领域（如 GNOME、KDE、Gecko 或其他）的程度的组合。

候选人几乎不应该有任何超时，对请求做出响应，并且通常乐于支持他们的端口。

必须有承诺的历史，因为众所周知，培养一个提交者需要时间和精力。如果有人在周围待了更长时间，并花时间观察事情是如何完成的，那么就会有一些对积累知识的预期。我们经常看到维护者提交一些 PR，出现在 IRC 上，并询问何时会获得提交权限。

订阅和关注邮件列表非常有益。没有真正的期望表明在列表上提交帖子会使某人成为提交者，但这表明了一种承诺。一些邮件也提供了对候选人知识以及他们如何与他人互动的见解。同样，参与 IRC 可以使某人获得更高的知名度。

询问六位不同的提交者，在被提名之前，维护者应该提交多少个 PR，你会得到六个不同的答案。询问同一个人某人应该参与多长时间，同样的困境。他们至少应该拥有多少个端口？现在我们有了争论的话题！有些事情很难量化，导师只需要运用自己的最佳判断，并希望 portmgr 同意。

随着信任水平的发展和提高，学员可能会被授予“隐式”提交权限。这可能包括对Makefile、pkg-descr 等进行微不足道的更改。同样，它可能包括不包含plist 更改的PORTVERSION 更新。其他情况可以由导师自行决定。但是，在指导期间，影响相关端口的端口版本升级应由导师检查。

就像我们都是不同的个人一样，每个学员都有不同的学习曲线、时间承诺和其他影响因素，这些因素将影响他们在能够“单飞”之前所需的时间。根据经验，应该观察学员至少 3 个月。90-100 次提交是导师在释放学员之前可以使用的另一个目标。在释放学员之前要考虑的其他因素包括他们可能犯的错误数量、收到的 QAT 等。如果他们仍在犯新手错误，他们仍然需要导师的指导。

当请求到达 portmgr 时，通常会写成：“我提议让'foo'成为端口提交者，我将与'bar'联合指导”。提案收到，投票通过，并通过。

导师是主要联系人或“平等中的第一”，联合导师是备份。

某个不具名的人做出了第一次有记录的联合导师提交。在 src 树中也发现了类似的联合导师提交。这是否正确？这是否错误？它似乎是事情发展方式的一部分。

我们期望学员准备好接受来自社区的建设性批评。仍然有很多“传说”没有写下来。我们希望通过首先审查他们在 IRC 和邮件列表上的现有贡献来筛选出能够很好地应对建设性批评的人。

我们警告学员，他们收到的某些批评可能不如其他批评那么“建设性”（无论是通过语言沟通问题还是过度吹毛求疵），并且优雅地处理这一点只是成为大型社区一部分的一部分。如果遇到特定人员的具体问题或任何疑问，我们希望他们会联系 IRC 或电子邮件上的 portmgr 成员。