A home for asynchronous discussion about KMK

[LukeDRussell]

Hi,
It would be nice to have a way to reference already asked questions. Github Discussions could be enabled on this repo with a simple settings change, as a way of organically growing the KB.

There is a lot of good stuff going through on Matrix, but it's still a Chat-based paradigm with, most of the downsides of synchronous communications. Like difficulty finding old info, it creates pressure on user to 'Keep up', it weaves content from different threads into the same wall of text, etc.

[klardotsh]

I have a strong preference towards handbook-based documentation instead of StackOverflow-esque "Discussions". IMO if it's important enough to move out of Matrix/IRC/etc., it's important enough to warrant a MarkDown doc in the docs/ tree. (but I do agree with you that asynchronous information finding is critical - it's something I harp on at work; it's something I should harp on in FOSS just as much 😄)

[kdb424]

I think I agree with @klardotsh here. If it's discussed in chat, and not a one off, an issue should be opened. Closed issues are never gone, and if it's a common enough issue, we need to make better docs. We do accept PR's for only docs if people find that information is lacking, and like many open source projects, we hope users "pay it forward". If someone helps fix your issue, and you feel it's going to be helpful to others, we would love some updated docs that you think would have helped you so we can solve these problems with a simple link, and not digging through message history.

[LukeDRussell]

OK, leave the documentation aside.

My main gripe is I don't want to use Chat at all, to contribute to KMK. I've looked at Matrix a few times in the last week or so. There were a few conversations in Matrix that interested me, and I could help with. I felt blocked though, because I can't participate in sync - I live in Australia. It also takes effort to de-thread conversations in my head and I just don't want to use that energy.

For the record I'm not anti Chat, I've introduced various types to a couple of operational organisations.

I feel that Github Discussions are a more inclusive medium than Matrix Rooms. They allow for Search Engine indexing, reduce/eliminate the mental overhead of interspersed chat topics, better enable asynchronous discussion. On top of that many more people have Github accounts than Matrix accounts.

[klardotsh]

Prelude and disclaimer: I have largely retired from KMK maintainership, and (as you might have noticed from my no longer providing binding PR reviews on much of anything) I'm trying to decrease my voice in these spaces to make room for others to carry this torch. More on that after this blurb.

Sure, let's leave documentation aside, though I still hold that regardless of the outcome of the rest of this, the docs/ tree is where long-term "help documentation" should live. Searching a forum should be a secondary step if grepping the docs tree can't help you. But let's move on.

You raise good points about timezones and general "untangling a wall of text" - both are inherent problems in IRC, Matrix, Slack, Discord, etc. and that this conversation is even happening is an interesting (and a bit exciting, in a way!) reflection of a growth painpoint KMK was bound to have to face eventually - I guess now may be that time. It's indeed probably worth considering separating the synchronous "help with this small, one-off thing" and general banter of Matrix (which I think is doing its job as a casual, synchronous chat place quite well - it's quasi-IRC, with a few UX changes/arguably-improvements, and IRC and/or Matrix is something almost all major FOSS projects have) from the development discussion and actual decision-making within the project (which is may be better suited for an asynchronous medium - especially given how Pull Requests are asynchronous anyway, too).

However, if we're introducing an asynchronous discussion platform, IMO it should not be GitHub, because KMK is, and has always been, a project by and for tinkerers, DIYers, and those who embrace that spirit. GitHub, as a closed-source and proprietary offering over which we have zero real control (a feature release can change our workflows by force or remove functionality at any time, and plus, GitHub exclusively controls who can interact with this space - see, for example, their blanket bans at various points on nationals or visitors to countries the US does not or did not do business with, such as Iran), does not, in my opinion, embrace that spirit. Further reading in this space by folks who are not me include:

• An oldie but a goodie, Free Software Needs Free Tools
• A much more recent one, It is important for free software to use free software infrastructure

If anything, I regret centering KMK's version control (and later, out of laziness, CI) on GitHub at all, and wish I would have put it on GitLab, a self-hosted service like Gitea, or (later in its evolution, since this tool didn't exist when the project started) perhaps Sourcehut, and would love to see the community not double down on a mistake I made four years ago, especially now that better tools in the space exist (and more awareness of that problem space exists, especially). We already have synchronous chat on a federated medium (Matrix), and can easily move source hosting and CI to other places. Let's not buy into the vendor lock "value-add" services that would tie us to one hosting provider when it's time to add asynchronous chat.

As for alternatives to GitHub: Mailing lists have powered Linux and PostgreSQL development for decades successfully. Discourse (plus RFCs which live on GitHub, whatever) power Rust's (and a few other projects') development and evolution in an asynchronous fashion. Heck, old BBS forums are great too - some free software projects of my youth used them as great help mediums (and some still do, decades later!).

All of this said...

This is up to the current community to decide. If the current community (and particularly @xs5871 as what amounts to the de-facto lead maintainer with me out 95% of the time and @kdb424 on a "here and there" basis) decide GitHub Discussions is where asynchronous KMK discussion should happen, I will not (ab)use my admin privileges or any other levers to inhibit such a decision or otherwise get in the way of it - consider this my piece I've spoken on the matter, and let's figure out where to go from here.

[kdb424]

I'll second that. xs5871 knows this community better than either of us at this point, and if they want the choice, I'll let them have it. I honestly don't have enough time to keep up with the rapid changes in KMK at this point in my life, and want it to do well, but am not in a position that I really even know what needs done, just how we got here.

