MLOBETA-58 FR: customisable behaviour of project status and waterfall propagation if inactive

[kitus]

Triggered by the moderator of this feature request in Jira, I need to reach some sort of consensus if I want the moderator to let this request make it to the next phase, which, btw, does not assure it may be ever implemented...

Two requests that are very related to one another.

First: There has been discussion in the past about whether or not current behaviour of MLO makes sense when it comes to allowing suspended projects to hold active actions. My opinion is that generally speaking I would say NO, but I accept that in specific cases you may want to start doing something towards project completion despite you may want to consider that specific project as suspended or not started. But, again, generally speaking my opinion is NO, and thus I would suggest either a check-box on the task options pane or a general setting in the menu. Please, allow MLO to adapt itself to user needs with regard to this.

Second: I would like to also get your attention to something related. Context inheriting is a feature that I use a lot. I have placeholders for calls, agnedas, etc., and when I drop a an item into that placeholder, I like to know that I inherits all the attributes from the parten. I have a placeholder for projects on-hold. I'm currently looking into how I can manage projects and I feel it would be beneficial to be able to configure MLO's behaviour in that project status propagated the changes to the elements that are created within the branch.

I'm not saying, however, that when a project is toggled from suspended to in progress, every sub-project hanging in that particular branch toggles its status to in progress. This would only apply to projects marked as Suspended or Not Started, and I would be happy if, at least, I could configure MLO so that those actions do not appear on the to-do view.

[Stéph]

Thanks for bringing this up, Kitus,

First: I agree with you - I don't want suspended project actions to appear in the list - perhaps by automatically selecting 'Hide Branch' when a project is suspended or completed. Any preparatory actions could always be put in a branch separate from the project itself.

Second: I don't use context inheritance, so would like to be able to stop it from happening on new tasks.

Stéphane

[David Jade]

I whole-heatedly agree with the first section: suspended projects should not show up as available actions in any view (unless you want them too by some MLO settings switch or property of the view). On the desktop I've used advanced filtering for a long while now to make it work like this, replacing all the built-in views with that additional tweak. This is also the main issue as to why I cannot use the iOS versions as my ToDo list becomes flooded with suspended or not started project items.

As for the second section, I too use context inheritance and could also see having a place for suspended projects to get them out of the way. Having the suspended status inherit would make a lot of sense here too.

David

[kitus]

Stéph, David, help me get people's attention. If we get enough consensus, the MLO team might consider this feature request.

[Stéph]

The daily digests from the forum should get people's attentions, kitus.  Task parameter inheritance (either from parent tasks or from projects) is pretty limited at the moment, forcing me to do more manual editing than I'd like, so here's hoping that Andrey will look into adopting more of the inheritance features in Bonsai.

Stéphane

[robisme (Olivier R)]

I would like the tasks belonging to an inactive project are inactive.

And I'd really like to be able to set a date at which a project becomes active.

Olivier

[kitus]

The more I use MLO, the more I think this feature is needed. The silence is deafening.

[kitus]

Andrey, would you care to comment on this request please? I don't think what's been requested here poses such a big change on your product, does it?

[JensFF]

I'm also missing this feature since the beginning.

I also prefer to inherit prject status like it's done with start/end date. As long as I don't change it for a single task it's always like the top level project. So it's not only suspending a project. If I set a top level project to completed all sub projects (and tasks) shall be completed to.

Additional I#d like to change the project status via context menu directly in the view.

Jens

[Marc García Martí]

I wouldn't be that categorical. In order not to impact too much on other users, I think that MLO could introduce this behaviour by adding a setting/user preference. 

--
You received this message because you are subscribed to a topic in the Google Groups "MyLifeOrganized" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mylifeorganized/-txNDi4uKXc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mylifeorganiz...@googlegroups.com.
To post to this group, send email to mylifeo...@googlegroups.com.
Visit this group at http://groups.google.com/group/mylifeorganized.
To view this discussion on the web visit https://groups.google.com/d/msgid/mylifeorganized/6065f09d-96f3-40cb-90a9-81330efcbe00%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Dwight Arthur]

I'm okay with much of what's requested here. I even, to my surprise, find that when a project gets suspended, I'm okay with all its subtasks becoming inactive. Just one thing concerns me. Sometimes there are tasks in a project that have to be completed before the date of the project kickoff, such as pre-ordering supplies. So I would not want to see all subtasks of a not-started project forced to become inactive.One more thing: I agree that a change in behaviour like this should be enabled only when the user opts in (or doesn't opt out).

 

[Stéph]

Hello Dwight. I'd deal with that in one of three ways:
1) have the early / prep works as part of the project and accept that the project has effectively started once you start carrying out those activities;
2) set up a separate project (called "… enabling works") for those early tasks;
3) set up sub-projects and mark them as not started / in progress / suspended, whilst the overall project remains in progress from as soon as the early work starts.

That's the way we tend to do it when setting up our project programmes in our business. The idea of having a project which is not started or which is suspended but which has tasks I've got to do just doesn't sound quite right to me.

Stéphane

[Dwight Arthur]

Hi, Stéph, and thanks for your response.

I think that the major issue is that it seems wrong to you to have project related tasks prior to the project start; to me, it's not only acceptable but necessary. I guess it's the diffetence between the way my business and yours work. MLO should not make eithet of us convett to the other's way of doing business.  Here's a different example.

I'm bidding on a contract that requires delivery of a draft in three weeks,  a proof in fove weeks and the finished product in six. To me this is a six week project from start date to due date with some subtasks pegged to intervening due dates. It's importart to me that project start date be the date on which I start tge project. It will take me two days to prepare and deliver my proposal and bid. The proposal and bid process is an integral part of the project which takes place before the project start date.

I cannot see any way to make your option one work for me.

Options two and three are the same to me. Each one involves an actual project as well as a pseudo-project called "bid for project". I could do that but it seems unnecessarily complex and not at all helpful.
-Dwight
Mlo betazoid on Android sgn2

[Stéph]

Fair enough. I do keep my bids separate from the projects (Quite a few of them are unsuccessful and never even become projects). I can see why you might want to keep a tighter link. Personally, if I managed it that way, I'd want to show the project as in progress while I worked on the bid and then I'd suspend it until I actually won the work from the client.

Flexibility is the principle with MLO, which is one of the things that distinguishes it from Omnifocus. I agree that it would be best for Andrey to make any of this automation optional, so he doesn't enforce a particular workflow on the users. Just like with the options for inheritance for new items, which I was proposing in another thread and Jira MLOBETA-108.

Stéphane

[Dwight Arthur]

D'accord
We are in agreement

--
You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mylifeorganiz...@googlegroups.com.

To post to this group, send email to mylifeo...@googlegroups.com.
Visit this group at http://groups.google.com/group/mylifeorganized.

To view this discussion on the web visit https://groups.google.com/d/msgid/mylifeorganized/38d47565-a7b3-4c45-ae58-8443a64656e7%40googlegroups.com.

[robisme (Olivier R)]

No news about this requested behavior?
Olivier