Better change handling for recurring pickups?

Karrot
#1

This is a hard topic that I’ve been working on for quite some time in 2017 and started working on again a week ago because of bug reports. I’m currently at a point where it’s hard for me to find out the best behavior, so I’d like your input on this!

Karrot currently tries to fulfill three requirements about pickups:

  1. no unexpected changes for pickup collectors: when anybody is signed up for a pickup, it shouldn’t get deleted or moved to a different time
  2. reliable changes to recurring pickups: when a recurring pickup gets changed, it should affect all existing upcoming pickups that were created as part of this recurring pickup
  3. allow exceptions to recurring pickups: if an individual pickup gets changed or deleted, these changes should be remembered even when the recurring pickup changes

As you might imagine, there’s sometimes a conflict between those requirements. For example, what should happen if someone joined the pickup on Monday, but then the series changes to Tuesday? Or another case: if a pickup Monday 20:00 gets cancelled, but then the recurring pickup changes to Monday 21:00, should the pickup at 21:00 stay cancelled?

When I started writing Karrot, I tried a rather simple way of resolving these conflicts. I didn’t update pickups automatically if they have been changed individually or if people signed up for them. But this lead to unpredictable behavior, such as duplicated pickups or pickups that show old information. After Karolina and Marta from foodsharing Warszawa helped me discover more cases where this simple algorithm turned rogue, I decided to spend some more time to make it better. But it’s been quite hard to find good solutions.

image
image898×910 42.5 KB


Adding and editing recurring pickups is a core functionality in Karrot and should be improved

My current idea is in order to fulfil requirement 2 better, drop requirement 1 and introduce cancelled pickups: pickups that don’t match the changed recurring pickup settings will get cancelled and a notification will get sent to people signed up for it. The notification should ideally contain a statement why the pickup was cancelled.

I would also partially drop requirement 3 and only remember exceptions if they actually match the recurring pickup. So if the rule says “Monday 20:00 every week” and there’s an exception (deleted pickup) for next Monday 20:00, we would remove the exception when the recurring pickup changes date or time, e.g. to “Monday 21:00” or “Tuesday 20:00”.
Also regarding requirement 3: if changes are being made to a pickup and then the recurring pickup changes, we would only keep that pickup if it matches. Otherwise, it will get deleted.

Alternatively, we could just drop requirement 3 and delete all exceptions when a time or day of a recurring pickup changes.

How does that sound to you?
Can you think of more use cases that might cause problems?
Do you have an idea how the behavior could be made simpler?

Pickups, refreshed!
#2

Thanks for your thoughts, @tiltec!

I’m gonna extend your example just to make sure I got your proposal right, okay?

Base scenario
We have a pickup series for Monday 20:00 every week.

Extension 1
For Monday November 26 there is already someone signed up.
Now someone changes the rule for the pickup series to Tuesday 20:00.

For the pickup of November 26 that means that–

  • following the old behavior it would stay unchanged, because somebody already signed up.
  • following the new behavior it would get cancelled and a new pickup would be created for November 27. The person that had signed up already would be notified.

Extension 2
On Monday December 24 there is no pickup, so someone deleted this one pickup date.
Now someone changes the rule for the pickup series to Tuesday 20:00.

For the pickup of December 24 that means that–

  • following the old behavior it would stay unchanged, because it was individually altered.
  • following the new behavior it would still be deleted, but a new pickup would be created for December 25. So the exception would be removed, because it doesn’t match the time of the series.

Extension 3
The pickup of Monday December 3 is moved to Tuesday.
Now someone changes the rule for the pickup series to Tuesday 20:00.

For the pickup of December 3 that means that–

  • following the old behavior it would get duplicated.
  • following the new behavior it would stay an exception, because it matches the new rule.

I’m really unsure if I got this point of yours right:

I would also partially drop requirement 3 and only remember exceptions if they actually match the recurring pickup. So if the rule says “Monday 20:00 every week” and there’s an exception (deleted pickup) for next Monday 20:00, we would remove the exception when the recurring pickup changes date or time, e.g. to “Monday 21:00” or “Tuesday 20:00”.
Also regarding requirement 3: if changes are being made to a pickup and then the recurring pickup changes, we would only keep that pickup if it matches. Otherwise, it will get deleted.

So if you could elaborate on that (maybe using concrete examples!) it would be highly appreciated! :slight_smile:

1 Like
#3

Yes.

The old behavior would not create a pickup on Tuesday, November 27, because it keeps the number of upcoming pickups constant. The algorithm would take every upcoming pickup and try to move it to the new date, but only if nobody is signed up for it.

Yes, a new pickup would be created for Tuesday, December 25. The exception would get removed.

The old behavior for this kind of scenario could lead to duplicated or missing pickups.

The old behavior will not duplicate the pickup in this specific case, because it would treat the existing one on Tuesday 20:00, December 4th as the first one in the series.

The new behavior will be the same, but for different reasons. The pickup moved to Tuesday 20:00, December 4th, matches the new rule and stays. The exception is Monday 20:00, December 3rd. The exception does not match the new rule and will get removed.

Ok, let me use your structure.

Extension 4
The pickup of Monday December 3 is moved to Tuesday.
Now someone changes the rule for the pickup series to Tuesday.
Afterwards, they would change it back to Monday.

For the pickup of December 4th that means that–

  • following the old behavior it will stay on Tuesday, December 4th
  • following the new behavior it will be cancelled and a new pickup gets created on Monday, December 3rd

The exception created on December 3rd will get removed after the first rule change, so the second rule change would only detect that there’s a pickup too much on December 4th and cancel it.

This makes it more predictable when changing a pickup series, because the user doesn’t need to remember all previous modifications.

#4

To sum it up, here’s the new set of rules I’ve been working on implementing in the past days:

  1. changing a recurring pickup always rewrites its existing pickups
    a. if time, weekdays or any other part of the recurrence rule changes, create new pickups where necessary and cancel its non-matching pickups
    b. if the description of the recurring pickup changes, rewrite descriptions of its existing pickups
    c. if max slots of the recurring pickup changes, rewrite max slots of its existing pickups
  2. changing the “weeks in advance” setting of a store rewrites date and time of its recurring pickups
  3. changing the group timezone rewrites date and time of all recurring pickups

I’m not super happy about (2) and (3) because they change much more than necessary, but at least the behavior will be more predictable than now.

2 Likes
#5

Implementation changed quite a bite, here’s the new thread: Pickups, refreshed!

#6