Create Doxygen manual

I'm the author of RakNet, a networking middleware library for games. I am using Doxygen to comment my header files - however, my understanding of Doxygen is limited and I know it is possible to make very nice HTML output from it. I'm offering a contract to improve the look and formatting of my pages through better and more use of Doxygen tags, such as grouping, links, and other formatting methods. The work would involve every header file here: <[login to view URL]> And here, recursively: <[login to view URL]> ## Deliverables RakNet currently has a Doxygen manual at [login to view URL] based on header file comments at <[login to view URL]> <[login to view URL]> All header files recursively under DependentExtensions, except bzip2-1.0.3, Lobby, Ogre3DInterpDemo, openssl-0.9.8g, PatchTest, portaudio_v18_1, speex-1.1.12 The contractor would be responsible for creating and editing Doxygen tags such that Doxywizard will parse those tags to produce attractively formatted output, grouped logically, with easy-to-navigate pages, and proper descriptions. Requirements: 1. Output must start with an introduction page, with links to every major section 2. Must produce a table of contents 3. No broken links 4. No missing images (where appropriate) 5. No spelling errors 6. Writing must be in native english, easily understandable 7. All public functions must be documented (currently some functions may be missing documentation) 8. All files must have documentation 9. Groups must be created for major sections, such that a user can go to a group to read about a particular feature, or portion of the library. At a minimum, this includes every class that derives from PluginInterface2, the Crash Reporter tool, all the Lobby2 commands, and a depreciated group for depreciated classes 10. For each group, the group itself should have text indicating the purpose and function of the group 11. No hand-tweaking required of the Doxygen output to get the correct formatting. 12. Every function must have \param[in], \param[out], and \return where appropriate 13. If the description of a class or function is longer than two sentences, it must also have \brief 14. Bidder is responsible for updating from SVN trunk on a daily basis, and before every submission, to integrate work done with the current code. It is not acceptable to submit old code, or documentation based on old code. Depreciated systems may be marked as depreciated, and no further documentation is required on those systems, besides listing them in the depreciated group. This includes: AutoRPC RakPeer::RPC Lobby ReplicaManager ReplicaManager2 Bidder is required to begin work on the project within one day of bid acceptance. Daily code updates must be provided once work has begin. * Edit 1 - Requirements clarification * 1. You are not required to check into SVN. At the end of each work day: A. Update from SVN, and integrate if necessary B. Run Doyxgen on the code to generate HTML for the changes you have made so far. C. Send me a message describing the changes made. I will provide feedback on these changes. 2. In the final output, running Doyxgen on the code generates no warnings or errors. I am willing to waive warnings and errors that are inappropriate. 3. To clarify the meaning of attractive output: The existing documentation essentially only uses 4 tags: \brief \note \param \return This generates a disogranized morass of code, because Doyxgen does not understand the relationship between bodies of code. Furthermore, the output is very basic - just a list of functions. Doyxgen provides dozens of tags however such as subsections, indicating blocks of code for samples, text formatting tags, including blocks of HTML code, images, and bullet points. This project is not about simply reviewing the existing documentation to fix spelling errors or add missing parameters. It is about using the rich set of tags that Doxygen provides such that the final output is organized and attractive. The coder is essentially turning a large body of header file output, which already had Doxygen tags, into what a professional coder would be able to use as an independent manual. This manual should contain, but is not limited to: Formatting tags to improve the visual quality of the content Images, where appropriate. The manual found under /Help already has images one can use. Additional images can be sourced upon request (either custom, or purchased). Examples, where appropriate to clarify complex functions Tags to organize the output, with links to relevant sections, especially when structures are used as input parameters. 4. In the cases where tags are missing, such as parameters or function descriptions, the tag the coder inserts must add information. An example of a tag that does not add information: /// Prints the screen void PrintScreen(void) An example of a tag that does add information: /// Prints the user list to the console. Called by User::DefaultImpl() void PrintScreen(void) The coder can ask for clarification on missing tags, in which case text will be provided.