寫在前面
因為機緣巧合參加了Github中國的第一次用戶活動，所以最近有參與一些開源項目的外圍維護赋除。簡單來說就是去issues 區(qū)域解答初級用戶的問題，以及盡可能的提出Pull Request。就我這兩周對一兩個開源項目的觀察涩维，更多地發(fā)現(xiàn)了一些共有的社區(qū)問題，希望可以拿出來探討下宛篇。
社區(qū)特點
拿百度之前捐給Apache 基金會的Echarts 項目為例娃磺，功能很強大，用戶特別多叫倍，僅僅是used by 就有接近5w 個偷卧，fork 有1.1w個，這充分說明Echarts 庫起步早吆倦，用戶多听诸。
但是從開源社區(qū)用戶特點講蚕泽，有幾點：
- 中國用戶多晌梨，issue 多為中文
- issue 中許多問題在文檔中有描述桥嗤，有效issue不占多數(shù)
- 貢獻者多為國內(nèi)開發(fā)者
這幾個特征其實也是很多國內(nèi)開源項目共有的。這直接導(dǎo)致國內(nèi)開源項目維護的難題：
- issue 中文多仔蝌，國外開發(fā)者難以提供幫助泛领，項目生態(tài)很難在國外推廣
- issue 質(zhì)量不高，項目維護需要更多人力
- 維護者缺乏多樣性敛惊，穩(wěn)定性
現(xiàn)狀和思考
由于我偶爾會到issue區(qū)逛逛渊鞋，順便解答一些力所能及的簡單問題，也偶爾看看郵件列表瞧挤，了解到這類項目維護的一些現(xiàn)狀锡宋。其實從Github 項目的 Insight 中，也可以窺探出一些總體趨勢特恬。
例如最近一個月的代碼改動狀況执俩，貢獻人數(shù)，PR 的merge鸵鸥、open情況奠滑，多少個issues 被open 和close 了。能看出來妒穴，最近一個月宋税，項目的維護效率算是比較高的，issue被處理的速度遠超open 的速度讼油。PR也是同樣杰赛，大部分都快速review 和merge 到主分支了。
相比之下矮台，ElementUI 項目似乎歷史總體貢獻者更多（接近500個）乏屯，但最近PR的處理速率更慢些（核心member 似乎不夠用，而PR 太多）
普遍的瘦赫，都有現(xiàn)存issues量很大的問題辰晕，還有一些現(xiàn)象值得思考。
重復(fù)工作量
我在處理一個issue 中與維護人員多次交互确虱，最后提了PR含友，但在查閱之前的 PR list 時，發(fā)現(xiàn)還有個類似的fix 沒有被merge校辩，是針對另外一個重復(fù)issue 的窘问。這導(dǎo)致我的工作似乎是重復(fù)了。宜咒。但這個問題經(jīng)過幾天的討論并沒有被維護人員標(biāo)記為duplicate惠赫，這使得工作量實際上是被浪費了。
不必要的需求
部分被用戶提出的new feature故黑，或者enhance 實際上優(yōu)先級不高儿咱，或者完全沒必要庭砍。這類feature，也許會占據(jù)開發(fā)者許多時間去實現(xiàn)或者對于功能穩(wěn)定性 risk 較高概疆。實際上需要更多的內(nèi)部投票逗威，討論去決定最終的方案，做還是不做岔冀，怎么做的問題凯旭。
這其實是個需求砍殺的問題，我在之前關(guān)于敏捷開發(fā)的文章中有提到過使套，合理的需求控制可以較好地讓團隊關(guān)注正在做的事情罐呼。
規(guī)范的樹立
我始終認(rèn)為，維護團隊?wèi)?yīng)該有自己的個性和強勢理念侦高。關(guān)于低質(zhì)量issue嫉柴，沒有reproduce link 的issue 應(yīng)該設(shè)定嚴(yán)格的超期時限，自動關(guān)閉奉呛，以減少對于團隊精力的消耗计螺。
作為一個致力于國際化推廣的項目，可以考慮以下幾點：
- 關(guān)閉中文issue的設(shè)定瞧壮，自動化管理issue
- 盡快處理PR登馒，標(biāo)注重復(fù)issue
- 對issue進行難度評級，優(yōu)先級評定咆槽，有利于招募貢獻者
- 更清晰的 RoadMap陈轿，有利于招募貢獻者
