Go，开源，社区

本文为官方 Go Blog 的中文翻译，详见 翻译说明

拉斯・考克斯
2015 年 7 月 8 日

欢迎#

[这是我在 Gophercon 2015 上的开幕主题演讲的文本。视频可在此处。]

谢谢大家前往丹佛，也感谢所有观看视频的人。如果这是您的第一个 Gophercon，欢迎您。如果您去年在这里，欢迎回来。感谢组织者为召开这样的会议所做的所有工作。我很高兴来到这里并能够与大家交谈。

我是 Go 项目和 Google Go 团队的技术负责人。我和罗伯・派克 (Rob Pike) 一样。在担任该职位期间，我花了很多时间思考整个 Go 开源项目，尤其是其运行方式，开源的意义以及 Google 内部和外部的贡献者之间的互动。今天，我想与大家分享我如何看待整个 Go 项目，然后在此基础上解释一下我如何看待 Go 开源项目的发展。

为什么去？#

要开始，我们必须回到起点。我们为什么开始研究 Go？

Go 是一种尝试，旨在提高程序员的生产力。我们希望改善 Google 的软件开发流程，但是 Google 所遇到的问题并非 Google 独有。

有两个总体目标。

第一个目标是开发一种更好的语言，以应对可伸缩并发的挑战。可扩展的并发性是指可以同时处理许多问题的软件，例如通过来回发送网络流量来协调一千台后端服务器。

如今，这种软件有了更短的名称：我们称其为云软件。可以说，Go 是在云运行软件之前为云设计的。

更大的目标是提供一个更好的环境，以应对可伸缩软件开发，由许多人使用和使用的软件，它们之间的协调有限且可以维护多年的挑战。在 Google，我们有成千上万的工程师彼此编写和共享代码，试图完成他们的工作，尽可能多地重用他人的工作，并使用具有十年历史的代码库工作。工程师经常研究或至少研究最初由他人编写的代码，或者至少是他们几年前编写的代码，而这些代码通常是同一回事。

Google 内部的这种情况与在 GitHub 等网站上实践的大规模现代开放源代码开发有很多共同点。因此，Go 非常适合开源项目，可以帮助他们在很长一段时间内接受和管理大型社区的贡献。

我相信 Go 的成功很大程度上可以归因于以下事实：Go 非常适合云软件，Go 非常适合开源项目，并且偶然地，这两者在软件行业中越来越流行并且越来越重要。

