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

William Woodall via Discourse.ros.org ros.discourse at gmail.com
Sat Feb 9 04:07:47 UTC 2019



I think lack of time to iterate and the lack of a democratic process for contentious design choices are issues here, but instead of solving those difficult issues here and now, I think better communication practices could help in the meantime.

tl;dr I think we should:

- use instantaneous chat more often
- consider some tools to facilitate that (like discord https://discordapp.com/open-source or slack)
- try to mitigate overwhelming core contributors with community moderation (as needed)

----

I think the discussion we had about the actions API suffered due to the nature of email/discourse discussions being so delayed. You end up with a lot of interleaved responses and it's hard to iterate on disagreements.

To that point, I think one thing we're missing is _good_ instantaneous chat.

We have an IRC channel (`#ros`) which is _text_ chat and is in my opinion just ok.
I am usually on IRC but rarely use it.
However, I recently had some design related discussions with a community member (@kyrofa sorry to single you out) and it was honestly much more productive than back and forth on GitHub or discourse are usually. So I'd like to see more of this kind of chat to see if it helps these cases.

However, IRC is just _ok_ and we lack a convenient way to do higher bandwidth communication like voice or video without scheduling a meeting (for what ever reason we don't use IRC to agree to do a Google meet or skype or w/e). I really enjoyed having a google hangout "situation room" during the crystal release. I think it was helpful for community members trying to get things into the release to be able to just hop in and ask a question, or just listen.

I know @dirk-thomas likes to say "different tools will not solve the problem" (and I tend to agree), usually meaning that when there's an underlying issue like lack of time to read and respond to design questions different tools won't help, but in this case I think a chat system that's more modern than IRC might be helpful, especially if it has a voice and video option which would make it casual to start up a conversation.

I think using text chat (whether IRC or something else) would help, but honestly it will cause other issues. Usually, if I don't answer a question about design things on discourse or GitHub immediately it's because I'm busy. If someone hits me up on IRC with a very specific question, they're more likely to get an immediate response out of me, and that's good for both me and them, but it also makes it harder for me to focus on long running tasks. It's all too easy for me to loose an entire day to reviews or design questions or help with bugs (whether they come from the OR slack or IRC or GitHub, etc...). So if we spend more time talking on these high bandwidth channels, I think it's going to improve others ability to work with us, but it's also going to consequentially impact our productivity.

I've seen this issue with content creators in the video game industry, and the way they balance this is by having community moderation, where issues bubble up through levels of access and insulate people who are easily overwhelmed. Email/GitHub/Discourse are kind of good for this, because it makes it easier for me to ignore conversations until I have time, but I still see them and often fall into reading them, thinking about them, or responding to them. I think a more casual setting might encourage community members to respond to each other before I even have time to read it. For what ever reason, I find this is more common on something like IRC than in forums like email. Perhaps because the perceived cost of a response is lower.

I've been thinking about suggesting that we emulate these communities for some time, but ironically I haven't had the time to put together a proposal. But briefly, I think we could learn from their use of community moderation, and the tools they use to accomplish that. One pretty common thing is that almost all of them use discord, which is a free service that provides text, voice, and video chat in channels (sort of like slack). However, it is geared towards gaming and gaming communities, but it seems to excel at community management, and it provides a lot of tools and automation for this purpose. There are a few projects using it already, and they have an Open Source outreach page: https://discordapp.com/open-source Other communities have similar solutions with different tools, choosing to use slack or gitter or one of the other options. I'm not tied to discord, but I do think it's a good solution. Obviously there's always a discussion to be had about memorandum and the ben
 efits of asynchronous communication like email, but I personally think there's a place for these more modern solutions to facilitate ephemeral discussions.

Currently we don't use the services we already have (IRC) to full effect, but I think if we had a more modern tool like discord or slack, and more of us committed to being available on it (IRC is pretty dead most of the time), then we might increase our use of it. This would help with communication. We could start with no moderation or hierarchy, i.e. everyone has "access" to everyone else, and if it becomes an issue we can start to add some structure to prevent overwhelming individuals.

No matter what we do (in terms of mitigation techniques like community moderation), this will negatively impact some people's productivity more than others, but it will also hopefully let us better leverage other contributors who are blocked or frustrated otherwise. So I think we just need to be aware of this trade-off and (this isn't a new request from me) also take this time spent collaborating into account when scheduling feature development. Personally I think this point needs discussion and support from the TSC level, but that's just my opinion.





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




More information about the ros-users mailing list