diff --git a/content/zh-CN/guides/employee-engagement.md b/content/zh-CN/guides/employee-engagement.md new file mode 100644 index 00000000..dee96236 --- /dev/null +++ b/content/zh-CN/guides/employee-engagement.md @@ -0,0 +1,212 @@ +--- +标题:员工开源参与指南 +--- + +本指南适用于将开源贡献作为雇主工作一部分的人员 + +直接与开源项目合作可以为每个人创造价值。受益者包括:你、你的雇主、开源项目和项目的用户。在开始与开源项目互动之前,你应该考虑一些挑战以及好处。这将有助于你取得成功,避免冲突或失败等问题。 + +本指南将帮助你了解如何与社区互动,如何确保尊重所有参与者的需求,以及如何确保你的参与是有价值的。 + +注意:由于你是代表雇主工作,你需要遵循一些他们期望的规则。本指南不会涵盖这些内容,但你可以阅读我们的其他指南以获取更多信息——[开源软件外部使用指南](https://todogroup.org/guides/outbound-oss/)。 + +每个项目中都有期望和规则,且存在文化和惯例。了解这些内容可能需要时间,因为它们可能不会立刻显现。我们建议你以尊重、透明和富有成效的方式参与开源社区。我们称之为*真实参与*。 + +**真实参与的七项原则** + +* [尽早开始。](#principle-1-start-early) +* [社区第一。](#principle-2-put-the-community-first) +* [从倾听开始。](#principle-3-start-with-listening) +* [继续参与。](#principle-4-continue-by-participating) +* [保持透明的动机。](#principle-5-have-transparent-motivations) +* [提倡尊重的行为。](#principle-6-promote-respectful-behavior) +* [优雅地结束。](#principle-7-end-gracefully) + +## 原则 1:尽早开始。 + +*在开发的早期阶段与社区进行互动,而不是等事情“完成”后再联系。建立信任。在贡献的创始阶段融入反馈。向社区学习。协同思考。在选择建设内容时达成共识。尽早参与,经常参与。* + +你可能会想立刻开始贡献,但这通常不是与开源项目建立良好且持久关系的最佳方法,有时还会导致意想不到的后果。例如,项目可能已经开始处理相关功能,或者之前讨论过某个功能但决定不实施。如果你在不了解背景的情况下就开始贡献,就有可能把时间和精力浪费在不需要或不想要的任务上。更糟糕的是,如果项目中没有人知道你是谁,你甚至可能会被认为是在试图强行推动一项只与你的雇主相关的变更。 + +通过遵循第一条原则:*尽早开始*,你可以避免这些意外后果。 + +与其直接进行贡献,不如先了解社区:它是如何运作的,它的需求是什么,以及它是如何管理的。通过加入社区首选的讨论渠道与社区互动,谈谈你想要进行的贡献。始终保持谦逊和透明的态度,展示你渴望学习和合作的意愿,公开你的公司隶属关系。在开始任何工作之前,通过互动与社区其他成员建立信任。 + +保持谦逊。当你尽早开始时,你会将学习放在首位,并尊重社区的专业知识和历史。你会发现,社区中蕴藏着丰富的经验,他们很可能已经思考过你要合作的想法。要小心,你可能正处于 [邓宁-克鲁格的“愚蠢山”顶峰!](https://ardalis.com/the-more-you-know-the-more-you-realize-you-dont-know/)。 + +在谈到任何可能的贡献时,请告诉社区为什么这项贡献对你来说很重要。说明你打算采取的方法和实施想法。尽早分享这些信息向社区表明,你尊重他们的时间和社区的工作方式。这将组织贡献的重心从“我”转移到“我们”:不是“我来解决问题”,而是“我们一起做一些事情”。 + +通过遵循*尽早开始*的原则,就能避免出现以下糟糕的情况:有人代表某个组织提出了一个重要的功能和大量的拉取请求,但最后却发现接收项目并不感兴趣。这最终会给所有参与者带来不快,而*尽早开始*可以通过提供社区反馈的机会,提前了解项目是否对该功能感兴趣,从而避免这些问题。 + +### 尽早开始的提示 + +* 在你编写任何代码之前,请加入讨论,跟踪变更,并倾听。 +* 提问。 +* 从简单的工作开始,为社区已经确定的需求做贡献。 +* 始终对你的来历(即你供职的组织)保持透明。 +* 当你首次加入一个社区时,不要害怕承认那些在你之前做出贡献的人。 +* 尽早开始意味着在事情还不完美之前就开始交流和贡献。不要害怕展示自己。保持轻松,做一个真实的人——在社区中没有人是机器。要注意语言和幽默的选择。当人们不了解你时,你可能会被误解,这可能导致额外的问题。 +* 意识到你可能身处一个国际化和地理多样化的空间中。倾听并注意差异,例如语言差异、文化差异、薪酬差异。 +* 展示你的工作、你的过程、你的思考——在完成之前。 +* 保持兴奋,你在这里是有原因的! + +## 原则 2:社区第一。 + +*平衡每个人的利益并寻求一致。如果不确定,就将社区的利益放在首位。这将带来更好的长期结果。以个人身份参与,但要牢记你的隶属关系和你所在组织的利益。永远不要忘记,开源是一项协作努力,集体掌握着时间轴。* + +开源是基于社区的构建。一旦你开始为一个项目做贡献,你就成为其社区的一部分。开源是一项协作性的工作,往往能比孤立工作产生更好的结果。 + +成功的开源社区像一个同伴小组,社区成员的个人参与和行动比他们的身份、职位或隶属关系更为重要。俗话说:“谁写代码,谁做主。”这给作为贡献者的你提供了很大的自由,但也赋予了你很大的责任。尤其是当你代表一个组织行事时,你需要平衡所有相关方的利益,并寻求一致。如果有疑问,请将社区放在第一位。你需要在你的组织中倡导他们以勇气和耐心支持这种做法。长期的利益将超过你在项目中强加雇主议程可能带来的短期收益。你的目标应该是致力于那些重要的变更,而不是将尽可能多的变更推向上游。不要将你公司的内部路线图强加给项目。专注于了解哪些任务需要帮助,并为你能够产生影响的任务做出贡献。 + +你刚加入的社区有现有的流程和历史,你需要对此有所了解。使用指定的沟通渠道和方式。社区是由许多个人组成的,制定规则是为了确保有一个安全的合作环境。这并不意味着你和你组织的利益不重要,而是意味着它们是集体利益的一部分。如果这些集体利益得到了平衡,那么整体结果将超过任何贡献方单独所能取得的成果。 + +> “……开源在由社区维护时是最具创新性和可持续性的。社区主导的开源开发促进了丰盈,为所有人创造了一个更大的“蛋糕”,包括为个别供应商带来更大的收入潜力,而不是单个供应商试图独占一个相对较小的“蛋糕”的利益。” [来源](https://thenewstack.io/why-the-best-open-source-is-community-led-open-source/) + +以协作方式开展工作的一个重要事实是,集体掌握着时间轴。个体利益会产生影响,但最终决定权在于集体。要对此保持警觉,并采取相应行动,避免强加或期待任何任意的时间表,例如为了满足你雇主的最后期限而推动某些变更的合并。 + +### 社区第一的提示 + +* 以个人身份行事,但不要隐瞒与雇主的隶属关系。 +* 专注于贡献,而不是它的来源。 +* 不要试图通过使用雇主或职位等身份信号来获取更大的影响力。 +* 牢记雇主的优先事项,但也要做好社区有不同优先事项的准备。 +* 当你需要实现内部目标时,尽量通过采取符合社区利益的行动来影响社区。 +* 找到能为社区创造价值的小事情,即使它不在雇主的直接议程上。 +* 积极响应并考虑周全,社区是你最大的盟友。 + +## 原则三:从倾听开始 + +*从倾听和了解项目、人员及其文化开始。通常会有大量文档和交流的公共档案,可以让你很好地了解社区的运作。利用这个机会。不要把自己当作一个无所不知的人介绍给项目。* + +当你的公司要求你参与一个对你来说很陌生的开源项目时,你应该花时间了解这个项目是如何运作的。如果有贡献文档,请阅读(如果没有贡献文档,你也可以了解项目如何运作,然后创建一份贡献文档,作为你对社区的第一份贡献)。 + +查看邮件列表(通常发布在项目网站上)、论坛和项目仓库(repo)。熟悉 repo 上的拉取请求(PR)和错误(bug)/问题(issue)报告。有些项目使用 Slack、IRC、Discourse、Discord、Mattermost 等交流渠道,你应该订阅这些渠道。介绍自己:你是谁、你代表哪家公司等。要表明你是代表雇主参与项目的。介绍完自己后,一个好的做法是征求建议,了解从哪里入手以及什么样的贡献适合新人。记住,你是在为社区工作,社区的需求才是第一位的(见原则 2)。 + +有些项目每周或每月举行会议,因此,如果时区允许,最好也参加这些会议,以便了解项目和参与人员的情况。 + +当你有问题时,很可能已经有人提出过同样的问题,因此最好的做法还是先搜索项目的讨论频道/邮件列表中的邮件,看看你的问题是否已经有人回答过。如果你的问题是新问题,尽管问吧。同样,如果你认为你的问题应该在项目的自述文件(readme)、贡献文档或其他项目文档中找到答案,请确保添加相关信息并做出贡献。 + +通过从倾听开始,你将了解项目是如何运作的,同时也会了解到哪些内容没有被记录下来,哪些反映在文化中。这让你和你的组织能够描绘项目的非正式网络和规范。 + +如果你完全是开源新手,这也是了解拉取请求、分叉/分支、审查等工作方式的好方法。如果你以尊重的态度对待开源项目,愿意倾听,并将所学付诸行动,那么开源项目是非常欢迎你的。 + +### 从倾听开始的提示 + +* 阅读README文档。 +* 阅读贡献(CONTRIBUTING)文档。 +* 查找主要的沟通渠道,并查看档案,了解社区是如何沟通的。 +* 访问项目所在的地方。你可能需要使用一些你不熟悉或不喜欢的沟通和源代码控制平台,但作为新的贡献者,你需要做这些工作以便加入他们的社区。 +* 如果你有问题,请先搜索issue /PR/留言板/FAQ,看看是否有人已经回答了你的问题。如果没有,请使用适当的途径提出问题。 +* 查看已关闭的issue和PR,了解贡献的运作方式。 +* 查找会议上项目介绍的录音,以更多了解该项目和介绍它的人。 + +## 原则4:继续参与。 + +在对项目、社区流程、沟通工具和渠道有了一些基本了解后,你就可以开始参与其中了。你可以采取一些小步骤来介绍自己,与已有的贡献者和项目维护者互动,并找到可以贡献和提供帮助的地方。 + +作为参与项目的第一项行动,你应避免对项目的代码库或文档提出大的改动。你需要首先与项目的贡献者建立良好的关系和信任。这将有助于你使自己未来的贡献与项目的整体使命和目标保持一致。 + +虽然许多开源项目都有良好的文档和活跃的沟通渠道供学习,但你可能仍然会有一些问题没有找到答案。在邮件列表或聊天平台上提问是与社区取得联系的好方法。始终通过分享背景信息确保清晰地沟通,这样你的问题或评论才具有必要的背景。 + +如果你已经花了一些时间部署和试用项目,那么你就已经掌握了一些良好的知识。即使是新手,你也可能知道别人的问题的答案,或者可以帮助他们找出下一步要做的事情。不要害怕参与讨论,帮助别人。 + +优先对代码或文档进行评审。大家都很重视这项活动,这也是了解项目的好方法。 + +如果你有有用的信息可以分享,不要害怕参与讨论。分享你的经验或提出一个澄清性的问题有助于推进对话。这也是向社区表明你关心他们的项目并愿意参与维护和进一步发展的好方法。 + +许多项目都有一份错误列表,上面标有 “可轻松实现的目标”、 “易于修复”或类似的字样。研究修复其中的一些错误是学习和参与帮助社区的另一个好方法。如果你还没有足够的知识来修复错误,整理错误也是一种很好的帮助方式。 + +参与社区的日常生活有助于你成为团队的一员。参与活动很重要,即使这些活动似乎与雇主的直接利益无关。帮助社区维护项目实际上符合每个人的利益,包括你的雇主!你还可以在社区中为自己发出声音,从而有机会推动设计和实施你和你的公司需要的新功能。 + +每个人在参与一个新社区时的舒适程度不同,特别是当他们可能还不认识任何人时。如果在会议上发言让你感到害怕,您可以通过邮件列表进行沟通或选择进行代码评审。始终保持谦虚,进行清晰的沟通。如果你让别人知道你是项目的新人,还在学习中,那么其他人就会有机会帮助和指导你走过整个过程,直到你变得更加成熟和熟悉为止。 + +提出变更建议,并展示其影响力。第一次尝试可能不成功。反复尝试。不断学习。如果感觉自己被忽视或建议被拒绝,不要生气。这种情况可能会发生。动机各不相同。不要提要求。这会毁掉你的信誉。 + +### 参与的提示 + +* 如果有社区会议,你可以介绍自己,甚至询问他们哪里需要帮助。 +* 你可以参与邮件列表或聊天平台上的讨论,提出问题和回答问题。 +* 进行代码和文档审查,这是每个社区都需要帮助的地方。 +* 整理错误或寻找更简单的issue进行修复。 + +## 原则五:保持透明的动机 + +*没有对动机的共同理解,就无法有效解决意见分歧。不要隐瞒你的动机。* + +你在项目上的工作应该是透明的。透明性有许多不同的方面和维度,我们将在这里进行解释。 + +你应该向社区的其他人公开你对这个项目的投入程度。如果你只能处理与公司利益重叠的问题,最好坦诚相告。如果你能在项目需要的任何方面提供帮助,告诉他们!也许你可以进行一次性修复,或者你想朝着长期维护某些代码的方向努力。所有选项都是有效的,没有对错之分。 + +重要的是要清楚地说明你为什么要做你选择的任务。尽可能多地分享背景信息,以便其他社区成员可以评估这项工作的重要性,以及为什么应该将其纳入项目。这并不是要泄露公司战略,而是要分享和解释为什么需要这项特定的工作。 + +在与社区互动时,我们扮演的不止一种角色,例如公司的角色或个人的角色。重要的是要区分并明确说明你在每个时刻扮演的角色。例如,在提交变更或写邮件时,要相应使用公司或个人的邮箱([更多信息](https://www.juliaferraioli.com/blog/2022/your-git-email-matters/))。 + +你可能没有权力正式代表你的组织发言,但有些人仍会将你视为组织的发言人。对此要谨慎处理。不要玩政治游戏,这样只会失败。 + +有些公司会认为,他们有钱、有地位或有客户,因此可以主导开源项目。有些公司会试图在项目中强加隐藏的议程。这不是开源的运作方式。为了项目的利益,积极贡献才是“货币”。影响一个项目是可以的,每个人都会明白,公司并非出于纯粹的理想主义动机而做出贡献。但这是通过向项目派遣从事有价值工作的个人来实现的。作为一名员工,你就是这些人中的一员。因此,你需要平衡这一点,并对自己的动机保持透明。 + +### 展示透明动机的提示 + +* 当代表你的组织工作时,使用组织的电子邮件地址进行提交。 +* 在GitHub上注明你的隶属关系。 +* 时刻意识到你在每个时刻扮演的角色。 +* 如果其他人可能不知道你的背景,要清楚说明你所持的观点。 +* 当你的动机或隶属关系发生变化时,要保持透明。 +* 谨慎使用后台频道和私人对话。这可能会破坏项目交流,因为项目没有这种背景。 + +## 原则六:提倡尊重的行为 + +*学习并遵守社区制定的行为准则。你的组织应承诺让你对自己在开源空间的行为负责。* + +开源项目是由人创建、与人合作、为人服务的。我们很容易忘记,网上的头像背后也是真实的人。你应该始终保持尊重,遵守社区规定的参与规则。 + +项目和社区通常都有行为准则。这是社区领导层对社区做出的承诺,即决不容忍任何滥用职权的行为。花点时间阅读并理解这些准则。你需要像遵守你们公司内部员工手册一样遵守这些行为准则。 + +如果你不遵守准则,你和你公司的声誉都将受到影响。为了大家的利益,请始终以尊重的态度参与。贵公司将把任何违反开源项目行为准则的行为视为违反内部员工手册的行为。 + +除了行为准则外,每个社区都有其偏好的沟通方式和参与讨论的方式。花时间了解每个社区的参与偏好,并遵循他们的方式。 + +要知道,开源社区的成员往往背景各异,来自不同的文化,讲不同的语言。如果使用的是没有太多语境的书面交流渠道,就很难注意到这一点。Postel法则是一个有用的指南:“在你的行为上要保守,在接受他人时要宽容。” + +### 促进尊重行为的提示 + +* 阅读并遵守项目的行为准则。 +* 不要假设他人有恶意,可能只是误解。 +* 生气时不要写邮件。 + +## 原则七:优雅结束 + +*不要突然撤回资源。相反,要给予适当通知并分享退出计划。提供清晰的文档,以便在贵公司决定撤出支持时,社区能够接手项目。* + +人们会记住你是如何离开一个项目的。开源项目的结束会影响你进入下一个项目的方式,无论你是回到同一个项目还是进入一个新的项目。当善意的开源贡献者就这样消失,留下沉默和疑问时,这可能是破坏性的。 + +在开源之旅中,结束与其他时刻一样重要。当你离开一个项目时,这是实践我们所讨论的所有原则的机会。 + +原则4和5尤其相关。要透明并保持尊重。当你加入一个项目时,建议分享你对项目的预期承诺和参与程度。当你离开时,应该总结并分享你的退出计划。解释你如何完成任何正在进行的工作,以及你在哪里记录了任何交接信息。任何合作都不会太短,但必须妥善完成。 + +要尊重并意识到情况会发生变化。优先事项会变化,或者会发生意外事情,这都是正常的。尽早与社区分享至关重要。提前结束和意外延期都是如此。 + +如果你接手了一些代码的维护者或其他重要角色,那么优雅地卸任、保持透明并将接力棒传给下一个人是至关重要的。 + +### 优雅结束的提示 + +* 当你无法继续贡献时,告知项目。 +* 如果你是维护者而无法继续担任这个角色,找到接任者后再卸任。 +* 确保有足够的文档可供他人接手你的工作。 + +## 贡献者 + +本指南基于在 Sustain 2020 创建和讨论的 [真实参与原则](https://authentic-participation.readthedocs.io/)。感谢 Justin W. Flory 推动了这一进程。 + +本指南的贡献者(按字母顺序排列): +* https://github.com/alice-sowerby +* https://github.com/awright +* https://github.com/cornelius +* https://github.com/DavidPHirsch +* https://github.com/DuaneOBrien +* https://github.com/ildikov +* https://github.com/jamesiri +* https://github.com/jlprat +* https://github.com/juliaferraioli +* https://github.com/lucasgonze +* https://github.com/winterrocks