@0x663 社区一直都在有新的同学贡献，只是因为今年主要精力在搞 AI ，所以一个季度只发一个版本了，然后在 java 上主要功能都比较完善了，现在都是些小 bug 修改，所以更新频率也自然降低了

我现在也主要写 go ， 这种路由，go 也没有注解，搞文档生成就是比较烦， 注释也要写一大坨。我以前搞 java 开发开源的 smart-doc 在 spring 这种技术栈上生成接口文档使用起来就很爽。

@securityCoding gRPC 也是使用 pb 格式定义的

@zhout 同个模块下 controller 级别可以分组的，这个可以看官方文档有分组配置，当然不同用户可能对 API 的分组需求有些不同，很多场景用户不提 issue 我们可能没法覆盖到。我们和 swagger 有很多区别，我们目标给研发链提供更多的支持，所以支持多种接口协议的文档生成，性能测试脚本的生成。随之时间沉淀 smart-doc 在国内知名大厂用户反而更多了。

@ByteCat 不支持 Kotlin ，确实有很多用户希望我们支持 Kotlin 和 golang 这些语言，但是社区没有足够精力支持。Java 开发 gradle 和 maven 都可以用。

线设计 API 文档和工具并不冲突，比如我最近的开发方式：
1 、分析需求文档
2 、用自己开发的 SpringBoot 脚手架创建一个空的 SpringBoot 项目用于建模 API 接口
3 、思考需求，在 2 步骤创建的 API 建模项目中定义空结构体和空 Controller 接口
4 、用 smart-doc 扫描定义的空接口生成 API 文档
5 、用生成的 API 文档和前端和产品人员完成定稿和微调。
6 、启动正式项目开发，完全复制一些前面编写空接口的结构体。

@rookie2luochao 目前主要在国内仓库，torna 是因外一个社区的人开发的，我属于项目发起人，docker 镜像下载量 5 位数+级别的，https://gitee.com/durcframework/torna

@rookie2luochao yapi 不怎么维护，而且他的后台用 nodejs 开发的也不太符合现在很多公司的主流技术了，二次开发不行。所以我做 smart-doc 这个工具的时候发起了 torna ，torna 现在国内部署量还可以，但是受限于前端，目前社区也缺人力。

ui 这种还是适合小型组织，在大厂 ui 不怎么行的通。包括在应用里集成 swagger 也不太行， 侵入性会被很多团队放弃， 压法阶段基本上走下正常单元测试就可以， 不需要什么界面去自测。成熟组织一般就是 yapi 和 torna 这种具备集成和管理的系统。

go 语言做 web 开发，api 管理工具不是最重要的，生成 API 文档的过程很烦，go swagger 页要求程序员写一堆的注释。
我自己是 java 文档生成工具 smart-doc 的作者。目前也只一个主力 go 语言的应用开发者。管理工具其实已经很多了，针对 go 语言文档生成端非常的弱

@xgfan 你可以理解为就是一种宣传和社区运营，让更多人来一起参与贡献，至于礼物多少价值真正参与开源的人并不在乎这些，所以也并不怕被喷。我们也是真正的做开源，项目在国内用户也很多，我们问心无愧。

@dianso 不能用物品价值去衡量开源社区奖品，奖品对于贡献者是鼓励和纪念意义。大多数开源社区本质是没有任何商业盈利的，也没有谁规定必须任何社区要给 Committer 发奖品，社区大多数的奖品也是文化衫或者是技术相关的图书。
我们非常尊重行业每一个真正的开源技术社区和无数的开源贡献者。

@musi 这个只是个宣传，目前也没有专业的社区运营人员，没什么尬的，至少我们也是国内极少数真实的给了贡献者一些小奖励的开源社区。也是为了鼓励更多人参与开源社区的贡献。

@Philippa swagger 对群主框架就没啥用的，go 框架也能用 swagger 搞，但是我们发现这东西无脑让写一堆非标注释。理想的情况就是既不去影响用户的代码，又不能要求用户写一堆非标注释增加开发的负担。smart-doc 在国内在 java 领域非常受欢迎也是这个原因。我们的贡献者甚至都有小米、快手这些公司的。

无注解框架的有一个痛点就是搞接口文档比较难，其实很多开发都不想手写文档，像我们开源的 smart-doc 对 spring 这种注解路由的框架，工程师已经只需要写几行简单的 javadoc 注释了。生成的文档质量也远超手写的。我同时也是一个 golang 开发者，我们发现 go 的框架基本也是声明式路由，搞文档就很头痛

@imianba2zz 你这个是很好思路，但是这个很难推广落地。减少了注释，但是比如像字段的注释，验证规则这些没没法通过网络数据来抓取，文档不完善让开发再去改非常难。go 框架主要是入口层面没有没法直接知道返回和入参，导致注释很多。如果你看现在 smart-doc 在 java 那块支持就很少，注释就只是描述下字段，简单写个方法用户说明。另外是像 smart-doc 在一些公司目前在 java 上是在 CI 的构建层面去工作的。压测其实并不需要自己去开发压测工具，我们的目的是生成工具需要的标准文件，然后倒入进去测试，就是支持现有的开源生态。

社区提案 https://github.com/TongchengOpenSource/smart-doc-golang/discussions/1

@jaycelhz 没特殊要求哈，愿意的就可以参与

@0xGnaixEuy 技术没有要求，社区更多的是愿意参与贡献，新手也是可以的，慢慢搞