背景
前段時間在使用 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