若 PR 有任何變化的話，請務必記得更新 PR 的『狀態(state)』。 『狀態』應該要能正確反映該 PR 的目前進度才是。
Example 1. 以下是更改 PR 狀態的小例子：
當有可以修正問題的 PR 出現，而相關負責的 developer(s) 也覺得這樣的修正可以接受，他們會 followup 該 PR，並將其狀態改為 “feedback”。同時，回報者應重新評估最終的修正結果，並回應：所回報的錯誤是否已成功修正。
每份 PR 通常會有下面這幾種狀態之一：
PR 最初的狀態：這個問題被提出來，並在等待處理中。
已經開始處理這問題，並且有找到疑似解決的方法。
需要回報者提供更詳細的相關資料，正如教學要因材施教，治病也要因人下藥，越多相關訊息，才能有最佳效果。
已經送相關 patch 了，但仍因某些原因(MFC，或來自回報者的確認結果異常)因此尚未完畢。
因為沒附上相關訊息或參考資料，所以還沒辦法處理這問題。 This is a prime candidate for somebody who is looking for a project to take on. If the problem cannot be solved at all, it will be closed, rather than suspended. The documentation project uses “suspended” for “wish-list” items that entail a significant amount of work which no one currently has time for.
A problem report is closed when any changes have been integrated, documented, and tested, or when fixing the problem is abandoned.
Note: The “patched” state is directly related to feedback, so you may go directly to “closed” state if the originator cannot test the patch, and it works in your own testing.
本文及其他文件，可由此下載：ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/。
若有 FreeBSD 方面疑問，請先閱讀 FreeBSD 相關文件，如不能解決的話，再洽詢
<questions@FreeBSD.org>。
關於本文件的問題，請洽詢 <doc@FreeBSD.org>。