diagnostic_msgs/Reviews/2009-09-30_Doc_Review

Reviewer:

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?
    • JL: No,but nearly implicit.
  2. Are all of these APIs documented?
    • JL: API is messages only. Could be more explicit that "This is a message-only package"
  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?
    • JL: No tutorials, but they probably belong in diagnostic_updater.
  4. If there are hardware dependencies of the Package, are these documented?
    • JL: N/A
  5. Is it clear to an outside user what the roadmap is for the Package?
    • JL: No. Could be made clear that stability of package is intended to maintain internode-operability.
  6. Is it clear to an outside user what the stability is for the Package?
    • JL: See above.
  7. Are concepts introduced by the Package well illustrated?
    • JL: Question of if this is the right place for the overview of the diagnostic system. Probably not. Should maybe contain pointer to diagnostics stack.
  8. Is the research related to the Package referenced properly? i.e. can users easily get to relevant papers?
    • JL: N/A
  9. Are any mathematical formulas in the Package not covered by papers properly documented?
    • JL: N/A

For each launch file in a Package

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

Concerns / issues

Jeremy

  • (./) Tutorials and Troubleshooting links are dead

  • (./) (moved TF)Using Diagonistics in C++ section feels like it belongs in diagnostic_updater rather than diagnostic_msgs.

  • (./) (links to diagnostic_updater and runtime_monitor added in place of above TF) No mention of the diagnostic display system? Runtime_monitor?

  • (./) (in manifest TF) Pointer to whole diagnostic stack could be useful.

  • (./) (commented in manifest TF) Stability / importance of stability could be made more clear

Conclusion

  • Cleared

Wiki: diagnostic_msgs/Reviews/2009-09-30_Doc_Review (last edited 2009-10-01 01:49:32 by TullyFoote)