Subject: [calsify] Requesting feedback on recurring JSTask/VTODO

From: Robert Stepanek <[email-masked]>
Date: Tue, 22 May 2018 13:12:40 +0200

Following up our recent discussions around evaluation of recurrence
rules, I am in the process of updating the JSCalendar draft.
One of the areas that hasn't received attention, yet, are the specifics
of JSTask and their recurrence rules. I would very much appreciate more
feedback on this from people with more practical experience in task-
oriented workflows. Specifically:
*Task due vs start*
The current JSCalendar RFC draft defines a JSTask to recur by its start
property, if defined. This is in line with the iCalendar RRULE
definition.
As an addition, JSCalendar defines the recurrenceRule to apply to the
due date, if no start is specified. Is this a reasonable suggestion?
What is more important for tasks, the start or the due date, e.g. should
due take precedence over start in RRULE evaluation? Or should it be
possible to define which property to recur by?
*Tasks without due and start*
The iCalendar spec defines a VTODO without a start or due date to
"specify a to-do that will be associated with each successive calendar
date, until it is completed."
During discussion of JSTask a year ago in Seattle, we had envisioned
tasks without start or due date to exist without any specific anchor to
a time-line. I am not sure if that's also what is meant in the iCalendar
spec. Does anyone know better? Also: it looks reasonable to explicitly
forbid recurrence rules for JSTasks without due or start time. Are there
any objections to that?
Cheers,
Robert

---

From: Michael Douglass <[email-masked]>
Date: Tue, 22 May 2018 12:23:23 -0400

On 5/22/18 07:12, Robert Stepanek wrote:
> One of the areas that hasn't received attention, yet, are the 
> specifics of JSTask and their recurrence rules. I would very much 
> appreciate more feedback on this from people with more practical 
> experience in task-oriented workflows. Specifically:
>
> *Task due vs start*
> The current JSCalendar RFC draft defines a JSTask to recur by its 
> start property, if defined. This is in line with the iCalendar RRULE 
> definition.
>
> What is more important for tasks, the start or the due date, e.g. 
> should due take precedence over start in RRULE evaluation? Or should 
> it be possible to define which property to recur by?
> tasks without start or due date to exist without any specific anchor 
> to a time-line. I am not sure if that's also what is meant in the 
> iCalendar spec. Does anyone know better?
I believe that's correct - a task without any start or due floats along 
as time progresses. I think I imlemented them as always being the 
current date which may not be totally correct
> Also: it looks reasonable to explicitly forbid recurrence rules for 
> JSTasks without due or start time. Are there any objections to that?
I think it's fairly simple and the rules as defined mostly work. We 
don't need to worry about precedence. Any generated instance must have 
the same time difference between start and end. It's up to the consumer 
to decide whether the start (assignment) is more or less important than 
the due date.

I think the rules are:
if there's a start use that.
otherwise if there's a due use that
otherwise no recurrence is possible or allowed.

>
>
> Cheers,
> Robert
>
>
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Adrian Apthorp <[email-masked]>
Date: Wed, 23 May 2018 20:29:57 +0800

> On 23 May 2018, at 12:23 AM, Michael Douglass <[email-masked]> wrote:
> 
>> Following up our recent discussions around evaluation of recurrence rules, I am in the process of updating the JSCalendar draft.
>> 
>> One of the areas that hasn't received attention, yet, are the specifics of JSTask and their recurrence rules. I would very much appreciate more feedback on this from people with more practical experience in task-oriented workflows. Specifically:

There was some discussion on this in TCTASK. You may find some details if you have access to the group archives. However, generally we opted to keep this simple, for the very reason that if we weren’t careful we’d end up defining a workflow language and there’s enough of those around. This is particularly true if you try and define recurring related tasks with no time anchor.

>> 
>> Task due vs start
>> The current JSCalendar RFC draft defines a JSTask to recur by its start property, if defined. This is in line with the iCalendar RRULE definition.
>> 
>> As an addition, JSCalendar defines the recurrenceRule to apply to the due date, if no start is specified. Is this a reasonable suggestion? What is more important for tasks, the start or the due date, e.g. should due take precedence over start in RRULE evaluation? Or should it be possible to define which property to recur by?
> Tasks without due and start
>> 
>> The iCalendar spec defines a VTODO without a start or due date to "specify a to-do that will be associated with each successive calendar date, until it is completed." 
>> 
>> During discussion of JSTask a year ago in Seattle, we had envisioned tasks without start or due date to exist without any specific anchor to a time-line. I am not sure if that's also what is meant in the iCalendar spec. Does anyone know better?
> I believe that's correct - a task without any start or due floats along as time progresses. I think I imlemented them as always being the current date which may not be totally correct

Yep. It just sits on a task list.

>> Also: it looks reasonable to explicitly forbid recurrence rules for JSTasks without due or start time. Are there any objections to that?
> I think it's fairly simple and the rules as defined mostly work. We don't need to worry about precedence. Any generated instance must have the same time difference between start and end. It's up to the consumer to decide whether the start (assignment) is more or less important than the due date.
> 
> I think the rules are:

This sounds right to me.