開源項目管理當中最為常見的十類糟糕實踐

本次于奧斯汀召開的openstack峰會成為大家交換開源項目管理經驗的絕佳平台。事實證明，在經曆了多年的社群參與及項目貢獻工作之後，我對這方面事務還是有點兒發言權的。

不過，在今天的文章中，我打算以反面視角解讀這一議題，即讨論開源項目管理當中不可取的種種作法。

　　1.給貢獻者們增添煩惱

軟體的開發者與維護者已經很忙了，是以過量的任務配置設定隻會令人更加反感。事實上，開源領域最大的誤解之一就是，管理者往往以為鋪天蓋地的工作能夠增加成員的參與感。這裡說得直白一點，任務太多的話人家可能幹脆就走人了。

我有位好朋友自2013年開始，就一直在為ceilometer做出貢獻。他的代碼審查水準相當高，甚至能發現許多旁人意識不到的錯誤。項目管理團隊最終讓他晉升為核心審查員——而非單純交給他更多任務。相信我，正是這種成就感讓更多水準超群的技術人員繼續留在項目當中。

2.隻讓人們參與枯燥的工作

在新人加入時，他們的動機往往不盡相同。部分使用者希望通過貢獻實作自身價值，也有些人是抱着學習的目的。但一般來說，人們其實比較抗拒始終接觸最低級的枯燥工作。如果管理者對于底層貢獻者的感受毫不關心，那麼無聊的内容再結合上一條提到的工作強度，肯定會讓很多有志于開源的朋友迅速撤離。

3.不重視點滴貢獻

改個錯字也能算貢獻?重新捋順說明文檔也能算貢獻?這種心态在開源項目中并不罕見，但事實證明這類工作其實同樣具有重要價值。

我個人就曾經在某個項目中負責修複文檔錯誤，并在短時間之内釋出了56項更新檔、修正了部分bug并添加了些額外的功能。沒人因為這些都是小事而看輕我，我也相信自己的工作确實擁有其價值。

4.為新人們設定過高的門檻

新人在參與開源項目時，其個人技術水準與從業經曆往往千差萬别。而很多管理者則直接給他們設定太過複雜的任務，這會讓很多人遭遇挫折感，甚至覺得自己太笨而默默退出。

事實上，我們應當對新人進行技術水準評估(簡單的交流應該能大緻摸清其程度)，而後再為其配置設定力所能及但又有些挑戰的工作。

5.要求人們犧牲自己的個人生活

大多數參與者隻會拿出空閑時間進行開源貢獻，這也是種非常健康的發展方式。請注意，不要指望項目成員犧牲個人生活進行貢獻，那樣既不現實也不利于項目的長期發展。

另外，過于頻繁的視訊會議乃至irc會議也會讓人感到厭煩。開源項目應當以人為本，并針對不同成員采取不同的交流及貢獻方式。

6.潛在的行為準則太難融入

随着社群的發展，總會有種潛在的風格或者行事方式成為其個性标簽。雖然這能讓老鳥們樂在其中，但卻也可能讓新人們望而卻步。

誠然，我們沒必要就行為規範整理什麼說明指南。但作為項目管理者，大家最好是能讓團隊在保持個性的同時，充分考慮新人的感受。有事沒事抛出一大堆内部用語或者“梗”，除了妨礙組織規模進一步擴大外真的沒什麼好處。

7.讓非英語為母語的發言者感到毫無參與感

絕大多數開源項目社群會以英語進行交流，而這也成為大家協作的重要前提。然而，我們也應該考慮到部分技術人員來自非英語為母語的國家，這意味着他們可能很難與原有成員順暢溝通，甚至是以受到打擊。

面對這種方式，我們可以想想其他的辦法進行替代。例如采用異步溝通方式，以文本為載體發送交流内容。如此一來，對方即可借助翻譯軟體大緻了解其中的含義，同時也避免了開口說外語所帶來的緊張感。

8.缺乏遠見，不願放權

這兩項錯誤常見于各類開源項目。事實上，部分貢獻者在加入後會開發新功能并向原有成員尋求回報意見，這時負責維護的管理者可能意識到自己并不熟悉這部分技術，甚至是以決定退出。必須強調的是，項目的發展願景與圍繞這一點展開的溝通非常重要，這樣我們才能讓各位成員擁有相同的判斷并了解是否應當留在隊伍裡發揮作用。

另外，就是應當将部分職責放心交給其他成員，而非全部由自己掌控。更新檔審查、子系統設計、錯誤修正以及文檔編寫等都可以由專人負責。通過這種方式，每位成員都能感受到自己的作用與價值，并更為積極地留在項目團隊當中。

9.不承認貢獻者們的成績

為開源項目做出貢獻的方式多種多樣，絕不限于編寫代碼。說明文檔、bug調試、使用者支援、體驗設計、傳播乃至翻譯等等，這一切都是非常重要的工作。

是以，我們應當對非技術貢獻予以充分的重視，并在建立團隊成員階層時小心再小心，以免遺漏了任何一類人才。

10.缺少感恩的心态

作為結尾，我要強調開源項目中感恩心态的重要性。這類項目往往是由參與者無償建構而成的，作為管理者我們要為每個人的分享精神喝彩——當然，要用能讓他們直覺感受到的方式!

====================================分割線================================

本文轉自d1net（轉載）