Best practices for threading in GitHub discussions

[smichel17]

Since there is only one level of threading, I think it's best to err on the side of top-level replies instead of threads, even if GitHub's UI (and sometimes @westnordost) push you to reply in threads. Threads are good if you're sticking to one topic, but if you throw another topic into the mix then you have the same concurrent-conversations problem again, just in an even more cramped location.

An excellent example of threads done right is #3326, especially my discussion with @mnalis at the start. It's mostly top-level comments, but then we use threading to isolate small tangents that would otherwise clog up the discussion.

An example of dangerous threading is the first few replies to #3341 (comment), which threaten to mix discussion about phrasing and changing the picture.

[mnalis]

I guess it was bound to happen to have a github discussion about github discussions. 😄

<rant>
Unfortunately I find github discussions (as currently implemented) quite bad from usability point of view. They are basically relatively OK-ish for only one (rarely used) use case, and fail horribly if they are used (even slightly) in any other way. They are also totally unreadable if one wants to find what is new in some discussion (unless one has e-mail notifications enabled and does all the reading in e-mail client, and then opens the web to cross-reference what that reply is related to). It is also hopeless to make sense of them if GitHub discussions are actually used to discuss any non-trivial matter which requires several back-and-forth attempts and clarifications, so they become big and tangled. And the "vote up" buttons actually make it even worse as they break any semblence of temporal connection if used in a way there were supposed to be used (luckily, we can still ignore them completely and sort by time, but that leaves useless and potentially dangerous UI pieces around, especially as we also also like/dislike/etc emoji icons which do kind-of-the-same-thing-but-not)

I find it quite appalling that UI attempts at user-friendly communication with threading have been going steadily downhill since the early 1980s Usenet !
</rant>

Plain GitHub issues work much better IMHO at least in updates/following regard, as one has position anchors. Still no threading at all, but one can at least try to manually simulate it with username notifications and markdown multi-level quoting (and lists).

Unfortunately, the best I can see GitHub discussion being used are:

• do not use "vote up" button, ever (use 👍 or 👎 🚀 etc. icons to indicate (dis)approval instead).
• always sort discussion by "oldest" (or any temporal connection between comments is lost)
• never use "reply" functionality on existing "comment" (it breaks discussion in two forks making it very hard to follow, and also makes finding new content since last visit next to impossible)
• always add new "comment", use quote markdown (>) to reference text you're replying to and, and reference it via @username and HREF links to manually indicate what you are replying to
• also, never edit any comment for any useful content change, as it does not generate mail notifications and will likely get missed (this also applies to regular GitHub issues). Using edit to fix spelling mistakes and other minor formatting changes is only acceptable usage.

That way, if everyone were to follow those rules, GitHub discussions might become almost as usable as GitHub issues (except no cross referencing or other issues is visible, and much more screen estate lost due and harder to follow due to different UI). Unfortunately, it is not likely to happen that everyone will even know, much less always follow, those rules.

Or, perhaps we can create new type/tag of issue, which overworked developer would ignore, and use that for discussion?

Note: I'm using GitHub Discussions terminology here (eg. "reply" is what happens when you type in the textarea with "write a reply" placeholder text, and "comment" is the textarea with "write a comment" placeholder).

[matkoniecz]

also, never edit any comment for any useful content change, as it does not generate mail notifications and will likely get missed (this also applies to regular GitHub issues).

In case of substantial new content I publish a new comment with them (to generate email notification) and delete it. Not sure is it welcome by users of email notifications or not.

[westnordost]

When the osmf finally moves the forum to discourse, one option would definitely be to also switch to that, have an own category for Streetcomplete.

[smichel17]

been going steadily downhill since the early 1980s Usenet !

This was before my time. How did/does Usenet handle threading? I assume it was similar to email, with manual quoting?

[westnordost]

The best / only forum that I know handled threads very nice is the mwForum. No-frills, simplistic. However, the software is not maintained since 2015 or so. There are probably a couple of more, but the instances I know are

• OpenClonk Forum
• LibGosu

[smichel17]

Looks like those have full threading, with no depth limit? Like reddit and hacker news, among others.

The downside to that is it fragments the conversation. You end up with a bunch of people talking back and forth; it feels more like a party where people group off and have their own separate conversations than everyone sitting in a circle to discuss one thing.

[westnordost]

yes

[mnalis]

Yes, multiple subthreads like reddit were the norm; but the main difference is something you don't see at web-based forums at all (at least I never found out anything even remotely usable comparable to (for example) 27 years old slrn Usenet reader) I prefer.

Because you could mark a whole subthread as interesting or not interesting with a press of one key, or even hide it completely in the future.

Or in the other direction, score certain persons or (sub)threads or keywords as interesting, and have them being brought to your attention (sorted) before all of the rest less-interesting stuff, with a choice of preserving ordering of subthreads stemming from them. Marking articles (or whole groups of them) as read, or mark as unread so you can visit them later, collapse/uncollapse threads, etc. Add to that capability to easily save threads locally for later perusing (while preserving all metadata like subthreading data, authors etc). And of course you can change all that on the fly as you wished.

Quoting was automatic, but also editable -- like e-mail depending on your client (like in github issues it quotes with > but you can also manually edit or add different levels of quoting >> etc). It also stored message-id of the posts you replied to in references, so you could always reconstruct whole thread by finding post partent, siblings etc. (but good e-mail clients let you do that too).

All that in an easy to use program of your choice - so you as a reader (instead of the forum owners) choose your UI and functionality and keybindings, and have them universal throughout all the interest groups ("forums") you wanted (like you use one mail reader for your e-mail, instead of being forced to use different mail reader depending on who sent you email). All that at amazing speed, even with old hardware, compared to web stuff. Oh, and you could easily have posts stored for offline use and sync them when you got online (kind of like git vs. cvs)

The net result being that you could comfortably read most interesting of 1000 of posts in the same time it would take you to get through maybe first few dozen posts today on some web forum - and most of them uninteresting to you (as you have little to none scoring options available on typical web forum).

Even today I prefer to use gateways (like https://gmane.io) which converts mailing list to Usenet groups, as it makes for much easier (and faster) access than any mailing list archive. Unfortunately, can't gateway Github discussion Usenet groups 😢

[Lee-Carre]

Just some (nostalgic) comic relief (I couldn't resist): Posting And You….