背景

前段时间在使用 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 社区的提案过程，我猜测其他社区的流程也是大差不差；其中重点就是异步沟通；大家都认可之后真的会比实时通信的效率高很多。

技术前沿拓展

前端开发，你的认知不能仅局限于技术内，需要发散思维了解技术圈的前沿知识。细心的人会发现，开发内部工具的过程中，大量的页面、场景、组件等在不断重复，这种重复造轮子的工作，浪费工程师的大量时间。 介绍一款程序员都应该知道的软件JNPF 快速开发平台，很多人都尝试用过它，它是功能的集大成者，任何信息化系统都可以基于它开发出来。

这是一个基于 Java Boot/.Net Core 构建的简单、跨平台快速开发框架。前后端封装了上千个常用类，方便扩展；集成了代码生成器，支持前后端业务代码生成，实现快速开发，提升工作效率；框架集成了表单、报表、图表、大屏等各种常用的 Demo 方便直接使用；后端框架支持 Vue2、Vue3。如果你有闲暇时间，可以做个知识拓展。

看完本文如果觉得有用，记得点个赞支持，收藏起来说不定哪天就用上啦～