我如何每周花 4 小时成为 Kubernetes 维护者

如果你只有少量时间,你也可以在开源领域做出重大贡献。
137 位读者喜欢这篇文章。

“我想为 Kubernetes 做贡献,但我不知道从哪里开始。”

Kubernetes 开始受到关注以来,我多次听到(甚至说过)类似的观点。因此,在过去一年里,我花时间为该项目做贡献,我发现每一分钟都物有所值。

我发现 Kubernetes 是一个规模合适的项目,任何人都可以利用他们日程安排中的任何时间来做出贡献。对我来说,每周只需四个小时。不多也不少。

在每周四个小时持续了六个月之后,我发现自己成为一个小组的领导者,这个小组在对项目的非代码贡献方面正在做出重大改变。

我将分享一些我从 Kubernetes 贡献中学到的东西。我希望它可以帮助你找到重点和时间参与进来。

从哪里开始

Kubernetes 社区体现了“参与”的原则。我曾经在社区频道“潜水”了一段时间,但没有花太多时间在其中发言。一旦我开始参与并(最终)发言,我立即感受到了社区意识的改变。

你问在哪里参与?以下是需要关注的关键渠道:  

这些渠道结合了同步通信(实时、快速反馈)和异步通信(最终、深思熟虑的反馈)。与我贡献过的任何其他项目相比,Kubernetes 对同步通信有微妙的偏好。参加会议或参与 Slack 讨论是参与行动的一种有价值的方式。你在实时互动中越活跃,从长远来看你就能产生越大的影响。似乎是这样。

尽管同步很重要,但不要忽视 Kubernetes 领域完成的异步工作。所有重要的活动,以及积压的需要人去做的深思熟虑的想法,都通过 GitHub issue 进行跟踪。邮件列表也越来越活跃,是建立联系的好地方。

无论通过哪个渠道,结论都是一样的:你必须参与。

我如何安排时间

很多人全职从事 Kubernetes 工作。我不是其中之一,如果你正在阅读这篇文章,我假设你也不是。那么,当你有一份每周 40 小时的工作时,你如何在一天中抽出宝贵的四个小时来为开源项目做贡献呢?

就我而言,这始于理解我的业务价值。我很幸运为一家通过开源贡献来定义自己的组织工作。这是一个好的开始。我的组织也普遍重视开源经验,更具体地说,是 Kubernetes 知识。因此,作为一个对组织的价值可以通过理解 Kubernetes 来衡量的人,可以合理地认为我需要花时间在这个项目上。

在我清楚了业务主张之后,我的下一步是开始。我没有从电子邮件请求或提案开始,将此作为我工作的一部分。管理我的技能发展是 *我的* 工作,我决定通过(限时的)开源贡献来最大化这一点。相当于每周半天的工作时间,我被信任可以支配我的时间。但需要注意的是,如果我的贡献 (a) 开始妨碍我的日常工作,或 (b) 没有为我的日常工作带来任何有意义的价值,我就必须停止贡献。

在贡献大约一个月后,我与我的团队、我的经理和我的经理的经理分享了一些我新获得的 Kubernetes 知识(这是我通过定期参与获得的)。他们都对我分享的内容感到兴奋。因此,我提出了继续贡献的想法,他们都非常同意这是一个好主意。

八个月后,我仍在贡献,并且它仍然在增加价值。

四个小时的贡献是什么样的?

这是我在 Kubernetes 社区中可持续贡献策略的清单

  • 每周参加一次 SIG 会议(1 小时)
  • 每周浏览两次 k-dev 邮件列表,每次 15 分钟(30 分钟)
  • 每周在 Slack 或 Twitter 上社交一次(30 分钟)
  • 大多数情况下,再安排两个一小时的时间段来完成你的行动项(1 到 2 小时)。
  • 每月一次,拿出一个小时参加每月社区电话会议(0-1 小时)。

我的前三个月完全是为了熟悉情况,而且它们得到了回报。一开始,计划花一些时间来了解背景。如果没有 SIG 立即吸引你的注意力,请从 Contributor Experience 开始。这个小组的存在是为了帮助指导和支持所有贡献者。

坚持这个时间投入,六个月后,我从参加 Contributor Experience SIG 会议到领导其 Upstream Marketing 小组。就我而言,时机恰到好处,角色也适合我的技能,但这表明持续的贡献可以很快得到回报。

跨时区贡献

同步活动——会议和 Slack 消息——确实偏向美国太平洋时区。这部分没什么好粉饰的。每周五,在我们的小组电话会议上,总有一些常客在欧洲和亚洲的晚上 8 点或 10 点之后签到。这对某些人来说不是理想的时间。

但是,虽然这些同步电话会议有助于了解团队,但贡献者可以快速切换到异步选项,并且仍然可以对项目产生重大影响。GitHub、电子邮件,甚至异步 Slack 占据了 90% 的工作完成量。对于某些 SIG,这个比例接近 100%。与其他 SIG 成员坦诚沟通,我相信他们会帮助你异步完成有意义的工作。

带来你独特的贡献

这是我从中学到的重要一点:大型项目通过持续的贡献蓬勃发展。长期做出小的贡献比一次性的、临时的 pull request 更有价值。

我详细地介绍了我是如何管理时间的,以突出一个我认为我们许多人可能没有意识到的机会。通常,我们对如何度过我们的一些工作周比我们想象的更有发言权。我希望你能从中抽出一些时间用于开源。你将提供独特的经验,从而有所作为。

接下来阅读什么
标签
I'm happiest at a microphone
Matt 曾经是 EMC 存储专家、VMware vExpert,以及其他专有技术的爱好者。他现在专注于开源和 DevRel 的应用。

1 条评论

感谢你对 Kubernetes 提出的这个有趣的观点。就我而言,我在设置它时遇到了很多困难。以至于我最终放弃了...
我现在改用 Docker Swarm,我对此感到非常满意,因为它既简单又强大。当我读到这篇文章时,我决定切换:https://juliensalinas.com/en/container-orchestration-docker-swarm-nlpcloud/
作者解释了他如何在 nlpcloud.io 后端成功使用 Docker Swarm。这很有趣,因为很多人倾向于认为 Docker Swarm 适用于小型网站,而 Kubernetes 适用于大型网站。但似乎情况并非如此...
再次感谢这篇好文章!

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 获得许可。
© . All rights reserved.