Next actions should not inherit tags from their project

Usage Questions
1

next actions should not inherit tags from their project.

Stop it!

A project includes tasks which happen in various contexts. It is obvious and very aggravating that project tags are inherited by their next actions. Please stop this.

Obviously projects need to be dealt with in different context than their children and their children happen in different contexts as well. This is utterly horrible. Oh my head is hurting.

Look

PROJECT MADE A CAKE @kitchen
NEXT decide what type to make @bed
NEXT make list of ingredients @workdesk
NEXT shop for ingredients @store
NEXT get advice for cooking @social-event

almost none of those next actions happen inside the project of making a cake in the context of at kitchen.

And before you tell me to make a next action of making a cake and doubling the project and doubling my work by making a next action for all of my projects. Stop. Stop making more work for yourself. Even if I did make another next action for making the cake in the kitchen, all of the actions in the project have different contexts.

DO not force actions to inherit tags from their project. Stop it. Who let this happen?

2

I personally like actions inheriting tags from the project.

One key difference for me is probably that I differentiate projects vs actions by considering projects as outcomes or goals, while actions are concrete steps that I can DO in order to achieve that outcome. As you note, this can create an extra step of creating a single action that is similar for the final step in the project that might be similar to the project name. This is under 30 seconds and separating what a project is and an action is in this way helps me to clarify the difference between actions and outcomes.

In your example, I might change the project to “Achieve a Tasty Cake”. The final step might now be “Make The Cake @kitchen”. Now when I burn the cake, I still have my outcome listed in the project name reminding me that I’d better take more actions to ensure that I still Achieve a Tasty Cake. Maybe I need to check that the timer is not broken or put a thermometer in the oven to make sure it is working properly. These things can lose clarity if the final step of Make a Cake is taken and completed, but then the outcome is not actually achieved. I see this happen all the time. Granted the cake example is stretched a little thin here, but I think it illustrates my point well enough.

At any rate, I like to be able to group my projects and actions by labels because I can use either AoR or Master Project tags to group things together (mostly for review). Having the actions inherit the projects’ tags allows me to see actions/projects grouped by purpose rather than context. Granted this “violates” GTD in some ways, but it helps me to brainstorm and achieve a feeling of ease that I’m not forgetting anything during reviews.

1 Like
3

@joshuarobison, what is the point of using the @kitchen tag in this case, considering that none of the project actions you listed happen in the @kitchen? As @barton986 said, there should be a final bake action that actually happens in the kitchen.

To be straight, the current behavior hasn’t changed since the day tags were introduced and it is guaranteed to stay this way.

2 Likes
4

  1. Then you are saying contexts should not be put onto projects. Fine, but that agrees with my first point that children should not inherit project tags.

  2. You are suggesting making an extra “finishing task” for each project that will be the name of each project.

PROJ Made a cake
NEXT buy ingredients
NEXT check recipies
NEXT make a cake

that is duplicating my work. I already went over that. I would need to make a next action for every one of my projects that was the name of the project.

Plus. No one ever addressed how children of projects happen in different contexts.

GTD is about contexts. tags are labels but we should stick to contexts.

If you want to remove the ability for projects to have contexts then fine but I say you keep it. Just make one small change.

Remove the senseless spamming the tags that are on the project onto all of its children. Where is the argument for that case?

My projects have different contexts then their children. I almost have zero projects where the project itself is the same context and all of its children are the same.

contexts are not labels.

5

One of the ways I use some projects since they are in another sense containers for a bunch of next actions, is I use them as a kind of next action in themselves to check up on all the actions inside of them.

Some of my projects are their own action in a sense. Otherwise you would need to make a next action for everyone of your projects to check on all its children. Doubling your work.

I am only able to check up on ‘projects’ when I am @home-office or @work-office so I need those contexts to be on the project files themselves. But I do not need to do everything in those projects at home or work office.

6

I just finished setting up my REMINDERS AREA and ROUTINES AREA.

In my ROUTINES I have them setup as projects based on time I need to check on them.

