TASKS

 -*- Text -*-

These are a few tasks that I hope others can complete.  I will eventually
get to them if nobody else does, but that will take time.

These two are always important:

Read the code:
  It would help immensely if someone could just read over the code and see
  what is sufficiently commented and documented and what is not.  If a
  construct is not understandable on its face, tell me and I will comment
  or rewrite it to be clearer.  This project is for naught if after I'm
  dome with it others can't work on it.  This could be done module by
  module.

Write some docs:
  One of Majordomo's largest problems has been its lack of good
  documentation.  The installation will be made much simpler in 2.0, so
  that problem is somewhat mitigated, but there's still the problem of
  general list administration, a whole new category of advanced list
  administration (multiple moderators, peer review, access_rules and the
  weird things you can do with it, etc) and the always painful subscriber
  documentation.  SRE has done an amazing amount of work getting the
  documentation that's there in place but documentation is a neverending
  task.

Next, some things in the forefront:

Write the report generator:
  Majordomo keeps logs of everything that goes on, and the list owner can
  choose how they will be informed of happenings.  One of those choices is
  to receive a summary report, but the report generator isn't written.

  We need to be able to generate reports of all kinds of list activity:

  Posting activity, including breakdowns of who posted what, common
   subjects, etc.  (Some of this was implemented in a list statistics
   package that I have; the code could be reused since the message log
   format is quite close to what this package used.)
  Meta-list activity: who signed up, who left, a count of accessed commands
   and files, etc.   
  Bounce activity: what addresses are bouncing, which were removed because
   of bouncing, etc.

  Pieces of this report need to ge generated based on the owner's inform
  settings.

Work on the web interfaces:
  Currently we have three interfaces: one for accepting confirmation
  tokens, one for doing user tasks and one for doing admin tasks.  These
  could all use some polish.

Stress test the bounce parser:
  We should be correctly parsing the great majority of all bounces now, but
  it would be a great help if everyone could save all of their bounces (one
  file per) and run misc/parsebounce.pl over them.  Any bounces which
  aren't parsed but should be (i.e. they have to contain information that
  we can reasonably parse) can be sent to me (tibbs@math.uh.edu).

 - J<