Personally, I would like it if the directory could replace the cliki as
the destination for asdf-install's mechanism to query where a package's
downloadable files are.  If we use care we can make sure that we make
this general enough for mk:defsystem or whatever might come in the
future.

I would like the directory to hold information about different
versions/releases of the same software package.  For packages with .asd
files, it could parse these files to figure out dependencies, the
current maintainer's email address, license, etc.  This gives us a good
bit of meta-information to provide to people browsing the directory.

Arthur Lemmens, I believe, pointed out the importance of comments so
that people can leave comments about what works and what doesn't;
perhaps even tied to specifiec versions/releases.  Of course, the
software could be tied to categories to make browsing the directory
easy.

Perhaps the directory could serve as a site to upload software so we
don't have to depend on sundry personal and institutional websites
which go up and down at inconvenient times; if we take this path we
must make sure that it's convenient enough for the publishers of
software to do just this.

An announce mailinglist (probably in a daily digest) should be
available so people who are looking for a continous update of software
available can get this without having to open a damned browser and
click around.  This should probably be granual enough that one could
pick a specific piece of software to monitor.  An RSS feed of the same
should be available so planet.lisp.org users could subscribe and get a
quick daily - or whatever - update of which packages were released.

Information on which implementations libraries run on would of course
be very useful; users could browse software available for their
implementation, only; same for asdf-install.  John Wiseman's latest
entry on lemonodor.com (the one about failing asdf-installs) is
interesting; the directory could run a nightly cronjob which did this
very thing: try to install the packages available and make sure they at
least load correctly (and perhaps down the line use asdf's test-op or
something more generic but similar).

I guess what I'm trying to say is that someone (I'll be happy to but
not for another three or four weeks) will have to sit down and write a
design specification for this that documents the interfaces.  Then the
potential users should be sought out for comments; especially those
working on asdf-installs and the like to make sure that the directory
can work with those tools.