提取要求就像是存放區的生命線，讓一切運作順暢無虞。本頁面將詳細說明如何建立完整且易於審查的提交要求，提高提交要求合併的可能性。
以下是確保能建立最佳公關的步驟。
通訊
在您開始撰寫程式碼之前，建議您與核心團隊進行溝通，讓他們瞭解您的興趣所在。
如果有您感興趣的問題，請在該問題上留言，表示您將開始著手處理。這樣一來，就能確保不會有多人同時處理同一件事情。團隊成員會回覆，確認該裝置屬於你。
如果您有想法，但未涵蓋在任何問題中，請在開始工作前撰寫一篇文章。這樣一來，團隊就能在您開始建構前討論如何最佳化變更作業，從長遠來看可節省您的工作量。
進行設定
如果這是您首次為 Blockly 或 Blockly 範例提供意見，請先參閱「開發設定」頁面。
保持小型
請務必盡量減少變更項目，並專注於特定項目。我們寧願審查多項較小的 PR，而非審查一項大型 PR。以下是一些實用經驗法則：
- 修正一個問題。請勿一次處理多個問題。
- 限制範圍。通常 PR 應在 8 小時內完成 (視您對程式碼集的熟悉程度而定)。
- 使用提交。如果覺得提交要求有點大，請使用 Git 提交將變更項目分成邏輯群組。
保持清潔
為什麼要重視程式碼樣式？我們會長期提供這項服務，而一致的樣式有助於簡化維護作業。樣式是指變數命名方式，但也涵蓋程式碼結構、註解編寫方式等。我們會盡可能使用 eslint 等工具，自動執行樣式檢查。
除了 eslint 外，請遵循下列指南：
測試變更
在提交合併請求之前，請務必測試變更是否正常運作，以免日後需要回頭修正。以下提供一些測試不同類別專案的想法：
- 外掛程式：編寫涵蓋變更的自動化 Mocha 測試。
- 示例：手動測試所有展示的功能。
- codelabs：在乾淨的環境中執行整個教學課程，並測試您提供的任何程式碼範例。
通訊
這是建立 PR 的最後步驟，也是最重要的步驟：撰寫摘要。
撰寫優質的提交要求摘要，有助於其他開發人員審查您的變更，進而提高變更通過的機率！
摘要應包含以下內容：
- 與您的提交內容相關的問題。
- 變更要求 (PR) 新增的內容。
- 如何測試變更。
- 任何你想讓審查員仔細審查的內容。
- 任何你認為審查人員需要的其他資訊。
只要您在建立要求時遵循 PR 範本，應該就沒問題。請記得盡可能保持簡潔和完整。
祝您程式設計一切順利！