Real-time team chat service?

[SirWumpus]

Other than social media (Mastodon), does the IOCCC support / prefer a common real-time team text chat service? Wire (E2E, group chats), Discord (pumped IRC), IRC (This Is The Way), other (for lesser mortals)?

Some of the Off-Topic discussions held during an Issue sometimes detract from the actual focus of an issue. Just wondering if there might be a more suitable channel for history, commentary, general chit-chat, rants & raves, etc.

[xexyl]

Nothing of the sort.

I understand the fact there are often OT things brought up. That is in part why there is an OT issue though it's not a perfect solution as sometimes something is relevant to a specific issue.

Email works I guess? IRC is something I have not used in a long time - at least not regularly.

[SirWumpus]

[xexyl]

Funny thing: I clicked the link 'uploading ..' and I guessed that you were making a joke as it just linked to this discussion. Now I see it's an image. I always thought if you clicked comment before it fully uploaded it would fail. Though I never really tried either.

[lcn2]

Some of the Off-Topic discussions held during an Issue sometimes detract from the actual focus of an issue.

Apologies for all of the OT. No we don't have a a sideband social media platform for that sort of stuff.

We had created an issue for each repo of the form "Question: Issues that aren’t really major issues but are still issues". The intent was any OT or semi-OT would do there.

As work winds down we expect those "Question: Issues that aren’t really major issues but are still issues" to be closed.

Perhaps we should have just opened a discussion for such OT and semi-OT stuff instead of an issue. Would that help, @SirWumpus ?

[xexyl]

And there is no reason not to create master tasks that tie a collection of smaller ones together. Granted the GitHub UI doesn't lend itself well like Phapbricator, but it is possible to create task lists in Markdown.

Sure there is.

And we already use the task lists you refer to.

[xexyl]

And there is no reason not to create master tasks that tie a collection of smaller ones together. Granted the GitHub UI doesn't lend itself well like Phapbricator, but it is possible to create task lists in Markdown.

Sure there is.

And we already use the task lists you refer to.

There aren't that many OT comments in threads that aren't related and not many OT comments in real issues anyway.

I don't want to have to go back and forth for the same topic. That's just silly.

[xexyl]

And there is no reason not to create master tasks that tie a collection of smaller ones together. Granted the GitHub UI doesn't lend itself well like Phapbricator, but it is possible to create task lists in Markdown.

Sure there is.

And we already use the task lists you refer to.

There aren't that many OT comments in threads that aren't related and not many OT comments in real issues anyway.

I don't want to have to go back and forth for the same topic. That's just silly.

And also as far as references to issues using the format #n is nicer in the sense that it will link to it.

But that's a stylistic choice I suppose.

Back another time. Have to go. Good day!

[SirWumpus]

references to issues using the format #n is nicer in the sense that it will link to it.
But that's a stylistic choice I suppose.

I avoided the use of #nnn in commits on favour of GH-nnn just in case I end up moving to another service. The GH- prefix at least signals GitHub, maybe GitLab is GL- , Sourceforge SF-, email-nnn etc. The #nnn is too generic and outside of GitHub, I would not necessarily know where the ticket was reported. Just a little future proofing my process.

Its not like we're being charged by the byte.

[xexyl]

references to issues using the format #n is nicer in the sense that it will link to it.
But that's a stylistic choice I suppose.

I avoided the use of #nnn in commits on favour of GH-nnn just in case I end up moving to another service. The GH- prefix at least signals GitHub, maybe GitLab is GL- , Sourceforge SF-, email-nnn etc. The #nnn is too generic and outside of GitHub, I would not necessarily know where the ticket was reported. Just a little future proofing my process.

My immediate and logical[0] reaction would be that you're not elsewhere. But my reasonable reaction that follows right after is that this is a matter of personal preference and style and it does not matter[1]. Sure it helps in GitHub but it's not a requirement. Though I might add that for me GH doesn't necessarily equate to GitHub. I only knew you meant it as you did those PRs on GitHub.

[0] This is not to say that I'm always logical and it's not to say that when I'm logical it's always immediate but it often is. Still I am a human being so there are many times I am not and I also enjoy being silly and even eccentric - in good fun. In this case, as noted, it's not about being logical that matters (something that can sometimes be hard to say).

[1] Do not, however, get me started on the ridiculous warning about misleading indentation in compilers nowadays. That is style policing at best. The same thing for when a for() or while() loop does not need an actual body of code as the condition/increment does it all, a common C idiom. I have had to put on a semicolon on a line by itself (often) in code just to shut that stupid and useless (and to call it useless is an extreme understatement, the same with the other one about misleading indentation) warning up. When the misleading indentation warning first came to gcc it was enabled by -Wall (a good one to use) and there was no way to turn the thing off. So I had to 'fix' code that was not broken and not in any way confusing or misleading to anyone who can read C. Changing code on style because a compiler warns about it is nothing but error prone and a waste of time.

It's not like we're being charged by the byte.

I suppose we're not. But we might be charged by the bite! On the other hand I also like the # form because I follow the git best practice of having the first line 51 (I think it was 51 .. maybe a bit more?) chars (or under) and a blank line after it. I configure vim to warn about these things too.

Of course we might ask who gets to decide what is best though (and it should be better as there is only one other option but that's another topic entirely). It's in documentation anyway and it is kind of nice to have a shorter summary. Still it can be annoying at times and writing more briefly takes more time, something humorists have pointed out (in amusing ways) and - going back to my favourite, so too did Tolkien (in a letter).

Anyway all that is to say I don't mind if you use your style. If it works for you you should use it!

Still as far as the number of issues I have so many emails from GitHub that it would be even more annoying to have to have another email for the same topic - but I would not want it anyway as I like to keep things together. Sometimes we do take it to the more OT thread though, fwiw.