JSON スキーマに行動規範が必要な理由

JSON スキーマプロジェクトが初期の段階で行動規範を持っていたなら、今の状態より数年は進歩していたと確信しています。それはありそうにないと思われるかもしれませんし、行動規範が実際に機能している場面をあまり見かけないかもしれません。しかし、行動規範を持つことは、貢献者からの基本的な期待を定める上で重要な役割を果たします。「行動規範は必要ない、常識と親切さで十分だ」と主張する人もいるでしょうが、それほど単純ではありません。説明させてください。

私の文化はあなたの文化ではありません

スタートレックのファンなら、「プライムディレクティブ」をよく知っているでしょう。そうでない人のために説明すると、プライムディレクティブとは、他の文化や文明に干渉しないという最優先の一般的な命令です。その理論では、文化は非常に異なる可能性があるため、意図に関わらず、人間は壊滅的な影響を与える可能性が高いとされています。

現実世界において、オープンソースプロジェクトの失敗が他の文明の崩壊を引き起こすことはまずありませんが、一般的な原則は依然として当てはまります。他者の文化を理解していると想定することはできません。ある文化では普通で許容されることが、別の文化ではそうでないことがあります。

これらの概念は、フィクションから現実世界にどのように翻訳されるのでしょうか？極端な例はたくさんありますが、あるテレビコマーシャルが、望ましくない結果を引き起こす文化的差異の良い例として、常に私の心に残っています。

そのコマーシャルでは、10人ほどの中国のビジネスマンと食事をしている英国人が描かれています。英国人はうなぎを注文しますが、おそらく間違って注文したのか心配そうな顔をしていますが、全部食べてしまいます。ナレーションは、「英国人は、皿をきれいに食べないことはホストの料理に対する侮辱だと考えますが、中国人は、食べきってしまうと、私の寛大さに疑問を呈していると感じます」と述べています。レストランは、今度はもっと大きなうなぎを出してきます。

このコマーシャルは、HSBCが発表した一連のコマーシャルの一つで、「ローカルノレッジ」の重要性を強調していました。これはキャッチーなフレーズではありますが、異なる文化規範と期待の良い例示となっています。

コミュニケーションは大部分が非言語的です

主にテキストを使ってコミュニケーションを行う場合、文化的衝突を避けることはさらに困難になります。専門家によると、コミュニケーションのわずか7％しか、使用する単語の意味によって伝えられていないと推定されています。残りの93％は、トーンとボディランゲージに起因します。驚くべき数字です。

普段から直接会話をしている相手とテキストでコミュニケーションを取るときは、トーンの欠如を補うことは通常難しくありません。しかし、一度も会ったことのない相手とやり取りする場合、仮定をするための基準や根拠がありません。そのため、私たちはしばしば、不足している部分を補って独自の結論を導き出しますが、それは意図と一致しない可能性があります。

では、GitHub 上のオープンソースプロジェクトは、どのように文化的衝突と誤解を避けるべきでしょうか？

絵文字は、トーンや感情的な意味合いを伝えることができるため、正しい意図を理解する可能性を高めるのに役立ちます。理解度と意図のレベルを高めることは、誤解を避けるのに間違いなく役立ちますが、これは必ずしも文化の違いに対処できるわけではありません。

私たちの文化と口語

文化が日常生活における私たちのやり取りにどれだけ影響を与えているかを忘れてしまいがちです。「壁が崩壊したとき、シャカ。」これはスタートレックの引用だと分かるかもしれません。あなたが惑星に着陸し、ユニバーサル翻訳機を持っていると想像してみてください。しかし、言葉の意味が全く分かりません。この架空の状況では、エイリアンの言語は口語表現のみを使用しており、使用されている単語を超えた意味を持つフレーズです。

私たちは、他のほとんどの人には無意味な口語表現を一つの言語で見つけます。皆さんの多くは、様々なインターネット文化の一部であり、それらにも独自の口語表現があります。画像がオンラインでコミュニケーションを取る方法であるため、私たちは視覚的な口語表現を作り出し、それはミームと呼ばれています。

