OpenACID’s Code of Conduct

本文链接: https://blog.openacid.com/culture/code-of-conduct/

社交规则

避免”故作惊讶”

第一条规则是, 当对方说他不知道某件事情时, 你最好不要(刻意的或无意的)表现得很惊讶。

包括技术问题(“什么?!我不能相信你不知道堆栈是什么!) 和非技术问题(“你不知道谁是RMS ?!”) (RMS: Richard Matthew Stallman, 自由软件奠基人)。

“故作惊讶”不会让沟通变得更顺畅, 同时也没有提供更多的信息到对话中: 当人们故作惊讶时, 通常是为了能自我感觉良好, 而使其他人感受很糟糕, 即使这些行为不是有意的。

显然, 这与我们的另一个原则十分相关: 创造一个氛围, 让人们在说“我不知道”时能感到自在无压力。

避免 好为人师的”呃, 但实际上是…”

“呃, 但实际上是…” 发生在这样的场景中: 对方说了一些事情, 但其中有些不准确的小地方, 这时你打断对方说, “呃, 但实际上是…”, 然后给出一个小纠正。.

不论当时讨论的问题简单或复杂, 除非这些小问题是非常关键的, 否则不需要一定要指出来。

如果这些小问题对沟通至关重要, 如果不明确下来会产生歧义, 那么一个必要的澄清和单纯的为人师就之间才有区别。

避免在不了解问题全貌的情况下给出意见

如果你偶然听到有人在讨论某个问题, 最好不要立刻向对方表达你的意见.

其中一个原因是这样可能会导致”too many cooks”的问题(太多厨子一起做饭很快会毁了一道菜), 而更重要的是, 突然加入到一个进行到一半的讨论有些粗鲁, 更重要的是很可能会破坏正在进行的讨论。 在使用Slack进行的沟通中尤其如此。 在一场正在进行的对话中, 这种突然的介入, 尤其当你只是通过回滚了几屏聊天记录来了解到对话内容的时候, 可能会造成很大的干扰。

这并不是说你不应该加入对话提供帮忙或建议。 相反, 我们鼓励所有这些行动。 它只是意味着, 当你想要帮助别人或与他人合作时, 你应该充分参与来了解到更多信息, 而不是时不时的插话。

避免不易察觉的嘲弄语气

这些不易察觉的嘲弄语气, 也被称为微攻击性, 是一些让别人感到不舒服的小事情, 例如, “这事太简单了我奶奶都会”就是一个这样的例子, 因为这句话里带着些许性别歧视和年龄歧视。

说它”不易察觉”, 是因为可能不是所有人都能马上感觉到这些言辞的问题,

即使是这些言辞所指的那些人。 但是, 即使它们是不易察觉的, 可能还看起来像句玩笑, 而且往往是无意的, 一系列这样的言词也会给对方带来被嘲弄的感觉。

时间管理

尊重他人; 尊重远程协作的团队成员的时间、位置或其他因素。

保持你的日程表随时更新, 准时参加会议, 拒绝你不打算参加的会议。

开会时, 要克制只喜欢本地开会的诱惑, 当需要远程团队成员参与时, 把需要参会的人拉进slack, hangouts或其他协作工具

给出反馈和接受反馈

给出建设性的, 而不是否定性的反馈。

否定性的反馈是说, 它指出了一个产品或一个人的问题, 却没有提到如何改进他们的行为或产品.

• 工作中, 否定性的反馈通常看起来是这样的: “你没有编写足够的测试”或“你的代码质量不够好”。 针对个人的评价可能会更严重, 通常类似这种: “你不应该那么武断”或“你是个累赘, 因为你问了太多问题”。

• 建设性的反馈 更多的是关于一个人如何能做得更好, 而不是他们做错了什么。 如果你想让某人做得更好, 你应该告诉他们什么是更好的。 首先, 询问一下这个问题讨论的前后内容, 了解问题的场景, 然后如果你发现有改进的空间, 就给出明确的建议。

  它创造了这样一个环境: 让大家明白成功是什么样子的, 而不是让人觉得自己很失败。

代码、配置文件, 以及对这些东西的评审也是沟通的一种。

就像你希望能够与他人在面对面交流时能友好积极一样, 在通过代码或代码评审时与他人的交流也应该这样。

你不是你的产品。 往往针对技术或产品的评论是直接和直白的, 但记住, 这些都是针对产品的, 这不是针对作者的。 不用说你一定非常在意你的工作和作品, 并在尽可能做到最好, 但这种对自己作品的感情有时会让评审变得困难重重。每个人都应该认识到: 在评审中发现问题比在生产环境中发现问题要好的多. 而且评审可以确保你的工作能跟整个团队的目标一致。

在评审他人的作品时, 首先假设作者的这些决定是有原因的, 而不是在凭空想出的。如果你不明白作者为什么这么做, 就问问他这么做的原因。

另一方面, 做到务实, 多询问问题的背景, 以不阻碍工作推进的方式做事, 例如如果你在别人的代码中发现一个你认为需要修改的问题, 但这个问题并没有在code style指南中明确规定, 那不提也罢.

代码、配置文件、架构、平台和框架总是需要演进和改变的。 如果你认为自己的设想是正确的, 那就推进这些改变, 但是, 也并不一定仅仅因为它是正确的就一定要改变。

本文链接: https://blog.openacid.com/culture/code-of-conduct/