前往主要內容

Pull Request

本文檔提供如何檢閱 Pull Request 的指南。

檢閱 PR 時請運用您的最佳判斷，最重要的是記得在回應使用者時要親切、友善且鼓勵。許多使用者是第一次接觸開源和輸入的 linting。我們必須給他們一個積極、令人振奮的體驗。

提示

如果您對任何部分的公關評論感到不確定，請不要猶豫，找一位有更多背景協助的維護人員！

管治​

依照從貢獻層級 > 指示的基準

  • 直截了當：視審查人員的決定，任何提交人或維護人員的單一核准可能會合併。這包括文件增強、錯誤修正和功能新增。
  • 非直截了當：可能使用兩個提交核准或一個維護核准進行合併。這些包括多套件內部重構和非中斷公開 API 變更。
  • 類別為「非同尋常」：需要兩個維護者核准。這些包括具有跨專案和公開 API 影響的重大重構。

公關評論流程​

注意

我們在.github/replies.yml中包含一系列對公關的常見回應，旨在與精緻儲存的回應擴充功能搭配使用。請勿將這些視為您必須使用的確切回應：它們只是一個開始的複製貼上輔助工具。請根據您的個人語氣調整您的特定回應，並針對非直截了當的公關修改討論串。

開放的公關請求理想上在兩個狀態之間切換

當你發表檢閱報告時，請將 awaiting response 標籤加到一個公關案中。如果原作者重新要求檢閱，這個標籤將被自動移除。

善待他人​

無論如何，在語氣上都應力求鼓勵和友善。

  • 將回饋以改進機會，而非責難的措辭表達出來。
  • 說出你看到任何積極面 - 特別是在較大型的公關案。
  • 頻繁使用快樂的表情符號。
  • 如果你有精神，在你的檢閱報告中發布一個有趣（但不太合適）的 GIF。

公關案是許多社群成員第一次與我們有意義互動的時候 - 或者，通常來說，是與任何開源維護者第一次互動。我們提供正向、令人振奮的體驗很重要。 ❤️

檢閱公關案​

在檢閱公關案之前，請嘗試回頭查看問題的詳細資訊，以便對其重新（或再次）熟悉。你可能會覺得這樣比較容易

  • 嘗試簡化所提供的縮減資訊 ("code golf")
  • 回頭查看先前針對相同程式碼/lint 規則的議題和公關案

如果沒有問題的詳細資訊

  • 如果公關案是針對文件或工具的直接修正，並未影響使用者，那麼直接檢閱即可
  • 如果不是上述情況，請加上 please fill out the template 這個標籤並貼上一則評論，例如 需求議題 範本

在完成檢閱後，如果建置通過，而你也覺得可以合併，請直接合併壓縮。否則，加上 1 approval 這個標籤。

常見的事項​

  • 風格：你能輕易閱讀程式碼，必要的複雜區域有提供評論，且其他地方沒有不必要的評論。
    • 嘗試不要對不重要的事情吹毛求疵。
    • 如果某事項在儲存庫中是標準，但沒有強制執行，可以考慮將其標記為非封鎖評論，並提交一個議題以強制執行。
  • 徹底性：是否處理相關的邊緣案例？常見
    • 泛型和類型參數（參閱：getConstrainedTypeAtLocation）。
    • 括號和空白（參閱：getWrappingFixer）。
    • 聯集和交集（參閱：unionTypeParts 和 intersectionTypeParts）。
  • 單元測試
    • 所有行都包含在 Codecov 中 / yarn jest path/to/impacted/file --coverage 報告。
    • 如果有合理的可能性，這裏存在「正」與「負」（「有效」與「無效」）兩種情況。
    • 修正和建議（如果有），請勿移除 // 或 /* 註釋。
    • invalid lint 規則錯誤包括行和欄資訊。
    • 即使它們在 TypeScript 中導致類型錯誤，有效的語法邊界情況也不使規則崩潰。

各別註釋​

針對一個稱讚備註、建議的變更或不可行的備註區塊，發表一則貼文。使用多個輔助註釋來標示 「（也包括這裡）」 備註，但不要讓請求相當繁重。

提示

如果要發布多於兩種類型的註釋，請考慮加上類別標示作為前置詞，例如 [文件]、[稱讚]、[測試] 等。這有助避免審查時產生有如大量請求的沉重感。

在每一個註釋中，清楚說明你在尋找或表達的是什麼。建議提供比你認為必要的更多資訊。

在不確定錯誤點時，請試著使用疑問語氣。鼓勵作者思考你的建議：「我認為是 (xyz)，但我並不確定，你覺得呢？」。

預先審閱或重複審查​

有時，你可能會想要發布預先審閱，和/或稍後才發現之前的審閱遺漏了什麼。這兩種情況都很合理。

對於預先審閱，你要明確說明審閱的範圍：「現在審閱架構，等到確定後，將會更詳細地審閱。」。

對於重複審閱，如果你是之前有遺漏的部分和/或有新資訊時，你要明確說明。如果由於要求的變更才讓遺漏的資訊變得明確，請勿道歉，這是審閱程序的一部份！

其他狀態​

外部阻礙​

如果公關對某件事受阻，例如外部 API 或議題討論，請加上適當的標籤 blocked by *。在註釋中說明原因，並至少連結到對阻礙因素的追蹤資訊。

頻外問題​

作者有時會在 PR 上將問題分別作為註解提問，有時候會包含 @ 標籤。如果你回答問題， 請放回 等待回覆 標籤。如果你漏掉一些這些問題，不用擔心；我們偏好透過正式重新要求審查，以確保視需要移除 等待回覆 標籤。

整理舊的 PR​

我們時常會搜尋有 等待回覆 標籤的開啟 PR，找出可能已被忘記的 PR。我們對於已等待 >=1 個月的 PR 的流程為

  1. 使用類似 與你聯繫 範本的訊息，傳訊給作者
  2. 加入 陳舊 標籤至 PR
  3. 等待 2 週
  4. 如果作者仍未回覆，請使用類似 整理陳舊 PR 範本的訊息關閉 PR

搜尋 PR​

對 PR 的其他各種查詢包括

如果你有時間，請偶爾瀏覽舊的 PR，以確保沒有問題未在數週內獲得解答。