为什么 JSON Schema 需要行为准则

如果 JSON Schema 项目在早期就制定了行为准则，我相信我们会比现在提前几年。这似乎不太可能，你可能觉得很少看到行为准则在行动，但制定行为准则为贡献者设定了一些基础期望。你可能会说你不应该“需要”行为准则，人们应该使用常识并友善……但这并不那么简单。让我解释一下。

我的文化不是你的文化

《星际迷航》的粉丝们无疑对“主要指令”很熟悉。对于我们其他人来说，主要指令是一项首要的总命令，即不干预其他文化和文明。理论认为，无论意图如何，人类更有可能产生灾难性的影响，因为文化可能非常不同。

虽然在一个开源项目失败不太可能导致现实生活中另一个文明崩溃，但这一普遍原则仍然适用；你不能假定自己了解他人的文化。在一个文化中正常或可以接受的行为，在另一个文化中可能就不是这样。

这些概念如何从虚构转化为现实？虽然有很多极端的例子，但我一直记得一个电视广告，它很好地展示了文化差异导致的负面结果。

广告中描绘了一位英国男子与十多位中国商人一起用餐。这位英国男子点了鳝鱼，可能是由于错误，因为他看起来很担心，但他把整条鳝鱼都吃掉了。画外音说：“英国人认为，如果你没有把盘子里的食物清空，就是在羞辱你的主人，而中国人则认为，如果你清空了盘子，就是在质疑我的慷慨。”餐厅又端出了一条鳝鱼，这次更大。

这条广告是汇丰银行发布的一系列广告之一，突出了“本地知识”的重要性。虽然这是一个很好的宣传语，但它很好地展示了不同的文化规范和期望。

沟通主要是非语言的

当主要使用文本进行沟通时，避免文化冲突更加困难。专家估计，我们沟通方式中只有 7% 是通过我们使用的词语的含义来表达的。剩下的 93% 属性归因于语气和肢体语言。哇。

当您通过文本与通常面对面交流的人进行交流时，通常不难弥补语气不足。但是，当您从未见过或认识您正在与之互动的人时，您就没有参考或依据来进行假设。有时会发生这种情况，我们填补这些缺失的部分，得出自己的结论，而这些结论可能与意图不符。

那么，GitHub 上的开源项目应该如何避免文化冲突和误解呢？

表情符号可以帮助提高理解正确意图的可能性，因为它们可以传达语气和情感上的含义。提高理解程度和意图无疑有助于避免误解，但这并不总是能帮助解决文化差异。

我们的文化和口语

我们很容易忘记文化在多大程度上影响着我们每天的互动。“夏卡，当墙倒塌时。”你可能会认出这是《星际迷航》中的台词。想象一下，你降落在一个星球上，你有一个通用翻译器，但这些词就是没有意义。在这种虚构的情况下，外星语言只使用口语；这些短语的含义超出了所用词语的范围。

我们在一种语言中发现了对于大多数其他语言来说毫无意义的口语。你们中的许多人会发现自己身处各种互联网文化中，而这些文化也会有自己的口语。由于图像成为我们在线交流的一种方式，我们创造了视觉口语，我们称之为“梗”。

我的意思是我们能够，也确实创造了我们自己的文化，这没问题。我们作为 JSON Schema 选择采用贡献者公约，出于几个原因，这为我们设定了文化基调。它定义了我们应该如何互动，以及我们在互动时应该有什么样的期望。除了贡献者公约，我们还继续遵守 IETF 行为准则 (BCP 54)，制定我们自己的行为准则。

为什么要有行为准则？

我们已经探讨了文化差异会使理解意图变得困难。但是，即使意图明确，有时特定的行为也可能不受欢迎。

对于开源项目来说，人们会来来往往。今天超级乐于助人的人，明天可能很忙……或者多年来不再优先考虑某个特定项目。除了让人们感到受欢迎，友善之外，从长远来看，这对于项目开发和维护来说也是有意义的。如果人们继续感到受欢迎和被重视，他们更有可能留下来。

有些人参与是因为这是他们的工作，有些人是因为它很有趣且有益。有些人幸运地能够将这两个方面结合起来。但无论你的理由是什么，我们都希望开源是一个积极的体验。

虽然我经常建议人们避免进行假设，但在你的沟通有限的情况下，你必须进行一些假设或要求澄清。但是，行为准则允许你用期望来构建你的互动。“如果评论看起来很糟糕，但我假设他们的意图是好的，我能以不同的方式理解其可能的含义吗？”

除了设定良好的互动期望之外，我们还有一些我们（同意贡献者公约）定义为不可接受的行为，例如公开或私人骚扰。虽然很难想象一个文化会接受这种行为，但有些文化规范和期望在许多文化中是完全不可接受的。

贡献者公约以承诺的形式明确了期望，并提供了一些满足这些期望的例子，但它没有给出任何关于工作方式（如何“开展业务”）的具体硬性规则。CBP 54 确实给出了一些明确的期望，例如我们应该如何工作：“我们通过使用推理论证来争论观点，而不是通过恐吓或人身攻击。”

