rosparam/Reviews/2009-11 Doc Review_Doc_Review
Reviewer:
- Bhaskara
- Stu
- Tim
To review:
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
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