Go 官方部落格

Go，開源，社群

Russ Cox
2015年7月8日

歡迎

[這是我在 Gophercon 2015 大會上的開幕主旨演講內容。 影片請見此處。]

感謝大家前來丹佛參加本次大會，也感謝所有觀看影片的朋友。如果這是您第一次參加 Gophercon 大會，歡迎您。如果您去年來過，歡迎回來。感謝組織者為舉辦這樣的大會所付出的辛勤工作。我很高興來到這裡，並有機會與大家交流。

我是 Google Go 專案和 Go 團隊的技術負責人。我和 Rob Pike 共同擔任此職。在此職位上，我花費大量時間思考整個 Go 開源專案，特別是它的執行方式、開源的意義，以及 Google 內部和外部貢獻者之間的互動。今天我想與大家分享我對 Go 專案整體的看法，並在此基礎上解釋我如何看待 Go 開源專案的發展演變。

為什麼選擇 Go？

首先，我們必須追溯到起點。我們為什麼開始研發 Go？

Go 是旨在提高程式設計師生產力的嘗試。我們想改進 Google 的軟體開發流程，但 Google 面臨的問題並非 Google 所獨有。

有兩個首要目標。

第一個目標是打造一種更好的語言來應對可伸縮併發的挑戰。我所說的可伸縮併發是指能同時處理多項事務的軟體，例如透過來回傳送網路流量來協調一千臺後端伺服器。

如今，這類軟體有了一個更簡潔的名稱：我們稱之為雲軟體。可以公平地說，Go 是在雲尚未執行軟體之前為雲設計的。

更大的目標是建立一個更好的環境，以應對可伸縮軟體開發的挑戰，即許多人共同開發和使用、彼此協調有限、並維護多年的軟體。在 Google，我們有數千名工程師互相編寫和分享程式碼，努力完成自己的工作，儘可能地重用他人的成果，並在一個擁有十多年曆史的程式碼庫中工作。工程師們經常處理或至少檢視他人最初編寫的程式碼，或者他們自己多年前編寫的程式碼，這通常沒什麼區別。

Google 內部的這種情況與在 GitHub 等網站上進行的大規模、現代開源開發有很多共同之處。正因為如此，Go 非常適合開源專案，有助於它們在長期內接受和管理來自大型社群的貢獻。

我認為 Go 的大部分成功在於它非常適合雲軟體，非常適合開源專案，並且巧合的是，這兩者在軟體行業中越來越受歡迎和重要。

其他人也發表了類似的觀察。這裡有兩個例子。去年，在 RedMonk.com 上，Donnie Berkholz 寫了一篇關於“作為雲基礎設施的新興語言的 Go”的文章，指出“[Go 的]主要專案……要麼是以云為中心，要麼是為處理分散式系統或臨時環境而構建的。”

今年，在 Texlution.com 上，作者寫了一篇題為“Go 註定會成功的原因”的文章，指出這種對大規模開發的關注可能比 Google 本身更適合開源：“這種對開源的適應性就是我認為您將看到越來越多 Go 的原因……”

Go 的平衡之道

Go 如何實現這些目標？

它如何使可伸縮併發和可伸縮軟體開發變得更容易？

大多數人回答這個問題時會提到通道和 goroutine、介面、快速構建、go 命令以及良好的工具支援。這些都是答案的重要組成部分，但我認為它們背後有一個更廣闊的理念。

我認為這個理念就是 Go 的平衡。任何軟體設計中都存在相互衝突的考慮，而且人們很自然地傾向於嘗試解決所有預見到的問題。在 Go 中，我們明確地嘗試不解決一切問題。相反，我們試圖只做足夠的事情，以便您可以輕鬆構建自己的定製解決方案。

我想總結 Go 選擇的平衡之道，那就是：少做，多賦能。

少做，但多賦能。

Go 不能做所有事情。我們也不應該嘗試這樣做。但如果我們努力，Go 或許可以在少數事情上做得很好。如果我們仔細選擇這些事情，我們就可以奠定一個基礎，在這個基礎上，開發者可以輕鬆地構建他們所需的解決方案和工具，並且理想情況下，這些解決方案和工具可以與其他開發者構建的解決方案和工具協同工作。

