首先，回報者(originator)以 send-pr(1) 送出 PR，然後會收到一封確認信。
然後，committer 們就會有人(假設叫做 Joe)發掘有興趣的 PR 並將該 PR 指派給自己來處理。 或者 bugbuster 會有人(假設叫做 Jane) 就會下決定：她覺得 Joe 比較適合處理，就將該 PR 指派(assign)給他
Joe 會先與有問題的回報者作些意見交流(以確定這問題有進入 audit 追蹤流程內) 以及判斷問題點。 然後再確定問題點有寫入 audit 追蹤流程之後，然後把該 PR 狀態設為 “analyzed(已分析)”。
Joe 開始徹夜找出問題解法，然後將 patch 送到 follow-up(回文用)，並請回報者協助測試是否正常。 然後，他就會將 PR 狀態設為 “feedback” 囉。
如此重複 analyzed、feedback 幾趟之後，直到 Joe 與回報者雙方都相當滿意 patch 結果， 於是就會將 patch 給 commits 進入 -CURRENT (或者若 -CURRENT 上面沒這問題的話，就直接送到 -STABLE)，在 commit log 內要把相關 PR 寫上去 (同時回報者若有送完整或部分 patch 的話，就順便記載)，然後，若沒什麼事的話，就開始準備 MFC 哩。 (譯註：MFC意指 Merged From CURRENT ，也就是把 -CURRENT 上的東西併入 -STABLE。
若該 patch 不需要 MFC 的話，Joe 就會關掉(close)該 PR 了。
若該 patch 需要 MFC 的話，Joe 會把 PR 狀態改為 “patched(已修正)”， 直到已經 MFC 完畢，才會 close(關掉)。
Note: 很多送出來的 PR 都很少附上問題的相關訊息，而有些則是相當複雜難搞， 或只是提到部分表面問題而已； 遇到這種情況時，是非常需要得到所有相關訊息以便解決問題。 若遇到這種無解的問題或再次發生的話，就必須要 re-open(重新開啟) 該 PR，以待解決。
Note: PR 上所附的 “email address” 可能因某些原因而無法收信時，遇到這種狀況，通常就是 followup 該 PR ，並(在 followup 時)請回報者重新提供可正常收信的 email address。 當系統上的 mail 系統關閉或沒裝的時候，這通常是在使用 send-pr(1) 的替代方案。
本文及其他文件，可由此下載：ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/。
若有 FreeBSD 方面疑問，請先閱讀 FreeBSD 相關文件，如不能解決的話，再洽詢
<questions@FreeBSD.org>。
關於本文件的問題，請洽詢 <doc@FreeBSD.org>。