[lapcat]

> I recall free node dying off or something a few years back?

Yeah, a kind of hostile takeover occurred, which the IRC community did not appreciate.

> Again, I think you grossly overestimate the amount of recorded "discussion" that goes with a bug.

Perhaps so. Seems a bit odd to me though. And a bit lonely :-)

> The lack of explanation is typically because the engineers working on changes have the context for why a change is needed, so don't include an explanation.

Well, I think it's worth noting that this is not very helpful to outsiders who are looking at and working with the code of an open source project.

Even in my closed source self owned projects, I like to provide useful context to my future self. ;-)

[olliej]

> Perhaps so. Seems a bit odd to me though. And a bit lonely :-)

People communicate in IRC (or a public slack now based on another comment?), in person, or in email. So when needed communication happens, it's just generally back and forth commentary in a bug is not a particularly good or efficient way to discuss implementation of bug fixes, features, etc.

> Well, I think it's worth noting that this is not very helpful to outsiders who are looking at and working with the code of an open source project.

Because it's a bug tracker being used to track bug fixes, not a tool for communicating with arbitrary people not involved in the project? I don't mean to be glib, but for WK at least that's just not what the bug trackers are used for.

> Even in my closed source self owned projects, I like to provide useful context to my future self.

In the bug report or in the code? Generally IME when code does things that are odd the explanation of that oddness is in the code (assuming not self explanatory) not the bug tracker.

It also depends on the bug itself, bug fixes you'd normally be able to see why a change was made (if not obvious from the title/description) is the attached test cases.

[lapcat]

> So when needed communication happens, it's just generally back and forth commentary in a bug is not a particularly good or efficient way to discuss implementation of bug fixes, features, etc.

I disagree, because whether it's the intention or not ("it's a bug tracker being used to track bug fixes, not a tool for communicating with arbitrary people not involved in the project"), the bug report de facto becomes an important historical record for understanding the code. In the future, when someone looks back, the question that often comes to mind is "Why?" Why this (that)? Why now (then)? The motive, the historical context, is rarely something that becomes evident just looking at the code, even code with comments.

Can I change this code? Can I delete this code? How did this code ever work? You can't rely on unit tests to tell you the story behind the code. And when you come upon some "questionable" code, it's equally likely that the comments and/or tests are questionable too.

If the code was written to handle something publicly important, if debates were had, alternatives considered, choices made and rejected, that's worth knowing, in my opinion.