- Tully Foote
- Tim Field
Instructions for doing a doc review
See DocReviewProcess for more instructions
- Does the documentation define the Users of your Package, i.e. for the expected usages of your Stack, which APIs will users engage with?
- Are all of these APIs documented?
- 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?
- If there are hardware dependencies of the Package, are these documented?
- Is it clear to an outside user what the roadmap is for the Package?
- Is it clear to an outside user what the stability is for the Package?
- Are concepts introduced by the Package well illustrated?
- Is the research related to the Package referenced properly? i.e. can users easily get to relevant papers?
- Are any mathematical formulas in the Package not covered by papers properly documented?
Concerns / issues
- Looks good. Should the page perhaps mention roadmap/stability?
- 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