rosmsg/Reviews/2009-12_Doc_Review

Reviewers:

• Tully Foote
• Tim Field

Pages:

• rosmsg

• rossrv

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?

Concerns / issues

Tim

• Looks good. Should the page perhaps mention roadmap/stability?
  • done

Tully

• Define how the tools might be used, aka (introspection into messages available on the system for reference/development)
  • kwc: added overview
• Add troubleshooting for things like

tfoote@agn:/home/tfoote/stable$ rosmsg show std_msgs::Float
tfoote@agn:/home/tfoote/stable$ rosmsg show std_msgs/Float
Invalid message: 'std_msgs/Float'
tfoote@agn:/home/tfoote/stable$ rosmsg show std_msgs/Float64
float64 data

tfoote@agn:/home/tfoote/stable$ rosmsg show std_msgs::Float64
tfoote@agn:/home/tfoote/stable$

• kwc: I opted instead to improve the robustness of rosmsg show and made it tell users what they were doing wrong.

• Add a example for the packages, and users commands. Maybe put it in as a tutorial for it would clutter up the main page.
  • kwc: added example usages

Conclusion