[ros-users] [Discourse.ros.org] [Next Generation ROS] Design process of ROS 2

William Woodall via Discourse.ros.org ros.discourse at gmail.com
Thu Feb 14 19:53:06 UTC 2019

[quote="mkhansen, post:12, topic:7782"]

Im not sure I agree that adding slack or IRC is going to resolve this any better than Github and Discourse has. I think its just going to add more confusion, not less, IMO.


My observation was that of two of my recent design interactions with people outside our office, one was on GitHub and one was on GitHub but with short bursts on IRC, and that the latter was much more productive. It certainly doesn't address issues where we have insufficiently written down what's in our heads so that external people can more clearly see what we envision for the API or design, nor does it address the fact that we're all already overwhelmed with notifications.

To be clear we already have IRC, so we don't need to add it, though I suppose you mean "add it to our workflow", in which case my experience is that it would help, but again that's just my opinion.

[quote="mkhansen, post:12, topic:7782"]

I think something more like the model that Google Cartographer is using for their [Open House ](https://github.com/googlecartographer/cartographer#open-house) is a better way to discuss the key design issues in real-time.


In my opinion, that's just using instantaneous chat on a regular schedule with meeting notes. Another way to address this short fall of "being on the same page" would be to have more meetings where we sync with one another, though I'm not sure if that's more or less efficient that ad-hoc discussions in something like IRC or discord (or a voip conversation arranged in either). Personally, I'm at my capacity for meetings already.

[quote="mkhansen, post:12, topic:7782"]

I would also like to add that I do understand the iterative approach, but without knowing what the long-term design goal is, often the first iteration becomes the only implementation (as noted above by @gbiggs). At least if the goal is stated clearly in a design document (or an Epic as he suggested), then it can be made clear that there will be changes upcoming to reach that final design.


I've always been a proponent of more detailed design and finding as many issues as possible before starting work (to that point I created the design.ros2.org website and tried to encourage its use), but I've always been encouraged to just jump in and get started or to avoid things like "decision paralysis", "premature optimization", or "over-engineering". I think those are valid concerns, but at the same time I anticipated issues related to not having enough of our design written down in order to involve external team members. I also started to make a ROS 2 version of the "Conceptual Overview" from ROS 1 in order to convey more of this, but I've not had time to keep it up, nor has any project come along that working on that seemed to fit with:

https://github.com/ros2/ros_core_documentation/blob/master/source/rclcpp_cpp_client_library_overview.rst (note this is out of date by now)

Perhaps someone who is more on the side of "get things done" could speak up here.


[Visit Topic](https://discourse.ros.org/t/design-process-of-ros-2/7782/13) or reply to this email to respond.

More information about the ros-users mailing list