document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2024-12-26 21:30:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

translated

Browse Source
This commit is contained in:
geekpi 2017-06-02 11:01:24 +08:00
parent 0a111b9212
commit a8d31694a3
2 changed files with 88 additions and 90 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

90
sources/tech/20170509 Much ado about communication.md
View File

@ -1,90 +0,0 @@
translating--geekpi
Much ado about communication
============================================================
### One of an open source project's first challenges is determining the best way for contributors to collaborate.
![Much ado about communication](https://opensource.com/sites/default/files/styles/image-full-size/public/images/business/rh_003601_05_mech_osyearbook2016_business_cc.png?itok=xZestz1h "Much ado about communication")
>Image by : Opensource.com
One of the first challenges an open source project faces is how to communicate among contributors. There are a plethora of options: forums, chat channels, issues, mailing lists, pull requests, and more. How do we choose which is the right medium to use and how do we do it right?
Sadly and all too often, projects shy away from making a disciplined decision and instead opt for "all of the above." This results in a fragmented community: Some people sit in Slack/Mattermost/IRC, some use the forum, some use mailing lists, some live in issues, and few read all of them.
This is a common issue I see in organizations I'm [working with to build their internal and external communities][2]. Which of these channels do we choose and for which purposes? Also, when is it OK to say no to one of them?
This is what I want to dig into here.
### Structured and unstructured
I have a tiny, peanut-sized brain in my head. Because of this, I tend to break problems down into smaller pieces so I can better understand them. Likewise, I tend to break different options in a scenario down into smaller thematic pieces to better understand their purpose. I take this approach with communication channels too.
I believe there are two broad categories of communication channels: structured and unstructured.
Structured channels have a very specific focus in each individual unit of communication. An example here is a GitHub/GitLab/Jira issue. An issue is a very specific piece of information that relates to a bug or feature. The discussion that cascades after the initial issue post is typically very focused on that specific topic and finding an outcome (such as a bugfix or a final plan for a feature). The outcome is then typically reflected in a status (e.g. "FIXED," "WONTFIX," or "INVALID"). This means you can understand the beginning and end of the communication without reading the pieces in between.
Likewise, pull/merge requests are structured. They are focused on a specific type (typically code) of contribution. After the initial pull/merge request, the discussion is very focused on an outcome: getting the contribution in shape to merge into the wider codebase.
Another example here is a StackOverflow/AskBot style Q&A post. These posts start with a question and are then edited and responded to in order to provide a concise answer to the question.
With each of these structured mechanisms there usually is little deviation from the structure. You never see people asking others how their kids/cats/dogs/family are doing in an issue, pull request, or Q&A topic. It is socially unacceptable to veer off topic, and that is part of the power of a structured medium: It is focused and (usually) efficient.
The inverse, unstructured media, include chat channels and forums. In these environments there is typically a theme (such as the topic of a channel or sub-forum), but conversations are much less tied to a specific outcome or conclusion and can often be more general in nature. As an example, in a developer mailing list you will get a mix of discussions including general questions, ideas for new features, architectural challenges, and discussions that relate to the operational running of the community itself. With each of these discussions it is imperative on the participants to keep the conversation focused, on topic, and productive. As you can imagine, this is often not the case, and these kinds of discussions can veer away from a productive outcome.
### The impact of recording
Aside from the subtle differences between structured and unstructured communication, the impact of what is recorded and how it can be searched plays a large role too.
Typically, all structured channels are recorded. People reference old bugs, questions from StackOverflow are reused over and over again. You can search for something, and even if there is lots of discussion, the issue, pull request, or question is usually updated to reflect the ultimate conclusion.
This is part of the point: We want to be able to quickly and easily dig up old issues/questions/pull requests/etc., link to them, and reference them. A key component here is that we convert this content into referenceable material that can be used to educate and inform people about previous knowledge. As our community grows, our structured communication becomes a corpus of knowledge that can inform the future from lessons in the past.
This gets murkier with unstructured communication. On one hand, forums are generally simple and effective to search, but they are of course filled with unstructured conversation, so the thing you are looking for might be buried inside a discussion. As an example, many communities use a forum as a support tool. While this is a more than capable platform, the problem is that the answer to a question may be response #16 or response #340 in a discussion. As we are bombarded with more and more sources of information (and in smaller pieces, such as Twitter), we have become increasingly impatient to reading through large swaths of material, and this can be problematic with an unstructured medium.
A particularly interesting case is real-time chat. Historically, IRC has paved the way for real-time chat for many years, and for most IRC users there was little (if any) notion of recording those discussions. Sure, some projects (such as Ubuntu) record IRC logs, but this is generally not a useful resource. As my pal Jeff Atwood said to me once: "If you have to search chat for something, you have already lost."
While IRC is limited in recording, Slack and Mattermost are better. Conversations are archived, but the point still typically stands: Why would you want to search through large bodies of conversation to find a point that someone made? Other channels are far better for referencing previous discussions.
This does create an interesting opportunity though. One consistent benefit that chat exhibits over all other media is how human it is. Structured channels, and even unstructured channels such as forums and mailing lists, rarely encourage off-the-cuff social discussion. Chat does. Chat is where you ask: "How was your weekend?" "Did you see the game?" and "Are you going to see Testament, Sepultura, and Prong next week?" (OK, maybe the last one is just me.)
So, while real-time discussion may be less effective in our corpus of previous collaboration, it does provide a vital glue in shaping relationships.
### Choose your poison
So, back to our original question for open source communities: Which of these do we pick?
While this answer will vary from project to project, I tend to think of this on two levels.
First, you should generally prioritize structured communication. This is where tangible work gets done: in bugs/issues, pull requests, in support Q&A discussions, etc. If you are tight on resources, focus your efforts on these channels: You can more easily draw a dotted line between the investment of time and money there and productive output in the community.
Second, if you are passionate about building a broader community that can focus on engineering, advocacy, translations, documentation, and more, explore whether bringing in unstructured channels makes sense. Community is not just about getting stuff done, it is also about building relationships and friendships, providing support to each other in our work, and helping people grow and flourish in our communities. Unstructured communication is a helpful tool in this.
Of course, I am merely scratching the surface of a large topic here, but I hope this provides a little clarity in how to assess and choose the value of communication channels. Remember, less is more here: Don't be tempted to defer the decision and provide all of the above; you will get a fragmented community that's just about as inviting as an empty restaurant.
May the force be with you, and be sure to let me know how you get on. I am always available through my [website][3] and at [jono@jonobacon.com][4].
--------------------------------------------------------------------------------
作者简介：
Jono Bacon - Jono Bacon is a leading community manager, speaker, author, and podcaster. He is the founder of Jono Bacon Consulting which provides community strategy/execution, developer workflow, and other services. He also previously served as director of community at GitHub, Canonical, XPRIZE, OpenAdvantage, and consulted and advised a range of organizations.
--------------------
via: https://opensource.com/article/17/5/much-ado-about-communication
作者：[ Jono Bacon][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com/users/jonobacon
[1]:https://opensource.com/article/17/5/much-ado-about-communication?rate=fBsUIx1TCGIXAFnRdYGTUqSG1pMmMCpdhYlyrFtRLS8
[2]:http://www.jonobaconconsulting.com/
[3]:http://www.jonobacon.com/
[4]:mailto:jono@jonobacon.com
[5]:https://opensource.com/user/26312/feed
[6]:https://opensource.com/users/jonobacon

88
translated/tech/20170509 Much ado about communication.md Normal file
View File

@ -0,0 +1,88 @@
关于沟通的很多纷扰
============================================================
### 开源项目的首要挑战是找出最佳的贡献者协作方式
![Much ado about communication](https://opensource.com/sites/default/files/styles/image-full-size/public/images/business/rh_003601_05_mech_osyearbook2016_business_cc.png?itok=xZestz1h "Much ado about communication")
>图片提供： Opensource.com
开源项目要面对的首要挑战之一是如何在贡献者之间沟通。这里有很多的选择：论坛、聊天频道、问题列表、邮件列表、pull request 等等。我们该选择哪个合适的来使用，我们又该如何做呢？
令人遗憾的是，项目往往不愿作出有纪律的决定，而是选择“上述所有”。这就导致了一个支离破碎的社区：有些人使用 Slack/Mattermost/IRC，而有些人使用论坛，有些使用邮件列表，有些使用问题列表，很少有人都用这些。
我在组织中常见到的一个问题是。我[正在努力建立它们的内部和外部社区][2]。我们会选择哪个渠道，以及出于什么目的？另外，何时可以对它们之一说不呢？
这就是我想在此处深挖的。
### 结构化和非结构化
我只有一个很小的如花生大小的头脑。因此，我倾向于将问题分成小的部分，这样我可以更好地理解它们。类似地，我倾向于将一个情景中不同困难的选择变成更小的题目来更好地理解它们的目的。我在沟通渠道的选择上也使用这种方法。
我相信有两大沟通渠道的分类：结构化和非结构化
结构化渠道在每个单独的沟通单位中都有非常具体的重点。例子如：GitHub/GitLab /Jira issue。一个问题是与 bug 或功能有关的一个非常具体的信息。在帖子发布之后的的讨论中都通常非常集中在该特定主题上并会有一个结果（比如 bugfix 或者一个功能的最终计划）。结果通常都反映在状态（例如 “FIXED”、“WONTFIX” 或 “INVALID”）中。这意味着你可以了解沟通的开始和结束，而无需阅读中间的内容。
类似的，pull/merge 请求也是结构化的。它们集中在特定类型（通常是代码）的贡献上。在最初的 pull/merge 请求后，讨论会会非常集中在一个结果上：让贡献符合要求来合并进入代码库中。
另一个例子是 StackOverflow/AskBot 这类的问答帖子。这些帖子以一个问题开始，接着被编辑以及回复来提供对这个问题的精确答案。
通过这些结构化机制，通常几乎不会偏离本来结构。你不会在问题列表，pull request 或问答主题上看到有人问别人他们的孩子/猫/狗/家人在做什么。偏离主题是社区上不可接受的，这是结构化媒体的力量的一部分：它是集中和（通常）高效的。
反之，非结构化媒体包括聊天频道和论坛。在这些环境中，通常会有一个主题（例如频道或分论坛的主题），但是会话与特定结果或结论的关系要小得多，而且通常情况下可能会更普遍。例如，在开发者邮件列表中，你会看到一系列讨论，包括一般问题、新功能的想法、架构挑战以及与社区自身运营相关的讨论。每一个讨论都必须让参与者保持对话的焦点、主题和工作效率。你可以想象，情况往往不是这样的, 这种讨论可能会偏离一个富有成效的结果。
### 记录的影响
除了结构化和非结构化沟通的微妙不同外，记录了什么的影响以及如何可以被搜索也扮演了一个很大的角色。
典型滴，所有的结构化渠道都是记录的。人们可以参考以前的 bug，来自 StackOverflow 的问题可以被反复地重用。你可以搜索一些东西，即使有很多讨论，问题，pull request 或者提问通常都会被更新以反映最终结论。
这是一个重点：我们希望能够快速，轻松地挖掘旧问题/提问/pull request 等，并链接到它们、引用它们。这里的一个关键部分是我们把这个内容转换成可以引用的材料，可以用来教育和告知人们以前的知识。随着社区的发展，我们的结构化沟通成为一种知识全集，可以通过以往的经验来告知未来。
这使得非结构化沟通变得越来越糟。一方面，论坛的搜索通常都简单高效，但是它们当然充满了非结构化的对话，所以你正在寻找的东西可能被埋在讨论之中。例如，许多社区使用论坛作为支持工具。虽然这是一个更强大的平台，但是问题在于，一个问题的答案可能是在 16 楼或者 340 楼中有响应。随着越来越多的信息来源（比如 Twitter）的轰炸，我们越来越不耐烦地阅读大量的材料，这对于非结构化媒体来说可能是一个问题。
一个专门的有趣案例是实时聊天。历史上，IRC 很多年来为实时聊天铺平了道路，对于大多数 IRC 用户而言很少有（如果有）记录这些讨论的念头。的确，一些项目（比如 Ubuntu）记录了 IRC 日志，但是这通常不是有用的资源。如我的伙伴 Atwood 有一次跟我说的：“如果你不得不在聊天中搜索一些东西时，你已经输了。”
虽然 IRC 在记录上有限制，但是 Slack 和 Mattermost 会好点。交流会被归档，但是问题仍旧存在：你为什么会想在海量的聊天信息中找出一个人提出的观点呢？其他的渠道能更好地引用先前的讨论。
不过，这的确创造了一个有趣的机会。聊天相比其他媒体的一个一贯的好处是能体现这是个怎样的人。结构化的渠道，甚至非结构化的渠道，如论坛和邮件列表，很少鼓励袖手旁观的社交讨论。但聊天是的。聊天时你会问：“你周末怎么样？”、 “你见过这个游戏吗？”还有“你下周会看 Testament，Sepultura 和 Prong 吗？” （好吧，也许最后一个只是我。）
因此，虽然实时聊天相比前面的那些方式也许更低效一些，但是它的确增进了人们的关系。
### 选择你的毒药
因此，回到我们最初的对于开源社区的提问：我们要选择哪个？
虽然这个答案对于不同的项目会不同，但我想在两个层面思考。
首先，你应该通常有限考虑结构化沟通。这有有形的工作可以完成：在 bug/问题 上、pull request、在支持问答讨论上等等。如果你资源有限，那么专注在这些渠道上：你可以更轻松地在时间和金钱的支出以及在社区的高效产出上画一条虚线。
再者，如果你热衷于建立一个可以专注于工程、宣传、翻译、文档等方面的更广泛的社区，那么探究是否引入非结构化渠道就有意义了。 社区不仅仅是为了完成工作，而且也是建立关系和友谊，在工作中相互支持，帮助人们在社区中发展壮大。非结构化通信是一个有用的工具。
当然，我这里只是抓住了庞大问题的表面，但是希望这对于如何评估和选择沟通渠道的价值提供一些清晰的想法。记住，少即是多：不要被引诱推迟决定并提供所有的渠道。否则你会得到一个支离破碎社区，就像一个空荡荡的餐厅一样。
愿原力与你同在，请确保让我知道你进行的如何另外。你可以通过我的[网站][3]和邮箱 [jono@jonobacon.com][4] 联系到我。
--------------------------------------------------------------------------------
作者简介：
Jono Bacon - Jono Bacon 是一名领先的社区管理者、演讲者、作者和播客。他是 Jono Bacon Consulting 的创始人，提供社区策略/执行、开发者工作流程和其他服务。他以前曾担任 GitHub、Canonical、XPRIZE、OpenAdvantage 的社区总监，并为很多组织曾经提供建议和咨询。
--------------------
via: https://opensource.com/article/17/5/much-ado-about-communication
作者：[ Jono Bacon][a]
译者：[geekpi](https://github.com/geekpi)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com/users/jonobacon
[1]:https://opensource.com/article/17/5/much-ado-about-communication?rate=fBsUIx1TCGIXAFnRdYGTUqSG1pMmMCpdhYlyrFtRLS8
[2]:http://www.jonobaconconsulting.com/
[3]:http://www.jonobacon.com/
[4]:mailto:jono@jonobacon.com
[5]:https://opensource.com/user/26312/feed
[6]:https://opensource.com/users/jonobacon