# GitHub Issues Migration: label mapping **URL:** \ **Category:** Core Development\ **Created:** [March 12, 2022, 9:23am UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212 "2022-03-12T09:23:23Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![ezio-melotti](https://avatars.discourse-cdn.com/v4/letter/e/f17d59/32.png) [@ezio-melotti](https://discuss.python.org/u/ezio-melotti)\ **Post date:** [March 12, 2022, 9:23am UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/1 "2022-03-12T09:23:23Z")
On bpo we have a number of different fields such as `Components`, `Versions`, `Resolution`, `Keywords`, etc., that need to be transferred to GitHub. On GitHub there is a flat list of labels that can be assigned to both issues and pull requests. During the migration, we have the opportunity to get rid of a few fields and values, reorganize or recombine some others, and possibly adding a few new ones. I already created a mapping for most fields, but there are still a few open questions. I would also like to hear feedback from other core devs, triagers, and release managers to make sure that the proposed mapping works for their use-cases. There are a few things to keep in mind: - You can now [subscribe/follow specific labels](https://github.com/psf/gh-migration/issues/16#issuecomment-1064900661) on all repos of the `python` org on GitHub. - The nosy autocomplete of bpo, that allows you to filter users based on [entries on the Expert Index](https://devguide.python.org/experts/), doesn’t exist on GitHub. Adding labels is the only way to indirectly subscribe someone else to an issue – assuming that they are following that label. Direct `@mentions` works too, if you know whom to add (as pointed out by @pradyunsg). - Our issue classification on bpo is very fine-grained, but also complex. Once we are on GitHub, a wider audience with different levels of expertise will be able to contribute, and a simpler classification system will make reporting and triaging easier. - Even though we have a lot of fields, [several are rarely used](https://github.com/psf/gh-migration/issues/5#issuecomment-935697646) and could be removed or combined. - Labels are shared between issues and pull request, and we already have 32 PR-specific labels. Some of them can be reused for issues and some might be removed. - Having a lot of labels will affect both the “Labels” dropdown in the right sidebar (that is already 3 “pages” long), and [the page that lists all issues](https://github.com/python/cpython/pulls), since labels are listed there too. - Labels can be grouped with a prefix (which makes the name longer) and/or with colors. This makes it easier to group related labels, but it’s not ideal. - After the migration is done, it will be difficult to change/add labels on all the migrated issues, so it’s better to get them right before the migration. Below you can find the proposed mapping, copied here for your convenience from [a message](https://github.com/psf/gh-migration/issues/5#issuecomment-943178681) on [Map bpo issue metadata to GitHub fields/labels · Issue #5 · psf/gh-migration · GitHub](https://github.com/psf/gh-migration/issues/5). I will keep both mapping in sync. The [first message from issue #5](https://github.com/psf/gh-migration/issues/5#issue-742245067) has more background information if you are interested. For more information about the migration see [this Discourse thread](https://discuss.python.org/t/github-issues-migration-is-coming-soon/13791) and [the update](https://discuss.python.org/t/github-issues-migration-whats-up/14108). Also remember to link your GitHub username to your profile on [bpo](https://bugs.python.org/). Please discuss on this Discourse thread instead of using the GitHub issue to keep the discussion focused in one place. * * * ## type - `type-bug`: “An unexpected behavior, bug, or error” - `type-feature`: “A feature request or enhancement” - `type-security`: “A security issue” - `type-crash`: “A hard crash of the interpreter, possibly with a core dump” In addition: - It was [suggested](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/19) to expand `type-compile-error` to include all build errors (e.g. configure/Makefile issues). Since we already have a `build` label, the `type-compile-error` has been removed. - Similarly, `performance` and `resource usage` have been replaced by a `performance` label that can be combined either with `type-bug` or `type-feature` - `bug`, `crash`, `compile error` could be merged under `type-behavior` (users often have trouble telling them apart). - ❓ Should we merge them or keep them separate? - ✔ `type-crash` has been kept, `compile error`s can be indicated with `type-bug` + `build` - ❓ Should `crash` became a standalone label instead of a `type-*` label? - We might want to get rid of `type-security` if security issues should be reported under the Security tab of the repo. - I’m not sure if we can detect this when users select the issue type from the template, or when they add the label before they submit, but it could either be written in the template or be handled by an action after the report. - ✔ `type-bugfix` has been renamed to `type-bug`. - ❓ do we need this classification for PRs when the issue is already classified? - ✔ `type-documentation` and `type-tests` have been renamed to `docs` and `tests` ## stage - We can remove stages - ❓ We currently have `awaiting change review`, `awaiting changes`, `awaiting core review`, `awaiting merge`, `awaiting review` on `python/cpython` and `test needed`, `needs patch`, `patch review`, `commit review`, `backport needed`, `resolved` - ❓ Should we map `patch review` and `commit review` to `awaiting review`? ## components Labels in this group are related to the location of the affected files: - `library`: “Python modules in the Lib dir” - `documentation`: “Documentation in the Doc dir” - `interpreter-core`: “Interpreter core (Objects, Python, Grammar, and Parser dirs)” - `extension-modules`: “C modules in the Modules dir” - `tests`: “Tests in the Lib/test dir” They could have their own namespace prefix (not sure what to use though, and the names are already long enough), or just a specific color. ## expertise (was included in components before) - `expert-asyncio`: this is already on python/cpython - Could be grouped with `expert-*` or just by color - ❓ What other components do we want to keep? (e.g. email, IDLE, IO, Unicode, etc.) - asyncio-\> `expert-asyncio` - IDLE-\> `expert-IDLE` - Build-\> `build` - email-\> `expert-email` - IO-\> `expert-IO` - ctypes-\> `expert-ctypes` - C API-\> `expert-C-API` - Unicode-\> `expert-unicode` - Installation-\> `expert-installation` - Tkinter-\> `expert-tkinter` - SSL-\> `expert-SSL` - XML-\> `expert-XML` - 2to3 (2.x to 3.x conversion tool)-\> `expert-2to3` - Subinterpreters-\> `expert-subinterpreters` - Regular Expressions-\> `expert-regex` - Argument Clinic-\> `expert-argument-clinic` - FreeBSD and Demos and Tools have no corresponding labels, Cross-build and Build have been merged into build, Distutils has been included into library, Parser into interpreter-core. ## OS (was included in components before) - `OS-windows` and `OS-mac`: these are already on python/cpython - We could add `OS-FreeBSD` and possibly others - ❓ Any other OS that deserves a label? - ✔ no ## versions - We already have `needs backport to *` on python/cpython - There is [a discussion on Discourse about this](https://discuss.python.org/t/github-issues-migration-is-coming-soon/13791/40) - In the same thread, it was suggested to just have labels to indicate if it only applies to `main`, if it should be backported to maintenance releases, and also to security releases - This could be inferred by the issue type (feature, bug, security) and marked with the `needs backport to *` labels - ❓ Should we remove versions, only keep two, or keep them all? - ✔ all active versions (`3.7`-`3.11`) have been kept. They can be converted to milestones after the migartion. ## resolution - I only kept `invalid` (since it was already on python/cpython). There is also a `spam` label. ## priority - ❓ Are the RMs fine with using milestones/projects to track release/deferred, or do they prefer to have labels? - ✔ they are fine, but for now the `release blocker` and `deferred blocker` labels have been added. This will make it easier to identify issues and add them to milestone/projects. ## keywords - I only kept `easy`. The others are barely used. - ❓ Is there any other keyword that we should keep? - ✔ no(?) ---
**Author:** ![pradyunsg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pradyunsg/32/206_2.png) [@pradyunsg](https://discuss.python.org/u/pradyunsg)\ **Post date:** [March 12, 2022, 9:35am UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/2 "2022-03-12T09:35:09Z")
> [@ezio-melotti](#): > > Adding labels is the only way to indirectly subscribe someone else to an issue – assuming that they are following that label. If you know the specific individual, you can @-mention them in a comment – which will subscribe them. It’s true that there’s no real way to find out who exactly is subscribed to an issue but I’ve always found that a bit weird on b.p.o anyway. 🙂 ---
**Author:** ![arhadthedev](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/arhadthedev/32/6420_2.png) [@arhadthedev](https://discuss.python.org/u/arhadthedev)\ **Post date:** [March 12, 2022, 11:39am UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/3 "2022-03-12T11:39:39Z")
> [@ezio-melotti](#): > > that allows you to filter users based on [entries on the Expert Index](https://devguide.python.org/experts/), doesn’t exist on GitHub. Adding labels is the only way to indirectly subscribe someone else to an issue Can CODEOWNERS be heavily employed for this instead, becoming a de facto expert list? ---
**Author:** ![arhadthedev](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/arhadthedev/32/6420_2.png) [@arhadthedev](https://discuss.python.org/u/arhadthedev)\ **Post date:** [March 12, 2022, 12:07pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/4 "2022-03-12T12:07:15Z")
> [@ezio-melotti](#): > > ❓ Should we merge them or keep them separate? I see type labels as a way to swiftly prioritize public stuff. Like, loss of user data first, behavior not conformant to the documentation second, degradation of performance third, everything else fourth. With such gradation an exact effect stops to matter, be it a hard termination after detection (“crash”) or just an undetected deviation of logic (“bug”). In this light, we can have the following mapping: - type-data-loss (crash) - type-not-as-documented (behavior, compile-error) - type-performance (stays as is) - type-enhancement (stays as is) I’m open to ideas how to make `type-not-as-documented` shorted considering it to be the most popular label. ---
**Author:** ![ezio-melotti](https://avatars.discourse-cdn.com/v4/letter/e/f17d59/32.png) [@ezio-melotti](https://discuss.python.org/u/ezio-melotti)\ **Post date:** [March 12, 2022, 12:26pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/5 "2022-03-12T12:26:53Z")
> [@arhadthedev](#): > > Can CODEOWNERS be heavily employed for this instead, becoming a de facto expert list? As far as I understand, the `CODEOWNERS` file only works for pull requests, so it can not be used automatically for issues. In addition, the Expert Index also covers other categories and areas of interests, not just files. ---
**Author:** ![arhadthedev](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/arhadthedev/32/6420_2.png) [@arhadthedev](https://discuss.python.org/u/arhadthedev)\ **Post date:** [March 12, 2022, 12:37pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/6 "2022-03-12T12:37:58Z")
> [@ezio-melotti](#): > > As far as I understand, the `CODEOWNERS` file only works for pull requests, so it can not be used automatically for issues. Yeah, I overlooked that PRs are not required to be created together with bound issues. Like, there can be a sufficient delay until issue participants get a proper approach condensed and a draft implementation is published, not to mention discussion-only issues. ---
**Author:** ![arhadthedev](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/arhadthedev/32/6420_2.png) [@arhadthedev](https://discuss.python.org/u/arhadthedev)\ **Post date:** [March 12, 2022, 12:42pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/7 "2022-03-12T12:42:47Z")
And here is a timely example ([bpo-43224: Implement substitution of unpacked TypeVarTuple in C by serhiy-storchaka · Pull Request #31828 · python/cpython · GitHub](https://github.com/python/cpython/pull/31828#issuecomment-1065873543)): > I think we should pause work on this until we’ve decided on exactly which approach we’re proceeding with. ---
**Author:** ![Jelle](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jelle/32/1049_2.png) [@Jelle](https://discuss.python.org/u/Jelle)\ **Post date:** [March 12, 2022, 2:27pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/8 "2022-03-12T14:27:02Z")
I’d really like labels for each of the expert areas, so I can easily find all bugs related to typing or sqlite or asyncio or some other major part of the stdlib. Maybe we just have to accept that the list of labels will be extremely long; I don’t think the costs you list are that bad. ---
**Author:** ![pradyunsg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pradyunsg/32/206_2.png) [@pradyunsg](https://discuss.python.org/u/pradyunsg)\ **Post date:** [March 13, 2022, 9:29am UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/9 "2022-03-13T09:29:09Z")
> [@ezio-melotti](#): > > Labels can be grouped with a prefix (which makes the name longer) and/or with colors. I’d recommend doing both. - I’m pretty sure that only distinguishing by color will not work well, since I’m pretty sure we’d have colour blind folks looking at these pages. - I don’t think that a long list of labels is problematic, as long as its well organised. It takes a bit of upfront effort but that effort pays off well. It’s also a decent amount of work to apply them on every issue though, something that bpo currently offsets onto the person filing the issue; which we might want to make possible. I’ve found pip’s issue tracker much easier to triage since we’ve moved to our prefix-based model for labels. And, as a purely bikesheding note: I think it’s reasonable to do something like “type: bug” instead of “type-bug”. Both of them will show up when you say “bug” or “type” or “type bug” in the label picker, and I personally find the visual separation of `type: bug` to be nicer than the lack of separation in `type-bug`. 🙂 ---
**Author:** ![hugovk](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hugovk/32/14505_2.png) [@hugovk](https://discuss.python.org/u/hugovk)\ **Post date:** [March 13, 2022, 10:03am UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/10 "2022-03-13T10:03:31Z")
> [@pradyunsg](#): > > - I don’t think that a long list of labels is problematic, as long as its well organised. Yes, especially as the “Filter by label” box lets you find things quickly: ![image](https://us1.discourse-cdn.com/flex002/uploads/python1/original/2X/b/be49520118474d2f9ba7b5ec3b1b0cd277786afb.png) ---
**Author:** ![ezio-melotti](https://avatars.discourse-cdn.com/v4/letter/e/f17d59/32.png) [@ezio-melotti](https://discuss.python.org/u/ezio-melotti)\ **Post date:** [March 13, 2022, 12:44pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/11 "2022-03-13T12:44:08Z")
Thanks everyone for the feedback! > [@Jelle](#): > > Maybe we just have to accept that the list of labels will be extremely long; I don’t think the costs you list are that bad. Fair enough. If the triagers are fine with the price of dealing with a long list of labels in order to have a more powerful issue search/filtering, then I guess it’s a worthy trade-off. > [@pradyunsg](#): > > I’ve found pip’s issue tracker much easier to triage since we’ve moved to our prefix-based model for labels. PIP currently has 90 labels ([Labels · pypa/pip · GitHub](https://github.com/pypa/pip/labels)) and it seems to mostly use one-letter prefixes that are not immediately obvious (in fact it took me several clicks to find [this page that lists the labels](https://pip.pypa.io/en/latest/development/issue-triage/)) and also has some “long” prefixes (like `type: *`). Black also uses a similar one-letter convention and has 45 labels ([Labels · psf/black · GitHub](https://github.com/psf/black/labels)). Jupyter Notebook mostly uses “long” prefixes and has 48 labels ([Labels · jupyter/notebook · GitHub](https://github.com/jupyter/notebook/labels)). CPython now has 31 labels ([Labels · python/cpython · GitHub](https://github.com/python/cpython/labels) – one disappeared overnight 🤔). All of them also have some unprefixed labels (e.g. `trivial`, `stale`, `invalid`). The colors seem somewhat inconsistent within the same category, except in the case of Jupyter which is fairly consistent. Even within category that use the same color, there are some differently-colored exceptions (e.g. the red `type-security` among the other blue `type-*`). If everyone else has experience working on repos with a many labels, I would be curious to hear about it. * * * That said, if we agree on having more labels, we still need to decide which ones we want to keep. I will update the list above and ask again for feedback. The good news is that the label name, description, and color can be changed at any time, so we will have plenty of time to bikeshed after the migration. ---
**Author:** ![iritkatriel](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/iritkatriel/32/2615_2.png) [@iritkatriel](https://discuss.python.org/u/iritkatriel)\ **Post date:** [March 13, 2022, 7:42pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/12 "2022-03-13T19:42:54Z")
I think we need some issue management labels. Things like: awaiting-information (OP was requested to clarify something). pending-close (a core dev or triager suggests closing, but wants to give others a chance to object). Maybe the bots can automatically close issues if they have one of these labels for a month. ---
**Author:** ![CAM-Gerlach](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cam-gerlach/32/3688_2.png) [@CAM-Gerlach](https://discuss.python.org/u/CAM-Gerlach)\ **Post date:** [March 13, 2022, 9:55pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/13 "2022-03-13T21:55:36Z")
FWIW, on the main [Spyder repository](https://github.com/spyder-ide/spyder), we get 150+ issues per month (and used to get double that or more before we implemented a bunch of automatic troubleshooting and triage steps). Back when I was in charge of it, we introduced a `status: Awaiting Followup` tag for this case, since it was very common that users would not give us enough information to propose a solution, reproduce a bug, close as a duplicate or otherwise act on it. If they didn’t answer after 8 days, the issue would be closed. It has since become very successful and kept our issue backlog more manageable, and I believe we’ve automated that nowadays (and there are many bots and GH Actions to do so). I’ve seen it used on a number of other projects as well, in combination with bots/GH Actions/etc that take care of the followup. A big issue for us with tags in general was core devs not applying and using them consistently; having a dedicated and relatively experienced person in charge of triaging issues and PRs (me; now its handled by everyone on a rotating basis, one core dev per day of the week) was pretty critical for that. In this case, you have a whole team of them, so that should hopefully be somewhat less of a concern. ---
**Author:** ![ezio-melotti](https://avatars.discourse-cdn.com/v4/letter/e/f17d59/32.png) [@ezio-melotti](https://discuss.python.org/u/ezio-melotti)\ **Post date:** [March 14, 2022, 4:39am UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/14 "2022-03-14T04:39:00Z")
> [@iritkatriel](#): > > awaiting-information (OP was requested to clarify something). > pending-close (a core dev or triager suggests closing, but wants to give others a chance to object). ISTM that both indicate an issue that should be closed unless more information that prove its validity are provided. Something like this is definitely useful to have, but perhaps we don’t need to distinguish between the two. On bpo we currently have [`test needed`](https://devguide.python.org/triaging/#stage) and [`pending`](https://devguide.python.org/triaging/#status). There is some overlap between them and with the labels you suggest. I think `pending` could be mapped, but probably not `test needed`. > [@CAM-Gerlach](#): > > we introduced a `status: Awaiting Followup` tag FTR Black and PyPI have `S: awaiting response` and `S: needs repro`, Jupyter has `status:Needs info`. > [@iritkatriel](#): > > Maybe the bots can automatically close issues if they have one of these labels for a month. > [@CAM-Gerlach](#): > > If they didn’t answer after 8 days, the issue would be closed. I think it would make sense to automatically close after a few days issues that have been marked with the aforementioned labels by a human, since they are not useful in their current state. I wouldn’t close old/stale issues just because they are old. ---
**Author:** ![hugovk](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hugovk/32/14505_2.png) [@hugovk](https://discuss.python.org/u/hugovk)\ **Post date:** [March 14, 2022, 8:08am UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/15 "2022-03-14T08:08:07Z")
We already have a GH Action to label old PRs as `stale` after 30 days, and remove `stale` after activity. After another 14 days, PRs labelled `stale` + `CLA not signed` are auto-closed. (Those also with `stale` + `CLA signed` are not auto-closed.) I can see value auto-closing issues that have `stale` and human-applied label(s), and we could use the same GH Action. ---
**Author:** ![blink1073](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/blink1073/32/2519_2.png) [@blink1073](https://discuss.python.org/u/blink1073)\ **Post date:** [March 14, 2022, 10:22am UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/16 "2022-03-14T10:22:04Z")
In JupyterLab we use [Labeler · Actions · GitHub Marketplace · GitHub](https://github.com/marketplace/actions/labeler) to apply labels by [path](https://github.com/jupyterlab/jupyterlab/blob/master/.github/labeler.yml). There is a limit of 100 labels that can be applied. We also have a [probot](https://github.com/jupyterlab/jupyterlab-probot/pull/11/files) that automatically applies a “status:Needs Triage” label to new issues. ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [March 14, 2022, 5:18pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/17 "2022-03-14T17:18:54Z")
> [@ezio-melotti](#): > > `behavior` , `crash` , `compile error` could be merged under `type-behavior` (users often have trouble telling them apart). > > - ❓ Should we merge them or keep them separate? `compile error` is fundamentally different from the other two, and I suspect if we don’t have a `crash` tag then people will be tempted to put `[crash]` in the title. I’d just keep them separate. The definitions you have in the first post are (almost) clear enough to handle triaging (I’d clarify that `compile error` is for compiling CPython, rather than “Python”). ---
**Author:** ![ezio-melotti](https://avatars.discourse-cdn.com/v4/letter/e/f17d59/32.png) [@ezio-melotti](https://discuss.python.org/u/ezio-melotti)\ **Post date:** [March 15, 2022, 1:21pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/18 "2022-03-15T13:21:38Z")
> [@blink1073](#): > > In JupyterLab we use [Labeler · Actions · GitHub Marketplace · GitHub](https://github.com/marketplace/actions/labeler) to apply labels by [path](https://github.com/jupyterlab/jupyterlab/blob/master/.github/labeler.yml). This sounds quite useful, especially because we have a number of labels that are directly correlated to specific files/paths. Thanks for sharing! > [@steve.dower](#): > > `compile error` is fundamentally different from the other two, and I suspect if we don’t have a `crash` tag then people will be tempted to put `[crash]` in the title. > > I’d just keep them separate. Upon further thought, I think it’s better keeping them separate, for two reasons: - While reporting, triagers know the difference and users can’t set labels directly, so misreporting shouldn’t be a problem; - While searching/filtering, devs might be interested in finding crashes and compile errors specifically, without having these kinds of issues lost among other generic bugs. ---
**Author:** ![erlendaasland](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/erlendaasland/32/4378_2.png) [@erlendaasland](https://discuss.python.org/u/erlendaasland)\ **Post date:** [March 15, 2022, 2:49pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/19 "2022-03-15T14:49:14Z")
I would consider renaming `type-compile-error` to `type-build` in order to encompass _all_ build related errors: configure not functioning as intended, makefile bugs, problems with build related tools (freeze, etc.), and of course compilation errors. ---
**Author:** ![ezio-melotti](https://avatars.discourse-cdn.com/v4/letter/e/f17d59/32.png) [@ezio-melotti](https://discuss.python.org/u/ezio-melotti)\ **Post date:** [March 15, 2022, 7:37pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/20 "2022-03-15T19:37:29Z")
> [@erlendaasland](#): > > I would consider renaming `type-compile-error` to `type-build` in order to encompass _all_ build related errors Note that we already have the `Build` and the `Cross-Build` components, and I was already planning to merge them. Should we also add `type-compile-error` and combine all three into `type-build` (or just `build`)? [Next page](https://discuss.python.org/t/github-issues-migration-label-mapping/14212.md?page=2)