Matrix/Gitter chat room

[smichel17]

In some posts, I am uncomfortable "wasting" people's time by posting unfinished thoughts. However, figuring out those thoughts can sometimes take a long time.

• In Allow to save/load current state of enabled quests #3034 (comment), holding my thoughts meant implementation started before I could share them.
• A quick chat might have resolved Don't enter compass mode before location is found  #3166 (comment) in much less time than I spent putting my explanation of the abstraction boundaries into words. Same with Thinking Through Quest Groups #3209.

I think it might be nice to have a chat room for times like this. I know there is a StreetComplete channel in the osmus Slack. However, the "GitHub regulars" that I'd be most interested in chatting with aren't there, and I prefer not to use proprietary apps when I can help it (I do actually have a Slack account, but I'm trying to get rid of it, not use it more :P).

If other people are on board with the idea (after all, sitting there talking to myself is not much use), then I think a gitter room would make most sense, since everyone with a GitHub account can join, and so can everyone with a Matrix account (since Gitter is a Matrix front-end now). I would take responsibility for managing the room.

[mnalis]

While I agree about using free and open protocol is definitely the way to go if one were to implement such a thing, I'm not too keen about real-time chat idea.

I am personally not the main target audience for this, and while I do recognize it might be faster way of doing things sometimes, here are few reasons why I wouldn't like it:

• it is another thing. Any communication channel that is added is inherently bad (eg. now people have 3 things to check instead of just 2), and should always be carefully weighted if the benefits visibly outweigh the problems. See the current OSM (and elsewhere) trend of trying to reduce the number of communication channels.

• not everybody is in the same timezone, nor is everyone free or online at the same time. This part might work out on big projects (where out of 20 developers, there will always be 2-3 of them available), but not so much on smaller ones.

• no automatic cross-referencing/searching of issues/solutions in chat. Manually curating and summarizing after each chat (as was done in days of Usenet with Followup-To: poster) is hard work, gets boring fast, gets out-of-date and has other problems of non-automated systems. (yeah vendor lock-in like GitHub is not ideal, but at least it gives some advantages of centralisation here)

• the most important advantage of real-time chat is its greatest disadvantage too: it is real-time. Which means, any incoming message will interrupt the developers who use it, and since context switching is quite expensive in human brain, it would be detrimental to their productivity (and peace of mind).

  Also, while developer could write and comment to an GitHub issue and walk away to do other stuff for the rest of the day without a second though, walking out in the middle of the chat might seem rude so they might feel pressure to "finish the chat", which could take away from their personal time and make the project not-as-fun. Also, time-shifting becomes problematic.

  Only way around this issue would be if developers would keep the chat disabled all the time, and only enable it once a day (or few times a week), when they have dedicated block of time and feel like it - which would make it mostly useless. (as it would then behave just like issues/discussion do)

  So, IMHO, as the developers of SC invest extra programming effort not to waste time of lots of users when they map (as even small amounts of time adds up then!), so should the users take the extra effort to maximally help the (so few) developers (like writing well researched and easily reproducible bug reports, or not interrupting them with real-time chat, etc.)

So I in light of all that, I would prefer to continue using GitHub issues/discussions, even if it is sometimes less efficient to us smaller-time contributors.

[smichel17]

only enable it once a day

I imagine that there would not be a regular time for chat at all. We'd only join when there was something explicitly to discuss. For example, I might say, "@mnalis Are you around to chat? " instead of having our long back-and-forth metaphor with meta-discussion in #2565. Only if you just replied so I know you're around. And then when we finish, I'd copy-paste the good parts back into the issue to summarize our discussion. In my experience, the healthiest chat communities are where it's not expected for everyone to read everything (closer to IRC semantics— a discussion is between those present… although it's nice to be able to ping people at any time and have them see it later).

I realize it's easy for a chat to grow and suck up a larger % of communications than intended (snowdrift.coop has this problem). And the community here is relatively healthy, so it's a reasonable thing to be measured in changing things.

Right now there's no side channel to have a conversation in. I've used #866 like that, before, but it's not really a good solution. We could try using GitHub discussions more like that. Maybe I just need to get used to posting less finished thoughts here in discussions sometimes.

[matkoniecz]

I think that as far as my OSM contributions go I should reduce amount of time used for online discussions/chats.

Given limited time it seems better to spend more of it on mapping/coding, and I am trying to do it.

With clearly substandard results. But I would definitely not join an extra chat - that would make things even worse. Especially if it requires figuring out new software.

[smichel17]

Yeah, I realize most folks here have a different relationship with OSM than I do (many of you are on mailing lists, etc; I exclusively follow this repository).

It doesn't necessarily mean taking time away from other OSM contributions, though. The chat can be a social space for relaxing in, and can replace time spent on other entertainment / media consumption.

Also see my reply to mnalis above.