15 ms·

One of the best things about email is that, with the right client, you can view discussions as hierarchical trees. That means you can have multiple simultaneous

One of the best things about email is that, with the right client, you can view discussions as hierarchical trees. That means you can have multiple simultaneous discussions about a topic asynchronously and not lose track of anything. GitHub and the like only work that well when there's maybe one or two things being discussed at once, because there's just a single linear stream of comments.

carussell 9y ago
On the other hand, the unthreaded approach can help keep the discussion focused and tight. There are few things worse than setting out to get some work done and having to wade through a bunch of comments to find the meat. In the age of Bugzilla, if you wanted to discuss something related, you'd open up a new bug. You'd string things together with a tracking (meta) bug if you liked. This Bugzilla-style workflow, however, doesn't accommodate the stuff that you wouldn't feel you should open a bug for. That's a feature. Like so many other things, though, this only works if you enforce it. It's pretty horrifying what the GitHub generation tends to think passes for acceptable on bugtrackers, for example.
- u801e 9y ago
  > On the other hand, the unthreaded approach can help keep the discussion focused and tight. Or that earlier posts get lost because no one actually sees them. With threaded discussion, if one subthread has gone off-topic, you can always collapse or kill that subthread. And your point doesn't always hold true. For example https://github.com/torvalds/linux/pull/17 https://github.com/torvalds/linux/pull/17
  - carussell 9y ago
    > With threaded discussion, if one subthread has gone off-topic, you can always collapse or kill that subthread. This is a social problem. I deliberately added a disclaimer about the tendency for things to turn to crap if you tolerate it. I don't know what this is supposed to mean: > And your point doesn't always hold true. For example https://github.com/torvalds/linux/pull/17 https://github.com/torvalds/linux/pull/17
    - u801e 9y ago
      >> And your point doesn't always hold true. For example https://github.com/torvalds/linux/pull/17 https://github.com/torvalds/linux/pull/17 > I don't know what this is supposed to mean What I linked to is an example of a discussion that didn't stay focused or tight despite the fact that it's not threaded.
      - carussell 9y ago
        This makes no sense. 1. You shouldn't expect that it would "always hold true". I really don't know why you would, because I did not write that it would always hold true. In fact, what I did write is the opposite: a tacit acknowledgement that it's not a hard and fast guarantee. I mean, I specifically made comments like, "Like so many other things, this only works if you enforce it". It's right there. You can go back and read it. Thing is, I even edited my comment (before you read it and responded) from the original; I edited in the words "can help" so that it says "the unthreaded approach can help keep the discussion focused". You want to know something perverse? While doing this, I stopped and asked myself whether I was hedging too much—writing too defensively. Apparently the answer to that is a big nope; I was still not defensive enough. 2. Regardless of everything above, the page you linked to is supposed to prove what? It's a misdirected pull request, and the very first comment is a message to the requestor telling them so. I don't know what you expect past that; even after the message explaining that GitHub is not the correct place to make a pull request and that it will not be moving forward, you seem to be trying to score the discussion against a rubric of how effective the discussion was at staying focused. Do you not see what's wrong with that? 3. I made an a priori remark about how lousy the GitHub community is in my very first comment. I mean, my exact words were calling out what's found on GitHub as "pretty horrifying". If there's some way to be clearer regarding how I feel about GitHub, I don't know what it is. GitHub is terrible. And yet, despite this, despite everything above, your choice example is to link to a GitHub thread where this exact thing is on display, in an attempt to prove me wrong. Or something. I don't get it. This'll be my last comment here. I think I'm gonna go away for a while.
        u801e 9y ago
