在解决了 2961 个用户反馈后，我做出了这样的改变...

2961 个问题？这么多？没错，Zadig 开源这一年来，也就平均每天十几到几十个问题吧，其实准确的数字不可能知道，但量大是一定的！这一年与社区小伙伴相处过程，也是我职业生涯心得最多/成长最快的一年，想知道我的故事吗？那继续往下看！

大家好我叫 MinMin，本科毕业于 UIUC，（对，就是那个发明了网景 netscape 浏览器的鸡蛋森的母校）

社区小伙伴应该对我比较熟悉，没错，下面这个正是在下。

当然也经常活跃在 GitHub 上，时不时会看到我的回复，这个也是我。

Zadig 的每次发布的英文版 Release Note 翻译，还是我。

工作这么杂，想必不是开发工程师吧，不不不。。下面我给大家讲讲我的研发经历。

职场摸索

那是 2020 年的 11 月，在经历 2 年的职业探索期后，以纯正的 Golang 工程师加入到 KodeRover 团队，当时主要做一些业务模块的开发，彼时对云原生和容器技术产生了浓厚的兴趣。回想过去多少有点好高骛远、眼高手低，但经历一系列打怪经历，像是代码仓导入服务，工作流定时器、触发器的重构等功能的开发，直到 2021 年 7 月 Zadig 正式开源，我的职场之路开始有了一些新的变化。

升级打怪

在 Zadig 宣布开源的时候，有大量用户蜂拥而至，我主要负责安装脚本的编写。 没想到的是，这个功能成为了我和社区建立连接的一个桥梁。安装作为第一步，直接影响试用体验，通过分析，我们将安装分为几类场景：

1. All in One 针对只有一台主机的场景，内置 K8s，快速搭建起来 Zadig，用于体验。
2. 正式使用的场景，可以基于 K8s 环境快速安装 Zadig 并做持久化。
3. 高阶使用的场景，基于 Helm 命令安装，可以自定义很多配置项。

虽然当时做了较多的准备，但发布出去以后社区群里依然炸了锅，还是有大量由于环境特异性导致的安装问题，微信吐槽群中的问题非常多，几乎都是安装问题，说实话当时我压力挺大的，心态也比较慌的，每天基本上要花 80% 以上的时间泡在微信群和 GitHub 上，互动解决安装问题，同时感觉到很难集中精力去完成较大功能模块的设计和实现。我当时有点想退缩，心想这样子的时间分配是不利于个人开发能力提升的。

期间借 1on1 交流和 Landy 沟通过这方面的顾虑，她跟我说了一段话 “写代码是很重要的，产品被人稳定的用起来更为重要，解决问题的能力对于一个工程师比写几行代码要重要的多，当然你可以选择退到产品之后”。

我咬了咬牙，决定把这座大山翻过去。。。

在 100% 开源后的紧接着的第二个版本（v1.3.0），我们决定花大精力做第二轮的安装易用性深度优化，随即：

1. 申请了大批云资源做实测：All in One 脚本经过了近 50 台主机测试，基于 K8s 的脚本也经过了腾讯、阿里、华为、AWS 等 23 个公有云 K8s 版本和自建标准 K8s、镜像仓库、对象存储实测。
2. 全员测试，做第一个用户：我们推崇"Eat own dog food"，每一个 Zadig 开发者也都是一个用户。针对兼容性测试，我们内部组织了两次安装体验会，全员在小黑屋集中测试。

于是有了 兼容性列表。后续在这个能力之上，又做了镜像瘦身、内置 Regsitry、脚本进一步缩短，实现了 10 分钟内就能安装和体验 Zadig。时至今日，安装 Zadig 已经变成一件 so easy 的事情了，社区吐槽群的问题也越来越高阶和深入。

开悟之坡

回想过去那段时间，我的心态经历了较大变化，这期间发生一些事件让我对社区交流和开发者这件事有了新的认识。

第一件事情其实是社区小伙伴对 Zadig 产品的期待和评价，每次发版都有一种被社区小伙伴推着走的感觉，不管多晚，总有一些小伙伴在”嗷嗷等待“。

