深入解析 Backstage 主仓库的 GitHub Label 体系从 Issue 分类到 PR 审查工作流【免费下载链接】backstageBackstage is an open framework for building developer portals项目地址: https://gitcode.com/GitHub_Trending/ba/backstageBackstage 主仓库本仓库即为其镜像规模庞大拥有上千个插件包、数十个独立维护的项目领域Project Area每天都有大量 Issue 与 Pull Request 进出。为了在这一体量下保持协作秩序仓库维护了一套结构严谨的 GitHub Label 体系它既是问题分类工具也是维护者之间、维护者与贡献者之间的沟通协议。本文基于仓库根目录下的 LABELS.md 官方文档逐类拆解这套 Label 的命名规范、语义边界与使用场景并结合仓库中的 CONTRIBUTING.md、OWNERS.md、beps/README.md 及插件目录结构说明如何利用 Label 快速定位适合自己的 Issue、加速 PR 审查甚至参与 Backstage 的进阶贡献。阅读本文后你将能够读懂 Backstage 仓库中任意一个 Issue/PR 上 Label 组合的真实含义按照新手友好 → 进阶贡献 → 维护者工作流三条路径用标准的 GitHub 搜索语法快速筛选目标 Issue理解needs:*、priority:*与 BEPBackstage Enhancement Proposal流程之间的联动关系掌握 PR 从提交到合并全过程中waiting-for:*、size:*、reviewer-approved等 Label 所代表的状态机语义。一、为什么 Backstage 需要一套成体系的 LabelLABELS.md 开篇就点明了这套体系的双重定位Label 不仅用于归类categorize和追踪trackIssue 与 PR更是一种沟通工具communication tool目的是帮助维护者更快地响应社区的提交。这与 Backstage 的实际协作规模直接相关。仓库根目录的 OWNERS.md 中列出了 Auth、Catalog、Design System、Documentation、Framework、Home、Kubernetes、Operations、Permission Framework、Search、TechDocs、Tooling 等多个独立的 Project Area每个 Area 都有各自的维护者团队与评审看板Review board。当一个问题打上area:catalog时它等于被自动路由到了 Catalog 维护团队的待办池中当 PR 被打上waiting-for:review时它就进入了评审队列等待被认领。同时CONTRIBUTING.md 的 Review Process 章节明确描述了这套 Label 在自动化流程中的角色PR 提交后各种 bot 会自动执行一系列动作——为 PR 分配来自相关领域的评审者、添加 Label 以方便评审、检查 changeset 是否缺失、检查提交是否符合 DCODeveloper Certificate of Origin、触发 CI 构建以及 GitHub Copilot review。也就是说Label 是机器自动打标 维护者人工调整共同维护的活数据理解它就能理解整个仓库的协作脉搏。二、Issue Type Labelstype:*明确这是哪类工作type:*系列 Label 回答的是这个 Issue 要求做哪种类型的工作。LABELS.md 定义了四类Label语义type:bug某功能未按预期工作需要修复type:docs文档缺失或需要更新type:suggestion对新功能或变更的提案type:maintenance常规维护任务如版本升级version bumps、清理cleanup、弃用处理deprecations等这一分类与仓库的文档维护流程是呼应的仓库根目录的docs/与docs-ui/目录承载了大量面向采用者、用户和开发者的文档而scripts/check-docs-quality.js等脚本则负责在 CI 中检查文档质量例如强制使用 vale 语言检查器因此type:docs的问题往往会被快速转交给 Documentation 维护团队处理。三、Priority Labelspriority:*被接受之后的优先级阶梯LABELS.md 特别强调priority:*这组 Label只在 Issue 已被接受accepted for implementation之后才会被打上它同时指示优先级以及该领域负责人是否会亲自处理Label语义priority:critical该领域负责人会尽快处理priority:roadmap已列入负责人路线图会在合适时机处理部分社区贡献可能受欢迎priority:contrib-welcome负责人短期内不太可能处理但欢迎社区贡献priority:contrib-needed负责人不会处理但欢迎社区贡献从这套定义可以看出 Backstage 维护者的精力分配策略critical是维护者的第一优先级roadmap是排期计划而contrib-welcome与contrib-needed则是明确向社区招工的信号。对于想参与贡献的开发者contrib-welcome和contrib-needed是比good first issue更有分量的筛选条件——它意味着这项工作已被官方接受、设计方向已确认只是暂时没人做。四、Need Labelsneeds:*Issue 被接受前的待办事项如果说priority:*描述的是接受之后的排期那么needs:*描述的就是接受之前的阻塞条件——它明确指出了让一个 Issue 走向可实施还需要什么。LABELS.md 定义了八类Label语义needs:bep属于进阶功能扩展需要先提交一份 Backstage Enhancement Proposalneeds:direction需要该领域负责人给出方向性决策needs:discussion前进路径尚不清晰需要与作者及其他参与者进一步讨论needs:more-info需要作者提供更多信息needs:motivation变更动机不明确作者应通过具体用例或场景示例说明为什么需要needs:repro负责人无法复现该问题作者应提供更多复现信息最好附上最小复现仓库needs:triage需要初次分类评审needs:unblock被其他 Issue 或上游依赖阻塞其中needs:bep直接指向仓库中的 BEP 机制。根据 beps/README.md 的说明BEPBackstage Enhancement Proposal是提议、沟通并协调 Backstage 新工作的方式适用于影响 Backstage 框架或核心特性的较大变更。它借鉴了 Kubernetes Enhancement ProposalKEP流程一个 BEP 需要经历implementable获批可实施、implemented已实施、deferred搁置、rejected否决、replaced被替代等状态。因此一个needs:bep的 Issue 意味着仅凭 Issue 讨论不足以推动实施需要作者或社区伙伴在 beps/ 目录下建立提案并最终由对应项目领域的维护者批准。另外值得注意的是needs:triage——它在维护者常用筛选列表中是独立出现的高频筛选条件说明初筛是仓库维护的日常压力点而needs:motivation、needs:repro则体现了仓库对 Issue 质量的要求CONTRIBUTING.md中对 AI 生成内容的规范同样强调你必须能解释你提出的每个变更这与needs:motivation的精神一脉相承。五、Area Labelsarea:*把问题路由到正确的模块area:*是这套体系里与代码结构绑定最深的一组 Label——它指明 Issue/PR 涉及 Backstage 的哪个部分。LABELS.md 列出的area:*与仓库plugins/目录下的实际插件一一对应Label语义仓库对应模块area:auditorAuditor 服务及其在插件中的使用对应plugins/下的事件审计相关能力area:auth认证与第三方授权plugins/auth-backend、plugins/auth-backend-module-* 等系列模块area:catalogCatalog 插件、Software Catalog 模型与集成plugins/catalog、plugins/catalog-backend 及大量catalog-backend-module-*area:design-systemBackstage UI 设计系统与组件库packages/ui、packages/core-componentsarea:documentation面向采用者、用户和开发者的文档docs/ 与 docs-ui/area:eventsEvents 系统及其他插件集成plugins/events-backend、plugins/events-nodearea:frameworkBackstage 核心框架packages/core-plugin-api、packages/frontend-plugin-api 等area:homeHome 插件与站点主页plugins/home、plugins/home-reactarea:kubernetesKubernetes 插件及集成plugins/kubernetes、plugins/kubernetes-backendarea:micrositebackstage.io 站点不含文档microsite/area:notificationsNotifications 插件及集成plugins/notifications、plugins/notifications-backendarea:openapi-toolingOpenAPI 工具及其在插件中的使用packages/backend-openapi-utilsarea:operations主仓库的日常管理与运维根目录发布脚本scripts/与 release 流程area:permissionPermissions 系统及其集成plugins/permission-backend、packages/permission-*area:scaffolder支撑 Software Templates 的 Scaffolder 插件plugins/scaffolder、plugins/scaffolder-backendarea:searchSearch 插件及搜索集成plugins/search、plugins/search-backendarea:techdocsTechDocs 插件plugins/techdocs、plugins/techdocs-backendarea:toolingBackstage CLI 与仓库工具链packages/cli、packages/cli-*从源码结构看area:*与 OWNERS.md 中的 Project Area 高度对齐——例如area:catalog对应backstage/catalog-maintainers团队及其评审看板area:auth对应backstage/auth-maintainers。这意味着打上area:*的 Issue 会被自动纳入对应维护团队的评审队列是贡献者按图索骥寻找擅长领域最直接的入口。例如你对 TypeScript 前端开发有经验可以优先关注area:home、area:search、area:notifications等插件型 Area而对数据模型感兴趣则可以关注area:catalog。六、Integration Labelsintegration:*按外部集成对象筛选integration:*帮助贡献者定位与具体外部服务集成相关的问题。LABELS.md 列出了十类Label语义integration:awsAmazon Web Servicesintegration:azureMicrosoft Azure 与 Azure DevOpsintegration:bitbucket-cloudBitbucket Cloudintegration:bitbucket-serverBitbucket ServerStashintegration:gcpGoogle Cloud Platformintegration:gerritGerrit 代码评审系统integration:giteaGiteaintegration:githubGitHubintegration:gitlabGitLabintegration:other其他任何集成这一分类同样与仓库的plugins/目录严格对应仅 Catalog 领域就有catalog-backend-module-aws、catalog-backend-module-azure、catalog-backend-module-bitbucket-cloud、catalog-backend-module-gerrit、catalog-backend-module-gitea、catalog-backend-module-github、catalog-backend-module-gitlab等模块Scaffolder 领域则有scaffolder-backend-module-github、scaffolder-backend-module-gitlab、scaffolder-backend-module-bitbucket-cloud等。如果你日常使用 GitLab直接筛选integration:gitlab就能找到与 GitLab 相关的全部问题而不必逐一翻阅各个插件目录。七、Domain Labelsdomain:*按专业技能领域筛选与按模块归属划分的area:*不同domain:*按专业技能领域划分更适合按自身技术栈来筛选任务。LABELS.md 定义了六类Label语义domain:a11y与 Web 无障碍accessibility相关domain:design视觉设计与用户体验domain:docs面向采用者、用户和开发者的文档domain:backendNode.js 后端开发domain:toolingNode.js 与 GitHub Actions 相关的工具与自动化domain:web使用 TypeScript 和 React 的前端开发domain:*与area:*可以自由组合使用——这也是下面常见 Issue 筛选器中各类组合查询的底层逻辑。例如前端 无障碍可以用domain:webdomain:a11y文档 Catalog可以用domain:docsarea:catalog。八、Workflow Labels面向维护者的工作流状态workflow:*系列用于标记维护侧的工作节奏状态Label语义workflow:do-not-merge该 PR 不应被合并workflow:before-release应在下一个主线版本发布前处理workflow:after-release应在下一个主线版本发布后处理workflow:after-vacations待负责人休假归来后处理其中workflow:before-release/workflow:after-release与仓库的发布节奏直接相关仓库根目录 scripts/ 下存在prepare-release.js、create-release-changelog.js、create-github-release.js、patch-release-for-pr.js等一整套发布工具链且docs/releases/目录为每个版本维护了独立的 changelog 文档。可以推断before-release标签通常用于标记那些必须在版本切片前合入的修复而after-release则用于可以安全推迟到下一个周期的变更。九、General Labelsgood first issue与stale机制通用标签面向所有参与者Label语义good first issue适合新贡献者上手对 Backstage 的熟悉程度要求不高staleIssue/PR 长期无活动若无进一步活动将被关闭no stale该 Issue/PR 不应因无活动而被关闭stale与no stale是 GitHub 上常见的僵尸清理机制的两面默认的stale标签标记休眠条目而no stale则为重要但进展缓慢的工作提供豁免权。CONTRIBUTING.md 的 Review Tips 中也提到了这一机制的实际影响——如果 PR 在等待评审或评审中途变stale最简单的方式就是 rebase 你的 PR 来清除 stale bot 的标记。十、Pull Request Labels审查状态机与规模评估审查状态waiting-for:*PR 的生命周期由四个waiting-for:*标签驱动LABELS.md 给出了精确的状态语义Label状态语义waiting-for:reviewPR 需要评审除非已分配负责人否则会出现在评审队列中waiting-for:author评审者已提出修改意见在修改完成前不会再次评审作者在 PR 上留言会将其推回评审队列waiting-for:decisionPR 较复杂需要负责人决策进展与讨论仍可继续但评审时间会更长此类 PR 通常适合带到 SIG 会议讨论waiting-for:mergePR 已获批等待合并。若你有写权限且是作者可以自行合并若无合并权限且获批一天后仍未合并请通知指派的评审者这套状态机与 CONTRIBUTING.md 的 Review Process 高度吻合PR 提交后 bot 会自动分配评审者并打标签waiting-for:author状态下作者回复即重新入队的设计保证了双向沟通的闭环而waiting-for:decision将复杂问题升级到维护者决策甚至 SIG 会议层面。对于贡献者而言理解这四个状态等于理解了我的 PR 现在卡在哪一步、我该做什么。规模评估size:*size:*标签衡量 PR 的代码变更规模并直接影响评审优先级Label规模语义size:tiny评审优先级提高size:small评审优先级略微提高size:medium评审优先级不变size:large评审优先级略微降低size:huge评审优先级降低这一设计与 CONTRIBUTING.md 中评审优先级由多个因素决定其中大小是关键因素越小优先级越高的描述完全一致。它同时解释了为什么仓库鼓励把大改动拆分为逻辑连贯的小提交——这不仅利于评审也直接关系到你的 PR 被合入的速度。特殊标签reviewer-approvedreviewer-approved表示 PR 已获得 reviewers 组成员的批准会获得高得多的评审优先级。这是 PR 状态机中质变的一环一旦通过正式评审组的认可PR 就不再只是等待某位评审者而是被标记为值得优先合入的对象。十一、实战用 Label 组合构建你的 Issue 筛选器LABELS.md 的最后一部分提供了一套官方推荐的常见 Issue 筛选器全部基于 GitHub 的 Issues 搜索语法。这些查询是理解 Label 组合用法的绝佳范本这里以仓库可执行的搜索语法形式呈现URL 编码后的完整查询可自行在 GitHub Issues 搜索框中输入等效语句。新手贡献者good first issue 领域适合刚接触 Backstage、不熟悉代码库的贡献者四类筛选入口后端is:open is:issue label:good first issue label:domain:backend文档is:open is:issue label:good first issue label:area:documentation工具链is:open is:issue label:good first issue label:domain:tooling前端is:open is:issue label:good first issue label:domain:web进阶贡献者priority:contrib-welcome/priority:contrib-needed 领域适合对 Backstage 已有一定熟悉度、希望接手官方已接受但暂时无人实施的工作后端is:open is:issue (label:priority:contrib-welcome OR label:priority:contrib-needed) label:domain:backend文档is:open is:issue (label:priority:contrib-welcome OR label:priority:contrib-needed) label:area:documentation工具链is:open is:issue (label:priority:contrib-welcome OR label:priority:contrib-needed) label:domain:tooling前端is:open is:issue (label:priority:contrib-welcome OR label:priority:contrib-needed) label:domain:web与新手入口不同这套查询的过滤条件从练手切换为官方认证的待贡献工作是深度参与 Backstage 开发的敲门砖。维护者专用列表LABELS.md 还为维护者提供了几类高价值列表均可直接用is:open is:issue label:...形式构建休假归来待处理label:after vacations最高优先级label:priority:critical发布前必须修复label:fix before release需要方向决策label:needs:direction待初次分类label:needs:triage这些列表背后各有明确的协作语义priority:critical是维护者的紧急队列needs:triage反映初筛积压情况needs:direction是需要领域负责人拍板的问题池。建议维护者将这几组查询保存为 GitHub 的 Saved Searches形成日常巡检仪表盘。十二、组合阅读把 Label 体系放进完整的贡献流程要真正用好这套 Label 体系建议把它与仓库中另外三份核心文档组合阅读CONTRIBUTING.md定义了从 fork/clone、yarn install、yarn tsc到提交 PR 的完整流程以及 PR 描述模板、changeset 规范、DCO 签署要求。它解释了 Label 背后人的规则——例如为什么size:tiny能提高评审优先级、为什么waiting-for:author状态下留言即可重新入队。OWNERS.md列出了所有 Project Area 及其维护者团队。area:*标签对应的正是这些团队通过 OWNERS.md 可以进一步找到每个领域的维护者与评审看板。beps/README.md解释了needs:bep标签背后的提案流程。当一个 Idea 足够大、需要设计前置审批时它会从 RFC 式的 Issue 讨论升级为 beps/ 目录下的正式提案可参考beps/NNNN-template/模板并经历从implementable到implemented的状态流转。三份文档加上 LABELS.md 本体恰好覆盖了规则Label→ 流程Contributing/BEP→ 组织OWNERS的完整协作图谱。对贡献者而言一条务实的行动路径是先用good first issuedomain:*完成第一次提交再用priority:contrib-welcome 熟悉的area:*深入某个模块当你想推动一个框架级新特性时就会自然走到needs:bep背后的 BEP 流程。结语Backstage 的 Label 体系不是一组随意的标签堆砌而是一套与代码结构area:*↔ 插件目录 ↔ Project Area、决策流程needs:bep↔ BEP 机制、评审状态机waiting-for:*size:*reviewer-approved深度耦合的协作协议。无论你是寻找第一个good first issue的新手、希望接手官方待办工作的进阶贡献者还是需要管理评审队列的维护者都可以从 LABELS.md 这份标签词典出发配合 CONTRIBUTING.md 与 OWNERS.md 快速定位自己在协作体系中的位置。【免费下载链接】backstageBackstage is an open framework for building developer portals项目地址: https://gitcode.com/GitHub_Trending/ba/backstage创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 深入解析 Backstage 主仓库的 GitHub Label 体系：从 Issue 分类到 PR 审查工作流
深入解析 Backstage 主仓库的 GitHub Label 体系从 Issue 分类到 PR 审查工作流【免费下载链接】backstageBackstage is an open framework for building developer portals项目地址: https://gitcode.com/GitHub_Trending/ba/backstageBackstage 主仓库本仓库即为其镜像规模庞大拥有上千个插件包、数十个独立维护的项目领域Project Area每天都有大量 Issue 与 Pull Request 进出。为了在这一体量下保持协作秩序仓库维护了一套结构严谨的 GitHub Label 体系它既是问题分类工具也是维护者之间、维护者与贡献者之间的沟通协议。本文基于仓库根目录下的 LABELS.md 官方文档逐类拆解这套 Label 的命名规范、语义边界与使用场景并结合仓库中的 CONTRIBUTING.md、OWNERS.md、beps/README.md 及插件目录结构说明如何利用 Label 快速定位适合自己的 Issue、加速 PR 审查甚至参与 Backstage 的进阶贡献。阅读本文后你将能够读懂 Backstage 仓库中任意一个 Issue/PR 上 Label 组合的真实含义按照新手友好 → 进阶贡献 → 维护者工作流三条路径用标准的 GitHub 搜索语法快速筛选目标 Issue理解needs:*、priority:*与 BEPBackstage Enhancement Proposal流程之间的联动关系掌握 PR 从提交到合并全过程中waiting-for:*、size:*、reviewer-approved等 Label 所代表的状态机语义。一、为什么 Backstage 需要一套成体系的 LabelLABELS.md 开篇就点明了这套体系的双重定位Label 不仅用于归类categorize和追踪trackIssue 与 PR更是一种沟通工具communication tool目的是帮助维护者更快地响应社区的提交。这与 Backstage 的实际协作规模直接相关。仓库根目录的 OWNERS.md 中列出了 Auth、Catalog、Design System、Documentation、Framework、Home、Kubernetes、Operations、Permission Framework、Search、TechDocs、Tooling 等多个独立的 Project Area每个 Area 都有各自的维护者团队与评审看板Review board。当一个问题打上area:catalog时它等于被自动路由到了 Catalog 维护团队的待办池中当 PR 被打上waiting-for:review时它就进入了评审队列等待被认领。同时CONTRIBUTING.md 的 Review Process 章节明确描述了这套 Label 在自动化流程中的角色PR 提交后各种 bot 会自动执行一系列动作——为 PR 分配来自相关领域的评审者、添加 Label 以方便评审、检查 changeset 是否缺失、检查提交是否符合 DCODeveloper Certificate of Origin、触发 CI 构建以及 GitHub Copilot review。也就是说Label 是机器自动打标 维护者人工调整共同维护的活数据理解它就能理解整个仓库的协作脉搏。二、Issue Type Labelstype:*明确这是哪类工作type:*系列 Label 回答的是这个 Issue 要求做哪种类型的工作。LABELS.md 定义了四类Label语义type:bug某功能未按预期工作需要修复type:docs文档缺失或需要更新type:suggestion对新功能或变更的提案type:maintenance常规维护任务如版本升级version bumps、清理cleanup、弃用处理deprecations等这一分类与仓库的文档维护流程是呼应的仓库根目录的docs/与docs-ui/目录承载了大量面向采用者、用户和开发者的文档而scripts/check-docs-quality.js等脚本则负责在 CI 中检查文档质量例如强制使用 vale 语言检查器因此type:docs的问题往往会被快速转交给 Documentation 维护团队处理。三、Priority Labelspriority:*被接受之后的优先级阶梯LABELS.md 特别强调priority:*这组 Label只在 Issue 已被接受accepted for implementation之后才会被打上它同时指示优先级以及该领域负责人是否会亲自处理Label语义priority:critical该领域负责人会尽快处理priority:roadmap已列入负责人路线图会在合适时机处理部分社区贡献可能受欢迎priority:contrib-welcome负责人短期内不太可能处理但欢迎社区贡献priority:contrib-needed负责人不会处理但欢迎社区贡献从这套定义可以看出 Backstage 维护者的精力分配策略critical是维护者的第一优先级roadmap是排期计划而contrib-welcome与contrib-needed则是明确向社区招工的信号。对于想参与贡献的开发者contrib-welcome和contrib-needed是比good first issue更有分量的筛选条件——它意味着这项工作已被官方接受、设计方向已确认只是暂时没人做。四、Need Labelsneeds:*Issue 被接受前的待办事项如果说priority:*描述的是接受之后的排期那么needs:*描述的就是接受之前的阻塞条件——它明确指出了让一个 Issue 走向可实施还需要什么。LABELS.md 定义了八类Label语义needs:bep属于进阶功能扩展需要先提交一份 Backstage Enhancement Proposalneeds:direction需要该领域负责人给出方向性决策needs:discussion前进路径尚不清晰需要与作者及其他参与者进一步讨论needs:more-info需要作者提供更多信息needs:motivation变更动机不明确作者应通过具体用例或场景示例说明为什么需要needs:repro负责人无法复现该问题作者应提供更多复现信息最好附上最小复现仓库needs:triage需要初次分类评审needs:unblock被其他 Issue 或上游依赖阻塞其中needs:bep直接指向仓库中的 BEP 机制。根据 beps/README.md 的说明BEPBackstage Enhancement Proposal是提议、沟通并协调 Backstage 新工作的方式适用于影响 Backstage 框架或核心特性的较大变更。它借鉴了 Kubernetes Enhancement ProposalKEP流程一个 BEP 需要经历implementable获批可实施、implemented已实施、deferred搁置、rejected否决、replaced被替代等状态。因此一个needs:bep的 Issue 意味着仅凭 Issue 讨论不足以推动实施需要作者或社区伙伴在 beps/ 目录下建立提案并最终由对应项目领域的维护者批准。另外值得注意的是needs:triage——它在维护者常用筛选列表中是独立出现的高频筛选条件说明初筛是仓库维护的日常压力点而needs:motivation、needs:repro则体现了仓库对 Issue 质量的要求CONTRIBUTING.md中对 AI 生成内容的规范同样强调你必须能解释你提出的每个变更这与needs:motivation的精神一脉相承。五、Area Labelsarea:*把问题路由到正确的模块area:*是这套体系里与代码结构绑定最深的一组 Label——它指明 Issue/PR 涉及 Backstage 的哪个部分。LABELS.md 列出的area:*与仓库plugins/目录下的实际插件一一对应Label语义仓库对应模块area:auditorAuditor 服务及其在插件中的使用对应plugins/下的事件审计相关能力area:auth认证与第三方授权plugins/auth-backend、plugins/auth-backend-module-* 等系列模块area:catalogCatalog 插件、Software Catalog 模型与集成plugins/catalog、plugins/catalog-backend 及大量catalog-backend-module-*area:design-systemBackstage UI 设计系统与组件库packages/ui、packages/core-componentsarea:documentation面向采用者、用户和开发者的文档docs/ 与 docs-ui/area:eventsEvents 系统及其他插件集成plugins/events-backend、plugins/events-nodearea:frameworkBackstage 核心框架packages/core-plugin-api、packages/frontend-plugin-api 等area:homeHome 插件与站点主页plugins/home、plugins/home-reactarea:kubernetesKubernetes 插件及集成plugins/kubernetes、plugins/kubernetes-backendarea:micrositebackstage.io 站点不含文档microsite/area:notificationsNotifications 插件及集成plugins/notifications、plugins/notifications-backendarea:openapi-toolingOpenAPI 工具及其在插件中的使用packages/backend-openapi-utilsarea:operations主仓库的日常管理与运维根目录发布脚本scripts/与 release 流程area:permissionPermissions 系统及其集成plugins/permission-backend、packages/permission-*area:scaffolder支撑 Software Templates 的 Scaffolder 插件plugins/scaffolder、plugins/scaffolder-backendarea:searchSearch 插件及搜索集成plugins/search、plugins/search-backendarea:techdocsTechDocs 插件plugins/techdocs、plugins/techdocs-backendarea:toolingBackstage CLI 与仓库工具链packages/cli、packages/cli-*从源码结构看area:*与 OWNERS.md 中的 Project Area 高度对齐——例如area:catalog对应backstage/catalog-maintainers团队及其评审看板area:auth对应backstage/auth-maintainers。这意味着打上area:*的 Issue 会被自动纳入对应维护团队的评审队列是贡献者按图索骥寻找擅长领域最直接的入口。例如你对 TypeScript 前端开发有经验可以优先关注area:home、area:search、area:notifications等插件型 Area而对数据模型感兴趣则可以关注area:catalog。六、Integration Labelsintegration:*按外部集成对象筛选integration:*帮助贡献者定位与具体外部服务集成相关的问题。LABELS.md 列出了十类Label语义integration:awsAmazon Web Servicesintegration:azureMicrosoft Azure 与 Azure DevOpsintegration:bitbucket-cloudBitbucket Cloudintegration:bitbucket-serverBitbucket ServerStashintegration:gcpGoogle Cloud Platformintegration:gerritGerrit 代码评审系统integration:giteaGiteaintegration:githubGitHubintegration:gitlabGitLabintegration:other其他任何集成这一分类同样与仓库的plugins/目录严格对应仅 Catalog 领域就有catalog-backend-module-aws、catalog-backend-module-azure、catalog-backend-module-bitbucket-cloud、catalog-backend-module-gerrit、catalog-backend-module-gitea、catalog-backend-module-github、catalog-backend-module-gitlab等模块Scaffolder 领域则有scaffolder-backend-module-github、scaffolder-backend-module-gitlab、scaffolder-backend-module-bitbucket-cloud等。如果你日常使用 GitLab直接筛选integration:gitlab就能找到与 GitLab 相关的全部问题而不必逐一翻阅各个插件目录。七、Domain Labelsdomain:*按专业技能领域筛选与按模块归属划分的area:*不同domain:*按专业技能领域划分更适合按自身技术栈来筛选任务。LABELS.md 定义了六类Label语义domain:a11y与 Web 无障碍accessibility相关domain:design视觉设计与用户体验domain:docs面向采用者、用户和开发者的文档domain:backendNode.js 后端开发domain:toolingNode.js 与 GitHub Actions 相关的工具与自动化domain:web使用 TypeScript 和 React 的前端开发domain:*与area:*可以自由组合使用——这也是下面常见 Issue 筛选器中各类组合查询的底层逻辑。例如前端 无障碍可以用domain:webdomain:a11y文档 Catalog可以用domain:docsarea:catalog。八、Workflow Labels面向维护者的工作流状态workflow:*系列用于标记维护侧的工作节奏状态Label语义workflow:do-not-merge该 PR 不应被合并workflow:before-release应在下一个主线版本发布前处理workflow:after-release应在下一个主线版本发布后处理workflow:after-vacations待负责人休假归来后处理其中workflow:before-release/workflow:after-release与仓库的发布节奏直接相关仓库根目录 scripts/ 下存在prepare-release.js、create-release-changelog.js、create-github-release.js、patch-release-for-pr.js等一整套发布工具链且docs/releases/目录为每个版本维护了独立的 changelog 文档。可以推断before-release标签通常用于标记那些必须在版本切片前合入的修复而after-release则用于可以安全推迟到下一个周期的变更。九、General Labelsgood first issue与stale机制通用标签面向所有参与者Label语义good first issue适合新贡献者上手对 Backstage 的熟悉程度要求不高staleIssue/PR 长期无活动若无进一步活动将被关闭no stale该 Issue/PR 不应因无活动而被关闭stale与no stale是 GitHub 上常见的僵尸清理机制的两面默认的stale标签标记休眠条目而no stale则为重要但进展缓慢的工作提供豁免权。CONTRIBUTING.md 的 Review Tips 中也提到了这一机制的实际影响——如果 PR 在等待评审或评审中途变stale最简单的方式就是 rebase 你的 PR 来清除 stale bot 的标记。十、Pull Request Labels审查状态机与规模评估审查状态waiting-for:*PR 的生命周期由四个waiting-for:*标签驱动LABELS.md 给出了精确的状态语义Label状态语义waiting-for:reviewPR 需要评审除非已分配负责人否则会出现在评审队列中waiting-for:author评审者已提出修改意见在修改完成前不会再次评审作者在 PR 上留言会将其推回评审队列waiting-for:decisionPR 较复杂需要负责人决策进展与讨论仍可继续但评审时间会更长此类 PR 通常适合带到 SIG 会议讨论waiting-for:mergePR 已获批等待合并。若你有写权限且是作者可以自行合并若无合并权限且获批一天后仍未合并请通知指派的评审者这套状态机与 CONTRIBUTING.md 的 Review Process 高度吻合PR 提交后 bot 会自动分配评审者并打标签waiting-for:author状态下作者回复即重新入队的设计保证了双向沟通的闭环而waiting-for:decision将复杂问题升级到维护者决策甚至 SIG 会议层面。对于贡献者而言理解这四个状态等于理解了我的 PR 现在卡在哪一步、我该做什么。规模评估size:*size:*标签衡量 PR 的代码变更规模并直接影响评审优先级Label规模语义size:tiny评审优先级提高size:small评审优先级略微提高size:medium评审优先级不变size:large评审优先级略微降低size:huge评审优先级降低这一设计与 CONTRIBUTING.md 中评审优先级由多个因素决定其中大小是关键因素越小优先级越高的描述完全一致。它同时解释了为什么仓库鼓励把大改动拆分为逻辑连贯的小提交——这不仅利于评审也直接关系到你的 PR 被合入的速度。特殊标签reviewer-approvedreviewer-approved表示 PR 已获得 reviewers 组成员的批准会获得高得多的评审优先级。这是 PR 状态机中质变的一环一旦通过正式评审组的认可PR 就不再只是等待某位评审者而是被标记为值得优先合入的对象。十一、实战用 Label 组合构建你的 Issue 筛选器LABELS.md 的最后一部分提供了一套官方推荐的常见 Issue 筛选器全部基于 GitHub 的 Issues 搜索语法。这些查询是理解 Label 组合用法的绝佳范本这里以仓库可执行的搜索语法形式呈现URL 编码后的完整查询可自行在 GitHub Issues 搜索框中输入等效语句。新手贡献者good first issue 领域适合刚接触 Backstage、不熟悉代码库的贡献者四类筛选入口后端is:open is:issue label:good first issue label:domain:backend文档is:open is:issue label:good first issue label:area:documentation工具链is:open is:issue label:good first issue label:domain:tooling前端is:open is:issue label:good first issue label:domain:web进阶贡献者priority:contrib-welcome/priority:contrib-needed 领域适合对 Backstage 已有一定熟悉度、希望接手官方已接受但暂时无人实施的工作后端is:open is:issue (label:priority:contrib-welcome OR label:priority:contrib-needed) label:domain:backend文档is:open is:issue (label:priority:contrib-welcome OR label:priority:contrib-needed) label:area:documentation工具链is:open is:issue (label:priority:contrib-welcome OR label:priority:contrib-needed) label:domain:tooling前端is:open is:issue (label:priority:contrib-welcome OR label:priority:contrib-needed) label:domain:web与新手入口不同这套查询的过滤条件从练手切换为官方认证的待贡献工作是深度参与 Backstage 开发的敲门砖。维护者专用列表LABELS.md 还为维护者提供了几类高价值列表均可直接用is:open is:issue label:...形式构建休假归来待处理label:after vacations最高优先级label:priority:critical发布前必须修复label:fix before release需要方向决策label:needs:direction待初次分类label:needs:triage这些列表背后各有明确的协作语义priority:critical是维护者的紧急队列needs:triage反映初筛积压情况needs:direction是需要领域负责人拍板的问题池。建议维护者将这几组查询保存为 GitHub 的 Saved Searches形成日常巡检仪表盘。十二、组合阅读把 Label 体系放进完整的贡献流程要真正用好这套 Label 体系建议把它与仓库中另外三份核心文档组合阅读CONTRIBUTING.md定义了从 fork/clone、yarn install、yarn tsc到提交 PR 的完整流程以及 PR 描述模板、changeset 规范、DCO 签署要求。它解释了 Label 背后人的规则——例如为什么size:tiny能提高评审优先级、为什么waiting-for:author状态下留言即可重新入队。OWNERS.md列出了所有 Project Area 及其维护者团队。area:*标签对应的正是这些团队通过 OWNERS.md 可以进一步找到每个领域的维护者与评审看板。beps/README.md解释了needs:bep标签背后的提案流程。当一个 Idea 足够大、需要设计前置审批时它会从 RFC 式的 Issue 讨论升级为 beps/ 目录下的正式提案可参考beps/NNNN-template/模板并经历从implementable到implemented的状态流转。三份文档加上 LABELS.md 本体恰好覆盖了规则Label→ 流程Contributing/BEP→ 组织OWNERS的完整协作图谱。对贡献者而言一条务实的行动路径是先用good first issuedomain:*完成第一次提交再用priority:contrib-welcome 熟悉的area:*深入某个模块当你想推动一个框架级新特性时就会自然走到needs:bep背后的 BEP 流程。结语Backstage 的 Label 体系不是一组随意的标签堆砌而是一套与代码结构area:*↔ 插件目录 ↔ Project Area、决策流程needs:bep↔ BEP 机制、评审状态机waiting-for:*size:*reviewer-approved深度耦合的协作协议。无论你是寻找第一个good first issue的新手、希望接手官方待办工作的进阶贡献者还是需要管理评审队列的维护者都可以从 LABELS.md 这份标签词典出发配合 CONTRIBUTING.md 与 OWNERS.md 快速定位自己在协作体系中的位置。【免费下载链接】backstageBackstage is an open framework for building developer portals项目地址: https://gitcode.com/GitHub_Trending/ba/backstage创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考