為什麼 JSON Schema 需要行為準則

如果 JSON Schema 專案在早期就制定了行為準則，我認為我們現在的進度會超前好幾年。這似乎不太可能，而且您可能覺得很少看到行為準則在實際運作，但是制定行為準則可以為貢獻者奠定一些基本的期望。您可能會爭論說您不需要行為準則，人們應該運用常識並且友善... 但事實並非如此明確。讓我解釋一下。

我的文化不是你的文化

《星艦迷航記》的粉絲無疑會很清楚「最高指導原則」。對於我們其他人來說，最高指導原則是一項最優先的普遍命令，即不干涉其他文化和文明。理論認為，無論意圖如何，人類更有可能產生災難性的影響，因為文化可能非常不同。

雖然開源專案的失敗不太可能在我們的現實中導致另一個文明的崩潰，但普遍原則仍然適用；您不能假設您了解他人的文化。在某種文化中正常或可接受的事情在另一種文化中可能不是。

這些概念如何從虛構轉化為現實？雖然有很多極端的例子，但有一個電視廣告總是讓我印象深刻，它很好地展示了文化差異如何導致不良結果。

該廣告描繪了一位英國男子與大約 10 位中國商人坐下來用餐。這位英國男子點了一條鰻魚，可能是因為他看起來很擔心而點錯了，但他還是把整條都吃完了。旁白說：「英國人認為如果你不把盤子裡的食物吃完，就是對主人的食物的一種侮辱，而中國人則認為如果你吃完，就是在質疑我的慷慨。」餐廳又端上另一條鰻魚，這次更大條了。

這個廣告是為匯豐銀行發布的一系列廣告之一，突出了「在地知識」的重要性。雖然這聽起來不錯，但它很好地展示了不同的文化規範和期望。

溝通主要是非語言的

當主要使用文字進行溝通時，避免文化衝突甚至更加困難。專家估計，我們溝通方式中只有 7% 是透過使用我們所使用文字的意義來傳達的。剩下的 93% 歸因於語氣和肢體語言。哇。

當您透過文字與您通常會親自溝通的人溝通時，通常不難彌補語氣的不足。但是，當您從未見過或看到您正在互動的人時，您沒有參考或基礎可以做出假設。有時發生的情況是，我們填補了那些缺失的部分來得出自己的結論，而這些結論可能與意圖不符。

那麼，GitHub 上的開源專案應該如何避免文化衝突和誤解呢？

表情符號可以幫助提高理解正確意圖的可能性，因為它們可以傳達語氣和情感含義。提高理解程度和意圖肯定有助於避免誤解，但這並不總是有助於解決文化差異。

我們的文化和口語

我們很容易忘記文化如何影響我們每天的互動。「牆倒時，夏卡。」您可能會認出這是《星艦迷航記》中的一句話。想像一下，您降落到一個星球上，您有一個通用翻譯器，但這些話語卻毫無意義。在這種虛構的情況下，外星語言只使用口語；具有超出所用文字含義的短語。

我們在一種語言中發現的口語對大多數其他語言來說都是無意義的。你們中的許多人會發現自己是各種網路文化的一部分，而這些文化也有自己的口語。由於圖像是一種我們可以在線上溝通的方式，我們建立了視覺口語，我們稱之為迷因。

我在此暗示的是，我們可以並且確實會創造自己的文化，這沒有問題。我們 JSON Schema 選擇採用 貢獻者公約 的原因有幾個，這確立了我們的文化基調。它定義了我們應該如何互動，以及我們互動時的期望。除了貢獻者公約之外，我們還繼續保留 IETF 行為準則 (BCP 54)，創建我們自己的行為準則。

為什麼需要行為準則？

我們已經探討過文化差異會使人們難以理解意圖。但是，即使意圖很明確，有時特定的行為也可能不受歡迎。

對於開源，人們來來去去。今天非常樂於助人的人明天可能很忙... 或將特定專案的優先順序延後數年。除了讓人們感到受歡迎和友善之外，從長遠來看，它在開發和維護專案方面也很有意義。如果人們繼續感到受歡迎和重視，他們更有可能留下來。

有些人參與是因為這是他們的工作，有些人是因為它很有趣且有回報。有些人很幸運能夠結合這兩個方面。但無論您的理由是什麼，我們都希望開源是一種積極的體驗。

雖然我經常建議人們避免做出假設，但當您的溝通有限時，您必須做出一些假設或要求澄清。但是，行為準則允許您使用期望來構建您的互動。「如果一則評論看起來很糟糕，但我假設他們的意圖是好的，我可以以不同的方式理解其可能的含義嗎？」

除了設定良好互動的期望之外，我們（與貢獻者公約一致）也定義了不可接受的行為，例如公開或私下騷擾。雖然很難想像一個可以接受這種行為的文化，但在許多文化中，有些文化規範和期望是完全不能接受的。

貢獻者公約以承諾的形式明確了期望，並提供了符合這些期望的示例，但它沒有提供任何具體的硬性工作規則（如何進行「業務」）。CBP 54 確實給出了一些明確的期望，例如我們應該如何工作：「我們透過理性的論證來反駁想法，而不是透過恐嚇或人身攻擊。」

