Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Snooze" (reply-later) feature for any message: Hide this email for x hours/days/weeks/months #572

Closed
marclaporte opened this issue Jun 19, 2022 · 5 comments · Fixed by #659

Comments

@marclaporte
Copy link
Member

marclaporte commented Jun 19, 2022

Like many (most?) people, my email inboxes and other email folders often contain todos and reminders. When I am completely finished with an email, I will delete it (If I am sure I will never need it again) or I archive it (out of my view but still findable): cypht-org/cypht-website#24

Cypht nicely permits to combine views, so this accentuates the challenge of quite a few emails with diverging levels of urgency.

While inbox zero is elusive, I regularly review emails from most recent to oldest. This "last in, first out aka LIFO method" is debatable logic as older emails can be more important, and they have been waiting longer. However, newer emails sometimes make older emails no longer important, so it makes sense to start with latest information. And threading will help. And I refuse to declare email bankruptcy.

Better filters being a way to deal with information overload, let's not analyze the same email again and again (without anything immediately actionable). Examples:

  • I am in CC and someone else is supposed to answer. I want to make sure they don't forget because this is important.
  • Someone replied to me with a quick confirmation of receipt, and it will take a few days/weeks/months before I can expect a follow-up on this topic
  • An important but not urgent email, and I want to make sure it's not lost
  • A confirmation of an appointment/online event far away in the future. Ex.: with information on how to access the webinar
  • etc.

In cases like this, I would like to snooze the email with choices like 1 day, 1 week, 1 month, pick a date. The snoozed emails should all be findable in a "snoozed" folder (or similar name), with a column for the snoozed-until date. Here, you can un-snooze them (it becomes a normal email), or change the snooze date. At the end of the snooze period, the email should appear in a dedicated section above all other emails. Then, you deal with them, or snooze them again.

It should be possible to "snooze" emails in any folder (sent, draft, etc.). If you send an important email, you can then add yourself a reminder to check up on it in one month (for example).

Why not use the flag tag? The flag tag is indeed useful, but then, you can end up evaluating an email again and again. We really need to hide the email until a specific date for that email.

Alternate names for this feature:

  • Snooze
  • Defer
  • Postpone
  • Delay
  • Reminder
  • ?

Related implementations / feature requests:

This feature request is one of many enhancements on the way via the collaboration with the Tiki project

I look forward to your thoughts to improve the plan before we start coding this.

Thanks!

@dumblob
Copy link
Member

dumblob commented Jun 19, 2022

So basically a transactional e-mail redelivery after a chosen period.

Yep, I also find this feature useful (though in my case I immediately put it to calendar manually and keep 99% of all emails I receive).

@nekohayo
Copy link

nekohayo commented Jul 16, 2022

In case this is relevant: https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-snooze-04

@marclaporte
Copy link
Member Author

This is a popular feature request: roundcube/roundcubemail#6603

@marclaporte
Copy link
Member Author

To be part of the JMAP spec: jmapio/jmap#301

@marclaporte
Copy link
Member Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants