Quality guide for ROS2

You can find a Quality Guide section in the ROS2 wiki now. A point to note is the dependency of various quality attributes on general design considerations which will be addressed in a Design Guide section in the ROS2 wiki. Both guides use a pattern format for efficient knowledge communication/transfer.

2 Likes

Do you have any particular direction in mind you want to take these pages? Are you looking for community contributions?

Sure. I encourage everyone to contribute. I just wanted to get something started when I stumbled over these first patterns a while ago.

Thanks, certainly a useful effort. I am reading through this. I think the goal appears somewhat similar to http://wiki.ros.org/Quality (which is a project we are starting to work on). A number of thoughts/questions.

  1. It is not clear (yet) for me how ROS2 wiki will be organized (is it going to live on github?).

  2. Perhaps https://github.com/ros2/ros2/wiki/Quality-Guide and http://wiki.ros.org/Quality should be maintained as sister websites linking-to-each other. OTOH, I think there will probably be large aspects of ROS quality that will be independent of ROS1 vs ROS2 division. So I am a bit lost on how should we organize ourselves. I am particularly concerned with duplication of work, maintenance effort, and also decreased visibility if we distribute too much.

To stick to a pattern format for a single “suggestions/recommendation” is the only thing one should consider right now w.r.t. contribution. (More and more books adapt to this format… even if you don’t always recognize it. E.g. all the “cookbook” style books implement a lightweight kind of easy to read pattern format.) As soon as a reasonable aount of patterns have been collected they can be categorized for easier navigation. In my experience there are usually more than 1 categorization scheme but this can be addressed e.g. if one uses different categorization schemes as table of content style referencing. E.g. there could be a categorization scheme according to “quality attributes” (reliability, security, etc.) which could reference some same patterns as a categorization scheme “software development lifecycle” (requirement engineering phase, design phase, implementation phase, etc.).

Thanks. My intent for a ROS2 specific quality guide was to start something which is from a technical point of view specific to ROS2. I also wanted to avoid to create a second ROSIN quality hub website with a lot of background information because it could prevent potential readers (especially developers!) from reading more than the first view lines until they realize “there’s nothing technical in there which I am interested in… I better watch out for some tutorials”.

I don’t know as well. I placed it there because it was most reasonable for me back then when I started to add the patterns. However from a contribution/maintenance point of view a github wiki is not the ideal tool to work with (not straight-forward to add images/diagrams, etc.).

Yes, from my perspective a single entry point for both, ROS1 and ROS2 would be ideal. There is already divergence of various sources already (ROS1 wiki QA sites, ROSIN quality hub) which we should somehow cross-reference and merge if required.

Another question is how to address different ROS2 user groups/domains packages are used in, applications packages are used in w.r.t. recommendations for quality related activities. (A lot of recommendations are just reasonable for the industrial domain.)

Recommendations could e.g. be coupled to the ROS industrial package “software status”: Experimental, DEVELOPMENTAL, PRODUCTION. (industrial_moveit is e.g. EXPERIMENTAL.) This would allow to recommend activities with relation to the development state of a package.

ADDITION:

In my experience it is especially challenging to define activity recommendations w.r.t to the application software is used in. The higher level SW design and the idiomatic level can be heavily impacted by this. Developing a good approach which enables iterative migration to avoid the need for major re-factoring of software is challenging. We can probably discuss about this challenge in the upcoming “ROS Quality Assurance Working Group meeting - April 2018”?

1 Like