MIGRATION: Retain issue priority?

[toddfarmer]

The source ASF Jira system has a dedicated Priority field, for which there is no equivalent in GitHub issues. Should we use labels to retain this information as we migrate? For example:

• Priority: 1
• Priority: 2

I personally prefer numeric priorities over strings such as High or Urgent, because it makes relative priority readily apparent without having to consult the list of possible values (and interpreting whether High or Urgent has higher priority). But I'm open to suggestions if other values are preferred.

[toddfarmer]

As a note, it is possible to create custom fields in GitHub projects, which would allow explicit Priority field definition and tracking. That said, it seems it is not possible to directly query project custom fields for issue searching, except within the context of a specific project.

[toddfarmer]

Example:

[jorisvandenbossche]

I think we mostly use "Priority: Blocker" for release management purposes, and somewhat "Priority: Critical" for prioritization of work. I am not sure we really use the other levels.

[raulcd]

I agree with @jorisvandenbossche here. The Priority: Blocker is really helpful for release management purposes and maybe another for work prioritization but the rest of the levels don't seem necessary in my opinion.

[jorisvandenbossche]

Short term, we can maybe "just" (assuming this is not too hard to set up) map the priority to labels? And then we can still later see if we want to keep all of them or only the blocker/critical ones?

[toddfarmer]

cc @rok to evaluate what needs done here.

[rok]

I like the idea of just bringing in the Jira priorities as labels. We would then have:

• Priority: Blocker
• Priority: Major
• Priority: Minor
• Priority: Trivial

[wjones127]

I'm skeptical those labels 4 labels are actually used. I'm personally only in favor of bringing over labels that are used in practice. Realistically, I think we only need two labels:

• release-blocker: which tells us we cannot bump this issue to the next release milestone
• critical-fix: which tells us we should prioritize fixing this over most other things. Defined as is in https://lists.apache.org/thread/s49bkj8ckgcjvjskhhz26xy1xscrswdp

I'm not familiar with any practice that involves Major/Minor/Trivial, and other commenters on this issue seem to be saying the same thing.

[rok]

I think these labels are used but not consistently so not sure if they are net good.

As for release-blocker - it could be skipped in favor of convention that everything within a milestone is a blocker for it.

[wjones127]

it could be skipped in favor of convention that everything within a milestone is a blocker for it.

Not sure about that. I think we often tag issues with the release to indicate that we would like to get that included, but not that it's absolutely necessary. It's helpful to have a tag that distinguishes what's nice to have and what's necessary. But maybe there's a better way to do that?

[rok]

Yeah, having an explicit label there will make it easier for the release work indeed. We would then migrate the following labels from Jira:

• Priority: Critical
• Priority: Blocker
• good-second-issue

[rok]

If there are no objections I'll create the last proposed labels when I start the migration sometime this week.

[raulcd]

@rok I have created the three labels as we are going to need the Priority: Blocker in preparation for the release. I am going to start asking people to mark any release blocker with it on the mailing list and Zulip.
Edited: Priority: Blocker is the required for the release, not Priority: Critical

[rok]

I suppose this is resolved then.