Sub-tasks need to be reimplemented

[Belgand]

As written sub-tasks do not work as intended. A tree structure will likely be necessary to implement them properly. They are being left intact as they exist currently since they aren't causing any problems (now something will certainly break), but commented with FIXME.

django-mptt was mentioned as a good implementation of trees in Django, but we should research exactly what will work best for our purposes.

[kellanjacobs]

Sub-tasks should be removed from the project. I don't think there is a good use case for them.

[Belgand]

My idea was that they would serve larger, more complex projects. In my personal experience sub-tasks are often a very useful way to break things down and keep track of what you're doing. Especially when working with a number of people to prevent repetition of work, make it easier to understand all of the dependencies, and delegate jobs to particular people. Since one of the design goals was to engage people with the space in groups rather than just as individuals this seemed like a natural fit.

Creating a large group of items all at the same level quickly devolves into a bit of a mess without any ability to sort hierarchically. Personally I've encountered of a number of times when I wish issues here could be re-sorted and better organized or a larger task could be split up into smaller, nested bits.

As anecdotal evidence the Android todo list app Astrid had a tremendous demand for implementing them for a long time before they finally added them in.

[kellanjacobs]

I think our use case here is very different. I use Omnifocus to manage my personal task list and I find subtasks crucial, but subtasks seems to be not a good fit for our project goals. It seems like we are over engineering a solution. We are making the task form much more difficult to use.

[Belgand]

If the concern is creating a simpler user interface wouldn't it be possible to just collapse the sub-task portion? My intent was to have it be something you'd only add after having already created a task from that task's detail page.

Why do you not feel they are a good fit for our project goals? As I said earlier I think that they greatly help people to interact with the space as groups. Making it easier for people to keep track of what's happening with a larger or longer project. It also makes it easier for people who aren't working on something, but want to follow it to stay up to date by being able to follow the top-level. This means that very broad goals can be defined, like building out the bio lab, and then nested down for the actual work. Basically by adding sub-tasks we can make top-levels function either as very simple tasks or, by adding a series of sub-tasks to them, have them function as projects.

No, it's not necessary for short, easy tasks like taking out the trash, but I think it would be invaluable for larger buildouts and an essential way of communicating with others.

[kellanjacobs]

While I see your point Mark. There are a couple of issues. First useability is one of them. This goes back to the iPod vs all the other mp3 player debate. At no point in time was the iPod the most feature rich product. It was never really ever the best product. Though it is the best selling product because I can teach my grandmother how to use it.

Secondly managing bigger projects is outside of the original scope. Though I can see it having a place. Implementing subtasks is not the way to add this feature into the scope of the application. If we do decide that we need this feature than it would be better to create a taxonomy for projects. Then you could tag a each task by project. We could then display tasks by project.

I actually wrote a very similar application for my last job. We found a much better way to handle this problem. We used the todo as a generic holder for things that needed to be done. We considered them like a workorder at an auto shop. In our case items could be injected into the todo list by several methods. One is by scheduled task. (ie take out the trash). Items could also be input by a user of the system. (I need help with python) We also allowed our servers to connect via an API to inject todos in the system.

The reason we added this complexity was because of exactly what you are talking about above. Users had different needs and more details than say to take out the trash. Each todo could link back to the more verbose entry method. What this really did was allow us to have a simple todo list that could expand as we needed it vs packing in a bunch of features that were only sometimes needed.