此前，Python 開發組一直在 Python 官方 Bug 網站 (縮寫為 bpo 或 BPO) 上進行 Bug 提交、跟蹤和處理，該網站使用開源工具 作為 Bug 跟蹤器。
2 月 18 日， Python 核心開發者 Łukasz Langa 在 Python Discourse 論壇上 ：Roundup / BPO 上的所有 Bug 資料都將遷移到 GitHub 中，遷移完成後，新的 Bug 在 GitHub Issue 中處理，原 BPO 官方網站將以唯讀模式存在，以避免連結失效帶來的一系列問題 。
CPython 的開發早於 2017 年 2 月就轉移到 中。因此，在 2018 年 Python 語言峰會上，核心開發者 Mariatta Wijaya 提議「放棄 Roundup 和 BPO 網站，切換到 GitHub Issues 用於 Bug 跟蹤」，該提議引出了 提案，並於 2019年獲得批准。
但由於從 Roundup / BPO 到 GitHub 的大遷移涉及的內容太多，在技術上、程式上或法律上都存在複雜難題，因此直到 2022 年大遷移才正式啟動。
根據 Łukasz Langa 的介紹，遷移的時間表如下：
- 2022 年 2 月 18 日，星期五：開始持續兩週的公眾反饋收集期。
- 2022 年 3 月 4 日，星期五：在 Github 的幫助下執行最終的端到端 Bug 資料遷移測試，收集遷移所需的時間和出現的問題。（將使用 10% 的 Bug 進行測試。）
如果測試過程沒啥問題，就正式遷移：
- 2022 年 3 月 10 日，星期四：遷移開始，BPO 進入唯讀模式，來自 BPO 的資料被匯出，並放在 Github 上的臨時儲存庫中。（預計要 22 個小時）
- 2022 年 3 月 11 日，星期五：Github 將臨時儲存庫中的 Bug 轉移到 GitHub 的 Python 庫 ，正式完成遷移。
在遷移過程中，有如下需要注意的事項：
- 不允許在 Github 或 BPO 上建立新問題
- 倉庫 PR 不受影響，可以在 Github 上建立新的 PR 並與現有 PR 互動
- 可以與 Github 上已遷移的 Issue 進行互動，但不鼓勵破壞性操作（更改問題標題、編輯評論內容、刪除評論、刪除標籤），因為資料的變化會讓遷移是否有成功變得難以稽核。
此外，進一步解釋了該遷移計劃的細節，對一些常見的疑惑也做出瞭解答：
Roundup / bpo 有啥問題？為啥放棄它？
- 維護者從未超過 5 個
- 沒有任何 CI 構建，審查和測試壓力太大
- UI 老舊
- 天天給使用者發垃圾郵件，還容易暴露使用者郵件地址
為什麼不繼續優化 Roundup / bpo？
優化成本太高，「建立和維護 GitHub 整合和審查機器人，工作量遠低於繼續優化並維護 Roundup 。」
為什麼選擇 GitHub 而不是其他平臺？
GitHub 功能齊全，而且受眾更廣，大部分程式設計師都知道如何操作，能降低貢獻門檻。因此，儘管它也有一大堆問題，但仍是目前最優解。
放棄了 Roundup / BPO 的同時，也意味著 Python 開發的基礎設施已經完成了從基於 Python 的開源工具（Mercurial、Roundup）到專有的 GitHub 「SAAS」 產品的全面轉變（從某種角度來看，這或許也算是開源的一種悲哀？）。但無論如何，該遷移肯定會吸引很多熟悉、並習慣使用 GitHub 的新開發人員來做貢獻，對 Python 的發展必然大有脾益。