[Feature][Jira] Allow users to define their own standard issue types and statuses

[Startrekzky]

Search before asking

• [X] I had searched in the issues and found no similar feature requirement.

Description

Allow users to define their own standard issue types and statuses when adding transformation rules for Jira boards at the 'create blueprint' flow.

Use case

Background

Users are using Jira for project management and they have following issue types:

• epic - indicating high-level goals
• story - indicating feature requests
• subtask - indicating technical tasks
• refactor - indicating refactor or infrastructure work
• bug - indicating bugs
• docs indicating documentation work
• support - indicating customer support work
• etc.

Users have following issue statuses for requirement issues

• open
• requirement-analysis
• design-in-progress
• to-do
• in-progress
• abandoned
• on-hold
• under-review
• testing
• closed
• done

Users have following issue statuses for bug issues

• open
• to-do
• in-progress
• on-hold
• abandoned
• to-be-verified
• verified
• re-open
• closed
• done

User stories

1. As a CTO or project manager, I want to understand how high-level goals are executed in the daily work on a monthly or bi-monthly basis. Specifically, I want to see how much development resources (No. of issues or time spent on issues) are spent on each type of issue:
   • Roadmap: all story and subtask issues with an epic link, including epic issues and subtasks whose parent issues have an epic link.
   • Unplanned: all story and subtask issues without an epic link, not including epic issues or subtasks whose parent issues have an epic link.
   • Infrastructure: all refactor issues
   • Support: all support issues
   • Other: the rest of issues
2. As a tech lead, I want to measure how many development resources (No. of issues or time spent on issues) are spent on each type of issues during weekly meetings. The issue types are:
   • Feature: all Story and subtask
   • Bug: all bug
   • Infrastructure: all refactor
   • Documentation: all docs
   • Other: the rest of issues
3. As a product manager, I want to measure requirement lead time and see which stage(status) takes the longest time. The current 3 standard statuses TODO, IN-PROGRESS and DONE only allow me to break down requirement lead time to issue cycle time from TODO to IN-PROGRESS and issue cycle time from IN-PROGRESS to DONE, which is too abstract to find out the bottleneck of the workflow. Hence, I want to find a way to group statuses together, so that I can measure the pickup time for status group defined by myself. For example:
   • Feature Analysis Time: time spent on open and requirement-analysis
   • Feature Design Time: time spent on design-in-progress
   • Pickup Time: time spent on to-do
   • Implementation Time: time spent on in-progress
   • Review and Testing: time spent on under-review and testing
4. As a QA manager, I want to measure bug age and see which stage(status) takes the longest time. I have the same problem as the product manager in Point 3.

User stories analysis

From the section above, we can see that:

• There're users who want to customize standard issue types and statuses.
• Different users might have totally different groups of issue types and statutes, based on their own classification logic and naming.
• The existing 3 standard issue statuses are too less to help identify workflow bottlenecks.

For instance, for user A, the wanted issue status groups might be

• group 1: status A, status B
• group 2: status C, status D
• group 3: status E, status F

while for user B, the wanted issue status groups might be

• group x: status A
• group y: status B, status C
• group z: status D, status E, status F

Conclusion

Essentially, users need a convenient way to configure how metrics related to type and status are aggregated. Once users have configured it, the embedded dashboarded can display the metrics without having to write a query to do so.

Related issues

No response

Are you willing to submit a PR?

• [ ] Yes I am willing to submit a PR!

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

Plan of attack

https://github.com/apache/incubator-devlake/issues/2535#issuecomment-1223739001

[leglars]

One suggestion: I don't think the process of defining standard types and statuses need to live in or bundle with "create blueprint", which can be a board or connection level configuration.

[hezyin]

@Startrekzky Thanks for the detailed user stories and analysis.

I need some help in understanding the benefit of allowing users to define custom standard issue types/statuses.

In our old approach, users map their original issue types/statuses to a fixed set of issue types/statuses that DevLake knows of and uses to write SQL queries. The benefit is then users don't need to worry about metric calculation and creating dashboards. The limitation is that users are restricted to the fixed set of issue types/statuses that DevLake provides.

If DevLake allows users to define their own standard issue types and statuses, since DevLake doesn't know about these custom issue types and statuses beforehand, I imagine the users would still need to implement metrics/dashboards by themselves? How does DevLake work with those user-defined standard issue types and statuses?

[Startrekzky]

If DevLake allows users to define their own standard issue types and statuses, since DevLake doesn't know about these custom issue types and statuses beforehand, I imagine the users would still need to implement metrics/dashboards by themselves? How does DevLake work with those user-defined standard issue types and statuses?

DevLake will provide pre-defined standard issue types/statuses that users can not change. In addition, DevLake allows users to ADD new types/statuses. Thus,

1. All the pre-built dashboards/charts based on existing standard types/statuses, such as Requirement lead time and No. of Bugs won't be affected, users don't have to modify these dashboards.
2. When users want to measure the distribution of issue types/statuses, for instance, Number or Ratio of different issue types/statuses and Mean lead time for issues in different types/statuses, users don't have to implement dashboards. Pre-built dashboards will do.
3. However, in some cases, users have to do customized dashboards. For example, to measure the metrics regarding a specific customized type/status of issues.

[hezyin]

@Startrekzky Thanks for the clarification. Now it's clear to me how the new proposal works.

Now my question becomes: do DevLake's standard statuses provide enough value to users?

If I understand correctly, the original intention of providing a set of standard statuses is to abstract away the process of defining metrics and creating dashboards from users. All they need to do is to map their original issue statuses to DevLake's standard statuses and then they'll get metrics and dashboards automatically.

But now it seems most likely, users would need to create their own metrics and dashboards anyway? In that case, is it still worth the cost to get users familiar with DevLake's standard statuses and do the mapping?

[klesh]

Plan of attack

1. Update the jira transformation rules struct and subtasks to support defining type/status mappings

{
  "epicKeyField": ...,
  ...
  "typeMappings": {
    "<USER_TYPE_1>": {
      "standardType": "<STD_TYPE_1>",  // STD_TYPE can be anything, we assume, it would be a pre-defined devlake standard type or user-defined value, we will never know.
      "statusMappings": {
        "<USER_STATUS_a_from_USER_TYPE_1>": {
          "standardStatus": "<STD_STATUS_1>" // STD_STATUS is the same as STD_TYPE, can be anything.
        }
      }
    } 
  }
}

The jira issue extractor is to be updated: - issue.std_type conversion stay unchanged. - issue.std_status should be equal to <STD_STATUS> IFF mapping was defined in statusMappings under the same USER_TYPE - otherwise, we fallback into existing logic: take the value from statusKey

2. Update jira blueprint swagger document
3. Update jira official document
4. config-ui support @yumengwang03

[mappjzc]

document part dismantling disassembled to #2864

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity for 30 days. It will be closed in next 7 days if no further activity occurs.