交流工具

Title

交流工具

Patlet

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

上下文

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

问题

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

约束

  • 东道主团队有兴趣接受贡献,并愿意指导贡献者。

  • 团队有很强的口头沟通文化,在建立项目特定的异步沟通渠道方面缺乏经验。

  • 沟通渠道可能与应该接触到的特定群体使用习惯相一致,但不是以沟通目标进行选择的。

解决方案

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

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

  • 项目应该有自己的问题跟踪器,东道主团队成员采用公开透明的方式进行结构化的沟通、决策和进度跟踪需求,同时也鼓励下游的用户和贡献者遵循同样的原则进行沟通。

  • 该项目应该有一个或多个结构不太严格的讨论渠道。通常情况下,这将是邮件列表、在线论坛甚至是存档的聊天频道。通常情况下,项目开始时只有一个频道就足够了,如果流量增加太多,把关于项目使用的讨论和关于项目开发的讨论分开是有帮助的。

  • 此外,项目应该有一个私人频道,可以在 Trusted Committer 之间进行敏感的交流--例如,将更多的 Trusted Committer 加入到东道主团队中。这个渠道的使用应该非常谨慎,因为沟通默认为公开的,只有在非常罕见的情况下才会保持私密。

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

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

结果上下文

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

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

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

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

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

已知实例

  • Europace AG

  • Paypal Inc.

  • Mercado Libre

作者

Isabel Drost-Fromm

状态

  • 结构化

  • 于2019å¹´12月起草。

翻译校对

最后更新于