pmoriarty 9y ago
This is one of the things that web-based forums have yet to get right. Email (and NNTP news) clients from 20 or 30 years ago are far superior in this respect, because they can intelligently deal with threading and folding. These features alone makes large conversations much easier to deal with than on web-forums. To add to that, email (and NNTP news) clients even from 20 or 30 years ago have other powerful features that web forums have yet to catch up on: - kill files[1] (which you can use to filter out unwanted articles/mails based on content or metadata such as subject, user, etc) - scoring - user-configurable anti-spam filtering or other "intelligent" filtering (such as bayesian filtering not just for spam/ham, but for interesting/unintersting content) - tagging not just on a site-wide level but at the client level so each user can tag messages/articles the way they make sense to them - other advanced filtering and scripting based on any of the above Web-based forums are just incredibly primitive compared to this many-decade-old technology. [1] - https://wikivisually.com/wiki/Kill_file https://wikivisually.com/wiki/Kill_file
- SubiculumCode 9y ago
  Can we do that with a chat system? Because Slack threading is just inadequate, imo.
  - alex-e 9y ago
    I'm trying to solve this right now with eul[0]. It's not an easy task. [0]: https://eul.im https://eul.im
    - mrmondo 9y ago
      Looking forward to OTR for XMPP :)
- nextos 9y ago
  Exactly. Gnus is a marvelous client because it has really good NNTP and threading support (silencing and automatic scoring) that allows you to cope with gigantic volumes of email. It's a bit sad the code is messy and it's a tad slow compared to other options. Notmuch for Emacs has so much potential to replace Gnus. The interface is incredibly fast and friendly (a classic tree view and a threaded view that IMHO surpasses Gmail). Plus super quick search. I think it could become a killer application for Emacs (the other two now are org-mode and Magit IMHO). However, there's no good tooling to keep Notmuch in two-way sync with maildirs right now. Everything works based on tags, which is incredibly flexible, but there should be some tooling to implement logic that allows moving mails around based on their tags, so that the remote IMAP store gets tidy. People usually rely on scripts for simple use cases, which is fine albeit a bit hacky. Some DSL that resembles Sieve, but implemented in ELisp would be cool.
leeoniya 9y ago
i'm implementing a webmail app as we speak (from the bottom up). my immediate thought was "wtf are 'conversations', gmail? of course i want threads!". then i started actually handling the raw email messages. i got threads working pretty well but noticed frequent rendering issues and digging into the cause. my conclusion is, email threading is mostly a pipe dream; it can only be done properly if you have a view of the entire conversation (as is the case with centralized forums/message stores like HN). the 'References:' header only represents the message ids of any particular branch up to the root. if you try turning a number of messages with the same root into proper threads, you quickly discover missing branches, partial branches/holes, missing leaf nodes, etc. If your knowledge of a thread starts with a message forwarded to you, no thread is possible (even though one clearly exists as indicated by the References chain in the header!). side-conversations that happen (selective replies, cc/bcc), additional fwd/reply chains are all invisible to you. sadly, an incomplete thread view is an extremely common thing (at least in my inbox/sent of ~15k messages). the client can only thread the actual raw messages it has; those simply quoted in any replies or forwards (which established the Reference chains) don't count. the only commonality you have is knowing the root message id and the timestamp for ORDER BY. everything in between, you may or may not have to reconstruct a partial view of the thread...and each user will have a different view of that thread based on which parts they've been party to. the threading that i did get working was nice, but not as useful as a bulletproof solution would have been. unfortunately, i don't believe that's possible with email. i now understand why gmail does flat convos.
- ori_b 9y ago
  > my conclusion is, email threading is mostly a pipe dream Them why has it been working so well for me since I started using email? Maybe take a look at this for inspiration: https://fkref.com/?RbC_-NEE https://fkref.com/?RbC_-NEE
  - leeoniya 9y ago
    thats basically what i did. the problem is with this step: 4. Prune empty containers. you can prune/flatten these containers but then the deeper messages that you do have are not direct replies to their ancestors in the flattened/pruned version of the tree. i didnt say that threading did not work. it does. but it is imperfect at best and can be misleading at worst. in my case i was constructing an MPTT structure (Nested Set) for optimal thread fetching and simply leaving in the dummy message placeholders that i didnt have a copy of. i plan to experiment further, but there arent really any earth-shaking revelations in that post. it's all fairly obvious.