Going on a date with my daughter every two weeks obviously happens in a different context then it’s parent.

Screenshot from 2021-08-18 02-30-57
Screenshot from 2021-08-18 02-30-571020×645 70.7 KB

Don’t make me create a next action for checking everything inside this project and then having to go hunt down the project and look at what’s inside it.

I can check the project itself and checking that project happens in a different context then everything inside it. Everything inside it also has a different context.

Also these items should be sorted by date by default. What in the world is the point of not sorting them by date!?!?!

7

Project is an outcome that I tag with area and other tags. The actions inherit the tags and areas, that’s a huge time saver for me.
I never tag a project with a context.

1 Like
8

What happens when you have next actions that are part of a different area?

The only reason that this is a time saver for you is because everdo does not have batch editing function.

next actions inheriting tags from parents gives a kind of batch editing ability. Trouble is when you move those next actions out of the parent they lose those tags that they had inherited.

What we need is batch editing function.

next actions inheriting project tags is a sorry replacement for that.

9

That won’t happen! If it does, I assign the area to that action. Then it has two assigned areas but who cares.

I sometimes have projects that are related to two or more areas but that is fine two.

I can’t even imagine a project with legit actions from other areas - feels fundamentaly wrong to me.

2 Likes
10

While Everdo doesn’t have full batch editing features, it does allow bulk editing of tags, on desktop. Select multiple actions, right click and select “Edit Tags”. You can add or remove tags.

4 Likes
11

@joshuarobison I do understand the frustration, here. Sometimes it can feel a bit unintuitive.

One thing that I do notice is a difference in how Projects are defined. For example, you have used an Action to title your Project - because of this, it feels duplicative to create a “terminating action”.

However, I think a subtle shift in understanding might help here. A project is not an action, it’s a stake in the ground that reminds you of an end goal, that actions need to be done until that goal is met. Put explicitly, a project should tell you what finished looks like, not what the last action will probably be.

In this instance, my project would not be “Bake a cake” - my project would be “Have a cake”. This leaves flexibility for various solutions (such as simply buying a cake to reach the goal). If there are more constraints, these are listed in the project too - “Have a cake, baked myself” - or “Feel confident in baking a cake on my own” if it’s a learning goal.

This removes the logical need for a context at the project level - after all, as you say, projects are likely to encompass multiple contexts and changing contexts.

For some of your uses of projects, therefore, there’s simply a conceptual collision. As you say yourself, you are using them as a next action or as simple containers. Used as intended as projects, looking at the “Next Actions” list is sufficient to see all relevant and actionable children; this only becomes a problem if they are being used as containers instead of as actual projects.

What’s more, all of these children are being grouped as “next actions”, too. But, they aren’t actually next actions - from your examples, they’re actually scheduled tasks. If you were to schedule them, then seeing all of your pending tasks would be as simple as opening the “Scheduled” list.

All of that said, I do understand your frustration. I can see you’ve built quite a sophisticated personal system that is a little frustrated by some fundamental conceptual differences to the intended use - particularly on what constitutes a project.

It seems to me that you have a desire for some methods of organisation that aren’t really projects, but that the Project feature seems like the closest fit for at the moment. In particular, it seems like you want to be able to only see your various lists and containers (which you have put into projects) in particular contexts. You want to remove the complexity of being able to see those lists at other times, while still being able to see their children if you’re in the appropriate context - is that right?

1 Like
12

Hello from Halifax, Nova Scotia in Canada. I am new to Everdo and so far am impressed. One of the things I like is that tasks inherit tags from the parent project. I hope that stays or at least remains an option.

I have been doing GTD for 12 years and I have never heard of a project being assigned a context. In pure GTD a project cannot be done, so it would, therefore, not have a context. A project is a collection of two or more tasks that achieve a desired outcome.

I do assign Areas of Focus to projects and what I liked is that Everdo tags each task in the project with the appropriate area.

Anyway, fwiw

Peter