ここで私が言いたいのは、私たち自身の文化を作り出し、それはそれで良いということです。JSON スキーマとして、私たちはいくつかの理由からコントリビューター・コベナントを採用することを選択し、これは私たちの文化的なトーンを設定します。それは、私たちがどのように交流し、交流する際の期待を定義します。コントリビューター・コベナントに加えて、私たちはIETF行動ガイドライン（BCP 54）を遵守し続け、独自の行動規範を作成しています。

行動規範が必要な理由

文化的差異によって意図を理解することが困難になる可能性があることを説明しました。しかし、意図が明確であっても、特定の行動が好ましくない場合があります。

オープンソースでは、人が出入りします。今日非常に役に立った人も、明日は忙しいかもしれません…あるいは何年も特定のプロジェクトを優先順位から外すかもしれません。人々に歓迎されていると感じさせるだけでなく、プロジェクトの長期的な開発と維持という点でも理にかなっています。歓迎され、価値があると感じ続ければ、人々はより長く残る可能性が高くなります。

仕事のために参加する人もいれば、楽しくてやりがいがあるから参加する人もいます。それら2つの側面を組み合わせることができるほど幸運な人もいます。しかし、あなたの理由が何であれ、私たちはオープンソースを肯定的な経験にしたいと考えています。

私はしばしば人々に仮定を避けることを提案しますが、コミュニケーションが制限されている場合、いくつかの仮定をするか、明確化を求める必要があります。しかし、行動規範は、期待とともにやり取りを構成することを可能にします。「コメントは悪いように読めるが、彼らの意図は良いと仮定した場合、異なる意味を理解できますか？」

良い交流の期待を設定することに加えて、私たち（コントリビューター・コベナントに同意して）公開または私的な嫌がらせなど、受け入れられないと定義された行動があります。それが許容される文化を想像するのは難しいですが、多くの文化では全く受け入れられない文化規範と期待があります。

コントリビューター・コベナントは、誓約書の形で期待を明確にし、それらの期待を満たす例を示していますが、作業方法（「ビジネス」を行う方法）に関する具体的な厳格なルールを示していません。BCP 54は、「私たちは、脅迫や個人的な攻撃ではなく、理にかなった議論によってアイデアを争います」など、私たちがどのように仕事をするべきかについて明確な期待を示しています。

コミュニティからの完全な視覚化とコメントにおいて提示され、合意された組み合わせは、私たちの期待に合致していると信じており、皆さんにも同意していただければ幸いです。それが変化したり、意見が異なったりした場合、喜んでそれを聞き、理解しようと努めます。これはコンセンサス構築の一部であり、その一部はBCP 54に示されています。

行動規範の選択は、部分的にその文書の評判と既存の使用方法に基づいています。コントリビューター・コベナントは多くのプロジェクトや組織によって採用されており、いくつかの改訂が行われています。それは、行動規範に関する豊富な経験と知識を持つ多くの人々によって開発および更新されており、これは私たちのチームの誰にも言えることではありません。

何もせずにいたら…どうなるか

あまり哲学的にならないようにしますが、人間は完全なコミュニケーションが可能であっても、しばしば対立を見つけるようです。テキストのみのコミュニケーションでは、誤解が生じることは避けられず、それが対立を引き起こします。

JSON スキーマというプロジェクトは、以前、コアチーム（私の知る限り）が異なる期待を持っていたために停滞しました。議論は激しくなり、感情が高まりました。潜在的な誤解を構成するデフォルトの期待はありませんでした。対立を解決または是正するための枠組みもありませんでした。

現在、JSON スキーマツールの断片化とバージョンサポートがかなりあります。私たちは積極的にこの問題の解決に努めていますが、これは仕様開発が停止したときにのみ発生したと感じています。それが継続し、それらのプロジェクトとツールがサポートされていれば、より簡単な状況になっていたかもしれません。

