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

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"

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.

modified to suit your own needs

Cheers,
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

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