我维护 BIThesis 已经有将近两年的时光了。彼时我还仅仅是一个对 的使用者；而此时我已经开始接触到 更深层的生态，算是勉强入门，成为一个开发者。BIThesis 也从最初仅仅为本科生提供毕设相关模板的规模，到现在并入了研究生模板以及 Beamer 的支持。
在维护 BIThesis 的期间，我除了渐渐懂得从 开发者的视角考虑问题，也学会从“代码”到“项目”，再到“产品”的视角看待 BIThesis （也包括其他的开源项目）。
从代码上来看，BIThesis 提供了开箱即用的功能，但仍有一些问题存在：
- 研究生学位论文模板由于刚刚迁移，还没有根据最新标准进行更正。
- 部分样式控制代码仍然暴露给了用户，没有起到分层的作用。
- 给用户提供的接口不够灵活，增加了用户的心智负担。
- 内部代码仍旧缺乏健壮性，也间接地增加了用户的心智负担。
- 有一些不是控制文档结构的代码被放入的
.cls中，理论上应该放入到.sty中。
其中，第二、三、四问题是相互依存的：因为维护者对代码不够有信心，因此不敢直接将样式加入到 bithesis 中（担心一旦出问题难以修改）。
长期来看，BIThesis 还是要积极迁移到 LaTeX3 上，提供键值对的配置方案；并且，采用更多最佳实践来提供健壮的代码。
先完成再完美，首先要做的是第一条：跟上目前的学校标准。
从项目的角度来看，BIThesis 目前由 bithesis 宏集、各种模板和 WIKI 组成；其社区目前存在于 Github 和 QQ 群。
我们服务的群体（曾）是北理工的本科毕业生，目前希望扩大到所有毕业生。但是在未来，这个目标还远远不够。BIThesis 想要成为北理工 LaTeX 学术写作的开源社区。
目前我们的代码托管在了 Github 上，分为存放 LaTeX 代码的 BIThesis 仓库和在线文档的 BIThesis-wiki。整体的工作流是这样的：
- 从社区收集需求，通过 Projects 或者 Issues 添加为一个任务
- 切分支、代码编写、提交 PR
- 通过单元测试
- Reviewer 进行回归测试
- 合入并准备考虑是否要发布新版本
新版本的发布流程如下：
但是，目前整个项目在协作开放还存在一些问题：
- 贡献流程不够详细。目前有简单介绍 Makefile 的使用，但是及不全面，也不具有针对性。一个友好的流程是：如何从头开始比较完整地完成一处微小的修改。
- 暂时没有其他的维护者。
代码和项目都是凭我一人之力所能触及的地方。但是从长远的角度来看，BIThesis 是一个产品——而这并非我一个人就能完成。BIThesis 存在的土壤是北理工良好的学术生态。而 BIThesis 希望成为这学术生态中的一环，反过来促进高质量的学术写作——此即为愿景。
另一方面，宣传是非常重要的。这里有两层意思：
- 通过教务部和研究生院的认证。只有这样，同学才能放心的使用我们的项目。而这也意味着需要和老师（或者有老师帮我们）打好关系。
- 让更多的同学了解到我们的项目。这就需要通过学校官方、自媒体或者校内的其他宣传途径。
由于 BIThesis 与毕业季高度关联的这个特性，也有额外的一些事情需要作为开发者的我去格外注意的：
- 在毕业季的时候，尽量不要引入 Breaking Changes、增加新 Feature；可以更多着手于文档建设和答疑解惑。（原因来自于 Hyrum's Law）
- 在非毕业季时，可以尽早开始联系学校、并引入一些 Breaking Changes。
- 文档中的指南不管是否提供过程，都至少要提供结果。