From: cworth@cworth.org (Carl Worth)
Subject: [sup-talk] On making kill-thread easier
Date: Thu, 20 Aug 2009 18:36:28 -0700 [thread overview]
Message-ID: <1250817987-sup-7256@yoom.home.cworth.org> (raw)
In-Reply-To: <1250800965-sup-4218@ntdws12.chass.utoronto.ca>
Excerpts from Ben Walton's message of Thu Aug 20 13:43:08 -0700 2009:
> Excerpts from Chris Wilson's message of Thu Aug 20 16:01:10 -0400 2009:
>
> > I'd be happy to have sup automatically kill a thread that I have
> > archived twice without reading.
>
> I think this kind of heuristic is a) hard to get right b) not required
> if you do batch operations as described above. Part b) is subject to
> personal opinion, of course! :)
[Here's one last thought from me in this thread before I come back
next time with actual code and maybe some experience in using it.]
Since, by nature of being a heuristic, this kind of thing can't be
perfect, and since the cost of a false positive is high, (an important
message being killed and never seen), here's another idea:
First, leave killing to the user as an explicit action.
Second, use the heuristics not for killing messages, but merely for
prioritizing them in the inbox. But since the inbox might often be
small, it's not adequate to move the "uninteresting" messages to the
bottom. Instead threads that the heuristic identifies as "likely
uninteresting" could have a delay attached to them before they are
presented again in the inbox, (not too unlike throttling proposed for
mailing-list servers to keep flamewars in check).
This way instead of pestering the user with the bikeshedding until the
user finally kills the thread in frustration, the bikeshedding could
get delayed until the next morning's sweep where a day's worth of
bikeshedding would be easy to identify and easy to kill.
So maybe something like "Once I archive a thread twice without
reading, don't show it to me again until tomorrow" or so. That might
be interesting to try out.
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090820/aefb8350/attachment.bin>
next prev parent reply other threads:[~2009-08-21 1:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-20 17:07 Carl Worth
2009-08-20 18:19 ` Andrei Thorp
2009-08-20 20:01 ` Chris Wilson
2009-08-20 20:36 ` Andrei Thorp
2009-08-20 21:07 ` Carl Worth
2009-08-20 20:43 ` Ben Walton
2009-08-20 21:11 ` Carl Worth
2009-08-20 22:56 ` Ben Walton
2009-08-21 0:09 ` Carl Worth
2009-08-21 1:36 ` Carl Worth [this message]
2009-08-21 15:16 ` Chris Wilson
2009-08-21 15:19 ` Edward Z. Yang
2009-08-21 15:20 ` Ben Walton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1250817987-sup-7256@yoom.home.cworth.org \
--to=cworth@cworth.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox