咱們常常被問到「我如何參與」,幸運的是,答案很簡單,只要寫一些代碼,而後提交 :) 這裏沒有你必需要跨越的障礙,也沒有祕密的握手。咱們有一個很是小的「開銷」,咱們請求容許可伸縮的項目開發,下面咱們將提供咱們要求的工具和「工做流」的概述,以及一些通常性建議。java
若是你寫了一些好文章,別忘了寫博客。git
登陸到jboss.org,你能夠訪問JBoss wiki、論壇和JIRA,進入https://www.jboss.org/ 並點擊「註冊」。github
你須要簽署的惟一形式是貢獻者協議,該協議經過web徹底自動化,以下圖所示,「這爲你的貢獻創建了條款和條件,並確保源代碼可以獲得適當的許可」。web
https://cla.jboss.org/segmentfault
爲了可以與核心開發團隊進行交互,你將須要使用問題跟蹤器JIRA,這確保了全部的請求都被記錄下來並分配到一個發佈計劃中,全部的討論都被捕獲在一個地方,Bug報告,Bug修復,特性請求和特性提交都應該在這裏,通常問題應在郵件列表中回答。工具
次要的代碼提交,好比格式或文檔修復,不須要建立相關的JIRA問題。單元測試
https://issues.jboss.org/browse/DROOLS測試
https://issues.jboss.org/browse/JBPMui
https://issues.jboss.org/browse/GUVNOR編碼
在簽署了貢獻者協議並將你的請求提交給JIRA以後,你如今應該準備好編碼 :) 建立一個GitHub賬戶,並fork任何Drools、jBPM或Guvnor存儲庫,fork會在你本身的GitHub空間中建立一個副本,你能夠按照本身的進度進行操做,若是你犯了錯誤,別擔憂,把它吹走,而後再用fork。注意,每一個GitHub存儲庫都爲你提供了克隆(檢出)URL,GitHub將爲你提供特定於fork的URL。
在編寫測試時,儘可能使它們最小化並保持自我控制,咱們更喜歡將DRL片斷保存在測試中,由於這樣能夠更快地進行檢查。若是它們是大量的規則,那麼使用字符串是不實際的,因此不管如何都要將它們放在單獨的DRL文件中,而不是從類路徑加載。若是你的測試須要使用模型,請嘗試使用那些已經存在於其餘單元測試中的模型;例如Person,Cheese或Order,若是不存在具備所需字段的類,請在添加新類以前嘗試更新現有類的字段。
有大量的測試須要查看以得到一個想法,MiscTest是一個很好的起點。
當你提交時,確保使用了正確的約定,提交必須從JIRA問題id開始,例如JBRULES-220。這確保了提交經過JIRA被交叉引用,所以咱們能夠看到在相同的位置爲一個給定的問題提交的全部提交。在id以後,接下來是問題的標題,而後使用帶有破折號的換行符來提供與此提交相關的附加信息,爲你想要表達的每個單獨的觀點使用額外的新線條和破折號。你能夠向同一個提交添加額外的JIRA交叉引用,若是它是合適的。通常來講,儘可能避免在同一個提交中組合不相關的問題。
不要忘記從原來的主分支中從新定位本地分支,而後將你的提交推回到你的分支中。
經過將代碼從最初的master中從新構建並推送到你的我的GitHub區域,你如今能夠以pull請求的形式提交你的工做,若是你在GitHub上查看你工做區域的頁面頂部,你會看到一個「Pull Request」按鈕,而後選擇它將提供一個gui來自動提交pull請求。
而後,pull請求進入一個隊列,供每一個人查看和評論,下面你能夠看到一個典型的pull請求。pull請求容許進行討論,並顯示全部相關提交和每一個提交的差別,討論一般涉及到代碼審查,這些審查爲改進提供了有用的建議,並容許咱們對代碼的特定部分留下內聯註釋。若是咱們不直接合並,不要灰心,在接受pull請求以前,一般須要進行屢次修改,幸運的是,GitHub讓返回代碼變得很是簡單,執行更多提交,而後將pull請求更新到你的pull請求到最新和最大。
咱們須要時間來回復pull請求,因此請耐心等待,隨修復程序一塊兒提交的測試一般會很快被應用,在咱們有時間提交修復程序以前,測試一般會一直進行下去。不要忘記不時地從新創建和從新提交你的請求,不然隨着時間的推移,它會有合併衝突,而核心開發人員一般會忽略這些衝突。