You can also use a separate email address for each different communication, like I do. In addition to avoiding much of the spam, you can also use this capability to search messages.
"2. Email is a poor aggregator of context ... When you receive two separate notifications related to one piece of your work ..., your inbox has no awareness that those notifications are linked to a common item."
It would be possible to do in a few ways: One is to include the pull request ID in the subject line or in a custom header. Another way is to assign a message ID to the piece of your work, in order that you can use it to reply. Using the message ID in this way is perhaps easier and would work better if a NNTP interface is used to provide the context and changes and the ability to reply to it, although it would work with email too.
"3. The inbox was not designed to manage tasks"
This section says the inboxes do not support some things, although it would be possible for the email client software to include some of these features. (That is also true of some of the other features mentioned below.)
1. Yes, it is possible to create a separate email address for all of your different purposes (work, personal, etc). However, for the average user that is not a very efficient workflow or desirable end result.
2. Yes, as you're describing there are various hypothetical ways to link an email with a pull request or vice versa. But how do you propose the average user implement this? At the end of the day, they'd end up building a subset of the underlying functionality that Monolist provides.
3. Yes, it is "possible" for email clients to support additional features, and many of them do. However, we believe email requires a fundamental rethinking to be valuable again in the workplace.
6 comments
[ 3.1 ms ] story [ 26.4 ms ] threadThat's what I want from it
You can also use a separate email address for each different communication, like I do. In addition to avoiding much of the spam, you can also use this capability to search messages.
"2. Email is a poor aggregator of context ... When you receive two separate notifications related to one piece of your work ..., your inbox has no awareness that those notifications are linked to a common item."
It would be possible to do in a few ways: One is to include the pull request ID in the subject line or in a custom header. Another way is to assign a message ID to the piece of your work, in order that you can use it to reply. Using the message ID in this way is perhaps easier and would work better if a NNTP interface is used to provide the context and changes and the ability to reply to it, although it would work with email too.
"3. The inbox was not designed to manage tasks"
This section says the inboxes do not support some things, although it would be possible for the email client software to include some of these features. (That is also true of some of the other features mentioned below.)
2. Yes, as you're describing there are various hypothetical ways to link an email with a pull request or vice versa. But how do you propose the average user implement this? At the end of the day, they'd end up building a subset of the underlying functionality that Monolist provides.
3. Yes, it is "possible" for email clients to support additional features, and many of them do. However, we believe email requires a fundamental rethinking to be valuable again in the workplace.