Map GitHub Labels to JIRA Issue Types

[adambkaplan]

Allow config options which map a label to an issue type in JIRA. For example, if a GitHub issue has the label bug , create a JIRA issue with the Bug type.

This should be flexible per repository, as well as allow a fall-through default (ex: "Story") to be set.

[mattreid]

@adambkaplan There's already a default type that can be set in the config options (type='Story'), but I agree it would be helpful to have some mechanism for certain identified issues to be created as a different type.

[Zyzyx]

Users can make a label anything they want, so we'd have to be precise about what the mapping is supposed to be. Issue type schemes or the types themselves on the Jira side might change, which could confuse things too. Here's an example of what I propose adding to the config:

'GITHUB_USERNAME/Demo_project': {
   'project': 'FACTORY',
   'issue_types': {
      'bug': 'Bug',
      'enhancement': 'Story'
   }
   [...]
}

keys are labels, and values are issue types. You'll note that bug and enhancement are default labels available in github. I'm thinking that the Sync2Jira code will expect this mapping at all times for every project, but maybe the lack of the mapping means we should default to the "Story" issue type?

I'm a little against failing over to an issue type if a specified one is not available, I think that should be an error because moving issues is an expensive op on the Jira side. Issue types may have custom workflows and fields that will need to be reset when moving between types.

What do you guys think?

[ralphbean]

I like it. I wish that we had and could require the use of "scoped labels" for this, so that we can be sure that an issue does not receive both the bug and the enhancement label at the same time, in which case our behavior would be undefined.

What should sync2jira do if an issue receives both a bug and an enhancement label?

[ralphbean]

Also, what should the tool do if both bug and enhancement are removed?

[adambkaplan]

I'm a little against failing over to an issue type if a specified one is not available, I think that should be an error because moving issues is an expensive op on the Jira side. Issue types may have custom workflows and fields that will need to be reset when moving between types.

Isn't this the current state, with the default type is "Story"? If no match is found, I think teams would rather have upstream items in the backlog vs. not and stuck in an email (or worse, not present at all).

What should sync2jira do if an issue receives both a bug and an enhancement label?

Agree this is a very likely scenario. If the issue types mapping is stored as an array, maybe the code just iterates and the first match wins? This behavior should be deterministic, and I don't foresee a huge performance penalty. My hunch is the the number of entries per project/repo will be small (less than 10).

Also, what should the tool do if both bug and enhancement are removed?

Perhaps we only worry about issue type at the point of story creation? As @Zyzyx mentioned, changing the issue type can be an expensive operation, so I don't think sync2jira should move issue types. This also helps narrow the scope.

[mattreid]

Agree that syncing something seems more valuable than having some kind of interim un-synced triage state that could get overlooked, but I don't have as broad exposure to projects as some here probably to say how painful it could be to move and re-type the occasional issue.

Could it apply a label or some kind of flag when syncing a potentially ambiguous issue to indicate that more triage may be necessary? Could also use that with a comment if the labels change later, rather than trying to automatically move it to the new type. If it becomes a large volume for a team, having an easy way to find those issues could make process conversations easier to try and mitigate it moving forward.

[Zyzyx]

Proposal 2 after this feedback.

There are 2 options to consider for issue types. type exists today and if specified, sets the issue type for any issue sync'd over. If it is absent, Bug is the default. issue_types is what I'm proposing is added. If absent, no behaviors change. If present without type, then it will perform as follows:

• if the upstream issue has exactly 1 label matching one specified in issue_types, use that (the simple case)
• if the upstream has multiple matching labels, take the first matching one alphabetically. Drop a comment warning that others were considered and ignored.
• if the upstream has no labels, default to Bug

If type and issue_types are specified, then the behavior for the last case changes. Instead of defaulting to Bug, it defaults to whatever type is set to.

I further support Adam's position re: changing labels later on. I don't think Sync2Jira should try to migrate issue types. We could drop a comment in consolation. I'd treat changing types post-creation as a separate RFE, the error handling alone is going to be a lot.

[ralphbean]

That sounds good. Let's try it.

[mattreid]

Overall, that sounds like a good starting point to me.

if the upstream has multiple matching labels, take the first matching one alphabetically. Drop a comment warning that others were considered and ignored.

Would it be valuable to additionally apply some kind of 'sync2jira_triage' label in this situation? If there's just a comment, that helps in the moment, but I don't think I could easily find all similar issues in my project(s) with a query.

[Zyzyx]

Are you suggesting that sync2jira_triage be a label that identifies work items that had a non-critical error and a team should possibly take further actions? I could see that being valuable in broader use cases, but maybe a separate RFE?

[mattreid]

Yes. I filed #171 for that triage listing assistance. It could be useful here, but doesn't need to block this change if you want to keep scope small.

[mattreid]

Of note here, this may get simpler in the future. From looking at GH's public roadmap - github/roadmap#837

[Zyzyx]

PR is ready