What are the "issue type" field advanteges? statistic only?
What is affected by the type? is it the issue fields, project evaluation, workfllow workes any different?
A lot of configuration is defined by issue type (in a project). You can make Project1:bug behave completely differently to Project2:bug if you want.
I'm not sure what you mean by "project evaluation", but workflows, fields and screens used can be configured independently, and you can have different types of issues available to different projects.
Hi Nic,
I tried it, and could not find any infuluence , if all other parameters are the same: Workfllow: the default is the same, so I can copy+change it...The benefit of choosing each type (or even not choosing at all) is not clear to me.
I undersand that each screen+fields can be configured independently, but is it uniq for each issue type?
...Beside the diiffer names: Task, Bug, Purchase... all types seems (to me) the same.
Shavit
Shavit,
In each project that you create, you can treat each issue type differently. You can create a custom workflow for each issue type or you can create different issue types with different custom workflows all within one project. You would setup your issue types for each project using Issue Type Schemes, and in order to setup the different workflows, you would create each workflow you want to use and configure a workflow scheme for each project. Also, you can use a different field configuration for each issue type as well. So a Bug in a Development project for example can include 20 fields that your users would have to fill in to provide your developers with as much detail as possible. On the other hand, you can also have a Helpdesk project and an issue type called Ticket which would only include 5 fields for very simple and basic requests.
Jira is customizable at almost every level, so the main question you should ask, is how you want it to work and then from there you can start to configure it in that way exactly. One thing we did to start was literally draw out our workflows in flowcharts. Based on the workflows that were required for different types of matters, we determined how many projects and issue types we wanted to create for our instance.
Hope this helps.
Sharon
Hi Sharon,
as you write:" So the main question you should ask, is how you want it to work and then from there you can start to configure it in that way exactly."
as you write:"
I know what I need, but I dont know which "issue type" to choose: as they are seem to me the same. The same as I cregte one. all has the same effacts and utilities. So, as I can see it the advantege is only statistics...
Pls explain me, in detailes what is the differ between: "issue type" BUG and TASK. Maybee then I will understand.
For now it is only differ by name, and then I can not understand why "Project Type"= 'Service Desk Type' include only the optional "issue types" Access, Change, Fault, IT Help and Purchase.
While "Project Type"= 'Simple Tracking Type' include only the optional "issue types" Task, New feture and subtask.
While all other "Project Type" has the full 13 "issue type"s.
For what I see, only one project type coulde be provided, that include all 13 "issue type"s. Each configuration is uniq any how...
Thanks,
As I said earlier, the issue type is something you hang the configuration off.
Technically, there is no difference between issue types ("Epics" excluded as they do things differently in the Agile plugin). It doesn't matter if you call an issue type "Bug", "Task", "Feature", "Dave", "Mystical Penguin", they're just issue types.
In the real world, you probably want to gather different data for Bugs and Tasks. In English, a Bug is something that's gone wrong with the software, usually because of a coding flaw (although named after an alleged incident where an insect got into a computer and clogged up the hardware!). A Task is something that needs to be done. For a bug, you might want to capture the version it's found in, but for a task, you don't. So you have different fields or screens to do that.
Off the shelf, Jira treats all issue types in the same way. They do the same thing. Until you, as an admin, chooses to do something different. Y
ou do this with "schemes" - an "issue type scheme" says "in this project, offer these issue types to the user". An issue type screen scheme says "in this project, use these screens for issuetype A, these for B, these for C". A workflow scheme says "in this project, use workflow 1 for Bugs, workflow 2 for tasks and workflow 3 for all the other types". And so on.
Out of the box, there is no difference between an issue defined as a bug, and one defined as a task. It is all dependent on what you do with those issue types. For each issue type that you have in 1 project you can do the following:
1) Use different workflows: For example, a bug that is a development issue would have 6 steps between being opened and resolved. Our workflow requires that a bug be confirmed by the developer, then the developer starts progress, resolves it, a QA person verifies, and then closes once in production. A task, can be as simple as asking someone to provide data. So a task in our instance gets opened, starts progress, and gets resolved. You can create different workflows using the Jira diagram tool under: Admin > Issues > Workflows. Once you have a workflow for each issue type, you will be able to associate them with one another by going to workflow schemes.
2) Field Configurations: In our instance, we require more fields to be filled in for bugs than we do for tasks. For bugs, we've even created several custom fields such as QA contact. Each issue type can have a different field configuration.
3) Screens: Each issue type can also be assigned different screen configurations. For example, when you create a new issue, you use one screen. You can decide that a bug should show certain fields when being created, and a task would require other fields.
Using the different issue types allows you to customize things to the level you might need. If you use the same issue type in the same project, keeping things organized, utilizing filters, and using Jira to its fullest potential will be very difficult.
Hope this answers your questions.
It looks like you're new here. Sign in or register to get started.
