获取帮助

社区通过文档、议题和讨论提供支持。多数问题在文档中已有说明，提交议题时把情况描述清楚，也能让其他遇到相同问题的人更快找到答案。

1. 支持渠道

社区按事项性质划分了不同渠道：资料查询看文档，缺陷与建议进议题，开放讨论在社区渠道，安全问题走非公开渠道。选对渠道可以减少问题被搁置的时间。

1.1 查阅文档

官方文档按主题组织，涵盖环境准备、构建运行、设计原理和问题定位。遇到与预期不符的行为时，查阅对应章节通常是解决问题最快的方式，也能避免提出文档中已有明确答案的问题。

文档入口的分类与查找方式见社区资源，其中按使用方式、设计原理和问题定位三类场景给出了对应的章节。如果确认是缺陷而非使用疑问，再进入下一个渠道。

1.2 提交议题

使用中发现的缺陷和功能建议请提交到 GitHub Issues。提交前请搜索是否已有同类议题，并使用清晰、描述性的标题，让其他人从标题就能判断问题是否与自己相关。

议题是社区的主要记录渠道，问题解决后讨论保留在议题中，便于他人检索，也让后续维护者能够了解当时为什么这样处理，而不是只看到最终改动。

1.3 参与讨论

一般性问题、使用经验交流和方案讨论欢迎在社区讨论渠道中进行。即时交流渠道适合快速确认某个现象是否普遍，作为正式记录的补充，得到的回复通常比议题更快。

在即时渠道得出的结论，建议回到议题或拉取请求中记录，以免后续难以查找，也让没有参与当时讨论的人能够了解结论与依据，避免同样的问题被反复讨论。

1.4 报告安全问题

如果您发现安全相关的问题，请不要在公开渠道披露。请通过 GitHub 的私有安全报告功能或直接联系项目维护者，社区会尽快跟进处理，并在修复完成后与报告者确认结果。

2. 提问建议

提问的质量直接影响问题被解决的速度，完整的描述可以让协助者少走很多弯路，也便于其他人判断自己遇到的是否是同一问题，从而复用后续的解决过程。

2.1 提问前的准备

提问前请先查阅文档和相关议题，并确认使用的是社区推荐的构建与运行方式。很多问题源于环境差异或版本不一致，先排除这一类原因可以节省双方的时间。

已经尝试过的排查请在提问时一并说明，避免其他人重复同样的尝试，也让协助者可以把精力放在尚未排除的可能性上，而不是从头开始推测。

2.2 报告应包含的信息

一份完整的报告能让协助者直接判断问题出在哪个环节，而不必先反复询问缺失的信息，因此建议按下面的结构组织内容，缺少的部分注明即可。

使用的系统与运行环境：
操作过程与执行的命令：
期望结果：
实际结果：
完整的错误输出：
已经尝试过的排查：

请尽量提供完整的输出而非摘要，并说明问题是否可以稳定复现。涉及特定配置时，请一并说明使用的配置文件，因为同一操作在不同配置下的表现可能完全不同。

3. 支持范围

社区支持以工作区自身的内容为界，依赖的第三方项目问题需要到各自社区处理，本社区只能在必要时协助判断问题出在哪一层，无法代替上游安排修复。

3.1 社区支持

社区支持覆盖工作区自身的构建、运行、测试与开发问题，主要形式包括文档与教程、成员间的互助，以及维护者在议题中的回复，通常在工作日内的响应更为及时。

社区也使用多个开源项目作为依赖。这些项目自身的问题需要到对应社区反馈，本社区可以协助判断问题出在哪一层，但无法代替上游处理，也无法承诺修复时间。

3.2 寻求商业支持

企业级需求或定制开发需求，可以通过议题或团队成员页面列出的渠道说明情况。定制工作通常涉及特定硬件适配、性能优化或功能扩展，需求说明中请给出目标场景、验收方式和期望的形式，便于社区评估可行性并判断是否有成员能够承接。

4. 常见问题

新参与者经常提出的问题大多能在文档中找到答案，下面几条是最常被问到的，按顺序阅读可以覆盖大部分入门场景，遇到具体问题再回到对应章节查阅。

4.1 如何开始使用

请参考快速开始指南，其中按系统分别列出环境准备、构建和首次运行的完整流程，遇到构建失败时可以对照该页面逐步检查每一步的预期结果。

4.2 如何参与贡献

请参考贡献指南，其中说明了贡献渠道、提交流程和协作约定。第一次参与可以从文档修正或问题复现开始，这类工作同样会被记录在贡献名单中。

4.3 如何在硬件上验证

除模拟环境外，社区也支持在真实硬件上运行与测试，用于验证与具体平台相关的行为，例如启动流程、外设驱动和中断处理。相关流程见板卡管理与测试与验证。

4.4 在哪里了解项目进展

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