Notes (and all other properties) are shared between 'every' repeating tasks. So, if you change the priority of an 'every' repeating task, all other instances of that task will change too. Notes are shared between all instances.

However, notes and other properties for 'after' tasks are not shared. This is because 'after' tasks are considered to be new tasks -- they copy across the properties from the previous repeating task, but if you change a property (e.g. priority) then it will change for that task only.

Hope this clears things up -- please let me know if you have any questions.

Ah, I see. Is it like this because of a programming issue, or for some other reason?

It's how we decided that it should behave -- but we're open to feedback on this :)

The reasoning went that 'every' tasks are identical tasks that repeat at a particular interval. So, if you have a task for a meeting that repeats 'every week', it always has the same priority etc and so the properties are shared (including notes).

In contrast, 'after' tasks only repeat after you complete them, and the new task isn't necessarily tied to the last one. So, you might have something like 'clean fridge' that you want to perform again 'after 3 months', or 'call parents' that you might need to do 'after 2 weeks'. However, you might want to give the new task a different priority or time estimate, without altering the old tasks.

Basically, 'after' repeats generate new tasks, while 'every' repeats contain a bunch of tasks as part of a series. If you want to have a series of tasks, you should use 'every'.

Well, here's how I was using it in this particular case. There was a company that I was having difficulties with regarding an order, so I made a repeating task to harrass them about it every week.

If I was scheduled to make the call on, say, Monday, but didn't get to it until Thursday, then I wanted the next occurrence to be a week from Thursday, the date that I actually completed the task.

In the notes, I was keeping track of who I talked to each time, result of the call, phone numbers I needed to use, etc. Er, I was going to, anyway, until I saw that it wasn't going to work that way.

I don't know about anyone else, but I use "after" pretty exclusively for recurring tasks. I can't always get to things when I think I will, and then I don't want a bunch of recurrences piling up. It only makes me feel like things are spiraling out of control! :)

So for me, it would be most useful to have all of the properties shared by default, and then if there's an exception, I can change it manually.

Ah, I see what you mean. In this case, it's kind of a cross between 'every' and 'after' -- you need to have a series that has its due date determined by the last time the task was completed.

The only way to do this now would be to make your repeating tasks 'every', and then postpone them to the appropriate date (e.g. if you completed the task on Monday, you could move the due date of the next one to be the next Thursday, and then it would be set to repeat every week from that date). We'll have to think if there's any way this could be done automatically.

The other issue is that Outlook works the same way ('after' tasks are just generated tasks with no sharing) -- so we'd have to consider whether doing things differently could cause problems for later synchronization with other software.

Emily, thanks for the information on "every" versus "after" and the reference to Argotnauts similar concerns.

I'm a power user of Outlook and have been for many years. What Outlook actually does for a recurrance is copy all the current attributes -- including the notes -- from the completed task to the new task. It does not share the information between these tasks, rather it stores each instance seperately. The net effect of this is a paper trail showing the changes from one instance to the next.

This feature exists so that decision makers (lawyers, project managers, sales people, etc) can identify what actions were taken when. In other words, it's an audit trail or a crude form of personal workflow. For many years, my business depended on it -- old habits die hard.

So, we know that the current priority, time estimate and tags are already copied from the old task to the new one in an 'after' recurrence. Why not the notes? Aren't they just another property? Shouldn't the user be the one to decide if that information is relevant to the next instance?

This would be the simplest solution to Argotnaut's problem, and it would comply more faithfully with the Outlook standard.

I'm not an Outlook user, but I intuitively expected "repeat" to include all of the attributes associated with the task, including the notes. It still seems strange to me that they would just get thrown out, and I have to say that I dislike the way that this works.

I think this is a little confusing because the 'notes' for a task in Outlook are actually just a single description field. You cannot have multiple descriptions for a task.

The notes in Remember The Milk are more like the separate Notes feature in Outlook -- they contain the note content and the modification date for each note. Notes are not properties of tasks -- they are separate entities that are then linked to tasks. You can have an unlimited number of notes linked to a task.

So, if we were to copy the notes when 'after' tasks were regenerated, we'd be creating an entire duplicate set of notes each time (keeping in mind that that might be okay if you just have one note, but might not be what you want if you have 20 notes).

Anyway, this definitely something we can look into further in the future if people would like to have the ability to duplicate notes like this. We appreciate the feedback on this!