![[lang]](/images/eye.png)
RSS feed readers for task tracking |
2008-11-10
|
A lot of the tasks I want to follow up on live outside of my GTD system and in various bug trackers. For a while, I've relied on mails to keep track of when I should be looking at tickets and taking some action, but that ended up not scaling very well.
So at some point I started experimenting with using RSS feed readers specifically for this purpose. My first attempt didn't work out very well.
Today, I spent some time trying again with various feed readers.
Here's the basic workflow I want to implement:
- go to my feed reader and see my 'daily' section which contains feeds for specific bug queries that I want to have a daily feedback cycle on
- See what's in there
- Go work on the tickets directly in the browser (so move away from the feed reader)
- After doing the work, go back, and refresh the feed reader to get validation that I've cleared my daily queue
Basically, I only want to use the feed reader to know when I should go do stuff somewhere else.
Now, all feed readers I tried today that actually worked seem to *never* clean up items from the RSS feed that were once in the feed but now have been removed. Is this standard, expected behaviour for a feed reader ? Am I trying to do something that's just not intended to be possible ?
Here are the feed readers I tried:
- tt-rss: doing an update does not delete the tickets that got removed from the rss feed; mailed the author
- liferea: same; though of all apps I tried today it did have the nicest user experience.
- blam: didn't show an error dialog for my https feed that had an invalid certificate; there was a console error though, and there was an option to allow invalid SSL. After that, the feed still didn't show up, and I had some GTK assertion on the console.
- snownews: was unable to open my https rss feeds with authentication; I was rooting for this one since it was command line so it would integrate easily with my gtd workflow
- gfeed: same as liferea
- evolution-rss: I was actually impressed with how well this integrated with Evolution; but afterwards, same problem as with liferea - updating the feed did not remove now-closed bugs that were gone from the rss feed.
Suggestions welcome from anyone who's tried to implement a task tracking workflow this way !
Things that I specifically want:
- store my list of feeds either on the web or in a text file I can commit to svn and sync across 3 machines
- link through to both the actual query and the individual tickets
- allow an 'update now' that removes items that are no longer in the feed
- allow https and invalid certificates
- implement username/password (for my private tracs)
Yup, that’s pretty much the expected behavior of a feed reader and highly desirable for usual stuff – after all, why should I lose the link to an article that I haven’t read yet, just because I waited too long? Storing the feed items relieves me from the uncertainty that I need to read that item *now*, otherwise it disappears. The key “problem” here is that a “removed” item in the feed is most likely an expired item that has just been thrown out of the feed because it’s too old.
I’ve got a backlog of 18 LWN.net entries that I want to read sometime, but it’s not a priority atm and can wait – I still plan to read those sometime in the future though, because they’re still interesting. Feed readers make it possible for me to keep track of those otherwise volatile items.
You’ve got a point though, it might also be desirable to just use the feed reader as composite view of all your feeds in their pure, original form. An option per link to get that behavior would be a nice idea, I guess.
(Akregator has an option to clean up its feed item archive after a certain item age or when the number of items grows larger than the configured value, and it also has an option to disable the archive completely – but even that only clears the feed on closing the application itself.)
Comment by Jakob Petsovits — 2008-11-10 @ 19:32
One other option is raggle, a curses client in ruby. I used it for a while before switching to GReader (for portability). Not sure about your requirements though, besides the text file.
Comment by Donnie Berkholz — 2008-11-10 @ 19:42
Did you file a ticket with ttrss? If so, I’d love a link. BTW – the trac site is http://tt-rss.org/trac
Thanks!
Comment by Craig — 2008-11-10 @ 20:02
While Jakob is spot on, what may be a work-around is to keep items as ‘unread’ until you’ve completed them. With Google Reader, this is pretty trivial: at the bottom of each item, there is a box you can check for ‘keep as unread’. It also has the added benefit that you’re not tied down to one system. Also, you’ll be running one less application (although obviously, the extra tab is going to consume some memory).
Comment by Shane Bishop — 2008-11-10 @ 21:01
What you are trying to do seems to be possible with Gregarius [1].
Its not exactly a feed reader, but a full-fledged aggregator.
You can tag and sort individual items, at least *shrug*.
It might not be the ideal solution, but maybe workable? Setting it up certainly is easy enough, and it also makes do with sqlite.
[1]: http://gregarius.net/
Comment by fizze — 2008-11-10 @ 21:16
“Now, all feed readers I tried today that actually worked seem to *never* clean up items from the RSS feed that were once in the feed but now have been removed. Is this standard, expected behaviour for a feed reader ? Am I trying to do something that’s just not intended to be possible?”
It is — if you use your feed reader for blogs or such, it’s always nice to have an archive of previous posts. Thunderbird has per-folder retention options that can automatically delete messages after a certain number of days, or after they’ve been read. Folders may contain more than one feed URL. No idea how helpful that is for you.
Firefox-based sage always only shows the feeds current contents (some South African page hosts a version of Sage that works with Firefox 3, too — it also only shows a single feed at once).
Comment by Aaron Strontsman — 2008-11-10 @ 21:46
“- tt-rss: doing an update does not delete the tickets that got removed from the rss feed; mailed the author”
That’s a feature, not a bug :)
Comment by Frank Osterfeld — 2008-11-10 @ 22:17
Liferea can have per-feed cache settings. Right click on a feed and select “Properties…”, then go to the “Archive” tab.
Comment by Jeff Ollie — 2008-11-11 @ 00:09
Look at http://www.newsbeuter.org/
Comment by Matthew — 2008-11-11 @ 02:53
http://www.taskcoach.org/
Comment by Cap — 2008-11-11 @ 11:57
Yes thats the expected behaviour, rss originally used to only be the most recent handful of news updates, not the result of a query – and it has no way of representing deletes.
So, don’t delete them. Instead, update the feed and use tags to identify bug statuses. (ie atom:updated, atom:category in an atom feed). Then you can filter bugs by their category, open or closed – lots of readers can do that.
If you’re using bugzilla (for example) this isn’t really possible with the feeds it supplies, since you need to get hold of the bugs that /are/ on your worklist and the bugs that /were/ on your worklist; you also need to get the atom:category labels into the feeds from the bug status, and bugzilla doesn’t do that, but the info is there and easy to extract. So, you could get two feeds with venus and massage them together into what you need.
Trac does use categories, but not in any useful way – their feeds entries are categorized as ‘Report’ or ‘Ticket’, depending on the feed you grabbed them from. They also don’t provide enough info in the ‘Report’ feeds to know the statuses of bugs without clicking through, which seems astonishingly unhelpful, so you can’t fix their feeds on the client side – you’d have to hack trac to get something better, not nice.
Comment by Baz — 2008-11-11 @ 16:40
well, try using firefox – live bookmarks, it does eactly what you want and you have a reader and browser in one.
Comment by Seeder — 2008-11-12 @ 11:11