示例

讓我用一些示例來闡明這一點。

首先，是 Go 語言本身的規模。我們努力引入儘可能少的概念，以避免在大型開發者社群的不同部分形成相互無法理解的方言問題。只有當一個想法被簡化到其本質，並且其清晰的好處能夠證明所增加的複雜度是合理的，它才會被納入 Go。

一般來說，如果我們希望 Go 在 100 件事上做得好，我們不能進行 100 次獨立的改動。相反，我們嘗試研究和理解設計空間，然後找出一些協同良好並能實現其中大約 90 件事情的改動。我們願意犧牲剩下的 10 件，以避免語言變得臃腫，避免僅僅為了解決今天看起來很重要但明天可能就消失了的特定用例而增加複雜度。

保持語言的精簡能夠實現更重要的目標。精簡使得 Go 更易學、更易理解、更易實現、更易重實現、更易除錯、更易調整、更易演進。少做，多賦能。

我應該指出，這意味著我們拒絕了很多其他人的想法，但我向您保證，我們拒絕我們自己的想法甚至更多。

接下來是通道和 goroutine。我們應該如何構建和協調併發與平行計算？互斥鎖和條件變數非常通用，但級別太低，難以正確使用。OpenMP 等並行執行框架級別太高，只能用於解決狹窄範圍的問題。通道和 goroutine 介於這兩個極端之間。就其本身而言，它們並不能解決很多問題。但它們足夠強大，可以輕鬆組織起來，從而解決併發軟體中的許多常見問題。少做——真正做到恰到好處——就能賦能更多。

接下來是型別和介面。擁有靜態型別可以實現有用的編譯時檢查，這是 Python 或 Ruby 等動態型別語言所缺乏的。與此同時，Go 的靜態型別避免了傳統靜態型別語言中的許多重複，使其感覺更輕量級，更像動態型別語言。這是人們最早注意到的事情之一，許多 Go 的早期採用者都來自動態型別語言。

Go 的介面是其中的關鍵部分。特別是，省略 Java 或其他具有靜態層次結構語言中的“implements”宣告，使介面更輕量且更靈活。沒有這種僵化的層次結構，可以實現諸如描述現有、不相關的生產實現的測試介面等習語。少做，多賦能。

接下來是測試和基準測試。在大多數語言中，測試和基準測試框架是否缺乏？它們之間是否存在一致性？

Go 的 testing 包並非旨在涵蓋這些主題的方方面面。相反，它旨在提供大多數更高階工具所需的基本概念。包有透過、失敗或跳過的測試用例。包有執行並可以透過各種指標衡量的基準測試。

在這裡做得更少是嘗試將這些概念提煉到本質，以建立共享詞彙，從而使更豐富的工具能夠互操作。這種一致性使得更高階的測試軟體成為可能，例如 Miki Tebeka 的 go2xunit 轉換器，或 benchcmp 和 benchstat 基準分析工具。

因為基本概念的表示形式確實存在一致性，這些更高階的工具適用於所有 Go 包，而不僅僅是那些努力選擇加入的包，而且它們彼此互操作，例如使用 go2xunit 不會妨礙同時使用 benchstat，這與這些工具作為相互競爭的測試框架外掛時的情況不同。少做，多賦能。

接下來是重構和程式分析。由於 Go 是用於大型程式碼庫的，我們知道它需要支援原始碼的自動維護和更新。我們也知道這個主題太大了，無法直接內建。但我們知道有一件事我們必須做。根據我們在其他環境下嘗試自動化程式修改的經驗，遇到的最主要的障礙實際上是以開發者可以接受的格式寫出修改後的程式。

在其他語言中，不同團隊使用不同的格式化約定很常見。如果程式進行編輯時使用了錯誤的約定，它要麼寫入原始檔的一部分，使其看起來與檔案的其餘部分格格不入，要麼重新格式化整個檔案，導致不必要和不受歡迎的差異。

Go 沒有這個問題。我們設計了語言以使 gofmt 成為可能，我們努力使 gofmt 的格式化對所有 Go 程式都可接受，並且我們確保從最初公開發布的第一天起 gofmt 就已存在。Gofmt 強制執行這種一致性，使得自動化修改可以融入檔案的其餘部分。你無法分辨某個特定的修改是人做的還是計算機做的。我們沒有內建明確的重構支援。建立一個一致的格式化演算法足以成為獨立工具開發和互操作的共享基礎。Gofmt 使得 gofix, goimports, eg 等工具成為可能。我相信這方面的工作才剛剛開始。還可以做得更多。

最後，構建和分享軟體。在 Go 1 釋出之前，我們構建了 goinstall，它演變成了我們今天熟知的“go get”。這個工具定義了一種標準的、零配置的方式來解析 github.com 等網站上的匯入路徑，後來又透過發出 HTTP 請求的方式來解析其他網站上的路徑。這種一致的解析演算法使得其他使用這些路徑的工具成為可能，最顯著的就是 Gary Burd 建立的 godoc.org。如果您還沒有使用過它，對於任何有效的“go get”匯入路徑，您可以訪問 godoc.org/the-import-path，該網站將抓取程式碼並顯示其文件。一個不錯的副作用是 godoc.org 成為了一個公開可用的 Go 包的粗略主列表。我們所做的只是賦予了匯入路徑一個清晰的含義。少做，多賦能。

您會注意到，許多這些工具示例都與建立共享約定有關。有時人們稱 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 需要你們。沒有你們所有人，沒有全世界使用 Go 開發各種不同專案的人們，Go 就無法成功。

反過來，Google 的 Go 團隊也永遠不夠大，無法支援整個 Go 社群。為了持續擴充套件，我們需要在少做的同時賦能所有這些“更多”。開源是其中的重要組成部分。

Go 的開源特性

開源意味著什麼？最低要求是開放原始碼，使其在開源許可證下可用，我們已經做到了這一點。

但我們也開放了我們的開發流程：自從釋出 Go 以來，我們所有的開發工作都在公共場合進行，在對所有人開放的公共郵件列表中進行。我們接受和評審來自任何人的原始碼貢獻。無論您是否為 Google 工作，流程都是一樣的。我們在公共場合維護我們的 bug 追蹤器，在公共場合討論和制定變更提案，並向著公共釋出版本努力。公共原始碼樹是權威副本。變更首先發生在那裡。它們只在稍後才被引入 Google 的內部原始碼樹。對於 Go 而言，開源意味著這是一項超越 Google 的集體努力，向所有人開放。

任何開源專案都始於少數人，通常只有一人，但 Go 專案始於三人：Robert Griesemer、Rob Pike 和 Ken Thompson。他們對 Go 的未來以及 Go 如何超越現有語言有著明確的願景，Robert 明天早上會更詳細地談論這一點。我是下一個加入團隊的人，然後是 Ian Taylor，接著，我們一個接一個地發展到今天，擁有數百名貢獻者。

感謝迄今為止為 Go 專案貢獻程式碼、想法或錯誤報告的許多人。今天在大會手冊的版面裡，我們盡力列出了所有能列出的人。如果您的名字沒有在其中，我深感抱歉，但仍然感謝您。

我相信迄今為止的數百名貢獻者正在朝著 Go 可能實現的共同願景努力。很難用言語來表達這些事情，但我盡力在前面解釋了願景的一部分：少做，多賦能。

Google 的角色

一個自然的問題是：與 Go 社群的其他貢獻者相比，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 的願景。

當然，並非全是協調和願景。Google 仍然為 Go 的開發工作提供資金。Rick Hudson 今天晚些時候會談論他關於減少垃圾收集器延遲的工作，Hana Kim 明天會談論她關於將 Go 移植到移動裝置上的工作。但我想明確指出，我們儘可能地將 Google 資助的開發視為與由其他公司資助或個人利用業餘時間貢獻的開發同等重要。我們這樣做是因為我們不知道下一個偉大的想法會來自哪裡。所有為 Go 做貢獻的人都應該有機會被聽到。

