交流工具
Title
交流工具
Patlet
一个内源项目正在原始开发团队之外使用，但用户在寻求帮助和与项目团队联系时遇到困难。 我们的想法是建立和记录标准的通信工具，使讨论变得可见、存档和可搜索。
上下文
一个团队依赖于另一个团队的组件。它希望对该组件做出贡献。 即使是书面形式的沟通，也是1对1的方式进行的。
问题
一个团队愿意接受来来自于下游的他们的组件用户的贡献。 由于协调和沟通是以一种点对点的方式进行的，导致了信息共享的不连贯性，收到答复的延迟，贡献者于是在收到明确的答复前会呼叫多个东道主团队成员。
约束
东道主团队有兴趣接受贡献，并愿意指导贡献者。
团队有很强的口头沟通文化，在建立项目特定的异步沟通渠道方面缺乏经验。
沟通渠道可能与应该接触到的特定群体使用习惯相一致，但不是以沟通目标进行选择的。
解决方案
东道主团队需要明确提供公司公开的、存档的、可搜索的、可链接的沟通渠道的好处，公司内部的任何人都可以免费订阅信息。
在精简内源项目的沟通渠道时，目标应该是围绕主题进行沟通，而不是围绕某些人。
项目应该有自己的问题跟踪器，东道主团队成员采用公开透明的方式进行结构化的沟通、决策和进度跟踪需求，同时也鼓励下游的用户和贡献者遵循同样的原则进行沟通。
该项目应该有一个或多个结构不太严格的讨论渠道。通常情况下，这将是邮件列表、在线论坛甚至是存档的聊天频道。通常情况下，项目开始时只有一个频道就足够了，如果流量增加太多，把关于项目使用的讨论和关于项目开发的讨论分开是有帮助的。
此外，项目应该有一个私人频道，可以在 Trusted Committer 之间进行敏感的交流--例如，将更多的 Trusted Committer 加入到东道主团队中。这个渠道的使用应该非常谨慎，因为沟通默认为公开的，只有在非常罕见的情况下才会保持私密。
虽然沟通可以发生在书面渠道之外，但尽可能多的信息应该被带回异步渠道。
所有的通信渠道都应该在项目的README.md中进行记录。东道主团队成员需要努力将他们个人收到的问题带回官方沟通渠道。
结果上下文
建立并持续使用官方的异步交流渠道，有助于建立一个基础的被动文档，当类似的问题再次出现时可以再次参考。
随着交流的公开化，其他人可以很容易地关注项目的进展，并积极做出贡献。其他人的聆听和阅读降低了参与的门槛，提高了获得贡献的可能性。
随着问题被公开回答，更多的人可以加入他们的观点，从而形成一个完整的画面--这不仅包括东道主团队成员，也包括项目的用户。
在异步渠道中保持交流，可以让不同时间段的参与者--无论是由于不同时区，还是由于不同的作息时间、会议时间、团队作息时间--对项目做出有意义的贡献。
在这些渠道中回答问题，不仅意味着其他团队成员可以倾听并提供额外的信息，也意味着有相同问题的其他用户可以看到（或后来找到）之前的答案，从而降低重复解释的需要。
已知实例
Europace AG
Paypal Inc.
Mercado Libre
作者
Isabel Drost-Fromm
状态
结构化
于2019年12月起草。
翻译校对
Last updated