GitHub里都叫bug，issue type与label的范围却不同

一条GitHub issue可以在资料中同时出现类型名称和标签名称。若两处都写bug，只抄这几个字，读者未必知道它属于哪套分类。GitHub官方分别用两篇文档介绍issue types和labels，区别首先落在组织与仓库的作用范围上。

Issue types用于在整个组织内分类和管理不同类型的问题。文档列出的默认类型是task、bug和feature；类型会出现在问题列表及问题本身，也可以用于搜索、筛选以及项目视图。它在这些位置显示，说明同一个组织分类能够成为多处阅读入口，而不是仅存在于一张单独的标签清单。

Label的定义范围更具体。标签在某个仓库中创建，就能用于该仓库的问题、拉取请求或讨论。官方明确说，在一个仓库中新增、修改或删除标签，不会影响属于其他仓库的标签。因此，名称相同也没有把两个仓库的标签合并成一个共同对象。

设想一个不对应真实项目的资料对照：仓库甲和仓库乙都列出bug标签。如果甲的说明被改写，不能凭相同名称就认定乙的说明也随之改变。这个例子只是原文仓库范围的逻辑结果，没有修改任何标签。若记录的是组织的bug类型，则应把它标为issue type，避免与甲、乙各自的label混在一列。

默认值也不能消除这个区别。官方为新仓库提供默认标签，并说明这些标签后来可以编辑或删除；其中bug用来表示非预期问题或行为。组织默认类型中同样有bug。两份默认名单词语重合，却仍分别属于组织类型与仓库标签，不能仅凭默认名称判断它们同步变化。

对代码托管资料交接，更清楚的表达是同时保留名称、分类种类以及所属组织或仓库。项目视图里的筛选可以引用issue type，仓库工作项也可以带label，但一张截屏中出现同一个词，并没有独自说明其定义来自哪里。本篇采用GitHub公开文档的分类说明，首次发布日期未确认；没有执行分类管理、权限调整或仓库操作，也不从这些名称推断实际工作已经完成。