On Saturday 2009 June 20, the Twin Cities Documentation Sprint (that's the twin cities of Minneapolis and Saint Paul in Minnesota, USA) will happen from 10AM through 5PM CST being held at Advantage Labs with sponsorships from fivefivefour and Gorton Studios. This event was crowd-sourced at one of our meeting.
We are still figuring out what areas we can focus on, but we don't actually need a specific agenda. If you have some documentation requests, please leave a comment. There will also be some members in the #drupal-docs IRC channel as well.
This past week, drupal.org experienced some down time; which is normal. The infrastructure team does an amazing job keeping things going as smoothly as possible, given the immensely growing community of Drupal.
But, of course, I needed to reference some functions and hooks at api.drupal.org, the community's resource for code documentation. Fortunately, there are a few places to go that have implemented the fantastic API module to help supplement api.drupal.org or help document their own modules.
This API module basically scans a directory recursively and reads the Drupal Doxygen documentation that is available and creates an easy-to-use interface to browse it all.
The API module would not be possible without in-depth, inline documentation in the Drupal code base. (We won't get into the importance of non-inline documentation.) As a programmer, I love some documentation, but I also understand how much of an after thought it usually is for most of. So, even if you think no one will read your code, think again; there's a good chance it will make it's way onto someone else's screen. And if you contribute modules, a good module has good documentation within the code.
Well, you should always document your code correctly. But, you can also set up an API site locally and for those other folks on the interwebs.
The first step was to install the API module locally so that if the Internet was not even a possibility, then I could still have an easy interface to reference the Drupal code base.
The second step was to create a public site, in my case api.zzolo.org, to help others have this information when needed. I also put a copy of HEAD up there, started to make a section for contributed modules for Drupal 6, and installed the almost-perfect-for-api-sites-theme, Pixture. Freestyle Systems did a nice job of setting up an API site with contributed module references, and is a good example. I attempted to mimic their ability to browse contributed modules; but mine is not as great as theirs.
Unless otherwise noted, all content on this site is licensed under Creative Commons Attribution-Share Alike 3.0.
Please see the legal page regarding more in depth information on copyrights or other relevant laws.
