Unlike dotnet/runtime and dotnet/aspnetcore, dotnet/aspire issues typically have more than one area label, which works well for their context as boundaries aren't always clear and stuff sometimes straddles them. There is no expectation that the labeler apply more than one area label, but only choose what it believes the best one and apply that. The question is whether this is a problem for training.
A possible improvement here could be to treat an issue with several area labels as an issue that appears several times in the training set, each time with one of those area labels.
Unlike dotnet/runtime and dotnet/aspnetcore, dotnet/aspire issues typically have more than one area label, which works well for their context as boundaries aren't always clear and stuff sometimes straddles them. There is no expectation that the labeler apply more than one area label, but only choose what it believes the best one and apply that. The question is whether this is a problem for training.
Currently the bot appears to train based on a random one of the area labels on an issue https://github.com/dotnet/issue-labeler/blob/0571c524404b80334144e365a4449bb111565ceb/src/ModelCreator/Downloader/OctokitDownloadHelper.cs#L224
That will make its predictions relatively poor.
A possible improvement here could be to treat an issue with several area labels as an issue that appears several times in the training set, each time with one of those area labels.
cc @jeffhandley would that work
cc @RussKie