Davinci 项目通过 Project 来管理开发计划和维护清单。
开发计划在 Roadmap 中管理。Committers 可以在 To do 栏中自行添加功能卡片，当功能还在卡片阶段时，意味着此功能还在设计和讨论阶段，卡片中应当包含：
- 功能描述标题
- 功能设计明细及原理
- 如果包含子功能项，请逐一列出
当功能经过设计和讨论阶段之后，可以将功能卡片转成 Issue，并打上相应的 Tags。如果有 Committers 计划开发实现它，请将 Issue 拖到 In progress 栏中，并添加自己到 Issue 的 Assignees 列表中。请确保功能经过充分设计和讨论之后再开始开发，未经社区讨论过的功能 PR 不会被合并。
维护清单在 Maintenance 中管理。Committers 可以在 To do 栏中自行添加 bug 或亟待修复的缺陷类 Issue。同样的，如果有 Committers 计划开发修复它，请将 Issue 拖到 In progress 栏中，并添加自己到 Issue 的 Assignees 列表中。
为保证开发高效以及目标专注，建议每位 Committer 在所有 Project In progress 栏中的 Issue 不超过2个。
当前阶段，如无特殊需求，每月发布一个 minor 版本，正式版本发布不遵循此规则
版本发布之前需要确认
- 所有功能可以正常运行
- 与此版本相关的 Issue 和 PR 已经被正确处理
编辑更新日志以及升级版本号
- 新建一个 PR 将 dev-0.3 分支合并到 master，所有发布操作需要在 master 分支上进行。注意！不要使用 squash merge！防止提交信息丢失！
- 从 master 新建一个 release 分支用来做发布的修改（例如：git checkout -b release-beta.7）
- 在 CHANGELOG.md 里添加发布日志，可以用 compare 功能找到当前和之前版本的区别，将有价值的改动如实反馈给用户
- 对用户使用上无感知的改动建议（文档修补、微小的样式优化、代码风格重构等等）不要提及，保持 changelog 的内容有效性
- 用面向开发者的角度和叙述方式撰写 changelog，不描述修复细节，描述问题和对开发者的影响
- 尽量给出原始的 PR 链接，社区提交的 PR 改动加上提交者的链接或 Issue 链接
- 如果不确定改动的真实目的，可以向提交者进行咨询
- push release 分支并发起 changelog 的 PR 请其他 Committee 成员进行 Review
- PR 的内容里填上 changelog 内容，好处是版本 changelog 的 PR 会关联在各个 issue 中，很容易知道 Issue 在哪个版本被改了
正式发布 release
- 更新日志的修改合并后，删除 release-x 分支，给当前 master 分支打上版本号 tag
- 上传 release 包，发布 release note