我们认为，我们在社区的充分视野和评论下呈现并同意的组合符合我们的期望，我们希望您也同意。如果情况发生变化或您的意见不同，我们很乐意倾听并尝试理解。这是共识建立过程的一部分，其中一部分是在 CBP 54 中列出的。

我们选择行为准则的部分原因是基于该文件的声誉和现有的使用情况。贡献者公约已被许多项目和组织采用，并经过多次修订。它是由许多拥有丰富行为准则经验和知识的人员开发和更新的，而我们团队中没有人能做到这一点。

如果我们什么都不做… 会怎么样？

不谈论哲学，人类似乎经常会发生冲突，即使在完全沟通的情况下也是如此。当只有文本进行沟通时，几乎不可避免地会出现一些误解，这会引发冲突。

JSON Schema 作为一个项目，此前停滞不前，因为核心团队（据我所知）存在不同的期望。讨论变得激烈。人们情绪激动。没有默认的设定期望来构建潜在的误解。也没有解决或弥合冲突的框架。

现在，JSON Schema 工具和版本支持存在相当程度的分裂。我们正在积极努力帮助解决这个问题，但我的感觉是，这只是因为规范开发停止了。如果它继续进行，并且那些项目和工具得到了支持，我们可能就会发现自己处在一个更容易的境地。

我们失去了知识。我们正在努力记录知识和决策理由，以便在未来继续发展，但有些事情我们根本不知道，而且很可能现在永远无法知道。之前在 JSON Schema 上工作的核心团队成员似乎已经从任何公开的开源工作中退出了。这可能是一个巧合，但基于非常公开的争论，我怀疑并非如此。

当我们用期望来构建我们的互动时，我们就会给与怀疑的利益。随着用户群不断扩大，我们必须期望贡献者可能不是以英语为母语，这使得优雅的解释变得越来越重要。

JSON Schema 的一个优势是能够使用任何符合标准的实现，并在需要时用另一种实现替换它，而无需付出太多努力。其他人需要用其他编程语言使用模式吗？没问题。这对于验证来说很棒，但生成类型或类呢？生成 UI 和数据库呢？生成文档呢？

解决了许多问题和不一致之处，开发了许多新功能，并重新建立了 JSON Schema 的积极开发，项目的合法性和信任度正在不断提高。我们现在正在与几个旨在定义 JSON Schema 标准化扩展的倡议进行互动和指导。标准化是为了确保互操作性。

随着社区的不断发展，我们与社区互动的方式和期望也必须随之改变。制定行为准则只是众多举措中的一项，旨在将 JSON Schema 从默默无闻的幕后英雄提升为我们所知晓的合法、成熟且得到广泛应用的关键标准。我们必须从历史中汲取教训，避免重蹈覆辙。

如何参与其中？

我们最近更新了主页，其中包含一些指向活跃社区和定期活动的链接，但我们还是在这里回顾一下。

我们大部分讨论都在 公开的 Slack 服务器 上进行。我们的通用频道用于所有讨论，包括寻求帮助的人。我们还有其他频道用于规范开发和实施者、官方测试套件，甚至用于监控 GitHub 和 StackOverflow 活动。它是我们的中心枢纽。但是，它具有短暂性，我们会失去对旧消息的访问权限（免费帐户的限制）。

活动和讨论的更持久、可搜索的位置现在是我们的 GitHub 讨论。目前，这些讨论仅限于我们的社区存储库，但我们计划稍后将这些讨论扩展到其他存储库。

目前，我们定期举办两套电话会议。

首先是我们的 JSON Schema 办公时间；每周同一时间举行一小时，任何人都可以来这里提问或讨论任何与 JSON Schema 相关的内容。参与人数不多，但这向我们的社区发出了一个重要的信号：“我们尽力帮助您”。每个星期二，协调世界时 15:00。

第二是我们的 公开社区工作会议。对于这些会议，我们交替时间；每个月的第一个星期五，协调世界时 20:00，每个月的第三个星期五，协调世界时 14:00。这使得电话会议能够面向更广泛的受众。这些会议有一个半正式的议程，并作为行动号召，收集对关键决定的反馈和想法，以及推进需要完成的工作。我们始终确保记录行动项目并在下一次会议中跟进。

这两套电话会议都对任何人开放。两者都进行了录制，但只有公开社区工作会议公开发布。办公时间会议不公开发布，希望可以让人们更加自由地发言。

除了 Slack、GitHub 讨论和定期会议之外，我们还使用 Twitter。您可以找到我运营的 @jsonschema 帐户。任何提到“JSON Schema”的帖子都会被推送到 Slack 的一个频道，因此我们可以看到大部分讨论，并根据情况提供帮助或指引人们的方向。

希望这篇介绍可以帮助您了解为什么 JSON Schema 特别需要行为准则。也许您正在考虑您的项目是否需要行为准则。如果您有任何疑问、想法或意见，请随时使用上述任何方式与我们联系。

图片由 Maike und Björn Bröskamp 提供，来自 Pixabay