documentation

In October of last year, I wrote a couple of articles, one about openness with regards to open source documentation and another about learning to embrace not knowing everything about the software or service you're documenting. I argued that if you're committed to openness in the support process, then you're also committing to asking for help when you don't know the answer to something. As the support master for Bryght, I've been tasked with writing some documentation for new functionality we added for in our new Bryght Basic profile, i.e. the ability to route system messages to essentially anywhere. This will be part of core for Drupal 6, and it has been backported for our Drupal 5 VPS customers. (Boris posted the reverse bounty, and Khalid came through with a backport.) I've written some skeletal documentation on the new Syslog module, I've been able to figure out and document routing Drupal logs to a file, which you can run the Unix tail command on to get a live view of what's happening on the site:

In that screenshot you can see that I typed in two URLs I knew to throw a 404 error message, tried a URL I knew would get access denied, created a test blog post then deleted it. It contains a lot of information, like the date, the site in question, the URL accessed, and the error/status message.