rosparam/Reviews/2009-11 Doc Review_Doc_Review

Reviewer:

• Bhaskara
• Stu
• Tim

To review:

http://www.ros.org/wiki/rosparam

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

Stu

• What's stopping rosparam get -p from becoming YAML-safe?

  • Two things: (1) development time, (2) future-proofing. The latter is more important. I often get feature requests like, "timestamps aren't readable, can you make them look like this?" Stating up-front that -p is not YAML safe gives me a path for developing this "readability" tickets without having to retrofit an entire toolchain. This is less an issue with rosparam given the parameter server representation.

Bhaskara

• Fixed some typos
• The para in section 2 on dictionaries could probably be clearer. I suggest:

YAML dictionaries can occur as the argument to the load and set subcommands of rosparam. Dictionaries in this context are interpreted differently from dictionaries that are set as the value of a parameter (e.g., from a C++ node). In the first case, ...

• kwc: new text: "YAML dictionaries can occur as the argument to the load and set commands of rosparam. Dictionaries in this context are interpreted differently from namespace dictionaries that are set as the value of a parameter (e.g. from a C++ or Python node). Instead of replacing a parameter namespace, dictionaries in rosparam are unpacked into individual parameters to be set on the Parameter Server. Thus, rosparam dictionaries can be thought of as adding new values to a parameter namespace."

• The first line of 4.3 should be "set parameter_name value"
  • kwc: fixed
• Should refer back to the issue with dictionaries in 4.3
  • kwc: fixed

Tim

• Removed "[...]" from lines which represent input on the command prompt

• ROS/YAMLCommandLine has salient info. Maybe link to it at the beginning of section 2?

  • kwc: fixed

• If the special converters aren't peculiar to rosparam, consider moving that info to ROS/YAMLCommandLine

  • kwc: they are rosparam-only

Conclusion

Suggestions have been incorporated, marking as doc reviewed