交流工具

交流工具

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

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

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

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

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

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

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

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

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

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

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

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

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

Isabel Drost-Fromm

最后更新于1年前