Bug 分类规范

This page describes the typical workflow of the bug triage team aka bugsquad when handling issues and pull requests on Godot's GitHub repository. It is bound to evolve together with the bugsquad, so do not hesitate to propose modifications to the following guidelines.

问题管理

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

  • 从预定义列表中设置一个或多个标签

  • 从预定义列表中设置一个里程碑

  • 在项目仪表板中跟踪问题

  • 在 Godot 引擎组织成员中定义一个贡献者作为“担当者”

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

目前,我们也不使用项目仪表板(Dashboard)功能。

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

标签

目前在Godot仓库中定义了以下标签:

分类:

  • Archived: 是另一个问题的副本, 或无效. 这样的问题也将被关闭.

  • Breaks compat:用于描述需要破坏已有项目兼容性才能修复的内容。

  • Bug: 描述无法正常工作的内容.

  • Cherrypick:用于描述合并入 master 分支后还可以移植回稳定分支的内容。

  • Crash:用于描述导致引擎崩溃的问题。这个标签仅适用于“硬”崩溃,卡死不算。

  • Confirmed: 已由至少一个其他贡献者而不是错误报告者(通常用于 Bug 报告)确认. 该标签的目的是让开发人员知道当他们想要选择要解决的问题时仍然可以重现的问题. 因此, 在一个评论中添加评论: 可以再现该问题的是什么平台, 什么版本或Godot的提交是一个好的做法;如果开发人员在一年后查看该问题, 则 Confirmed 标签可能不再相关.

  • Discussion: 这个问题不是共识, 需要进一步讨论以定义解决该主题的确切方法.

  • Documentation: issue related to the documentation. Mainly to request enhancements in the API documentation. Issues related to the ReadTheDocs documentation should be filed on the godot-docs repository.

  • Enhancement: 描述对现有功能的建议增强.

  • Feature proposal: describes a wish for a new feature to be implemented. Note that the main Godot repository no longer accepts feature requests. Please use godot-proposals instead.

  • For PR meeting:该问题需要在拉取请求会议中进行讨论。会议是公开的,在 Godot 贡献者聊天中举行。

  • Good first issue:该问题应该是易于修复的,非常适合想要熟悉代码库的新贡献者。

  • High priority:该问题非常重要,可能导致人们无法发布他们的项目或造成数据丢失。

  • Needs work:拉取请求需要额外处理才能进行合并。

  • Needs testing: 问题/拉取请求无法完全测试, 因此需要进一步测试. 这可能意味着需要在不同的硬件/软件配置上进行测试, 或者甚至重现的步骤不确定.

  • Performance: 直接影响引擎或编辑器性能的问题。也可用于改善性能或增加低端友好选项的拉取请求。不应与 Usability 可用性结合在一起。

  • PR welcome / Hero wanted!: 我们特别欢迎对带有这些标签的问题做出贡献。请注意,这 并不 意味着不能处理没有这些标签的问题。

  • Regression: 在没有表现出该错误的稳定版本发布之后,该错误出现。

  • Salvageable: 由于设计问题或合并冲突,该拉动请求不能被合并,其作者也不再活跃。然而,它仍然可以被一个外部贡献者拾取,以使其达到可合并状态。为此,您需要基于原始拉取请求打开一个新的拉取请求。

  • Tracker: 用于跟踪其他问题的问题(例如与插件系统相关的所有问题).

  • Usability: 直接影响用户可用性的问题。不应与 Performance 相结合。

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

话题:

  • 2D: 涉及 2D 特定问题。应该与下面的某个标签组合使用,而不应该与 3D 组合。

  • 3D: 涉及 3D 特定问题。应该与下面的某个标签组合使用,而不应该与 2D 组合。

  • Assetlib: 与在线资源库的问题有关.

  • Audio: 与音频功能(低级别和高级别)有关.

  • Buildsystem: 与构建问题有关, 可以链接到SCons构建系统或编译器特性.

  • Codestyle:与代码库所使用的编程风格有关。

  • Core: 与核心引擎有关的任何事物. 稍后可能会进一步拆分, 因为这是一个很大的话题.

  • Editor: 与编辑器中的问题(主要是UI)有关.

  • GDNative: 与GDNative模块有关.

  • GDScript: 与GDScript有关.

  • Mono:与 GUI(Control)节点有关。

  • Import:与资源导入系统有关。

  • Input:与输入系统有关。

  • Mono:与 C# / Mono 绑定有关。

  • Navigation:与导航系统(包括 A* 和导航网格)有关。

  • Network:与网络有关。

  • Physics:与物理引擎(2D/3D)有关。

  • Plugin:与编写插件时遇到的问题有关。

  • Porting:与某些特定平台或导出项目有关。

  • Rendering:与 2D 和 3D 渲染引擎有关。

  • Shaders:与 Godot 着色器语言或可视化着色器有关。

  • Tests:与单元测试有关。

  • Thirdparty:与 Godot 所使用的第三方库有关。

  • VisualScript:与可视化脚本语言有关(不是可视化着色器)。

  • XR:与增强现实(AR)或虚拟现实(VR)有关。

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

平台:

AndroidHTML5iOSLinuxmacOSWindowsUWP

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

文档标签

In the documentation repository, we use the following labels:

  • Bug:现有页面中的错误信息。请勿对缺失信息使用。

  • Class reference:类参考的问题,非文档页面。

  • Discussion: 这个问题不是共识, 需要进一步讨论以定义解决该主题的确切方法.

  • Enhancememnt:为现有页面加入新信息。

  • New page:创建新页面。

  • Hero wanted!:特别欢迎为具有这些标签的问题做贡献。请注意这并不意味着你不能处理没有这些标签的问题。

  • Organization:这个问题涉及移动页面或者重新组织内容。

  • Redirect:需要在 Read the Docs 后端创建重定向。管理员才能实现。

  • Salvageable: 由于设计问题或合并冲突,该拉动请求不能被合并,其作者也不再活跃。然而,它仍然可以被一个外部贡献者拾取,以使其达到可合并状态。为此,您需要基于原始拉取请求打开一个新的拉取请求。

  • Topic:Mono:问题与 Godot 中的 C# 支持有关。

  • Topic:Website:问题与 Sphinx/Read the Docs 前端或后端有关,与文档内容无关。

里程碑

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. :)

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