Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MIGRATION: Track issue type #14507

Closed
Tracked by #14542
toddfarmer opened this issue Oct 25, 2022 · 5 comments
Closed
Tracked by #14542

MIGRATION: Track issue type #14507

toddfarmer opened this issue Oct 25, 2022 · 5 comments

Comments

@toddfarmer
Copy link
Contributor

In anticipation of a potential migration from ASJ Jira to GitHub for issue tracking, an assessment is needed on whether we need to retain the ability to meaningfully track different issue types (bug, feature request, etc.). Issue type is a top-level Jira construct, but there is no corresponding attribute in GitHub issues. Alternatives may include labels or custom fields.

@toddfarmer toddfarmer changed the title Track issue type MIGRATION: Track issue type Oct 25, 2022
@toddfarmer
Copy link
Contributor Author

toddfarmer commented Oct 25, 2022

I've initially implemented this as follows, which covers all issue types currently in use in the ARROW Jira project (example here):

def set_issue_type_label(issue, labels):
    issue_type = issue.fields.issuetype.name
    if issue_type in ["Bug"]:
        labels.append("bug")
    if issue_type in ["Improvement", "Wish", "New Feature"]:
        labels.append("enhancement")
    if issue_type in ["Task"]:
        labels.append("task")
    if issue_type in ["Sub-task"]:
        labels.append("sub-task")
    if issue_type in ["Test"]:
        labels.append("test")
    return labels

@amol-
Copy link
Member

amol- commented Oct 26, 2022

Flagging thins as "sub-task" doesn't seem super useful, and I doubt anyone will add the label.
It probably is more useful to add a section at the end of the parent issue description with the link to the subtask. Like voltrondata/substrait-r#205

That will make so that GitHub properly tracks them as sub-tasks

@toddfarmer
Copy link
Contributor Author

To me, this issue focuses on defining what we want to retain of the ASF Jira issue type field. As you rightly note, retaining references across Jira issues has significant additional value, and I've opened #14520 to track that independently. I still think there's value in knowing the issue type of an issue migrated from ASF Jira. If not "sub-task" as a label, should we not include an explicit type label? Should we call it a "task", effectively elevating it from sub-task to task?

I agree that the notion of a "sub-task" label is unlikely to be consistently applied in future manually-created GitHub issues, though it may be possible with issue templates and forms (e.g., a special form to create a sub-task of an existing issue which properly sets the label and requires a reference to the parent issue).

@assignUser
Copy link
Member

I have added some examples/details about task lists in #14520

still think there's value in knowing the issue type of an issue migrated from ASF Jira. If not "sub-task" as a label, should we not include an explicit type label? Should we call it a "task", effectively elevating it from sub-task to task?

eh, sub-tasks are marked as such by the "tracked in"-badge, I don't think that is worth another label. For the other types labels make sense.

@toddfarmer
Copy link
Contributor Author

The logic has been updated as follows:

    if issue_type in ["Bug"]:
        return "Type: bug"
    if issue_type in ["Improvement", "Wish", "New Feature"]:
        return "Type: enhancement"
    if issue_type in ["Task", "Sub-task"]:
        return "Type: task"
    if issue_type in ["Test"]:
        return "Type: test"
    return None

@rok rok closed this as completed Jan 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants