The bottleneck I see that the changes needs to be "formally approved"
This is currently required because the
ocaml.org repo contains code, which is run hourly on a server (formerly at OCamlPro, now at NYU, soon at OCaml Labs). Giving too many people direct push permission would be a security risk. Nonetheless, this can easily be resolved. We can have a separate repo for pure text contributions, and the
ocaml.org code could pull from that one at publish time.
My answer would be as lightweight as possible, oddmuse is perl, mediawiki is php.
I'd go even lighter. So far the idea I like best is using github. We could create a new repo ocaml.org-wiki, in which we use just the wiki feature. This provides pure text files which can be manipulated to generate nice output however we want. We can give push permission to everyone who requests it.
Before committing to this, I'd like to know if something like
99 Problems (solved) in OCaml could be supportable in a wiki (not just in theory, but realistically what work does it take)? Note it has images, icons to indicate the difficulty level, code that is auto-run through OCaml's toploop library, clickable boxes that show/hide the solution, and an auto-generated table of contents. All of these little details add up to making the page nice. A plain text version of this would be lame. Ideally, the tutorials, which are currently plain text, could also include more rich content like this.
Also these are wiki engines, so we probably don't need to hack on it.
Various hacking ends up being required. If you want to style the wiki content, you might have to change the attributes on the html elements, or something. Maybe someday we want to
ocaml.org to have user accounts for some other reason, and at that point it would be nice to make the wiki login system integrate with these other services. Maybe the wiki has an SSO capability that works perfectly, but maybe you end up having to read php code.
So no need to worry that we need to get dirty with php :)
It does scare me!
I also think ocsigen with ocsimore would be cool to have at some point
I'm enticed by this a lot! The trick is to start this on some sub-component of the website without disrupting the current work flow. Pick a particular feature that would benefit from the rich dynamic capabilities ocsigen enables, implement that in a separate repo, show the code works, is maintainable, and then it can be integrated into
ocaml.org.
We could have at least a static webpage generator like Stog
That's what we have, but we are using Christophe Troestler's Weberizer.
We should keep in mind all of the above is asking a lot from various people. Having an ocsigen backend means we are asking OCaml Labs to provide a server with ocsigen installed. Using the github wiki syntax to html converter, or weberizer, or stog means asking their respective authors to do work when the tools don't do exactly what is needed. Converting the current tutorials to wiki syntax will take hours, after hours were already spent converting them into html. But hey... a little peer pressure to get a better website is worth it. :)