Progress

[cirrob]

How come when I complete a Task within a project the project itself is still marked as not started? It seems very obvious That this would indicate The project shas started.

[Domas]

Hi,
But there definitely could be cases where this is the required behaviour.
So it is set up so that the user can decide himself on project status.
I find it reasonable.

[Stéph]

Hello cirrob,

There have been a few discussions on this topic. MLO is trying to be flexible enough for everyone's systems, so there is no link between the settings of any of the parameters. That means that you end up having to manually set lots of parameters for each task, which makes it a bit slower to use. Personally, I've argued for the idea of being able to set custom behaviours, so that items can be set to inherit (or not) start and due dates and contexts from their parent or nearest sibling and so that checking off a project sets its project status to completed. Maybe that automated functionality will be added as an option in the future.

[cirrob]

I don't see that.  If you have a project, with subtasks, that means those subtasks are part of the project.  And if you complete a subtask on a project, the project has started because work on it has started, ergo the default should be to the behavior I described.

But I'll humor you: let's say that there are some use cases where this behavior would not be the norm.  Fine... but I think we can all agree, those would be outliers; the exception, not the rule.  So, in an effort to accommodate the masses from several more clicks, we should pander to the normal use case rather than the exception and make it the default behavior as to inconvenience the least amount of users, and for those VERY few users who do not need this normal and expected behavior, they can turn it off; not the other way around and the majority can turn it on.... in what world does that make sense?  

Yes, the app is being flexible.  But there is a line which has clearly been crossed in this one workflow that goes against the normal use and expected behavior.  

Just ask anyone when a project has begun:  Is it when work has begun on the project or some other time after that?  The answer will almost always be, "When work has been done on the project."  So why not accommodate the majority, and most logical use case, with the option to turn it off for the extremely rare instance when this would not be the acceptable and desired behavior.

[Domas]

Hi,

well, I think MLO positions itself as a personal task management solution and not a professional project management software.

In these terms, the "Project" in MLO means quite a different thing than a usual business project. The most prominent use case is GTD system, which defines a project as "any task, which requires more than one step".

In this sense, I can easily see how I would want to see the project "Not started", even if few tasks are already complete. Perhaps I would want to have few preparation tasks at the beginning of the project. For example, if my project would be "buy a car", maybe I would want to complete few things like, "decide do I need a car" or "look for options", but still don't have a project as "Started".

If the project is just a list of tasks and not a business project with clear definition, then the "Project status" property becomes just one more property of this item, which you can set up in any way you want, depending on your productivity system.

Of course, I would agree that it would be good to have a possibility to turn this automatic function on and off. But that would mean one more setting in a already cramped settings window, and of course, some cost for its implementation. I assume that the developers decided that it's not worth it.

Regards,

Domas

[cirrob]

As I said before, I am willing to bet your example below, and any example of a project not auto starting being the desired effect is, in fact, a minority.  Your statement about being different than a business project actually supports the argument for making this behavior automatic (in addition to it simply being intuitive), as business projects have many stakeholders and project start status is specifically relevant; personal use, not so much.  With that said (it doesn't matter so much), and the intuitive default would be that a project has started once work on it has begun, the default should be for this expected behavior.  The cramped settings thing is a non-starter since it would only be a relevant setting to a very small group of users, or an even smaller group of situations in which it's counter-intuitiveness would need to be disabled.  

You are arguing for an outlier example for an outlier group of users.  I don't know why this small group of people and use cases is a hill worth dying on when the vast majority would expect and welcome this.  It simply means LESS clicking for the larger group of users.  Why is this not the goal of the organization?

[Stéph]

I agree with cirrob. It seems more intuitive and cuts out a lot of clicks, taps and manual editing if I can automate projects so they start when their tasks begin to be completed and they finish when all their tasks are done - along with automation and inheritance for other parameters. However, there are people who argue for quite different task behaviour to me. I’d certaily like to see _options_ for presetting and scripting some parameter behaviours, to be set to suit the user. Maybe one day…

[robisme (Olivier R)]

Sometime, working on a project starts with adding tasks, not only complete them (when organisation is part of the job). A project can therefore be in progress before any completion.
It can also be in progress but in late, if no task has been completed.

I see one case where a task can be completed but the project has to remain unactive : if this task was usefull for another project, or when you know it is completed even if you don't actually have to work on the entire project yet. (e.g : project "plan summer trip", with a task "renew my passport". Imagine you had a business travel that made you update the passport in march : task is done, but summer trip is still not active).

By the way, I'd prefer to automate the activation of a project by choosing a date ("project to be in progress on june 12")

Olivier

[cirrob]

I appreciate that there are rare, outlier, cases wherein the expected behavior would not be suitable.  However, for the majority of users, the expected behavior would be appreciated as it saves time by automating what should be intuitively automated (the starting of a project when a subtask is completed.  

My argument is that the majority should not suffer because one or two rare use case scenarios don't jive with what is a perfectly logical, acceptable, and intuitive behavior.  

The default should be the behavior I have described, with the option to turn it off for the few people who don't needs that behavior.  At the very least, it should have the option to turn it on (although that would be almost insulting to the majority of the users to have to manually turn it on instead of the minority having to manually turn it off).

I used to think that having it (projects) behave this way (non automated) was a boon.  However, after several years and listening to the opposition argument, I now agree.  Not only should the behavior be optional, it should be defaulted to automate the project process.  It just makes more sense.