...
下面的指南主要是協助貢獻者和提交者與整個社群一同工作 :
| Tip |
|---|
|
- 請依循 寫碼慣例 (英)。 請認真閱讀此份文件。
- 裝妥 OFBIZ Subversion 的 客戶端設置檔案
- 提交者請遵循底下兩個主要準則:
- 規則 #1 提交者要像醫師一樣: 首先不造成傷害. 不論在提交前或提交後, 如果會使得已有功能發生問題, 就不要進行提交。無論是和誰一起開發, 或者有人也許是很多人有機會用到它。
- 規則 #2 提交者要像科學家一樣: 先讀再寫. 剛開始入門, 讀和寫的時間比大約是 20:1, 當成為 OFBiz 專家通曉關於專案內外的大小事, 或許可把比例降到 3:1。
- 和社群討論你要的功能。說說打算實作什麼, 以及打算怎麼做? 如果你是這專案的新手, 會是很重要的事。
- 撰寫清楚, 良好的意見, 以及能被瞭解的程式碼。不要採取捷徑, 特別是對於變數名稱, 和錯誤或警告訊息的處理。使用能被瞭解的資料結構。請牢記, 日後有某個人會和你的程式碼相處, 讓他能好好相處。
- 準備一個修補檔案(patch)時, 儘可能避免在相關變更混入格式的變更 (可能的話, 把格式變更獨立出來): 這樣的話, 審核者會較容易著手處理。
- 準備一個修補檔案(patch)時, 請不要在程式碼加入作者資訊, 你的大名會載明在提交紀錄擋 (這是我們保存相關資訊的地方)
- 程式碼請使用 UI 標籤做國際化
- 從小規模貢獻開始, 以便於審核處理。在過程中, 藉此熟悉這個專案的程式碼風格, 以及 "思考方式"。
- 保持讓修補檔案和貢獻容易被審核與提交。雖然大量的程式碼很讓人感動, 但請維持事務的獨立, 以及修補檔案意圖的清晰。請瞭解到大部份的提交者可花 20 分鐘做些額外的瑣事, 但一次要費個 2 到 4 小時來做審核, 及提交一個巨大的修捕檔案就有些困難 (特別是牽涉到任何低階, 或較為敏感, 或較為複雜的東西, 這都需要投入更多的審核)。
如果修補檔案有點複雜的話, 請提供提交者足夠的資訊以進行測試 - 像是實際進行的步驟, 用來測試
- 如果有網址(URL), 會很有幫助
- 把貢獻放到 JIRA, 不要直接寄給提交者, 這樣每個人都可以審核, 以及提供意見。儘管不是必要的, 但透過這種方式可讓貢獻授權給 Apache 軟體基金會, 並可被追蹤。
- 讓更多社群成員試用你提供的修補檔案。寫到 開發論壇 告知所完成的事情, 請大家來試看看, 並支持這項修補。這有助於提交者審核時, 對修補檔案具備更多的信心 ... 瞭解嘗試要做的目標, 也知曉它不破壞任何東西。
|
...
將會看到這種樣式在一些地方使用。這方式是使用者所期待的, 便於從 OFBiz 的一個版本升級到另一個版本。
| Wiki Markup |
|---|
{center}*停用實體: 更多資訊在 [這裡|OFBTECH:General Entity Overview#DeprecatedEntities]*{center} |
如何發送貢獻 (或如何建立與使用修補檔案)
首先是為自己在 JIRA 事例追蹤服務 建立一個帳號, 然後才建立一個新的事例。描述貢獻做了什麼: 是修正一個錯誤, 改進一項既有功能, 或者建立一個新的功能? 請儘可能詳細描述, 也可能附帶螢幕截圖, 如果可以展示成果的話。OFBiz 是個巨大的專案, 對你來說很直覺的, 對其他人則不一定, 即使像是提交者熟悉這個專案也會如此。
...
當 Jira 事例已完全解決, 我們會關閉事例, 而不是標示已解決。有些情況是, 雖然有暫時的方案, 但故意不 關閉 事例, 因為想獲得更多回報, 或是其他人來審核, 測試, 修正。如果是簡單的事例, 特別是本身就做好回報, 最好的方式就是逕行 關閉, 而不是之後再做 關閉。
為什麼我的修補檔案併入 OFBiz 要花那麼長的時間?
...