私たちは知識を失いました。私たちは知識と意思決定の理由を今後捉えようとしていますが、私たちが全く知らないことがあり、おそらく今後知ることもないでしょう。JSON スキーマに取り組んでいた以前のチームの主要なメンバーは、公開されたオープンソースの仕事から離れたようです。それは偶然の一致かもしれませんが、非常に公開された議論に基づくと、私はそうではないと思います。

やり取りに期待を設定すると、疑いの利益を与えます。ユーザーベースがますます広がるにつれて、貢献者が英語を母語としていない可能性があることを期待する必要があり、優雅な解釈がますます重要になります。

JSON スキーマの強みの1つは、準拠する実装を使用し、必要に応じて最小限の労力で別のものと交換できることです。他の人が別のプログラミング言語でスキーマを使用する必要がありますか？問題ありません。検証には最適ですが、タイプやクラスの生成はどうでしょうか？UI の生成やデータベースの生成はどうでしょうか？ドキュメントの生成はどうでしょうか？

多くの問題と矛盾を修正し、多くの新機能を開発し、JSON スキーマのアクティブな開発を再開したことで、プロジェクトの正当性と信頼性が向上しています。現在、私たちはいくつかのイニシアチブと連携して、JSON スキーマへの標準化された拡張機能を定義しています。相互運用性を確保するために標準化されています。

コミュニティが成長するにつれて、コミュニティとの関わり方や期待値も変化していく必要があります。行動規範の策定は、JSON Schemaを影の英雄から、誰もが知る確立された、広く利用される重要な標準へと高めるための数々の取り組みの一つです。過去の過ちを繰り返さないためには、歴史から学ぶ必要があります。

どのように参加できますか？

最近、ホームページを更新し、活発なコミュニティと定期的な活動へのリンクをいくつか追加しましたが、ここで改めてご紹介します。

私たちの議論の大部分は、オープンなSlackサーバーで行われています。一般的なチャンネルでは、ヘルプを求める方を含むすべての議論が行われます。仕様開発者や実装者、公式テストスイート、さらにはGitHubやStackOverflowの活動を監視するためのチャンネルもあります。これが私たちのハブです。しかし、これは一時的なものであり、古いメッセージへのアクセスを失う可能性があります（無料アカウントの制限）。

活動と議論のより永続的で検索可能な場所は、GitHub Discussionsです。現在、これらはコミュニティリポジトリに限定されていますが、後で他のリポジトリにも展開する予定です。

現在、2種類の定期的な会議を開催しています。

1つ目はJSON Schema オフィスアワーです。毎週同じ時間に1時間、誰でも参加して質問したり、JSON Schemaに関することなら何でも議論できる時間です。参加者は少ないですが、コミュニティに重要なメッセージを送っています。「私たちはできる限り皆さんを支援します」。毎週火曜日15:00 UTC。

2つ目はオープンコミュニティワーキングミーティングです。これは時間を交互に開催しています。月の第1金曜日は20:00 UTC、第3金曜日は14:00 UTCです。これにより、より幅広い聴衆が参加できるようになります。これらの会議はセミフォーマルな議題を持っており、重要な決定事項に関するフィードバックや意見を集め、必要な作業を進めるための行動喚起として機能します。常に結果として生じる行動項目を記録し、次のセッションでフォローアップします。

どちらの会議にも誰でも参加できます。どちらも録音されますが、公開されるのはオープンコミュニティワーキングミーティングのみです。オフィスアワーのセッションは公開されません。これにより、参加者はより自由に発言できることを期待しています。

Slack、GitHub Discussions、定期的な会議以外にも、Twitterも利用しています。@jsonschemaアカウントを運営しています。「JSON Schema」の言及はSlackのチャンネルにフィードされるため、ほとんどの議論を見ることができ、必要に応じてお手伝いしたり、方向性を示したりできます。

JSON Schemaが特に行動規範を必要とする理由についての説明が役立ったことを願っています。もしかしたら、あなたのプロジェクトにも行動規範が必要かどうか検討しているかもしれません。この記事を読んで、質問、意見、コメントなどがありましたら、上記のいずれかの方法でご連絡ください。

Maike und Björn Bröskamp氏によるPixabayからの画像