对比隔壁 RISC-V 生态的东亚时区双周会（链接为最近一期的活动，供参考，主办方会在活动结束后将 PPT 归档）：
- RISC-V 双周会是故意安排在东亚、澳洲时区的工作时间。龙架构双周会则完全相反，故意安排在休息日
- RISC-V 双周会服务于“小伙伴”（归档库 README）或“partners”（“合作伙伴”，community.riscv.org 活动说明），这两种写法在理解上存在区别，但截至目前似乎没有导致过什么问题
考虑到 龙架构对相当一部分贡献者不是本职工作 这一点——甚至双周会上的讨论内容也未必符合参会的龙芯员工的职责甚至立场，一个谈论技术话题但位于休息时间的双周会，当然属于制度创新。但也正因如此，进入“改革深水区”也就变得很正常。隔壁双周会进行了 90 多期，都没有遇到我们两期活动即暴露的问题（当然也可能发生过了，只是我没去过那个会，不知道而已）；尽管如此，目前我认为建立一个简短的说明（“宪章”，“charter”）性质的文档即可较好满足预期管理的需求。
另外一些思考：
由于龙架构生态的参与人数不如其他架构多（个人观测 llvm 的 Targets 目录下相应提交数量，龙架构的活跃程度大约在 RISC-V 的十分之一，主流架构如 x86、AArch64 更是另一个程度），如果双周的沟通频率达不到非研发人员对“用户可观测产出”的合理预期，那么势必需要为非研发人员单独拆分品牌并沟通此改变。
个人不是很建议单单为了最终用户每期都有狠活儿看，就把双周会降级为月会，除非：
- 多期双周会的结果都能表明龙架构生态发展没有如此迅速，并且
- 一旦有重要事件发生或即将发生，仍然有方法确保能快速召集社区人员，发起计划外的会议，并且
- 所有社区成员都能有畅通的渠道通报上述的“重要事件”并发起会议：因为核心贡献者们都已经有通畅人脉了，所以重点在于社区的其他人是否也能享受相同的号召力。
合理怀疑，这么做有一个坏处：社区的“小虾米”会害怕自己的提议不够专业、浪费时间，就不去打破流程、进行上报了。——如果在做好预期管理之后，双周会的内容能够维持一个非研发人员也能勉强不掉队的程度，他们在会上评论、在群里接龙预征集提问、甚至鼓起勇气编辑 PPT 的心理负担就没那么大，因为他们没有在打破流程。