示例

我想分享一些證據來證明我的這一說法，即隨著時間的推移，Google 的原始 Go 團隊越來越注重協調而非直接開發。

首先，Go 開發的資金來源正在擴大。在開源釋出之前，顯然所有的 Go 開發都由 Google 資助。開源釋出之後，許多個人開始貢獻他們的時間，並且我們正在緩慢但穩步地增加由其他公司支援的貢獻者數量，這些貢獻者至少是兼職參與 Go 的工作，特別是那些與使 Go 對這些公司更有用相關的方面。今天，這份名單包括 Canonical、Dropbox、Intel、Oracle 等公司。當然，Gophercon 和其他地區性的 Go 大會完全由 Google 以外的人組織，並且它們除了 Google 之外還有許多企業贊助商。

其次，由原始團隊外部進行的 Go 開發的概念深度正在擴大。

開源釋出後不久，首批重要的貢獻之一是將 Go 移植到 Microsoft Windows，這項工作由 Hector Chu 發起，並由 Alex Brainman 和其他人完成。更多的貢獻者將 Go 移植到其他作業系統。甚至還有更多貢獻者重寫了我們的大部分數字程式碼，使其更快或更精確，或兩者兼而有之。這些都是重要的貢獻，我們非常感激，但它們大多不涉及新的設計。

最近，由 Aram Hăvărneanu 領導的一群貢獻者將 Go 移植到了 ARM 64 架構，這是 Google 之外的貢獻者完成的第一次架構移植。這意義重大，因為一般來說，對新架構的支援比對新作業系統的支援需要更多的設計工作。不同架構之間的差異比不同作業系統之間的差異更大。

另一個例子是過去幾個版本中引入的初步支援使用共享庫構建 Go 程式。這項功能對許多 Linux 發行版很重要，但對 Google 不那麼重要，因為我們部署的是靜態二進位制檔案。我們一直在協助指導總體策略，但大部分設計和幾乎所有的實現都是由 Google 之外的貢獻者完成的，特別是 Michael Hudson-Doyle。

我的最後一個例子是 go 命令處理 vendoring（依賴vendoring）的方式。我將 vendoring 定義為將外部依賴項的原始碼複製到您的程式碼樹中，以確保它們不會消失或在您不知情的情況下更改。

Vendoring 並不是 Google 面臨的問題，至少不像世界其他地方那樣面臨。我們將我們想要使用的開源庫複製到共享原始碼樹中，記錄複製的版本，並且只有在需要時才更新副本。我們有一條規則，即原始碼樹中只能存在特定庫的一個版本，任何想要升級該庫的人的任務是確保它繼續按依賴它的 Google 程式碼的預期執行。這些事情並不經常發生。這是一種懶惰的 vendoring 方法。

相比之下，Google 之外的大多數專案採用更積極的方法，使用自動化工具匯入和更新程式碼，並確保他們始終使用最新版本。

由於 Google 在這個 vendoring 問題上經驗相對較少，我們將其留給了 Google 外部的使用者來開發解決方案。在過去的五年裡，人們開發了一系列工具。目前主要使用的工具有 Keith Rarick 的 godep、Owen Ou 的 nut 以及 Dave Cheney 的 gb 的 gb-vendor 外掛。

當前的情況存在兩個問題。首先是這些工具與 go 命令的“go get”不相容。其次是這些工具彼此之間也不相容。這兩個問題都導致開發者社群因工具而分裂。

去年秋天，我們發起了一場公開的設計討論，試圖就這些工具如何協同工作的一些基本原則達成共識，以便它們能夠與“go get”以及彼此協同工作。

我們的基本提議是所有工具都同意在 vendoring 過程中重寫匯入路徑，以適應“go get”的模型；並且所有工具都同意一種檔案格式來描述複製程式碼的來源和版本，這樣即使是同一個專案也可以同時使用不同的 vendoring 工具。如果您今天使用一種工具，明天仍然應該能夠使用另一種工具。

