mk/Reviews/2010-01-12_Doc_Review

Reviewer: Rob Wheeler

Instructions for doing a doc review

See DocReviewProcess for more instructions

  1. Does the documentation define the Users of your Package, i.e. for the expected usages of your Stack, which APIs will users engage with?
  2. Are all of these APIs documented?
  3. Do relevant usages have associated tutorials? (you can ignore this if a Stack-level tutorial covers the relevant usage), and are the indexed in the right places?
  4. If there are hardware dependencies of the Package, are these documented?
  5. Is it clear to an outside user what the roadmap is for the Package?
  6. Is it clear to an outside user what the stability is for the Package?
  7. Are concepts introduced by the Package well illustrated?
  8. Is the research related to the Package referenced properly? i.e. can users easily get to relevant papers?
  9. Are any mathematical formulas in the Package not covered by papers properly documented?

For each launch file in a Package

  1. Is it clear how to run that launch file?
  2. Does the launch file start up with no errors when run correctly?
  3. Do the Nodes in that launch file correctly use ROS_ERROR/ROS_WARN/ROS_INFO logging levels?

Concerns / issues

Tully

  • I cleaned up a few typo's and added a little bit to the package page.
    • (./) Thanks.

  • links to a few example packages might be nice.
    • (./) Added pointers to a few packages that use each .mk file.

  • The manifest descriptions should be extended to define the user (3rd party package authors, list the APIs (svn_checkoug, download_unpack_build, download_unpack, ...)
    • (./) Updated manifest to extend description.

  • git_checkout, rosmd5sumcheck, download_unpack, buildtest.mk are all undocumented
    • (./) Removed all of them.

  • genmsg.mk, msg.mk, node.mk, recurse_subdirs.mk are legacy and should be deleted
    • (./) Removed all of them.

Rob

In addition to Tully's comments:

  • In section 2 (CMake-driven builds), "here" links are generally considered bad style.
    • (./) Fixed.

  • In section 4 (3rdparty code, from SVN), the first sentence talks about pulling from a tarball instead of SVN
    • (./) Fixed.

Conclusion

Wiki: mk/Reviews/2010-01-12_Doc_Review (last edited 2010-01-19 02:06:49 by BrianGerkey)