# 小组支持

### Title

小组支持

### Patlet

如果某个团队或个人不再支持 InnerSource 项目怎么办？ 由一群感兴趣的个人组成小组来保持项目活跃。

### 问题

* 即便是一个广受欢迎的 InnerSource 项目也可能陷入孤立的困境。
* 当前没有明确的出路。

### 故事

一个 UI 组件类库，在全公司有 50 多个项目使用。 该类库的开发团队在资源耗尽后，宣布解散。 起初，没有人注意到，但过了一段时间，每当有人问“谁负责它”时，得不到答案。 接下来会怎么样？ 新的团队会避免使用它吗？ 该项目是否会停滞不前，直到其用户最终被迫转向其他项目？ 如果一个完美且有价值的项目出现这种情况，那将是多么令人遗憾！

### 上下文

* 广受欢迎的 InnerSource 项目。
* 作为一个构件时的依赖项使用（比如 代码模块）。
* 没有活跃的开发者提供支持。
* 公司无法指派团队提供支持。

### 约束

* 没有人在日常工作中被指派负责这项工作。
* 每个人都很忙。
* 项目迁移的成本很高。

### 解决方案

面向全公司征集感兴趣的志愿者，组成一个 [可信任提交者](https://patterns.innersourcecommons.org/zh/p/trusted-committer) 小组来支持该项目。 可能需要根据提交或使用的历史记录联系特定的个人。 重要的一点是要有足够的数量，这样每个人的负担可以相对较小。

该小组成立后，应确定或创建[标准基础文档](https://patterns.innersourcecommons.org/zh/p/base-documentation)和[沟通工具](https://patterns.innersourcecommons.org/zh/p/communication-tooling)。

团队应尽全力从以下方面管理项目：

* **维护**. 如果项目在标准用例中完全失效，那就修复它。 随着项目使用的依赖关系和框架的不断发展，及时更新项目。
* **新人上手**. 如果有人对如何使用项目有疑问，确保他们能得到合理的答复。
* **更新**. 如果有人想在项目中添加新功能，请为他们提供必要的设计和技术支持，以便他们实现该新功能，使其既能为自己所用，又能为项目增光添彩。 及时评审收到的 PR。

由于该小组由志愿者组成，因此重要的是要传达提供“尽力而为”的支持。 因此，这种支持模式不太适合像实时 API 这类运行时关键的生产项目。 它更适合在构建时使用的项目，例如类库/包/模块。 该小组预计不会为其他人实现任何新功能。

### 结果背景

* 对 InnerSource 项目有些微弱的支持。
* 从长远来看，小组支持可能会在某个时候再次解散。如果该项目长期持续下去，那么就利用这段稳定的小组支持期，找到一种长期支持的方式（比如 [核心小组](https://patterns.innersourcecommons.org/zh/p/core-team)）。

### 理由

人们通常都愿意提供帮助。 如果有人邀请某个人是否愿意加入成为[可信任提交者](https://patterns.innersourcecommons.org/zh/p/trusted-committer)，通常会有很多人回答“是的”。 感受到自己是集体的一员，并在组织结构上体现和被赋予一定的责任，通常会激励人们尽最大努力，很多时候这就已经足够了。

### 已知实例

* WellSky

### 状态

结构化

### 作者

[Russell R. Rutledge](https://github.com/rrrutledge)

### 翻译校对

* **2024-10-10** 翻译[Chris Yang](https://github.com/node)
* **2024-10-12** 校对[姜宁](https://github.com/willemjiang)