# 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:** 14\ **Page:** 2
**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 21, 2022, 2:13pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/21 "2022-03-21T14:13:59Z")
Since renaming and removing labels can be easily done at any time after the migration, I decided to map most of the fields to labels during the migration, and we can then update the labels after the migration. Colors and descriptions can be updated too. Merging label can technically be done after the migration too, by selecting all issues with label `B`, adding label `A` to all of them, and removing label `B`. Doing this after the migration however will generate two new events on each issue (addition of `A` and removal of `B`), and will update their “Last updated” date, making some searches more difficult. Because of this, doing it before the migration is better – the downside is that if we change our minds on a merge, it’s tricky to undo it. Based on the feedback I received, I changed the following things: - Removed `type-compile-error` and `type-performance` and added a `build` and `performance` labels that can be combined with the other `type-*` labels - Temporarily renamed `docs` and `tests` to `type-documentation` and `type-tests` to match the existing labels in the CPython repo (these should be renamed) - Renamed `type-enhancement` to `type-feature` - Added labels for `3.7`-`3.11` (these can be removed afterwards) - Added `release-blocker` and `deferred-blocker` labels (these can also be removed) - Updated `pending` to map to `pending` instead of `stale` - Added labels for most components Regarding the components, this is the full mapping: - Library (Lib)-\> `library` - Documentation-\> `type-documentation` - Interpreter Core-\> `interpreter-core` - Windows-\> `OS-windows` - Extension Modules-\> `extension-modules` - Tests-\> `type-tests` - asyncio-\> `expert-asyncio` - IDLE-\> `expert-IDLE` - Build-\> `build` - email-\> `expert-email` - IO-\> `expert-IO` - macOS-\> `OS-mac` - 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` - Cross-Build-\> `build` (easily searchable, not too useful) - Demos and Tools-\> `` (only a few issues, not too useful) - Subinterpreters-\> `expert-subinterpreters` - Regular Expressions-\> `expert-regex` - Argument Clinic-\> `expert-argument-clinic` - FreeBSD-\> `` (only a few issues, easily searchable) - Parser-\> `interpreter-core` (only a few issues, easily searchable) - Distutils-\> `library` (only a few issues, easily searchable) 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`. ~~(I’ll update the initial post shortly)~~ – done ---
**Author:** ![guido](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/guido/32/21_2.png) [@guido](https://discuss.python.org/u/guido)\ **Post date:** [March 21, 2022, 3:35pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/22 "2022-03-21T15:35:29Z")
What about renaming type-behavior to type-bug? ---
**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 21, 2022, 3:55pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/23 "2022-03-21T15:55:32Z")
This can be easily done either before or after the migration, and renaming `type-behavior` to `type-bug` is fine with me. The `python/cpython` repo already has `type-bugfix` for PRs though, so there are a few options: 1. Rename `type-bugfix` to `type-bug` and use `type-bug` in the mapping, so that both issues and PRs will end up under the same label; 2. Get rid of the `type-bugfix` label for PRs and only mark issues with `type-bug` (issues are linked to PRs anyway, so we don’t need to mark them twice unless some bot/script needs that label) 3. Keep both labels, use `type-bug` for issues and `type-bugfix` for PRs. ---
**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 21, 2022, 5:23pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/24 "2022-03-21T17:23:26Z")
> [@ezio-melotti](#): > > Rename `type-bugfix` to `type-bug` and use `type-bug` in the mapping, so that both issues and PRs will end up under the same label; +1 Nothing will be improved by having two different tags, you can filter with `is:pr` or `is:issue` (IIRC). ---
**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 25, 2022, 2:56am UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/25 "2022-03-25T02:56:38Z")
I’ve already renamed some of the labels on the `python/cpython` repo: - `type-bugfix` → `type-bug` (this will replace `type-behavior` too) - `type-enhancement` → `type-feature` - `type-documentation` → `docs` - `type-performance` → `performance` - `type-tests` → `tests` I also noticed that the `python/cpython` already has some stage-like labels: `awaiting change review`, `awaiting changes`, `awaiting core review`, `awaiting merge`, `awaiting review`. bpo has these stages `test needed`, `needs patch`, `patch review`, `commit review`, `backport needed`, `resolved`. - ❓ Should we map `patch review` and `commit review` to `awaiting review`? The `awaiting *` labels don’t seem to be documented, so I’m not entirely sure what mapping (if any) would make more sense. ---
**Author:** ![guido](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/guido/32/21_2.png) [@guido](https://discuss.python.org/u/guido)\ **Post date:** [March 25, 2022, 3:09am UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/26 "2022-03-25T03:09:20Z")
IIRC some bot owns the ‘awaiting’ labels. ---
**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 25, 2022, 7:12am UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/27 "2022-03-25T07:12:47Z")
Bedevere [uses](https://github.com/python/bedevere/blob/7f1449fb1a44ec71c1cc109c641c2b813877b799/bedevere/stage.py#L17-L36): - `Awaiting review` - `Awaiting core review` - `Awaiting changes` - `Awaiting change review` - `Awaiting merge` ![image](https://us1.discourse-cdn.com/flex002/uploads/python1/original/2X/2/2a82312d6913ff00d5278b53ec0b7040bccfa508.jpeg) ---
**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 25, 2022, 10:08am UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/28 "2022-03-25T10:08:25Z")
> [@ezio-melotti](#): > > ❓ Should we map `patch review` and `commit review` to `awaiting review` ? Commit review typically means it’s been merged already, so that wouldn’t map to anything. Probably best to leave those tags for PRs only. It’ll very likely confuse the bot if they start showing up on issues. ---
**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 25, 2022, 7:50pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/29 "2022-03-25T19:50:58Z")
The reason I was suggesting this mapping is that `patch review`/`commit review` are currently used on bpo to indicate issues that have a proposed solution (either a PR or a patch) ready to be reviewed. If we add the `awaiting review`, it will be possible to filter for these issues with `is:issue is:open label:"awaiting review"`. In theory this should be possible by searching for `is:issue is:open linked:pr`, but this has two problems: - PR linking is not supported during the migration (I’m still looking for a solution) - Issues with a patch on bpo won’t be included in the search without a label Moving forward it won’t be necessary to add this label to issues, since PRs will be linked properly, so it’s mostly a way to preserve some extra metadata of the migrated issues. If we decide against it, it will still be possible to search for issues awaiting for review on bpo even though the list will become outdated as more issues gets closed on GitHub. > [@steve.dower](#): > > Commit review typically means it’s been merged already, so that wouldn’t map to anything. FWIW the [devguide](https://devguide.python.org/triaging/#stage) says: > commit review: A triager performed a patch review and it looks good. This signals to core developers the patch or pull request needs a quick once-over to make sure nothing was overlooked before committing it. Either way there are only 21 issues with `commit review`, so it doesn’t make much difference if they are not included. There are 2199 issues with `patch review` and also 2869 with the `patch` keyword (added automatically for PRs). ---
**Author:** ![mikecm](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mikecm/32/5448_2.png) [@mikecm](https://discuss.python.org/u/mikecm)\ **Post date:** [May 20, 2022, 11:53am UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/30 "2022-05-20T11:53:32Z")
Any chance of adding ‘draft’ label? This will help with searching PRs. ---
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [May 20, 2022, 12:00pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/31 "2022-05-20T12:00:58Z")
I’m pretty sure you can already set a PR as draft, and search for draft PRs. It shouldn’t need a label as well. ---
**Author:** ![mikecm](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mikecm/32/5448_2.png) [@mikecm](https://discuss.python.org/u/mikecm)\ **Post date:** [May 20, 2022, 12:09pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/32 "2022-05-20T12:09:09Z")
I actually want to filter them out. and searching GH seems like overkill. Why not just have a label and I can do what I want simply by adding that label (to the others that I currently use)? ---
**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:** [May 20, 2022, 12:32pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/33 "2022-05-20T12:32:59Z")
DRY. We don’t need to repeat GitHub either. There is already a `draft:true` [filter](https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests#search-for-draft-pull-requests) for issue/PR search. ---
**Author:** ![mikecm](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mikecm/32/5448_2.png) [@mikecm](https://discuss.python.org/u/mikecm)\ **Post date:** [May 25, 2022, 4:23pm UTC](https://discuss.python.org/t/github-issues-migration-label-mapping/14212/34 "2022-05-25T16:23:24Z")
Thanks -draft:true works for me. [Previous page](https://discuss.python.org/t/github-issues-migration-label-mapping/14212.md?page=1)