如何貢獻：詳細列出貢獻的規(guī)則。如果你需要人進行單元測試，那么寫上去。如果你需要人編寫文檔，那么也寫上去。給出一個檢查表，這樣大家在提交貢獻之前可以先逐項檢查一下。
在與貢獻者們的交流基礎上，同時也參考了其它人問的一些問題，我花了許多時間來完善CSS Lint的開發(fā)者指南。我認為，開發(fā)者指南與其它文檔一樣，應當是一個活躍的文檔，它應當隨著項目的成長而不斷成長。
郵件列表的使用
所有的開源項目都會給出一個地方，讓大家提問。簡單的方法是設置一個郵件列表。當我們剛啟動CSS Lint時，Nicole和我很快被各種問題淹沒了。比較麻煩的是，這些問題來自各種渠道。有些人在Twitter上問，有些人直接給我倆寫信。你不會想要面對這種局面吧。
利用Yahoo Groups和Google Groups設置郵件列表很容易，而且免費。在宣布項目上線之前，記得先設好郵件列表吧，然后主動鼓勵大家用郵件列表來提問。不要忘了在你的網(wǎng)站上和文檔里放上郵件列表的鏈接。
運營郵件列表的另外一個重要環(huán)節(jié)是對其進行積極地關注。對于用戶或開發(fā)者來說，沒有什么比自己被忽略更加令人沮喪了。如果你設置了一個郵件列表，花一些時間關注它，并 為那些提問的人作出答復。這是圍繞一個項目培育出開發(fā)者社區(qū)的佳手段。讓一個郵件列表達到像樣的活躍度是一件比較費時的事，然而這是值得的。為有意向作出貢獻的人提供建議、建議人們在適當?shù)臅r候提交成果(不要讓你的郵件列表變成bug追蹤工具!)、并且利用你從郵件列表中獲得的反饋來提升文檔的質(zhì)量。
使用版本號
開放源代碼項目的一個常見的錯誤是忽視使用版本號。版本號對項目的長期穩(wěn)定和維護時相當重要的。CSS Lint首次發(fā)布時沒時使用版本號，我很快意識到錯誤。當有bug提交時，我不知道人們是否正在使用新的版本，因為沒有辦法告訴用戶代碼是何時發(fā)布的，雖然提交的bug已經(jīng)修復但用戶無從知曉。
將每個發(fā)布的版本用官方的版本號來標記，當有人提交bug時，你可以詢問他們使用的版本并檢查bug是否已經(jīng)修補。這大大縮短了我花在報告bug 上的時間因為我可以馬上知道用戶是否在使用新版本。
除非你的項目以前有過使用并已經(jīng)通過審核， 否則以0.1.0位啟動版本號并遞增每個后續(xù)發(fā)布的版本。在 With CSS Lint中我們增加了第二個數(shù)字在作為計劃版本號，因此，0.2.0便是第二個計劃版本號，0.3.0是第三個以此類推。如果我們?yōu)榱诵扪abug而需要發(fā)布一個介于兩個計劃版本之間的版本，我們需要增加第三個數(shù)字。因此在第二個計劃版本0.2.0之后的非計劃釋出本版號為0.2.2.
不要誤解。這里并沒有什么規(guī)則來規(guī)定在一個項目中如何增加版本號，盡管這里有些值得參考的東西 Apache APR Versioning and Semantic Versioning. 我只是挑出來一些并遵循罷了。
除了對項目跟蹤的幫助，版本號當然還可以為你的項目做一些其他的事情。
源碼控制中的標記版本
當你決定要發(fā)布一個新版本時，應用源碼控制標記來標注此版本的代碼狀態(tài)。當我們開始在CSS Lint中使用版本號，我也開始這么做了。開始我沒考慮那么多，直到有一次我忘了給一個發(fā)布版添加標記，但是發(fā)現(xiàn)某位開發(fā)者提交的bug卻是針對那個特定標記的。這說明開發(fā)者們更傾向于檢出特定版本的代碼。
要讓標記和版本號的綁定關系更明確，把版本號直接包含在標記名稱中。在CSS Lint中，我們的標記都使用“v0.9.9”這種格式。這樣可以讓每個人都能夠很容易地通過標記名稱來識別其含義 — 包括你自己，因為你也將能夠更好地跟蹤每次版本發(fā)布的改動。
變更日志
版本管理還有一個好處是能夠生成變更日志。不管是對終用戶和貢獻者，變更日志都是溝通版本差異時的重要依據(jù)。版本標記和源碼控制有一個附加好處，你能基于這些標記自動生成變更日志。CSS Lint的構(gòu)建系統(tǒng)能夠在每次發(fā)布是自動生成一個包含提交信息及其貢獻者的變更日志。這樣變更日志不僅只是一個代碼變更記錄，也是社區(qū)貢獻值的記錄。
可用宣告
每當項目發(fā)布一個新版本時，都應該在某處發(fā)布宣告。不論是在你的博客或郵件列表或是在兩者上都發(fā)布，正式宣告項目新版本已經(jīng)可用是非常重要的。這份宣告應該包括項目代碼的主要改動及其貢獻者。對貢獻者工作的認同是對他們的大鼓勵，能從貢獻代碼中獲得更多的認同感他們更有動力做更多的貢獻。所以給予那些耗費無數(shù)精力在你的項目中的開發(fā)者以大的贊揚吧。
管理代碼貢獻
萬事俱備，下一步是解決如何接受代碼貢獻。 你的貢獻模型是非常規(guī)范還是很隨意，取決于你的喜好和目標。對應個人項目，可能不需要什么規(guī)范的貢獻流程。開發(fā)者指南應該說明合并代碼到倉庫的必要條件，一個提交先要滿足這些條件才會被接受。對于更大的項目，應該要有更多規(guī)范的策略。
首先要考慮的是是否需要一個貢獻者許可協(xié)議(CLA)。CLA在很多大型開源項目中使用以保護項目的合法權(quán)利。每位提交代碼的開發(fā)者都需要同意CLA，以承諾任何貢獻的代碼都是原創(chuàng)的同時將代碼的版權(quán)移交給項目所有。CLA也賦予項目所有者將貢獻的代碼作為項目一部分的授權(quán)，而且要求貢獻者保證不會故意將他人具有版權(quán)、專利或其他權(quán)利的代碼包含在自己的代碼中進行提交。jQuery， YUI 和 Dojo 在代碼提交時都要求貢獻者同意CLA。如果你正在考慮使用CLA，那么尋求一些法律咨詢是很值得的。
接下來，你可能想要為項目的工作人員建立一個權(quán)限層次。開源項目一般都會設置三個主要的角色：
貢獻者
任何對項目做過代碼貢獻的人都可以算作貢獻者。貢獻者不能直接訪問代碼倉庫，但是提交的補丁可以被接受。
提交者
提交者有權(quán)限直接訪問代碼倉庫。他們經(jīng)常對項目做特性添加和bug修正，也能夠直接提交代碼到代碼倉庫。
審查者
審查者是更高一級的貢獻者，是能夠?qū)椖慨a(chǎn)生直接影響的指揮官。他們的職責是審查貢獻者和提交者提交的代碼，批準或者否決補丁，任命或者撤銷提交者稱號，總的來說是運作這個項目。
如果你打算采用剛才所說的權(quán)限層次，那么接下來需要起草一份文檔來描述每種類型的貢獻者的角色和貢獻者角色如何通過排名來進行提升。YUI近創(chuàng)建了一個很正式的“貢獻者模型”，有很的文檔來描述角色和職責。
目前CSS Lint沒有CLA，也沒有正式的貢獻者模型，但是每個人都應該在自己的開源項目成長過程中認真考慮這件事。
證明
從CSS Lint第一次發(fā)布到形成一個全功能的開源項目大概花了我們差不多6個月時間。從那時開始，超過一打的貢獻者提交的代碼被接受。盡管這個數(shù)字按照一個大型開源項目的標準來說有點少，但我們?nèi)匀粚Υ烁械津湴�。獲得一次外部貢獻很容易，在很長一段時間內(nèi)都能持續(xù)獲得幫助可不容易。
而且我們明白自己做的所有努力都是正確的，原因是收到的積極反饋。喬納森·克萊因近到項目的郵件列表里問了幾個問題，在后他也提交了一個pull request并被項目接受了。接著他給我發(fā)了一封反饋郵件：
我想說CSS Lint是開源項目的典范-文檔，擴展方便，代碼簡潔，反饋及時，定制方便。基于CSS Lint做開發(fā)像閱讀wiki一樣容易，而且事實上你提出的特有更改工作流使得項目的進入門檻變得很低。我希望有更多的開源項目能照著做，讓開發(fā)者為其做共享更容易。
對CSS Lint來說收到這樣的郵件已經(jīng)是司空見慣的事了。如果你愿意花點時間為自己的項目建立一個可持續(xù)發(fā)展的生態(tài)系統(tǒng)，這種事在你的項目里也一樣會成為常態(tài)。每個人都希望自己的項目能成功，都希望有大量的開發(fā)者來做貢獻。但是像喬納森說的一樣：盡量降低門檻，開發(fā)者們自然會找到方法來幫忙的。
