Boost 函式庫提交流程
本頁面描述函式庫開發者讓函式庫被 Boost 接受的流程。
關於內容相關議題，請參閱Boost 函式庫要求和指導方針頁面。
讓函式庫被 Boost 接受的步驟
1. 了解 Boost
持續關注主要開發者郵件列表上的貼文，或瀏覽存檔。探索網站。了解要求。閱讀本頁面的其餘部分以了解流程。搜尋網路以了解將函式庫納入 Boost 所需的投入。
Boost 有一種相關的文化，旨在透過討論和精進的過程來鼓勵高品質的函式庫。有些函式庫在從最初概念到通過社群審查的時間不到兩年，但大多數都需要更長的時間，有時甚至更久。一個函式庫從審查到納入 Boost 需要五到十年並不罕見，您應該為所需的個人投入做好準備。
2. 確認興趣
雖然參與其他提交的審查並非將函式庫提交到 Boost 的先決條件，但強烈建議您參與；這將使您熟悉流程以及正式審查的情緒需求。沒有什麼比讓 C++ 社群的傑出成員評論你的作品更能打擊你的自尊心了，但，唉，這是值得的！
潛在的函式庫提交者在開始設計新函式庫之前，應仔細研究現有技術。遺憾的是，時不時會有人帶著他們投入了許多時間的新函式庫來到 Boost，卻發現 Boost 已經具備了該功能，而且有時已經具備多年了。候選者也應該研究其他人正在為 Boost 開發的函式庫——如果您有想要解決的問題，其他人通常也有，與他們合作開發他們的函式庫通常比單打獨鬥更有效率。
潛在的函式庫提交者也應注意宣傳、徵求並評估對其函式庫的興趣，理想情況下是在開始之前，但肯定要在提交審查之前。即使設計精良的函式庫，如果對主題沒有足夠的興趣，也可能無法通過審查；我們只能審查那些具有足夠吸引力以形成可行的同儕審查的函式庫。確保有足夠多的人對您的潛在函式庫感興趣，對確保這一點大有幫助。
有許多地方可以宣傳和徵求函式庫。Boost 開發者郵件列表應該是您評估對可能的新 C++ 函式庫的興趣的第一站。準備好調整您的設計和重點，直到您提議的函式庫獲得關注。其他可用於評估函式庫興趣的地方可能是Reddit/r/cpp。
發送到 Boost 開發者郵件列表的訊息可以簡單到「是否有人對可以在線性時間內解決旅行推銷員問題的函式庫感興趣？」
一些進一步的描述或程式碼片段可能會有幫助。順帶一提，郵件列表上的訊息首選格式是純文字；而不是RTF、HTML 等。
請避免在郵件列表中張貼冗長的描述、文件或程式碼，也請不要夾帶附件。提供長篇幅資料的最佳方式是透過網路連結。專案託管服務，例如 SourceForge、GitHub、Google Code 和 Bitbucket，都很適合用於此目的。
3. 開始開發
如果初步詢問獲得了感興趣的回覆，那麼如果您尚未公開您的函式庫，請務必將其公開。
請將您的程式碼提交到版本控制系統，例如 Git，並以 HTML 格式在公開網站（例如 GitHub）上提供您的文件。也強烈建議使用問題追蹤器，例如 GitHub 提供的追蹤器。
您的函式庫應包含如同放在 boost.org 網站上的所有資料。您的函式庫越能反映網站的最終目錄結構和格式，就越好。這讓審閱者可以輕鬆地將您的程式碼複製到 Boost 發行版中進行測試。
請確認您的函式庫至少可以在兩個編譯器下編譯和執行。這可以排除明顯的移植性問題。
建議您根據 Boost 軟體授權發布您的程式碼；有關更多資訊，請參閱需求頁面。
4. 調整
討論、調整、重寫。重複直到滿意為止。
此過程的確切細節差異很大。通常是在郵件列表上公開進行，但經常會在私人電子郵件中進行討論。對於某些函式庫，此過程很快結束，但對於其他函式庫，則會持續數月。這通常具有挑戰性，有時會走向完全意想不到的方向。
過去訊息的存檔是了解此流程如何應用於其他 Boost 函式庫的一種方式。
要了解最佳實務以及現有 Boost 函式庫中的一些腳本和程式碼範例，請參閱 Boost Wiki 上的最佳實務手冊。
5. 獲得審查的附議
當您覺得您的函式庫已準備好進入 Boost 時，您需要找到至少一位（但最好是幾位）Boost 社群成員願意公開支持您的函式庫進入 Boost。一個簡單的方法是在Boost 開發人員郵件列表上發布您的函式庫的簡短描述、其 GitHub 和文件的連結，以及徵求支持的請求。
預計那些支持函式庫進行審查的人將至少對函式庫在文件、與 Boost 其他部分的契合度以及實用性方面是否適合 Boost 進行初步檢查。公開支持函式庫進行審查意味著從初步看來，他們認為該函式庫在正式審查期間有合理的被接受機會。預期這些支持者將在正式審查期間自行審查該函式庫，儘管這沒有約束力。
一旦您獲得了一份公開支持您的函式庫進行審查的人員名單，請發送電子郵件給審查精靈，請求將您的函式庫新增到審查佇列中，其中將顯示以下資訊：
- 提交
- 提交者
- 原始碼 (GitHub)、文件 (HTML 網站) 和任何孵化器項目的連結
- 支持此提交進行審查的成員姓名
- 審查經理
- 審查日期
⚠ 為了避免任何利益衝突，潛在的審核經理應向 Boost 社群揭露他們與函式庫作者或函式庫本身的任何關係。
6. 尋找審核經理
為了安排正式審核，作者必須找到一位有能力的志願者來管理審核。此人應具備函式庫領域的知識，以及審核流程的經驗。有關審核經理的職責，請參閱正式審核流程。
作者可以在開發者郵件論壇上討論函式庫，以找到有興趣管理審核的社群成員。如果沒有人主動提出擔任審核經理，可以直接聯繫對該函式庫感興趣且經驗豐富的 Boost 成員。請體諒管理審核是一項重要的承諾；因此，最好私下聯繫該成員（不要在郵件論壇上公開聯繫）。
如果您在使用上述方法 3 週後仍找不到審核經理，且您的提交目標是最終標準化，則有一份 Boost 常客名單，他們也是 WG21 委員會成員，並自願在此類情況下擔任審核經理。請按列出的順序嘗試聯繫他們：Zach Laine、Micheal Caisse、Matt Calabrese、Edward Diener、Louis Dionne、Vinnie Falco、Glen Fernandes 和 David Sankel。
一旦確定了潛在的審核經理，請聯繫審核指導員以獲得批准。審核指導員會根據潛在審核經理在 Boost 社群的參與程度來批准他們。
審核指導員將與作者和審核經理協調，安排一個雙方都方便的日期。
詳情請參閱正式審核流程。
7. 正式審核
在正式審核開始之前，請仔細檢查您的函式庫，再三確認。驗證每個程式碼範例都能正常運作，所有單元測試都能在至少兩個主要作業系統上的至少兩個編譯器上通過，並使用拼寫和文法檢查器檢查您的文件。
請勿在審核期間修改主分支 (master branch) 上的函式庫。請在一個獨立的開發分支 (develop branch) 上修改以回應回饋和審核意見。對於較大的工作項目，請在您的問題追蹤器上開啟問題，以便感興趣的人可以追蹤特定問題的修復進度。
審核經理將考慮社群成員提出的所有審核意見，並決定您的函式庫是被拒絕、有條件接受還是無條件接受。他們將公開發布一份總結決定的報告。如果接受附帶條件，您需要實施這些條件，否則需要進行額外的正式審核。
8. Boost 網站發布
一旦被接受的函式庫準備好發布到 Boost 網站上，提交者通常會被授予 Boost 儲存庫的寫入權限，並被期望將函式庫提交到儲存庫並進行維護。如果您需要寫入權限或無法直接使用儲存庫，請聯繫版主。
9. 人物頁面
如果 boost.org 網站上還沒有您的簡歷和照片（可選，建議使用不太嚴肅的照片！），請將它們發送給 Boost 網站管理員。簡歷是否包含您的電子郵件地址或其他聯繫資訊由您決定。首選的圖片格式是 .jpg，但也接受其他常見格式。首選的圖片大小是 500x375，但網站管理員有照片編輯軟體，可以根據需要進行圖片處理。
10. 生命週期
函式庫是軟體；如果不維護，它們會隨著時間推移而失去價值。在 Boost 開發者或使用者郵件論壇上的貼文可以提醒您潛在的維護需求；請規劃長期維護您的函式庫。如果您不再能夠或希望維護您的函式庫，請在 Boost 開發者郵件論壇上發布訊息，徵求新的維護者，並花時間協助他們接手。
無人維護的函式庫將由社群維護團隊接管。
