如何让程序员加入你的项目?

2 位读者喜欢这篇文章。
A bunch of question marks

Opensource.com

本月在 The Queue 专栏中,来自 LinuxQuestions.org 的 josephj 问道:

我怎样才能让程序员加入我们的项目?

我接手了一个用 $programming_language 编写的项目,因为最初的开发者离职了,没有人接手。它目前托管在 GitHub 上,并采用 GPL 3 许可证。

这是一个我每天都在使用的工具,我不想看到它消亡。我对 $programming_language 和 GUI 编程知之甚少,所以我无法自己维护它。

我该如何找到一位或多位有时间帮忙的程序员呢?

过去我找到了两三位程序员,但是,尽管他们有最好的意愿,但没有人坚持足够长的时间来完成大量工作。

答案

这是一个我经常听到的问题,所以感谢您将其提交给 The Queue 专栏。由于程序员的需求非常旺盛,并且他们自己通常也有很多副项目,因此让他们参与您的项目可能是一个挑战。我对您的第一个建议是为参与设定切合实际的期望。除非您找到另一位对该项目有浓厚兴趣或迫切需要将其用于工作的程序员,否则您不太可能找到有人直接接手维护工作。成为维护者所涉及的时间、奉献精神和责任不应被低估。话虽如此,以下是一些您可以采取的措施,以确保找到您的项目并有兴趣参与的人员能够顺利成为常规贡献者。

介绍和信息

您的项目明确概述以下内容至关重要:

  • 它的用途,
  • 它的目标用户,
  • 它的与众不同之处,
  • 以及何时何地应该使用它。

这些项目看起来很简单,对于已经参与项目一段时间的人来说,很容易忘记这些信息对于其他人来说可能并不明显。许多项目,尤其是较小的项目,由于信息缺失、无法找到或难以理解而被忽视。您正在使用 GitHub,因此 README.md 文件是放置此信息的地方。(在 GitHub 之外,README 文件也具有相同的基本用途。)包含的信息应该简洁,但要足够长,以清晰地表达您认为关于项目的重要信息。

贡献指南

您还应该创建一个 CONTRIBUTING 文件(如果您在 GitHub 上使用 Markdown,则为 CONTRIBUTING.md 文件),其中包含有关实际参与您的项目的信息。这是放置简单的分步说明的地方,包括如何克隆、关于代码应如何构建的详细说明、您可能拥有的任何编码标准或格式标准、关于测试的信息、提交补丁的流程、您的拉取请求和审查流程,以及任何其他被认为对贡献至关重要的信息。GitHub 对此评价很高:从维护者的角度来看,该文档简洁地传达了如何最好地进行协作。对于贡献者来说,快速检查此文件可以验证他们的提交是否符合维护者的指南。

简单且定义明确的初始贡献

潜在的新贡献者可能面临的最困难的决定之一是找到从哪里开始参与。让他们直接进入问题跟踪器可能很容易,但是拥有一系列小的、定义明确的任务可以大大减少获得新贡献的摩擦。

发出行动号召。诸如次要 UI 问题、翻译和小型的简单修复等任务将鼓励人们花时间熟悉您的代码库,以查看参与是否适合他们(以及您)。一旦有人花时间深入研究您的代码,那么下一步提交一个小的补丁似乎就不那么大了。在提交几个补丁之后,这个人可能既愿意也有能力承担更大的任务,例如更重要的功能请求。从那里,他们可能会成为长期的提交者。

代码质量和文档

程序员倾向于出于某种原因参与他们感兴趣的项目。持续参与的另一个先决条件是处理他们理解的代码库。编写结构良好且具有高质量文档的代码将帮助其他人更快地入门,并将确保您不会在“熟悉您的代码库”的过程中失去太多贡献者。

鼓励初始贡献

特别是对于较小的项目,很容易让补丁被忽略。对于新的贡献者来说,即使没有回应是由于日程繁忙而不是代码质量差,也不太可能导致进一步的参与。此外,尽管并非所有贡献的代码都将达到可接受的质量,但您拒绝代码的方式在许多方面为整个项目定下了基调。拥有愿意且能够以建设性的方式识别和指导潜在贡献者的现有贡献者至关重要。尖酸刻薄的敌对回应不会导致潜在贡献者提供更高质量的代码,而是让他们为不同的项目做出贡献。

目光超越线上

有了 GitHub 等出色的工具,很容易忘记也可以在其他地方找到潜在的贡献者。会议、本地用户聚会和其他线下选项可能是很好的资源,不应被遗忘或忽视。

现实情况是,为新的或小型开源项目获得贡献者并非易事。确保您做对了基本的事情至关重要。拥有关于如何参与的明确指南、易于入门的任务以及欢迎性的建设性反馈循环将促进您获得的贡献,并将有助于确保您获得持续稳定的贡献者。

User profile image.
Jeremy Garcia 是 LinuxQuestions.org 的创始人,也是一位热心但务实的开源倡导者。在 Twitter 上关注 Jeremy:@linuxquestions

3 条评论

这里所说的一切都是真的。早在 2005 年,许多工具都不可用,所以事情更加复杂,尽管如今工具(社交网络、代码仓库等)可能会让事情变得更加复杂(因为每个人都在使用相同的渠道),但痛苦却减少了。

@JR 和 @JG 我可以将这两篇文章编译成一篇法语文章吗?我想那里会有人欣赏的。

知识共享许可协议本作品采用知识共享署名-相同方式共享 4.0 国际许可协议进行许可。
© . All rights reserved.