If you use Jira project to track things that are not tasks, reading "Sub-Tasks" or "Sub-Issues" will be suboptimal and not in the context of the project.

There should be an option to rename headings of an issue, per project. For example, if you want to use a project in Jira to track assets (an old Atlassian blog post was speaking about this).

If the issue represents an asset like a Computer, the sub-task could be a piece of hardware inside that computer (ie. the Hard Drive), if the issue represent a Mobile Phone, a sub-task could be representing the SIM card inside, etc.

Instead of reading "Sub-Tasks" I would like to read "Parts" for example.

Andreas,

You are not missing anything as such and your suggestion makes a lot of sense. The reason behind the way things work at the moment is that a lot of customers wanted to restrict the complexity of sub-tasks (or sub-issues ) Especially in enterprise edition using a different issue type is very useful as one can ensure that sub-issues have a simple workflow (just open and closed), and different set of fields (e.g. only summary, type, and assignee), etc. Hence making special sub-task issue types restricts what each sub-task can be. We like to keep things simple to begin with and then expand as needed.

You suggestion makes sense going forward, however I feel it deserves its own issue.

Thanks,
Anton

Nick,

why do you make the difference between issue and sub-issue? (With an issue can be of type "Task"/"Bug"/"New Feature" and sub-issues can be of type "sub-task"/etc.)
wouldn't it be a simpler and more powerful approach to define a "parent" to an issue, so any type of issue can be a sub-issue of another type?
I mean, not just rename "sub-task" to "sub-issue"...

Example:
When entering a issue with type "new feature" named F, it might come up that there are several tasks to be done or issues to be solved to finish feature F.

• F
  • Task T
  • Bug B to solve
  • Improvement I to be developed

So if your developers have a look into improvement I and realize that there are several tasks to be performed for this single improvement, It would be great, if you just could add some sub-issues to the improvement:

• F
  • Task T
  • Bug B to solve
  • Improvement I to be developed
    • Task IT1
    • Task IT2
    • Improvement I2

We might also need a way to organize issues, to change the parent issue. There is already JRA-5272 pending, but this one specialized on the notion of sub-tasks being something different than regular issues. Also, Mahmad could add this to the bunch of issues he collected, as a part of the whole picture.

Theoretically, there might be an unlimited number of levels in the tree, maybe there must be way to limit this...

Did I make my point or am I missing something here?

Thanks
Andreas

Nick, elegant and diplomatic answer .....

Thanks for the comments Ahmad.
All text (well nearly all) can be modified to suit your own needs. With 3.5 even more will be able to be modified.

Cheers,
Nick

I had to agree to Pavlo - it looks like he is able to take a look from the outside on JIRA.

A sub-task is not a sub-task , it's a sub-issue .

Probably historical reasons?

I think the idea was to add just one sub-issue type as a child of
a parent issue - just to break down an issue in some partial stages.
It becomes just a sub-task.

But .... fortunately Atlassian did in a consistent way and added the feature
to define the type of a sub-issue. Now Professional/Enterprise customer
are able to define there own whatever the need sub-types.

So, it could be a sub-task to a parent issue, but
it could be also a sub-feature or sub-what-else.

The type of the sub-issue depends on the type the administrator defines.

Check JIRA: "Administration -> Sub-Tasks"

Add New Sub-Task Issue Type

But if you summarize the term, it's:

Add New Sub-Issue Type

If you don't setup multiple sub-issue types, you wouldn't run into this inconsistency.
Even Atlassian uses only one sub-issue type.

I know, a developer prefers to add 10 new features before changing the name
of an existing feature in all the code, documentation etc.

But please consider to rename sub-task to sub-issue - it becomes
more consistent and easier to explain to the users.

Giving a clearer summary & description.

Yes, sure.

Let we have 3 "Sub-task":

1) Sub-Task
2) Sub-Feature
3) Sub-Improvement

About all of than we can (I hope) say that we have 3 types of sub-issues.

Now, when I create a Sub-improvement, I press create SUB-TASK.

IMHO Sub-Feature will be just more universal name for any type of Sub-"SOMETHING"

Hi,

Could you clarify the problem for us? The sub-task is a type of Issue Type it is not an issue in itself.

Thanks,
Brian