Bug分类指南

本页面描述了bug分类团队即bugsquad在处理问题和从Godot的 GitHub 存储库上拉取请求时的典型工作流程。它一定会与bugsquad一起发展，所以不要犹豫对下面的指导方针提出修改。

问题管理

GitHub提出了各种功能来管理问题：

  • 从预定义列表中设置一个或多个标签
  • 从预定义列表中设置一个里程碑
  • 在项目仪表板中跟踪问题
  • 在Godot引擎组织成员中定义一个贡献者作为 受托者

由于GitHub上的Godot引擎组织目前的贡献者数量有限，我们暂时不会广泛使用受托者。欢迎所有贡献者讨论任何问题，如果在问题单上提及和/或讨论，是与其他开发人员解决此问题的最佳方式。

目前，我们也不使用项目仪表板功能。

我们尽可能尝试为问题和拉取请求分配标签(和相关的里程碑)。

标签

目前在Godot存储库中定义了以下标签：

分类：

  • Archived：是另一个问题的副本，或无效。这样的问题也将被关闭。
  • Bug：描述无法正常工作的内容。
  • Confirmed：已由至少一个其他贡献者而不是错误报告者(通常用于 Bug 报告)确认。该标签的目的是让开发人员知道当他们想要选择要解决的问题时仍然可以重现的问题。因此，在一个评论中添加评论：可以再现该问题的是什么平台、什么版本或Godot的提交是一个好的做法；如果开发人员在一年后查看该问题，则 Confirmed 标签可能不再相关。
  • Discussion：这个问题不是共识，需要进一步讨论以定义解决该主题的确切方法。
  • Documentation：与文档相关的问题。主要是要求改进API文档。与ReadTheDocs文档相关的问题应该在 godot-docs 储存库上提交。
  • Enhancement：描述对现有功能的建议增强。
  • Feature proposal：描述了实现新功能的愿望。
  • Junior job：假设 是一个容易修复的问题，这使得它非常适合需要熟悉代码库的初级贡献者。
  • Needs rebase: the issue need a Git rebase to be merged.
  • Needs testing：问题/拉取请求无法完全测试，因此需要进一步测试。这可能意味着需要在不同的硬件/软件配置上进行测试，或者甚至重现的步骤不确定。
  • PR welcome / hero wanted!：特别欢迎对这些标签的问题的贡献。请注意，这 并不 意味着您无法处理没有这些标签的问题。
  • Tracker：用于跟踪其他问题的问题(例如与插件系统相关的所有问题)。
  • Usability：直接影响用户可用性的问题。

这些类别用于问题的一般分类。它们可以在相关时以某种方式组合，例如， 如果这是一个提高可用性的问题，则可以同时将问题标记为 Enhancement 和 Usability。或者如果它是非自愿的功能请求，或者不够精确的功能请求，可以标记为 Feature proposal 和 Discussion。

话题：

  • Assetlib：与在线资源库的问题有关。
  • Audio：与音频功能(低级别和高级别)有关。
  • Buildsystem：与构建问题有关，可以链接到SCons构建系统或编译器特性。
  • Core：与核心引擎有关的任何事物。稍后可能会进一步拆分，因为这是一个很大的话题。
  • Drivers：与引擎使用的驱动程序有关。
  • Editor：与编辑器中的问题(主要是UI)有关。
  • GDNative：与GDNative模块有关。
  • GDScript：与GDScript有关。
  • Mono：与C# / Mono绑定有关。
  • Network：与网络有关。
  • Physics：与物理引擎(2D/3D)有关。
  • Plugin：与编写插件时遇到的问题有关。
  • Porting：与某些特定平台有关。
  • Rendering：与2D和3D渲染引擎相关。
  • VisualScript：与可视化脚本语言的问题有关。

问题通常只对应一个主题，但看到符合两个主题的问题并不是不可想象的。一般的想法是，将有专门的贡献者团队支持所有主题，因此他们可以专注于标记为团队主题的问题。

平台：

Android、HTML5、iOS、Linux、macOS、Windows、UWP

默认情况下，假定给定的问题适用于所有平台。如果使用其中一个平台标签，则它不是通用的，之前的假设不再适用(因此，如果它是例如Android和Linux上的错误，请选择这两个平台)。

里程碑

Milestones correspond to planned future versions of Godot for which there is an existing roadmap. Issues that fit in the said roadmap should be filed under the corresponding milestone; if they don’t correspond to any current roadmap, they should be left without milestone. As a rule of thumb, an issue corresponds to a given milestone if it concerns a feature that is new in the milestone, or a critical bug that can’t be accepted in any future stable release, or anything that Juan wants to work on right now. :)

无论指定的里程碑如何，贡献者都可以自由选择问题；如果针对一个不被认为是紧急的错误提出修复，因此没有里程碑，那么它可能仍然非常受欢迎。