Using a Gnus for collaborative work & todo list mgmt?

[Kai Grossjohann <grossjoh@charly.informatik.uni-dortmund.de>]

Hi there,

we're thinking about maintaining todo lists with Gnus for a group of
people.  So far, here's what we've come up with:

Consider the area `emacs'.  We define groups:

  - emacs.new: contains new todo items
  - emacs.cur: contains items that are currently being worked on
  - emacs.old: contains old items, used for reference

Whenever somebody sees an article in a .new group that they want to
work on they move that article into the .cur group, with their login
name prepended to the subject (there's a function to do this).

In the .cur group, followups and similar things can be used to update
the status of each item.

When the item is completely done, the whole thread is moved from .cur
to .old.

Now the main issue: what kind of backend could we use that
  - allows read/write access
  - doesn't cause too many problems with several people writing (I'm
    not even concerned about locking, it's just that I'm unsure about
    .overview files, for example -- what happens if somebody adds
    something to the .overview file while I'm reading a group -- will
    the new article just appear the next time I get new news?)
I would think that, say, nnfolder is not a good idea because several
running Emacsen may have a copy in their main memory.
What happens if several people read and write the same nnml directory?

We would also have to do some magic to allow `refreshing' of stuff
(`I want this to (re-)appear as a new item in 2 weeks').  But I
suppose that could be done by adding an emacs.susp group where each
article has a header saying when to `refresh' the item.  A cron job
could then do the rest.

I'm looking forward to hearing any suggestions you might have,
kai
-- 
Life is hard and then you die.