获取帮助

社区通过文档、Issue 和即时交流提供支持。本页集中说明联系渠道和提问准备；开发任务的登记、排期与交付遵循贡献指南。

1. 支持渠道

按事项性质选择渠道，方便保留处理记录。需要联系特定方向的负责人时，在 Issue 或 PR 中说明涉及的系统与子系统，维护者会转交给相应成员；角色和名单见团队成员。

1.1 查阅文档

先根据文档入口查找快速开始、构建、架构或调试章节。遇到与预期不符的行为时，对照所用版本、配置与文档步骤检查，再决定是否需要提交问题。

1.2 提交议题

缺陷和功能建议提交到 GitHub Issues，已纳入计划的任务通过 Pull Requests提交实现并接受审查。登记问题或提出建议不代表已经纳入开发计划，季度范围和特殊变更规则见季度规划。

1.3 即时交流

一般性问题、使用经验和方案交流可以在社区交流群中进行。即时交流产生的技术结论应回到相关 Issue 或 PR 中记录，以便后续查找和追溯。

加入交流群后，说明关注的系统和当前问题，方便其他成员了解背景。贡献任务仍通过 Issue 和 PR 跟踪。

1.4 安全报告

安全相关问题通过 GitHub 私有安全报告功能或直接联系项目维护者反馈。报告中涉及漏洞的细节应保留在非公开渠道，社区会跟进处理，并在修复完成后与报告者确认结果。

2. 提问准备

提供完整的环境和操作信息，可以让协助者复现现象，减少反复补充材料的时间。正式缺陷报告与开发任务共用现有 Issue 模板。

2.1 检索与排查

提问前查阅相关文档和已有 Issue，确认使用的是仓库推荐的构建与运行方式。搜索到相同问题时，在已有 Issue 中补充新的复现信息，避免重复登记。

说明已经尝试过的排查及其结果；日志尽量提供完整文本，涉及特定配置时附上对应配置文件或关键参数，并说明现象是否能稳定复现。

2.2 使用统一模板

提交缺陷报告或功能建议时，使用开发任务模板，将复现材料填入“当前问题”部分。所需字段和其他主体部分的填写要求统一见Issue 填写要求。

候选阶段尚未确定的方案和验证方法可以标注待讨论；在任务纳入季度计划并开始开发前，再按贡献指南补齐。即时交流时也可引用已有 Issue，让讨论围绕同一份材料进行。

3. 支持范围

社区支持围绕 TGOSKits 工作区自身的使用与开发展开。需求反馈、可用的协助方式和实际开发排期应分别说明，避免把一次交流理解为已经承诺交付。

3.1 社区互助

构建、运行、测试与开发问题主要通过文档、成员互助和 Issue 回复处理。第三方依赖自身的问题需要向对应项目反馈，社区可以协助判断问题所在层次，无法代替上游安排修复或承诺修复时间。

维护者通常在工作日内回复更及时。需要代码、文档或测试改动的处理任务，按贡献指南进入季度计划；计划外事项先登记为候选，特殊情况通过再次讨论决定。

3.2 合作与定制

企业级需求和定制开发需求可以通过 Issue 或社区交流渠道说明，提供目标场景、硬件环境、期望产出和验收方式，便于评估是否有成员能够承接。

合作沟通不直接改变仓库开发计划；需要向工作区交付的改动仍遵循季度任务和 PR 流程。