社区治理
天工由南京大学 Dislab 发起。欢迎高校、企业及独立开发者参与贡献。
社区通过公开讨论、技术评审与共同承担责任开展协作。项目职责依据个人贡献与判断力确定，机构归属本身不自动赋予职务或仓库权限。
谁负责什么
| 角色 | 职责 |
|---|---|
| Project Chair／项目主席 | 协调项目方向、社区讨论与研究合作，协助处理跨组件问题，以及技术讨论后仍未解决的分歧。 |
| Maintainer／维护者 | 负责技术质量、共享接口、兼容性、评审、发布准备、文档维护和贡献者支持。 |
| Contributor／贡献者 | 参与代码、工厂场景、调度算法、实验、测试、文档、翻译、评审或用户支持，无需任命即可参与。 |
社区委员会介绍项目主席与维护者，贡献者与致谢介绍贡献者，并记录系统与网站仓库中的贡献。
如何做出决定
通过相关 Issue 或 Pull Request 讨论技术工作，说明预期行为，并依据证据寻求共识。记录考虑过的方案、最终决定及其理由，方便其他人理解和继续参与。
- 常规变更： 由作者以外的维护者评审修改及其验证结果，再合并代码。
- 重大变更： 涉及共享接口、工厂执行语义、调度接口约定、实验结果或兼容性时，先讨论设计，再进行实现，并补充受影响的示例、验证结果和文档。
- 未解决的分歧： 由项目主席协调相关维护者与贡献者讨论并形成处理结论，在对应 Issue 或 Pull Request 中记录；技术修改仍需维护者评审。
仿真与算法修改应按需提供工厂实例、随机种子、参数和可比较的实验结果。网站修改应保持中英文内容一致。Pull Request 检查清单说明提交时需要包含的信息。
如何成为维护者
贡献者可以表达持续承担维护职责的意愿，也可以提名自己熟悉其工作的伙伴。请先与现任维护者沟通，介绍已有贡献、希望承担的工作范围，以及需要的支持。
项目主席与维护者共同考虑持续贡献、技术和评审判断力、协作能力、对架构的理解，以及支持其他参与者的意愿，不设置固定的 Pull Request 数量、雇佣关系或参与年限要求。
与熟悉候选人工作的参与者讨论提名，并处理实质性意见。职责达成共识并由候选人接受后，记录工作范围、配置所需权限，同步更新中英文社区名单和作者信息。职务名称本身不自动赋予仓库权限。
如何处理利益冲突与行为问题
保持相互尊重，围绕具体行为、证据与改进方案开展讨论。涉及直接个人利益冲突时应主动说明；涉及本人任命、免职或权限调整时，应回避相关决定。来自同一机构本身不构成利益冲突。
项目主席与维护者协调处理分歧，直接涉及事件的人员应回避处理。敏感的人事或行为问题可通过项目联系人，选择未涉及事件的联系人私下反馈。提供理解问题所需的信息，并避免在公开 Issue 中披露个人信息。
在保护个人隐私的前提下，公开记录技术决定和适当的处理结果。受到决定影响的参与者可以请未涉及事件的项目主席或维护者复核相关理由与证据。
暂停参与后如何交接
成员可以与维护者讨论参与时间减少或职责调整，并为尚未完成的评审、Issue、发布、文档以及工作所需权限安排交接。
社区名单与仓库权限应随保留或移交的职责同步更新。毕业或变更工作单位不会自动终止角色；历史贡献继续在贡献者与致谢和仓库记录中保留。