[xs5871]

You're all raising very good points that we sooner or later have to address. A space for focused interaction would be wonderful.
Currently our ansynchronous organization and discussion tools are issues and PRs, the chat is it's own community thing.
I agree that chat can be hard to parse, especially if I only open it up twice a week. That is something I struggle with myself.
Issues and PRs can be used for topical discussions with a little discipline, no idea if github discussions would make that easier (never used them).

[LukeDRussell]

To get a sense of how Discussions work in active projects, see Tailwind CSS, Reveal.js, Rich.

Thanks for your thoughts @klardotsh on developing using Open tools. It wasn't an idea I'd considered much. I actually had to restrain myself from going too deep down the rabbit hole.

I'm going to rename this issue to something more general, like "A home for asynchronous discussion", as Github Discussion may not be the best answer for this community.

I see three main use cases for communications:

1. Talking about Changes to KMK

For: Bugs, enhancements, governance, docs, build pipelines.
Current: Github Issues, Pull Requests, Projects.
Alternatives: GitLab, Gitea, Bitbucket, SourceHut.

2. Talking About KMK

For: User help, showcases, surveys, etc.
Current mechanisms: Github Issues for async, Matrix Chat for sync
Alternatives: Github Discussions, SourceHut, Discourse, other Mailing List, IRC, Slack, etc.

3. Connecting to like-minded folks

For: Feeling good about our nerdy hobby.
Current: Chat (Matrix), I guess there might be phone/video between core contributors.
Alternatives: Github Discussions, Discourse, IRC, Slack etc.

Recommendations

1. I'm still recommending Github Discussions as first pick for async "Talking About KMK".
   a. Easiest to enable. Instructions.
   b. Easy for previously active maintainers and fans to contribute informally when they can/want.
   c. Doesn't have the mental hurdle of the "formalness" of Issues.
   d. Still uses Github identity, which many people have.
   e. Searchable by public search engines.
2. Ask Discourse for free hosting.
3. Set up Github Issue templates for different types of discussions. Bugs, Feature Request, Help Request, etc. Mostly the same benefits as Discussions.
4. Self-hosting GitLab, Gitea, Synapse, Mailing List, Discourse, etc. This is only viable if KMK has a contributor willing to build and manage and potentially pay for the infra. I'd prefer to be contributing KMK itself (mostly docs) rather than doing infra. This is from someone who works in IT Infra as a profession.

[klardotsh]

Given that I also host the Matrix homeserver our synchronous chat runs on, within reason I'm open to standing up and maintaining a self-hosted async discussion system if that's what's selected out of all of this.

[hendrix04]

I am super new to this community (flashed a keyboard for the first time yesterday).

I too prefer more of an async conversation for issues and discussion. Working all day and then immediately dealing with kids all night doesn't make for a lot of time to hang out in a chat room. Being able to ask questions such as, "How do people generally handle caps lock led toggling" is a lot easier to discuss in a forum than a chat imho.

[klardotsh]

After playing with the product this week on the primary public instance (disclosure: because I'm interviewing there, though this product has bene on my radar for years and I just never thought of it in a KMK context), I'll throw Zulip¹² in the ring as a "meet in the middle, linkable externally, sync-async-hybrid" form of communication. It's "IM", but with threaded streams of topics that can be marked resolved, and thus sits somewhere between email (topic-threaded, slow, private), forums (topic-threaded, slow, searchable), and Matrix/Discord (unending spew of words, not always topic-threaded, and when it is, macro-topics only, not searchable/referenceable).

Footnotes

1. https://zulip.com ↩

2. https://github.com/zulip/zulip ↩

[klardotsh]

@LukeDRussell @xs5871 @kdb424 what do we think about trying to figure out an agreeable path forward (whatever that looks like) some time by end of November? That gives us on the maintainer side December to set things up, and allow us to have this paradigm sorted out for the new year (if we decide to move forward at all, though I think we're growing more and more evidence in favor as the project continues to grow new users, and as maintainers and contributors continue to allude to the Matrix room being a huge source of burnout or overwhelmingness)

[kdb424]

I have zero opinions, and whatever works fine. As long as users are happy, then I'll chime in where I can, but I'm fairly inactive in general, so I don't really have a reason to disagree with any decision at this point.

[xs5871]

Never heard of it, but I'm more than willing to try it out.

[LukeDRussell]

It’s a big thumbs up from me.

I did look into Zulip a while ago for a work use case. I was really impressed by the channels within channels threading paradigm.

[klardotsh]

Posting this to both issues (#437 and #650):

The KMK Zulip instance now exists, and allows registration with email, GitHub OAuth, Google OAuth, or GitLab OAuth. Once xs5871 is in the instance, they will be promoted to an equal administrator alongside me.

I've requested FOSS sponsorship to enable things like public permalinks which should fully bridge the gap between IM and "forums-style" chat: linking Zulip discussions in GitHub Issues would allow any future readers to catch up on context without signing up for an account on the Zulip instance, for example. I'll report back with the outcome of my sponsorship request (I imagine, given that I now work for Zulip and also given that our Matrix room historically is relatively slow-paced, there should be little drama in that request).

[klardotsh]

Zulip Cloud FOSS sponsorship granted this morning, the linked instance above now has features like public-anonymous permalinking enabled.

[LukeDRussell]

Love your work folks. I know I haven't been active the last two months, the new job has been hectic. I appreciate the new threads.