慈善代码马拉松

2012年1月25日

在过去的几年里,我的几位同事一直在组织代码马拉松[1]活动,让开发人员聚在一起为慈善事业编写软件。一个很好的例子是纽约定期举办的代码马拉松,该活动致力于RapidFTR。Chris George,一位驻扎在纽约的ThoughtWorker,帮助组织了2010年8月在纽约举办的一次性活动。该小组在当天没有完成他们希望完成的那么多工作,但在随后的酒吧里,他们决定尝试更定期地聚会。从那时起,他们每周都会见面。这是一个小团体,仍然主要是ThoughtWorkers和朋友,核心成员有3-4人,当我们有大型项目在城里时,人数会增加到12人。[2]。(Chris很乐意让更多人加入这个小组,所以如果你有兴趣,请给他发邮件。)

许多人发现这些活动是将我们的技能用于我们认为比许多日常工作更充实目的的一种愉快方式,也是学习新技能和从不同群体的人那里学习的一种方式。所以我想我应该分享我们关于如何建立一个代码马拉松的想法。

首先是找到一个合适的努力目标。我们希望为非政府组织生产开源软件的项目做出贡献——开源模式非常适合此类组织。我们与之建立了最密切关系的两个项目是RapidFTR和OpenMRS。RapidFTR是一个旨在帮助灾难或其他灾难发生后团聚家庭的系统。它允许人们快速输入有关失踪儿童或没有父母的儿童的信息——然后提供搜索功能来匹配他们。OpenMRS是一个开源医疗记录系统,旨在支持各种形式的医疗保健交付工作。它被世界各地的许多医疗保健团体使用(不仅仅是在发展中国家)。

与纽约一样,我们大多数代码马拉松都是从一次性活动开始的,一次晚上或一整天的活动。如今,我们大力宣传,希望吸引当地开发人员的良好样本参与其中。这种一次性的代码马拉松通常不会产生太多有用的软件,因为它们时间太短,无法真正完成太多工作。但它们仍然有价值。首先,它们会提高知名度,让当地开发人员社区了解特定项目以及为非政府组织进行开源工作的概念。更直接地说,它们可以成为定期代码马拉松的种子,因此将活动组合在一起以鼓励以后再次聚会是有用的。

定期代码马拉松会按照计划进行,核心成员每周都会参加。这样一个小组可以对代码库做出一些重大贡献。人们会来参加,因为他们可以接触到一些不同的技术,与不同的开发人员群体合作,面向的受众(与大多数开源项目不同)不仅仅是其他开发人员。

为了取得有意义的进展,你需要有人为每次代码马拉松做好准备,将工作项分解成足够小的部分,以便人们能够在马拉松期间完成它们。无论人们怎么说,他们很少会在代码马拉松时间之外工作在这个项目上,而且时间安排过于频繁,不希望半途而废的事情悬而未决。小任务允许团队在每次马拉松中取得明显的进展——这有助于保持高昂的士气。我们喜欢在每次活动之前将这些任务发布到网上,以便人们可以提前准备,或者只是了解我们正在做什么。我们还建立了一个邮件列表,以便在马拉松期间保持定期沟通,并支持任何在马拉松之外做出贡献的人。

当小组中有一两个带头组织活动的冠军时,我们的定期代码马拉松最成功。最好有多个冠军,以应对工作量,并在他们缺席一段时间时提供一些弹性。

我们努力确保开发环境的设置能够让人们快速加入并提高工作效率。这其中很多与我们在项目中为了实现持续集成而做的事情是一样的——确保安装和构建是自动化的,以便人们可以快速安装代码库并使其正常工作。在活动宣传中提及这一点很重要——人们往往会因为担心由于这些问题而无法开始而却步。即使如此,也要确保每次活动至少有一人熟悉代码库和构建环境,她可以帮助其他人找到自己的路。通常,有人会在马拉松开始时简要概述系统的工作原理以及如何为新人工作。

我们通常会为每次活动提供食物——这对我们来说是一项容易的企业贡献。正如任何XPer都知道的那样,在工作时分享食物是团队凝聚的重要组成部分。

所以,如果你对代码马拉松的想法感兴趣,为什么不试一试呢?找到一个合适的项目来贡献,一个由几个人组成的核心团队,花几节课来启动它。(如果你对这些项目感兴趣,OpenMRSRapidFTR都有开发人员指南来帮助你入门。)如果你能够稳定地进行下去——在某个博客上发布,这样我们就能看到哪些代码马拉松可用,并更多地了解如何启动它们。

进一步阅读

我的同事Jeff Wishnie长期以来一直参与这个领域,并解释了为什么黑客马拉松很糟糕(而且不必如此)

笔记

1: “代码马拉松”对于这些活动来说是一个有问题的名称。据我所知,术语“代码马拉松”最初用于竞赛性活动,程序员会在其中尝试在某种编程挑战中胜过同行。我在这里描述的活动与之完全相反,在许多层面上都是如此,但吸引了相同的名称。

2: 当团队中的一员前往我们的波尔图阿雷格里办公室时,他也让一个小组在那里做出了贡献。