Issue type advanteges

[Shavit Gur]

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?

[Nic Brough -Adaptavist- · Accepted solution]

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.

[Shavit Gur]

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

[Sharon Shapira]

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

[Shavit Gur]

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."

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,

Shavit

[Nic Brough -Adaptavist-]

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.

[Sharon Shapira]

Shavit,

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.

[Shavit Gur]

Hi Nic,

First: my apology if the question sound as I dont know the dictunary diffrent, in eng, between the words -:)

Second: Are you saying that the BUG "issuue type" will have the option to the "version" field, that can not be added to the TASK "issuue type"?

If this is not what you meant and it is allowed to be added, then it is as I meant: The system is provided with some default schemes, issue types, screens the the configured fields etc. Just in order to supplay common "issue type"s. And I have to explore each provided "issue type" for all its componets, in order to discover the differ.

And this is exactly what I ask: Can you, pls prescribe (to list) the main differ between each "issue type"...So, I will know which one to choose, instead of trying them all....

Thanks,

Shavit

[Sharon Shapira]

Shavit, to answer your question a bit further, out of the box, there is no difference. You don't even need to stay with the pre-created issue types. You can create your own issue types with names that work best for your business. The difference between the issue types comes in how you configure them in terms of workflow and fields.

[Shavit Gur]

Dear Sharon,

It is certenly more clear now.

And now is the following question: Which "Project Type" to choose? If BUG "issue type" (for example) is available in must of the optional "Project Type"s ( beside 'Simple Tracking Type' and 'Simple Tracking Type'), is there any influence to the "Project Type" that I choose?

Oops...will it be clear some day?

Best regards,

Shavit

[Sharon Shapira]

Hi Shavit,

Project type is also something that can be changed to match your preferences. As both Nic and I mentioned, Jira comes with default settings. One default project type will be setup with a certain workflow and certain issue types. The best way to view Jira is more like a blank page, where you can utilize it to create the environment you prefer.

If you create your own project, you can set it up however you wish. The project type is determined by the issue types you include, by the workflows you create, by the people you give access to that project. It is all variable based on what you choose to do with it.

I felt pretty lost myself when just starting to setup our instance. I would recommend reviewing the steps here and following them one by one. https://confluence.atlassian.com/display/AOD/JIRA+Administrator%27s+Guide

You will quickly start to understand how everything works and how one thing affects the other.

Thanks,

Sharon

[Shavit Gur]

Thanks to you both Nic and Sharon..I think that now it much better.

With the practice it will be more clear.

Shavit

[Nic Brough -Adaptavist-]

>my apology if the question sound as I dont know the dictunary diffrent, in eng, between the words

It's just a language thing. You have absolutely no need to apologise for not understanding the subtleties of English - I don't grasp all of them, and I'm English (and, to my shame, don't speak any other languages)

I was just trying to say that the words have different meanings, but, more importantly, the actual meanings do not matter. You could rename Bug to Beetle, Insect, Glitch, Blob... it does not matter what the label displayed is. What matters is the configuration you associate with each project/issue-type (and the default is a simple "one of each scheme, and those are the defaults") I think Sharon has said everything else I wanted to say!

[Shavit Gur]

I appriciate the time and the effort you have made. You conribute my understanding as Sharon did. The discuttion it self contribute, also.

Regards,

Shavit