lloeki 9y ago
GitLab has discussions, which thread topics within an issue/MR/commit. In the context of a MR, individual messages or whole threads can be marked as resolved. This is an invaluable tool to get out of linear quote hell.

carussell 9y ago

On the other hand, the unthreaded approach can help keep the discussion focused and tight. There are few things worse than setting out to get some work done and having to wade through a bunch of comments to find the meat. In the age of Bugzilla, if you wanted to discuss something related, you'd open up a new bug. You'd string things together with a tracking (meta) bug if you liked. This Bugzilla-style workflow, however, doesn't accommodate the stuff that you wouldn't feel you should open a bug for. That's a feature. Like so many other things, though, this only works if you enforce it. It's pretty horrifying what the GitHub generation tends to think passes for acceptable on bugtrackers, for example.

u801e 9y ago
> On the other hand, the unthreaded approach can help keep the discussion focused and tight. Or that earlier posts get lost because no one actually sees them. With threaded discussion, if one subthread has gone off-topic, you can always collapse or kill that subthread. And your point doesn't always hold true. For example https://github.com/torvalds/linux/pull/17 https://github.com/torvalds/linux/pull/17
- carussell 9y ago
  > With threaded discussion, if one subthread has gone off-topic, you can always collapse or kill that subthread. This is a social problem. I deliberately added a disclaimer about the tendency for things to turn to crap if you tolerate it. I don't know what this is supposed to mean: > And your point doesn't always hold true. For example https://github.com/torvalds/linux/pull/17 https://github.com/torvalds/linux/pull/17
  - u801e 9y ago
    >> And your point doesn't always hold true. For example https://github.com/torvalds/linux/pull/17 https://github.com/torvalds/linux/pull/17 > I don't know what this is supposed to mean What I linked to is an example of a discussion that didn't stay focused or tight despite the fact that it's not threaded.
    - carussell 9y ago
      This makes no sense. 1. You shouldn't expect that it would "always hold true". I really don't know why you would, because I did not write that it would always hold true. In fact, what I did write is the opposite: a tacit acknowledgement that it's not a hard and fast guarantee. I mean, I specifically made comments like, "Like so many other things, this only works if you enforce it". It's right there. You can go back and read it. Thing is, I even edited my comment (before you read it and responded) from the original; I edited in the words "can help" so that it says "the unthreaded approach can help keep the discussion focused". You want to know something perverse? While doing this, I stopped and asked myself whether I was hedging too much—writing too defensively. Apparently the answer to that is a big nope; I was still not defensive enough. 2. Regardless of everything above, the page you linked to is supposed to prove what? It's a misdirected pull request, and the very first comment is a message to the requestor telling them so. I don't know what you expect past that; even after the message explaining that GitHub is not the correct place to make a pull request and that it will not be moving forward, you seem to be trying to score the discussion against a rubric of how effective the discussion was at staying focused. Do you not see what's wrong with that? 3. I made an a priori remark about how lousy the GitHub community is in my very first comment. I mean, my exact words were calling out what's found on GitHub as "pretty horrifying". If there's some way to be clearer regarding how I feel about GitHub, I don't know what it is. GitHub is terrible. And yet, despite this, despite everything above, your choice example is to link to a GitHub thread where this exact thing is on display, in an attempt to prove me wrong. Or something. I don't get it. This'll be my last comment here. I think I'm gonna go away for a while.
      - u801e 9y ago

pmoriarty 9y ago

This is one of the things that web-based forums have yet to get right. Email (and NNTP news) clients from 20 or 30 years ago are far superior in this respect, because they can intelligently deal with threading and folding. These features alone makes large conversations much easier to deal with than on web-forums. To add to that, email (and NNTP news) clients even from 20 or 30 years ago have other powerful features that web forums have yet to catch up on: - kill files[1] (which you can use to filter out unwanted articles/mails based on content or metadata such as subject, user, etc) - scoring - user-configurable anti-spam filtering or other "intelligent" filtering (such as bayesian filtering not just for spam/ham, but for interesting/unintersting content) - tagging not just on a site-wide level but at the client level so each user can tag messages/articles the way they make sense to them - other advanced filtering and scripting based on any of the above Web-based forums are just incredibly primitive compared to this many-decade-old technology. [1] - https://wikivisually.com/wiki/Kill_file https://wikivisually.com/wiki/Kill_file

