|
| 1 | +# 貢獻幫助指南 |
| 2 | +👋 Hi,我們很高興見到您對[PowerNukkitX](https://github.com/PowerNukkitX/PowerNukkitX)項目所表現出的熱情,我們的目標是為所有參與開發的參與者們提供一個良好的協作環境,因此我們決定列出一些在此過程中需要您牢記的事情,以下指南是根據過往經驗總結而成的。 |
| 3 | + |
| 4 | +但您需注意,這些規則本身不是"**官方規則**",但您若遵循它們將幫助參與者們提高處理效率。 |
| 5 | + |
| 6 | +## 目錄 |
| 7 | + |
| 8 | +1. <a href="#Catalogs-Faq#1">🧾 我想提交一個問題!</a> |
| 9 | +2. <a href="#Catalogs-Faq#2">💡 我想提交拉取申請!</a> |
| 10 | +3. <a href="#Catalogs-Swlang">🌐 切換語言 / Switch Languages</a> |
| 11 | + |
| 12 | +## <a id="Catalogs-Faq#1"></a> 我想提交一個問題! |
| 13 | + |
| 14 | +我們隨時歡迎您提出任何問題,錯誤報告和功能建議,但請記住,如果該問題在可預期的時間點內被認定為不重要,無法解決等,我們也會將其忽略,因此Issues頁面可能會出現長時間未解決或徹底關閉的問題反饋將會是正常情況。 |
| 15 | + |
| 16 | +* **在提交問題報告前,請您先搜索現有問題列表。** |
| 17 | + |
| 18 | + 出於管理目的,我們會關閉與先前就存在的問題反饋,避免產生重複,推薦您先通過自行搜索的方式查詢是否存在類似問題。 |
| 19 | + |
| 20 | +* **在提交問題報告時請盡可能的嘗試提供更多詳細信息。** |
| 21 | + |
| 22 | +由於產生的錯誤信息各不相同,其中一部分錯誤在幾乎所有設備上都能遇到,而有一部分是因為某些特定情況甚至是硬件本身導致,所以我們推薦您在提交問題時提供盡可能多且詳細的信息,以下為示例模板: |
| 23 | + |
| 24 | +* 服務器的日誌文件(若服務器可用時),您則可用通過以下方式獲取日誌文件: |
| 25 | + * `/spark` |
| 26 | + * `[您的服務端所在文件夾]/logs/latest.log` |
| 27 | +* 你的設備規格參數 (包括您客戶端的類型,操作系統平台,服務器硬件參數等), |
| 28 | +* 重現步驟 (您在遇到BUG之前進行了什麼操作等), |
| 29 | +* 如果可以的話,請提供視頻或截圖加以輔助。 |
| 30 | + |
| 31 | +* **當被要求提供更多有關信息時。** |
| 32 | + |
| 33 | + 在某些情況下,某個錯誤可能會難以復現等,當上面反饋的信息都不能很好的幫助我們追踪問題時,在這種情況下,我們可能會要求您提供額外的信息以便更好的幫助追踪問題,並且我們一旦知道問題所在時,就會著手開始修復並與您取得聯繫。 |
| 34 | + |
| 35 | +* **提交改進意見時,請以簡單易懂的方式描述它。** |
| 36 | + |
| 37 | + 有時傳達您對某個功能的想法通常很困難,我們希望避免產生任何誤解,因此,您在提交改進建議時,盡量使用簡潔易懂的話語或方式描述您的想法。 |
| 38 | + |
| 39 | +* **避免發布"+1"重複問題。** |
| 40 | + |
| 41 | + 如果問題已經產生,並且你也遇到過但無法提供任何對我們有幫助的問題細節的話,那您可在相關問題下評論留言。 |
| 42 | + |
| 43 | + |
| 44 | +## <a id="Catalogs-Faq#2"></a>我想提交拉取申請! |
| 45 | + |
| 46 | +同時我們也歡迎各位開發者們對該項目作出您的貢獻,您可在[問題追踪器](https://github.com/PowerNukkitX/PowerNukkitX/issues)頁面發表您可以解決的問題等,同時我們也會使用[`Good First issue`](https://github.com/PowerNukkitX/PowerNukkitX/issues?q=is%3Aissue+is%3Aopen+label%3Agood%20first%20issue)標籤標記出我們認為對新人有幫助的問題解答等。 |
| 47 | + |
| 48 | +⚠ 若您想參與該項目,則您需要注意一些事項: |
| 49 | + |
| 50 | +* **確保您對Java編程有一定的基礎的同時,還需熟悉對IDE工具的使用等。** |
| 51 | + |
| 52 | + 雖然我們接受各種類型的貢獻,但我們也有一定的代碼質量要求,但我們審查您提交的代碼時間是有限的,因此,我們希望避免提供入門建議等,如果您對Java編程不是很熟悉,我們建議您從一些個人項目開始,並熟悉語法,工具鍊等。 |
| 53 | + |
| 54 | +* **您需熟悉Git和Pull Request工作流程** |
| 55 | + |
| 56 | + [git](https://git-scm.com/) 是一個分佈式版本控制系統,如果你不熟悉版本控制,一開始可能不是很直觀。特別是,使用git的項目有一個特定的工作流程來提交代碼修改,這被稱為拉動請求工作(Pull Requests)流程。 |
| 57 | + |
| 58 | + 為了讓事情進行得更順利,我們建議你在網上查找一些資源,熟悉git的詞彙和命令,並按照自己的節奏練習處理分叉和提交拉動請求。關於這個過程的高層次概述可以在[該文章](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests)中找到。 |
| 59 | + |
| 60 | + 我們還提供了一個[快捷鏈接](https://github.com/powernukkitx/powernukkitx/pulls),用於向PowerNukkitX提出拉動請求。 |
| 61 | +* **確保提交的拉動請求是在相關分支上。** |
| 62 | + |
| 63 | + 如前文所述,特性分支可以幫助你將工作平行化,並將其與主要的 `Bleeding` 分支分開,另外也便於維護者的工作。在許多遠程站點上使用多個 `Bleeding` 分支是很難跟踪的,而且很容易犯錯,不小心推送到錯誤的 `Bleeding` 分支。 |
| 64 | + |
| 65 | +* **盡可能地為你添加的代碼做測試。** |
| 66 | + |
| 67 | + 自動測試是高質量和可靠的代碼庫的一個重要組成部分。它們通過確保以各種方式重組(或重構)代碼是安全的,來幫助使代碼更具可維護性,同時也防止回歸--在過去的某個時間點被修復後重新出現的錯誤。如果可行的話,請花時間添加測試,這樣你所做的修改可以持續很長時間(希望如此)。 |
| 68 | + |
| 69 | +* **在打開拉動請求之前,先運行測試。** |
| 70 | + |
| 71 | + 與上一點相聯繫的是,有時代碼庫的一部分的變化會導致代碼的其他部分的行為發生不可預測的變化。這就是為什麼最好是在開啟PR之前先運行測試。 |
| 72 | + |
| 73 | + 持續集成也會為你(和我們)運行測試,但最好不要依賴它,因為任何時候都可能有許多構建在排隊。自己運行測試將幫助你更確定在點擊 "創建拉動請求" 按鈕時,你的修改已經準備就緒。 |
| 74 | + |
| 75 | +* **在打開拉動請求之前,請確保該請求是完整的。** |
| 76 | + |
| 77 | + 無論是修復錯誤還是實現新功能,你最好在點擊*創建拉動請求*按鈕之前,確保你要提交的修改盡可能完整。要跟踪一個拉動請求是否準備好接受審查,會給審查者帶來額外的負擔。 |
| 78 | + |
| 79 | + 草稿拉動請求是一種選擇,但要在合理的範圍內少用它們。它們最適合用來討論那些不容易用自然語言描述的代碼修改,或者對項目的未來方向有潛在的巨大影響。如果有疑問,不要打開草案,除非維護者要求你這麼做。 |
| 80 | +* **只有當代碼準備好了才推送。** |
| 81 | + |
| 82 | + 作為上述內容的延伸,當對一個已經開放的PR進行修改時,請盡量只推送你有合理把握的修改。每次提交後的推送都會導致持續自動構建隊列的規模擴大,減緩工作速度,並佔用可以用來驗證其他修改的時間。 |
| 83 | + |
| 84 | +* **請確保選中*允許來自維護者的編輯*複選框。** |
| 85 | + |
| 86 | + 為了加快合併過程,合作者和團隊成員有時會想自己向你的分支推送修改,對代碼風格進行細微的調整,或者以其他方式重構代碼,而不必煞費苦心地描述他們希望代碼是什麼樣子。勾選 "允許維護者編輯 "複選框可以讓他們這樣做;如果沒有這個複選框,他們就不得不向你報告問題並等待你來處理。 |
| 87 | + |
| 88 | +* **不要不斷地將PR合併到主分支上。** |
| 89 | + |
| 90 | + 除非有合併衝突需要解決,否則沒有必要一次又一次地把 `Bleeding` 合併到一個分支。反正在合併PR之前,其中一個維護者會自己合併 `bleeding`,而且持續的合併提交會使CI因排隊等待過多的構建而不堪重負。 |
| 91 | +* **避免強行推送到PR分支。** |
| 92 | + |
| 93 | + 應該避免強行推送,因為這可能會導致意外地覆蓋維護者的修改或CI構建錯誤的提交。我們重視項目中的所有歷史,所以在大多數情況下沒有必要壓製或修改提交。 |
| 94 | + |
| 95 | + 需要強行推送的情況非常少見(比如不小心洩露了提交文件中的敏感信息,添加了不相關的文件,或者錯誤地合併了一個依賴的PR)。 |
| 96 | + |
| 97 | +* **在等待代碼被審查和合併的過程中要有耐心。** |
| 98 | + |
| 99 | + 儘管我們希望盡可能快地審查所有的貢獻,但我們的時間是有限的,因為團隊成員除了審查代碼外,還必須處理自己的任務。因此,工作需要被優先考慮,不幸的是,你的PR可能需要數天或數週才能被合併,這取決於它被認為是多麼重要。 |
| 100 | + |
| 101 | +* **不要把對代碼的批評誤認為是對你個人的批評。** |
| 102 | + |
| 103 | + 如前所述,當涉及到項目時,我們對質量有高度的承諾。這意味著,來自經驗不足的社區成員的貢獻可能需要多輪審查才能達到可合併的狀態。我們盡最大努力不把一個人和他所寫的代碼混為一談,並且在任何時候都把討論集中在代碼上。請把我們的評論和要求看作是一種學習經驗,不要把它當作是一種人身攻擊。 |
| 104 | + |
| 105 | +* **我們隨時歡迎您聯繫我們或尋求幫助。** |
| 106 | + |
| 107 | + 如果你對代碼庫的某些部分或遊戲和框架的某些內部運作不確定,請通過在相關問題或PR中留言,或在[Discord](https://discord.gg/BcPhZCVJHJ)&[QQ群](https://jq.qq.com/?_wv=1027&k=6rm3gbUI)發文來聯繫我們。我們會盡可能地幫助你。 |
| 108 | + |
| 109 | + 說到哪種溝通方式最好,GitHub通常更適合長篇大論,而Discord和QQ群則更適合快速的呼喚和回應。在決定的時候,請盡力斟酌,並儘量將一個討論放在一個地方,而不是來回移動。 |
| 110 | +## <a id="Catalogs-Swlang"></a>🌐 多語言文檔 |
| 111 | + |
| 112 | +--- |
| 113 | +Need to switch languages? |
| 114 | + |
| 115 | +[](../zh-hans/CODE_OF_CONDUCT.md) |
| 116 | +[](./CODE_OF_CONDUCT.md) |
| 117 | +[](../../CODE_OF_CONDUCT.md) |
| 118 | +[](../../LICENSE) |
| 119 | +[](../zh-hant/CHANGELOG.md) |
| 120 | +[](https://doc.powernukkitx.cn) |
0 commit comments