慈善程式馬拉松

在過去幾年，我的幾位同事一直在組織程式馬拉松[1]活動，讓開發人員齊聚一堂，為慈善事業編寫軟體。一個很好的例子是紐約定期舉辦的程式馬拉松，專注於RapidFTR。紐約的 ThoughtWorker，Chris George，協助在 2010 年 8 月於紐約組織了一場一次性的活動。該小組當天並未如預期完成太多工作，但在隨後的酒吧聚會中，他們決定嘗試更定期地聚會。從那時起，他們每週都會見面。這是一個小團體，成員仍然主要是 ThoughtWorker 和朋友，核心成員約 3-4 人，當我們在城裡有大型專案時，人數會增加到十幾人[2]。(Chris 很樂意讓更多人加入這個團體，因此如果您有興趣，請寄電子郵給他。)

許多人發現這些活動是一種令人愉快的管道，可以將我們的技能用於我們認為比許多日常工作更有意義的目的，同時也是學習新技能和向不同群體學習的方式。因此，我認為我應該分享我們關於如何建立一個團體的想法。

首先是找到一個合適的專案來貢獻。我們希望為生產非政府組織開放原始碼軟體的專案做出貢獻，開放原始碼模型非常適合此類組織。我們建立最多關係的兩個專案是 RapidFTR 和 OpenMRS。 RapidFTR 是一個系統，旨在幫助家庭在自然災害或其他災難後團聚。它允許人們快速輸入有關失蹤兒童或未找到父母的兒童的資訊，然後提供搜尋功能來比對他們。 OpenMRS 是一個開放原始碼醫療記錄系統，旨在支援各種形式的醫療保健交付工作。它被世界各地的許多醫療保健團體使用（而不仅仅是在開發中國家）。

如同紐約，我們大多數的程式馬拉松一開始都是單次活動，單一夜晚或全天活動。這些日子以來，我們大力宣傳，並希望獲得當地開發人員的良好範例，讓他們前來參與。像這樣的單次程式馬拉松通常不會產生太多有用的軟體，因為它們太短暫，無法真正完成太多事情。但它們仍然有價值。首先，它們會產生意識，讓當地開發社群接觸到特定專案，以及為非政府組織從事開放原始碼工作的概念。更直接地說，它們可以成為定期程式馬拉松的種子，因此，將活動放在一起，鼓勵大家稍後再次聚會是有用的。

定期程式馬拉松會按照時間表聚會，由大多數週都會來的核心人物組成。這樣的團體可以對程式碼庫做出一些重大貢獻。人們會來，因為他們可以與不同的共同開發人員一起使用一些不同的技術，面對的受眾（與大多數開放原始碼專案不同）不只是其他開發人員。

為了取得有意義的進展，您需要有人為每次程式馬拉松做好準備，將工作項目細分成足夠小的部分，讓大家可以在馬拉松時間內完成它們。無論人們怎麼說和希望，他們很少會在程式馬拉松時間外從事專案，而時間表太不頻繁，無法讓未完成的事情懸而未決。小任務讓團隊可以在每次馬拉松中取得明顯的進展，這有助於保持高度的動機。我們喜歡在每次活動前將這些任務放在網路上，這樣人們就可以在有需要時做好準備，或者只是了解我們正在從事的工作。我們還建立了一個郵寄清單，以便在馬拉松中保持定期溝通，並支援在馬拉松外做出貢獻的任何人。

我們的定期程式馬拉松在團體有幾個帶頭組織活動的擁護者時最成功。最好有不止一位擁護者，以應付工作負擔，並在他們缺席一段時間時提供一些韌性。

我們試著確保開發環境的設定，讓大家可以快速加入並提高生產力。其中許多是我們在專案中會做的事情，無論如何，都是為了實現持續整合，確保安裝和建置是自動化的，因此大家可以快速安裝程式碼庫並讓它正常運作。在活動廣告中提到這一點很重要，因為人們往往會擔心由於這些問題而無法開始，因此會打消前來的念頭。即便如此，請確保每次活動至少有一個人熟悉程式碼庫和建置環境，然後她可以幫助其他人找到方法。通常，有人會在馬拉松開始時，對系統的功能和運作方式提供簡短的概述，說明給新人聽。

我們通常會為每次活動提供食物，這對我們來說很容易做到，作為企業貢獻。正如任何 XPer 所知，在工作時分享食物是凝聚團隊的重要一環。

因此，如果您對程式碼快閃活動有興趣，何不試試看？找一個合適的專案來貢獻，找幾個志同道合的人組成核心小組，花幾個時段讓事情動起來。（如果您對這些專案有興趣，有針對 OpenMRS 和 RapidFTR 的開發人員指南，可以協助您入門。）如果您持續進行，請在某個部落格中發文，讓我們知道有哪些程式碼快閃活動可用，並進一步了解如何讓它們持續進行。