檢閱拉取請求
此指南適用於維護人員。這些特殊人員擁有對一個或多個 Jekyll 儲存庫的寫入權限，並協助合併其他人的貢獻。你可能會覺得這裡寫的內容很有趣，但這絕對不是為所有人而寫的。
親切回應
最重要的是，請親切地檢閱拉取請求。只有當我們營造出一個歡迎和包容的環境時，我們的社群才能強大。為了進一步促進這一點，Jekyll 社群受 行為準則 約束，所有社群成員都必須遵守。
自由使用表情符號 
，並隨時表達你的情緒！貢獻讓這個專案持續前進，我們總是樂於收到貢獻，即使拉取請求最終沒有合併。
Mike McQuaid 在 GitHub 部落格上發表的文章 “Kindly Closing Pull Requests” 是個很好的起點。它描述了在哪些情況下可以接受因技術完整性或準確性以外的原因關閉請求。友善的一部分是快速回應和解決請求。
快速回應
我們應該可以在一週內檢閱所有請求。唯一會花費較長時間進行初始檢閱的情況，是所有維護人員在同週都神秘地休假。迅速處理能鼓勵社群成員和其他維護人員頻繁提供高品質的貢獻。
如果您的回應需要作者回應，請加上 pending-feedback 標籤。一旦請求的作者回應，@jekyllbot 會自動移除標籤。
快速解決
類似地，我們應該力求快速解決請求。如果一個請求引入了不符合專案核心目的或目標的功能，請迅速關閉它，並友善地說明為什麼它不可接受。
盡可能留下詳細的評論。向貢獻者提供您要求變更的必要性背景，或說明您提出的問題為何重要。我們能清楚地向貢獻者傳達的背景資訊越多，貢獻者就能提供越優質的修補程式。
如果作者超過 30 天沒有回應，您可以關閉請求。
在某些情況下，審查會涉及數週的往返。只要溝通持續進行，這沒問題。理想情況下，任何公關活動都應能在開啟後 30 天內解決。
尋找測試
如果這是程式碼變更，是否有針對更新或新增行為的測試？發布有錯誤的版本是不可避免的，但確保對變更進行測試有助於將錯誤和回歸降至最低。
CI 必須通過
在開始審查之前，要求貢獻者調查 Travis 上的失敗並修補它們是可以的。建議為貢獻者留下一則訊息，指出測試已失敗，並且在測試通過之前不會進行審查。如果他們尋求協助，請查看並在您有能力的情況下提供協助。
二人法則
當兩個維護人員審查公關請求並表示可以接受時，就可以合併公關請求。除非兩位審查員中的一位希望再找人審查，否則不需要等待第三人。
思考安全性
我們有責任確保我們的使用者使用社群中的佈景主題或建立其他人的網站時，不會遇到內建的安全漏洞。例如，哪些檔案可以讀取和寫入等事項對於維持安全性非常重要。Jekyll 也是 GitHub Pages 等託管服務的基礎，當引入安全性問題時，這些服務無法升級。