原始英文網頁: OFBiz Contributors Best Practices
為什麼該貢獻 OFBiz
透過改進貢獻回饋給 OFBiz, 將可獲得整個開發者與使用者社群協助除錯, 加強, 或者拓展你業務所需要的功能。此外, 假如此貢獻有利於 OFBiz, 日後會吸引更多使用者與開發者加入 OFBiz, 最終那些使用者與開發者做出貢獻的話, 又有利於你。最後, 貢獻這個專案的過程是新的使用者與開發者用來參與原有社群的方式, 並能學習更多關於 OFBiz, 發掘更多功能和彈性。
...
如果是一位經常的貢獻者, 而且可幫助此專案長遠發展的話, 就可能變成一個 專案提交者 (英)。
下面的指南主要是協助貢獻者和提交者與整個社群一同工作 :
| Tip |
|---|
|
- 請依循 寫碼慣例 (英)。 請認真閱讀此份文件。
- 裝妥 OFBIZ Subversion 的 客戶端設置檔案
- 提交者請遵循底下兩個主要準則:
- 規則 #1 提交者要像醫師一樣: 首先不造成傷害. 不論在提交前或提交後, 如果會使得已有功能發生問題, 就不要進行提交。無論是和誰一起開發, 或者有人也許是很多人有機會用到它。
- 規則 #2 提交者要像科學家一樣: 先讀再寫. 剛開始入門, 讀和寫的時間比大約是 20:1, 當成為 OFBiz 專家通曉關於專案內外的大小事, 或許可把比例降到 3:1。
- 和社群討論你要的功能。說說打算實作什麼, 以及打算怎麼做? 如果你是這專案的新手, 會是很重要的事。
- 撰寫清楚, 良好的意見, 以及能被瞭解的程式碼。不要採取捷徑, 特別是對於變數名稱, 和錯誤或警告訊息的處理。使用能被瞭解的資料結構。請牢記, 日後有某個人會和你的程式碼相處, 讓他能好好相處。
- 準備一個修補檔案(patch)時, 儘可能避免在相關變更混入格式的變更 (可能的話, 把格式變更獨立出來): 這樣的話, 審核者會較容易著手處理。
- 準備一個修補檔案(patch)時, 請不要在程式碼加入作者資訊, 你的大名會載明在提交紀錄擋 (這是我們保存相關資訊的地方)
- 程式碼請使用 UI 標籤做國際化
- 從小規模貢獻開始, 以便於審核處理。在過程中, 藉此熟悉這個專案的程式碼風格, 以及 "思考方式"。
- 保持讓修補檔案和貢獻容易被審核與提交。雖然大量的程式碼很讓人感動, 但請維持事務的獨立, 以及修補檔案意圖的清晰。請瞭解到大部份的提交者可花 20 分鐘做些額外的瑣事, 但一次要費個 2 到 4 小時來做審核, 及提交一個巨大的修捕檔案就有些困難 (特別是牽涉到任何低階, 或較為敏感, 或較為複雜的東西, 這都需要投入更多的審核)。
如果修補檔案有點複雜的話, 請提供提交者足夠的資訊以進行測試 - 像是實際進行的步驟, 用來測試
- 如果有網址(URL), 會很有幫助
- 把貢獻放到 JIRA, 不要直接寄給提交者, 這樣每個人都可以審核, 以及提供意見。儘管不是必要的, 但透過這種方式可讓貢獻授權給 Apache 軟體基金會, 並可被追蹤。
- 讓更多社群成員試用你提供的修補檔案。寫到 開發論壇 告知所完成的事情, 請大家來試看看, 並支持這項修補。這有助於提交者審核時, 對修補檔案具備更多的信心 ... 瞭解嘗試要做的目標, 也知曉它不破壞任何東西。
|
...
做為一名提交者, 可提供你的顧主及客戶很大的助益, 也能成為個人或職涯上很大的資產。可保證在參與活動過程中, 會獲得學習與成長。將會學習到如何建立企業應用系統, 無論是技術與商務的這兩方面。也將學習到如何和其他人協同工作, 特別是和遠方的人一起工作的方式。
更多詳細資訊以及開始進行的說明, 請參考 提交者角色與責任 頁面。