总体理念#
以下内容仅为指导原则，旨在帮助您理解我们的工作方式。 请随意灵活变通 ;-).
SUMO 开发遵循“代码优先”（Code First）的原则。 当在开会和编写代码之间犹豫时，请选择编写代码。 当在编写设计文档和编写代码之间犹豫时，更倾向于编写代码。 这带来了相对较高的开发速度，但也导致了正式文档的缺乏。
多样性被视为一种优势。我们不强制规定或推荐特定的标准平台或 IDE 来使用或开发 SUMO。 我们努力让任何拥有 C++11 兼容编译器的环境都能工作，并积极支持三大桌面平台（Windows、Linux、macOS）。
Git 与发布工作流#
我们在 "main" 分支上进行开发，没有专门的 "dev" 分支。 没有针对个别版本的分支（只有标签），我们也不向后移植关键修复，因此没有并行的开发线。换句话说，如果 SUMO 1.10.0 已经发布，就永远不会出现 SUMO 1.9.1，另请参阅 版本控制。
虽然强烈建议在推送（push）之前运行测试，但这并未通过钩子（hooks）或强制性的拉取请求（pull requests）来执行。偶尔甚至会发生推送导致构建中断的情况。我们支持钩子，但它们是自愿使用的。
每个开发者都可以自由使用特性分支，但这主要作为一种“备份”工具，很少用于协同工作。
Issue 工作流#
我们使用 GitHub Issues 来处理许多不同的事情。它是存储想法的地方（主要在 待办事项 中），是提问的场所（questions），也是所有当前开发任务的集中记录地。
我们每两周在开发者会议上进行 Issue 分类（triage）。如果您想参与，请给我们发送 消息。 目标是最终每个 Issue 都处于（至少）以下状态之一：
- 标记为 "question" 或 "review needed"
- 拥有（编号的）里程碑（milestone）且至少有一名指派对象（assignee）
- 在待办事项（backlog）中
- 已关闭（closed）
每个人都可以自由处理任何 Issue，即使它已被指派给其他人。当然，在开始工作时，您应该联系指派对象并同时将自己指派为处理人。将 Issue 指派给里程碑并不提供保证，但如果 Issue 拥有 "important" 标签或被视为回归（regression），我们会尽最大努力。
强烈建议为您的代码编写 测试，并仅在拥有测试的情况下才认为 Issue 已完成。我们不会因为缺乏活动而关闭 Issue（问题除外，见下文），即使在问题解决后也不会关闭评论。
问题（Questions）#
每个问题都值得得到回答，即使只是文档的链接。如果您认为问题已得到解答，请关闭该 Issue。如果您需要原作者提供更多信息，请添加 "awaiting reply" 标签。两周后，除非您怀疑背后存在真正的 Bug，否则可以关闭该 Issue。