13
  1. As long as you make the next actions in the same area as the project, the area tag gets added automatically anyways.
  2. Don’t know what these “other” tags are but does not sound like GTD related.

no one has commented on my display of the obvious problem with actions inheriting project tags

PROJECT MADE A CAKE @kitchen
NEXT decide what type to make @bed
NEXT make list of ingredients @workdesk
NEXT shop for ingredients @store
NEXT get advice for cooking @social-event

Even if you don’t add a context to the project, ALL OF THE ACTIONS have different tags.

If you need the area tag on all of the same actions just create them in that area or like mentioned above use the desktop to do a bulk edit.

  1. There is no way to know which tags are inherited and which are local.
    So when you move an action to another project you have no idea which tags will stick with that action. IT’s a mess.

I have been listing off reason after reason and no one has made an adequate response. All I hear is , "I want tags to inherit from parent because I like that "

Look at all the pain it causes.

14

I have updated my original posts to reflect this. But you guys are getting off track. The biggest reason why it is a mess for next actions to inherit their project’s tags is because every action in a project needs different tags and different contexts.

It sounds like for you guys the TAG IS the project while for me the project is the project. It sounds like you all are keeping your projects together by making a kind of tag that links projects. Yeah, just make the project the project and you will be fine.

You are doubling your work . You are making a project and then making some kind of self named tag for each project. Doubling your work. Not necessary.

And can we just not have actions inherit the tags of their projects, that is insanity. actions all are different and happen in different contexts . No one has given one case scenario yet for why you would want all of the actions in a project to have the same tags… What is that!!!

15

No. They are by GTD definition “the steps necessary to complete the project” next actions.
They are next actions.

16

and

Usually my workflow is like this:

  • Adding to inbox while in All Areas,
  • Processing while in All Areas
  • engaging while using all kind of filters and views depending what context and area I’m currently moving in
  • reviewing per area or some specific tags that are unique for my personal system

I setup my projects with tags so that the tags make sens for my actions.

Sometimes I have a big project that I want to split up in sub projects.

In that case I use tags to group those projects.

I guess the problem is only obvious to you.
If you don’t tag the project with a context, then that part of the problem is gone.

  1. Actions can only be done in certain contexts.
  2. Projects can’t be done - they can be achieved by doing one or more actions

Some are different some are inherited formt the project - so what?

Seems legit to me.

I strongly disagree!

Boy keep calm, neither you or some body else is the ultimate use case owner. Just because it’s insane for you.

If you don’t want to inherit tags - just don’t tag your projects - it’S that easy.

The only thing I agree with, is that it’s hard to see what’s inherited and what’s not.

17

Well, if we get down to GTD definition, they aren’t necessarily next actions. They’re just actions. This can be neatly proven by referring to the text itself - see the following quote.

Any less-than-two-minute actions that you perform, and all other actions that have already been completed, do not, of course, need to be tracked; they’re done. What does need to be tracked is every action that has to happen at a specific time or on a specific day (enter those on your calendar); those that need to be done as soon as they can (add these to your Next Actions lists); and all those that you are waiting for others to do (put these on a Waiting For list).

What you will notice is that actions for a specific time or day are entered on the “calendar”, whilst ones to be one as soon as they can go onto the “Next Actions list”. This logically demonstrates that not everything that is a necessary step will always be on a “Next Action list” from a pure GTD perspective - and in particular, things for specific dates and times explicitly do not go in the Next Actions.

1 Like
18

Which is why inheriting tags from their projects is nutty. Obviously child actions have a variety of contexts unrelated to their parent.

19

that isn’t an answer. My question still has not been answered.

This stands.

20

I deliberately tag projects so the actions that belong to those projects have the same tags. It saves me having to add identical tags to individual actions and I rarely don’t want an action to have the same tag as the project it belongs to. In the rare instance I want the action to have different tags I leave the tag off the project and only put it on the action.

So for me the current behavior saves time and effort and it would make more work for me if the tags weren’t inherited.

3 Likes