大家好，从上次团队内部会议以来，由于工作繁忙，没组织内部交流。
不过我也一直在思考未来框架开发的重点、边界以及团队协作的事情。
本次内部会议交流的要点，是2022年下半年的框架开发事项，以及相关事项的跟进人。
我下面列举了几项参考的事项，大家可以一起讨论。内容可以增删，根据讨论结果来定。
会议地址
郭强 邀请您参加腾讯会议
会议主题：框架开发下半年事项讨论
会议时间：2022/07/28 20:00-21:00 (GMT+08:00) 中国标准时间 - 北京
点击链接入会，或添加至会议列表：
https://meeting.tencent.com/dm/KJGPbYJ91QDe
#腾讯会议：318-380-501
复制该信息，打开手机腾讯会议即可参与
会议视频
https://www.bilibili.com/video/BV1tY4y1P7jP/
讨论事项
| 讨论工作事项 | 优先级 | 难度 | 说明 | 跟进人 |
|---|---|---|---|---|
| 入门资料完善 | 高 | 低 | 从去年年底到现在加入的新人比较多，新人对框架的反馈主要在入门资料不完善，期望提供入门资料循序渐进指导新手入门。 | |
| 框架接口适配层工具及组件 | 高 | 很高 | 接口协议层到框架内部实现的接口适配层，难度比较大，会比较花时间。会需要长期跟进。 | |
| 微服务组件-配置管理-Polaris实现 | 高 | 高 | 基于Polaris的配置管理接口实现，通过社区包提供。 | 智刚 |
微服务组件-超时重试（gretry） | 中 | 中 | 提供通用性的超时重试基础组件，至少支持 | |
微服务组件-指标采集（gmetric） | 高 | 高 | 提供通用性的指标采集功能，通过接口化的形式提供。目前业务项目大多直接采用 在框架组件层面， 默认提供基于纯内存的实现。 | |
微服务组件-限流熔断（glimit） | 中 | 中 | 限流和熔断其实是两个功能。不过归根到底都是对流量的限制。限流一般在客户端控制，熔断需要由业务端设定一定条件触发熔断器机制。该组件的难度在于限流的逻辑实现，熔断条件的输入设计，可以参考现有的第三方相关组件实现。 | |
微服务组件-消息队列（gmq） | 低 | 很高 | 提供通用性的MQ接口管理。将MQ常用的消息写入、读取、回执做成接口形式，并提供依赖注入的接口，由业务端注入具体的实现。这块组件的难度在于接口的抽象化设计，如果设计得不好可能接口就不通用便失去了组件的意义。 | |
Redis组件与框架的解耦 | 中 | 中 | 目前框架中的 目前已有不完善的PR可供参考： | |
| 框架单测覆盖率达到80% | 中 | 中 | 开源项目80%的单测覆盖率是一个门槛。 | 黄骞 |
| 框架英文文档完善 | 中 | 中 | 国际化文档的跟进。 |
其他事项
Pull Request的规范管理
由于框架目前已经逐步转为社区驱动的开源项目，在PR这块的管理也需要规范化管理。秉承以下三点原则：
- 框架所有的代码改动需要通过PR而不是Commit。
- PR至少需要需要一名社区开发成员执行Code Review通过才能合并进入主库。目前社区开发成员有24名，欢迎有更多感兴趣参与长期贡献的同学加入。
- PR需要Maintainer才能执行Merge操作。目前框架的Maintainer只有1名，随着社区驱动的发展，若有较为熟悉框架思路的同学出现，会再增加一名。
- 谁提出谁跟进。如果PR长期没有活跃，需要PR提出者跟进PR的Code Review，主动找到开发团队成员提出Code Review要求，直至被成功合并到主分支。
3 Comments
海亮
建议教程独立出来一个空间，与查文档分开。
海亮
小版本打tag看看有什么办法把改进内容写到release里面。
海亮
Releases · polarismesh/polaris (github.com)