SubiculumCode 9y ago
Can we do that with a chat system? Because Slack threading is just inadequate, imo.
- alex-e 9y ago
  I'm trying to solve this right now with eul[0]. It's not an easy task. [0]: https://eul.im https://eul.im
  - mrmondo 9y ago
    Looking forward to OTR for XMPP :)
nextos 9y ago
Exactly. Gnus is a marvelous client because it has really good NNTP and threading support (silencing and automatic scoring) that allows you to cope with gigantic volumes of email. It's a bit sad the code is messy and it's a tad slow compared to other options. Notmuch for Emacs has so much potential to replace Gnus. The interface is incredibly fast and friendly (a classic tree view and a threaded view that IMHO surpasses Gmail). Plus super quick search. I think it could become a killer application for Emacs (the other two now are org-mode and Magit IMHO). However, there's no good tooling to keep Notmuch in two-way sync with maildirs right now. Everything works based on tags, which is incredibly flexible, but there should be some tooling to implement logic that allows moving mails around based on their tags, so that the remote IMAP store gets tidy. People usually rely on scripts for simple use cases, which is fine albeit a bit hacky. Some DSL that resembles Sieve, but implemented in ELisp would be cool.

leeoniya 9y ago

i'm implementing a webmail app as we speak (from the bottom up). my immediate thought was "wtf are 'conversations', gmail? of course i want threads!". then i started actually handling the raw email messages. i got threads working pretty well but noticed frequent rendering issues and digging into the cause. my conclusion is, email threading is mostly a pipe dream; it can only be done properly if you have a view of the entire conversation (as is the case with centralized forums/message stores like HN). the 'References:' header only represents the message ids of any particular branch up to the root. if you try turning a number of messages with the same root into proper threads, you quickly discover missing branches, partial branches/holes, missing leaf nodes, etc. If your knowledge of a thread starts with a message forwarded to you, no thread is possible (even though one clearly exists as indicated by the References chain in the header!). side-conversations that happen (selective replies, cc/bcc), additional fwd/reply chains are all invisible to you. sadly, an incomplete thread view is an extremely common thing (at least in my inbox/sent of ~15k messages). the client can only thread the actual raw messages it has; those simply quoted in any replies or forwards (which established the Reference chains) don't count. the only commonality you have is knowing the root message id and the timestamp for ORDER BY. everything in between, you may or may not have to reconstruct a partial view of the thread...and each user will have a different view of that thread based on which parts they've been party to. the threading that i did get working was nice, but not as useful as a bulletproof solution would have been. unfortunately, i don't believe that's possible with email. i now understand why gmail does flat convos.

ori_b 9y ago
> my conclusion is, email threading is mostly a pipe dream Them why has it been working so well for me since I started using email? Maybe take a look at this for inspiration: https://fkref.com/?RbC_-NEE https://fkref.com/?RbC_-NEE
- leeoniya 9y ago
  thats basically what i did. the problem is with this step: 4. Prune empty containers. you can prune/flatten these containers but then the deeper messages that you do have are not direct replies to their ancestors in the flattened/pruned version of the tree. i didnt say that threading did not work. it does. but it is imperfect at best and can be misleading at worst. in my case i was constructing an MPTT structure (Nested Set) for optimal thread fetching and simply leaving in the dummy message placeholders that i didnt have a copy of. i plan to experiment further, but there arent really any earth-shaking revelations in that post. it's all fairly obvious.

lloeki 9y ago

GitLab has discussions, which thread topics within an issue/MR/commit. In the context of a MR, individual messages or whole threads can be marked as resolved. This is an invaluable tool to get out of linear quote hell.