Create sub-tasks to specify which part of a task is done

[hauke96]

trafficstars

This would be a second method to finish a task:

Divide a task further into smaller sub-tasks which can be set from "todo" into to "done". The overall task finish state (so the percentage) can than be calculated from the amount of finished sub-tasks. This maybe makes it easier to keep track of the process within a task.

There are some questions coming up:

• Why not directly create smaller tasks? Is there a key advantage of this solution over generally smaller tasks?
• Can every project have sub tasks?
• Automatic or manual size of the sub-tasks?
• How does the project creation look like? Does the user has to decide which "type" of project he want's to create?
• Can I create sub tasks within a sub task?
• Technical stuff
  • When are the sub-tasks created? (project creation vs. on-the-fly during the work on a project)
  • Is this a new type of entity? (project, task and the new "sub task")
  • How to distinguish a project with and without sub tasks? Is there even a difference? Do we wan't to also create a new entity type for projects (a somehow "ProjectWithSubTask" project)?

This is an interesting idea but also quite complex.

[Strubbl]

Why not directly create smaller tasks? Is there a key advantage of this solution over generally smaller tasks?

In rural areas it might be nice to have larger size tasks, whereas in cities there are so many things to map, that it would make sense to have much smaller tasks. I would like to see the "usual" behavior which i know from the HOT TM, where i, as a mapper, can divide a too large task into 4 smaller parts.

Why not directly create smaller tasks?

Because it is very boring to have many tasks for one farmland. And because there's the 1000 tasks limit.

[hauke96]

Why not directly create smaller tasks?

Because it is very boring to have many tasks for one farmland. And because there's the 1000 tasks limit.

But why not creating smaller tasks when creating the project using the divide-feature for tasks? This would eliminate the problem of too large tasks for city areas and too small tasks for rural areas: (But I have to admit this does only work for squares)

Best would probably to just make a project editable and just enable the owner to change geometries of tasks after the project has been created. Even though this isn't the actual idea of this issue, it would be the most useful. But editing an existing project is not a small feature as well.

[Strubbl]

But why not creating smaller tasks when creating the project using the divide-feature for tasks?

Because different mappers have different preferences. This would also mean, that i, as a creator of the project, have to think about which size for the current area of the map makes sense. It increase the time to create a project a lot. And I have to do the slicing at the point in time when i create a project. This cannot be done afterwards. Also, i cannot save my slicing progress, which i might lose when i encounter bug #175.

Maybe there is a separate tool to create a sliced polygon in advance, which i can import into STM then?

[hauke96]

This would also mean, that i, as a creator of the project, have to think about which size for the current area of the map makes sense.

Yeah ok, that might not always be possible.

Maybe there is a separate tool to create a sliced polygon in advance, which i can import into STM then?

You can always use external tools (JOSM, QGIS, online editors, ...) to create geometries. STM can import them, just take a look at the"Upload" section in the "Import" tab when creating a project. Standard formats like GeoJSON and others are supported.

[pyrog]

• Why not directly create smaller tasks? Is there a key advantage of this solution over generally smaller tasks?

A project to integrate i.e. hiking routes coud have big tasks by cities, and then subtasks by hiking routes (see #213).

Clicking on a task display it's subtasks in the list and on the map. The list coud display/hide subtasks "inside" the parent task (or in a hierarchical list). Each parent task have one point for each subtask.

In the following example we have top level tasks for "cities" (admin_level=8 + boundary=administrative)

• Kerlouan
• Kernilis
• Lannilis
• Guissény
  • Route 1
  • Route 2
  • …
  • Route 10

In project 666 I tried to mimic a click on Guissény. STM display 10 hexagons, one for each "route". But in the list, subtasks (numbered tasks) are listed at the same level than main tasks (named tasks).

[hauke96]

@pyrog I understand your use case. But generally I'm not convinced about the whole sub-task idea yet. The word "simple" in "SimpleTaskManager" is there for a reason. For me, things like sub-tasks, hierarchies, etc. cross a line regarding the simplicity of STM.

I also thought of a simple visualization based on the task names. Like when a task name is a prefix of another task, then this other task is shown a bit indented. To model the hierarchy simply by some margin in the list entries. But I'm not convinced about this either, because I don't not if people would be annoyed by such feature or not. Maybe some separation characters are needed, so that the task "Route#Route 1" is shown as "Route 1" and indented below the task "Route". Maybe that would work, but I have to think about it.