On Wed, 2004-10-20 at 01:22, Olaf Chitil wrote:
I agree that using the Wiki is a sensible compromise.
I do not quite see why more people would be willing to edit a Wiki page than send an email to John and me, but it is worth trying. To make this clear: John and I are perfectly able to handle the incoming emails about desired additions and changes to the pages; there simply are very few of them. Most entries actually are written by ourselves, just from coming across things on the various Haskell mailing lists or otherwise. This activity is too time consuming (especially writing short descriptions when it is unclear to me what the library actually does) and I only do it occasionally.
I think the later is one reason why the wiki might work better. The wiki enables everybody interested to clean up other people libraries' entries. You might ask why should anybody do this? Firstly, freshmeat does work partially because package author and freshmeat entry maintainer need not be the same person. Secondly, what happens with wikis often is that people who use the wiki to try to find some information and are not successful do update the wiki if they find this information by other means. (The occasional wiki user probably won't do that, but regular users tend to develop a sense of responsibility for the accuracy of the information.)
I agree with Manuel that first we need to make some changes to the Wiki page before we can expect other people to make entries there. After that is done, I'm happy to place a big forward link onto the libraries page to the Wiki libraries page. Later the old page can go when all information has been transferred.
As Manuel says we should come up with a template and explain it on the Wiki page. Each entry should certainly be short, not much more than the current: name, URL, paragraph of description. For further information there could optionally be a Wiki link to a library specific page. I don't know what to do with all the version numbers on the current Wiki page. Are they really up to date?
The page needs to be broken into several pages, because it is hard to edit a huge page with the Wiki editor. On the other hand the hierarchy should not be too deep, requiring too many pages to select and load. Basically I think we could use the existing top level of the hierarchy of the libraries&tools page. Naturally, if we want to change this hierarchy later, this will be more complicated.
Let me make a concrete proposal for a structure for the wiki and see whether we can evolve this into something everybody can agree on. Libraries & tools ~~~~~~~~~~~~~~~~~ I think we should have two separate pages for libraries and tools. These days there are just too many of both, so that the main effect of treating them together is longer, less clear pages. Having said that, we might have a top-level page which is essentially only an index for both together, but then that should point to separate pages for, eg, FFI tools and FFI libraries. Short descriptions versus table of OS/versions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Currently, haskell.org/libraries/ and hawiki differ as follows: The former lists the name of each package with a hyperlink to that packages web sire followed by a one paragraph description. In contrast, the wiki has a table listing versions on different OSes. I think we want to preserve the one paragraph description of haskell.org/libraries/, but add some of the information of the table on the wiki. I agree with Olaf that it is probably hard to keep the version numbers up to date, but what I find very useful is to have a list of the supported OSes and also the license information that the wiki provides. The hyperlink at the package name can either be a directly link to the package web page or a link to a wiki page with more information including a link to the package web page. Page structure ~~~~~~~~~~~~~~ I think we should have one wiki page for each of the following topics, separating tools and libraries (modelled after haskell.org/libraries/). More precisely, one wiki page for each "*" bullet point, which is turn is structured as indicated by the "-" points. Tools: * Program development - Compiler and compilation tools - Integrated Development Environments - Editor support - Source documentation and browsing - Testing - Tracing and debugging - Type setting - Misc * Foreign language interfacing * Web programming Libraries: * Data structures * Foreign language interfacing * Databases * Graphics and graphical user interfaces - Widget sets - Graphics - Graphics file formats * Web programming, HTML, XML * Pretty printing * Music * Mathematics and numerics * Hardware verification * Robots * Misc * Library collections Remarks: - I think "Extended Haskell" entries should be under program development. - I don't like "Interfaces to specific systems" as something like hMPI is arguably for parallel programming and all the GUI libraries are arguably also interfaces to specific systems. For similar reasons "Interfaces to databases" should be under databases. Summary ~~~~~~~ * Toplevel index page with links to topics pages * Separate topics pages for libraries and tools * Topic as listed above * Format of entries: <package name as hyperlink to further info> < ........ one paragraph description ........ > <supported OSes> <license> Cheers, Manuel