My team does a lot of internal tooling and infrastructure work - you can think of us as a small scale version of the teams Facebook, Etsy, Netflix, etc. who build all the infrastructure for scaling their services up to thousands/tens of thousands of servers and supporting millions of users.
Lately, we've been running full steam ahead improving much of the tools we use internally, like tools for automatically creating new servers, setting up new application instances, etc. An end result of this has been decreased developer frustration, but increased 'ignorance' by most of the developer team about how to use our tools correctly and effectively. More often than not, my team will be asked by other teams to help them use the tools.
Solutions we've thought up or things already in place:
All our code is relatively simple and self-explanatory, with good comments where necessary, so developers could read the scripts.
Counterargument: You can guess this isn't a particularly good idea, having people read our tools' code to figure out how to use it.
All our code is committed to Subversion with very detailed commit messages about changes, developers could read the commit emails.
Counterargument: Expect the developers to read all our commits? Ludicrous.
Wiki - we have an internal company wiki, that we try to maintain with up to date information, but as we are moving so fast, the wiki has to keep pace as well.
Counterargument: As mentioned, we move fast in my team, as more improvements on our tools are added daily. Again still relies on people to read something that might change constantly.
Email the team? We could email the team when we have a glut of improvements to communicate.
So as you can all see, we are trying to find new ideas, and explore options we haven't thought of yet.
Anyone else ever been in a similar situation and have some guidance?