On Sat, 15 Dec 2012, Florian Haftmann wrote:
I started this repository for two reasons:
* I had to cleanup the webserver configuration and needed proper
versioning.
* I wanted to discover ways to maintain documentation in a lightweigth
fashion apt to versioning.
Such a purely administrative repository for internal use does have a
purpose, since not every aspect of the TUM configuration needs to be made
world-readable on public servers.
We merely need to learn where to draw the line. For example, the isatest
settings have greatly benefitted from being exposed in
Admin/isatest/settings under official version control. Before it was
always a guess in the dark what isatest was using in a failed test in the
first place.
Concerning wikis in general, since over one year I do not consider
mediawiki the tool of choice for our purpose. It requires massive
infrastructure, its format is a sink (only mediawiki can parse
mediawiki), and is hopelessly tied to a RDMS backend which is useless
until the number of your users grows beyond, say, 10 in a minute (just
to give a figure).
For my part, I knew that already before the start of the community wiki.
MediaWiki is "the" standard wiki in public perception, mainly because
Wikipedia uses it. But Wikipedia uses massive add-on technology and
social and administrative structures to arrive at its perceived quality.
Without that a MediaWiki wiki becomes a sink for rubbish by default.
The Isabelle community wiki has emerged in a classic way you normally tell
first-year students as bad joke in software technology management:
* 2-3 users (students) had asked for a wiki at TUM for their own use
as "isanotes".
* Without spending any time to think about the "implementation" the
admins were asked to install a mediawiki server that they happened to
have already running anyway. It was known to be an insignifant,
temporary experiment, so nobody cared much.
* Since the wikiserver happened to be there already, it was re-dedicated
to host the Isabelle community wiki.
So systematic use of things that just happened to be there by accident.
This is the standard way to produce a lot of follow-up costs in everyday
use and maintenance of the result.
If a wiki frontend seems critical, as of today I would recommend
something like Gitit http://gitit.net/, which uses hg or git as backend,
with all benefits like easy integration into versioning infrastructure,
usable without frontend etc.
This is one of the many starting points for contemporary technology to do
the job, in a more lightweight and more robust way than old Mediawiki.
Every time I pass by Bitbucket, I am impressed how nice they make a
secondary "wiki" repository appear on the web, using the existing concepts
of Mercurial repository + interpretation of Markdown. Even the "main"
repository looks nice on the web, with rendering of README within each
directory. (They even have a tracker that does not look like the first
big issue to be tracked with it, but it poses probably a vendor-lock-in
problem, unlike the wiki with its generic hg + md basis.)
Makarius
_______________________________________________
isabelle-dev mailing list
[email protected]
https://mailmanbroy.informatik.tu-muenchen.de/mailman/listinfo/isabelle-dev
