審閱流程
概觀
本文概述 LangChain 維護者用於審閱提取請求 (PR) 的流程。此流程的主要目標是提升 LangChain 開發人員體驗。
審閱狀態
我們使用三種主要狀態對 PR 進行分類,這些狀態在右側邊欄中標記為專案項目狀態,並且可以在此處查看詳細資訊。
-
初步評估:
- 所有新提交的 PR 的初始狀態。
- 需要維護者將其分類為其他狀態之一。
-
需要支援:
- 在繼續之前需要社群回饋或額外意見的 PR。
- 如果收到 5 個贊,則自動提升到待辦事項。
- 當應用此狀態時,會自動產生註解,說明流程和贊數要求。
- 如果 PR 在此狀態下保持 25 天,則會透過自動註解標記為「過時」。
- 如果未採取進一步行動,PR 將在 30 天後自動關閉。
-
審閱中:
- 正在由我們的團隊積極審閱的 PR。
- 這些會定期審閱和監控。
注意: 一個 PR 一次只能有一個狀態。
注意: 您可能會注意到另外 3 個狀態:完成、已關閉和內部,它們在此生命週期之外。完成和已關閉的 PR 已分別合併或關閉。內部用於核心維護者提交的 PR,這些 PR 歸提交者所有。
審閱指南
-
涉及 /libs/core 的 PR:
- 直接影響核心程式碼並可能影響終端使用者的 PR。
- 初步評估指南:大多數 PR 應直接進入
審閱中
或關閉。 - 這些 PR 具有最高優先順序,並且審閱速度最快。
- 沒有對其動機進行簡潔描述(無論是在 PR 摘要中還是在連結的問題中)的 PR 很可能會在沒有深入審閱的情況下關閉。請勿使用 LLM 生成冗長的 PR 描述。
- 沒有單元測試的 PR 很可能會被關閉。
- 功能請求應首先作為 GitHub 問題開啟,並與 LangChain 維護者討論。在沒有事先討論的情況下提交的大型 PR 很可能會被關閉。
-
涉及 /libs/langchain 的 PR:
- 高影響力的 PR,與核心 PR 密切相關,但優先順序略低。
- 初步評估指南:大多數 PR 應直接進入
審閱中
或關閉。 - 這些 PR 會像核心 PR 一樣積極審閱和關閉。
- 新的功能請求應事先在問題中與核心維護團隊討論。
-
涉及 /libs/partners/ 的 PR:
- 涉及整合套件的 PR。
- 初步評估指南:大多數 PR 應直接進入
審閱中
或關閉。 - 審閱可能由我們的團隊進行,也可能根據 PR 的內容移交給合作夥伴的開發團隊。
- 我們與大多數合作夥伴開發團隊保持溝通管道,以促進此流程。
-
社群 PR:
- 大多數社群 PR 的初始狀態將為「需要支援」。
- 初步評估指南:大多數 PR 應進入
需要支援
。高流量整合的錯誤修復應直接進入審閱中
。 - 初步評估指南:所有新功能和整合都應進入
需要支援
,如果它們沒有獲得足夠的支援(透過贊數或評論衡量),將會被關閉。 - 處於
需要支援
狀態 20 天的 PR 會被標記為「過時」,如果沒有採取任何行動,將在 30 天後關閉。
-
文件 PR:
- 涉及 docs/docs 中文件內容的 PR。
- 初步評估指南:
- 修復單個檔案中的錯字或小錯誤並通過 CI 的 PR 應直接進入
審閱中
。 - 在問題中討論並同意進行變更的 PR 應直接進入
審閱中
。 - 新增頁面或變更文件結構的 PR 應進入
需要支援
。
- 修復單個檔案中的錯字或小錯誤並通過 CI 的 PR 應直接進入
- 我們力求標準化文件格式,以簡化審閱流程。
- CI 作業針對文件運行,以確保符合標準,從而自動化大部分審閱工作。
-
PR 必須使用英文:
- 非英文的 PR 將在未經審閱的情況下關閉。
- 這是為了確保所有維護者都能有效地審閱 PR。
如何查看 PR 的狀態
請參閱螢幕截圖
要查看所有開啟的 PR 的狀態,請造訪 LangChain 專案看板。
審閱優先順序
我們的目標是透過專注於製作以下軟體來提供最佳的開發體驗:
- 運作正常:按預期運作(沒有錯誤)。
- 實用:透過可立即使用的組件和簡化應用程式建置的執行時,改進 LLM 應用程式開發。
- 容易使用:直觀易用且文件完善。
我們相信此流程反映了我們的優先事項,如果您認為沒有,我們願意接受回饋。
Github 討論
我們歡迎您對此流程的回饋。請隨時在此 GitHub 討論中新增評論。