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?
- Users should not have to interact with this package, unless they want to change the behavior of the default controllers. It is clear to uses that this is the place to change the behavior of the default controllers.
- 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?
- To change the configuration of the default controllers, users need to look at the doc of the individual controllers. I listed all default controllers and added links to the relevant pages.
- If there are hardware dependencies of the Package, are these documented?
- The pr2 robot
- 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?
- This is tied to the roadmap of the default controllers
- 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?
For each launch file in a Package
- Is it clear how to run that launch file?
- The launch file in this package should not be used directly by uses.
- Does the launch file start up with no errors when run correctly?
- On a full robot it comes up cleanly. We might add support for robots without arms at a later point.
- Do the Nodes in that launch file correctly use ROS_ERROR/ROS_WARN/ROS_INFO logging levels?
Concerns / issues
- Good to go!