我的开源故事开始于 2014 年,当时我从参加 Hacker Hours 之类的免费技术聚会中受益匪浅,很多开发者聚在一起,在编程问题上互相帮助,这种知识共享文化对一名刚从校园毕业,且没有大型协作经验的毕业生来说是非常有趣的。
虽然这种技术聚会很好,但我发现这种方式比较容易分散注意力。偶然间,我发现与其他开发者通过 Google Hangouts 屏幕共享是解决分散注意力问题的绝妙方法。我发现许多初学者很容易陷入编程的细节中,但是与其他人结伴是更快调试这些问题的有效方法。此外,通过网络连接,随时随地都可进行“远程聚会”,这将有助于因日程安排或地理问题而无法参加技术聚会的人。
接触开源
最初,Google Hangouts 由一系列 Google Group 邮件列表组织而成,形成了一个很小的数百人的社区。几个月后,我们发现需要一个合适的平台来主持远程学习课程。因此,我为该项目启动了一个基于 MeteorJS 构建的 GitHub 存储库。
现在,CodeBuddies 已有 5 年历史,并且已经成长为国际社区,仍然本着自愿且非营利的原则。开源是我做的最好的事情。尽管它不是传统的开源库或工具,但我所经历的许多学习和挑战与其他开源维护者完全一样。
接下来,我将分享维护此开源项目汲取的十个经验。
第 1 课:向贡献者学习
做开源,可以从其他贡献者那里学到很多。我清楚地记得两个核心贡献者(distalx 和 d3vild06)在项目早期就教了我两个基本准则:
不要让贡献者直接 push 到 master,而是 fork 项目,然后提 PR;
务必评审代码,然后再合并。
过往,我是没有这种意识的,但我接受了上述反馈,并继续向每个新人学习更多的课程,将他们的观点、问题和技术知识的多样性带入项目。
我从贡献者那里学到的很多东西甚至都与软件无关,而与项目工作流程或社区相关。 项目最开始的一个贡献者(olii)大大改善了早期的 CONTRIBUTING.MD 文档。 我学会了如何设置 CircleCI,以及如何使用 Invision 等设计工具。
提示:不确定如何检出 PR 的 git 分支? 请遵循以下命令:
第 2 课:项目代码实时在线
我通过在 codebuddies.org/hangouts 上安排视频群聊来为自己的项目提供技术协助,该视频群聊主要是通过代码库吸引新的贡献者。 由于以下原因,我建议其他开源项目维护者也做同样的事情。因为这为新贡献者提供了一个提问的渠道,确实可以帮助 git 和 GitHub 新用户。此外,我发现对话可以帮助加强联系。许多参加过代码演练的人已经成为目前主要的贡献者和朋友。
第 3 课:充分利用 GitHub 的功能
我将分享一些有关使用 GitHub 的快速技巧,比如利用 GitHub 的问题和 PR 模板;保护 master 分支;使用 CI 集成,以便在合并新提交的 PR 之前对它们进行检查;认真考虑在 GitHub 提交的问题中添加易于搜索的标签。在 CodeBuddies 上,贡献者(billglover)亲自负责清理标签,并引入了一种更有效的问题标签系统。
确保贡献者就正在处理的问题进行交流。例如,在 Hacktoberfest 业务繁忙的时期,多个人可以很容易地为同一问题提交 PR,最终导致彼此冲突。在 CodeBuddies,这是我们为减少问题冲突而制定的政策:
如果贡献者发现错误或尚未提交功能请求,请要求他们提交。
请和贡献者就分配问题进行沟通。
维护者将重新标记该问题,从标签开始。
如果提出问题的人在两天内没有更新,则维护者会将问题重新标记为再次需要帮助标签。
第 4 课:贡献不一定全部是代码
贡献不必全部都是代码。 在 CodeBuddies 上,我们使用“所有贡献者”插件,该插件可识别贡献者为项目提供的替代贡献,例如设计、文档帮助、项目管理、内容、贡献者演练、请求审查以及有关 Github 上问题的讨论。
如果没有 adachiu,那么 CodeBuddies 就不会有今天,因为 adachiu 设计了 CodeBuddies 的徽标和网站的许多部分。
通常,我还尝试为贡献者提供他们想要的方式添加到项目中。 例如:由 billglover 创建的 Buddybot,可让 Slack 社区中的用户将消息标记到私有管理员频道;由 bethanyg 在 stain88 和 angelocordon 的帮助下创建 Greetbot 向 Slack 上的新成员发送欢迎消息,并允许用户向该机器人请求编程资源;Gaurav 编写了一个 Slack 集成,使成员可以从 Slack 内部安排有关 CodeBuddies 的视频群聊。
最终,如果没有无数人的参与,他们将不会成为今天的社区,这些人提供反馈,在 Slack 上互相帮助解决编程问题,并发起群聊,邀请世界各地的开发者一起讨论。
我记得一个周末,我随机参加了一个学习群聊。事实证明,参与者来自澳大利亚、尼日利亚、芬兰、中国和印度。 每个人都在不同时区随机地在同一小时自由活动,并且在增进对技术概念的理解方面有着共同的兴趣,这是因为有人在网站上安排了时间和空间,这些贡献者也提供了帮助。
第 5 课:API 发生变化
开源项目所依赖的依赖项在整个项目过程中可能会发生很大的变化。这个过程还要密切关注 Github 安全警报,这些通知通常会在存储库顶部告警,其他工具可以帮助及时了解安全警告和依赖项升级:
Snyk
Greenkeeper
Dependabot
第 6 课:公共工作
从本质上讲,从事开源工作是公开的,但也可通过其他方式公开工作。例如:
撰写博客文章(如 Tumblr);
写 ReleaseNote;
视频采访社区成员和核心贡献者;
在处理代码库时发布到到 Twitch;
在 Slack 或 Discord 社区中创建开放渠道,以邀请成员并讨论项目更新。
上述所有,可以帮助社区更好地了解项目路线图,更好地招募新的贡献者,并阐明迄今所取得的进展。
第 7 课:金钱不是感谢贡献者的唯一奖励
我在 2017 年和 2018 年参加的 SustainOSS(我在 2017 年和 2018 年参加的开源会议)上的一个话题是如何为开源项目提供财务支持,Nadia Erghbal 在 2016 年为此撰写了出色的指南。
值得分享的是,如果项目没有很多钱,可以通过多种方式奖励贡献者。首先要记住,金钱并不是人们在贡献时一定会期望得到的回报。做出贡献的常见原因包括:
培养技术技能或探索新技术的机会
相信项目的总体目标
与他人合作的机会
在未来的工作面试中有机会谈论他们的工作
关于非金钱奖励的主要提示是:在发行说明中感谢贡献者,查找愿意捐赠非货币性物品的赞助商,例如网站托管(感谢 DigitalOcean,MongoDB Atlas 和 Netlify),课程促销代码(感谢 egghead.io 和 Tyler McGinnis),也可以抽奖给贡献者。如果碰巧拥有少量预算,那么可以使用一些钱来购买 logo 贴纸感谢核心贡献者。
第 8 课:社区管理和项目管理技能也很有价值
作为开源项目维护者,您可能会戴上许多头衔:
项目经理(project manager)
产品经理(product manager)
工程经理(engineering manager)
社区管理员(community manager)
代码贡献者(code contributor)
开源本质上是陌生人一起工作和众筹代码。作为维护者,可能会遇到一些需要调解的冲突,例如人们在技术指导上存在分歧,以及主要通过文本交流的人们之间的误解。这就需要制定路线图,传达愿景,确定问题的优先级,加入新的贡献者,学会委派并激发新兴的领导者。
老实说,我没有打算参加所有这些工作。过去几年,随着社区的发展,以及从关心该项目的成员提供的想法和反馈中学到的知识,让我感到满意。因此,在某种程度上,社区给了我学习的机会。
第 9 课:倦怠
事实上,倦怠是真实存在的,尤其是维护开源项目并不是你的全职工作时。对于一般的辅助型项目,建议弄清楚要从中获得什么,是因为正在努力学习还是因为喜欢新任务,喜欢与为该项目做出贡献的开发者合作等。
第 10 课:永无止境
我花了一段时间才能接受的一点是,CodeBuddies 永远不会“完成”。最终,每个开源项目都面临这个问题,类似 #sustainnoss 这样的社区正在探索的关键问题是如何使开源项目更具可持续性。
原文链接:
https://www.twilio.com/blog/10-lessons-learned-maintaining-open-source-community
评论 1 条评论