工单处理

<工单

本文档概述了在中/大型开源项目中处理工单的最佳实践。由于 CocoaPods 是在 GitHub 上开发的，因此基于 GitHub 功能，除了这一点外，所有概念都适用于其他开源项目。

以下准则具有指示性，当合理无用时可以跳过任何步骤。

CocoaPods 的工单处理和开发是一个开放的过程，参与者使用自己的判断来决定是否愿意执行某项操作。如果出于任何原因对某项操作没有足够的信心，可以召集团队的其他成员。

<标签

工单按 4 个轴分类：类型、状态、难度和优先级。每次应用或更改标签时，都应发布一条评论，其中包括任何相关信息。

<解决工单的步骤

• 类型识别
• 澄清
• 确认
• 识别操作
• 实施
• 验证

<类型识别

工单类型应设置为：增强 缺陷 讨论

如果工单重复了另一个工单，则应将其关闭为重复，并注明评论。

<澄清

工单状态应更改为等待输入

如果工单描述不完整或不清楚，应向提交者索取更多信息。对于缺陷，此信息可能包括可重现的测试用例。

<确认

工单应关闭或将其状态更改为已确认

如果工单被认为非常需要，则可以通过将优先级设置为★来优先处理。

缺陷

缺陷可以通过重现用户报告的测试用例来确认。确认评论应报告所用 CocoaPods 的版本，并且应被视为 2 个次要版本有效。此外，它还应包括该工具生成的输出报告以及任何生成的人工制品的相关内容。

功能

任何贡献者都可以确认次要增强功能，而主要增强功能则需要核心团队成员的意见，因为他们的判断可能需要架构和哲学方面的含义。

<操作的识别

工单状态应更改为 详细

如果在实现此工单之前还有另一个工单需要解决，则应应用 已阻止 标签，并发布一条评论指出依赖关系。

在此步骤中，根据更改的范围和所涉及的技术难度，工单的难度应设置为 容易 中等 困难

包括对 CocoaPods 输出应执行的更改的描述，如果相关，则指出命令（或应发生更改的上下文）。

此外，评论应包括实现工单所需的编程更改的描述。

<实现

通过拉取请求实现工单后，可以将其标记为 等待验证

<验证

实现工单后，应对其进行验证、合并并最终关闭。

要验证主要工单的实现，需要核心团队成员。

除非进行微小的更改，否则每个拉取请求都应包括

• 防止回归的测试
• CHANGELOG 中的注释