self_test/Reviews/Jan 11 2010 Doc Review

Reviewer:

• Josh

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?

Not clear if this is for hardware only (implied by API docs) or more general.

1. Are all of these APIs documented?

Somewhat. Would be impossible right now to create your own self test without looking at the example cpp file.

1. 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?

No

1. If there are hardware dependencies of the Package, are these documented?

N/A

1. Is it clear to an outside user what the roadmap is for the Package?

No, but I'm not sure it's applicable

1. Is it clear to an outside user what the stability is for the Package?

Yes

1. Are concepts introduced by the Package well illustrated?
2. Is the research related to the Package referenced properly? i.e. can users easily get to relevant papers?
3. 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

• Josh
  • Example cpp file uses printf, usleep.

  • TestRunner API docs do not mention anywhere that it inherits from DiagnosticTaskVector -- had to look at the code to see where I would find the API docs for add()

  • TestRunner::setID() seems to imply that it must be called during one of the tests, which implies this is for hardware only, but nothing about that is mentioned on the wiki page. Also doesn't say what setting the ID actually does.

  • There's a lot of assumed knowledge -- use of things in diagnostic_updater without pointing it out or linking to the relevant documentation.

  • The example should be on the wiki (DocumentationPolicy)

  • Example uses magic numbers (0 = OK, 2 = ERROR, etc.)

Conclusion

I think there's still quite a bit to be done, but I'm not sure it should hold up any kind of release since it's not something that is widely used. The example is enough to work from, but is also really the only useful documentation.