# 交流工具

### Title

交流工具

### Patlet

一个内源项目正在原始开发团队之外使用，但用户在寻求帮助和与项目团队联系时遇到困难。 我们的想法是建立和记录标准的通信工具，使讨论变得可见、存档和可搜索。

### 上下文

一个团队依赖于另一个团队的组件。它希望对该组件做出贡献。 即使是书面形式的沟通，也是1对1的方式进行的。

### 问题

一个团队愿意接受来来自于下游的他们的组件用户的贡献。 由于协调和沟通是以一种点对点的方式进行的，导致了信息共享的不连贯性，收到答复的延迟，贡献者于是在收到明确的答复前会呼叫多个东道主团队成员。

### 约束

* 东道主团队有兴趣接受贡献，并愿意指导贡献者。
* 团队有很强的口头沟通文化，在建立项目特定的异步沟通渠道方面缺乏经验。
* 沟通渠道可能与应该接触到的特定群体使用习惯相一致，但不是以沟通目标进行选择的。

### 解决方案

东道主团队需要明确提供公司公开的、存档的、可搜索的、可链接的沟通渠道的好处，公司内部的任何人都可以免费订阅信息。

在精简内源项目的沟通渠道时，目标应该是围绕主题进行沟通，而不是围绕某些人。

* 项目应该有自己的问题跟踪器，东道主团队成员采用公开透明的方式进行结构化的沟通、决策和进度跟踪需求，同时也鼓励下游的用户和贡献者遵循同样的原则进行沟通。
* 该项目应该有一个或多个结构不太严格的讨论渠道。通常情况下，这将是邮件列表、在线论坛甚至是存档的聊天频道。通常情况下，项目开始时只有一个频道就足够了，如果流量增加太多，把关于项目使用的讨论和关于项目开发的讨论分开是有帮助的。
* 此外，项目应该有一个私人频道，可以在 [Trusted Committer](https://patterns.innersourcecommons.org/zh/p/trusted-committer) 之间进行敏感的交流--例如，将更多的 Trusted Committer 加入到东道主团队中。这个渠道的使用应该非常谨慎，因为沟通默认为公开的，只有在非常罕见的情况下才会保持私密。

虽然沟通可以发生在书面渠道之外，但尽可能多的信息应该被带回异步渠道。

所有的通信渠道都应该在项目的`README.md`中进行记录。东道主团队成员需要努力将他们个人收到的问题带回官方沟通渠道。

### 结果上下文

建立并持续使用官方的异步交流渠道，有助于建立一个基础的被动文档，当类似的问题再次出现时可以再次参考。

随着交流的公开化，其他人可以很容易地关注项目的进展，并积极做出贡献。其他人的聆听和阅读降低了参与的门槛，提高了获得贡献的可能性。

随着问题被公开回答，更多的人可以加入他们的观点，从而形成一个完整的画面--这不仅包括东道主团队成员，也包括项目的用户。

在异步渠道中保持交流，可以让不同时间段的参与者--无论是由于不同时区，还是由于不同的作息时间、会议时间、团队作息时间--对项目做出有意义的贡献。

在这些渠道中回答问题，不仅意味着其他团队成员可以倾听并提供额外的信息，也意味着有相同问题的其他用户可以看到（或后来找到）之前的答案，从而降低重复解释的需要。

### 已知实例

* Europace AG
* Paypal Inc.
* Mercado Libre

### 作者

Isabel Drost-Fromm

### 状态

* 结构化
* 于2019年12月起草。

### 翻译校对

* **2022-12-06** 翻译[姜宁](https://github.com/willemjiang)
* **2022-12-09** 校对[龙文选](https://github.com/hncslwx)