document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-25 23:11:02 +08:00
Code Issues Packages Projects Releases Wiki Activity

校对完毕

Browse Source 
校对完毕
This commit is contained in:
jasminepeng 2017-06-08 15:05:04 +08:00 committed by GitHub
parent 5eaeef07ff
commit 9fff4c72f2
1 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
translated/tech/20170509 Much ado about communication.md
View File

@ -9,21 +9,21 @@
开源项目要面对的首要挑战之一是如何在贡献者之间沟通。这里有很多的选择：论坛、聊天频道、问题列表、邮件列表、pull request 等等。我们该选择哪个合适的来使用，我们又该如何做呢？
令人遗憾的是，项目往往不愿作出有纪律的决定，而是选择“上述所有”。这就导致了一个支离破碎的社区：有些人使用 Slack/Mattermost/IRC，而有些人使用论坛，有些使用邮件列表，有些使用问题列表，很少有人都用这些。
令人遗憾的是，项目往往不愿做出约束性的决定，而是选择“上述所有”。这就导致了一个支离破碎的社区：有些人使用 Slack/Mattermost/IRC，而有些人使用论坛，有些使用邮件列表，有些使用问题列表，很少有人能够读到所有这些途径的内容。
我在组织中常见到的一个问题是。我[正在努力建立它们的内部和外部社区][2]。我们会选择哪个渠道，以及出于什么目的？另外，何时可以对它们之一说不呢？
在我[帮助建立内部和外部社区][2]的组织中,这是一个常见的问题。我们会选择哪个渠道，以及出于什么目的？另外，何时可以对它们之一说不呢？
这就是我想在此处深挖的。
这就是我想在此处深度探讨的。
### 结构化和非结构化
我只有一个很小的如花生大小的头脑。因此，我倾向于将问题分成小的部分，这样我可以更好地理解它们。类似地，我倾向于将一个情景中不同困难的选择变成更小的题目来更好地理解它们的目的。我在沟通渠道的选择上也使用这种方法。
我并不是个聪明人。因此，我倾向于将问题分成小的部分，这样我可以更好地理解它们。类似地，我倾向于将一个情景中不同困难的选择变成更小的题目，来更好地理解它们的目的。我在沟通渠道的选择上也使用这种方法。
我相信有两大沟通渠道的分类：结构化和非结构化
我认为有两大沟通渠道的分类：结构化和非结构化。
结构化渠道在每个单独的沟通单位中都有非常具体的重点。例子如：GitHub/GitLab /Jira issue。一个问题是与 bug 或功能有关的一个非常具体的信息。在帖子发布之后的的讨论中都通常非常集中在该特定主题上并会有一个结果（比如 bugfix 或者一个功能的最终计划）。结果通常都反映在状态（例如 “FIXED”、“WONTFIX” 或 “INVALID”）中。这意味着你可以了解沟通的开始和结束，而无需阅读中间的内容。
结构化渠道在每个单独的沟通单位中都有非常具体的重点。例子如：GitHub / GitLab /Jira 的 issue（问题）。一个问题是与 bug 或功能有关的一个非常具体的信息。在帖子发布之后的的讨论中，通常非常集中在该特定主题上并会有一个结果（比如 bugfix 或者一个功能的最终计划）。结果通常都反映在状态（例如 “FIXED”、“WONTFIX” 或 “INVALID”）中。这意味着你可以了解沟通的开始和结束，而无需阅读中间的内容。
类似的，pull/merge 请求也是结构化的。它们集中在特定类型（通常是代码）的贡献上。在最初的 pull/merge 请求后，讨论会会非常集中在一个结果上：让贡献符合要求来合并进入代码库中。
类似的，pull/merge 请求也是结构化的。它们集中在特定类型（通常是代码）的贡献上。在最初的 pull/merge 请求后，讨论会非常集中在一个结果上：让贡献符合要求，且合并入代码库中。
另一个例子是 StackOverflow/AskBot 这类的问答帖子。这些帖子以一个问题开始，接着被编辑以及回复来提供对这个问题的精确答案。
@ -33,11 +33,11 @@
### 记录的影响
除了结构化和非结构化沟通的微妙不同外，记录了什么的影响以及如何可以被搜索也扮演了一个很大的角色。
除了结构化和非结构化沟通的微妙不同外，记录了什么以及如何可以它们也扮演了一个很大的角色。
典型滴，所有的结构化渠道都是记录的。人们可以参考以前的 bug，来自 StackOverflow 的问题可以被反复地重用。你可以搜索一些东西，即使有很多讨论，问题，pull request 或者提问通常都会被更新以反映最终结论。
典型的，所有的结构化渠道都是记录的。人们可以参考以前的 bug，来自 StackOverflow 的问题可以被反复地重用。你可以搜索一些东西，即使有很多讨论，通常问题、pull request 或者提问都会被更新以反映最终结论。
这是一个重点：我们希望能够快速，轻松地挖掘旧问题/提问/pull request 等，并链接到它们、引用它们。这里的一个关键部分是我们把这个内容转换成可以引用的材料，可以用来教育和告知人们以前的知识。随着社区的发展，我们的结构化沟通成为一种知识全集，可以通过以往的经验来告知未来。
这是一个重点：我们希望能够快速、轻松地挖掘旧问题/提问/ pull request 等，并链接到它们、引用它们。这里的一个关键部分是我们把这个内容转换成可以引用的材料，从而可以用来教育和告知人们以前的知识。随着社区的发展，我们的结构化沟通成为一种知识全集，可以通过以往的经验来告知未来。
这使得非结构化沟通变得越来越糟。一方面，论坛的搜索通常都简单高效，但是它们当然充满了非结构化的对话，所以你正在寻找的东西可能被埋在讨论之中。例如，许多社区使用论坛作为支持工具。虽然这是一个更强大的平台，但是问题在于，一个问题的答案可能是在 16 楼或者 340 楼中有响应。随着越来越多的信息来源（比如 Twitter）的轰炸，我们越来越不耐烦地阅读大量的材料，这对于非结构化媒体来说可能是一个问题。
@ -55,13 +55,13 @@
虽然这个答案对于不同的项目会不同，但我想在两个层面思考。
首先，你应该通常有限考虑结构化沟通。这有有形的工作可以完成：在 bug/问题 上、pull request、在支持问答讨论上等等。如果你资源有限，那么专注在这些渠道上：你可以更轻松地在时间和金钱的支出以及在社区的高效产出上画一条虚线。
首先，你应该通常优先考虑结构化沟通。这是完成有形工作的地方：bug / issue、pull request、问答讨论等等。如果你资源有限，那么专注在这些渠道上，你可以用较少的时间和金钱支出，获得社区的高效产出。
再者，如果你热衷于建立一个可以专注于工程、宣传、翻译、文档等方面的更广泛的社区，那么探究是否引入非结构化渠道就有意义了。 社区不仅仅是为了完成工作，而且也是建立关系和友谊，在工作中相互支持，帮助人们在社区中发展壮大。非结构化通信是一个有用的工具。
再者，如果你热衷于建立一个可以专注于工程、宣传、翻译、文档等方面的更广泛的社区，那么探究是否引入非结构化渠道就有意义了。 社区不仅仅是为了完成工作，也是为了建立关系和友谊，在工作中相互支持，帮助人们在社区中发展壮大。非结构化通信是一个有用的工具。
当然，我这里只是抓住了庞大问题的表面，但是希望这对于如何评估和选择沟通渠道的价值提供一些清晰的想法。记住，少即是多：不要被引诱推迟决定并提供所有的渠道。否则你会得到一个支离破碎社区，就像一个空荡荡的餐厅一样。
当然，我只是在一个大的话题上浅谈即止。 不过我希望在如何评估和选择沟通渠道的价值方面，为大家提供了一些清晰的想法。记住，少即是多：不要被引诱推迟决定并提供所有的渠道。否则你会得到一个支离破碎社区，就像一个空荡荡的餐厅一样。
愿原力与你同在，请确保让我知道你进行的如何另外。你可以通过我的[网站][3]和邮箱 [jono@jonobacon.com][4] 联系到我。
愿力量与你同在，请让我知道你进行的如何。你可以通过我的[网站][3]和邮箱 [jono@jonobacon.com][4] 联系到我。
--------------------------------------------------------------------------------