作为最多接触外部反馈的我，认识到了处理社区问题其实不是一件很 “low” 的事情， 恰恰相反，高效的处理社区问题是一个非常好的打磨产品的机会，是让 Zadig 的一段代码产生价值的必经之路。这个过程中随着一个个问题被解决，我的网络问题、K8s 知识、沟通和协作能力都得到了很大的提升。

第二件事情是 Zadig Contributor Bootcamp 的建立，让我对社区内容输出的部分有了更多的了解。 这个活动的建立其实是个很自然的过程，当时为了 Zadig 未来更好的扩展性我们规划了 v1.3.1 底层架构的大规模，引入关键的云原生组件。版本发布后，有很多小伙伴对 Zadig 的架构非常感兴趣，也会有一些相关讨论，当时我找到 Landy：既然那么多人感兴趣，我们就应该分享出去，要不我们试着分享几期。当时我也没多想就粗略规划了下，就一些比较重要的内容和社区发起腾讯会议邀请，没有做任何运营就直接扔到群里。 其实当时对于 Bootcamp 效果没有太多期待也有点忐忑，结果现在一期一期办下来，每期都稳定有 30 来个参与者积极提问、交流、献计献策，这让我充分感受到了开放的力量，正确的事情总会发生。

第三件事情其实是如何让社区的反馈处理过程高效，本身也是一种成长。社区小伙伴各种需求各种问题都有，有时候真的想发火，如果不能很高效的处理，将会把自己拖入低效率状态，我抽象了几类问题：

• 特别小白的问题，比如基础的网络、Dockerfile/YAML 编写这些，刚开始会手把手教，后来我们复盘觉得这样是很不合适的，这不利于更好的社区建设，于是后续此类都建议小伙伴自己摸索

• 产品使用问题，直接扔文档，文档是最好的工具，可以系统性的阐述一个能力，Zadig 文档使用率目前也飞速提升，这非常有利于高效的学习和使用 Zadig，单纯的拿来主义是行不通的，也不是社区倡导的。

• 场景接入问题，直接扔公众号最佳实践，Zadig 在大量企业用户场景下，沉淀了很多好的实践，它山之石可以攻玉，能很大程度的帮助用户找到适合自己的路径。

而现在随着社区小伙伴越来越多，用户实践越来越深度，有很多热心开发者自己充当起了布道师，在此特别提到社区的乔克、Aurora、还有一些同学像“起于微末”分享他们的使用经验，也交流越来越高阶的技术话题，这才是正确的社区打开姿势。

未来展望

自加入 KodeRover 团队以来，随着工作内容越来越多，心态也随着成长而不断改变。 从刚刚入职时候的干劲十足，到经历职责转变后的迷茫不安。最终，这种对于未来的迷茫，在实践中都转变为了对于未来的信心。

现在的我，非常相信社区的力量，也希望能推动 Zadig 的快速成长的同时，与社区内的所有小伙伴深度链接，一起成长。

接下来将是一个新的开始，我将会有相当一部分投入社区的建设，研发的内容也会更加侧重在开发者体验，最近我在做的一件事就是建设 Zadig 论坛来沉淀更多有价值的交流。

One more thing：社区论坛来啦

大家一定好奇每天社群那么活跃，我们是怎么有效处理社区反馈的？其实我们每天会将有效反馈记录到文档中，每周会邀请产品、架构进行半个小时的讨论会，最终沉淀为需求项。每次发版后都会 at 到相应的小伙伴，截至目前社区问题反馈解决率达到 70%。

社区论坛的推出，让沟通更加的高效，知识更好的沉淀。有了论坛，不仅可以链接 Zadig 与用户/开发者，还可以实现开发者之间的互联。微信社群我们会继续保留，仍然能及时听到大家的声音。

来不及解释了，快去 https://community.koderover.com 注册论坛抢占 ID！

Zadig，相信开放的力量。欢迎加入 开源吐槽群🔥

Zadig on Github
Zadig on Gitee