gRPC-Go 工程实践
新年伊始，也是我在 gRPC-Go 项目上的第一个完整年头即将结束之际，我想借此机会更新一下 gRPC-Go 的开发状态，并让大家了解我们如何管理这个项目。对我个人而言，这是我第一次有意义地为一个开源项目做出贡献，因此今年对我来说是一次学习的经历。在过去的一年里，团队一直在不断改进我们的工作习惯和沟通方式。我仍然看到有改进的余地，但我相信我们现在的状况比一年前好得多。
仓库健康状况
当我第一次加入 gRPC-Go 团队时，他们已经几个月没有之前的技术负责人了。当时，我们有 45 个未处理的 PR，其中最旧的已经有一年多的时间了。作为一名新团队成员和维护者，累积的过期 PR 使我们难以评估优先级并了解事情的状况。对于我们的贡献者来说，忽略 PR 既不尊重，也不方便，因为我们开始要求他们由于其他提交进行 rebase。为了解决这个问题，我们齐心协力地合并或关闭了所有这些 PR，并且我们现在每周举行会议来审查每个活跃 PR 的状态，以防止这种情况再次发生。
同时，我们有 103 个未解决的问题，其中许多问题已经修复、过时或未分类。从那时起，我们修复或关闭了其中的 85 个问题，并制定了一个流程，以确保我们每周轮流分类和优先处理新的问题。与我们的 PR 类似，我们还在每周的会议上审查我们分配的和高优先级的问题。
我们对新问题和 PR 的持续 SLO 是 1 周内进行分类和首次响应。
我们还改进了我们的 标签，用于问题和 PR，以帮助组织。我们通常会对每个问题应用优先级 (P0-P3) 和类型（例如，Bug、Feature 或 Performance）。我们还有一系列在各种情况下应用的狀態标签。类型标签也应用于 PR，以帮助生成我们的发布说明。
版本控制和向后兼容性
我们最近记录了我们的 版本控制策略。我们的目标是保持完全的向后兼容性，除非在有限的情况下，包括实验性 API 和减轻安全风险（最值得注意的是 #1392）。如果您注意到行为倒退，请不要犹豫在我们的仓库中打开一个问题（请合理）。