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