我們認為我們在社群的全面檢視和評論下提出並達成一致的組合符合我們的期望，我們希望您也同意。如果情況發生變化或您的意見不同，我們將很樂意傾聽它們，並盡力理解。這是共識建立的一部分，其中一些在 CBP 54 中有規定。

我們選擇行為準則的部分原因是基於該文件的聲譽和現有使用情況。貢獻者公約已被許多專案和組織採用，並且經歷了多次修訂。它由許多在行為準則方面具有豐富經驗和知識的人開發和更新，這是我們團隊中沒有任何人可以說的。

如果我們什麼都不做呢？

如果不過於哲學地說，即使在完全溝通的情況下，人類似乎也經常發現衝突。幾乎不可避免的是，僅限文字的溝通會出現一些誤解，而這會導致衝突。

JSON Schema 作為一個專案之前停滯不前，因為核心團隊（就我所知）有 不同的期望。討論變得激烈。脾氣上來了。沒有預設的期望來構建潛在的誤解。沒有解決或補救衝突的框架。

目前，JSON Schema 工具和版本支援方面存在相當程度的碎片化。我們正在積極努力解決這個問題，但我的感覺是，這一切都源於規格開發的停滯。如果規格開發持續進行，並且這些專案和工具得到支援，我們或許就能處於更容易的境地。

我們已經失去了知識。我們正努力記錄知識和決策推理的過程，但有些事情我們就是不了解，而且很可能永遠不會了解。先前參與 JSON Schema 的團隊的關鍵成員似乎已經退出了任何公開的開源工作。這可能只是巧合，但根據一些公開的爭論，我懷疑並非如此。

當我們以期望來構建互動時，我們會給予對方善意的推定。隨著使用者群體的日益擴大，我們必須預期貢獻者可能不以英語為母語，這使得優雅的解讀變得越來越重要。

JSON Schema 的一個優勢是能夠使用任何符合規範的實作，並且在需要時以最小的努力替換另一個實作。其他人需要在其他程式語言中使用 schema 嗎？沒問題。這對於驗證來說很好，但對於產生型別或類別呢？對於 UI 生成和資料庫生成呢？對於產生文件呢？

在解決了許多問題和不一致之處、開發了許多新功能，並重新建立了 JSON Schema 的積極開發之後，該專案的合法性和信任度正在提高。我們現在正在與多個倡議互動並指導它們，以定義 JSON Schema 的標準化擴展。標準化是為了確保互通性。

隨著我們社群的成長，我們與社群互動的方式和期望也必須隨之成長。建立行為準則是旨在將 JSON Schema 從一個默默無聞的無名英雄提升為我們知道它可以成為的合法、成熟且廣泛使用的重要標準的幾個倡議之一。如果我們不想重蹈覆轍，就必須從歷史中學習。

我該如何參與？

我們最近更新了首頁，其中包含一些指向我們活躍社群和定期活動的連結，但無論如何，我們在這裡再回顧一下。

我們大部分的討論都在我們的 開放 Slack 伺服器上進行。我們的一般頻道用於所有討論，包括尋求幫助的討論。我們還有其他頻道用於規格開發和實作者、官方測試套件，甚至是監控 GitHub 和 StackOverflow 活動。它是我們的中心樞紐。但是，它是短暫的，而且我們無法存取較舊的訊息（免費帳戶的限制）。

現在，更長久且可搜尋的活動和討論地點是我們的 GitHub Discussions。目前，這些僅限於我們的社群儲存庫，但我們計劃稍後在其他儲存庫中開放這些功能。

目前，我們定期舉行兩組會議。

首先是我們的 JSON Schema 辦公時間；每週在同一時間舉行一小時，任何人都可以來這裡提問或討論任何與 JSON Schema 相關的事情。它流量較低，但它向我們的社群發出了一個重要的信號：「我們在這裡盡我們所能幫助您。」 每週二的 UTC 時間 15:00。

其次是我們的 開放社群工作會議。對於這些會議，我們在不同的時間之間輪替；每月的第一個星期五的 UTC 時間 20:00，以及每月的第三個星期五的 UTC 時間 14:00。這使得會議可以對更廣泛的受眾開放。這些會議有一個半正式的議程，作為一個行動號召，收集對關鍵決策的回饋和想法，並推進需要完成的工作。我們始終確保記錄最終的行動項目，並在下一次會議中跟進。

兩組會議都歡迎任何人加入。兩者都會錄音，但只有開放社群工作會議會公開分享。辦公時間會議不會分享，希望這能讓大家更自由地發言。

除了 Slack、GitHub Discussions 和定期會議之外，我們還會使用 Twitter。您可以找到我運行 @jsonschema 帳戶。任何提及「JSON Schema」的內容都會傳送到 Slack 上的一個頻道，以便我們看到大多數的討論，並在適當的時候提供幫助或指導方向。

希望這能幫助您了解為什麼 JSON Schema 特別需要行為準則。也許您正在考慮您的專案是否需要行為準則。如果您因此篇文章有任何問題、想法或意見，請隨時使用上述任何方法與我們聯繫。

圖片由 Maike und Björn Bröskamp 來自 Pixabay