Labels converted from Trac Type, Component, Priority, Resolution, Status, special Milestones, some Keywords

[mkoeppe]

as proposed in https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#proposed-workflow-on-github-with-transition-guide-from-trac

Type ("defect", "enhancement", "task") is mapped to a "Label" with prefix t:, e.g., t: bug
Component ("basic arithmetic", "linear algebra", "geometry", ...) are mapped to "Labels" with prefix c:
Priority ("major"/"minor"/"critical") is mapped to "Labels" with prefix p:

[tobiasdiez]

The labels can also be renamed after the migration

[soehms]

The labels can also be renamed after the migration

Why do you want to rename them? Because the name is unsatisfactory or because you want to change the meaning? In both cases we also need to adapt this to the migrated tickets (to keep them visible there). In the first case, it would be more efficient to find a satisfactory name before migrating. In the second case, there could be confusion regarding the migrated tickets.

I think the main problem we have here is that the GitHub labels are not a suitable substitute for select lists. If these labels are in place, they can also be used for new issues (not just migrated tickets). Then there may be issues marked as p:blocker and p:trivial at the same time. If mapping the Trac select lists to labels is the only option, we need GitHub actions (triggered by on: issues: types: [labeled, unlabeled]) to ensure that only one label of each group (p:.... , t:... ...) is set.

As for naming, I would prefer if they were all prefixed with trac (for example trac_p_major) so that users who have never worked with Trac can see where they came from. Is there a special reason to choose a comma as a separator?

[tobiasdiez]

What I meant was that the prefixes don't necessarily have to be added as part of the migration, i.e. its fine to migrate tickets and label them with "bug" , and then after the migration rename the label to "t: bug" without any issues (and this then automatically applies to all issues). If its however easy to prefix them in the script, then there is of course also no harm in doing this now.

we need GitHub actions (triggered by on: issues: types: [labeled, unlabeled]) to ensure that only one label of each group

That only makes sense for some groups. For example, you can easily imagine an issue that is a bug and needs changes to the docs (t: bug + t: docs).

The idea was to keep using these labels also for new issues/pull-requests, right?

[soehms]

What I meant was that the prefixes don't necessarily have to be added as part of the migration, i.e. its fine to migrate tickets and label them with "bug" , and then after the migration rename the label to "t: bug" without any issues (and this then automatically applies to all issues). If its however easy to prefix them in the script, then there is of course also no harm in doing this now.

I see! Sorry for misunderstanding!

That only makes sense for some groups.

Sure! Groups that come from select list and radio buttons via the migration.

The idea was to keep using these labels also for new issues/pull-requests, right?

Independent whether that is the idea or not, if they are there they can be used. Or can we block them after the migration?

[tobiasdiez]

Or can we block them after the migration?

Nope, as of now, you can only delete labels (which then also removes them from the issues). A workaround would be to rename them to something that sort them last and add in the label description that they shouldn't be used.

[soehms]

Or can we block them after the migration?

Nope, as of now, you can only delete labels (which then also removes them from the issues). A workaround would be to rename them to something that sort them last and add in the label description that they shouldn't be used.

Maybe changing habits will be easier if we keep them (see my recent post on sage-devel). But when we do that, we should eliminate sources of confusion.

[mkoeppe]

Also we should not create "PLEASE CHANGE" labels - https://github.com/sagemath/trac_to_gh/blob/main/Issue%2018792.md

[mkoeppe]

In a8ace24, I introduce a "component: " prefix (instead of the cryptic "c: ") and reduce noise by suppressing labels for the default priority and for ticket types other than "bug".

[tobiasdiez]

I would still add types for enhancement/feature request and questions. You can always remove labels later, but it's going to be hard to add the correct labels after the migration. Also it's handy to e.g. filter out questions (which me might want to convert to Discussions anyway).

[tobiasdiez]

The ticket status (needs review etc) should also be mapped to a label.

[mkoeppe]

Not sure about "needs review" because that is just the status of a non-draft, non-approved PR. (See #57 "create PRs instead of Issues for closed tickets with branches")

[mkoeppe]

But I agree that we should make an effort to map to the default labels defined by Github:

• "duplicate" (map from Resolution: duplicate)
• "enhancement" (map from Type: enhancement)
• "good first issue" (map from keyword: beginner)
• "help wanted"
• "invalid" (map from Resolution: invalid),
• "question" (map from Status: needs_info)
• "wontfix" (map from Resolution: wontfix)

[mkoeppe]

We may also want to get rid of the special milestones and map them to labels instead:

• "sage-duplicate/invalid/wontfix" milestone: map it to label "invalid" unless Resolution is set to something more specific
• "sage-feature" map to label "feature"
• "sage-pending" map to label "pending"
• "sage-wishlist" map to label "wishlist"

[mkoeppe]

In the code, we can change keywords_to_labels from boolean to a dictionary - some keywords to be mapped to labels (for "beginner"). Done in e46ee3d

[mkoeppe]

Resolutions are now mapped to labels (done in 40f262d)