以這種方式尋找共同點，非常符合“少做，多賦能”的精神。如果我們能就這些基本語義方面建立共識，那將使得“go get”和所有這些工具能夠互操作，並且能夠實現工具之間的切換，就像關於 Go 程式如何儲存在文字檔案中的共識使得 Go 編譯器和所有文字編輯器能夠互操作一樣。因此，我們發出了關於共同點的提議。

發生了兩件事。

首先，Daniel Theophanes 在 GitHub 上發起了一個名為 vendor-spec 的專案，提出了一個新的方案，並接管了 vendoring 元資料規範的協調和設計工作。

其次，社群基本上一致發聲，表示在 vendoring 過程中重寫匯入路徑是不可行的。如果程式碼可以在不更改的情況下被複制，vendoring 的工作會順暢得多。

Keith Rarick 提出了一個替代方案，建議對 go 命令進行最小改動以支援 vendoring 而不重寫匯入路徑。Keith 的提議無需配置，並且與 go 命令的其餘方法很好地契合。該提案將作為實驗性功能在 Go 1.5 中釋出，並可能在 Go 1.6 中預設啟用。我相信各種 vendoring 工具的作者已同意在 Daniel 的規範最終確定後予以採納。

結果是，在下一屆 Gophercon 上，我們應該能看到 vendoring 工具和 go 命令之間廣泛的互操作性，而實現這一目標的方案完全是由原始 Go 團隊之外的貢獻者完成的。

不僅如此，Go 團隊關於如何做這件事的提議基本上是完全錯誤的。Go 社群非常明確地告訴了我們這一點。我們採納了他們的建議，現在有了一個 vendoring 支援方案，我相信所有參與其中的人都很滿意。

這也是我們總體設計方法的一個很好的例子。在我們認為對一個充分理解的解決方案尚未達成廣泛共識之前，我們不會對 Go 進行任何更改。對於 vendoring，來自 Go 社群的反饋和設計對於達到這一點至關重要。

程式碼和設計越來越傾向於由更廣泛的 Go 社群貢獻，這一趨勢對 Go 至關重要。你們，更廣泛的 Go 社群，知道在使用 Go 的環境中哪些有效，哪些無效。我們 Google 不知道。我們會越來越依賴你們的專業知識，並努力幫助你們開發設計和程式碼，將 Go 擴充套件到更多場景下都能有用，並與 Go 的最初願景很好地契合。與此同時，我們將繼續等待對充分理解的解決方案達成廣泛共識。

這把我帶到了最後一點。

行為準則

我一直認為 Go 必須是開放的，並且 Go 需要你們的幫助。

但實際上 Go 需要每個人的幫助。並非每個人都在這裡。

Go 需要儘可能多的人提供想法。

為了實現這一點，Go 社群需要儘可能包容、友好、樂於助人且彼此尊重。

Go 社群現在已經足夠大了，與其假設每個參與者都知道預期行為，不如像我及其他人認為的那樣，明確地寫下這些預期。就像 Go 規範為所有 Go 編譯器設定了預期一樣，我們可以寫一份規範，為我們在線上討論和像這次這樣的線下會議中的行為設定預期。

像任何好的規範一樣，它必須足夠通用以允許多種實現，但又足夠具體以識別重要問題。當我們的行為不符合規範時，人們可以向我們指出，然後我們可以修正問題。同時，重要的是要理解，這種規範不可能像語言規範那樣精確。我們必須首先假定我們在應用它時都會是理性的。

這類規範通常被稱為《行為準則》。Gophercon 有一套，我們在這裡就意味著我們都同意遵守它，但 Go 社群還沒有。我及其他人認為 Go 社群需要一套《行為準則》。

但它應該說什麼呢？

我相信我們能做出的最重要的一項總體宣告是：如果您想使用或討論 Go，那麼您在本社群是受歡迎的。這是我相信我們所追求的標準。

即使沒有其他原因（需要明確的是，還有許多其他極好的原因），Go 也需要儘可能大的社群。如果行為限制了社群的規模，就會阻礙 Go 的發展。而行為很容易限制社群的規模。

