跳到主要内容

关于我们

TGOSKits 是一个面向操作系统与虚拟化方向的开源社区，由来自高校、科研机构和企业的开发者共同参与。社区维护同一套代码工作区，把 ArceOS、StarryOS、Axvisor 以及相关的共享组件放在一起，让不同背景的参与者能在统一的工程组织下协作，也让研究成果能够更快地进入可运行的系统。

我们希望通过长期稳定的社区协作，让系统软件的学习、研究与实践有更低的进入门槛，也让参与者在这条路径上能够持续积累经验，而不是每次都从零开始。

1. 社区概况​

社区围绕共同维护的工作区运转，成员按参与深度承担不同职责，共同决定项目的技术方向和协作方式。社区不设固定的加入门槛，也不限定参与形式，任何愿意投入时间并遵守协作约定的参与者都可以找到合适的位置。

1.1 项目定位​

TGOSKits 工作区同时包含三条系统路径和一组被它们共用的组件。ArceOS 提供组件化内核，StarryOS 在其之上提供 Linux 兼容的运行环境，Axvisor 面向虚拟机监控器场景。三条路径各有侧重，但共享内存管理、任务调度、设备驱动等基础能力，因此可以放在同一套工程组织中协同演进。

工作区还统一了构建、运行与测试的方式。参与者只需熟悉一套流程，就能在任意一条系统路径上开展工作，这也是社区能够接纳不同方向贡献者的前提。研究与工程实践由此可以在同一份代码上互相验证，减少成果转移时的重复投入。

1.2 组织方式​

社区以公开仓库为中心开展协作，日常事务通过议题、拉取请求和讨论推进，技术决定与讨论过程一并保留在仓库中，供后来者查阅和追溯。

成员分为三类：指导老师提供研究方向与长期规划方面的指导，核心团队负责日常维护、审查和技术决策，贡献者通过代码、文档、测试或问题定位参与具体工作。三类角色之间没有硬性界限，参与的深度和范围会随投入情况变化，具体职责与名单见团队成员。

2. 社区目标​

社区希望让系统软件方向的研究与实践更易于持续推进，这些目标来自日常协作中反复出现的取舍，也决定了社区在处理具体事务时的判断方式。

2.1 降低参与门槛​

系统软件的进入门槛主要来自陌生的工程组织和繁杂的工具链。社区统一维护工作区的构建、运行与验证方式，并在文档中说明每一步的做法，让新参与者不必依赖口耳相传的经验，也不需要先读完大量源码才能开始工作。

我们同样重视非代码形式的参与：整理文档、补充示例、复现并说明问题，都是让后来者少走弯路的方式，社区在认可贡献时也会把这些工作计算在内。

2.2 促进能力共享​

内核、虚拟化、驱动和平台支持之间存在大量共通机制。社区鼓励把这些机制沉淀为可复用的组件，由多条系统路径共享，减少重复实现带来的维护成本和行为差异，也让同一处修复能够同时惠及多条路径。

衡量标准不是组件数量，而是同一能力是否只在社区中维护一份，并且被需要的路径稳定使用。如果一个组件长期只有单一使用者，社区会重新评估它是否值得独立存在。

2.3 保持过程可追溯​

社区的技术判断需要有据可查。问题、方案讨论和验证结论都留在仓库中，后来者可以据此还原某个决定是如何形成的，而不是只能看到最终结果，也不必重复已经排除过的方案。

改动与文档同步更新、结论附上可复现的依据，是让这份记录长期有效的具体做法。参与者在提交改动时说明背景和取舍，就能让后续维护者少花时间推测意图。

3. 协作准则​

成员来自不同的学校、企业和研究方向，协作方式需要让技术讨论高效推进，也让新参与者容易融入，因此社区在讨论、提交和评审等环节形成了一些共同的习惯。

3.1 公开透明​

讨论在公开仓库中进行，议题、拉取请求和评审意见对所有人可见。涉及方向的取舍，社区会说明考虑过的方案与放弃的原因，让其他人能够理解决定的背景而不只是结果。

成员在议题和拉取请求中的发言即代表社区记录，因此我们鼓励把结论写清楚，而不只停留在即时沟通中；口头的讨论如果产生了结论，也应当回到仓库里补充说明。

3.2 重视质量​

质量由可执行的检查与同行评审共同保证。社区统一了代码风格、静态检查和测试要求，持续集成会按改动范围执行这些检查，避免把判断标准交给个人偏好，也让评审可以把精力放在设计和取舍上。

评审意见针对代码、设计和文档本身，说明意见对应的具体行为或约束，不针对个人。对结论有分歧时，社区以可复现的行为和明确的约束为依据继续讨论。

3.3 尊重差异​

参与者来自不同的学校、企业和经验背景，关注的子系统也不相同。我们欢迎这种差异，并希望协作方式不会成为障碍，让每个人都能用自己熟悉的方式参与。

实践中的做法是：提交改动时说明目标系统和验证方式，提问时给出环境信息与已经尝试过的步骤，讨论时使用友好和包容的语言，接受建设性批评，也愿意为他人补充必要的背景说明。

3.4 鼓励分享​

系统软件的知识分布在多个层次，理解需要逐步建立。社区鼓励成员通过文档、技术分享和讨论把经验固定下来，让个人积累转化为社区资产，也避免同一类问题被反复重新发现。

整理一份说明文档、补充一段示例或回答一个问题，与提交代码同样受到认可。社区在整理贡献者名单时会一并考虑这类工作，因为它们在长期维护中的价值往往不低于单次的功能实现。

4. 参与方式​

参与不限于编写代码。整理文档、补充示例、复现并说明问题、帮助他人排查，都是社区实际需要的工作，选择自己熟悉的方式即可开始。

4.1 关注项目进展​

订阅博客可以了解版本发布与阶段性总结，仓库的提交记录和拉取请求反映了社区各方向正在推进的事情，也是了解当前关注重点最直接的途径。

4.2 反馈问题与建议​

缺陷报告和功能建议统一提交到 GitHub Issues。提交前先搜索是否已有同类议题，并按照获取帮助说明的结构提供信息，便于维护者定位问题，也让其他人能够判断自己是否遇到相同情况。

4.3 提交代码与文档​

第一次提交可以从修正文档表述、补充一个缺失示例或修复一个小问题开始，不必一开始就选择复杂的功能。完整流程、分支选择和提交要求见贡献指南。