開源項目流程文檔化

對于一個項目的維護(hù)者來說寫文檔是最重要的事情之一。

文檔不僅說清楚了你的想法是什么，而且還幫助別人在問問題之前理解你需要什么和接下在希望做什么。

將一些東西寫下來，當(dāng)遇到不符合項目預(yù)期的內(nèi)容時，可以輕松的拒絕。同時，它對于人們的參與和提供幫助提供了指導(dǎo)。最有意思的是，撰寫文檔的人可能永遠(yuǎn)也不知道是誰讀了他寫的文檔，或者使用項目。

即使你不想長篇大論，對要點(diǎn)略說一二也比啥都不寫要好。

寫下你的項目的發(fā)展方向

請在項目啟動時就寫下項目目標(biāo)，并將之加到 README 文件中， 或者創(chuàng)建一個單獨(dú)的 VISION 文件，其它還能幫助人們了解這方面的信息如項目管理路線圖，最好是也把他們公開。

有一個明確的，用文檔表達(dá)清晰的愿景，能保證項目的走向不會跑偏，同時也能保障因為其他的貢獻(xiàn)者增加的奇怪的需求而使項目變質(zhì)。

比如，@lord 發(fā)現(xiàn)項目有一個明確的愿景能夠幫助他決定哪個 PR 值得花時間。作為一個維護(hù)者的新手，他甚至還后悔當(dāng)他接到第一個關(guān)于 slate ) PR 的時候沒有堅持項目本身的原則。

我一直都在摸索。我沒有努力尋求一個完整的解決方案。與其采用那種半吊子辦法，我真希望曾經(jīng)對某些 Issue 的提出者說：”我暫時沒有時間干這個，但是我會把他放到我的待辦事項中”。

— @lord , “開源項目維護(hù)者新手的幾點(diǎn)技巧”

和大家交流你自己對項目的期望

制定規(guī)則是很傷腦筋的。有時候你可能覺得你像是在限制別人的行為或者說把好玩的東西都搞沒了。

制定了規(guī)則，然后嚴(yán)格執(zhí)行，當(dāng)然啦，好的規(guī)則會讓維護(hù)者更輕松。他們會把你從做自己不愿意做的事情中解脫出來。

大多數(shù)知道你項目的人對你或者你的處境都是一無所知。他們可能會覺得你做這個項目是有錢拿的，特別是你的項目是他們經(jīng)常用的而且某種程度上有點(diǎn)依賴的時候。其實你只是在有時候會在項目上花很多時間，但是現(xiàn)在你在忙于新工作或者照顧剛出生的兒子。

這些都是再正常不過的事情！所以確保讓別人也知道這些。

如果你維護(hù)某個項目是利用空閑時間或者完全自愿的，能花多少時間就花多少時間。而不是你覺得項目需要你花多少時間或者別人想讓你花多少時間。

這里是一些值得你寫進(jìn)項目里的東西：

• 怎樣的貢獻(xiàn)才會被復(fù)查和接受（需要測試嗎？提 Issue 有模板嗎？）
• 你本人會接受什么類型的貢獻(xiàn)？（你是不是只希望在某些部分的代碼上需要別人的幫助？）
• 在合適的時候跟進(jìn)項目（比如說 如果你在七天之內(nèi)沒有收到 maintainer 的回復(fù)，而且依舊沒有其它任何的響應(yīng)，那么就直接找 Ta。）
• 你會在這個項目上花多少時間（比如說 “我們每星期只會在這個項目上花5個小時“）

Jekyll 、CocoaPods 、以及 Homebrew 均是為維護(hù)者和貢獻(xiàn)者提供了很好的基本規(guī)則的項目，乃業(yè)內(nèi)典范。

保證交流是公開進(jìn)行的

不管是什么時候，保證你的交流是在公共的場所（就是大家都能看到的地方）。如果有人嘗試和你私聊，哪怕是討論一個新的需求或者功能，請禮貌的引導(dǎo) Ta 到公共的交流場所，比如郵件列表或者 issue tracker。

如果你和別的維護(hù)者見面了，或者在私下做了一個很重要的決定，把這些信息告訴大家，即使只是把你的筆記發(fā)上去。

這樣的話，每個人新加入到你們社區(qū)的人和已經(jīng)呆了多年的人能夠了解到的信息是一樣的。