类型：代码托管平台
简介：只支持Git作为唯一的版本库格式进行托管，故名GitHub。
GitHub Issue是开源项目和团队项目里最常用的问题入口，但Issue一多，很快就会变成杂乱列表：有人报Bug，有人提需求，有人问安装问题，有人提交环境不完整的截图。维护者如果每条都从头追问，沟通成本会越来越高。要让Issue真正帮项目沉淀问题，需要先用标签和模板把入口分流清楚。
一、先区分四类问题
Issue至少可以分成Bug、功能建议、使用求助、文档反馈四类。Bug关注复现步骤、版本、环境和期望结果；功能建议关注使用场景、需求价值和替代方案；使用求助更像问答，需要引导到文档或讨论区；文档反馈则关注描述是否清楚、示例是否过时、链接是否失效。
如果所有问题都进入同一个列表，维护者很难判断优先级。分类不是为了形式整齐，而是为了减少重复沟通。提问者在创建Issue时看到类型选择，也会更容易提供必要信息。
二、模板要帮助提问者说清楚
Issue模板不要写成一长串命令式要求。更好的模板是引导用户提供关键材料。Bug模板可以包含：当前版本、运行环境、复现步骤、实际结果、期望结果、相关日志。功能建议模板可以包含：遇到的场景、当前绕行方案、希望项目提供什么能力、是否愿意参与实现。
模板里还可以放提醒：提交前请搜索已有Issue，敏感信息不要放进截图，日志请删除Token和账号。提醒不必很多，但要放在容易看到的位置。模板越贴近项目真实问题，后续维护越省力。
三、标签不要过多
标签太少无法分流，标签太多没人愿意维护。一个中小项目可以从十个以内开始：bug、enhancement、question、documentation、needs-repro、good-first-issue、priority-high、wontfix、duplicate、help-wanted。后续再根据项目情况增加平台、模块或版本标签。
标签命名要稳定，不要今天用help，明天用question，后天用support。标签颜色也可以辅助识别，例如高优先级用醒目颜色，文档和讨论类用浅色。视觉上越清晰，列表处理越快。
四、优先级要有判断标准
不是声音最大的Issue就最重要。优先级可以根据影响范围、是否阻断使用、是否有安全风险、是否有稳定复现、是否有明确解决方案来判断。一个影响大量用户的启动失败，比一个少数场景下的体验建议更优先。没有复现信息的Bug，即使描述严重，也应先标记needs-repro。
维护者可以在项目文档里说明处理原则，让贡献者理解为什么某些问题先处理、某些问题暂缓。透明的规则能减少情绪化沟通。
五、关闭Issue也要有说明
重复Issue应当链接到主Issue后关闭；无法复现的问题可以说明需要更多信息，并在一段时间无回复后关闭；不符合项目方向的需求，也应简短解释原因。直接关闭不回应，会降低社区信任。说明不需要很长，但要让对方知道问题被看见了。
Issue治理的目标不是把列表清空，而是让问题能被理解、排序和复用。标签、模板和关闭规则做好后，维护者才能把更多精力放在真正需要修复和改进的地方。
六、让提问者在提交前自检
Issue模板里可以加入简短自检项，例如是否搜索过已有Issue，是否使用最新版本，是否提供复现步骤，是否删除敏感信息。自检项不是为了阻止提问，而是帮助提问者把问题说清楚。很多无效Issue并非恶意，而是不知道维护者需要哪些信息。
自检项要少而关键。太长的表单会让人放弃提交，太短又起不到筛选作用。对中小项目来说，四到六个问题通常足够。模板写得越贴近项目真实问题，后续沟通越顺畅。
七、把常见问题转成文档入口
如果同类使用求助反复出现，说明文档没有解决入口。维护者可以把这些Issue整理成FAQ、故障排查页或示例说明，再在模板里引导用户先查看。这样Issue不只是问题列表，也能反向推动文档完善。
重复问题不要只关闭，也可以在关闭时链接到对应文档。下一次有人搜索同类问题时，就能从旧Issue找到答案。项目维护的长期价值，往往来自这些可复用的问题沉淀。
八、为新贡献者保留低门槛入口
标签不仅用于维护者分类，也能帮助新贡献者找到参与机会。good-first-issue、help-wanted、documentation这类标签可以标出适合入门的任务。但这些标签不能随便贴，任务描述要足够清楚，范围要可控，否则新贡献者接手后仍然无从下手。
对开源项目来说，一个清楚的小Issue，可能比一个宏大的路线图更能吸引贡献。标签体系如果能兼顾维护和参与，Issue列表就不只是负担，也会成为社区协作入口。
九、让Issue列表保持可搜索
Issue处理完以后，不要只关注关闭数量，还要考虑它是否能帮助后来的人搜索答案。标题应当尽量描述问题本身，例如安装失败、某版本报错、某功能建议，而不是只写“求助”或“有问题”。维护者在回复时可以补充关键词、版本和最终原因，让这个Issue以后能成为可检索资料。
一个维护良好的Issue列表，既能减少重复提问，也能让项目显得更可靠。用户看到问题有人回应、重复问题有归档、复杂问题有进展，会更愿意继续使用或参与项目。
