...
| Tip |
|---|
|
- 請依循 寫碼慣例 (英)。 請認真閱讀此份文件。
- 裝妥 OFBIZ Subversion 的 客戶端設置檔案
- 提交者請遵循底下兩個主要準則:
- 規則 #1 提交者要像醫師一樣: 首先不造成傷害. 不論在提交前或提交後, 如果會使得已有功能發生問題, 就不要進行提交。無論是和誰一起開發, 或者有人也許是很多人有機會用到它。
- 規則 #2 提交者要像科學家一樣: 先讀再寫. 剛開始入門, 讀和寫的時間比大約是 20:1, 當成為 OFBiz 專家通曉關於專案內外的大小事, 或許可把比例降到 3:1。
- 和社群討論你要的功能。說說打算實作什麼, 以及打算怎麼做? 如果你是這專案的新手, 會是很重要的事。
- 撰寫清楚, 良好的意見, 以及能被瞭解的程式碼。不要採取捷徑, 特別是對於變數名稱, 和錯誤或警告訊息的處理。使用能被瞭解的資料結構。請牢記, 日後有某個人會和你的程式碼相處, 讓他能好好相處。
- 準備一個修補檔案(patch)時, 儘可能避免在相關變更混入格式的變更 (可能的話, 把格式變更獨立出來): 這樣的話, 審核者會較容易著手處理。
- 準備一個修補檔案(patch)時, 請不要在程式碼加入作者資訊, 你的大名會載明在提交紀錄擋 (這是我們保存相關資訊的地方)
- 程式碼請使用 UI 標籤做國際化
- 從小規模貢獻開始, 以便於審核處理。在過程中, 藉此熟悉這個專案的程式碼風格, 以及 "思考方式"。
- 保持讓修補檔案和貢獻容易被審核與提交。雖然大量的程式碼很讓人感動, 但請維持事務的獨立, 以及修補檔案意圖的清晰。請瞭解到大部份的提交者可花 20 分鐘做些額外的瑣事, 但一次要費個 2 到 4 小時來做審核, 及提交一個巨大的修捕檔案就有些困難 (特別是牽涉到任何低階, 或較為敏感, 或較為複雜的東西, 這都需要投入更多的審核)。
如果修補檔案有點複雜的話, 請提供提交者足夠的資訊以進行測試 - 像是實際進行的步驟, 用來測試
- 如果有網址(URL), 會很有幫助
- 把貢獻放到 JIRA, 不要直接寄給提交者, 這樣每個人都可以審核, 以及提供意見。儘管不是必要的, 但透過這種方式可讓貢獻授權給 Apache 軟體基金會, 並可被追蹤。
- 讓更多社群成員試用你提供的修補檔案。寫到 開發論壇 告知所完成的事情, 請大家來試看看, 並支持這項修補。這有助於提交者審核時, 對修補檔案具備更多的信心 ... 瞭解嘗試要做的目標, 也知曉它不破壞任何東西。
|
如果規劃進行更大的貢獻, 請按照下面的要點, 以利授權與合作的進行。這些要點讓提交者更容易審核及採納你的成果, 整體而言也利於加速你的開發過程, 要求 OFBiz 團隊進行小型且簡單的工作, 優於一整個巨大的工作, 這會讓提交者得找到時間去審核和提交。
| Note |
|---|
|
- 不要自行做出大型的成果(程式碼, ... 等等)之後, 才貢獻給 OFBiz。
- 如果有一個大型的成果要貢獻, 我們可以和你一起進行, 但和一般貢獻有差異, 必須進行不同的審核和法律撿審程序, 細節在後面網址有說明 http://incubator.apache.org/ip-clearance/index.html。
- 當一個方法被停用(deprecated), 需解釋該用那個方法, 及什麼被改變了。
- 藉由貢獻方式來替代開發。意思是如同一般的開發, 但和 OFBiz 社群透過論壇, 以及持續貢獻修補檔案保持溝通。
- 如果團隊中沒有一位 OFBiz 的提交者, 可能會降低開發速度, 對策是 "賣出" 一位專案中的提交者, 和 OFBiz 提交者建立結盟關係, 以持續正式審核與提交你專案中的修補檔案。請注意到, 如果讓我們知道是在擘劃進行更大進展的特質, 我們或許可找到一位志願與你一同進行工作的人。
- 請瞭解到在 OFBiz 中沒有支付薪水的員工, 全部都是志願者。也許會看到你的修補檔案在 Jira 待了很長一段時間, 而提交者都在處理其他事情。這通常是由於提交者會優先處理發生問題的地方, 或為了生活先去處理有付款的合約, 這才能繼續幫助 OFBiz。
- 沒有 OFBiz 提交者加入, 只靠自己的努力也許會有些風險。請明白提交者能在技術上, 業務上, 以及法律方面提供協助, 無論是由他們自己本身, 或透過與 ASF 內的專案成員經常性合作。
|
未完 ...