模板
教程
環境
性能
功能
管理
如何開始一個新的開源項目(3)
lhyhb
翻譯于 7天前
0人頂
頂 翻譯的不錯哦!
對于CSS Lint, 我們選用了一個基本的 頂層目錄結構: src 用于主源代碼, lib 用于外部依賴, test 用于測試代碼。 src目錄進一步分為子目錄, 分類相關的文件。 所有的CSS Lint規則都在 rules 子目錄; 所有的輸出格式化都在 formatters 目錄等等。 test目錄劃分子目錄與src目錄相同, 這樣可以標示測試代碼和主代碼的關系。 隨著時間過去, 我們因為需要已經添加了頂層目錄, 但基本結構和開始做的是一樣的。
AlfredCheung
翻譯于 8天前
0人頂
頂 翻譯的不錯哦!
文檔
很多對開源項目的抱怨是由于缺乏文檔。寫文檔往往沒有寫程序來得有趣，但對于開源項目成功卻至關重要。如果你不想要別人使用你的軟件，不想要人們貢獻代碼，那么只要不提供文檔就行了。我們的CSS Lint一開始就犯了這個錯誤。項目剛啟動時，我們沒有提供文檔，結果大家都不知道怎么用這個東西。不要重蹈我們的覆轍，在啟動項目之前，一定要做好文檔的工作。
AlfredCheung
翻譯于 8天前
0人頂
頂 翻譯的不錯哦!
文檔應該很容易被更新，而且不需要push代碼就可以更新，必須能根據用戶的反饋快速地修改。也就是說，不要把文檔與代碼放在一個倉庫里。如果你把代碼放在GitHub上，那么可以用GitHub內置的wiki來放文檔。我們的CSS Lint就是把文檔放在wiki上。如果你的代碼不是放在GitHub上，那么可以用自己的wiki或其它類似的系統來放文檔，以便實時地更新它們。好的文檔系統應該是很容易更新的，否則你可能永遠都不會去更新它們。
AlfredCheung
翻譯于 8天前
0人頂
頂 翻譯的不錯哦!
最終用戶文檔
無論你寫的是命令行程序、應用框架、工具庫還是其它什么東東，都要把最終用戶深深地放在腦海里。最終用戶并不是修改你代碼的人，而是使用你代碼的人。拿我們的CSS Lint來說，大家一開始不知道怎么用，因為我們沒有給出最終用戶文檔。爭取不到最終用戶，也就爭取不到貢獻者。對你的代碼滿意的最終用戶們最后會成為貢獻者，因為他們看到了蘊含在代碼中的價值。
AlfredCheung
翻譯于 8天前
0人頂
頂 翻譯的不錯哦!
開發者指南
即時你的代碼布局合理，文檔豐富，也無法保證一定會有貢獻者出現。你需要一份開發者指南，讓那些貢獻者們快速融入進來。一份好的開發者指南應該有下面這些內容：
如何獲取源代碼：你當然希望貢獻者們都知道怎么check out代碼，但世事無絕對。一份友好的介紹總是受人歡迎的。
代碼是如何組織的：即使你的代碼和目錄結構很清晰，完全能自我說明，也最好寫下來，總有用處的。
如何設置構建系統：如果你用了某種構建系統，那么應該提供一份怎么設置這個系統的說明。如果構建時的一些依賴項沒有包含在你的倉庫中，那么這份說明中還應該包括怎么獲取這些依賴項的信息。
如何構建：如何進行構建以及單元測試的步驟。
如何貢獻：詳細列出貢獻的規則。如果你需要人進行單元測試，那么寫上去。如果你需要人編寫文檔，那么也寫上去。給出一個檢查表，這樣大家在提交貢獻之前可以先逐項檢查一下。
AlfredCheung
翻譯于 8天前
0人頂
頂 翻譯的不錯哦!
在與貢獻者們的交流基礎上，同時也參考了其它人問的一些問題，我花了許多時間來完善CSS Lint的開發者指南。我認為，開發者指南與其它文檔一樣，應當是一個活躍的文檔，它應當隨著項目的成長而不斷成長。
AlfredCheung
翻譯于 8天前
0人頂
頂 翻譯的不錯哦!
郵件列表的使用
所有優秀的開源項目都會給出一個地方，讓大家提問。最簡單的方法是設置一個郵件列表。當我們剛啟動CSS Lint時，Nicole和我很快被各種問題淹沒了。比較麻煩的是，這些問題來自各種渠道。有些人在Twitter上問，有些人直接給我倆寫信。你絕對不會想要面對這種局面吧。
AlfredCheung
翻譯于 8天前
0人頂
頂 翻譯的不錯哦!
利用Yahoo Groups和Google Groups設置郵件列表很容易，而且免費。在宣布項目上線之前，記得先設好郵件列表吧，然后主動鼓勵大家用郵件列表來提問。不要忘了在你的網站上和文檔里放上郵件列表的鏈接。
原文轉自：http://www.anti-gravitydesign.com
