|
1 |
| -## Title |
| 1 | +## 标题 |
2 | 2 |
|
3 |
| -Communication Tooling |
| 3 | +交流工具 |
4 | 4 |
|
5 | 5 | ## Patlet
|
6 | 6 |
|
7 |
| -An InnerSource project is being used outside the original development team but |
8 |
| -users are having trouble getting help and getting in touch with the project |
9 |
| -team. The idea is to set up and document standard communication tooling that |
10 |
| -allows for discussions to become visible, archived and searchable. |
| 7 | +一个InnerSource项目正在原始开发团队之外使用,但用户在寻求帮助和与项目团队联系时遇到困难。 |
| 8 | +我们的想法是建立和记录标准的通信工具,使讨论变得可见、存档和可搜索。 |
11 | 9 |
|
12 |
| -## Context |
| 10 | +## 上下文 |
13 | 11 |
|
14 |
| -A team depends on another team's component. It would like to make contributions |
15 |
| -to that component. Even when it happens in writing, communication happens in a |
16 |
| -1-on-1 fashion. |
| 12 | +一个团队依赖于另一个团队的组件。它希望对该组件做出贡献。 |
| 13 | +即使是书面形式的沟通,也是1对1的方式进行的。 |
17 | 14 |
|
18 |
| -## Problem |
| 15 | +## 问题 |
19 | 16 |
|
20 |
| -A team is open to receiving contributions from downstream users of their |
21 |
| -component. Coordination and communication happens in an ad-hoc fashion though |
22 |
| -leading to incoherent information being shared, delays in answers received, |
23 |
| -contributors pinging multiple host team members before receiving a definitive |
24 |
| -answer. |
| 17 | +一个团队愿意接受来来自于下游的他们的组件用户的贡献。 |
| 18 | +由于协调和沟通是以一种点对点的方式进行的,导致了信息共享的不连贯性,收到答复的延迟,贡献者于是在收到明确的答复前会呼叫多个东道主团队成员。 |
25 | 19 |
|
26 |
| -## Forces |
| 20 | +## 约束 |
27 | 21 |
|
28 |
| -- The host team is interested in receiving contributions and willing to mentor contributors. |
29 |
| -- Teams have a strong verbal communication culture and are inexperienced with setting up project specific asynchronous communication channels. |
30 |
| -- Communication channels may be aligned with specific groups that should be reached but not by communication purpose. |
| 22 | +- 东道主团队有兴趣接受贡献,并愿意指导贡献者。 |
| 23 | +- 团队有很强的口头沟通文化,在建立项目特定的异步沟通渠道方面缺乏经验。 |
| 24 | +- 沟通渠道可能与应该接触到的特定群体使用习惯相一致,但不是以沟通目标进行选择的。 |
31 | 25 |
|
32 |
| -## Solution |
| 26 | +## 解决方案 |
33 | 27 |
|
34 |
| -The host team needs to be clear on the benefit of providing company-public, |
35 |
| -archived, searchable, linkable communication channels that are free to subscribe |
36 |
| -to by anyone in the company. |
| 28 | +东道主团队需要明确提供公司公开的、存档的、可搜索的、可链接的沟通渠道的好处,公司内部的任何人都可以免费订阅信息。 |
37 | 29 |
|
38 |
| -The goal when streamlining communication channels for InnerSource projects |
39 |
| -should be to align communication around topics, not around certain sets of |
40 |
| -people: |
| 30 | +在精简 InnerSource 项目的沟通渠道时,目标应该是围绕主题进行沟通,而不是围绕某些人。 |
41 | 31 |
|
42 |
| -- The project should have its own issue tracker where structured communication, decision-making and progress tracking can happen transparently for all host team members but also for downstream users and contributors to follow. |
43 |
| -- The project should have one or more discussion channels that come with less rigid a structure. Typically, this will be mailing lists, online forums or even archived chat channels. Usually it is enough to start with just one channel for the project, if traffic increases too much it's helpful to split discussions about project usage from discussions about project development. |
44 |
| -- In addition, the project should have one private channel where sensitive communication can happen between [Trusted Committers](../trusted-committer.md) - e.g. adding further Trusted Committers to the host team. This channel should be used with great care such that communication defaults to open and is kept private only under very rare circumstances. |
| 32 | +- 项目应该有自己的问题跟踪器,东道主团队成员采用公开透明的方式进行结构化的沟通、决策和进度跟踪需求,同时也鼓励下游的用户和贡献者遵循同样的原则进行沟通。 |
| 33 | +- 该项目应该有一个或多个结构不太严格的讨论渠道。通常情况下,这将是邮件列表、在线论坛甚至是存档的聊天频道。通常情况下,项目开始时只有一个频道就足够了,如果流量增加太多,把关于项目使用的讨论和关于项目开发的讨论分开是有帮助的。 |
| 34 | +- 此外,项目应该有一个私人频道,可以在[Trusted Committer](./trusted-committer.md)之间进行敏感的交流--例如,将更多的Trusted Committer加入到东道主团队中。这个渠道的使用应该非常谨慎,因为沟通默认为公开的,只有在非常罕见的情况下才会保持私密。 |
45 | 35 |
|
46 |
| -While communication can happen outside of written channels, as much information |
47 |
| -as possible should be brought back to the asynchronous channels. |
| 36 | +虽然沟通可以发生在书面渠道之外,但尽可能多的信息应该被带回异步渠道。 |
48 | 37 |
|
49 |
| -All communication channels should be documented in the project `README.md`. The |
50 |
| -host team members need to make an effort to direct questions that they receive |
51 |
| -personally back to official communication channels. |
| 38 | +所有的通信渠道都应该在项目的`README.md`中进行记录。东道主团队成员需要努力将他们个人收到的问题带回官方沟通渠道。 |
52 | 39 |
|
53 |
| -## Resulting Context |
| 40 | +## 结果上下文 |
54 | 41 |
|
55 |
| -Setting up and consistently using official asynchronous communication channels |
56 |
| -helps create a base level of passive documentation that can be referenced again |
57 |
| -when similar questions come up again. |
| 42 | +建立并持续使用官方的异步交流渠道,有助于建立一个基础的被动文档,当类似的问题再次出现时可以再次参考。 |
58 | 43 |
|
59 |
| -With communication happening in the open others can easily follow project |
60 |
| -progress and get active contributing. Others lurking and reading lowers the |
61 |
| -barrier to get involved raising the likelihood of receiving contributions. |
| 44 | +随着交流的公开化,其他人可以很容易地关注项目的进展,并积极做出贡献。其他人的聆听和阅读降低了参与的门槛,提高了获得贡献的可能性。 |
62 | 45 |
|
63 |
| -With questions being answered in public more people can add their perspective |
64 |
| -leading to a complete picture - this includes not only host team members, |
65 |
| -but also users of the project. |
| 46 | +随着问题被公开回答,更多的人可以加入他们的观点,从而形成一个完整的画面--这不仅包括东道主团队成员,也包括项目的用户。 |
66 | 47 |
|
67 |
| -Keeping communication in asynchronous channels allows for participants on |
68 |
| -different schedules - either due to different time zones or due to different |
69 |
| -routines, meeting schedules, team routines - to meaningfully contribute to |
70 |
| -the project. |
| 48 | +在异步渠道中保持交流,可以让不同时间段的参与者--无论是由于不同时区,还是由于不同的作息时间、会议时间、团队作息时间--对项目做出有意义的贡献。 |
71 | 49 |
|
72 |
| -Answering questions in those channels means that not only other team members |
73 |
| -can listen in and provide additional information, it also means that other |
74 |
| -users with the same question see (or later find) the previous answer leading |
75 |
| -to a lower need to repeat explanations. |
| 50 | +在这些渠道中回答问题,不仅意味着其他团队成员可以倾听并提供额外的信息,也意味着有相同问题的其他用户可以看到(或后来找到)之前的答案,从而降低重复解释的需要。 |
76 | 51 |
|
77 |
| -## Known Instances |
| 52 | +## 已知实例 |
78 | 53 |
|
79 | 54 | * Europace AG
|
80 | 55 | * Paypal Inc.
|
81 | 56 |
|
82 |
| -## Authors |
| 57 | +## 作者 |
83 | 58 |
|
84 | 59 | Isabel Drost-Fromm
|
85 | 60 |
|
86 |
| -## Status |
| 61 | +## 状态 |
87 | 62 |
|
88 |
| -* Structured |
89 |
| -* Drafted in December 2019. |
| 63 | +* 结构化 |
| 64 | +* 于2019年12月起草。 |
| 65 | + |
| 66 | +## 翻译校对 |
| 67 | + |
| 68 | +* 翻译 [姜宁]: https://github.com/willemjiang |
| 69 | +* 校对[龙文选](https://github.com/hncslwx) |
0 commit comments