技術社群，尤其是 Go 社群，傾向於那些直言不諱的人。我不認為這是本質的。我不認為這是必要的。但在像電子郵件和 IRC 這樣的線上討論中尤其容易這樣，因為純文字交流缺乏面對面交流中的其他提示和訊號。

例如，我瞭解到當我時間很緊時，我傾向於少寫字，結果就是我的電子郵件看起來不僅匆忙，而且直率、不耐煩，甚至帶有輕視的意味。這並非我的本意，但這可能是我給人的印象，而這種印象足以讓人們在使用 Go 或為其貢獻時猶豫不決。當一些 Go 貢獻者給我發私信告訴我這一點時，我意識到了自己的問題。現在，當我時間很緊時，我會特別注意自己寫的內容，而且通常會寫得比平時多，以確保我傳達的是我想要表達的資訊。

我認為，糾正我們日常互動中那些（無論有意無意）會趕走潛在使用者和貢獻者的部分，是我們所有人為了確保 Go 社群持續增長而能做的最重要的事情之一。一套好的行為準則可以幫助我們做到這一點。

我們沒有編寫行為準則的經驗，所以一直在閱讀現有的準則，並且很可能會採納一套現有的，可能只做少量修改。我最喜歡的是 Django 的行為準則，它源自另一個名為 SpeakUp! 的專案。它的結構是對一系列日常互動提醒的詳細闡述。

“友善而耐心。歡迎他人。體諒他人。尊重他人。謹慎選擇你的言語。當我們有分歧時，試著理解原因。”

我相信這抓住了我們想要設定的基調，我們想要傳達的資訊，以及我們想要為新貢獻者創造的環境。我當然希望能做到友善、耐心、歡迎、體諒和尊重。我不會每次都做得完美，如果我沒有做到，我也很樂意收到善意的提醒。我相信我們大多數人都有同感。

我還沒有提到基於種族、性別、殘疾或其他個人特徵的主動排斥或造成歧視性影響的行為，也沒有提到騷擾。對我來說，從我剛才所說的可以看出，排斥行為或公開騷擾無論在線上還是線下都是絕對不可接受的。每一份行為準則都明確指出了這一點，我期望我們的準則也會如此。但我相信 SpeakUp! 關於日常互動提醒同樣重要。我相信，為日常互動設定高標準，能讓極端行為更加清晰，也更容易處理。

我毫不懷疑 Go 社群可以成為技術行業中最友善、最受歡迎、最體諒他人、最受尊重的社群之一。我們可以做到這一點，這將對我們所有人都有益處和榮譽。

Andrew Gerrand 一直在牽頭為 Go 社群制定合適的行為準則。如果您有建議、擔憂，或者有行為準則方面的經驗，或者想參與其中，請在會議期間找 Andrew 或我。如果您週五還在，Andrew 和我打算在 Hack Day 期間留出一些時間討論行為準則。

重申一下，我們不知道下一個偉大的想法會從哪裡來。我們需要一切能獲得的幫助。我們需要一個龐大、多元化的 Go 社群。

謝謝

我認為許多人透過“go get”釋出可供下載的軟體、透過部落格文章分享他們的見解，或是在郵件列表或 IRC 上幫助他人，都是這一廣泛開源工作的一部分，都是 Go 社群的一部分。今天在座的每個人也是這個社群的一部分。

提前感謝接下來幾天將花時間分享他們使用和擴充套件 Go 經驗的演講者們。

提前感謝所有在場的聽眾，感謝你們花時間來這裡、提問題，並告訴我們 Go 對你們來說效果如何。回家後，請繼續分享你們學到的東西。即使你們日常工作不使用 Go，我們也樂於看到 Go 中行之有效的方法被其他領域採納，就像我們一直在尋找好想法帶回 Go 中一樣。

再次感謝大家努力來到這裡併成為 Go 社群的一份子。

在接下來的幾天裡，請：告訴我們哪裡做得對，告訴我們哪裡做得不對，並幫助我們一起努力讓 Go 變得更好。

記住要友善、耐心、歡迎他人、體諒他人、尊重他人。

最重要的是，享受這次會議。