其他人也有类似的看法。这是两个。去年，Donnie Berkholz 在 RedMonk.com 上写道：“ 成为云基础架构的新兴语言，” 观察到 “[Go's] 字幕项目... 是以云为中心的，或者以其他方式处理分布式系统或瞬态环境。”

今年，作者在 Texlution.com 上写了一篇文章，标题为 “ 为什么 Golang 注定要成功，” 结果表明，这种对大规模开发的关注甚至可能比 Google 本身更适合于开源：“这种开源的适应性就是为什么我认为您将会看到越来越多的 Go go ...”

平衡#

Go 如何完成这些任务？

它如何使可伸缩并发性和可伸缩软件开发更容易？

大多数人通过谈论通道和 goroutine，接口，快速构建，go 命令以及良好的工具支持来回答这个问题。这些都是答案的重要组成部分，但我认为它们背后有一个更广泛的想法。

我认为该想法是 Go 的平衡。在任何软件设计中都存在相互竞争的问题，并且很自然地会尝试解决您预见的所有问题。在 Go 中，我们明确尝试不解决所有问题。取而代之的是，我们已尽力做到足以轻松构建自己的自定义解决方案。

我总结 Go 选择的余额的方式是：少做些。启用更多。

少做一点，但是多做些。

Go 不能做所有事情。我们不应该尝试。但是，如果我们努力工作，Go 可能会做得很好。如果我们仔细选择这些东西，我们可以为开发人员可以轻松构建他们需要的解决方案和工具奠定基础，并且理想情况下可以与其他人构建的解决方案和工具进行互操作。

例子#

让我用一些例子来说明这一点。

首先，Go 语言本身的大小。为了避免在大型开发人员社区的不同部分形成相互难以理解的方言，我们付出了尽可能多的努力。直到将其简化为实质并获得明显的好处 (证明增加了复杂性) 之后，Go 才真正想到。

通常，如果我们有 100 项希望 Go 做好的事情，我们将无法进行 100 项单独的更改。取而代之的是，我们尝试研究和理解设计空间，然后确定一些可以很好地协同工作的变更，这些变更可能使其中的 90 件事成为可能。我们愿意牺牲其余的 10 个语言，以免使该语言肿，避免增加复杂性，仅解决在今天看来很重要但在明天可能消失的特定用例。

保持较小的语言可以实现更重要的目标。较小的体积使 Go 易于学习，易于理解，易于实现，易于重新实现，易于调试，易于调整，易于开发。少做多做。

我应该指出，这意味着我们对很多其他人的想法都拒绝，但我向您保证，我们对自己的更多想法都说不。

接下来，渠道和 goroutines。我们应该如何构造和协调并发和并行计算？互斥量和条件变量非常通用，但是级别很低，很难正确使用。诸如 OpenMP 之类的并行执行框架是如此高级，以至于只能用于解决一小部分问题。通道和 goroutines 位于这两个极端之间。就其本身而言，它们并不能解决很多问题。但是它们足够强大，可以轻松安排以实现对并发软件中许多常见问题的解决方案。少做 - 确实做得足够 - 可以做更多。

接下来，类型和接口。拥有静态类型可以启用有用的编译时检查，这是诸如 Python 或 Ruby 之类的动态类型语言所缺少的。同时，Go 的静态类型避免了传统静态类型语言的大部分重复，使它感觉更轻巧，更像是动态类型的语言。这是人们注意到的最早的东西之一，Go 的许多早期采用者来自动态类型的语言。

Go 的界面是其中的关键部分。特别是，如果省略具有静态层次结构的 Java 或其他语言的实现声明，则会使接口的重量更轻且更灵活。没有那种严格的层次结构会启用习惯用法，例如描述现有的，不相关的生产实现的测试接口。少做多做。

接下来，进行测试和基准测试。大多数语言是否都缺乏测试和基准测试框架？他们之间有协议吗？

Go 的测试包并不意味着解决这些主题的所有可能方面。相反，它旨在提供大多数高级工具所必需的基本概念。程序包中的测试用例通过，失败或被跳过。程序包具有运行的基准，并且可以通过各种指标进行衡量。

此处不做任何尝试都是为了将​​这些概念简化为实质，以创建共享词汇，以便更丰富的工具可以互操作。该协议可以启用更高级的测试软件，例如 Miki Tebeka 的 go2xunit 转换器，或者 Benchcmp 和 Benchstat 基准分析工具。

因为关于基本概念的表示存在 * 共识，所以这些高级工具适用于所有 Go 软件包，而不仅是那些努力加入的软件包，而且它们彼此互操作，例如使用 go2xunit 并不排除也使用 Benchstat，就像这些工具是竞争性测试框架的插件一样。少做多做。

接下来，进行重构和程序分析。因为 Go 是用于大型代码库的，所以我们知道它需要支持自动维护和源代码更新。我们也知道这个话题太大了，无法直接建立。但是我们知道我们必须做的一件事。根据我们尝试在其他设置中自动更改程序的经验，我们遇到的最大障碍实际上是将修改后的程序以开发人员可以接受的格式写出来。

在其他语言中，不同的团队通常使用不同的格式约定。如果程序的编辑使用了错误的约定，则它要么编写源文件的某个部分，使其看起来与文件的其余部分不同，要么重新格式化整个文件，从而导致不必要的不​​必要的差异。

去没有这个问题。我们设计了使 gofmt 成为可能的语言，我们努力使 gofmt 的格式对于所有 Go 程序都可接受，并且我们确保 gofmt 从原始公开发布的第一天就存在。 Gofmt 具有统一性，因此自动更改会混入文件的其余部分。您无法分辨是人还是计算机进行了特定更改。我们没有建立明确的重构支持。建立一致同意的格式化算法足以为独立工具的开发和互操作提供一个共享基础。 Gofmt 已启用 gofix，goimports 等工具。我相信这里的工作才刚刚开始。甚至可以做更多的事情。

最后，构建和共享软件。在 Go 1 的启动过程中，我们构建了 goinstall，它成为了大家都称为 “go get” 的东西。该工具定义了一种标准的零配置方式来解析 github.com 等网站上的导入路径，后来又定义了一种通过发出 HTTP 请求来解析其他网站上的路径的方法。这项公认的解析算法使其他可在这些路径下使用的工具成为可能，最著名的是 Gary Burd 创建的 godoc.org。如果您没有使用过它，请访问 godoc.org/the-import-path 以获取任何有效的 “ go get” 导入路径，该网站将获取代码并向您显示其文档。这样做的一个很好的副作用是，godoc.org 可以用作公开可用的 Go 软件包的粗略主列表。我们所做的只是给导入路径一个明确的含义。少做，多做。

您会注意到，其中许多工具示例都是关于建立共享约定的。有时，人们称此为 Go 被 “调皮”，但是还有更深层次的事情发生。同意共享约定的局限性是一种实现广泛互操作的工具的方法，因为它们都使用相同的基础语言。这是减少工作量却可以实现更多工作的非常有效的方法。具体来说，在很多情况下，我们可以做最少的事情来建立对特定概念的共识，例如远程导入或对源文件进行正确的格式设置，从而可以创建可以一起使用的软件包和工具，因为它们都同意关于那些核心细节。

我将稍后再回到这个想法。

为什么要开源？#

但是首先，正如我之前所说，我想解释一下我如何看待 “尽力而为” 和 “实现更多” 之间的平衡，指导我们在更广泛的 Go 开源项目中的工作。为此，我需要从为什么 Go 完全是开源开始。

Google 付钱给我和其他人从事 Go 的工作，因为如果 Google 的程序员的生产力更高，那么 Google 可以更快地构建产品，更轻松地维护它们，等等。但是为什么要开源 Go？ Google 为什么要与全世界分享这项利益？

当然，我们中的许多人在 Go 之前从事开源项目的工作，我们自然希望 Go 成为该开源世界的一部分。但是，我们的偏好并不是商业理由。业务理由是 Go 是开源的，因为这是 Go 成功的唯一途径。我们 (在 Google 内部构建 Go 的团队) 从一开始就知道这一点。我们知道，必须让尽可能多的人使用 Go 才能成功。

封闭的语言消亡。

语言需要广泛的社区。

语言需要大量的人编写大量的软件，因此，当您需要特定的工具或库时，很有可能已经由比您更了解该主题并且花费了更多时间的人编写了该语言使它变得很棒。

语言需要大量的人员报告错误，以便快速发现并解决问题。由于用户群更大，因此 Go 编译器比以前松散地基于的 Plan 9 C 编译器更加健壮和符合规范。

一种语言需要大量的人将其用于多种不同的用途，因此该语言不会过分适合一个用例，并且在技术格局变化时最终无用。

一种语言需要很多想学习它的人，因此人们就有了写书，讲课或举办会议的市场。

如果 Go 留在 Google 内部，那么这一切都不会发生。 Go 会在 Google 内部，任何一家公司或封闭环境中窒息而死。

从根本上来说，围棋必须是开放的，围棋需要您。没有所有人，没有所有人都可以使用 Go 进行世界各地的各种项目，Go 不会成功。

反过来，Google 的 Go 团队再也无法支持整个 Go 社区。为了保持规模，我们需要在少做些事情的同时使所有这些 “更多”，开源是其中的很大一部分。

Go 的开源#

开源是什么意思？最低要求是打开源代码，使其在开放源代码许可下可用，而我们已经做到了。

但是我们也打开了开发过程：自宣布 Go 以来，我们已经在公开的邮件列表上公开进行了所有开发。我们接受并审查任何人的源代码贡献。无论您是否为 Google 工作，该过程都是相同的。我们在公共场所维护错误跟踪程序，在公共场所讨论和开发更改建议，并努力在公共场合发布版本。公共源代码树是权威副本。变化首先在那发生。它们仅在以后被带入 Google 的内部源代码树。对于 Go 来说，开源是意味着这是一项集体努力，超越了 Google，向所有人开放。

任何开放源代码项目都始于几个人，通常只有一个人，但是 Go 语言只有三个人：Robert Griesemer，Rob Pike 和 Ken Thompson。他们对自己想要 Go 成为一个愿景，认为 Go 可以比现有语言做得更好，Robert 将在明天早上谈论更多。我是加入团队的下一个人，然后是 Ian Taylor，然后是一个接一个的人，到今天为止，我们已经有了数百名贡献者。

谢谢您到目前为止为 Go 项目贡献代码或想法或错误报告的许多人。今天，我们试图列出该计划中我们所能提供的所有人员。如果您的名字不存在，我深表歉意，谢谢。

我相信到目前为止，数百名贡献者正在为实现 Go 的愿景达成共识。这些事情很难说出来，但是我尽力早点解释了愿景的一部分：少做多做。

Google 的角色#

一个自然的问题是：与其他贡献者相比，Google Go 团队的作用是什么？我相信角色会随着时间而改变，并且会不断变化。总的趋势是，随着时间的流逝，Google 的 Go 团队应该做的更少，而需要做的更多。

在 Go 尚未为大众所知的早期，Google 的 Go 团队显然是在自己工作。我们编写了所有内容的初稿：规范，编译器，运行时，标准库。

不过，一旦 Go 开源之后，我们的角色便开始发生变化。我们需要做的最重要的事情是传达我们对 Go 的愿景。这很困难，我们仍在努力。最初的实现是传达此愿景的重要方式，我们领导的开发工作导致了 Go 1 的开发，以及我们撰写的各种博客文章，文章和讨论已经出版。

但是正如罗布 (Rob) 去年在 Gophercon 上说的那样，“语言已经完成。” 现在，我们需要了解它的工作原理，人们如何使用它，了解人们的构建。现在的重点是扩大 Go 可以帮助的工作类型。

Google 现在的主要作用是使社区能够协调，确保变更能够很好地协同工作，并使 Go 忠实于最初的愿景。

Google 的主要作用是：少做事。启用更多。

前面我提到过，我们宁愿拥有少量功能，例如可以启用 90％的目标用例，并避免将数量级提高到 99％或 100％所需的更多功能。我们已经成功地将该策略应用于我们熟知的软件领域。但是，如果 Go 要在许多新领域中变得有用，我们需要那些领域的专家将他们的专业知识带入我们的讨论中，以便我们可以共同设计一些小的调整措施，以使 Go 能够有许多新的应用程序。

这种转变不仅适用于设计，还适用于开发。 Google 的 Go 小组的角色继续转移到指南之一，而不再是纯粹的开发。与编写代码相比，我花更多的时间进行代码审查，比自己提交错误报告要花费更多的时间来处理错误报告。我们需要少做些，多做些。

随着设计和开发转向更广泛的 Go 社区，Go 的原始作者可以提供的最重要的事情之一就是愿景的一致性，以帮助保持 Go Go。我们必须达到的平衡当然是主观的。例如，一种可扩展语法的机制将是一种允许使用更多方式编写 Go 代码的方式，但这将与我们拥有一致的语言而没有不同的方言的目标背道而驰。

有时候，我们不必多说，也许比其他语言社区多。但是，当我们这样做时，我们的目标是建设性和尊重地这样做，以此作为阐明 Go 愿景的机会。

当然，这不只是协调和远见。 Google 仍在资助 Go 开发工作。瑞克・哈德森 (Rick Hudson) 今天晚些时候将谈论他在减少垃圾收集器延迟方面的工作，而汉娜・金 (Hana Kim) 明天将谈论她在将 Go 引入移动设备方面的工作。但我想说明的是，我们的目标是尽可能地将 Google 资助的开发等同于其他公司资助的开发或个人利用业余时间贡献的开发。我们这样做是因为我们不知道下一个好主意将从何而来。每个为 Go 做出贡献的人都应该有机会被倾听。

例子#

我想分享一些有关这种说法的证据，即随着时间的推移，Google 最初的 Go 团队将重点更多地放在了协调上，而不是直接开发上。

首先，Go 开发的资金来源正在扩大。在开源发布之前，显然 Google 支付了所有 Go 开发费用。开源发布后，许多人开始贡献自己的时间，而我们在缓慢而稳步地增加了由其他公司支持以从事兼职工作的贡献者的数量，尤其是与使 Go 更加有用这些公司。今天，该列表包括 Canonical，Dropbox，Intel，Oracle 等。当然，Gophercon 和其他区域 Go 会议完全由 Google 以外的人组织，除了 Google 之外，他们还有许多公司赞助商。

其次，原始团队之外进行的 Go 开发的概念深度正在扩大。

开源发布后，立即做出的第一个重大贡献就是移植到 Microsoft Windows，该移植由 Hector Chu 启动，由 Alex Brainman 等完成。更多贡献者移植到了其他操作系统。甚至有更多的贡献者重写了我们的大多数数字代码，以便更快或更精确，或两者兼而有之。这些都是重要的贡献，非常感谢，但是在大多数情况下，它们不涉及新设计。

最近，由 AramHăvărneanu 领导的一组贡献者将 Go 移植到了 ARM 64 体系结构，这是 Google 外部贡献者的第一个体系结构端口。这很重要，因为与支持新操作系统相比，对新架构的支持通常需要更多的设计工作。体系结构之间的差异大于操作系统之间的差异。

另一个例子是过去几个发行版中对使用共享库构建 Go 程序的初步支持的介绍。此功能对许多 Linux 发行版很重要，但对 Google 却不那么重要，因为我们部署了静态二进制文件。我们一直在帮助指导整体策略，但是大多数设计和几乎所有实施都是由 Google 外部的贡献者完成的，尤其是 Michael Hudson-Doyle。

我的最后一个示例是 go 命令的供应商方法。我将供应商定义为将外部依赖项的源代码复制到树中，以确保它们不会消失或在脚下改变。

供应商并不是 Google 所遭受的问题，至少不是世界其他国家所遭受的问题。我们将要使用的开源库复制到共享源树中，记录要复制的版本，并仅在需要时更新副本。我们有一条规则，即在源代码树中只能有一个特定库的一个版本，任何人都想升级该库以确保其按其依赖的 Google 代码的预期运行，这是工作的职责。这些都不会经常发生。这是供应商的惰性方法。

相比之下，Google 之外的大多数项目都采用更急切的方法，使用自动化工具导入和更新代码，并确保它们始终使用最新版本。

由于 Google 在处理此供应商问题方面经验相对较少，因此我们将其留给 Google 以外的用户来开发解决方案。在过去的五年中，人们已经构建了一系列工具。今天使用的主要工具是 Keith Rarick 的 Godep，Owen Ou 的螺帽以及 Dave Cheney 的 gb 的 gb-vendor 插件，

当前的状况有两个问题。首先是这些工具与 go 命令的 “go get” 不兼容。第二个是工具之间甚至不兼容。这两个问题都通过工具分散了开发人员社区。

去年秋天，我们开始了一次公共设计讨论，以期就这些工具的全部操作方式建立一些共识，以便它们可以与 “go get” 并用。

我们的基本建议是，所有工具都同意在供应商期间重写导入路径的方法，以适应 “go get” 模型，并且所有工具都同意描述复制代码的源代码和版本的文件格式，因此即使单个项目也可以一起使用不同的供应商工具。如果今天使用另一个，明天应该仍然可以使用另一个。

以这种方式找到共同点非常符合 “少做多做” 的精神。如果我们能够就这些基本语义方面达成共识，那将使 “ go get” 和所有这些工具能够互操作，并且将能够在工具之间进行切换，就像关于如何将 Go 程序存储在文本文件中的协议一样，编译器和所有文本编辑器可以互操作。因此，我们提出了共同立场的建议。

发生了两件事。

首先，Daniel Theophanes 提出了一个新提案，在 GitHub 上启动了供应商规范项目，并接管了供应商元数据规范的协调和设计。

其次，社区基本上用一种声音说，在供应商期间重写导入路径是站不住脚的。如果无需更改即可复制代码，则供应商的工作会更加顺畅。

Keith Rarick 发表了另一项建议，建议对 go 命令进行最小的更改以支持供应商而无需重写导入路径。 Keith 的建议是无配置的，并且与 go 命令的其余方法完全吻合。该建议将在 Go 1.5 中作为实验功能发布，并可能在 Go 1.6 中默认启用。而且我相信，各种销售工具的作者都同意在最终确定 Daniel 的规格后采用它。

结果是，在下一个 Gophercon 上，我们应该在供应商工具和 go 命令之间具有广泛的互操作性，而实现这一目标的设计完全由原始 Go 团队之外的贡献者完成。

不仅如此，Go 团队关于如何执行此操作的建议实质上是完全错误的。 Go 社区非常清楚地告诉我们。我们采纳了这些建议，现在有一个供应商支持计划，我相信所涉及的每个人都会满意。

这也是我们一般设计方法的一个很好的例子。在我们对一个易于理解的解决方案达成广泛共识之前，我们尝试不对 Go 进行任何更改。对于供应商而言，Go 社区的反馈和设计对于达到这一点至关重要。

来自更广泛的 Go 社区的代码和设计的总体趋势对 Go 来说很重要。您 (更广泛的 Go 社区) 知道在使用 Go 的环境中什么是有效的，什么不是。我们不在 Google。越来越多，我们将依靠您的专业知识，并且我们将尽力帮助您开发可扩展 Go 的设计和代码，使其在更多设置中有用，并与 Go 的原始愿景很好地契合。同时，我们将继续等待就易于理解的解决方案达成广泛共识。

这将我带到最后一点。

行为守则#

我认为 Go 必须是开放的，Go 需要您的帮助。

但是实际上 Go 需要每个人的帮助。而且每个人都不在这里。

Go 需要尽可能多的人的想法。

为了实现这一目标，围棋社区需要尽可能地包容，热情，乐于助人和尊重。

现在，Go 社区已经足够大了，我和其他人认为不必明确地让每个参与的人都知道期望，而是明确写下这些期望是有道理的。就像 Go 规范为所有 Go 编译器设定了期望一样，我们可以为在线讨论和此类离线会议中的行为编写一个设定期望的规范。

像任何好的规范一样，它必须足够通用才能允许许多实现，但又要足够具体以便可以识别重要问题。当我们的行为不符合规范时，人们可以向我们指出，我们可以解决问题。同时，重要的是要了解这种规范不能像语言规范那样精确。我们必须从这样一个假设开始，即我们在应用它时都将是合理的。

这种规范通常称为行为准则。 Gophercon 有一个，我们都同意在这里跟随，但 Go 社区没有。我和其他人认为，围棋社区需要一个行为准则。

但是应该怎么说呢？

我认为，我们可以做出的最重要的总体声明是，如果您想使用或讨论 Go，那么在我们社区中，欢迎您的到来。这是我相信我们追求的标准。

如果没有其他原因 (很明显，还有其他极好的原因)，Go 需要尽可能多的社区。在某种程度上，行为限制了社区的规模，它支持 “回去”。行为可以轻易限制社区的规模。

整个技术社区，特别是围棋社区，都偏向那些坦率交流的人。我不认为这是根本。我不认为这是必要的。但是，在像电子邮件和 IRC 这样的在线讨论中，这样做特别容易，在这些讨论中，纯文本不会被我们面对面互动中的其他提示和信号所补充。

例如，我了解到，当我时间紧迫时，我倾向于写更少的单词，最终结果是我的电子邮件似乎不仅匆忙，而且变得直率，不耐烦甚至不屑一顾。那不是我的感觉，而是我的经历，这种印象足以使人们对使用 Go 或为 Go 做出贡献进行三思。当一些 Go 贡献者向我发送私人电子邮件通知我时，我意识到我正在这样做。现在，当我时间紧迫时，我会特别注意自己写的东西，而且我经常写得比平时要多，以确保我发送了我想要的信息。

我相信，纠正日常交互的某些部分 (有意或无意) 会驱逐潜在的用户和贡献者，这是我们所有人都可以做的最重要的事情之一，以确保 Go 社区继续发展。好的行为准则可以帮助我们做到这一点。

我们没有编写《行为准则》的经验，因此我们一直在阅读现有的准则，并且我们可能会采用现有的准则，也许会稍作调整。我最喜欢的是《 Django 行为准则》，该准则源自另一个名为 SpeakUp 的项目！它的结构是精心设计的日常互动提醒列表。

“要友好和耐心。要热情。要体贴。要尊重。要谨慎选择您要说的话。当我们不同意时，请尝试理解原因。”

我相信这捕捉了我们想要设置的基调，我们想要发送的消息，我们想要为新贡献者创建的环境。我当然想变得友善，耐心，热情，体贴和尊重。我不会一直都正确地做到这一点，如果我不敢做到这一点，我会欢迎提供有用的注释。我相信我们大多数人都有同样的感觉。

我没有提及基于种族，性别，残障或其他个人特征的种族歧视或对其造成不成比例的积极排斥，也没有提及骚扰。对我而言，这仅取决于我刚才所说的，无论在线上还是线下，排斥行为或明确的骚扰绝对是不可接受的。每个行为准则都明确说明了这一点，我希望我们也能做到。但我相信 SpeakUp！关于日常互动的提醒同样重要。我相信为这些日常互动设定高标准可以使极端行为更加清晰和易于处理。

我毫不怀疑，Go 社区可以成为技术行业中最友好，最热情，最体贴和最受尊重的社区之一。我们可以实现这一目标，这对我们所有人都是一种利益和信誉。

Andrew Gerrand 一直在努力为 Go 社区采用适当的行为准则。如果您有任何建议，疑虑或行为准则方面的经验，或者想参与其中，请在会议期间找到 Andrew 或我。如果您星期五仍然在这里，我和安德鲁将在 “黑客节” 期间抽出一些时间来讨论《行为准则》。

同样，我们不知道下一个好主意将来自何处。我们需要获得的所有帮助。我们需要一个庞大而多样化的围棋社区。

谢谢#

我认为许多人使用 “go get” 发布软件以供下载，通过博客文章分享他们的见解，或帮助邮件列表或 IRC 上的其他人成为 Go 社区这一广泛的开源工作的一部分。今天这里的每个人也是该社区的一部分。

预先感谢演示者，他们将在接下来的几天里花时间分享他们使用和扩展 Go 的经验。

在此先感谢所有在座的观众，感谢您抽出宝贵时间来这里，提出问题，并让我们知道 Go 如何为您服务。当您回家时，请继续分享您学到的知识。即使您不使用 Go 进行日常工作，我们也希望看到在其他情况下采用 Go 的方法，就像我们一直在寻找将其带回 Go 的好主意一样。

再次感谢大家为来到这里并成为 Go 社区的一员而付出的努力。

在接下来的几天里，请：告诉我们我们在做错什么，告诉我们在做错什么，并帮助我们所有人共同努力，使 Go 变得更好。

记住要友善，耐心，热情，体贴和尊重。

最重要的是，享受会议。

本译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

原文地址：https://learnku.com/docs/go-blog/open-so...

译文地址：https://learnku.com/docs/go-blog/open-so...