问题类型是为了在请求之间起到简单区别的作用，范例: 缺陷、任务、功能，等等。
名称
描述
类型 (标准类型(父) 或子类型 (子))
图标
图标在筛选器、仪表盘、面板和邮件通知上提供了视觉上的区别。
你可以为每一个类型设定一个标准动作(例如: 界面) 。
理想的情况下，你会有一个问题类型来指出软件的错误。
相反地，有一家公司有9个，例如：Bug、缺陷、Beta缺陷、Bug报告、研发缺陷、生产缺陷等，此外，他们还有22个问题类型表示“任务”!他们所有的条目很多是重复的，并且很难区分。你拥有越多的问题类型，你应用上的管理就越困难，一长串的问题类型列表意味著移动问题或是将问题类型关联不同的工作流需要较长的流程。
在创建新的问题类型之前，思考一下什么类型的问题你的用户需要提交报告并且将这些问题类型组成一个通用的条目，这里有些范例:
| 问题分类 | 问题类型名称 | 注记 |
| 我发现了一个：研发缺陷、准生产缺陷、生产缺陷 | 缺陷 | 不要使用多种问题类型，而是使用自定义的字段来收集收集环境(位置)的缺陷 |
| 我需要一个：密码、构建密钥、服务器帐号 | 访问，或是可以使用更通用的词(例如：支持) |
在请求副本中，用户需要指定的访问类型，如果这些还不足，仍需要你额外查询访问类型的话，使用标签(Label)、组件模块、或是自定义字段来收集层级的细节 |
问题类型方案，一个问题类型的组合，当谈到创建项目类型时，重点是要让事情有条理。
名称
描述
默认问题类型 (例如: 任务)
问题类型 (包含子任务)
可以限制项目仅使用特定的问题类型组合
示例: 研发团队的项目：功能、缺陷、任务
示例: 商务团队的项目可以使用：请求和任务
在一家公司里，有几个项目使用默认问题类型方案，这个方案包含每一个可用的问题类型，当创建新的问题时，报告人非常不知所措，为什么？因为他有超过100种问题类型的选项！
这些选项甚至不是按照字母排序的！项目负责人出报告或是要分割目前团队正在处理中的问题会非常困难。不要使用默认的方案。
使用子任务，这可以帮助用户拆分问题成可管理的片段。
将问题类型按照字母或是按照使用频率排序，这样用户能够快速找到正确的问题。
下面是一些问题的类型的示例，你可能会在不同的项目中发现他们。
| 项目类型 | Software | Business | Support |
| 问题类型 | 缺陷 代码审核 史诗 改善 新功能 故事 任务 子任务 |
主意(Idea) 任务 子任务 |
新建项目 修改项目 用户 任务 子任务 |
使用上表的范例，为这三种项目类型各自创建一个新的问题类型方案，每一种方案关联适当的问题类型，接着，每一个项目都使用最适合的方案。
例如：所有软件研发项目都可以使用"Software"的方案，不需要每一个项目都各自有一个独立的方案。
问题类型方案的名称应该是能描述一组问题类型而不是计划用来分组的项目，例如：“开发套件”
问题类型的名称应该通用些，例如：“任务”，不要让用户为每一种任务请求都有一个新的问题类型。
本文节选自《JIRA策略管理实战手册》，为应用程序管理员提供配置、清理和维护Jira的模板。
此实战手册包含：
152条建议- 帮助您设置、清理和维护Jira
50个工作表，以及其他相关模板、代码片段和示例- 帮助您建立和简化主要工作
33个需避免的反面真实案例
每个管理区域的最佳实践和注意事项
我作为管理员犯下的十大错误
此实战手册向您展现：
精心策划并得以实施的行动项
工作流管理的简单方法
如何审计及清理应用程序
维护和扩展Jira的方法
如何创建可重复的流程
如何远离“Jira沼泽”
