Proposal accepted in GLCC 2023

docs/README.md

@@ -0,0 +1,11 @@
+Welcome to use `atest` to improve your code quality.
+
+## Get started
+TODO
+
+## Release Notes
+* [v0.0.12](release-note-v0.0.12.md)
+
+## Articles
+* [Introduction](introduce-zh.md)
+* [GLCC 2023 announccement](glcc-2023-announce.md)

docs/glcc-2023-announce.md

@@ -0,0 +1,30 @@
+很荣幸与屈晗煜在 GitLink 编程夏令营（GLCC）活动中协作
+
+作为一名软件工程师，天然有着追求代码质量的执念。相信很多人对代码的优雅、质量有着自己的认识，业界也有不少的共识，其中有一条我认为是非常重要的——代码可测试。
+
+作为一名研发，只关注功能可测（容易测）是远远不够的。从严谨的角度来看，我们每提交一个 PR（泛指有新的代码准备如何主分支）时，需要提供你已经测试通过的“证据”。
+仅仅基于对团队成员的信任（或 QA 人员的回归测试）是很难从软件工程角度来保障代码质量的。研发 leader（或 QA）在面对 PR 时，可能会问到：你的代码自测过了吗？
+这也许是一个毫无意义的提问——可能很大一部分人会出于面子考虑直接回答”测过了“，另外一些诚实的人会说”忘记了“。在我看来，我们需要避免类似的无效、低效沟通；
+既然都是研发，那为什么不用测试代码来证明你的逻辑（或业务）代码的正确性呢？
+
+单元测试、接口测试，是两种非常有效的、相对低成本的方法，前者可以确保函数的逻辑正确，后者可以确保 API 总是按照既定的输入和输出格式来处理。对于后端研发来说，
+能把这两种方法用起来的话，低级的、关联性的 bug 已经很难再流入到代码仓库的主干分支中了。[API Testing](https://github.com/LinuxSuRen/api-testing) 项目
+的发起，主要是为了持续提高我自己的代码质量，并且希望能帮助到有需要的其他人（研发或测试）。这个项目提供了诸如：命令行、CICD、VS-Code、浏览器等场景对接口测试的需求，
+目标是在尽量不改变已有研发习惯的前提下，使得大家可以便捷、简单地借助接口测试提高自己的代码质量。文中多次提到代码质量，本项目的后端 Golang 部分的单元测试
+覆盖率目前为 94%，之后也会持续提高测试覆盖率（包括前端等代码的）。
+
+几周前，了解到 [GLCC](https://www.gitlink.org.cn/glcc) 这个活动还在招募开源项目。于是尝试联系官方负责人，咨询是否接受个人发起的开源项目（而且
+还是一个处在早期阶段的项目，截止本文只有 77 次 commit）。另外我感到惊喜和意外的是，这个项目不仅受到官方的认可与资助（完成项目议题的同学可以得到 6000 元奖励），
+而且还有 5 位同学对这个项目表示感兴趣，收到 4 份申请书。之后，我分别从多个维度尝试选择与项目匹配的申请人：是否在本项目中提交过 PR 或 issue、是否有邮件等
+沟通、议题设计、示例代码或 POC、GitHub 是否活跃、时间安排是否充足等（前面每一项的权重略有不同）。要知道，大部分同学都已经通过邮件和我进行了多次沟通，
+而且有两位同学也分别提交过 PR、issue，放弃任何一位申请人都是于心不忍的，因而我也尽量以相对客观的方式来做出选择。
+
+让我印象比较深刻的是，屈晗煜 ([Ink-33](https://github.com/Ink-33)) 同学在申请书中给出了他对 gPRC 的一些调研结果，以及如何实现 gRPC 接口测试的大致思路，甚至还有一些实验性的代码。另外，他虽然只是大一新生，但编码经验却不少；能看得出来他确实是对编程很感兴趣。
+
+最后，希望其他几位同学能匹配到其他项目，并能在参与开源的过程中有所收获。
+
+本文相关链接：
+* https://github.com/Ink-33
+* https://github.com/LinuxSuRen/api-testing/issues/81
+* https://www.gitlink.org.cn/glcc/2023/subjects/detail/656
+* https://www.gitlink.org.cn/linuxsuren/api-testing/issues/1