背景
前段時間在使用 Pulsar 的 admin API 時，發現其中的一個接口響應非常慢：
admin.topics().getPartitionedStats(topic);
使用 curl 拿到的響應結果非常大，同時也非常耗時：
具體的 issue 在這裏：https://github.com/apache/pulsar/issues/21200
後面經過分析，是因爲某些 topic 的生產者和消費者非常多，導致這個查詢 topic 統計的接口數據量非常大。
但在我這個場景其實是不需要這些生產者和消費者信息的，現在就導致這個 topic 無法查看狀態，所以就建議新增兩個參數可以過濾這兩個字段。
流程
因爲涉及到新增 API 了，所以社區維護者就建議我起草一個提案試試：
什麼時候需要提案
此時就涉及到什麼情況下需要給社區發起一個提案的問題了。
在官方的提案指南中有着詳細的說明，簡單來說就是：
- 對任何模塊新增了 API、或者是重大改動的新特性、監控指標、配置參數時都需要發起提案
- 對應的如果只是對現有 bug 的修復、文檔等一些可控的變更時，是不需要發起提案的，直接提交 PR 即可。
提案步驟
起草
首先第一步就是根據官方模版起草一個提案：
重點描述背景、目的、詳細設計等。
併發起一個 PR，如果不確定怎麼寫的話可以參考已經合併了的提案。
郵件討論
之後則是將這個 PR 發送到開發組郵箱中，讓社區成員參與討論。
這一步可能會比較耗時，提案內容可能會被反覆修改。
發起提案的一個重要目的是可以讓社區成員進行討論，評估是否需要這個提案或者是否
有其他解決方法。
發起投票
經過討論，如果提案獲得通過後就可以發起投票了，至少需要有三個 binding 通過的投票後這個提案就通過了。
雖然任何人都可以參與投票，但社區只會考慮 PMC 的投票建議；投票的時效性也只有 48h。
48 小時候便可以發一個投票結果的郵件，如果達到通過條件便可以通知參與投票的 PMC 合併這個 PR 了。
實現提案
之後就是沒啥好說的實現過程，因爲通常我們是需要在提案裏詳細描述實現過程以及涉及到修改的地方。
總結
只要提案被 review 通過後實現起來就非常簡單了，跟着提案裏的流程實現就好了。
這點非常類似於我們在企業中對某個業務做技術方案，如果大家都按照類似的流程嚴格審覈方案，那實現起來是非常快的，而且可以儘量的減少事後扯皮。
所以最後我的實現 PR 提交之後，都沒有任何的修改意見，直接就合併了；也大大降低了審覈人員的負擔，提高整體效率。
以上就是我第一次參與 Pulsar 社區的提案過程，我猜測其他社區的流程也是大差不差；其中重點就是異步溝通；大家都認可之後真的會比實時通信的效率高很多。
具體的提案細節可以閱讀官方指南 https://github.com/apache/pulsar/blob/master/pip/README.md