KiCad 开发者文化

目的

本文件阐述了 KiCad 主导开发团队所期望的工作方式。它旨在为新的开发人员提供基本介绍，同时也为目前的主导开发人员提供如何管理和解决不确定性和冲突的参考。

基本准则

  • 我们是一个平等的团队。

  • 我们尊重我们的用户群体。

  • 我们尊重彼此的贡献。

  • 我们贡献的代码属于每个人。

  • 在分歧中，每个人都会付出一点。

  • 我们把我们的家庭、我们的健康和我们的线下生活放在 KiCad 之前。

讨论

我们是一个平等的团队

这意味着你的意见将与首席开发者团队中的每一个人得到同等重视。

如果一个决定在多个开发人员的权衡下陷入僵局，那么决议将由项目负责人做出。 然而，如果可能的话，这是一个应该避免的结果。

我们也认识到，我们每个人都为团队带来了不同的经验。 在决定实施问题时，我们会尽量考虑那些积极使用某一特定功能的主要开发者。

我们尊重我们的用户群体

我们都是带着不同的期望、经验和英语流利程度来到这个项目的，开发者和用户。 当彼此打交道时，这些差异不可避免地会导致因礼貌、适当的期望或我们在沟通中可能出现的无数其他 阻抗不匹配 而产生冲突。

作为首席开发者，我们在公共项目空间的行为反映了整个项目的情况。 我们对自己行为的要求将高于对终端用户的要求。

当我们对发帖人或帖子的内容感到厌烦或恼怒时，我们不会对任何问题报告、合并请求或论坛帖子做出回应。 我们提供了一个 Zulip 频道，主要开发人员可以标记其他人来承担平静回应的负担。 我们会做以下工作:

  1. 发布一个有关页面的链接

  2. （可选）表达我们的任何挫折感

  3. 说出为什么这个内容是错误的

(1) 和 (3) 是必须的。 (2) 是可选的，但如果它有助于分散围绕内容的情绪，则可以使用。 在这一点上，另一个不感兴趣的首席开发人员将承担起回应的任务。 你可以回去编码其他东西了。

如果不遵循这一准则，将不可避免地导致戏剧化。 而戏剧性的事情会吸走你、对方和其他主要开发者团队的时间，因为我们最终要处理的是回应而不是实际内容。

我们尊重彼此的贡献

虽然我们都会犯错，但我们不会在没有明确同意的情况下撤销其他开发者的贡献，即使我们认为他们可能没有按照我们对标准的看法来实现一些东西。

我们每个人都要对自己的贡献的质量负责。 如果对提交的代码有异议，必须通过 电子邮件 / Zulip / 视频通话 /等方式与提交代码的人解决。 我们不在代码库中打架。

如果一个有问题的提交被提交到了代码库中，而负责的人又不能讨论，那么在公开（在 GitLab 或 Zulip 上）讨论并同意后，提交可以被撤销，并与其他主要开发团队的成员一起讨论。

当我们不同意其他开发者的贡献时，我们会礼貌地直接与他们讨论。 礼貌性反馈的例子可能包括：

This code doesn’t work for me when I… 这段代码对我来说不起作用，当我…​

Or/或

I think that this code will cause problems because… 我认为这个代码会引起问题，因为…​

我们将避免的粗暴反馈的例子包括：

This code stinks/sucks/is really bad/etc 这段代码很臭/很烂/非常糟糕/等等。

Or/或

Whoever screwed up this part of the codebase… 不管是谁搞砸了这部分的代码库…​

当然，我们都欢迎为自己写的代码提供尽可能多的不礼貌的反馈，因为我们可以处理。:)

我们贡献的代码属于每个人

我们是一个自由/自由的开源社区。 我们为 KiCad 项目贡献的一切都属于整个 KiCad 开发团队并由其负责。 新文件的版权将被分配给 KiCad 开发团队。 它们可能会被额外分配给编写代码的主要作者或发起人，但这并不意味着原作者在讨论代码如何发展时拥有否决权或甚至更大的权重。

当我们向 KiCad 代码库提交代码时，我们是站在所有在我们之前这样做的人的肩膀上的。 我们的贡献将以我们没有预料到的方式被改变、更新、改进和完善，甚至我们可能不同意。 这个过程是对原始代码作者的赞美，因为如果没有原始工作，这些改变是不可能的。

在分歧中，每个人都会付出一点

在对规范文件或代码本身的讨论中，我们经常会遇到这样的情况：我们对某一特定功能或其他实现细节的方向有不同的看法。 当这种情况发生时，我们会努力确定对每个开发者来说最重要的元素的优先次序。

我们决定一个功能的哪些部分对我们来说更重要，并要求这些部分的存在，放弃那些虽然仍然非常重要，但比其他部分不那么关键的部分。 每个人都被期望缓和他们的立场，以达成共识。

我们提供意见的方式要让人知道这个意见的重要性和原因。 比如说：

非常重要的是，我能够以同样的方式修改直线和弧线的起点，因为我需要这是个统一的 XYZ 接口。

或

我对打印对话框的非模式化有偏好，这样我就可以看到预览的实时更新，但这并不是一个强烈的偏好。

在与其他开发者进行对话时，评估我们自己的优先事项是很重要的。 并非每一个意见都能成为最重要的、第一优先事项。

团队中的每个开发人员都有很高的技术水平，如果不止一个人与你意见相左，那么退后一步，审视一下你的意见是否可能不合适或需要改变，总是一个好主意。

我们会额外考虑那些积极使用某项功能的开发者和那些愿意实施自己设想的开发者提出的关切。

如果参与讨论的开发者不能达成一致，在各自调整立场以适应协议后，最终决定将由项目负责人做出。 如果可能的话，应尽量避免让项目负责人参与解决争端。

我们把家庭、健康和线下生活放在 KiCad 之前。

KiCad 是一个为社区做出贡献的好地方。 我们努力做到开放和相互参与。 我们努力与对方欢笑，相互支持。 但我们仍然只是一个由志同道合的人组成的在线小组。 我们不会给对方施加压力，让他们工作得更多或更长。 我们会鼓励对方从编码中休息。 我们会注意过劳或压力的迹象，并鼓励对方在关心代码库的健康之前先关心我们自己的健康。

我们将在设计我们的系统和程序时，为任何需要意外请假的人提供便利。