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